Chain adapter model

Velarum targets many chains through one consistent interface. A chain adapter captures everything that differs between chains so the rest of the system — and your code — can stay chain-agnostic.

Ten chains, one interface

V0 design covers ten chains across five families: EVM (ethereum, base, arbitrum, polygon, optimism, avalanche), solana, stellar, ton, and starknet. You select a chain with a settlement_chain_id string; the adapter handles the rest.

The six dimensions

Each adapter declares a profile across six dimensions: signing (algorithm + account model), fee model (e.g. EIP-1559 vs Stellar fixed stroops), finality (probabilistic vs absolute vs sequencer/ZK), address format (encoding, prefix, checksum), mempool semantics (RBF, expiry, MEV exposure), and error-code mapping (raw chain errors → Velarum error codes). These let the SDK pick safe defaults per chain.

Chain families

Still non-custodial (HC-NC-1)

The adapter only constructs, observes, and maps transactions — it builds the unsigned payload and reads public chain events. It never holds a user signing key, MPC share, or recovery share (HC-NC-1). Signing stays in your wallet on every chain.

What this means for you

Because finality differs sharply — Stellar settles in ~5–7s with no reorg risk, while Ethereum waits for finalized (~15 min) — watch_until_terminal and the chain’s safe_confirmations decide when settled is reported. Always send the settlement_chain_id and an asset_id that match (e.g. base + base_usdc), and let the adapter validate the address format for that chain.