Asset bridging and custody

The asset bridge represents externally custodied assets as local Universal Token Header accounts. A source vault locks funds, validators attest to the observed deposit, and the bridge credits the corresponding UTH balance. Returning funds burns that local balance and creates an obligation that a destination vault must later unlock.

The useful result is a local asset that can participate in Singularity's account model. Its backing still depends on external custody and the complete lock/mint/burn/unlock route. A local balance or successful burn does not by itself prove external solvency or completed payment.

This explanation follows the custody obligation from deposit to release. For endpoint diagnostics, use Check HILSA readiness; for live-use constraints, check the dated availability record. The public attestation probe at 00:19 UTC on 8 September 2026 returned -32012, describing a protocol-v8 durable-interop safety pause that included mint, unlock and withdrawal routes. That response came from a different deployed build than this protocol-5 checkout; it was not a separate execution test of every bridge method. No funded bridge operation was performed in this run.

Explore the custody lifecycle. Preserve identifiers and evidence across every asynchronous boundary.

Two deposit routes accept different evidence

Two deposit mechanisms coexist under HILSA:

Do not substitute the first mechanism for the second without explicitly choosing its trust model. A vault can emit both legacy Deposit and HilsaDepositV2 events; the existence of the newer event does not change the verification performed by a legacy watcher.

The persistent route binds source chain, gateway, and asset to a destination mint and decimal policy. It derives an immutable mint receipt from the destination domain and source-event coordinates. The current generic Merkle proof is not an Ethereum receipt proof or a Solana account/log inclusion proof. NativeDepositProofRequired is enforced while validating enabled routes, including during account decoding and instruction processing. Persistent mint processor, native adapter gate.

How a compatibility deposit gains authority

An EVM BridgeVault starts paused. Its guardian selects when to accept custody and controls validator membership. A native deposit records the received value. An ERC-20 deposit measures the vault balance before and after transfer and records the actual increase, rather than assuming the requested amount arrived. Both paths reject zero amounts and amounts beyond u64::MAX, the canonical event's raw-unit limit. This protects the amount representation; it does not make every unusual token's future behavior safe. Vault construction and deposits.

The EVM watcher waits for its configured depth and checks the event block against the configured RPC's canonical block hash before observation. That RPC remains a trust and availability dependency. The attestation signs the source block number, but not its block hash.

The ETO_DEPOSIT_ATT_V3 digest binds:

• the cluster's deployment ID and source vault;
• source chain, deposit nonce, and source token;
• recipient, raw amount, decimals, symbol, and name;
• source block number.

The on-chain verifier counts valid Ed25519 signatures from distinct configured validators by stake weight and rejects an empty vault binding. A unique ETO_BRIDGE_DEPLOYMENT_ID is necessary when deployments might reuse validator keys. Attestation preimage, quorum check.

A significant startup boundary remains: the production node passes withdrawal gossip channels into the watcher manager, but passes None for both deposit-signature gossip channels. The local aggregator can meet quorum only if its available signatures carry sufficient stake; a distributed collector implementation does not establish distributed startup wiring. Node integration.

The local representation commits through its enclosing transaction

The bridge derives asset identity from a domain-separated hash of source chain and source-token bytes. It uses that identity as the mint key and derives the recipient's canonical token account. Metadata tracks total minted and burned amounts. The bridge program owns the resulting custody-backed UTH representation; matching header bytes alone do not establish ownership.

Deposit processing checks pause state, chain activation, vault binding, quorum, and replay status. It registers missing asset metadata, checks accounting overflow, credits the recipient, and advances the nonce tracker through its enclosing transaction path. Some helpers write through a supplied account store, so callers must preserve the outer journal/commit boundary rather than treating direct helper calls as independent database transactions. Asset derivation, deposit accounting.

Replay protection is per source chain and nonce. The tracker's 65,536-entry window is a soft bound: it advances its low-water mark only through a contiguous processed prefix. A missing earlier nonce can prevent compaction and grow the recent set. Backfill or investigate the gap; resetting the tracker destroys the evidence needed to reject duplicate minting. Nonce tracker.

