Bitcoin confirma propiedad y orden de los UTXO anchor, mientras historial, witness data y proofs del activo se envían fuera de la blockchain al receptor, que valida todo el linaje desde el genesis point.
Taproot Assets, anunciado originalmente como Taro, usa una salida Taproot como anchor Bitcoin para commitments de activos. Las reglas completas y witness data del activo no son estado global de Bitcoin; los participantes las conservan y validan. [1]
La emisión crea una minting transaction y el outpoint que consume se convierte en genesis point y parte de la identidad única del activo. En una transferencia, el witness anterior se vuelve a comprometer en una o más salidas Taproot y el proof necesario se entrega al receptor. [2]
Un Sparse Merkle Tree permite pruebas selectivas de ramas de activos en una salida y un Merkle-Sum Tree comprueba la conservación de cantidades. Un UTXO Bitcoin puede comprometer varios activos sin que un full node conozca nombres, saldos ni reglas de transferencia. [1]
El receptor valida el linaje desde la salida genesis frente a transacciones Bitcoin. Un Universe puede indexar y distribuir proofs y metadata, pero no convertir un activo inválido en válido; el cliente puede comparar sus datos con otro Universe o con su propio almacén. [1]
Una dirección Taproot Assets lleva asset ID o group key, cantidad, claves e información para entregar el proof. Un group key puede identificar un grupo al que el emisor añada emisiones posteriores, por lo que una oferta fija o ampliable debe evaluarse para cada activo. [3]
La implementación pública tapd admite mainnet y la actual serie v0.8.4, pero el repositorio todavía la califica como software alpha. Tener comandos o selector mainnet no garantiza copias completas, compatibilidad ni seguridad de producción. [5]
La recuperación exige más que un seed Bitcoin: tapd conserva un tweak y datos cliente necesarios para gastar con seguridad la salida anchor y demostrar el historial. Perder base de datos o proofs puede destruir acceso al activo y, en algunas configuraciones, poner en riesgo BTC en la misma salida. [2]
Nombre, ticker y metadata libre no prueban solvencia económica. Antes de aceptar, verifica asset ID o group key, genesis, proof completo, reglas de oferta, control del emisor, estado de transacciones anchor y versión exacta del cliente. [4]
Para obtener la imagen más completa, lee esta entrada junto con Taproot, Client-Side Validation, Lightning Network, UTXO, RGB Protocol, Hash. También enlazan con esta entrada Runes.
01¿Validan los full nodes Bitcoin los Taproot Assets?+
Validan la transacción Taproot y el gasto del UTXO anchor, no reglas, cantidad ni historial del activo. Eso lo valida el receptor con proofs en un cliente Taproot Assets.
02¿Basta un seed Bitcoin para recuperar Taproot Assets?+
No. La implementación oficial exige expresamente copia de datos tapd; el seed lnd por sí solo no contiene todos los tweaks, proofs y estado cliente necesarios para una recuperación segura.