How Arkade Assets Work

Arkade Assets are Bitcoin-native assets that live on unspent outputs 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 outputs 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 is the transaction where the asset was first minted
group_index is the index of the asset group within that genesis transaction

There are two group types:

Type	Behavior
Fresh mint	`AssetId` is absent. The asset is born here. Its ID becomes `(this_txid, group_index)`.
Existing asset	`AssetId` is present. References a previously minted `(genesis_txid, group_index)`.

A single packet can include multiple groups, allowing 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 assets 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 output; whoever holds it holds reissuance rights

Asset Metadata

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

Known Fields

Field	Type	Description
`name`	`string`	Human-readable name
`ticker`	`string`	Short trading symbol (e.g., `"USDT"`)
`decimals`	`number`	Display precision
`icon`	`string`	URL 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 lets assets move between Arkade virtual outputs and conventional onchain Bitcoin outputs. This requires two components:

Arkade Signer acts as a private indexer for the user, tracking onchain asset state after a unilateral exit or offboarding.
Arkade Indexer ingests Arkade transactions to present a complete asset ledger across virtual and onchain outputs.

Transfers Through Batch Swaps

The batch swap system connects virtual outputs and onchain outputs. A batch registration request locks an asset for a pending batch:

Old asset virtual output → [Registration request] → [Commitment transaction] → New asset virtual outputs / Onchain outputs

A registration request can split a single asset across destinations in one operation:

Registration request outputs:
  vout 0 → 50 tokens  (offboarding → onchain output)
  vout 1 → 30 tokens  (new virtual output)
  vout 2 → 20 tokens  (new virtual output)

The commitment transaction resolves all pending registration requests and places assets at their final destinations. This mechanism also lets batch swaps carry assets forward, so renewed virtual outputs keep their asset balances without requiring operator liquidity.

Issue Assets

Create assets with the TypeScript SDK

Send Assets

Transfer assets between wallets

Virtual Outputs

How offchain outputs work

For Issuers

For Integrators

Packets

Asset Groups

Asset ID

Conservation Rules

Control Assets

Asset Metadata

Known Fields

Metadata Hash

Hybrid Architecture (Planned)

Transfers Through Batch Swaps

Issue Assets

Send Assets

Virtual Outputs

​Packets

​Asset Groups

​Asset ID

​Conservation Rules

​Control Assets

​Asset Metadata

​Known Fields

​Metadata Hash

​Hybrid Architecture (Planned)

​Transfers Through Batch Swaps

​Related

Issue Assets

Send Assets

Virtual Outputs

Packets

Asset Groups

Asset ID

Conservation Rules

Control Assets

Asset Metadata

Known Fields

Metadata Hash

Hybrid Architecture (Planned)

Transfers Through Batch Swaps

Related