Interactive, spec 1.0.0

Builder and decoder

Two tools against the same grammar. The decoder takes a leaf script hex and tells you what the payload is and exactly how the stack behaves. The builder takes a payload and emits the leaf script that carries it.

Everything runs in your browser. Nothing you paste or type leaves this page. There is no network request, no analytics, no storage of your input, and no server involved. The page works offline once loaded. Spec version 1.0.0; leaf bytes are identical on mainnet, testnet, signet, and regtest.

These tools need JavaScript. Everything else on this site works without it. The test vectors page contains the same worked examples with their expected results already computed, and the specification gives the grammar you can implement yourself.

Decoder

Leaf script hex (witness item 1 of an OP_DROP reveal input)

Paste a leaf script hex and select Decode.

Stack evolution

Builder

Operation

Ticker (exactly four characters)

Amount

x-only public key (64 hex characters)

Choose an operation and select Build.

Stack evolution

How to read the result

The stack view is the point of the whole protocol, so it is worth reading carefully.

What each row of the stack view means
Row	Meaning
Step 0	The witness has already placed the Schnorr signature on the stack before the leaf script starts running. Everything the leaf does happens on top of it.
A push row	One data element is added to the stack. The stack grows by exactly one item.
An `OP_DROP` row	The top item is removed. The stack returns to what it held before the push. This row is coloured differently because it is the mechanism the protocol is named after.
The `OP_CHECKSIG` row	The public key and the signature are both consumed and a single truth value is left. That value alone decides whether the spend is valid.

If the payload were meaningful to consensus, it would have to survive to the end. It does not. That is why an OP_DROP transaction is not more likely to be rejected by a node than any other Taproot script-path spend: at the point the node makes its decision, the payload is already gone.

What these tools do not check

The decoder validates the leaf script and the payload. Four things are outside its reach, and all four matter before you can call an event valid.

The Taproot commitment. A leaf counts only when a 33-byte control block proves the spent P2TR output committed to it (OD-5.1 to OD-5.4). That needs the control block and the previous output script, neither of which is in the leaf.
Ledger state. Whether a mint is within the remaining supply, whether a ticker is already deployed, whether a sender has the balance: all of that depends on the whole chain history, not on one script.
The anchor and settlement. Whether output 0 of the reveal yields an address, and where a transfer eventually settles, is transaction-level information.
The media attachment. If a leaf carries an appended drops-media image, the decoder reports its presence and decodes the token fields, but does not verify the image chunks, digest, or size.

For the full picture, read the specification and check your implementation against the test vectors.

Fee estimates

The fee table models the reveal transaction only: one Taproot script-path input, one Taproot output, one Schnorr signature, the leaf script, and a 33-byte control block. Weight is computed as base bytes × 4 + 2 + witness bytes, and virtual size is the weight rounded up to the next whole vbyte. A real order also pays for the commit transaction and for any extra outputs your wallet adds, so treat the number as a floor.