Skip to main content
Arkade Assets are Bitcoin-native assets that live on VTXOs and move through Arkade transactions. They embed asset data directly into Bitcoin transactions using an OP_RETURN output, without requiring any changes to the Bitcoin protocol.

​
Packets

Every Arkade Asset transaction embeds a single asset packet in exactly one OP_RETURN output. The packet is encoded as a TLV (Type-Length-Value) stream, prefixed with the ASCII magic bytes ARK (0x41524b): 
OP_RETURN <0x41524b> <TLV_Stream>
The TLV stream contains one or more typed records. The asset record uses type 0x00: 
<Type: 0x00> <Length: LEB128 varint> <Asset_Payload>
A transaction is rejected if it contains:
  • Multiple OP_RETURN outputs with ARK magic bytes
  • Multiple type 0x00 records across any TLV streams
Implicit burn: If a transaction spends UTXOs carrying asset balances but contains no asset packet, those balances are permanently burned. Indexers remove them from state.

​
Asset Groups

The asset payload inside a packet is an ordered list of Asset Groups. Each group defines one asset’s inputs and outputs for the transaction — how much of a given asset is consumed and where it goes.

​
Asset ID

Each asset is identified by a pair: (genesis_txid, group_index).
  • genesis_txid — the transaction where the asset was first minted
  • group_index — the index of the asset group within that genesis transaction
There are two group types:
TypeBehavior
Fresh mintAssetId is absent. The asset is born here. Its ID becomes (this_txid, group_index).
Existing assetAssetId is present. References a previously minted (genesis_txid, group_index).
A single packet can include multiple groups — this allows multiple assets to be transferred or issued in the same transaction.

​
Conservation Rules

For each group, total output amounts must be ≤ total input amounts (except during fresh issuance or reissuance with a control asset). Spent input assets not assigned to outputs are burned.

​
Control Assets

A control asset is itself an Arkade Asset that authorizes supply increases for another asset. You designate one at genesis — it cannot be added later. 
Fresh mint group → specifies ControlAsset → (enables future reissuance)
Reissuance: To increase supply (outputs > inputs), the transaction must include the control asset in the same packet. Without it, any excess output is rejected. Supply finalization: Burning the control asset — either explicitly or by not routing it to any output — permanently caps the controlled asset’s supply. Existing tokens continue to circulate normally. Rules:
  • An asset cannot reference itself as its control asset
  • Control is not transitive — if Asset A is controlled by Asset B, reissuing A requires only B, not B’s controller
  • The control asset can be transferred to a new UTXO; whoever holds it holds reissuance rights

​
Asset Metadata

Metadata is defined at genesis and is immutable — it cannot be changed after creation.

​
Known Fields

FieldTypeDescription
namestringHuman-readable name
tickerstringShort trading symbol (e.g., "USDT")
decimalsnumberDisplay precision
iconstringURL to an image
Any additional key-value pairs are valid. The full metadata set is committed at genesis as a Merkle root (using BIP-341 tagged hashes), enabling compact inclusion proofs.

​
Metadata Hash

The metadataHash is the Merkle root of all key-value pairs encoded as leaves: 
leaf[i] = tagged_hash("ArkadeAssetLeaf", 0x00 || varuint(len(key)) || key || varuint(len(value)) || value)
branch  = tagged_hash("ArkadeAssetBranch", min(left, right) || max(left, right))
This aligns with BIP-341 taptree construction, making metadata verifiable without full indexer state.

​
Hybrid Architecture (Planned)

The full Arkade Assets design targets a hybrid environment where assets move seamlessly between offchain Arkade transactions and onchain Bitcoin UTXOs. This requires two components:
  • Arkade Signer — acts as a private indexer for the user, tracking on-chain asset state after unilateral or collaborative exits
  • Arkade Indexer — ingests Arkade-native transactions to present a complete asset ledger across both layers

​
Intent-Based Transfers

The bridge between offchain VTXOs and onchain outputs is the intent system. An intent transaction locks an asset for a pending batch: 
Old Asset VTXO → [Intent TX] → [Commitment TX] → New Asset VTXOs / Onchain outputs
An intent can split a single asset across destinations in one operation: 
Intent TX outputs:
  vout 0 → 50 tokens  (collaborative exit → onchain)
  vout 1 → 30 tokens  (new VTXO)
  vout 2 → 20 tokens  (new VTXO)
The commitment transaction resolves all pending intents and places assets at their final destinations. This mechanism also enables batch swaps to carry assets forward, so VTXOs maintain their asset balances across settlement rounds without requiring operator liquidity.
Find the detailed intent system description in the Server & API section

Issue Assets

Create assets with the TypeScript SDK

Send Assets

Transfer assets between wallets

VTXOs

How offchain outputs work