Utexo Bridge — Smart Contracts

Smart contracts for the Utexo cross-chain bridge. Each supported network has its own directory with chain-specific contract implementations, tests, and deployment scripts.

Repository structure

ethereum/   — EVM contracts (Solidity, Foundry)

See the README in each directory for setup and deployment instructions.

Architecture overview

The bridge transfers assets between the EVM side and Bitcoin-anchored networks (RGB, and other Bitcoin L2s in the future). A transfer consists of two on-chain operations: FundsIn on the source network (user deposit) and FundsOut on the destination network (bridge releases funds to the recipient).

Deployment topology

The EVM-side contracts in this repository are deployed on Arbitrum. Cross-chain delivery from other EVM networks is implemented by an external delivery layer that lives outside this repository — from the perspective of the contracts here, every deposit lands on Arbitrum and is treated identically regardless of where the user originated from.

        ┌──────────────────────────────── Arbitrum ─────────────────────────────────┐
        │                                                                           │
        │                       ┌─────────── RouteRegistry ────────────┐            │
        │                       │  per-route (srcChainId, dstChainId): │            │
        │                       │      FinalityVerifier + SettlementModule          │
        │                       └──────────────────┬───────────────────┘            │
        │                                          │                                │
        │                                  BridgeProxy                              │
        │                               (Bridge implementation)                     │
        │                                          │                                │
        │                              CommissionManager                            │
        │                                          ▲                                │
        │                                          │                                │
        │                                   MultisigProxy                           │
        │                              (TEE + Federation)                           │
        └───────────────────────────────────────────────────────────────────────────┘

Arbitrum — main contracts:

• BridgeProxy + Bridge implementation — the canonical value-holding address is a custom ERC-1967 proxy. It locks the bridged ERC-20 on fundsIn and releases it on fundsOut, while federation-approved implementation upgrades preserve its address and state. Upgrade control is restricted to typed, timelocked MultisigProxy operations. Route additions still use plugins and normally require no Bridge upgrade.

• RouteRegistry — the routing brain. For every supported (sourceChainId, destChainId) pair it stores two addresses: a FinalityVerifier and a SettlementModule. The Bridge calls into the registry on every transfer; the registry forwards to the right plugins. Routes are registered, paused, and rotated through federation governance (granular SetRoute proposals on MultisigProxy). Owned by MultisigProxy; bridge is immutable, so rotating the registry itself means redeploy + UpdateRouteRegistry.

• FinalityVerifier — a per-route plugin consulted by Bridge.fundsOut to confirm that the source-side event justifying the release is final on its origin chain. The current production verifier is RGBVerifier, a wrapper around Atomiq's on-chain Bitcoin SPV light client (BtcRelay) — it stores Bitcoin block headers and validates proof-of-work continuity and the difficulty-retarget rules. This removes the need to trust any single oracle or off-chain attestation for Bitcoin finality: the EVM-side release is gated by Bitcoin's own consensus, observed on-chain. Routes that don't need finality verification (e.g. trusted-bridge EVM legs) use NullVerifier.

• SettlementModule — a per-route plugin that owns route-specific state. RgbSettlementModule is the permanent proof-of-mint ledger for RGB mint/burn routes. RgbPoolSettlementModule gives pool routes asymmetric behavior: pool credits create no ledger record or RGB-specific event, while pool releases verify their Bridge operation ids against the mint/burn ledger. Routes whose settlement is handled entirely by an external delivery layer use NullSettlementModule.

• CommissionManager — a dedicated fee-accounting contract that holds the protocol's commissions strictly separated from bridge liquidity. The Bridge consults it on every transfer to determine the per-route commission (token vs. native; charged on FundsIn vs. FundsOut) and forwards the fee to it. Withdrawal is gated by federation governance through MultisigProxy. Owned by MultisigProxy.

• MultisigProxy — the authorization layer. Owns Bridge, RouteRegistry, and CommissionManager. It has two independent signer sets plus a direct emergency path: TEE-authorized routine operations (FundsOut) execute immediately on M-of-N enclave signatures; federation-authorized administrative operations (signer rotation, configuration changes, commission withdrawal, route registration, contract address updates) go through a two-phase propose → timelock → execute flow. Federation emergency pause/unpause is instant, and a separately configured emergency guardian may perform the same actions directly without multisig signatures.

Signing model

The bridge uses a federated M-of-N signing model. Multiple independent signer nodes run inside Enclaves (TEE). Each node validates transfer data independently and produces a signature only after its own checks pass. A FundsOut transaction executes only after the required threshold of valid signatures is collected.

There are two independent signer sets:

Enclave signers (TEE) — authorize routine value-transfer operations. For FundsOut, M-of-N signatures are required. In turn, FundsIn does not perform any TEE signature verification, so anyone can call it.

Federation signers (governance) — authorize administrative operations: signer rotation, configuration changes, commission withdrawal, and updates to the addresses of Bridge / CommissionManager. All federation operations go through a two-phase timelock (propose → wait → execute), except emergency pause/unpause which are instant.

Emergency guardian — a single address initialized when MultisigProxy is deployed. It may immediately pause or unpause both bridge directions without signatures. Federation can rotate it or set it to address(0) through timelocked governance.

Private keys are held inside Enclaves and cannot be extracted. Key persistence is handled through attested enclave-to-enclave cloning.

Signing scope by direction

Direction	FundsIn (source side)	FundsOut (destination side)
EVM → RGB	Anyone can call FundsIn and lock funds in the EVM contract	M-of-N PSBT signing inside TEE enclaves
RGB → EVM		M-of-N ECDSA verified on the EVM contract via MultisigProxy

Commission

Each transfer may deduct a per-route service commission consisting of a proportional component plus an optional flat baseFee: fee = amount × percentageFee + baseFee. FundsIn commission may be paid in the bridged token or native currency; FundsOut commission is token-only. The Bridge enforces separate non-zero minFundsInAmount and minFundsOutAmount floors, and a configured flat fee must leave a positive net amount at the applicable floor. On EVM the commission is held by the CommissionManager contract — kept separate from bridge liquidity — and withdrawal is controlled by federation governance through the timelock.

Replay protection

Each network enforces replay protection at the smart-contract level. On EVM the Bridge records consumed burnIds on-chain (each FundsOut carries a burn id bound to the complete release intent and is rejected if already seen), while MultisigProxy enforces a sequential teeNonce for each source chain's typed enclave operations. Route-specific bookkeeping — e.g. matching FundsOut against the exact source-side deposits being settled — lives in the per-route SettlementModule.

Third-party code

The Bitcoin SPV light client consulted on the RGB route lives under ethereum/src/btc_relay/. This code is vendored from the upstream Atomiq project:

• Source: atomiqlabs/atomiq-contracts-evm
• License: Apache License 2.0 — preserved in the SPDX headers of the vendored files.

RGBVerifier does not import the vendored BtcRelay directly — it talks to a deployed relay through the minimal local IBtcRelayView interface (ethereum/src/interfaces/IBtcRelayView.sol), which mirrors only the read methods the verifier relies on.