Oracle Systems

1. A submission interface where solvers can submit their filled outputs. It should accept arbitrary payloads for validation, then call the associated output settlement contract to check whether those payloads are valid. If the oracle can prove contract calls, events, or storage on its own, submission is automatic and this requirement does not apply. Oracle implementations can validate whether an output has been filled through the IAttester interface:
   interface IAttester {
     function hasAttested(
         bytes[] calldata payloads
     ) external view returns (bool);
   }
   
2. Implement the validation interface so the input chain can check whether an output was filled:
     interface IInputOracle {
         function efficientRequireProven(
           bytes calldata proofSeries
       ) external view;
     }
   

• Submission and receive interfaces do not have to be standardized, but you must document them so solvers can implement them.
• Oracle systems can either have automatic relaying or manual relaying.
• The oracle system’s trust assumptions must be explicit, so intent issuers and solvers can make informed decisions.

​

Implemented Validation Interfaces

1. Self-serve: Validation interfaces where submitting the payload generates an off-chain proof that must be collected and submitted on the input chain.
   • Polymer — EVM, Tron, and Solana
   • Wormhole — EVM and Solana (see the current mainnet deployment below)
2. Automatic: Validation interfaces where submitting the payload automatically delivers the associated proof on the input chain.
   • Hyperlane
   • Chainlink CCIP
   • Axelar
   • LayerZero
3. Same Chain: Using the Output Settlement to produce an oracle proof for itself, skipping a dedicated oracle system.
   • OutputSettlerSimple

​

OutputSettlerSimple

function setAttestation(
  bytes32 orderId,
  bytes32 solver,
  uint32 timestamp,
  MandateOutput calldata output
) external

​

Same-chain intents on Solana

​

Polymer

• Low gas cost.
• Low latency for quick settlement.
• Polymer can only prove one output at a time, so solvers have to implement batch proving themselves to stay efficient.
• Broadcast

event OutputFilled(
  bytes32 indexed orderId,
  bytes32 solver,
  uint32 timestamp,
  MandateOutput output,
  uint256 finalAmount
);

​

Polymer on Solana

• Output side (a fill on Solana): after filling, the solver exports the fill with one of two instructions. Both validate each description against its LocalAttestation and emit a Prove: log line that Polymer proves on the input chain:
  • submit(source, fill_descriptions) — permissionless and non-consuming. Its only named account is the oracle_polymer state PDA; remaining_accounts holds one read-only attestation per payload. The attestation stays in place, so a dropped or unproven log can simply be submitted again.
  • submit_consume(source, fill_descriptions) — also consumes each attestation, which closes it and returns its rent (if the recorded payer is an executable account, the attestation is only marked consumed and the rent is deferred). Named accounts: submitter (signer), oracle_polymer, Polymer’s local_consumer PDA (2m1udXnYmaxjSXBBE88yZZcwrtT127DqLcwK9B3WCAus), and intents_protocol. remaining_accounts holds interleaved writable pairs [attestation_0, rent_refund_0, attestation_1, rent_refund_1, …]. For every fill payload the submitter must be the attestation’s recorded rent payer — the Solana account that signed the fill, not the filler_data solver id — otherwise it fails with UnauthorizedFillSubmitter. A consuming batch therefore cannot mix fills from different fillers. Not-filled payloads can be submitted by anyone.
  A consumed attestation is no longer a valid proof, so it cannot be exported again by either instruction. Consume only once you no longer need to resubmit — for example, after a submit whose log you have already proven.
• Input side (a Solana order awaiting a remote proof): receiving always ends in receive_attest(), which reads the validated event from the prover’s result account, maps the source chain id through ChainMapping, and registers the Attestation.

1. Call create_polymer_accounts().
2. Call load_proof_chunk(chunk) once per chunk.
3. Call validate_event() with a compute budget of roughly 1,000,000 CU.
4. Call receive_attest().

​

Wormhole

• Security through a decentralized guardian set.
• Supports batch proving of multiple outputs in a single VAA.
• Comparatively slow compared to alternatives.
• Broadcast

function submit(
  address source,
  bytes[] calldata payloads
) public payable returns (uint256 refund);

​

Deployments

• On EVM, submit publishes the Wormhole message with consistency level 15.
• Fetch the signed VAA from the Wormholescan API.
• Delivery is not automatic: the solver (or any caller) must submit the VAA to receiveMessage on the input chain.

​

Wormhole on Solana

• Output side: submit(source, fill_descriptions) validates and consumes the fills’ LocalAttestation accounts, then posts one Wormhole message covering all of them (finality: finalized). remaining_accounts holds interleaved writable pairs [attestation_0, rent_refund_0, …], and the batch must not be empty. The named submitter and a fresh post_message account sign; there is no filler-signature requirement. The VAA emitter is the oracle’s PDA.
• Input side: the receive instruction verifies a posted VAA, maps the emitter chain via ChainMapping, and creates one Attestation per payload. remaining_accounts holds one writable destination attestation PDA per decoded payload, in payload order, with no rent-refund slots; the named signer funds their creation.

​

Hyperlane

• Highly customizable security modules.
• Supports batch proving of multiple outputs in a single message.
• Strong censorship guarantees.
• Automatic or manual relaying.

function submit(
  uint32 destinationDomain,
  address recipientOracle,
  uint256 gasLimit,
  bytes calldata customMetadata,
  address source,
  bytes[] calldata payloads
) public payable

​

Chainlink CCIP

• Security through Chainlink’s oracle network.
• Supports batch proving of multiple outputs in a single message.
• SOC2 and ISO 27001 compliant

function submit(
  uint64 destinationChainSelector,
  bytes32 receiver,
  bytes calldata extraArgs,
  address source,
  bytes[] calldata payloads,
  address feeToken
)

​

Axelar

• Security through Axelar’s Proof of State network.
• Supports batch proving of multiple outputs in a single message.
• Automatic relaying.

submit(
  string calldata destinationChain,
  string calldata destinationAddress,
  address source,
  bytes[] calldata payloads
) public payable

​

LayerZero

• Customizable security
• Popular and broad chain compatibility.
• Supports batch proving of multiple outputs in a single message.
• Expensive

function submit(
  uint32 dstEid,
  address recipientOracle,
  address source,
  bytes[] calldata payloads,
  bytes calldata options
) external payable;

​

Bitcoin

import mempoolJS from "@catalabs/mempool.js";
const mainnet: boolean;
const {
  bitcoin: { transactions, blocks },
} = mempoolJS({
  hostname: "mempool.space",
  network: mainnet ? undefined : "testnet4",
});

export async function generateProof(
  txid: string,
): Promise<{ blockHeader: string; proof: Proof; rawTx: string }> {
  const tx = await transactions.getTx({ txid });

  const merkleProof = await transactions.getTxMerkleProof({ txid });
  // TODO: serialization version 1.
  const rawTx = await transactions.getTxHex({ txid });

  const blockHash = await blocks.getBlockHeight({
    height: merkleProof.block_height,
  });

  // Most endpoints provide transactions witness encoded.
  // The following function serves to strip the witness data.
  const rawTxWitnessStripped = removeWitnesses(rawTx);

  const blockHeader = await blocks.getBlockHeader({ hash: blockHash });

  return {
    blockHeader,
    proof: {
      txId: txid,
      txIndex: merkleProof.pos,
      siblings: merkleProof.merkle.reduce(
        (accumulator, currentValue) => accumulator + currentValue,
      ),
    },
    rawTx: rawTxWitnessStripped,
  };
}