STAS-01

STAS-01 is an open interoperability specification for representing Bitcoin Digital Objects 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. The core specification is protocol-independent: protocol-specific bindings are defined through profiles, and the initial binding profile uses the Taproot Assets protocol.

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 a protocol-specific profile connects the object's canonical representation and verification evidence to a Bitcoin-secured ownership mechanism. The initial binding profile uses the Taproot Assets protocol.

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 — Accepted in the STAS process — defines the 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 profiles — split states. The three layer profiles (representation, deterministic CBOR serialization, encoding) and the Type vocabulary (RFC-0017) are Accepted, backed by frozen test vectors — exact canonical bytes that two independent implementations reproduce. The composite profile, the Taproot binding, and the attestation extension remain In Review: implementable now, expected to reach Accepted as field evidence accumulates, 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