Cross-Chain Protocol

The Elastos cross-chain bridge moves ELA between the main chain and sidechains (ESC, EID) at a 1:1 ratio. Deposits are trustless (verified via SPV proofs). Withdrawals are semi-trusted (require 2/3+1 of the 12 Council-operated arbiters to sign).

Deposit Flow: Main Chain to ESC

Step by step:

1. User sends deposit tx — a TransferCrossChainAsset (type 0x08) sends ELA to the ESC genesis block address on the main chain, specifying the target 0x address in the payload
2. Main chain confirms — miners include the tx, BPoS validators confirm with 2/3+1 signatures
3. Arbiter detects — the arbiter's SPV module monitors the main chain via bloom filters tuned to sidechain genesis addresses. When a matching tx is found, it's stored locally
4. On-duty arbiter relays — when the arbiter becomes on-duty, it calls sendrechargetransaction on the ESC node with the main chain tx hash
5. ESC verifies and mints — the ESC node fetches the tx and Merkle proof from the main chain, verifies it independently via its SPV light client, checks for duplicates, then mints ELA to the target address

Trust Model

Deposits are trustless — the ESC node independently verifies the SPV proof. The arbiter only notifies; it cannot forge a deposit.

Withdrawal Flow: ESC to Main Chain

Step by step:

1. User burns ELA on ESC — sends ELA to the cross-chain contract address, specifying the target main chain address
2. Arbiter detects — polls ESC via getwithdrawtransactionsbyheight RPC, waits for 6 block confirmations
3. On-duty arbiter builds tx — constructs a WithdrawFromSideChain (type 0x07) transaction on the main chain, spending UTXOs from the genesis block address
4. Multi-sig collection — the on-duty arbiter broadcasts a proposal to the arbiter network; each arbiter validates and returns its signature; 2/3+1 signatures are required
5. Main chain confirms — the signed tx is broadcast and included in a main chain block, releasing ELA from the genesis address to the user

Trust Model

Withdrawals are semi-trusted — 2/3+1 of the 12 Council-operated arbiters must collude for a fraudulent withdrawal.

Genesis Block Address

Each sidechain has a unique deposit address on the main chain, derived deterministically from the sidechain's genesis block hash. This address has no known private key — it functions as a provable escrow controlled only by the arbiter multi-sig.

Small Transfer Fast Path

Transfers below SmallCrossTransferThreshold (default: 1 ELA) use a simplified single-signature path where only the on-duty arbiter signs. This is a convenience-vs-security trade-off for low-value transfers.

danger

A single compromised arbiter can approve fraudulent small withdrawals.

Schnorr Aggregate Signatures

Introduced at SchnorrStartHeight to replace classic M-of-N multi-sig. Produces a single 64-byte signature instead of N individual signatures.

Curve: NIST P-256 (secp256r1)

The protocol runs in three phases:

1. Nonce generation — each participating arbiter generates a random nonce and computes the corresponding public nonce point R_i = k_i * G
2. R-value collection — the on-duty arbiter broadcasts a request; each arbiter responds with its (R_x, R_y, P_x, P_y). After collecting enough responses, the aggregate challenge is computed: e = SHA256(R_aggregate || P_aggregate || message)
3. S-value collection — each arbiter computes its partial signature s_i = k_i + e * privateKey_i and returns it. The final signature is [R_x || sum(s_i) mod N] (64 bytes)

SPV Proof Format

SPV proofs consist of a Merkle path from the transaction to the block header's Merkle root:

Field	Description
BlockHash	Block containing the transaction
Height	Block height
Transactions	Total transactions in the block
Hashes	Merkle path hashes
Flags	Bit flags for path traversal

Verification rebuilds the partial Merkle tree and compares the computed root against the block header. Includes CVE-2012-2459 protection against duplicate hash attacks.

The arbiter's SPV client uses BIP37-style bloom filters (MurmurHash3) to efficiently monitor the main chain for sidechain-related transactions.

Failed Deposit Return

If a deposit fails on the sidechain (e.g., invalid payload), the arbiter creates a ReturnSideChainDepositCoin (type 0x51) transaction on the main chain, returning ELA to the original sender. This requires the same 2/3+1 multi-sig as withdrawals.

Arbiter Rotation

Height Range	Arbiter Set
Before CRC-Only DPoS	5 original cross-chain arbiters
CRC-Only to BPoS	12 Council arbiters
After BPoS activation	Full BPoS validator set

When the on-duty arbiter changes, it processes all pending deposits, withdrawals, NFT operations, and failed deposit returns.

Fees

Cross-chain fee minimum: 10,000 sela (0.0001 ELA) per cross-chain output. The exchange rate between chains is 1:1.