Advanced and Complex Features

2.1. RAW PROOF DATA & EXPORT .PROOF

2.1.1. RAW PROOF DATA

It is well known that in the BTC blockchain, the ledger records the movement of every BTC. However, under the Taproot Assets protocol, the Bitcoin mainnet acts merely as a “notary”: it is only responsible for locking a Taproot output, while the specific asset type, balance, and ownership changes are stored off-chain in a proof file. Specifically, when an asset is minted or transferred, the system generates a segment of binary data that begins with the marker `TAPP` (serialized as `54415050` in hexadecimal). This data contains all the cryptographic paths for the asset from its moment of creation through every subsequent transfer. This is the asset’s proof file, which we call PROOF DATA.

Taproot Assets employs client-side validation. This means Bitcoin miners do not verify whether the transferred asset is authentic; therefore, this responsibility falls to the receiver. By verifying the proof file, the receiver can independently confirm the asset’s total issuance, current balance, and its existence on the BTC chain, all without relying on a centralized server. From a security perspective, the proof includes a proof from a Merkle-Sum Sparse Merkle Tree (MS-SMT), which cryptographically ensures that assets are “neither lost nor created” during transfers, completely preventing double-spending and unauthorized minting.

A complete proof contains the following core parts: a) Genesis Proof: Defines the asset’s metadata (name, icon, Asset ID). b) Inclusion Proof: Proves that the asset indeed exists in the current Taproot tree. c) Exclusion Proof: Proves that there are no duplicate assets in other branches of the tree, ensuring the asset’s uniqueness. d) On-chain Anchor Proof: Links the off-chain asset change to a block header on the BTC mainnet via a Merkle Proof, confirming that this is a legitimate, existing asset.

The proof decouples complex asset logic from Bitcoin’s consensus layer, allowing it to benefit from Bitcoin’s security while achieving high scalability. It can be considered the bridge connecting Bitcoin’s underlying scripts with upper-layer asset applications.

2.1.2. EXPORT .PROOF

This function allows you to export the asset proof file to your local device.

2.2. Detailed Explanation of BTC and TA Transactions

In the Taproot Assets protocol, every change in an asset’s lifecycle (whether minting or transferring) is not simply an on-chain or off-chain record, but a “dual transaction” combining both on-chain and off-chain elements. On-chain, there is an anchoring transaction on the Bitcoin mainnet, protected by global consensus. Off-chain, a proof file is generated and stored on a dedicated server (TAPD), detailing the asset’s attributes. This design decouples asset logic from the underlying consensus—Bitcoin provides the immutable infrastructure, while the proof carries the complex business logic.

2.2.1. BTC Transaction

The on-chain component corresponds to a genuine Bitcoin Taproot (P2TR) transaction. Unlike a standard Bitcoin transfer, the output (UTXO) of this transaction conceals a cryptographic commitment known as the “Tweaked Public Key.” Using Taproot’s scripting adjustment technology, the asset holder compresses the asset information into a 32-byte root hash and incorporates it into the public key. Externally, this appears as a regular Bitcoin transaction, preserving privacy and saving on-chain space. Once this transaction is confirmed in a block, it effectively “legalizes” the off-chain asset change, serving as a consensus anchor that ensures the asset’s physical existence.

The process of generating the tweaked public key is illustrated in the figure below:

Source: https://learnmeabitcoin.com/technical/script/p2tr/

On the explorer, from the transaction details page, you can view the Bitcoin transaction portion corresponding to this transaction. As shown in the figure below, the output of 1000 sats is the UTXO anchoring this Taproot Assets transfer:

2.2.2. TA Transaction

The on-chain Bitcoin transaction acts as the asset’s “anchor,” while the off-chain proof is the asset’s true “soul.” In the Taproot Assets protocol, asset transfers are essentially state transitions similar to the Bitcoin UTXO model. A Bitcoin transaction consists of inputs and outputs. The off-chain transfer of Taproot Assets follows a similar structure:

a) Asset Input: The sender must provide proof that the “leaf node” representing the asset they currently hold existed in a previous valid asset tree. This process corresponds to referencing the UTXO of a previous transaction in Bitcoin.

b) Asset Output: The transaction generates new leaf nodes, including a leaf for the recipient and a leaf for the change. The recipient leaf contains the asset quantity assigned to the receiver, while the change leaf returns the remaining asset quantity to the sender. This mirrors Bitcoin’s process of sending to the recipient and returning change to the sender.

c) Asset Conservation: Unlike Bitcoin, which uses scripts to validate amounts, Taproot Assets uses the Merkle-Sum Sparse Merkle Tree (MS-SMT) to mathematically enforce that “what goes in must come out.” Each branch node in the tree records the sum of its child nodes’ asset quantities. If the total input does not equal the total output, the Merkle root hash calculation fails, cryptographically preventing any form of inflation.

When a user initiates an asset transfer, the state flow of the asset’s vUTXO is illustrated in the figure below:

a) Destroy Old State: The sender proves that the old asset leaf has been removed from the original tree (Exclusion Proof).

b) Build New Tree: In the new MS-SMT tree, new leaf nodes are created for the recipient and the sender’s change address.

c) Generate Proof Chain: The system generates a binary sequence containing the Inclusion Proof and Exclusion Proof.

d) Deliver Proof: The sender sends this complete proof file to the receiver. The receiver, without needing to download the entire Bitcoin ledger, can verify the asset’s legitimacy solely by tracing this proof back to the asset’s genesis point.

On the explorer, you can view the asset’s input and output information visually, as shown in the figure below: