Thinking about the following: Let’s imagine that we had OP_CAT and that it did indeed give us introspection, STARKs + state-carrying ability (to build rollups, validiums etc), or even other opcodes that solve it even more neatly (take your pick of OP_TXHASH, OP_CCV, OP_MERKLEBRANCHVERIFY, OP_STARK_VERIFY, OP_M31ADD, OP_M31SUB, OP_M31MUL, OP_M31INV, <insert 64-bit arithmetic opcodes here>) What would the ideal L2 construction look like for Bitcoin? What we don’t want to do: repeat the Ethereum playbook—200 competing teams building different L2s, poor interconnectivity/composability all competing for the same users, what *DO* we want to do? Which lessons can we learn from Ethereum? Keep in mind that we can’t (nor do we want to) do based rollups. The L1 is too slow for that, and we don’t want baselayer MEV of that nature. Also keep in mind that we want: - A high-TPS transaction system (Lightning without channels basically) - Some will want more expressivity (for trustless stablecoin loans, AMM swaps, vaults, inheritance plans, leverage products) Should these two types of systems exist on the same execution layer, or is it best to separate payments from applications with different sequencing queues (I tend to believe so) — maybe we want to go in a Celestia-ish direction of doing one zkVM L2 and all the other systems as L3s, separate queues but aggregation via the L2. Doing real rollups for anything at scale is basically out of the question for the endgame vision given the low throughput of the L1 and the DA needs (and adding blobs seems highly unlikely) so we’d most likely be running some flavor of validiums + external DA-layer, zk-plasmas or client-side validation-based architectures like Miden. Also, we should explore whether we want pure ZK-systems or hybrid proving (”optimistic ZK”, see Fuel for ref) to maximize throughput even further. One way is to let the free market win and just see what happens, but that’s what Ethereum did. Even if we take the lessons in with us and teams try to coordinate around singular aggregation solutions from the getgo, there’s no guarantee at all that it will work. We also don’t have any ability to enshrine any particular execution layer via the L1. Still, it is clear to me that STARKs present the best path for all of the following: - Trust-minimized payments (without channels, routing or liquidity requirements) - Expressivity (for those who want it) - Privacy (full ZK-privacy VMs) - Achieving all of the above without introducing any exotic cryptographic assumptions, trusted setups etc. You may ask about finality because of the latency of the L1, but imo it can quite clearly be addressed to a satisfying degree with bonded sequencers for fast pre-confs. So we have all the tools, what do we do to arrange the best possible outcome? While BTC should obviously be the currency for all these systems (and pay for fees/gas), there’s the last (or perhaps first) question about how to achieve all of this without introducing an L2 token mostly controlled by a Foundation with too much control. I think a payments-only system can work fine without a governance token (with just central sequencing + unilateral exits against censorship), but I doubt it for anything expressive. While most Foundations/DAOs have decentralization as goals, putting that much power in the hands of a centralized org even in a bootstrapping phase seems suboptimal to me if we want some kind of collective approach from the getgo to mitigate fragmentation risks. Would be great to hear what other people think from people with experience from other ecosystems like Ethereum, Celestia, Polygon, Cosmos and also curious how current L2 teams working on Bitcoin are thinking about these questions (e.g. Alpen, Chainway, Starkware). Please feel free to chime in in the comments!

@ryanberckmans As long as people keep asking ”which rollup should I deploy to” and the answer is ”Base stage 0 rollup” (with complete alignment with Coinbase stock quarterly earnings), IDK