The deposit helper also has an attest-only surface that returns verified attestation facts without minting or consuming a deposit nonce. That is useful for an external consumer, but its verification remains the same configured observer quorum. It is not an automatic conversion into native source-consensus proof. Attest-only and standalone verification.

Burn locally, then unlock externally

Withdrawal instruction data, after the opcode, is:

asset_id[32] | amount:u64-LE | destination_chain:u64-LE | recipient[remaining bytes]

The recipient must contain 1–64 bytes. The gross amount must be at least 1,000 raw asset units. The destination chain must match the asset's source chain. Preparation checks the global, chain, and asset policy; validates the canonical bridge-owned UTH and signer ownership; rejects frozen or insufficient balances; and prepares four replacements: user balance, asset metadata, withdrawal counter, and withdrawal event.

Preparation itself is side-effect free. EVM execution stages the updates in its adapter, so discarding a simulation also discards the bridge effects. Metrics are recorded from committed withdrawal accounts, not merely from successful preparation. Withdrawal implementation, validation and updates.

The fee is floor(gross × 5 / 10,000): 5 basis points. For 1,000,000 raw units, the burn is 1,000,000, the event's net amount is 999,500, and its fee is 500. The helper splits that fee into relay and protocol portions, but the withdrawal path records the fee in the event; it does not credit an implemented UTH fee accumulator or convert it into native lamports. Fee arithmetic, fee recording.

New recognized withdrawals are refused by default at mempool admission. The explicit override and the funded ETO_BRIDGE_RELAYER_KEY are separate requirements. Once enabled and configured, the implemented relay signs an EIP-1559 unlock and waits for a successful receipt. The vault verifies its own sorted secp256k1 membership signatures and nonce replay guard before transferring funds. See HILSA writes and settlement for exact relay and destination boundaries.

Preserve the handoff and reconcile custody

The deposit journal is stored below SVM_DATA_DIR. It syncs observation data and directory changes before the watcher advances past a durable handoff. Replay retains an entry until the canonical bridge nonce tracker acknowledges processing; mempool acceptance alone is not finalization. Entry or byte quotas apply backpressure instead of evicting unprocessed obligations. Journal write path, replay.

Track at least these accounting relationships in the same raw asset units:

local net issuance = total_minted - total_burned
gross withdrawal burn = event.amount + event.fee
external custody must cover outstanding represented supply and unpaid obligations

The last line is an operational reconciliation requirement, not an equation the local runtime can enforce against an arbitrary external token balance. Include locked-but-unminted deposits, burned-but-unpaid withdrawals, and fee accounting. Preserve the source receipt, attestation, journal record, local transaction, affected accounts, unlock authorization, destination transaction hash, and receipt.

For a stalled deposit, inspect source finality and canonicality, watcher cursor and journal, quorum wiring, deployment/vault bindings, and the local replay record. For a stalled withdrawal, inspect the committed event, destination membership, relay key and gas, broadcast ledger, vault pause/liquidity, and receipt. Avoid minting again or burning again merely because the external step is slow.

SVM custody and release boundaries

The SVM source gateway accepts native SOL and legacy SPL Token deposits, with immutable receipt PDAs and an explicit pause/asset-enable policy. Its instruction enum contains initialization, authority transfer, configuration, registration, and deposit operations. It contains no release or administrative sweep instruction. It is consequently a custody-only source implementation, and its proof-backed destination mint route remains gated. Instruction surface, source gateway contract.

Tests cover attestation domains, distinct signers, replay gaps, amount/overflow checks, journal reopen and backpressure, and withdrawal preparation. The three-peer withdrawal test uses production frame encoding with simulated channel transport; it does not establish a live vault release. No funded bridge operation was executed during this documentation run. Use recovery operations and the availability reference before choosing a deployment.