Overview

This document outlines the technical requirements for building an Oracle that will participate Fabriq’s cross-chain settlement system. The Oracle’s primary role is to facilitate the settlement of solver-fulfilled intents, by listening for intent events on source chains, validating fulfillment on destination chains and unlocking an escrow once safe to do so.

Background: Current security model

Users deposit funds into an escrow on the source chain upon intent initialization. The solver then fulfills the intent on the destination chain immediately. The escrow is withdrawable by the solver after an hour-long challenge period. If a challenge is issued during the challenge period, the solver must participate in the challenge and resolve it by proving it fulfilled the intent on the target chain correctly.

The protocol flow between the user, system contracts and solver is illustrated below. src represents source-chain, dst represents destination chain. Note: the off-chain oracle service is not represented.

sequenceDiagram

participant User
participant CCD[src]
participant Oracle[src]
participant CCD[dst]
participant Solver

User->>Solver:Submit Intent
Solver->>CCD[src]:Initiate Order: locks collateral
CCD[src]->>User: lock input tokens via Permit2
Solver->>CCD[dst]: Fill Order: transfer output tokens to CCD[dst], order is marked as filled
CCD[dst]->>User: transfer output tokens
Solver->>CCD[src]: Finalize Order
CCD[src]->>Oracle[src]: query CCD[dst] state
Oracle[src]-->>CCD[src]: relay CCD[dst] state
CCD[src]->>Solver: Release Collateral & Intput Tokens

Requirements

Functional

The oracle consists of an on-chain component (the oracle contract, referred to as oracle[src] in the above diagram and as SpecularOracle in the guidelines below) and an off-chain component—responsible together for facilitating secure settlement.

When the intent registry (CCD[src] above) on a source chain queries the oracle contract on the same chain, it should return true if the corresponding intent has been fulfilled prior to the deadline according to its constraints, and false otherwise.

The off-chain service(s) must simply perform any off-chain roles necessary to enable this behavior of the contract. This can include running an optimistic oracle such as UMA, or using a ZK-proof based approach.

Non-functional

The oracle must be secure against:

1. Solvers, who are considered untrusted (but rationally incentivized) parties. If an intent is initiated but not properly fulfilled, the solver must not be paid by the escrow.
2. Destination chain reorgs. The oracle must therefore wait until it is safe to finalize. This time period should be set according to an acceptable time to finalization for each target chain.

Additionally, we care about: