I put together a summary of Casey Rodarmor’s recent talk on the current Bitcoin L2 and meta-protocol ecosystem. Using the transcript attached, I asked GPT to break down the different solutions, their trade-offs, and what they might mean for Zenon.
The idea is to give our community a clear overview so we can discuss which paths make the most sense for us going forward.
Meta protocols (L1 overlays)
| Protocol | What it is (from the convo) | Strengths | Weaknesses / Risks | Fit for Zenon (NoM) |
|---|---|---|---|---|
| Ordinals / Inscriptions | Data embedded in Bitcoin txs; NFTs and arbitrary payloads without consensus changes. | Pure L1 settlement; huge mindshare; minimal new trust. | Bloats blockspace; weak on-chain logic; UX via indexers; culture volatility. | Good for awareness (NFTs, culture). Low core-tech leverage for NoM. |
| BRC-20 → “BRC-2.0” | Token instructions in JSON inscriptions; 2.0 expands capabilities beyond basic mint/transfer. | Dead-simple to launch; liquidity/culture flywheel. | Spec churn; indexer fragmentation; poor composability; fee sensitivity. | Marketing only. Not robust for infra; avoid as primary token stack. |
| Runes | UTXO-native fungible tokens meant to be cleaner than BRC-20. | Leaner design; better UTXO hygiene; simpler than JSON blobs. | Still indexer-dependent; limited programmability. | If you must do tokens on L1, prefer Runes over BRC-20. Still not ideal for NoM core. |
| Bitmap / similar metas | Social/experimental inscriptions (land, identities, etc.). | Community engagement and meme energy. | Speculative; no hard guarantees; noisy. | Community content only. Keep separate from NoM’s core roadmap. |
| RGB (client-side) | Client-validated assets/contracts with Bitcoin anchoring. | Scales without L1 bloat; strong privacy; powerful semantics. | Tooling is complex; UX heavy; fewer turnkey apps today. | Promising for asset layers around NoM if you want client-side validation + BTC anchoring. |
| Taproot Assets | Assets anchored on-chain, routable over Lightning. | Payment-first UX; leverage Lightning rails. | Operational complexity; Lightning liquidity constraints. | Great for payments on the edge; pair with NoM for spend rails, not stateful logic. |
L2s, sidechains & constructions
| Solution | How it works (per the convo) | Pros | Cons / Risks | Fit for Zenon (NoM) |
|---|---|---|---|---|
| Lightning | Channel network for instant BTC payments. | Mature, battle-tested; instant & cheap. | Not general compute; liquidity/routing mgmt. | Yes for payments. Integrate for spend/use, not app logic. |
| Stacks | Smart-contract chain tied to Bitcoin events. | Rich programmability; existing dev base. | Indirect security; different trust/model. | Limited fit. Philosophy/security differ from NoM’s plan. |
| Liquid (federated sidechain) | Pegged BTC managed by a federation; fast finality. | Stable, production-ready; good for exchanges. | Federation trust; not Bitcoin-trustless. | Only for bridges/liquidity hubs, not core settlement. |
| Rootstock/RSK | EVM sidechain with BTC peg/merge-mining. | EVM tooling; familiar dev stack. | Peg/trust assumptions; complex security. | If you need EVM reach, use as an external zone, not as NoM’s base. |
| Ark | Off-chain e-cash style protocol enabling non-custodial payments without channels. | Great UX for end users; privacy benefits. | Provider rotation and liquidity design are evolving. | Nice complement for retail UX atop NoM/Lightning stack. |
| BitVM / BitVM2 (optimistic-style on BTC) | Fraud-proof style verification using clever scripting & off-chain interaction. | Rollup-like guarantees without soft-forks; huge potential. | Complex; latency & UX overhead; still early R&D. | Strategic alignment. Track & prototype fraud-proof bridges to NoM. |
| Optimistic / ZK Rollups (BTC-anchored) | Post compressed data/proofs to Bitcoin; prove or challenge off-chain execution. | High throughput; re-use modern rollup patterns. | Without opcodes/soft-forks, engineering is hard; prover infra heavy. | Core vision match with NoM Phase-1/zk-anchoring narrative. Target Bitcoin DA + NoM execution. |
| Nomic / Merlin / other “BTC L2s” | Range from IBC/Zone bridges to EVM chains marketing as “L2”. | Faster time-to-market; app ecosystems. | Often marketing vs strict security; varied bridges/trust. | Case-by-case for liquidity access, not as NoM’s security core. |
What this means for Zenon (NoM) — pragmatic path
North Star: a Bitcoin-native rollup platform anchored to BTC for data availability, with merge-mining, TSS custody options, and Plasma-style scalability (this maps to your Phase-1 vision). That keeps Bitcoin as the settlement/DA root while NoM handles programmable execution and UX.
Recommended stack (layered)
-
Payments edge
-
Integrate Lightning and optionally Taproot Assets for spend/use.
-
Explore Ark for smooth, non-channel UX where it helps retail.
-
-
Assets & apps
-
For BTC-anchored assets where privacy/scale matter, pilot RGB for client-side validation.
-
For culture/awareness, use Ordinals/Runes tactically (NFT drops, community campaigns), but keep tokenomics off BRC-20.
-
-
Security & settlement
-
Pursue a BTC-anchored rollup design (validity where feasible, with a BitVM-style fraud-proof path in parallel).
-
Keep federations/sidechains (Liquid/RSK) as peripheral liquidity routes, not as NoM’s root of trust.
-
Trade-offs you should embrace explicitly
-
Throughput vs. Purism: Pure L1 metas (Ordinals/Runes) are culturally powerful but don’t give you the scalable, composable state you need. Rollup architecture anchored to BTC does.
-
Time-to-market vs. Security: EVM sidechains get you apps fast but dilute the “Bitcoin-native” promise. Better: ship modules that bridge to them while you keep NoM’s core anchored to BTC.
-
UX vs. Complexity: RGB/BitVM paths are powerful but complex. Counter this with opinionated tooling, hosted indexers, and “one-click” developer kits.
Concrete next steps (actionable)
-
Prototype track A (security-first):
-
Minimal data-availability anchoring to Bitcoin (Taproot/OP_RETURN commitments), canonical DA indexer, and proof relay to NoM.
-
Spike a BitVM-style challenge game for a single contract type (e.g., token bridge) to measure interaction latency and costs.
-
-
Prototype track B (payments-first):
-
NoM wallet integration with Lightning send/receive.
-
Optional Taproot Assets receive for merchant demos.
-
-
Ecosystem ops:
-
Run community campaigns via Runes/Ordinals to grow awareness while keeping core funding/governance on NoM.
-
Publish a “What is a real Bitcoin L2?” explainer (security models, pegs, DA) to set the narrative and avoid sidechain mislabeling.
-
NoteGPT_Which Bitcoin L2s Will Survive_ Creator of Ordinals Weighs In.txt (80.3 KB)