Component

Opcode tiers

None of LayerTree runs on Bitcoin today: the covenant needs opcodes that have been proposed but not activated, and LayerTree proposes none of its own. To measure how much of the proposed menu it needs, the same transitions are built four times, against four sets of opcodes, on one tree format.

The four tiers

The tree format is the same in every tier, so proofs, roots and off-chain data are interchangeable; a tree is created for one tier, and its scripts follow from that choice. The repository's tests fail if a script uses any opcode outside its tier's set.

FULL

FULL is what the Great Script Restoration proposal makes possible together with the introspection, signature-over-data and elliptic-curve proposals. Arbitrary length arithmetic lets a 116-byte leaf sit on the stack as one element whose fields are cut out as needed, and the elliptic-curve opcodes compute the output key from the root directly. It is the recommended target.

MID

MID keeps today's tapscript numbers, which are at most four bytes. A leaf therefore arrives as seven field elements that the script joins with OP_CAT after checking their sizes, and every 8-byte sum carries a padding element so that it can be both added and hashed. The padding and the size checks are most of MID's extra 33% per exit. Sums must stay under 2³¹ satoshis per tree, and the scripts enforce it: every number the witness feeds into a sum is checked to be non-negative. The Liquid sidechain already has most of these opcodes.

MIN

MIN asks how little the covenant itself needs: OP_CAT and one key-tweaking opcode, with no way to read the transaction. Its way out is that OP_CHECKSIG does read the transaction. The script assembles the signature message from the values it wants to constrain, including the new tree output, and checks a signature over it under the generator point as the key with the generator as the nonce. For that key and nonce the signature is a value the script can compute itself, so it authorises nothing, but it binds: the check passes only if the message the script built equals the real transaction's. The spender varies a free field of the transaction until the computed signature has the right form, about 256 tries. MIN as built has only the exit and SPLIT, so a MIN tree is created with its whole membership and only shrinks. It is an existence proof, not a recommendation: the covenant needs only OP_CAT and one tweak opcode.

CCV

CCV replaces the key arithmetic with OP_CHECKCONTRACTVERIFY, which checks that an input or output key commits to a piece of data, here the root, under a given script set. The root and the script set leave the witness, and the script needs no elliptic-curve opcodes. It works with either FULL's numbers or MID's, and its exit is the smallest of the four. Its vouchers bind a per-tree identifier instead of the script-set root.

CCV plus a Merkle-sum opcode

One opcode built for Merkle-sum trees, verifying a path and returning the root with one leaf replaced, would remove the unrolled fold that is most of every script above: the exit becomes 252 bytes of script at any depth, and the witness carries one 40-byte sibling per occupied level and nothing per empty one, so the sparse profile stops costing more than the dense one. The simulator measures 388 vB on its six-leaf tree. With 65,536 members a path has about sixteen occupied levels, 10 vB each, so the exit is about 540 vB, against 1,020 in FULL, and each doubling of the membership adds only 10 vB more. That is what lets one tree grow to millions of members; the scaling page compares it with transaction trees and Lightning at sizes up to 2³². The opcode is specified and measured in the repository's simulator (133 checks) but nobody has proposed it for Bitcoin yet, so it is kept apart from the four tiers and their golden vectors, which use only proposals that exist.