STAS-01

STAS-01 (Shared Taproot Assets Standard) is an open interoperability specification for representing Bitcoin Digital Objects using the Taproot Assets protocol on Bitcoin. Its purpose is that two independent applications, given the same object and the same evidence, resolve the same BDO — the same identifier, the same canonical bytes, the same cryptographic verification results — with no dependence on any vendor.

STAS-01 does not define what a Bitcoin Digital Object is. That definition belongs to the BDO category, maintained independently. STAS-01 is the first specification developed for the category; the category remains open to other specifications and carriers.

The layered architecture, in plain language

STAS-01 separates concerns into layers, so each can evolve without breaking the others:

  • Object model — every object has six logical components: Type (what it is), Identity (which one it is), Content (what it carries), Metadata (how it describes itself), Integrity (whether it is intact), and Capabilities (what it can do).
  • Representation — a concrete structure for those components: named slots with defined fields.
  • Serialization — the structure becomes bytes through deterministic CBOR (RFC 8949 §4.2): one object, exactly one byte sequence, reproducible by any implementation. Determinism is what lets independent software agree.
  • Binding — how those bytes anchor to the Taproot Assets protocol and, through it, to Bitcoin.

Identity: the Taproot Asset ID

A STAS-01 object uses the Taproot Asset ID — derived by the Taproot Assets protocol from the asset's genesis information — as its persistent, protocol-level identifier. It is assigned at issuance, is globally unique, and remains stable as the asset is transferred. Identity is protocol-derived: no platform assigns it, and no platform can change it.

Integrity: committed at issuance

In the Taproot Assets protocol, an asset's genesis information includes a commitment to its metadata payload. STAS-01's Taproot binding places the object's canonical bytes — or their digest — in that payload, so the object's content is fixed at issuance: a later change to the document would not match the commitment carried by the asset, and would in effect describe a different asset. Verification of integrity is recomputation: hash the canonical bytes, compare against the committed value, and validate the asset's proofs against Bitcoin with standard Taproot Assets tooling.

Authenticity: attestations

Whether an object is intact and who signed it are kept separate. An attestation is a signature by an identified key — the creator claiming authorship, or a platform vouching for its process — over the object's integrity commitment. Attestations travel with the object and are validated with standard cryptography (Schnorr/BIP-340, BIP-322). A valid attestation proves that a specific key signed; connecting that key to a real-world identity requires an identity source outside the object itself. An object without a valid attestation is an unattributed claim, and honest verifiers present it as such.

The Type vocabulary

RFC-0017 — currently In Review in the STAS process, where an RFC is a proposal until accepted — defines the proposed vocabulary of object Types: collectible, ticket, membership, redeemable, and certificate, each with explicit consumption semantics (whether presenting the object consumes it, as with a ticket, or never does, as with a certificate). It also fixes the safety rule for unknown Types — never consume; display-only or reject — and requires that new Types arrive only through the public RFC process.

Bitcoin, Taproot Assets, and Lightning

  • Bitcoin is the settlement and anchoring substrate for ownership and integrity evidence.
  • Taproot Assets is the asset protocol STAS-01 binds to, used exactly as specified by its maintainers. STAS-01 occupies only the space the protocol leaves application-defined; it never modifies or extends protocol rules.
  • Lightning is a transfer rail the Taproot Assets protocol supports. STAS-01's binding is transfer-mechanism agnostic — the identifier derives from the asset's genesis information, not from any transfer path — so objects moved over Lightning remain the same objects, verifiable the same way.

Status, versions, and governance

STAS documents carry explicit process states, and this page reports them as they are:

  • STAS-01 v1.0 — Released. The core specification (sixteen RFCs and a compiled spec) is published.
  • The BDO profile family — In Review. The profiles that make the pipeline concrete (representation, deterministic CBOR serialization, encoding, the Taproot binding, and the attestation extension) are published and stable enough to implement against, with frozen test vectors — exact canonical bytes any implementation must reproduce. In Review means exactly that: implementable now, expected to reach Accepted as reference implementations validate them, and not yet part of the Released core.
  • Governance. The standard evolves through a public RFC process (issue → discussion → RFC → review → acceptance → specification), with explicit versioning and compatibility rules. Anyone can propose a change.

Sources: STAS-01 repository (GitHub) — specification, profiles, RFCs, and test vectors · What is a BDO? · Implementations

What is a BDOPrinciplesFAQImplementations