SRC-101

Interactive tool · Bitcoin mainnet · Rules as of indexer 1.9.3

SRC-101 payload validator

Paste an SRC-101 JSON operation and choose a block height. The tool works out which operation it is, applies the exact key set for that operation at that height, checks every field rule, and explains each result. It distinguishes a payload that is excluded, leaving no trace at all, from one that is recorded as invalid with a status code.

Nothing leaves your browser

This tool is a single static JavaScript file with no dependencies. There is no request, no logging, no storage and no analytics of any kind. You can read assets/validator.js and confirm it. The Base58Check and Bech32 checks, including a SHA-256 implementation, run locally.

JavaScript required for this tool only

The validator needs JavaScript. Every other page on this site works without it.

Reading the verdict

Well formed
Every check that can be made from the payload alone passes. The operation still depends on chain state: the namespace, the price, the payment, the ownership and the expiry.
Recorded as invalid
The payload reaches its handler and a handler check fails on the payload alone. A row is written with a status code, and the register does not change.
Excluded
The payload never became an SRC-101 operation. No row, no status code, nothing to look up. In SRC-101 this covers key-set failures and every field-level failure, which is more than most people expect.

Why the block height matters

Three heights change what this tool does. Move the height field and watch the same payload change verdict.

What each height changes
HeightEffect on validation
Below 870652Nothing is an SRC-101 operation. Every payload is excluded
870652 to 872199mint requires img, and mint matching is exact. An img entry must equal the derived URL
872200 and abovemint drops img from the required set and switches to containment matching. Extra keys are allowed on mint alone
Below 940000A P2WSH-carried mint or renew is seen as paying zero and fails with IRV. Bare multisig is the only viable carrier for a paid operation
No upper boundSRC-101 has no end block. The Counterparty-carried branch never closes

If you are coming from SRC-20

The field names are different and so is the temperament. The differences that cost people the most:

SRC-20 habits that break on SRC-101
Habit from SRC-20What SRC-101 does
Add an extra field and expect it to be ignoredDiscards the payload entirely for four of the five operations
Expect a bad field to produce an invalid record you can look upAbandons the operation with no usable record at all
Write a boolean as a JSON booleanRejects it. prim must be the string "true" or "false"
Expect an over-large amount to be clamped and still succeedHas no clamping. An underpayment simply fails with IRV
Expect operations to be free of protocol feesRequires a payment at output 0 for mint and renew
Rely on the ledger hash catching a divergenceContributes nothing to it. There is no cross-check
Assume Counterparty carriage stopped at 796000Never stops for SRC-101

The two protocols do share the whole carrier layer. The SRC-20 documentation is the sibling of this site.

What this tool does not do

  • It does not decode a transaction. Paste the JSON payload, not the raw hex.
  • It does not check the carrier: keyburn, framing, output geometry and the ARC4 or P2WSH decoding are all outside its scope.
  • It does not resolve a namespace, so it cannot know the price list, the recipient set, the whitelist key, the mint window or the term granularity.
  • It does not verify a discount signature or an Ethereum record signature. Both need data the payload does not carry.
  • It does not verify that a wla public key is a valid point on secp256k1, only that it is well formed.
  • It does not know who owns a name or when a term ends.