Proof of Reserves Project - Research Notes

Just a dump of Stent's notes, not super organized or neat. # Table of Contents 1. [Resources](#org397c0a5) 1. [Coinbase project resources](#org2543fd8) 2. [Silver Sixpence](#org849f78d) 3. [Shashank](#orgd8560dd) 4. [Vitalik](#org6a1bce3) 5. [Nic Carter](#orgb43f430) 1. [Chamber of Digital Commerce](#orgeaadad6) 6. [Academic papers](#org15bd847) 1. [Provisions](#org77c529f) 7. [Summation Merkle Tree](#org12df67c) 8. [Proven](#org020b158) 9. [Summa](#org5dc9024) 1. [Alternative approach](#org711dd5f) 2. [Privacy of verifier](#org7d8d23a) 10. [MystenLabs/calibra](#org4b54e0c) 1. [DAPOL+](#orgf6624a6) 11. [Diem (Libra)](#orgd7d2ce0) 12. [Chainlink PoAL](#org0dff73f) 1. [PoL](#org31c25df) 2. [PoR (assets)](#org7295bf6) 13. [BIP standard for PoA](#org0134e5a) 14. [Monero](#orgca0cc78) 15. [TLSNotary](#orgebef641) 1. [Performance](#orgc43bd60) <a id="org397c0a5"></a> # Resources Apparently the first person to be talking about proof of solvency: <https://web.archive.org/web/20170106070229/https:/people.xiph.org/~greg/bitcoin-wizards-fraud-proof.log.txt> [2022-12-07 Wed] A call to standardize PoRL by @kostascrypto: <https://twitter.com/kostascrypto/status/1598104696090075138> - @zkproof is a standardization org that was keen to get involved: <https://zkproof.org/> [Episode 256: New ZK Use Cases with Dan Boneh](https://zeroknowledge.fm/256-2/) - Dan mentions that we need to have standardization for PoS Some other proof of solvency <https://gusty-radon-13b.notion.site/Proof-of-solvency-61414c3f7c1e46c5baec32b9491b2b3d> <a id="org2543fd8"></a> ## Coinbase project resources CB Project Milestones <https://docs.google.com/spreadsheets/d/1QGyZipj1h1_07AqBjX8GDDMgLDX6WjLEqvLjPF8aFPs> Blog article prep <https://docs.google.com/document/d/1ef5fc3M90lLHIf-n8Qpzudsw4HQNMiYNA1kIXi-ntnk/edit#heading=h.a5jyeqa4ehbq> [2022-11-07 Mon] Coinbase $500k grant to encourage proof of reserves: <https://twitter.com/coinbase/status/1596188655638355968> Coinbase has around 108M users <a id="org849f78d"></a> ## Silver Sixpence Merkle tree for Proof of Liability - <https://github.com/silversixpence-crypto/merkletree-verify> - <https://merkle.silversixpence.io/> <a id="orgd8560dd"></a> ## Shashank [Shashank's research into PoS solutions/protocols](https://docs.google.com/document/d/1LsNAetgZhTP1f7YSHpNl1CeeS8oSAPlBD2enRYMeWFE) <a id="org6a1bce3"></a> ## Vitalik <https://vitalik.ca/general/2022/11/19/proof_of_solvency.html> Instead of an SMT the proposal is to use a Kate commitment, but I don't understand how to prove the balances. <a id="orgb43f430"></a> ## Nic Carter <https://niccarter.info/proof-of-reserves/> - list of exchanges currently doing PoR - list of papers - list of articles - etc <a id="orgeaadad6"></a> ### Chamber of Digital Commerce <https://digitalchamber.org/proof-of-reserves-blog/> Nic Carter helped create their long document of PoR. <a id="org15bd847"></a> ## Academic papers SoK for Crypto Audits - ACNS 2021 (the most comprehensive Survey on what algorithms exist - probably read this first as you'll find concrete solutions even for zCash, Monero etc) <https://eprint.iacr.org/2021/239> GPOL scheme for Proof of Liabilities - CCS 2021 (the most recent protocol for proving liabilities - considered for standardization + top10 finalist in CSAW 2022, one of the most prestigious applied research competitions re most innovative / impactful papers of the year) Tech: sparse Merkle trees + Bulletproofs range proofs + random sampling <https://eprint.iacr.org/2021/1350> gOTzilla scheme for Proof of Assets - PETS 2022 (the most recent protocol for proving assets when hashed public keys are used) Tech: MPC in the Head <https://eprint.iacr.org/2022/170> Broken Implementations for Proof of Reserves in major exchanges - CoDecFin FC 2022 (as you will notice NOBODY is doing it right: all Deloitte, Kraken, Armanino, the old Coinfloor and BHEX etc audits have exploitable bugs or processes) <https://eprint.iacr.org/2022/043> [2023] Instant Zero Knowledge Proof of Reserve <https://eprint.iacr.org/2023/1156.pdf> <a id="org77c529f"></a> ### Provisions [[CCS15] Provisions: Privacy-preserving proofs of solvency for Bitcoin exchanges](https://eprint.iacr.org/2015/1008.pdf) <https://pdfs.semanticscholar.org/db25/42bba9ae84ca7d8a1c563b8b69f08a1a75ad.pdf> <https://xiaohuiliu.medium.com/zero-knowledge-proof-of-solvency-for-crypto-exchanges-ba787a3cb1d> <https://github.com/bbuenz/provisions> 1. PoA The proof size is linear in the size of the anonymity set n. 500k users => ~300MB proof size 1. Some missing proofs? The ZK protocol only has a proof for Honest Verifier Zero-knowledge (appendix B & C), not for if the verifier is malicious - can have a contract that is the verifier and then you can be sure that it is honest - since the Fiat-Shamir heuristic can be used to make this non-interactive it is not necessary to consider malicious verifier because the verifier has no input in the protocol It also does not have a soundness proof, only a completeness proof - ZKPK (argument of knowledge proof) is stronger than soundness - Why does ZKPK show that malicious prover (does not know whether value exists to make statement true & does not know value to make statement true) cannot convince verifier? - Running the extractor assumes the prover has already convinced the verifier, so if prover knew nothing then it contradicts the ZKPK because ZKPK says the prover knows the value 2. Proof of non-collusion Every exchange is required to publish a list L which is all 1s for addresses not owned by the exchange, and some essentially random group elements for the addresses that the exchange does know. You check for collusion by finding non-empty intersections of sets from different exchanges. One cannot infer the public or private keys from this list but one can determine how many addresses the exchange owns. One hurdle to overcome with this protocol extension is to have every exchange do their PoA at the same time (otherwise collusion is still possible). They actually don't have to run the protocol at the same time, they just have to agree on the same block number to run the protocol against. 2. PoL Given 2M users that have a 51 bit balance the proof size for PoL is ~18GB and proof time is ~5 hours (on a rather beefy machine) <a id="org12df67c"></a> ## Summation Merkle Tree Merkle Tree with sums of balances, called a Summation Merkle Tree (SMT) [2013] Maxwell <https://bitcointalk.org/index.php?topic=595180.0> Maxwell+: security flaw was fixed in [Hu, Zhang, and Guo (2019)](https://eprint.iacr.org/2018/1139.pdf) - attack involves using max(node1, node2) instead of sum(node1, node2) Maxwell++: split users into fragments to obfuscate info (some info could be guessed: total number of users & other users balances): [Ji-Chalkias (2021)](https://eprint.iacr.org/2021/1350.pdf) - height of the tree indicates number of users - if the full tree is private then this is only revealed to users who request proof that they are in the tree - if the full tree is public then this is revealed to everyone - leaf node reveals the balance of another user - if the full tree is private then this only 1 leaf node is revealed to each user who requests proof that they are in the tree - if the full tree is public then this is revealed to everyone i.e. everyone's balances are public but not their identities [Philippe Camacho. 2014. Secure Protocols for Provable Security](https://www.slideshare.net/philippecamacho/protocols-for-provable-solvency-38501620) - SMT but with Pedersen commitments and range proofs Summary of vulnerabilities & privacy leaks for the various tree types: [Broken Proofs of Solvency in Blockchain Custodial Wallets and Exchanges](https://eprint.iacr.org/2022/043.pdf) Note the size of an SMT is [claimed by Chainlink](https://blog.chain.link/proof-of-solvency/#benefits-and-challenges) to be on the order of 100s of GB for 100s of millions of users, which seems to be fairly accurate but does obv depend on the size of each node: - <https://www.unitconverters.net/data-storage/character-to-kilobyte.htm> - <https://photo333.com/text-to-kb.php> - <https://www.desmos.com/calculator/49azbv0gdl> - note that with the Maxwell++ tree there will be more nodes than users IDEA: sparse Merkle trees are computationally more expensive to create than regular Merkle trees. In order to keep the privacy property of obfuscating the number of leaf nodes (users) while not having a negative affect on performance would it be possible to have the leaf nodes at different heights? If using Pedersen commitments then a user could not tell, when asking the exchange for proof that they are in the tree, if the nodes given to them are leaf nodes or have sub-trees (will have to have whole tree privately stored with exchange). Am not sure if there are security issues with this approach or not. Another possible approach would be to have more than 2 children nodes for a particular parent. This has problems with the summation part because more than 2 things to sum together means you don't know which of the values come from which other sibling nodes besides the one you know. <a id="org020b158"></a> ## Proven <https://www.proven.tools> - not much info at all, some links for crypto primitives <https://cointelegraph.com/news/former-jane-street-pimco-traders-raise-15m-for-zk-proof-of-solvency-protocol> - news of $15m fund raise in March '23 <https://twitter.com/ProvenTools> <https://twitter.com/AgustinLebron3/status/1633934250620891136> - one of the founders <https://twitter.com/slopeagency/status/1635424259525816321> ["Proof-of-Solvency: security models, privacy guarantees and the future" (Craig Newbold, Proven)](https://www.youtube.com/watch?v=ChX8MuRVzmw) Similar to above video: [Proving Solvency: Using cryptography and game theory to enable trustless audit](https://www.youtube.com/watch?v=7ozDvZTjSOM) Seems like their protocol is just 1 snark: - public inputs: merkle root, anonymity set, message for signing - private inputs: signatures from wallets, user balances - computation: - build full merkle tree, check that it matches the root - add up user balances - add up assets for accounts that have matching sigs - check liabilities < assets Each user is then sent a merkle inclusion proof that they should verify. Security is ~80 bits, and has to be this way to keep the prover time reasonable (the hashes are expensive, Poseidon-80 is ~171 constraints in R1CS) <a id="org5dc9024"></a> ## Summa Only PoL [(Thursday Talks) ZK Proof of Solvency with Summa](https://www.youtube.com/watch?v=F-Q31AwuTCU&t=33s) - from the 0xPARC foundation youtube page Creator: <https://twitter.com/backaes> Source: <https://github.com/summa-dev> - this is the repo that is currently being worked on: <https://github.com/summa-dev/summa-solvency> Protocol: - Exchange builds basic SMT - Exchange publishes root hash - Exchange produces zk-snark proofs for every user that show: user is in tree, tree matches root hash, tree adds up to total sum - Exchange shares proofs with users Uses Halo2 so no trusted setup. The exchanges total liabilities are hidden, although this cannot be seen from the diagrams in their [old circuit repo](https://github.com/summa-dev/pyt-circuits). How does exchange share proofs with users? - if publicly this leaks num users and possibly the user info too because how is each user supposed to know which proof is theirs? - if private then we have the same who-is-telling-the-truth problem: how can the user prove to others that they should have gotten a proof but did not? - This is important: "The exchange shares a proof to each of its users. It is important that the proof is the action of sharing the proof is initiated by the exchange rather than actively queried by the user. In the second scenario, the exchange gets to know which are the users that are interested in verifying the solvency of the exchange and which ones are not." What if a user finds that their balance is misrepresented? - could do another snark to prove that they are in the tree but balance is wrong - snark: - private inputs: account ID - public inputs: original snark the exchange produced for user, leaf hash for user, actual balance, fake balance (would have to be guessed by brute force) - computation: verify snark, check fake balance + account ID create correct leaf hash - user would have to then just make public their actual balance and show that it is indeed the real one (how to do this cryptographically?) What if a user finds that they should have been given a proof to verify but did not get one? - Not easy to show this unless they expose their private info. How much computation must be done to produce the proofs given n users? [This article](https://ethresear.ch/t/snarked-merkle-sum-tree-a-practical-proof-of-solvency-protocol-based-on-vitaliks-proposal/14405/6) seems to be similar to Summa from [2022-12-02 Fri] - links to [zk-attestor](https://github.com/yi-sun/zk-attestor) which could be useful for private PoA but the readme is sparse and I haven't read the circom code yet - this is part of the Axiom project <https://www.axiom.xyz/> Also links to [another article](https://www.coincenter.org/how-can-cryptographic-proofs-provide-a-guarantee-of-financial-solvency/) that has a very soft non-mathsy way of explaining the basics of ZK PoS. [2023-06-28 Wed] Enrico said: as of now each proof is 2752 bytes, so 100M proofs are 256 GBs [Instant Finality Proof Of Solvency](https://hackmd.io/snKUDmGfRYaRTZFPPBPowg) <a id="org711dd5f"></a> ### Alternative approach <https://github.com/orgs/summa-dev/discussions/3> Protocol: - All user data is on IPFS (hashed) - Exchange does snark to produce merkle tree of user data and add up all the balances - Chain verifies proof and balance sum - User verifies that they are in the set on IPFS How does a user show prove that they should be in the set but are not? How big is this data that is on IPFS and how often do exchanges post new data? What is the cumulative cost function? <a id="org7d8d23a"></a> ### Privacy of verifier Currently the tree is planned to be held with the exchange. This means the exchange will know who is requesting inclusion proofs, which means that over time and multiple PoLs the exchange may be able to safely exclude certain users from the tree and go undetected. One way to circumvent this problem is to make the tree fully public. This does, however, expose the number of users of the exchange to everyone. This approach is also not feasible due to the fact that each inclusion proof is 2752 bytes, so with 100M users that's 256 GBs total. Another method that might work is to do the following: 1. Exchange groups leaf nodes together and commits to each grouping by publishing some data on-chain 2. User can determine which group they are in using their hash and the on-chain commitment 3. User requests from the exchange all the inclusion proofs for a particular group As long as the exchange does not know the identity of the user that does the query they do not know which proof will be verified, only that it is one of the many in the group. More formally: <a id="org4b54e0c"></a> ## MystenLabs/calibra <https://twitter.com/kostascrypto> - [Practical Privacy Preserving Proofs of Solvency - Kostas Chalkias](https://www.youtube.com/watch?v=EH40KY5P5Y0) - <https://community.zkproof.org/uploads/short-url/v6QCjfWfHUxjlWTpBaLF1qlAQw5.pdf> - TODO Fully zk is too good, regulators want to know certain bits of information from the data, read about Differential Privacy - What about multi-sig wallets? - TODO HSM / cold wallets (read about HSM) Podcast: [Episode 257: Proof of Solvency with Kostas Chalkias](https://zeroknowledge.fm/257-2/) [Distributed Auditing Proofs of Liabilities](https://eprint.iacr.org/2020/468) (dapol) (2020) - Accepted as a standardization proposal draft in the 3rd [ZKProof](https://zkproof.org/) workshop 2020 <a id="orgf6624a6"></a> ### DAPOL+ [Generalized Proof of Liabilities](https://eprint.iacr.org/2021/1350) by Yan Ji and Konstantinos Chalkias ACM CCS 2021 paper - Implementation <https://github.com/MystenLabs/dapol> - this is dapol+ / gpol In section 3.5 (Privacy Definitions) there is a term that is given but not explained, presumably because it is common in the literature: "leakage function Φuser". What is this? For user privacy, does the protocol have this property: if some adversary that knows the user data for all users in some subset V of all the users U, and all their inclusion proofs, then they cannot determine any other users' data (U-V) and they cannot determine the amount of users of the exchange. If someone has the whole tree, what can they infer about user's data (also considering multiple PoLs at different times) and what can they infer about the number of users in the exchange? - well for one the hashes are the same as long as the salts are the same, so if the salts are different then it would not be possible to track the same user over multiple trees - since the padding nodes are added at different heights and the user nodes are all at the bottom there can be an upper bound placed on the number of users of the exchange, but is this a bad thing? - could you place users at random points in the tree (i.e. not just at the bottom)? Would this help in hiding the number of users from the party that has the whole tree? What about adding additional padding nodes in random places (not just as fillers of the user nodes)? For multiple PoLs why does one need to use ORAM-SMTs? Why can't you just have the timestamp as part of the hash? If we want to use the 3PP method then range proofs only need to be provided for the leaf nodes, which the 3rd party can verify in a snark (to show everyone that they indeed verified the ranges). Furthermore.. if the tree is only to be seen and used by the 3rd party then it can be condensed to the minimal size, since the 3rd party would already know the number of users so why try hide it? But likely the tree will be used for any users to query so needs to stay sparse. What is appendix F (dispute resolution) about? It talks about a user sending funds to another user (in the same exchange or in another). In section 4.3 (Accumulator Variants) there is this statement for 4.3.2: "Note that since 𝑢 and P need to agree on 𝑙𝑢 for PoL, P can in the meanwhile send each user 𝑤𝑢 in a similar application-specific registration process before P generates the SMT, which won’t affect the security or privacy guarantees of DAPOL+" - but why must w be shared with the user before the exchange creates the tree? What security risk is posed if this is not done? 1. Idea to adjust the tree so that it can be made public Regarding the topic of "Privacy of verifier identity" in section 4.4.3 The DAPOL+ tree was intended to be held by the exchange. The problem with the exchange holding this data is that they would know who is requesting inclusions proofs, and over time they might know the set of users who like to do verification which means they can potentially omit other users from the PoL without detection. There is the option of PIR as mentioned in the paper but the time complexity on this operation is high for both parties (actually not sure how high exactly, still need to read the papers on this one.. ). One way to solve the exchange-knows-which-users-verify issue is to make the tree public. With DAPOL+ as far as I can see the only information that would be leaked by a public tree is the number of users of the exchange; even over multiple PoLs it's not possible to track users since the hashes can made different by picking a different master key for each PoL. To solve this then I was thinking the following: - the users are currently bottom leaf nodes only, which puts [to any observer of the tree] an upper bound of `<num_leaf_nodes>` and a lower bound of `<num_leaf_nodes>/2` on the number of users - what if the tree was constructed by assigning users random points in the tree (not just bottom nodes), then peppering the tree with 0-commitment nodes in a random manner the same as the user nodes, and then adding padding nodes (have to assume that the NDM-SMT accumulator here) - the number of 0-commitment pepper nodes could be adjusted at the exchanges will to achieve whatever level of privacy required (the more nodes the more private) - the range proofs would be simpler too: the exchange would only need to give range proofs for all the leaf nodes (as long as the range proof upper bound is sufficiently less than the order of the group), and using Bulletproofs these can be combined into 1 range proof which would minimize proof size <a id="orgd7d2ce0"></a> ## Diem (Libra) [Proof of Assets in the Diem Blockchain](https://eprint.iacr.org/2021/598.pdf) - @kostascrypto <a id="org0dff73f"></a> ## Chainlink PoAL <https://chain.link/proof-of-reserve> Not ZK, uses oracle network <a id="org31c25df"></a> ### PoL <https://blog.chain.link/proof-of-solvency/> - details their PoL idea References Maxwell, SMT, DAPOL, DAPOL+ states some problems about existing ideas (they are not really credible or unfixed issues) states 3 ideas about how using oracles is beneficial (non of the ideas really stand out as novel or are not already solved by other methods) 1. Problems with SMT The article states some problems with SMT, starting with "the operations involved in orchestrating an SMT-based auditing via user self-checks". 1 of the operation stated is not always required: "There must be an SMT service providing users with inclusion-proofs against a fresh root." - if the dapol+ SMT tree with Pedersen commitments and range proofs is used then this whole tree can be public available on decentralized storage like IPFS and there can be a script that runs in the browser to verify a user's inclusion in the tree 1. "Freshness" concern Note the size of an SMT is claimed by Chainlink to be on the order of 100s of GB for 100s of millions of users, which seems to be fairly accurate but does obv depend on the size of each node: - <https://www.unitconverters.net/data-storage/character-to-kilobyte.htm> - <https://photo333.com/text-to-kb.php> - <https://www.desmos.com/calculator/49azbv0gdl> - note that with the Maxwell++ tree there will be considerably more nodes than users There is also a concern about data freshness, which is valid because user's balances can change frequently and they may not know which balance they should use for the verification. 2. "Completeness" concern It's up to the users to do their due diligence in order for a malicious exchange to be caught. DAPOL+ does have some stats around this e.g. how many users does it take to do the verification for an exchange to be caught if the exchange changed/omitted X accounts. 3. "Dispute handling" concern This is very relevant because how does a user prove that they were not in the tree but they should be, or if their balance in the tree is incorrect? There is an snark idea that could help with this, detailed below. 2. Suggested improvements using oracles 1. "Oracles can store on behalf of the CEX the SMT of commitments to end-user account balances and serve user self-checks" This is very similar to having the tree stored in decentralized storage like IPFS Difference is that only the oracles know the SMT. 2. "Oracles can help orchestrate inclusion self-checks on behalf of end-users." Not sure what this section is actually talking about or what how this helps. 3. "Oracles can automate the triggering of self-checks on behalf of end-users." This could be helpful, but not sure exactly which advantages it has over just a script running in the browser has. There is the issue of users having to give their data to the oracles, but maybe some zk can help here e.g. user proves their balance at time t using a snark then sends this proof to the oracle network along with a snark proof that they have the data to construct the leaf node to be used in the tree for time t, oracles can then do all the checks themselves after CEX has published the tree. Also! To build on above idea.. oracles could also tell the CEX which balances to use for the users, which allows different times for each user to be used for the tree. As long as the times are not so far apart then it should be acceptable to use these balances in the tree. And this way we get around the problem of user's not knowing which balances to use for tree verification (assuming user's balances change at a rapid rate). NOTE: user sends zk-snark proof + commitment of account ID (hash?) NOTE: possible issue: exchange knows which users want to verify so they can specifically include those users and leave out the rest Make the Proof of Solvency Verification process non interactive: <https://github.com/orgs/summa-dev/discussions/2> <a id="org7295bf6"></a> ### PoR (assets) <https://chain.link/education-hub/proof-of-reserves> - details their PoA system Ideal for taking off-chain data and putting on-chain, via their oracle network. The off-chain data is inherently trusted. Can use this data to restrict minting of wrapped/backed tokens for only when total supply < reserves. Examples of off-chain reserves for wrapped tokens: - [TUSD](https://trueusd.medium.com/trueusd-becomes-first-usd-backed-stablecoin-to-secure-minting-with-proof-of-reserves-fe8dbffde44f): "Reserve data for TUSD is aggregated by The Network Firm LLP (“TNF”), an independent, industry-specialized accounting firm in the U.S." - [PoundToken](https://chain.link/case-studies/poundtoken) - [Cache Gold](https://chain.link/case-studies/cache-gold) Another use case is cross-chain reserves, example: [Swingby](https://chain.link/case-studies/swingby) <a id="org0134e5a"></a> ## BIP standard for PoA <https://blog.blockstream.com/en-standardizing-bitcoin-proof-of-reserves/> <https://github.com/bitcoin/bips/pull/756> Does not seem to have any privacy on the exchanges' UTXOs <a id="orgca0cc78"></a> ## Monero [MProve: A Proof of Reserves Protocol for Monero Exchanges](https://eprint.iacr.org/2018/1210.pdf) <a id="orgebef641"></a> ## TLSNotary <https://tlsnotary.org/> - <https://github.com/tlsnotary> - [Nethermind notes](https://nethermindeth.github.io/lido_phase_1/Database%2011b9b21206a8466191f8587fb73edf58/TLS%20Notary%20ff29d483f9514e47b6d9ebfd5c93be56.html) - <https://tlsnotary.org/TLSNotary.pdf> - [Optimization Strategies for TLSNotary](https://hackmd.io/@clique/r1gYyzjYj) Shashank says 2PC can slow down the connection by 100 or 1000 x DECO - [Nethermind notes](https://nethermindeth.github.io/lido_phase_1/Database%2011b9b21206a8466191f8587fb73edf58/DECO%20adaf7e5a69294d0eb44b3b174d6a3a3b.html) [TLS-N: Non-repudiation over TLS Enabling Ubiquitous Content Signing for Disintermediation](https://eprint.iacr.org/2017/578.pdf) <a id="orgc43bd60"></a> ### Performance [2023-06-29 Thu] From their Discord server: > Hey, unfortunately we havent run the protocol under WAN conditions yet but gimme a minute, I'll give an approx cost. > > In the most favourable conditions with access to AES-NI and all optimizations applied, for a 4KB request the Prover would have to upload ~25MB of data and download ~11 MB of data. Assuming the request is followed by a 4KB response, then the Prover needs to download another ~11MB of data. > The CPU cost for the Prover (assuming AES-NI) would be in the 100 milliion cpu cycles area. > There is no significant memory cost. is it a resonable cost? Depends on a few things: - is the relationship between original message size & extra download/upload size linear? i.e. if request is 40kB then is upload ~250MB? - what size is a typical response size between user and exchange? Some websites might make specific requests for user balance data (likely small), some might use graphQL to get all the data needed to render a page (likely too big) I think it's possible that it will be a reasonable cost because the size of a message containing only balance data should definitely be smaller than 4kB from discord: > yes, for both request and response it is linear