On ZK STARK amortized proof size for @Zcash: Part of the important discussion around having a TZE (Transparent Zcash Extension) for @Starknet is about the size of a ZK STARK proof and whether it'll cause congestion. Similar discussions will arise if ZK STARKs are to be settled onto Bitcoin. The issue is that a single ZK STARK is a bit long. How long? We haven't optimized it yet for TZE deployment but I believe it'll be 20-100 KB for a single proof. Given that a shielded Sapling tx is about 2KB, this means one STARK proof is like 10 to 50 txs. (The older Sprout txs are about 20KB each). I argue this is not a problem, for 2 main reasons: 1. You can chop a STARK proof and verify it over time. Done right, this even drastically shrinks proof size (you use the PoW as additional security). In fact, when we verify STARK proofs on Ethereum, we already chop them up this way, to fit inside Ethereum txs. 2. ZK STARKs excel at scaling a blockchain. A single ZK STARK proves the equivalent of hundred of thousands, or even millions, of txs. The number of txs covered by a single proof is nearly unlimited. And they are submitted to the L1 at a rate of once every few hours (currently on Ethereum its once every 6 hours). So, do the math: Starknet has capacity of about 1000 TPS for transfers (it can also do more elaborate computations, like gaming or perps). If you submit a ZK STARK proof every 6 hours, that proof covers 1000 x 3600 (seconds in an hour) x 6 (hours) = 21.6 M txs. The proof itself fits inside 50 txs. This means that amortized, one chunk (the equivalent of one shielded tx) covers 432,000 txs. Or, each single bit of this proof covers about 27 txs. Summarizing: For the price of 50 txs every 6 hours, you can scale Zcash (and Bitcoin) immensely, while also offering programmability and good UX (native account abstraction). The END