Crypto custody & compliance · engineering reference
Stablecoins join four systems with different clocks and failure modes: an issuer, a token contract, a chain or bridge, and banking settlement. Production design must name every dependency.
A stablecoin payment depends on four systems running on different clocks: an issuer, a token contract, a chain or bridge, and a bank. Treating it as a single payment is how integrations break, because any one of the four can fail without the others noticing.
Only as far as the issuer's balance sheet and redemption terms go. What you hold is a token whose contract has an owner, whose value depends on reserves you cannot inspect directly, and whose redemption runs on banking hours rather than block times.
Chain finality and issuer control are independent axes. A finalized transfer can still sit in a frozen address, wait on a bridge attestation, or land on a contract that resembles the asset you wanted and is not it.
They are different tokens carrying different risk. Native is issued on that chain by the issuer. Bridged is a claim minted by a bridge against a balance locked elsewhere, so it inherits the bridge's failure modes and may not be redeemable at par.
Not the chain. Redemption queues, banking cutoffs, and pricing sources are where a depeg turns into an operational incident, which is why the treasury controls on this page sit next to the contract details.
If you remember one lineSettled on chain and redeemable at par are two separate guarantees. Never let one stand in for the other.
Four systems with different clocks. A rail is production-ready only when every state has an immutable ID, a retry rule, and a reconciliation path.
A rail is production-ready only when every state has an immutable internal ID, a retry rule, and a reconciliation path.
| Layer | Question | Evidence | Bad shortcut |
|---|---|---|---|
| Asset | Which chain, contract, and issuance path? | Allowlisted contract + issuer registry | Ticker symbol |
| Reserve | What backs the liability and at what cutoff? | Issuer report + accountant procedures | “Audited” badge |
| Transfer | When is this route final? | Chain + bridge/attestation state | Block count copied from another chain |
| Control | Who can pause, freeze, mint, or upgrade? | Contract roles + issuer policy | “Decentralized” label |
| Redemption | Who can exit at par, when, and how? | Eligibility + minimum + banking cutoff | Exchange spot price |
Chain finality and issuer control are independent axes. Only one quadrant is actually settled.
Do not use supply figures or chain counts from this table: both drift quickly. Pull issuer APIs/reports at decision time and save the as-of snapshot.
| Asset / model | Issuer/control | Reserve class | Freeze surface | Operator consequence |
|---|---|---|---|---|
| USDC · fiat-backed | Circle | Cash / short-duration liquid reserve per issuer reports | Issuer-controlled addresses | Native contract + chain + issuer redemption are separate risks |
| USDT · fiat-backed | Tether | Issuer-reported reserve mix | Issuer-controlled addresses | Chain support and direct redemption terms differ |
| PYUSD · fiat-backed | Paxos | Issuer-regulated reserve reporting | Issuer-controlled addresses | Contract admin and regulated issuer are dependencies |
| EURC · fiat-backed | Circle | Euro-denominated issuer reserve | Issuer-controlled addresses | FX and banking-calendar exposure differ from USD rails |
| DAI / USDS family · crypto/RWA-backed | Protocol governance | On-chain collateral + RWA structures | Governance/module dependent | Peg and governance risk differ from issuer token |
| Synthetic / delta-neutral | Protocol/operator | Hedged derivatives + custody | Protocol-specific | Funding, exchange and liquidation risks replace reserve cash |
An agreed-upon-procedures report tests specified assertions at a point/date; it does not opine on the whole business.
Concrete use: Record report period, reporting accountant, procedures, reserve cutoff, and liabilities definition.
Failure mode: A monthly PDF cannot prove intraday liquidity or future redemption.
Token price converges to par only when eligible parties can redeem under workable limits and banking schedules.
Concrete use: Model direct issuer redemption, exchange sale, and market-maker path separately for a $5M treasury exit.
Failure mode: Retail token holders may not have the same direct claim or minimum.
Pause, blacklist, mint, burn, and upgrade roles are operational dependencies.
Concrete use: Inventory current contract proxy/admin addresses and alert on role or implementation changes.
Failure mode: “On-chain” does not mean immutable or permissionless.
Native issuance is an issuer liability on that chain; bridged representation adds bridge custody and message finality.
Concrete use: Identify by chain + contract + issuance path; reject symbol-only asset configuration.
Failure mode: A bridge failure can decouple a representation while native tokens remain sound.
Mint/redemption and fiat settlement may stop while tokens trade continuously.
Concrete use: Hold weekend liquidity buffers sized to Monday settlement and expected redemption queue.
Failure mode: 24/7 chain settlement does not create 24/7 bank money.
CCTP v2 encodes confirmed=1000 and finalized=2000 thresholds; integrators must still track source transaction, message, attestation, destination mint, and reconciliation as separate states.
| Rail | Finality dependency | Trust added | Best use | Failure mode |
|---|---|---|---|---|
| Same-chain transfer | Source chain | Token admin | Routine payment | Reorg, pause/blacklist, gas |
| Centralized exchange/book transfer | Internal ledger | Venue solvency/operations | Liquidity conversion | Withdrawal halt or account freeze |
| Lock-and-mint bridge | Both chains + bridge validators/contracts | Bridge custody | Unsupported native route | Exploit or validator compromise |
| Burn-and-mint (CCTP) | Source finality + attestation + destination | Issuer attestation service | Native USDC cross-chain | Attestation delay / destination submission |
| Liquidity network | Source payment + provider settlement | LP/solver | Fast UX | Liquidity exhaustion / pricing |
| Bank wire → mint | Bank settlement + issuer processing | Bank + issuer | Treasury creation/redemption | Cutoff, return, compliance hold |
A payment intent fixes asset, chain, contract, amount, destination, expiry, and finality policy.
Concrete use: Invoice inv_9372 expects 1,250.00 USDC on Base contract X before 16:00Z.
Failure mode: “Send USDC” without chain/contract is not a complete instruction.
Match observed finalized balance delta to a tolerance and route exceptions.
Concrete use: Accept $1,249.99 only if the merchant policy permits a one-cent fiat-equivalent tolerance; never hide the delta.
Failure mode: Token decimals are not business-currency precision.
A refund is a new screened, authorized withdrawal—not reversal of the inbound transaction.
Concrete use: Link refund rf_881 to invoice, verified destination, case, and payout hash.
Failure mode: Sending to the source address can pay a custodial hot wallet or poisoned route.
Set issuer, chain, bank, bridge, venue, and intraday-settlement limits.
Concrete use: Cap any one issuer at a board-approved percentage and keep operational gas in each active chain.
Failure mode: Diversifying contracts on the same issuer may not diversify credit risk.
Predefine price source, duration, size, and operational triggers rather than improvising during panic.
Concrete use: At 0.995 for 15 minutes, pause auto-conversion; at 0.98, require treasury quorum and evaluate redemption path.
Failure mode: A single thin exchange price can trigger a false cascade.
A finalized token transfer may still be frozen, bridged, unreedeemable, or the wrong contract. Settlement assurance is multidimensional.
| Risk | On-chain finality solves? | Issuer/bridge solves? | Required control |
|---|---|---|---|
| Source-chain reorg | YES, after finality | No | Chain-native finality policy |
| Issuer blacklist | No | CONTROL SURFACE | Exposure limits + screening + legal runbook |
| Bridge exploit | No | BRIDGE DEPENDENCY | Prefer native; cap bridged inventory |
| Bank failure/cutoff | No | Redemption path dependent | Bank diversification + calendar buffer |
| Attestation outage | Source may be final | CCTP DELAY | State machine + retry + reconciler |
| Wrong contract | A fake transfer may be final | No | Allowlist chain + contract |
Stablecoin operations fail at the boundaries between a 24/7 chain, an administered token, a bridge/attestation service, and banking hours.
Failures that pass a vendor demo. Expand each for the control and the reason it fails.
USDC exists in multiple native and bridged contracts.
Concrete use: Key by chain + contract + issuance path.
Failure mode: A fake symbol can produce a final transfer.
The scope and assertion are narrower.
Concrete use: Read the procedures and cutoff.
Failure mode: Cadence does not equal continuous assurance.
The representation adds bridge and destination dependencies.
Concrete use: Cap and reconcile by route.
Failure mode: Peg can fail locally while issuer remains solvent.
Thin or stale markets can lie.
Concrete use: Use multiple feeds, duration and size thresholds.
Failure mode: Automation can sell into the very dislocation it creates.
Do not mark tokens issued or redeemed because a bank instruction was submitted. Banking and token events have separate immutable states.
| Rail | Clock | Reversal/failure | Ledger representation | Use when |
|---|---|---|---|---|
| Domestic wire | Bank operating hours | Return/compliance hold | Fiat receivable → settled cash → mint | High-value treasury movement |
| ACH / local batch | Batch days | Return window | Pending receivable distinct from settled | Lower-cost non-urgent funding |
| Issuer mint/redeem API | Issuer + bank settlement | Eligibility, cutoff, account hold | Issuer receivable/payable + token mint/burn | Direct eligible treasury operation |
| Exchange conversion | 24/7 trading; fiat rail separate | Venue withdrawal/counterparty risk | Venue position + in-flight withdrawal | Liquidity/asset conversion |
| OTC / market maker | Contracted settlement | Counterparty and failed delivery | Trade receivable/payable | Large negotiated block |
Engineering routing map, not legal advice. Effective dates and implementing-rule status belong in maintained policy data.
| Regime | Current status checked | System requirement shape | Primary text |
|---|---|---|---|
| US GENIUS Act | Public Law 119-27, approved 2025-07-18; 2026 implementation rulemaking | Permitted issuer, reserve/redemption, BSA and lawful-order controls | GovInfo |
| EU MiCA | Regulation 2023/1114 in force | Authorization, reserve segregation/liquidity, redemption and custody | EUR-Lex |
| EU 2025/1264 | Delegated liquidity/reserve rules published | Intraday liquidity, emergency availability, custodian concentration | EUR-Lex |
Operational and volatile claims were checked against these first-party documents on 2026-08-31. Examples are illustrative controls, not legal, investment, or vendor-selection advice.