Assets and asset types

Every AMP2 asset is a Liquid issued asset: a native token on the Liquid Network. AMP2 adds tracking, lifecycle management, and policy enforcement on top of Liquid's native issuance capabilities.

Asset identification

Assets are identified by their hex asset ID: a 64 character string derived from the issuance transaction on chain. This is the canonical identifier used across all AMP2 endpoints.

asset_id: "6f0279e9ed041c3d710a9f57d0c02928416460c4b722ae3457a11eec381c526d"

AMP2 uses only the on chain hex ID.

Contract metadata

Every asset carries on chain metadata embedded in the issuance transaction:

Precision determines how satoshis map to display units:

• precision: 8 → 100,000,000 sat = 1 display unit (like Bitcoin)
• precision: 2 → 100 sat = 1 display unit (like cents)
• precision: 0 → 1 sat = 1 display unit (integer tokens)

Contract metadata is immutable after issuance. Choose values carefully: they cannot be changed later.

Reissuance tokens

When issuing an asset, you can optionally create a reissuance token by setting satoshi_token > 0. The reissuance token is a separate asset that grants its holder the ability to mint additional supply of the original asset.

• If you need to increase supply later (stablecoins, supply management), always create a reissuance token at initial issuance.
• If supply is fixed (bonds at maturity, limited editions), set satoshi_token: 0.
• The reissuance token is held in the same wallet as the original issuance unless explicitly transferred.

Asset operating models

AMP2 supports two asset operating models, determined by how restrictions are configured:

Issuer tracked

The issuer registers wallets and monitors balances, but does not restrict where assets can move. Useful when visibility matters more than strict transfer gating.

• Anyone with a registered wallet can receive the asset.
• Transfers are unrestricted: no whitelist enforcement.
• The issuer tracks ownership through AMP2's balance and UTXO endpoints.

Transfer restricted

The issuer defines explicit transfer policies using restriction groups. The HSM enforces these policies at PSET cosigning time.

• Only wallets in the toWhitelist can receive the asset (when useToWhitelist is enabled).
• Burn permission is controlled per wallet via canBurn.
• The HSM refuses to cosign any transaction that violates the active restriction policy.

Comparison table

Asset Registry

Liquid assets can be registered in the Liquid Asset Registry for ecosystem visibility. Registration associates the asset ID with verified metadata (name, ticker, icon, domain) so that wallets and explorers can display it correctly.

AMP2 does not handle registry registration directly. This is a separate process through the Liquid Asset Registry API.

Asset Registry v2.0

The Asset Registry v2.0 introduces a richer metadata schema that separates immutable core fields from issuer controlled mutable data, custom fields, and admin managed annotations. This allows issuers to update metadata like trading venues and category tags without altering the on chain contract hash.

Metadata categories

Example v2.0 metadata

{
  "asset_id":      "aa909f1b...",
  "name":          "Acme Bond Token",
  "ticker":        "ABT",
  "domain":        "acme.com",
  "precision":     8,
  "version":       0,
  "issuer_pubkey": "02abc...",
  "contract_hash": "e3b0c442...",

  "mutable": {
    "trading_venues": [
      { "name": "SideSwap", "url": "https://api.sideswap.io/assets/ABT" }
    ],
    "category_tags":    ["bond", "fixed-income", "tokenized"],
    "last_updated":     "2026-02-18T00:00:00Z",
    "update_signature": "304402..."
  },

  "custom": {
    "maturity_date": "2028-12-31",
    "isin":          "US0378331005"
  },

  "admin": {
    "asset_type":     "AMP_asset",
    "featured":       true,
    "admin_notes":    "Verified AMP enrollment 2026-01-10",
    "last_admin_action": {
      "action":    "update",
      "field":     "asset_type",
      "admin_id":  "bs-admin-07",
      "timestamp": "2026-01-10T09:30:00Z"
    }
  }
}

Core fields (immutable)

These fields are embedded in the issuance transaction and hashed to produce the contract_hash. They cannot be changed after issuance:

• asset_id: the canonical hex identifier, derived from the issuance outpoint.
• name / ticker / domain: human readable identifiers committed at issuance.
• precision: decimal mapping (0–8), determines how satoshis convert to display units.
• issuer_pubkey: the compressed public key of the issuer, establishing on chain provenance.
• contract_hash: SHA-256 hash of the JSON contract, verifiable by any client.

Mutable fields (issuer signed)

Issuers can update these fields post issuance. Each update is signed with the issuer's key and timestamped:

• trading_venues: list of exchanges or OTC desks where the asset is listed, each with a name and API URL.
• category_tags: freeform tags for classification (e.g., "bond", "fixed-income", "tokenized").
• update_signature: ECDSA signature over the mutable payload, proving issuer authorization.

Custom fields

A flexible key value store for domain specific metadata. Common examples:

• maturity_date: for bonds and fixed income instruments.
• isin: International Securities Identification Number.
• jurisdiction: regulatory jurisdiction of the issuer.
• Any other structured data the issuer needs to attach to the registry entry.

Admin fields

Managed by Blockstream administrators, these fields provide platform level annotations:

• asset_type: classification within the registry (e.g., AMP_asset, standard).
• featured: whether the asset appears in featured listings.
• admin_notes: internal notes for Blockstream operations.
• last_admin_action: audit trail of the most recent admin modification.

Related pages

• Restrictions: how transfer policies are defined and enforced
• Wallets and Descriptors: how wallets relate to assets
• Asset Issuance: step by step issuance flow
• Reissue and Burn: supply management operations