Guides
  1. INDUSTRY FUNDAMENTALS

Digital Asset Rails & Custody

Digital assets — cryptocurrencies and stablecoins — function as an additional funding and settlement rail alongside traditional banking rails. This page covers the generic mechanics of how digital-asset deposits work (on-ramps, confirmations, finality) and the institutional custody models used to secure them, then maps these onto Axys's automatic multi-chain funding model — the diagrams on this page are referenced from Funding & Deposits and Accounts, Wallets & Deposit Addresses.

On-ramps and off-ramps

An on-ramp converts fiat currency into a digital asset; an off-ramp does the reverse. In a card issuing context, a digital-asset deposit needs an off-ramp at some point — the card's balance is denominated in a fiat (or fiat-equivalent) currency, so any digital asset received must eventually be converted.

Stablecoins vs. volatile assets

Stablecoins (such as USDC or USDT) are pegged to a fiat currency (typically USD) and designed to maintain a roughly 1:1 value. Converting a stablecoin deposit to its fiat equivalent carries minimal price risk regardless of timing.

Volatile assets (Bitcoin, Ethereum, and most other tokens) have market-determined prices that can move significantly even within the time it takes for a transaction to be confirmed. Converting these requires real-time pricing at the moment of conversion, and the platform performing the conversion bears (or hedges) the price-movement risk between when the deposit is detected and when it's converted.

Confirmations and finality

When a transaction is broadcast to a blockchain, it's first included in a block. Each subsequent block built on top of that one is a confirmation. The more confirmations a transaction has, the more computationally expensive it becomes to reverse it (via a blockchain "reorganization," or reorg).

Finality is the point at which reversal is considered practically impossible. Different blockchains have very different finality characteristics:

  • Some chains (particularly proof-of-work chains like Bitcoin) have probabilistic finality — there's no single "final" block, but the probability of reversal becomes negligible after enough confirmations (often cited as ~6 confirmations for Bitcoin, though this is a convention rather than an absolute).
  • Other chains (many proof-of-stake networks, and various Layer 2s) have deterministic finality checkpoints — a defined point at which a block is formally finalized by the network's consensus protocol, often reached faster than probabilistic finality on PoW chains.

This is why platforms processing digital-asset deposits typically use a two-stage model: an early confirmation threshold (enough to safely begin processing) and a later finality threshold (enough to treat the funds as fully settled).

Custody models

How a platform holds the private keys controlling digital assets is one of the most consequential design decisions in any digital-asset system:

  • Custodial — the platform holds private keys on behalf of users. Simple user experience, but introduces counterparty risk (users are trusting the platform's security and solvency), and typically requires the operator to be licensed as a custodian or Virtual Asset Service Provider (VASP) under applicable regulation.
  • Non-custodial (self-custody) — users hold their own private keys. No counterparty risk from a custody perspective, but significant UX complexity and the risk of irrecoverable loss if keys are lost.
  • Distributed / MPC custody — a middle path: no single party holds a complete private key. Using Multi-Party Computation (MPC), key material is split into shares distributed across multiple independent parties; a Threshold Signature Scheme (TSS) allows a sufficient subset ("M-of-N") of those parties to jointly produce a valid signature without ever reconstructing the full key in one place. This has become the institutional standard for qualified custodians, combining strong security guarantees with operational practicality.

How Axys implements this

Hierarchical Deterministic (HD) wallets

Rather than provisioning and managing separate wallets per chain per card, HD wallet architectures derive an effectively unlimited number of addresses — across multiple chains — from a single master seed, using standardized derivation paths (the approach popularized by BIP32/BIP44 for Bitcoin-derived chains, and adapted across the broader multi-chain ecosystem). This is the generic technique that underlies Axys's ability to generate unique deposit addresses across 80+ chains and 3,000+ digital assets for every card at the moment it's issued — see Funding & Deposits.

MPC/TSS custody

Axys's custody architecture follows the distributed/MPC model described above — see Security, Compliance & Data Protection for the full architecture, including hardware-isolated key shares (TEEs), M-of-N co-signing, and offline backup with a regulated trustee.

The two-stage confirmation model, concretely

Axys's deposit flow is a direct application of the generic confirmation/finality model above:

  • At 10 confirmations, a deposit is considered safe enough to begin reflecting — the card's ledgerBalance updates, and the deposit is in a pending state.
  • At finality (the chain-specific threshold beyond which reversal is not a practical concern) and once the asset has been off-ramped into the card's base currency, the card's availableBalance updates, and the deposit is complete.
sequenceDiagram
    participant Issuance as Card issuance
    participant Sender as Depositor
    participant Chain as Blockchain
    participant Custody as Axys custody (MPC/TSS)
    participant Account as Card Account

    Issuance->>Issuance: Derive unique deposit address<br/>per chain (HD wallet)
    Sender->>Chain: Send digital asset to deposit address
    Chain->>Chain: Transaction included in a block
    Chain->>Chain: Confirmations accumulate
    Chain->>Custody: 10 confirmations reached
    Custody->>Account: ledgerBalance updated — deposit "pending"
    Chain->>Chain: Finality reached (chain-specific)
    Custody->>Custody: Off-ramp — convert to card's base currency<br/>(dynamic spread applied)
    Custody->>Account: availableBalance updated — deposit "complete"
stateDiagram-v2
    [*] --> AddressGenerated: Card issued — deposit<br/>addresses generated (HD wallet)
    AddressGenerated --> DepositDetected: On-chain transaction observed
    DepositDetected --> Pending: >= 10 confirmations —<br/>ledgerBalance updated
    Pending --> Complete: Finality reached AND<br/>off-ramped to base currency —<br/>availableBalance updated
    Pending --> Reversed: Chain reorganization<br/>before finality (rare)
    Complete --> [*]
    Reversed --> [*]
📘

The "Reversed" path above reflects the generic possibility of a blockchain reorganization between the confirmation threshold and finality — a normal characteristic of how blockchains work, not a documented Axys-specific behavior. Its likelihood depends heavily on the chain and asset involved, and is part of why the confirmation threshold (10 blocks) is set conservatively before any balance update occurs at all.

Unified balance

Because both the bank-rail (fiat) and digital-asset rails ultimately update the same Card Account — see Accounts, Wallets & Deposit Addresses — a cardholder's balance is a single, unified figure in the card's base currency, regardless of which rail funded it.

What's next