Decoder 1.0.0 / bitcoin mainnet rules
Read the frame.
Paste a scriptPubKey. The decoder lays out the bytes, works out which of the three protocols claims the payload, decodes the fields, and tells you why a reader would refuse it.
Everything happens in this page
The decoder is a static script in this repository. What you paste is never logged, stored or transmitted. There is no network request, no analytics and no third party code on this site.
Loading the decoder. If this message stays, the script did not run. See the test vectors instead.
What the decoder checks
In order, and stopping at the first protocol that claims the payload:
- Carrier. The script must start with
0x6a, or with0x00 0x6a, which only the OP Inscriptions scanner accepts. Pushes are decoded with the rules in R-CAR-3 and concatenated in order. - OP-20. The payload must start with a JSON object tagged
"p":"op-20". Field sets, duplicate keys, ticker normalisation and the amount forms are all checked as in R-20. - OP Names. Either a JSON object tagged
"p":"opns", or plain text with exactly one literal dot. Identity is normalised and validated as in R-NAME-4, including the Unicode dot lookalike rejections. - OP Inscriptions. A JSON tag of
op-inscriptions,op_inscriptionsorop-inscription, or the narrow historical envelope described in R-OPI-5. - Size and relay. Script bytes, payload bytes and push count, compared against the 83 byte default data carrier limit and the 4096 byte reader bound.
What it does not do
- It reads one output. Rules that depend on the whole transaction, such as "exactly one OP_RETURN output" or "exactly one OP-20 carrier", cannot be evaluated from a single script.
- It does not resolve state. It cannot tell you whether a name is already registered, whether a balance exists, or who owns a receipt outpoint.
- It does not check addresses against a network. An address that is well formed for testnet will be reported as written.
- It applies mainnet rules only.