Oracle Network#
Cross-chain oracles bridge the gap between origin and destination chains. They attest that a solver's fill actually occurred, enabling the escrow to release funds. TetraFi supports 0 oracle implementations - all implementing the same IInputOracle interface.
Cross-Chain Relay Flow#
Cross-Chain Settlement Path
Oracle Relay Sequence
Oracle Comparison#
Oracle Implementations
| Feature | Hyperlane | LayerZero | Wormhole | Polymer | Broadcaster |
|---|---|---|---|---|---|
Trust Model2 features | |||||
Verification | Configurable ISM validators | Ultra-Light Node | 19 guardian validators | ZK-proof (CrossL2ProverV2) | ERC-7888 storage proofs |
Security level | Configurable | Moderate | High (multi-sig) | Highest (ZK) | Emerging |
Coverage3 features | |||||
EVM L2 chains | |||||
Cross-VM (Solana, Sui) | |||||
Bitcoin | |||||
Characteristics2 features | |||||
Latency | Low | Low | Medium | Medium | Variable |
Default for EVM L2 | |||||
Rule of thumb: Hyperlane for EVM L2 corridors, Wormhole for cross-VM (Solana, Sui, Aptos), Polymer when ZK trust is required.
How Oracle Attestation Works#
- Solver calls
fill()on the destination chain OutputSettler - The OutputSettler records the fill event
- The oracle's relay infrastructure detects the fill (monitoring mechanism varies by oracle)
- The oracle constructs an attestation proving the fill occurred
- The attestation is submitted on the origin chain
- The InputSettler verifies the proof and releases escrowed funds to the solver
Each oracle implements IInputOracle with a single key method: the ability to verify that a fill on the destination chain is valid and can be claimed on the origin chain.
Oracle Details#
Default oracle for EVM L2 corridors. Uses configurable Interchain Security Modules (ISMs) for validation. Hyperlane mailbox dispatches messages, validators relay them, and the destination ISM verifies authenticity.
- Deployed on: Ethereum, Optimism, Base, Arbitrum (mainnet + Sepolia)
- Relay: Hyperlane validator network
- Configuration: ISM per corridor (multisig, optimistic, or aggregation)
Wide EVM coverage. Ultra-Light Node model - uses block headers and receipts verified on-chain. Good for chains not yet supported by Hyperlane.
- Supported chains: 30+ EVM chains
- Relay: LayerZero relayer network
Cross-VM bridge. 19 guardian validators provide multi-signature attestations. The only oracle supporting non-EVM chains (Solana, Sui, Aptos).
- Security: 19-of-19 guardian set
- Latency: Higher than L2-native oracles due to guardian quorum
Highest security - ZK proofs. Uses CrossL2ProverV2 for zero-knowledge state proofs. No trust assumption beyond L1 finality.
- Trust: Trustless (ZK-verified)
- PolymerMapped variant: same ZK proof engine with chain ID mapping for non-standard EVM chain identifiers
Emerging standard (ERC-7888). Uses storage proofs - verifies state directly from chain storage. Still experimental.
- Standard: ERC-7888 Cross-Chain Storage Proofs
- Status: Experimental Available for testing, not yet default on any corridor
Bitcoin SPV proofs. Verifies Bitcoin transactions using Simplified Payment Verification. Specialized for Bitcoin-to-EVM settlement corridors.
- Verification: Bitcoin block header + Merkle proof
- Finality: Waits for configurable confirmation depth
- Status: Phase 3 Not yet deployed - Bitcoin-EVM corridors are roadmap-only
Experimental tier. Broadcaster + Bitcoin SPV are not default on any corridor - pluggable IInputOracle implementations gated behind explicit config.
Supported Networks#
| Network | Status | Default Oracle |
|---|---|---|
| Ethereum | Mainnet + Sepolia | Hyperlane |
| Optimism | Mainnet + Sepolia | Hyperlane |
| Base | Mainnet + Sepolia | Hyperlane |
| Arbitrum | Mainnet + Sepolia | Hyperlane |
Oracle Strategy Selection#
The OracleSelector supports three runtime strategies for choosing which oracle to use when multiple are available for a corridor:
Oracle Selection Strategies
| Feature | First | RoundRobin | Random |
|---|---|---|---|
Properties5 features | |||
Selection logic | Lowest latency oracle | Distribute load evenly | Random selection per request |
Latency | |||
Load distribution | |||
MEV resistance | |||
Default | |||
Best For3 features | |||
Time-sensitive orders | |||
High-volume corridors | |||
Security-sensitive flows | |||
Failure Handling#
| State | Behavior |
|---|---|
| Healthy | In selection pool, eligible for requests |
| Cooldown | Skipped, timer counting down to probe |
| Recovery | Single probe request - success → Healthy, failure → extends cooldown |