Ethereum

The Vault provides full support for the Ethereum mainnet and EVM-compatible configurations. Each Ethereum-enabled wallet receives a standard 0x address derived via the ECDSA public key.

Address Generation

Ethereum addresses are derived from the MPC public key using the standard Ethereum derivation: keccak256(publicKey)[12:], producing a 20-byte checksummed address (EIP-55). The address format is identical to any externally generated Ethereum address — counterparties do not need to know the address originates from an MPC wallet.

Supported Asset Types

ERC-20 support requires the token to be listed in The Vault’s token registry (see Deposits).

Gas and Fee Model

Ethereum withdrawals are built as legacy (type-0) transactions. The Vault reads the current gas price from the node (eth_gasPrice / SuggestGasPrice) and applies a headroom multiplier so the transaction confirms even if the price rises before it is mined.

Gas limits: native ETH transfers use the standard fixed gas; ERC-20 transfers estimate gas from the token contract via eth_estimateGas. If a transaction fails on-chain (e.g. out of gas), the Vault records it as FAILED and does not auto-retry — a new transaction must be initiated.

ERC-20 Transfer Mechanics

For ERC-20 withdrawals, The Vault constructs and signs a transfer(address,uint256) call to the token contract. The sending wallet must hold sufficient ETH to pay gas — the Vault does not automatically sweep ETH into wallets to cover gas costs. If the wallet has insufficient ETH for gas, the withdrawal fails.

Deposit Detection

ERC-20 deposits are detected via eth_getLogs for the Transfer(address,address,uint256) event on the registered token contracts; the indexer then matches the to address against watched wallet addresses in-process. Native ETH deposits are detected by scanning each block’s transactions (eth_getBlockByNumber) and matching the to address against watched wallets, then fetching the receipt.

The Vault’s Ethereum indexer polls for new blocks every 3 seconds (configurable), well inside Ethereum’s ~12-second block time, so new blocks are picked up promptly.

Confirmation Policy

Default confirmation threshold: 12 blocks (~2.5 minutes at 12-second block times).

This threshold protects against chain reorganisations. For higher-security use cases (e.g., large deposits), consider raising the threshold to 20–30 blocks. For low-value automated flows, a threshold of 1–3 blocks may be acceptable.

The confirmation threshold is configurable per network in your deployment configuration.

Reorg Protection

The indexer protects against shallow chain reorganisations using a finality lag: it only treats a block as final once it is buried under the configured number of confirmations (finalityLagBlocks), so short reorgs at the chain tip are never acted on. It also verifies parent-hash continuity between consecutive blocks. If a reorg is detected deeper than the finality lag, indexing halts for that chain and requires operator intervention rather than silently rolling back.

Nonce Handling

Each Ethereum transaction is assigned the account’s current pending nonce, read from the node (eth_getTransactionCount / PendingNonceAt) at build time. Sessions for the same wallet are serialised so nonces are not reused concurrently.