BZA1 (BTX Artifacts standard)

BZA1 is a standard for issuing artifacts, on-chain collectible items, on the BTX blockchain. An artifact is created by an ordinary BTX transaction that carries a structured OP_RETURN payload, and ownership of the artifact follows the coin that carries it. Collections are recognized by indexers and a registry rather than by smart contracts. The specification is published at easybtx.com/relics.

#Consensus constraints

BTX applies a reduced-data consensus rule: an output's scriptPubKey may not exceed 34 bytes unless the output is an OP_RETURN carrying at most 83 bytes. The rule has been in force since the first block, and it rules out the approach taken by inscription schemes on other chains, which embed large files in witness data.

BZA1 is designed to fit inside that limit rather than around it. A payload is a single data push of at most 80 bytes in one OP_RETURN output, and the operations defined in v0 use 52 bytes or fewer. Full nodes validate such a transaction like any other and do not interpret the artifact semantics. That same narrow lane is the subject of a proposed consensus change described under Status and planned sunset.

#Payload format

Every payload opens with a 6-byte header, followed by an operation-specific body. All integers are big-endian.

A MINT body adds 46 bytes, for 52 bytes total:

A STATE body adds 45 bytes, for 51 bytes total. It repeats collection_id and item_id, replaces the flags byte with a one-byte issuer-defined state value, and carries a new meta_hash. It has no schema byte, because the schema is fixed at mint.

Decoding is strict: a payload with the wrong length for its operation, an unknown version, an unknown operation, or an unrecognized flag bit is not a BZA1 artifact, and the transaction is treated as an ordinary payment. Strictness is what makes independent indexers agree.

#Script encoding

The payload sits in a scriptPubKey consisting of OP_RETURN (0x6a) followed by exactly one data push. A payload of 75 bytes or fewer is pushed with a single length byte; a longer payload uses OP_PUSHDATA1 (0x4c) followed by a one-byte length. Version 0 recognizes only this exact shape, so a script with more than one push, or with trailing bytes after the push, does not carry an artifact even if well-formed payload bytes appear inside it.

#Operations

v0 defines three operations, of which two are implemented.

MINT (0x01) creates an item. The artifact attaches to the first output of the transaction that is not an OP_RETURN, and that coin becomes the item's location.

STATE (0x02) advances an existing item. It is valid only when the transaction spends the exact artifact its identifiers name, and it both updates the committed meta_hash and state byte and moves the item, as a transfer does. When the identifiers do not match the spent artifact, the payload is ignored and the transaction is read as a plain transfer.

BIND (0x03) is reserved for a later phase and is not implemented. Because decoding is strict, a payload carrying this operation is currently rejected outright rather than ignored.

#Metadata commitment and schemas

Under schema 0, meta_hash is the SHA-256 (SHA-2) digest of a canonical JSON serialization of the artifact's metadata: object keys sorted lexicographically at every depth, no insignificant whitespace, UTF-8 encoding, and integers only, since floating-point numbers do not round-trip identically across JSON implementations. Canonicalization is what allows any party to re-derive the committed hash from the served metadata and confirm it matches the chain. The commitment is recorded on chain; the metadata itself is not.

The same 32 bytes can serve more than one purpose. Stored as an IPFS block identifier, the digest that proves the metadata also locates it. Used as a seed for a deterministic renderer, it lets artwork be rebuilt from chain data alone, with nothing hosted.

Schema 1 (glyph) reinterprets the field entirely. The 32 bytes are not a hash but a 16 by 16 one-bit bitmap, which is exactly 256 pixels, read row-major and most-significant-bit first, so that the pixel at row r and column c sits at bit index r * 16 + c. A glyph artifact is fully on chain: nothing is hosted, hashed, or fetched, and the image reconstructs from the payload alone.

#Artifact types

The payload defines the container. An artifact type is a convention over how the 32-byte field, the schema byte, and the flags are used, and the standard describes five:

• Linked (schema 0): meta_hash is both the commitment to off-chain metadata and, read as an IPFS block identifier, its address.
• Generative (schema 0): the mint transaction hash seeds a deterministic renderer, so artwork rebuilds from chain data with nothing hosted.
• Glyph (schema 1): the 32 bytes are the image.
• Attestation (soulbound flag): a record that something occurred, such as attendance or a first mined block, with no artwork attached. The committed fact is the artifact.
• Dynamic (STATE operation): an item that advances through issuer-defined states, each change appended to its history.

The standard also describes a possible later route to a layer 2 for logic that layer one cannot express, naming the private EVX network, with BTX layer one remaining the source of truth. No such bridge is implemented.

#Ownership model

Each artifact is attached to a specific coin, a UTXO. Whoever can spend the coin owns the artifact, and transferring the artifact means spending the coin to the new owner, protected by the same post-quantum signatures (ML-DSA, SLH-DSA) as any BTX payment. Because the OP_RETURN output is itself unspendable, the artifact rides a separate output of the same transaction.

A soulbound artifact is one intended to remain with its original recipient. Indexers that follow the standard permit issuer state updates on such an item but treat any other spend as destroying it.

#Indexer rules

