CRC-20: the last meta on Bitcoin
hi, i'm tap3leaf. i build $leaf.
i'll try to keep this simple. u will still have to link the dots tho.
straight to it: $ordi. brc-20. what is it, really? a nft with a json shape. it did exactly what it had to do at the moment it had to do it, and we won't rewrite history. it's the reason half of us are here. i'm bullish.
BUT
it's almost 2027. AI everywhere. robots. ten years of bitcoin research behind us. ATH above $100k. Liquid (Adam Back) got hacked for 4 000 btc. op_return is a communication channel. the last meta on Bitcoin launched and somehow.. this is where we are.
straight to it: $leaf. crc-20. i'm (very) bullish.
Seeds become trees.
2012. p2sh. bip 16. stop putting the script in the output. u put its hash. the script only shows up when u spend it. read it again: one hash, a whole program behind it, nobody sees it until it moves. 2012. that's fourteen years ago.
2015. timelocks. bip 65, bip 112. cltv, csv. time becomes a spending condition. when i say ur $leaf is locked at the bitcoin level, i mean bip 112. i mean timechain. i don't mean my indexer.
2016. mast. bip 114. a program becomes a tree. u reveal only the branch u use. never activated. the idea didn't die tho, it walked straight into taproot.
all the rest never landed. apo. op_ctv. txhash. op_cat. op_csfs. eight years of covenant proposals, zero activations(!!!). i'm not waiting for a ninth year. the question they all ask is the right one: not who can sign, but where is this coin allowed to go. u can answer that today, without an opcode.
2017 → 2021. segwit, then taproot. bip 141, 340, 341, 342. schnorr, a hidden script tree, tapscript. and one number that changes everything. (32) one x-only key, or a commitment to a tree of programs. same 32 bytes either way.
2017 → 2025. simplicity + cmr. a real language, semantics, and a merkle root for every program: the cmr. 32 bytes. and i just told u what fits in 32 bytes. commit the program, carry it in the address, reveal it when u spend.
2019. utreexo + floresta. prove a coin exists without carrying the whole set. that's the shape of a crc-20 node. light (af). replayable from genesis.
2023. ordinals + brc-20. atom32 (atomicals). ordinals made the envelope. witness data, images, content on L1. (smooth). brc-20 made the syntax. a token standard that spread over the world. (genius). atom32 introduces a standardized address format based on bech32 encoding to resolve asset identification challenges within the Bitcoin system.
2019 → 2025. sovereign rollups. lazyledger, celestia, validity rollups. the base layer orders and publishes. the client executes. which is why i keep saying: we run a radar. an indexer decides. a radar reads.
2026. CRC-20...
how to activate covenants: $LEAF.
+bitcoin enforces the lock, the key and the commitment. today.
+the client validates the program behind that commitment. today.
+(🌱)
i'm going to repeat myself now. on purpose. this is the part people skip and then ask me "[whatever i already answered]".
the address is the state. the lock is enforced at the bitcoin level.
everyone is waiting for an opcode. every single one of them needs bitcoin to change. a soft fork. years of review, politics, activation clients, bitcoin wars. i'm not against it. i'm saying u don't need it to start. because u can already constrain an output today.
here's the trick: an address is 32 bytes. u can tweak those 32 bytes.
@laz1m0v showed me the equation. once u see it u can't unsee it.
u can make the tweak a function of the transaction itself. so the resulting address only exists if the transaction that creates it follows one exact shape.
wrong inputs, wrong outputs, wrong order, wrong amount → different 32 bytes → the address u were aiming at simply doesn't exist.
one shape. (one template). we call it TUSM.
now put the pieces together, slowly.
+the covenant output is p2tr. 32 bytes.
+the internal key is NUMS. no key path.
+the only way out is one tapleaf.
+the spend has to rebuild, byte for byte, the template that made that address possible in the first place.
so what does a user actually do on CRC-20? they craft exactly the transaction the protocol expects. not a transaction. the transaction. and that exact transaction is the protocol operation.
again. (again). again:
+the only possible output is determined by the transaction and by bitcoin.
+no third party in the spend path.
+no committee.
if the shape of the next transaction is known in advance, then u can prepare circuits. u chain templates. state → template → address → state → template → address. every hop is a 32-byte commitment. the program runs client side. the outcome is governed by bitcoin. and every step is auditable by anyone with a node and the rules, from block 0.
a virtual layer on top of L1 that doesn't ask L1 for anything new. call it L1+.
today the client checks the program before it spends. tomorrow a miner can do the introspection themselves. same rules, same templates, no consensus change needed. running the more complex scripts natively, and earning from the yield the virtual layer generates. that's the direction. miners already sell blockspace. next they sell execution.
last part:
one leaf is nothing. but a branch, a tree, a forest, ...u look up and there's a whole new world. and everything can be built there. that's how this works.
because here's the thing people forget: cryptography alone is just math. beautiful, useless math. a signature is worth nothing until a bunch of strangers decide it is. agreement is what turns cryptography into value.
so yes, i believe. we can activate covenants. and i need u to believe it with me because that's literally the mechanism. you are the consensus.
activate covenants on L1. NOW.
🌱 crc.garden
---
every dot, link them.
p2sh (2012) — BIP 16
Gavin Andresen · @gavinandresen · https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki
timelocks (2015–16) — BIP 65 · CLTV
Peter Todd · @peterktodd · https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki
— BIP 112 · CSV
BtcDrak · Mark Friedenbach · Eric Lombrozo · @btcdrak · @MarkFriedenbach · @eric_lombrozo · https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki
mast (2016, never activated) — BIP 114
Johnson Lau · https://github.com/bitcoin/bips/blob/master/bip-0114.mediawiki
the covenant proposals that never landed — covenants paper
Malte Möser · Ittay Eyal · Emin Gün Sirer · @maltemoeser · @ittayeyal · @el33th4xor · https://maltemoeser.de/paper/covenants.pdf
— APO · BIP 118
Christian Decker · Anthony Towns · @Snyke · @ajtowns · https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki
— CTV · BIP 119
Jeremy Rubin · @JeremyRubin · https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki
— TXHASH · BIP 346
Steven Roose · Brandon Black · @stevenroose3 · @reardencode · https://github.com/bitcoin/bips/blob/master/bip-0346.md
— CAT · BIP 347
Ethan Heilman · Armin Sabouri · @Ethan_Heilman · https://github.com/bitcoin/bips/blob/master/bip-0347.mediawiki
— CSFS · BIP 348
Brandon Black · Jeremy Rubin · @reardencode · @JeremyRubin · https://github.com/bitcoin/bips/blob/master/bip-0348.md
segwit → taproot (2017–21) — BIP 141 · SegWit
Eric Lombrozo · Johnson Lau · Pieter Wuille · @eric_lombrozo · @pwuille · https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki
— BIP 340 · Schnorr
Pieter Wuille · Jonas Nick · Tim Ruffing · @pwuille · @n1ckler · @real_or_random · https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki
— BIP 341 · Taproot
Pieter Wuille · Jonas Nick · Anthony Towns · @pwuille · @n1ckler · @ajtowns · https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki
— BIP 342 · Tapscript
Pieter Wuille · Jonas Nick · Anthony Towns · @pwuille · @n1ckler · @ajtowns · https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki
hd wallets — BIP 32
Pieter Wuille · @pwuille · https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki
atom32 — AIP-2
wizz-wallet-dev · AstroxNetwork contributors · https://github.com/atomicals-community/AIPs/pull/2
simplicity + cmr (2017–25)
Russell O’Connor · https://arxiv.org/abs/1711.03028 · https://github.com/BlockstreamResearch/simplicity · https://blog.blockstream.com/simplicity-launches-on-liquid-mainnet/
utreexo + floresta (2019–)
Tadge Dryja · @tdryja · https://eprint.iacr.org/2019/611
— Floresta
Davidson Souza + contributors · https://github.com/getfloresta/Floresta
dlc + adaptor signatures (the next door)
Tadge Dryja · @tdryja · https://adiabat.github.io/dlc.pdf · https://github.com/discreetlogcontracts/dlcspecs
— adaptor signatures
https://eprint.iacr.org/2020/476
ordinals + brc-20 (2023) — inscriptions
Casey Rodarmor · @rodarmor · https://docs.ordinals.com/inscriptions.html
— BRC-20
Domo · @domodata · https://domo-2.gitbook.io/brc-20-experiment
— OPI indexer
Best in Slot contributors · https://github.com/bestinslot-xyz/OPI
sovereign rollups (2019–25) — LazyLedger
Mustafa Al-Bassam · Alberto Sonnino · Vitalik Buterin · @musalbas · @alberto_sonnino · https://arxiv.org/abs/1905.09274
— Celestia / sovereign rollups
https://blog.celestia.org/sovereign-rollup-chains/
— validity rollups on Bitcoin
John Light · @lightcoin · https://github.com/john-light/validity-rollups/blob/main/validity_rollups_on_bitcoin.md
— R&D (Precop)
The Precop · @laz1m0v
https://delvingbitcoin.org/t/tee-hardened-autonomous-agent-wallet-with-simplicity-pre-execution/2377
— $LEAF
https://crc.garden https://mempool.space/tx/c19ca4e4ce09a2ff07fc8990c502c9d7e2a013e0da22753e4a00454bc9bb04b7
— inspiration / prior work @gavinandresen · @peterktodd · @pwuille · @n1ckler · @real_or_random · @ajtowns · @Snyke · @JeremyRubin · @reardencode · @stevenroose3 · @Ethan_Heilman · @maltemoeser · @ittayeyal · @el33th4xor · @tdryja · @rodarmor · @domodata · @musalbas · @eric_lombrozo · @MarkFriedenbach · @btcdrak · @alberto_sonnino · @lightcoin