STAS-01

STAS-01 (Shared Taproot Assets Standard) es una especificación abierta de interoperabilidad para representar Bitcoin Digital Objects usando el protocolo Taproot Assets sobre Bitcoin. Su propósito es que dos aplicaciones independientes, ante el mismo objeto y la misma evidencia, resuelvan el mismo BDO — el mismo identificador, los mismos bytes canónicos, los mismos resultados criptográficos de verificación — sin depender de ningún proveedor.

STAS-01 no define qué es un Bitcoin Digital Object. Esa definición pertenece a la categoría BDO, mantenida de forma independiente. STAS-01 es la primera especificación desarrollada para la categoría; la categoría permanece abierta a otras especificaciones y otros soportes.

La arquitectura por capas, en lenguaje llano

STAS-01 separa las responsabilidades en capas, de modo que cada una pueda evolucionar sin romper las demás:

Modelo de objeto — todo objeto tiene seis componentes lógicos: Type (qué es), Identity (cuál es), Content (qué porta), Metadata (cómo se describe), Integrity (si está intacto) y Capabilities (qué puede hacer).
Representación — una estructura concreta para esos componentes: ranuras con campos definidos.
Serialización — la estructura se convierte en bytes mediante CBOR determinista (RFC 8949 §4.2): un objeto, exactamente una secuencia de bytes, reproducible por cualquier implementación. El determinismo es lo que permite que software independiente se ponga de acuerdo.
Binding — cómo esos bytes se anclan al protocolo Taproot Assets y, a través de él, a Bitcoin.

Identidad: el Taproot Asset ID

Un objeto STAS-01 usa el Taproot Asset ID — derivado por el protocolo Taproot Assets a partir de la información de génesis del asset — como su identificador persistente a nivel de protocolo. Se asigna en la emisión, es globalmente único y permanece estable a medida que el asset se transfiere. La identidad deriva del protocolo: ninguna plataforma la asigna y ninguna plataforma puede cambiarla.

Integridad: comprometida en la emisión

En el protocolo Taproot Assets, la información de génesis de un asset incluye un compromiso sobre su carga de metadata. El binding Taproot de STAS-01 coloca en esa carga los bytes canónicos del objeto — o su digest —, de modo que el contenido del objeto queda fijado en la emisión: un cambio posterior del documento no coincidiría con el compromiso que porta el asset y describiría, en la práctica, un asset distinto. Verificar la integridad es recomputar: calcular el hash de los bytes canónicos, compararlo con el valor comprometido y validar las pruebas del asset contra Bitcoin con herramientas estándar de Taproot Assets.

Autenticidad: atestaciones

Que un objeto esté intacto y quién lo firmó se mantienen separados. Una atestación es una firma de una clave identificada — el creador reivindicando la autoría, o una plataforma avalando su proceso — sobre el compromiso de integridad del objeto. Las atestaciones viajan con el objeto y se validan con criptografía estándar (Schnorr/BIP-340, BIP-322). Una atestación válida demuestra que una clave concreta firmó; conectar esa clave con una identidad del mundo real requiere una fuente de identidad externa al propio objeto. Un objeto sin atestación válida es una afirmación sin atribuir, y un verificador honesto lo presenta como tal.

El vocabulario de Types

El RFC-0017 — actualmente In Review en el proceso STAS, donde un RFC es una propuesta hasta su aceptación — define el vocabulario propuesto de Types de objeto: collectible, ticket, membership, redeemable y certificate, cada uno con semántica de consumo explícita (si presentar el objeto lo consume, como una entrada, o no lo consume nunca, como un certificado). Fija también la regla de seguridad para Types desconocidos — nunca consumir; solo mostrar o rechazar — y exige que los Types nuevos lleguen únicamente por el proceso RFC público.

Bitcoin, Taproot Assets y Lightning

Bitcoin es el sustrato de liquidación y anclaje para la evidencia de propiedad e integridad.
Taproot Assets es el protocolo de assets al que STAS-01 se ancla, usado exactamente como lo especifican sus mantenedores. STAS-01 ocupa solo el espacio que el protocolo deja definido por la aplicación; nunca modifica ni extiende las reglas del protocolo.
Lightning es un raíl de transferencia que el protocolo Taproot Assets soporta. El binding de STAS-01 es agnóstico al mecanismo de transferencia — el identificador deriva de la información de génesis del asset, no de ninguna ruta de transferencia —, así que los objetos movidos por Lightning siguen siendo los mismos objetos, verificables de la misma manera.

Estado, versiones y gobernanza

Los documentos STAS llevan estados de proceso explícitos, y esta página los refleja tal como son:

STAS-01 v1.0 — Released (publicado). La especificación núcleo (dieciséis RFCs y una spec compilada) está publicada.
La familia de profiles BDO — In Review (en revisión). Los profiles que concretan el pipeline (representación, serialización CBOR determinista, encoding, el binding Taproot y la extensión de atestación) están publicados y son lo bastante estables para implementar contra ellos, con vectores de prueba congelados — bytes canónicos exactos que cualquier implementación debe reproducir. In Review significa exactamente eso: implementables ya, con la expectativa de alcanzar Accepted a medida que las implementaciones de referencia los validen, y aún no parte del núcleo Released.
Gobernanza. El estándar evoluciona por un proceso RFC público (issue → discusión → RFC → revisión → aceptación → especificación), con reglas explícitas de versionado y compatibilidad. Cualquiera puede proponer un cambio.

Fuentes: Repositorio STAS-01 (GitHub) — especificación, profiles, RFCs y vectores de prueba · ¿Qué es un BDO? · Implementaciones