Test vectors 1.0.0 / bitcoin mainnet
Real scripts, recorded outcomes.
Every vector below was produced by feeding the script into the organisation's own parser and recording exactly what came back. Nothing here is a guess about intended behaviour.
How these were produced
Each vector is a synthetic transaction whose outputs were passed to the live OP-20 payload reader, the live OP Names transaction parser, or the live OP Inscriptions record decoder. The three columns record the outcome verbatim: an accepted result, a thrown rejection with its reason code, or null, which means the reader does not claim the payload at all.
Addresses use the well known witness v0 example address bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4. Paste any script into the decoder to reproduce the classification in your own browser.
OP-20, accepted
| Id | scriptPubKey hex | Result |
|---|---|---|
| V-20-01 deploy |
6a477b2270223a226f702d3230222c226f70223a226465706c6f79222c227469636b223a2250495045222c226d6178223a223231303030303030222c226c696d223a2231303030227d |
operation deploy, reference pipe, ticker as written PIPE, maximum 21000000, limit 1000, no coercion |
| V-20-02 mint |
6a347b2270223a226f702d3230222c226f70223a226d696e74222c227469636b223a2250495045222c22616d74223a2231303030227d |
operation mint, reference pipe, amount 1000, recipient null |
| V-20-03 transfer with add |
6a4c6a7b2270223a226f702d3230222c226f70223a227472616e73666572222c227469636b223a2250495045222c22616d74223a22323530222c22616464223a226263317177353038643671656a7874646734793572337a6172766172793063357877376b763866337434227d |
operation transfer, amount 250, recipient bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4. One stage, the balance moves immediately |
| V-20-04 transfer without add |
6a377b2270223a226f702d3230222c226f70223a227472616e73666572222c227469636b223a2250495045222c22616d74223a22323530227d |
operation transfer, amount 250, recipient null. Legacy two stage shape, see R-20-12 |
| V-20-05 mixed case ticker |
6a317b2270223a226f702d3230222c226f70223a226d696e74222c227469636b223a2250695065222c22616d74223a2231227d |
ticker as written PiPe, reference pipe. Identity is the reference, so this is the same asset as V-20-02 |
| V-20-06 trailing bytes |
6a367b2270223a226f702d3230222c226f70223a226d696e74222c227469636b223a2270697065222c22616d74223a2231227d206e6f7465 |
accepted, with suffixBytes 4 and suffix text note. The bytes after the JSON object are recorded and not interpreted |
| V-20-07 zero fraction amount |
6a377b2270223a226f702d3230222c226f70223a226d696e74222c227469636b223a2250495045222c22616d74223a22313030302e3030227d |
amount 1000 from the written value 1000.00, coercion legacy-zero-fraction-truncated-by-mysql-bigint recorded |
OP-20, rejected
These payloads are recognisably OP-20 and are refused with a reason. The Bitcoin transaction is still valid and the fee is still spent.
| Id | scriptPubKey hex | Rejection |
|---|---|---|
| V-20-08 two OP-20 carriers |
6a317b2270223a226f702d3230222c226f70223a226d696e74222c227469636b223a2250495045222c22616d74223a2231227dplus 6a317b2270223a226f702d3230222c226f70223a226d696e74222c227469636b223a2250495045222c22616d74223a2232227d |
protocol_mismatch: the transaction must contain exactly one OP-20 OP_RETURN output. Neither mint applies |
| V-20-09 unknown field |
6a3c7b2270223a226f702d3230222c226f70223a226d696e74222c227469636b223a2250495045222c22616d74223a2231222c226d656d6f223a2278227d |
upstream_schema: OP-20 payload contains unknown field memo |
| V-20-10 unsupported operation |
6a317b2270223a226f702d3230222c226f70223a226275726e222c227469636b223a2250495045222c22616d74223a2231227d |
protocol_mismatch: the OP-20 operation is unsupported. There is no burn operation |
| V-20-11 zero amount |
6a317b2270223a226f702d3230222c226f70223a226d696e74222c227469636b223a2250495045222c22616d74223a2230227d |
upstream_schema: the mint amount must be a positive atomic amount |
| V-20-12 non zero fraction |
6a347b2270223a226f702d3230222c226f70223a226d696e74222c227469636b223a2250495045222c22616d74223a2231302e35227d |
upstream_schema: 10.5 is refused. Only an all zero fraction is tolerated, and only by truncation |
| V-20-13 duplicate key |
6a3b7b2270223a226f702d3230222c226f70223a226d696e74222c227469636b223a2270697065222c22616d74223a2231222c22616d74223a2232227d |
protocol_mismatch: the payload repeats field amt. Checked textually, before parsing |
OP-20, not claimed
These produce null. The reader does not consider them OP-20 at all, which is different from rejecting them.
| Id | scriptPubKey hex | Why |
|---|---|---|
| V-20-14 | 6a327b2270223a226272632d3230222c226f70223a226d696e74222c227469636b223a2250495045222c22616d74223a2231227d | the tag is brc-20, not op-20 |
| V-20-15 | 6a3768656c6c6f207b2270223a226f702d3230222c226f70223a226d696e74222c227469636b223a2270697065222c22616d74223a2231227d | text precedes the opening brace, so the payload does not begin with a JSON object |
| V-20-16 | 6a51 | 0x51 is OP_1, not a data push. The carrier is unreadable |
| V-20-17 | 6a4c05aabb | a PUSHDATA1 declaring 5 bytes with only 2 present |
| V-20-18 | 00141111111111111111111111111111111111111111 | an ordinary witness v0 output, no carrier at all |
OP Names, accepted
| Id | scriptPubKey hex | Result |
|---|---|---|
| V-NM-01 JSON reg with add |
6a4c5f7b2270223a226f706e73222c226f70223a22726567222c226e616d65223a227361746f7368692e627463222c22616464223a226263317177353038643671656a7874646734793572337a6172766172793063357877376b763866337434227d |
valid, operation reg, name satoshi.btc, label satoshi, namespace btc, asset id op_names:name:b64.c2F0b3NoaS5idGM, explicit address present, encoding json |
| V-NM-02 JSON reg, no add |
6a2c7b2270223a226f706e73222c226f70223a22726567222c226e616d65223a227361746f7368692e627463227d |
valid, operation reg, explicit address null. The owner comes from the receipt output |
| V-NM-03 JSON transfer |
6a317b2270223a226f706e73222c226f70223a227472616e73666572222c226e616d65223a227361746f7368692e627463227d |
valid, operation transfer. Authorisation still depends on input 0 spending an output of the exact current owner |
| V-NM-04 legacy plain text |
6a0b7361746f7368692e627463 |
valid, operation reg, encoding text. No protocol tag needed, because the text has exactly one literal dot |
| V-NM-05 case normalisation |
6a0b5361746f7368692e425443 |
valid. Written Satoshi.BTC, normalised to satoshi.btc, same asset id as V-NM-04 |
OP Names, recorded as evidence
These are recognisably OP Names attempts. They are stored with a reason and never become assets.
| Id | scriptPubKey hex | Reason |
|---|---|---|
| V-NM-06 | 6a0c7361746f7368692e622d7463 | invalid_op_name: the namespace b-tc is not lowercase ASCII alphanumeric |
| V-NM-07 | 6a042e627463 | invalid_op_name: .btc has an empty label |
| V-NM-08 | 6a377b2270223a226f706e73222c226f70223a22726567222c226e616d65223a227361746f7368692e627463222c226d656d6f223a2278227d | unknown_field: memo is not allowed on a reg |
| V-NM-09 | 6a2d7b2270223a226f706e73222c226f70223a226275726e222c226e616d65223a227361746f7368692e627463227d | unsupported_operation: only reg and transfer exist |
| V-NM-10 | 6a04612eff62 | invalid_utf8: the bytes contain 0x2e so the attempt is recorded, but they are not valid UTF-8 |
| V-NM-11 two carriers | 6a0b7361746f7368692e627463plus 6a0c6e616b616d6f746f2e627463 | ambiguous_op_return: two OP_RETURN outputs in one transaction. Neither name is applied, even though both are individually valid |
OP Names, not claimed
| Id | scriptPubKey hex | Why |
|---|---|---|
| V-NM-12 | 6a05612e622e63 | a.b.c has two literal dots, so the text shape does not match. Not evidence, not an asset |
| V-NM-13 | 6a0d7361746f736869e38082627463 | satoshi then U+3002 then btc. The ideographic full stop is not a literal dot, so the text has zero dots and is not claimed. This is the homograph defence working |
| V-NM-14 | 6a077361746f736869 | no dot at all |
Receipt selection
Verified directly against the receipt selector for a registration with no add field.
| Carrier index | Chosen receipt index | Outcome |
|---|---|---|
| 0 | 1 | owner taken from output 1, burned: false |
| 1 | 0 | owner taken from output 0, burned: false |
OP Inscriptions classification
Produced by the OP Inscriptions record decoder. Remember R-OPI-6: the labels this decoder assigns to foreign payloads are catalogue metadata, not an authority decision by the owning protocol.
| Id | scriptPubKey hex | Recorded classification |
|---|---|---|
| V-OPI-01 explicit tag |
6a4c5a7b2270223a226f702d696e736372697074696f6e73222c226f70223a22696e736372696265222c22616464223a226263317177353038643671656a7874646734793572337a6172766172793063357877376b763866337434227d |
protocol OP_INSCRIPTIONS, operation inscribe, address recovered, content type json, media type application/json, renderable, 90 payload bytes, id <txid>:0 |
| V-OPI-02 historical envelope |
6a4c4c7b22616464223a226263317177353038643671656a7874646734793572337a6172766172793063357877376b763866337434222c22636f6c6c656374696f6e223a2270696f6e65657273227d |
protocol OP_INSCRIPTIONS, operation inscribe. Accepted only because every key is in the narrow historical set and an address is present |
| V-OPI-03 foreign, OP-20 |
6a347b2270223a226f702d3230222c226f70223a226d696e74222c227469636b223a2250495045222c22616d74223a2231303030227d |
labelled protocol OP-20, operation mint, ticker PIPE. Catalogue label only |
| V-OPI-04 foreign, bare name |
6a0b7361746f7368692e627463 |
labelled protocol OP_NAMES, operation inscribe, ticker BTC, content type text. The label rule here is looser than R-NAME-4 |
| V-OPI-05 plain text |
6a0b68656c6c6f20776f726c64 |
protocol TEXT, no operation, content type text, media type text/plain |
| V-OPI-06 arbitrary JSON |
6a0d7b22666f6f223a22626172227d |
protocol JSON. Not an OP inscription: it has no protocol tag and its keys are outside the historical envelope set |