BTX has no smart contract layer, so BZA1 places collection logic off chain. Indexers scan the chain for well-formed payloads and reconstruct artifact histories from transaction data, and a registry records recognized collections. A collection launches when the registry and indexers recognize its issuances, not when any code is deployed. The v0 rules are deterministic by construction:

• A transaction carries at most one artifact payload, the first valid single-push OP_RETURN it contains.
• For MINT, the first-seen (collection_id, item_id) pair wins permanently, including after the item is destroyed, so a burned item cannot be re-minted.
• When a transaction spends artifact-bearing coins, those artifacts map in input order onto the non-OP_RETURN outputs in output order, one each. An artifact with no output left to receive it is burned.
• A transaction that spends an existing artifact cannot also mint a new one; its MINT payload is ignored.
• Reconstructed history is a sequence of MINT, XFER, STATE, and BURN events per item.
• Events are ordered by confirmed chain position only, never by mempool arrival, wall-clock timestamps, or a first-seen rule. An indexer that ranks competing updates any other way can reach a different history than its peers from the same chain.

Ordering ambiguity for the mutable operation resolves at the consensus layer rather than by convention. A STATE update must spend the artifact's own coin, so two competing updates to one item are, by construction, double spends of that coin: at most one can ever confirm. Conflicting state therefore cannot coexist on a settled chain, and an indexer that reads only confirmed blocks in height order inherits that guarantee without needing a tie-break rule of its own.

Parsers face untrusted input, since any transaction may carry any bytes in an OP_RETURN. Implementations that follow the standard enforce the exact maximum payload size, validate the version and operation bytes, keep every integer field inside its declared width, allocate nothing on the basis of an untrusted value, and reject duplicate or conflicting records. A malformed payload is ignored, leaving a plain transaction; it never aborts a scan or halts synchronization. The fixed 52-byte MINT layout, with no variable-length fields and no recursion, is what makes that bound checkable rather than aspirational.

Reorganizations are handled by the indexer rather than the format. The reference implementation is forward-only; a production indexer re-buffers recent blocks or rebuilds from a checkpoint below the fork point.

This division has direct consequences. On chain, an artifact inherits the guarantees of BTX itself: its content commitment and its ownership history are as durable as the chain. Off chain, the interpretation of artifacts, such as which issuances belong to which collection and which are canonical, depends on indexer rules and registry conventions rather than on consensus. Different indexers applying different rules could, in principle, disagree.

#Limitations

Because an artifact is an ordinary coin, a wallet that does not recognize BZA1 can spend it as an ordinary input, including as a fee, which destroys the artifact. Keeping artifacts in wallets or addresses that understand the standard is a practical requirement rather than a convenience.

Wallets that follow the standard therefore identify carrier outputs from the transactions that created them and withhold those coins from ordinary coin selection by default, rather than leaving the distinction to the holder. Because the loss is irreversible and silent, such implementations fail closed: a coin whose origin transaction cannot be retrieved or fully read is set aside for that attempt instead of being treated as ordinary funds. The requirement does not expire with issuance. From the v0.33.2 activation at block 185,000, artifacts can no longer move, but their carrier coins remain spendable inputs and so remain destructible by an unaware wallet.

Confirmation depth is a second caution. A chain reorganization rewrites the transactions that carry mints and transfers, and a smaller chain is easier to reorganize deeply than a larger one, so implementations treat a recent artifact as pending until roughly ten blocks have confirmed on top of it. BTX targets a 90-second block time.

#Comparison with contract-based standards

Contract-based collectible standards on EVM chains implement ownership as mutable contract state. BZA1 instead reuses the transaction graph itself as the ownership record, similar in spirit to other UTXO-carried asset schemes. The trade is programmability for simplicity: BZA1 artifacts cannot execute logic, but there is also no contract to exploit, upgrade, or abandon. The STATE operation provides the one mutable element, and it changes a committed hash and a state byte rather than running code.

#Status and planned sunset

BZA1 is a community standard from the team behind PQ Wallet, qID and BTXScan. It is not an official BTX feature, and it requires no fork or consensus change. The v0 byte layout is provisional, and the BIND operation is reserved and unimplemented.

A consensus change ends BZA1 issuance. The work opened in July 2026 as BTX pull request 88 shipped in BTX Core v0.33.2, which makes BTX a financial-only base layer by forbidding OP_RETURN outputs in every non-coinbase transaction, leaving only the mandatory coinbase witness commitment exempt. The activation height is 185,000, not the 165,000 the original proposal listed as provisional. It activates together with MatMul v4.7 Epoch A and BMX4C bonded offers, under the name Resident Curriculum.

Its effect on BZA1 is specific rather than total. MINT and STATE both require an OP_RETURN output, so after the activation height no new artifact could be issued and no committed state could be updated. Transfers do not use an OP_RETURN, since an artifact moves by spending the coin that carries it, which is an ordinary payment. Data already written to the chain is permanent. Artifacts minted before the height would therefore persist, remain verifiable, and continue to change hands, while the standard would accept no new entries.

Pull request 88 is consequently the record of both ends of the standard: it documents the 83-byte reduced-data rule that BZA1 was designed to fit inside, and the change that would close that lane. Public collectible releases that use BZA1 are indexed at BTX drops, and issuance transactions can be inspected in BTXScan like any other BTX transaction.