Wallets and descriptors

AMP2 wallets are identified by descriptors: compact string expressions that fully describe a wallet's script policy and key material. This replaces AMP0's GAID (Green Account ID) model with a standard, wallet agnostic approach.

What is a descriptor

A Liquid wallet descriptor encodes:

• The script type (e.g., elwsh for Elements witness script hash)
• The key arrangement (e.g., multi(2, key1, key2) for 2-of-2 multisig)
• The blinding scheme (e.g., ct(elip151) for Confidential Transactions)
• Derivation paths and key origins for each key

A typical AMP2 descriptor looks like this:

ct(elip151,
  elwsh(multi(2,
    [3d970d04/87'/1'/0']tpubDC347.../<0;1>/*,
    [c67f5991/87'/1'/0']tpubDC4SU.../<0;1>/*
  )))

Breaking this down:

The 2-of-2 multisig model

TODO: Explain more the 2-2 multisig model as the actors involved (actor+AMP2 server) but the issuer and investor can have more complex scenarios (e.g. 3-of-3, 4-of-4, etc.) for them

Every AMP2 wallet is a 2-of-2 multisig between the client (issuer or venue) and the AMP2 server. This means:

• Neither party can unilaterally move assets. The client must sign, and AMP2 must cosign.
• Policy enforcement is cryptographic. AMP2's HSM checks restriction policies before cosigning. If a transfer violates policy, the HSM refuses to sign and the transaction cannot be broadcast.
• The issuer retains custody. Both the issuer's key and AMP2's key are needed. AMP2 cannot move assets without the issuer's signature.

To build a descriptor, you need both your keyorigin xpub and AMP2's keyorigin xpub. AMP2's xpub is provided in the invite data you receive during onboarding (see Environments).

Wallet ID (WID)

When you register a descriptor with AMP2, the server returns a wallet ID (WID): a deterministic identifier derived from the descriptor itself. The same descriptor always produces the same WID.

The WID is used throughout the API:

• As a recipient in send operations
• In restriction group membership
• For balance and transaction queries
• For lock/unlock operations

Registration behavior

Difference from AMP0's GAID model

Keyorigin xpub format

A keyorigin xpub includes the master fingerprint and derivation path:

[<fingerprint>/<derivation_path>]<xpub>

For example:

[b805d768/87h/1h/0h]tpubDCYEgnLyCH2okSittQNNB8JHLwPgmoEAoKcMrJDHP9dFVamsadPAFJQ77C1htgR8ksie3VksLXoryng9AUaPZSF8FwTwEv6CaHp8j2YCrds

• b805d768: the master key fingerprint (first 4 bytes of the master public key hash)
• 87h/1h/0h: the BIP derivation path (purpose 87, testnet coin type 1, account 0)
• tpubDCYEg...: the extended public key at that derivation depth

Caution: Testnet and mainnet use different derivation paths (87h/1h/0h vs 87h/0h/0h). Using the wrong path will produce an invalid descriptor that AMP2 will reject.

Wallet funding

Every AMP2 wallet needs LBTC to pay Liquid transaction fees. Before issuing or sending assets, fund the wallet:

1. Create a Wollet from the wallet descriptor using LWK.
2. Generate a receive address from the wollet (e.g., wollet.address(None)).
3. Send LBTC from an external source to that address.
4. Sync the wollet with Esplora and verify the balance.

Without LBTC, transaction construction will fail because AMP2 cannot pay for network fees.

Related pages

• PSET Lifecycle: how the 2-of-2 signing model works in practice
• Wallet Registration (Issuer): SDK based registration flow
• Wallet Registration (Venue): LWK based registration flow
• Key Management: generating the keys that go into descriptors