Foundation Mission Request: Interop Oracle Standards & Infra for OP Superchain [TECHNICAL]

[opjulian]

Proposed Foundation Mission Request: Interop Oracle Standards & Infra for OP Superchain

Season 7 Intent: A set of interoperable Stage 1 chains doing $250m per month in cross-chain asset transfer

Total grant amount: 154k OP

Should this Foundation Mission be fulfilled by one or multiple teams: One

OP Labs or Optimism Unlimited Sponsor: zainbacchus

Reviewing Body: Developer Advisory Board Foundation Mission Team

Submit by: May 6th at 19:00 GMT

Selection by: May 9th

Start date: May 12th (Please note Missions must be completed within 12 months (i.e. marked as done)

Any questions? You can reach the DAB via the new #dab-general channel in the Optimism Superchain Devs discord: https://discord.gg/QSdZHfHq

---

This mission will define standards, specifications, and infrastructure for interop oracles on the OP Superchain. The goal is to enable trustless, cheap, and fast cross-chain data reads, allowing developers to use oracle information from any chain on any chain.

This team will create guidelines, smart contract templates, and infrastructure for service chains that bring off-chain data on-chain, or do heavy processing/verification (such as on-chain ZK oracles). This will make cross-chain oracles easier to build, use, maintain and expand their chain-support.

What is required to execute this Mission:

1. Define Interop Oracle Standards:
   • Specify data formats, validation mechanisms, and security models for cross-chain oracles.
   • Ensure compatibility with existing oracle solutions and Superchain-native messaging.
2. Develop Smart Contract Templates:
   • Create modular oracle contracts that handle data ingestion, verification, and cross-chain reads.
   • Provide examples for different use cases (e.g., price feeds, RNG, off-chain computation/ZKPs).
3. Build Infrastructure & Tools:
   • Develop off-chain relayers and indexing services to track cross-chain oracle updates.
   • Create SDKs and APIs to simplify oracle integration for devs.
4. Provide Documentation & Developer Guides:
   • Publish step-by-step guides for using interop oracles.
   • Include best practices for security, efficiency, and reliability.
   • Offer tutorials with real-world examples (e.g., fetching ETH price from Unichain to OP Mainnet).

How should progress towards completion be measured?

• Phase 1 - Research & Standardization
  • Define interop oracle architecture and security assumptions.
  • Publish initial standards and messaging formats.
• Phase 2 - Smart Contract Development
  • Create base oracle contracts for cross-chain data sharing.
  • Implement example oracles for key use cases.
• Phase 3 - Infra & Tools
  • Deploy off-chain relayers and indexing infra.
  • Build APIs and integration libraries for easier adoption.
• Phase 4 - Documentation & Adoption
  • Release developer guides, tutorials, and best practices.
  • Work with oracle providers & projects to onboard them to interop oracles.

Impact:

• Seamless cross-chain oracle data availability.
• Standardized interop oracle models for developers.
• Faster, cheaper, and trustless data sharing across OP Superchain.

Go-to-Market Plan:

1. Define and document interop oracle standards.
2. Build smart contracts and infra for cross-chain oracle data.
3. Release developer tools, APIs, and best practices.
4. Onboard oracle providers and projects.

Note - please leverage the [Superchain Dev Docs](https://docs.optimism.io/stack/interop/explainer) and [[Superchain Devnet](https://docs.optimism.io/stack/interop/tools/devnet)](https://docs.optimism.io/stack/interop/tools/devnet) to prototype the Superchain interop integration.

Application Instructions

To apply for this Foundation Mission, please complete the form in the expandable section below and leave your response as a comment on this issue thread. Submissions will be open until April 11th*, at which time the Foundation will review all submissions and select individuals/teams to complete the work defined here.*

Submission Form

Copy the entire application below and leave a comment on this issue with your answers completed. A representative from the Optimism Foundation or the Developer Advisory Board may reach out using the contact info provided to request more information as necessary.

Foundation Mission Application

Please verify that your team members below:

• Team Lead: Please specify the best point of contact for your team
• Contact info:
• L2 recipient address:
• Please list the members of your team and link to any previous work:

---

What makes your team best-suited to execute this Mission?

• [...]
• [...]

Please describe your proposed solution based on the above Solution Criteria (if applicable):

• [...]
• [...]

Please outline your step-by-step plan to execute this Mission, including expected deadlines to complete each piece of work:

• [...]
• [...]

Please define the [critical milestone(s)](https://gov.optimism.io/t/collective-grant-policies/5833#p-25088-critical-milestones-and-clawback-8) that should be used to determine whether you’ve executed on this proposal:

• [...]
• [...]

Please list any additional support your team would require to execute this mission (financial, technical, etc.):

• [...]
• [...]

---

Please check the following to make sure you understand the terms of the Optimism Foundation Mission program:

• I understand my grant for completing this Foundation Mission will be locked for one year from the date of proposal acceptance.
• I understand that I will be required to provide additional KYC information to the Optimism Foundation to receive this grant
• I understand my locked grant may be clawed back for failure to execute on critical milestones, as outlined in the [Collective Grant Policies](https://gov.optimism.io/t/collective-grant-policies/5833#p-25088-critical-milestones-and-clawback-8)
• I confirm that I have read and understand the [Collective Grant Policies](https://gov.optimism.io/t/collective-grant-policies/5833#p-25088-critical-milestones-and-clawback-8)

[themandalore]

hey guys, was thinking of applying, but just wanted to know what the goal was or if there was any more discussion on it. Mainly was just wondering why you wouldn't use generic cross-chain messaging for this. I know you could make it more specific, but the only oracle type with any usage is price feeds and the latency to add a cross-chain call here seems DOA (and doesn't fit with the new pull model of oracles anyway).

[skeletor-spaceman]

hey @themandalore , this FMR is mainly to tackle the surrounding tasks that any oracle would need to support/integrate the superchain.
quoting the FMR:

This mission will define standards, specifications, and infrastructure for interop oracles on the OP Superchain.

[IgorShadurin]

Foundation Mission Application

Team Lead:
@IgorShadurin

Contact Info:
igor.shadurin@gmail.com

L2 Recipient Address:
0x026d2DBD90BfFaF08d90C30D30B218218fF6aE1d

Team Members and Previous Work:
Our team has a strong history of building web2 and web3 infrastructure and tools. Key projects include:

• DappyKit – Superchain SDK for decentralized social apps, used by 100+ apps, with 200+ more expected in 2025.
• ClickCaster – Traffic exchange and analytics platform for Farcaster Frames apps.
• FDP Storage – Private data management on decentralized storage.
• FairJournal File System – Public data protocol for web2 and web3 rollups.
• FairJournal – Medium-like platform using the above file system.
• Zoomerok – TikTok-style app with decentralized user data.
• GetLoginEth – Web3 single sign-on and OAuth solution.
• GetLoginEth Mobile – Mobile wallet and login manager.

In March 2024, we deployed DappyKit contracts on Optimism Mainnet and organized a hackathon:

• Verification Token Contract – Issued 6,000+ verification tokens.
• Smart Account Factory – Created 6,000+ smart accounts.

We’ve grown a community of 35,000+ subscribers on Farcaster and plan a 2025 hackathon to onboard 200+ apps to the Superchain via DappyKit.

Previous Grants:

• DappyKit – SDK for Social Apps – Completed Optimism grant.
• DappyKit – Superchain – Almost completed Optimism grant.

What Makes Your Team Best-Suited to Execute This Mission?
With over 15 years of experience in complex IT systems, we excel at security auditing (e.g., distributed storage systems) and designing detailed specifications, including the Web4 Apps Specification. In DappyKit, we created fast, reliable systems by moving off-chain data verification into scalable infrastructure. Our proven ability to deliver Superchain tools—used by 100+ apps—demonstrates we can define interop oracle standards and build the required infrastructure effectively.

---

Proposed Solution:
We will:

• Define universal data structures for any external oracle to plug in, add modules for proof verification, and rely on off-chain relayers to transform external updates into Superchain-compatible messages.
• Define interop oracle standards (data formats, validation, security) compatible with Superchain messaging.
• Create modular Solidity smart contracts for data ingestion, verification, and cross-chain reads, with examples for price feeds, RNG, and ZKPs.
• Build TypeScript off-chain relayers and indexing services to relay oracle updates across Superchain chains.
• Develop a TypeScript SDK and APIs for easy developer integration.
• Provide clear documentation and tutorials (e.g., fetching ETH price from Unichain to OP Mainnet).
• Integrate a top oracle such as Chainlink to enable broader data coverage and reliable feeds across the Superchain.

Example: Cross-chain use case: Chainlink → OP Mainnet → Base

This scenario uses Chainlink to supply ETH/USDC prices, OP Mainnet to issue loans, and Base to unlock user perks.

1. Chainlink price feed

Chainlink updates ETH/USDC data (e.g., 3000.00) every few minutes. Our relayer packages this proof for the Superchain.

2. OP Mainnet – Collateral loan

A CollateralLoan contract checks the Chainlink proof. If valid, it calculates the user’s collateral, issues a USDC loan, and emits LoanIssued.

3. Base – Premium access

On Base, an AccessController contract verifies the LoanIssued proof from OP Mainnet. Once confirmed, it grants the user premium NFT perks.

Note: Final data formats, proof logic, and cross-chain standards will be fully implemented under this grant.

Example: Cross-chain use case: Unichain → OP Mainnet → Base

This scenario demonstrates a fully trust-minimized, cross-chain oracle workflow involving Unichain (as a data source), OP Mainnet (as an execution layer), and Base (as a secondary execution layer using verified outcomes from OP Mainnet). All interactions will rely on our proposed grant deliverables: smart contracts, off-chain relayers, proof verifiers, and a TypeScript SDK.

1. Unichain – source of oracle data

Unichain acts as a service chain for publishing reliable ETH/USDC price feeds. A contract on Unichain updates the price every 5 minutes with:
postPrice("ETH_USDC", 3120.50, timestamp)

This emits a standardized PriceUpdated event. Our off-chain relayer listens to this event, collects the proof of inclusion in Unichain’s state, and prepares a message for OP Mainnet.

2. OP Mainnet – execution logic based on verified oracle input

On OP Mainnet, a CollateralLoan contract lets users deposit ETH for a USDC loan, referencing the real-time price of ETH from Unichain. The user (or relayer) calls issueLoan with:

• The ETH/USDC price
• Timestamp
• Proof of data publication on Unichain

The contract verifies the proof using on-chain logic and proceeds if the data is valid and fresh:

if (verifyPriceProof("ETH_USDC", price, timestamp, proof)) {
    if (ethAmount * price >= 150% * loanAmount) {
        issueLoan(msg.sender, loanAmount);
    }
}

If successful, the contract emits a LoanIssued event.

3. Base – follow-up action based on OP Mainnet event

On Base, the user owns an NFT that unlocks premium features but remains inactive until a loan is issued on OP Mainnet. A contract called AccessController verifies the loan via a transaction from the relayer, containing:

• Borrower address
• Loan amount
• Timestamp
• Proof that LoanIssued was emitted on OP Mainnet

After verifying the proof, it activates the NFT-based access:

if (verifyLoanProof(borrower, amount, timestamp, proof)) {
    activatePremiumAccess(borrower);
}

Note: This example is conceptual. Actual message structure, proof validation, and cross-chain interaction standards will be designed and implemented under this grant.

    sequenceDiagram
        participant Unichain
        participant Relayer
        participant OP_Mainnet
        participant Base

        Note over Unichain: Price feed is updated
        Unichain->>Relayer: Emit PriceUpdated(price, timestamp)
        Relayer->>OP_Mainnet: Submit price + proof
        OP_Mainnet->>OP_Mainnet: verifyPriceProof()
        OP_Mainnet-->>OP_Mainnet: issueLoan() and emit LoanIssued()

        Note over OP_Mainnet: Loan has been issued

        OP_Mainnet->>Relayer: LoanIssued event
        Relayer->>Base: Submit loan event + proof
        Base->>Base: verifyLoanProof()
        Base-->>Base: activatePremiumAccess()

Loading

---

Step-by-Step Plan (8 Months):
Month 1–2: Research & Standards (May 1 – Jun 30, 2025)

• Analyze Superchain interop and outline how existing solutions can be adapted.
• Define data formats, validation rules, and security models.
• Publish a standards document on GitHub.

Month 3–4: Smart Contracts (Jul 1 – Aug 31, 2025)

• Write Solidity contracts for data ingestion, verification, and cross-chain reads.
• Provide examples: price feeds, RNG, ZKPs.
• Test on a devnet.

Month 5–6: Infrastructure & Tools (Sep 1 – Oct 31, 2025)

• Build off-chain relayers and indexing services for cross-chain data.
• Release a TypeScript SDK and APIs.
• Deploy on Superchain chains.

Month 7–8: Docs & Adoption (Nov 1 – Dec 31, 2025)

• Publish guides, tutorials, and best practices.
• Onboard 2–3 projects to use the oracles.
• Finalize and release all deliverables.

Critical Milestones:

• Month 2 (Jun 30, 2025): Standards published (GitHub docs).
• Month 4 (Aug 31, 2025): Contracts deployed and tested (Devnet proof).
• Month 6 (Oct 31, 2025): Relayers, indexers, SDK, and API live (deployed endpoints).
• Month 8 (Dec 31, 2025): Docs released, 2+ projects onboarded (adoption proof).

Additional Support Required:
None.

Terms Acknowledgment:

• I understand my grant for completing this Foundation Mission will be locked for one year from the date of proposal acceptance.
• I understand that I will be required to provide additional KYC information to the Optimism Foundation to receive this grant.
• I understand my locked grant may be clawed back for failure to execute on critical milestones, as outlined in the Collective Grant Policies.
• I confirm that I have read and understand the Collective Grant Policies.

[chiro-hiro]

Orochi Network application

Team Lead: Chiro Hiro
Contact Info: chiro@orochi.network
L2 Recipient Address: 0xCa484B766085992584af778F61579bB29EcE0BC4
Please list the members of your team and link to any previous work:

• Chiro Hiro - Principal Researcher - 100 hours/month
  • Founder & CTO of Orochi Network
  • Responsibilities: Protocol design, implementation, and project management.
  • Relevant Work: zkDatabase, zkMemory (Ethereum Foundation grant), libecvrf, Orand, Orocle, ERC-6366, ERC-6617
  • Affiliation: Orochi Network
• Chung Thai Nguyen - Researcher - 160 hours/month
  • Responsibilities: Cryptography protocol research, algorithm development, benchmarking, prototype implementation, and testing.
  • Relevant Work: zkMemory (Ethereum Foundation grant).
  • Affiliation: Orochi Network
• Dinh Thang Nguyen - Researcher - 160 hours/month
  • Responsibilities: Cryptography protocol research, algorithm development, benchmarking, prototype implementation, and testing.
  • Affiliation: Orochi Network
• Tung: Researcher - 100 hours/month
  • Responsibilities: Develop smart contracts and prototype implementation.
  • Affiliation: Ancient8

What makes your team best-suited to execute this Mission?
Orochi Network is a research-driven company with a proven track record in scalable, verifiable blockchain infrastructure, and scientific research in cryptography and distributed systems, making us ideally suited for this mission. Our expertise includes:

• Zero-Knowledge Proofs: We’ve built zkDatabase - the first provable database for web3, zkMemory - a universal memory prover (Ethereum Foundation grant), and RAMenPaSTA: Parallelizable Scalable Transparent Arguments of Knowledge for RAM Programs.
• Cryptography and distributed systems: Chiro Hiro (10+ years in security and cryptography) authored libecvrf, Orand, Orocle, MEV: Scalable fair-ordered DAG Mempool (DAGPool), and our researchers also specialize in cryptography, distributed systems and algorithms.

Our deep expertise in Zero-Knowledge Proofs (ZKPs), cryptography, distributed systems, and real-world implementation allows us to both pioneer new secure constructions and evaluate the effectiveness of existing technologies in solving the interoperability, security, and trustlessness challenges of cross-chain oracles. With a track record of grants, awards, and deployed products, we are committed to ensuring that every step of oracle data processing is cryptographically verifiable, enhancing reliability for DeFi, DAOs, and other applications.

We envision ZKPs as the default standard for transparent and trustless computation verification, eliminating reliance on centralized or weak security models. Given our recognized expertise from pretigious foundations like Ethereum Foundation, Web3 Foundation and Mina Foundation, we are confident in our ability to conduct cutting-edge research, propose robust solutions, and implement them efficiently to meet the goals of this grant.

Please describe your proposed solution based on the above Solution Criteria (if applicable):

Our solution, zkOracleHub, is a trustless, verifiable oracle framework for the Optimism (OP) ecosystem, leveraging Zero-Knowledge Proofs (ZKPs) to ensure data integrity from both off-chain and on-chain sources. It features zk-based verifiability, on-chain proof validation, extensibility for custom oracle providers, and superchain oracle interoperability, enabling seamless cross-chain data flow and a permissionless, trustless oracle model.

The main idea is to have a zkOracleHub portal smart contract that enables other contracts to query verified oracle data securely. Oracle providers submit data backed by zk proofs, ensuring verifiable data sampling, whether it's fully off-chain data or on-chain data from other chains. The main oracle provider of the zkOracleHub ecosystem is a decentralized network zkOracle which operates under a fair BFT protocol to maintain high-quality feeds for major tickers. These major tickers serve as the backbone for the verification oracle data of small tickers from other providers. Oracle data can also flow easily between subchains in the OP ecosystem via our trustless oracle validation model.

The solution comprises five key components:

1. ZK proof for data sampling:

The oracle providers perform data sampling from either off-chain or on-chain sources, generate ZK proof of data sampling via a ZKVM and parse data into the corresponding OracleData format. Then they push the data into the zkOracle network consensus for major tickers or push directly into the zkOracleHub smart contract for small tickers.

sequenceDiagram
    API Endpoint->>+Provider: Request
    note over Provider: Prove TLS transcript
    Provider->>-zkOracleHub: Proof Carrying Data
    zkOracleHub->>dApp: Data query
    zkOracleHub-->>Provider: Share profit

Loading

Figure 1: Off-chain data

• Off-chain Data:
  For centralized API sources (e.g., Binance, Coinbase), the oracle providers captures real HTTPS request-response sessions using tools that expose the raw TLS handshake and transcript data. These transcripts—along with the server’s certificate chain and session details—are fed into the RISC Zero zkVM, which replays and verifies them inside the ZK circuit.
  The ZKVM checks:
  • TLS handshake validity (certificate chain, randomness, key exchange, and cipher suite selection).
  • Message Authentication Code (MAC) correctness and decryption using cipher suites like TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, and TLS_CHACHA20_POLY1305_SHA256.
  • Message integrity and payload correctness.
    Once verified, the response (e.g., Binance aggTrades JSON) is parsed into a canonical OracleData format, including value, timestamp, and source metadata. The proof attests to the fact that this data was fetched from a trusted HTTPS session.

  Note: The TLS i/o is not executed inside the VM; only the TLS transcript is verified and the validity of the API response is validated.

sequenceDiagram
    EVM Compatible->>+Provider: eth_getProof()
    note over Provider: Prove EVM state root
    Provider->>-zkOracleHub: Proof Carrying Data
    zkOracleHub->>dApp: Data query
    zkOracleHub-->>Provider: Share profit

Loading

Figure 2: EVM Compatible on-chain data

• On-chain Data:
  For on-chain data from EVM chains (e.g. price of a Uniswap pool), oracle providers use the eth_getProof RPC method to extract Merkle Patricia proofs against the EVM state roots for the corresponding storage slots of the data (e.g. typically Slot 0 in Uniswap V2/V3 pairs for sqrtPriceX96). The proof is passed to the RISC Zero zkVM, which reconstructs the storage trie path and verifies it against the known root hash.

2. zkOracleHub smart contract template:

• The zkOracleHub contract serves as a portal for dApps/smart contracts to access oracle data

  • Anyone can create a new ticker by calling createOracleTicker(ticker: string, spec: OracleTickerSpec)
  • Smart contracts can get oracle data from zkOracleHub by calling getOracleData(ticker: string, provider: string).
  • Oracle providers push data by calling pushOracleData(ticker: string, data: OracleData, proof: OracleProof).
    • The oracle data is first validated by ZK proofs of data sampling. For major tickers from the zkOracle network provider, a threshold signature of the network is verified to ensure decentralized agreement, while for data of non-major tickers, their timestamp are verified against the current timestamp of their sources (which are pushed by the zkOracle network provider)
    • Validated data is aggregated by calculating the average of the last aggregationWindow data items, where aggregationWindow is specified in the specification of the ticker. For major tickers, it's usually equal to 1 since the data has gone through consensus of the zkOracle network.
  • The oracle providers must implement the IzkOracleProvider interface, which allows customizable logic for oracle data access (e.g. payment).

• We have demo interfaces as below:

  interface IzkOracleHub {
      function getOracleData(string calldata ticker, address provider) external returns (OracleData memory);
      function pushOracleData(string calldata ticker, OracleData calldata data, bytes calldata proof) external;
      function createOracleTicker(string calldata ticker, OracleTickerSpec calldata spec) external;
      function isEligibleToGetOracleData(string calldata ticker, address provider, address caller) external view returns (bool);
  }
  
  struct OracleData {
      uint256 value;
      uint256 timestamp;
      string source;
  }
  
  struct OracleTickerSpec {
      uint8 decimal;
      mapping(string => bool) approvedSources;
      uint8 aggregationWindow;
  }
  
  interface IzkOracleProvider {
      function isEligibleToGetOracleData(string calldata ticker, address caller) external view returns (bool);
  }

3. The zkOracle network:

The zkOracle network is a decentralized network operates the zkOracle provider. This network is responsible for publishing high-value oracle data such as major tickers (e.g., BTCUSD, ETHUSD) and trusted source timestamps (Unix time for off-chain data, block headers for on-chain data).

To ensure integrity and consistency, participating peers run a BFT consensus protocol (e.g., DAGPool), which offers order fairness, scalability, and censorship resistance. Once consensus is reached, the data is signed using a threshold signature scheme and submitted to the zkOracleHub portal smart contract. For timestamp oracle data, they are used as basis for verification of other oracle data.

The set of major tickers is determined through community governance.

4. Superchain Interoperability:

The zkOracle framework supports seamless oracle data access across the Superchain in a fair and permissionless model. Though the zkOracle network operates mainly on the OP mainnet, we have two options to get oracle data on subchains:

sequenceDiagram
    participant Provider
    participant OP (zkOracleHub)
    participant CrossL2Inbox
    participant L2StandardBridge
    participant SubOP (zkOracleHub)
    participant dApp
    Provider->>OP (zkOracleHub): Proof Carrying Data
    OP (zkOracleHub)->>CrossL2Inbox: Data
    CrossL2Inbox->>SubOP (zkOracleHub): Data
    SubOP (zkOracleHub)->>dApp: Data query
    SubOP (zkOracleHub)-->>L2StandardBridge: Pay for data usage
    L2StandardBridge-->>OP (zkOracleHub): Pay for data usage
    OP (zkOracleHub)-->>Provider: Share profit

Loading

Figure 3: Superchain Interoperability

• Option 1: OP Mainnet Sampling with Superchain Interop – By adopting Superchain interop message passing, subchains can deploy a local oracle provider that leverages this framework to push OP Mainnet timestamps (verified with Merkle proofs) and sample storage slots from the zkOracleHub on OP Mainnet using ZK-verified Merkle proofs. This enables diverse finance models, such as subchains paying back to the zkOracleHub on the main chain for services rendered. Alternatively, the zkOracleHub can operate independently on the main chain, functioning equivalently to a mainnet provider without requiring subchain interaction.
• Option 2: Direct Submission – Providers can push data directly to subchains, following the same process used on OP Mainnet (Check Figure 1, Figure 2).

These two approaches ensure consistent and verifiable oracle data flows across all chains in the Superchain ecosystem.

5. Tooling and infrastructure:

We aim to build a full-stack toolkit to deploy zkOracleHub's interoperable oracles across the Superchain. This includes:

• JavaScript SDKs: for off-chain data access to zkOracleHub data and integration.
• Rust-based infrastructure: powering the consensus layer for the zkOracle network and zero-knowledge proof generation for providers.
• Modular smart contract templates: for data ingestion, verification, and cross-chain reads—compatible with OP Mainnet and subchains.

Our team will operate the zkOracle network on the devnet and OP mainnet, ensuring production-grade support for OP Mainnet and future Superchain rollouts.

Tooling will align with emerging Superchain interop standards, enabling developers to easily integrate any oracle data (e.g. price feeds, random beacons, or off-chain computation, etc) into any chain in the Superchain.

Please outline your step-by-step plan to execute this Mission, including expected deadlines to complete each piece of work:

• Phase 1: Requirements & Design (April 22 - June 30, 2025)

  • Research TLS verification, Merkle proof sampling for DeFi data on EVM chains, RISC Zero zkVM and consensus protocol for oracle networks.
  • Define ZK proof formats (TLS transcripts, Merkle proofs), aggregation logic (averaging, alternatives), and zkOracleHub specs
  • Design provider node architecture (full zk proof for off-chain & on-chain data)
  • Design zkOracleHub smart contract
  • Design zkOracle network consensus

• Phase 2: Proof of Concept (July 1 - September 30, 2025)

  • Implement oracle provider node: TLS verification (e.g., Binance API) and Merkle proof sampling (e.g., Uniswap slot 0) in RISC Zero zkVM.
  • Implement zkOracle network consensus and threshold signatures on devnet.
  • Implement zkOracleHub smart contracts on devnet with sample major tickers (BTCUSD, ETHUSD), with the zkOracle network being the only provider.

• Phase 3: Integration & interoperability (October 1 - January 31, 2026)

  • Implement JS SDKs for off-chain interaction withzkOracleHub smart contracts
  • Implement Rust SDKs for provider node and zkOracle network node
  • Implement superchain inteoperability: cross-chain oracle flow and test on subchains

• Phase 4: Testing & Documentation (February 1 - April 21, 2026)

  • Test with real-world data (e.g., Binance API, Uniswap pools) across OP Mainnet and subchains
  • Operate the zkOracle network and ensure inteoperability on mainnet and subchains.
  • Write guides, tutorials, and onboard 3+ providers.
  • Final release by April 21, 2026, with devnet and mainnet operations live.

Please define the critical milestone(s) that should be used to determine whether you’ve executed on this proposal:

• Milestone 1 (June 30, 2025): Publish ZK oracle standards (proof formats for TLS/Merkle, zkOracleHub specs), oracle provider node architecture, zkOracle consensus protocol.
• Milestone 2 (September 30, 2025): Deploy working PoC on Superchain devnet with zkOracleHub smart contracts, zkOracle consensus, oracle provider node (which consists zk proof generation) for 2 tickers.
• Milestone 3 (January 31, 2026): Launch SDKs (JS/Rust), integrate cross-chain oracle flows for subchains, operate zkOracleHub and zkOracle for mainnet and oracle providers for subchains.
• Milestone 4 (April 21, 2026): Final release on OP mainnet and subchains, with real-world oracle feeds, provider onboarding, full documentation, and production-grade support.

Please list any additional support your team would require to execute this mission (financial, technical, etc.):

• Financial: The 154k OP grant is sufficient, but we request 15k OP upfront (unlocked) to fund infra testing (RISC Zero zkVM with hardware acceleration, zkOracle consensus simulation) and API cost.
• Technical: Access to Superchain Devnet resources (e.g., compute credits) and OP Labs support for native messaging/subchain integration.
• Community: Developer Advisory Board feedback on standards and assistance in onboarding providers and zkOracle network peers.

Please check the following to make sure you understand the terms of the Optimism Foundation Mission program:

• I understand my grant for completing this Foundation Mission will be locked for one year from the date of proposal acceptance.
• I understand that I will be required to provide additional KYC information to the Optimism Foundation to receive this grant.
• I understand my locked grant may be clawed back for failure to execute on critical milestones, as outlined in the Collective Grant Policies.
• I confirm that I have read and understand the Collective Grant Policies.

[dmitriy-woof-software]

WOOF! Application

Team Lead: Dmitriy Babenko

Contact info: dmitriy@woof.software

L2 recipient address: 0x985B29fe72988c5381005747C96EaEa5Fc274b1C

---

Team Members and Previous Work:
WOOF! is a blockchain development company specializing in EVM and infrastructure solutions. After launching one of our first projects—bringing Compound Finance to the Optimism network—we expanded our role to become a core development team for the Compound protocol. Since then, we've collaborated with Avalanche, Ronin, Etherfi, and the Uniswap Foundation on various research and development initiatives.

Throughout our work experience, we deeply collaborated with leading service providers as OpenZeppelin, Gauntlet, Compound Labs, Etherfi, Chainlink, Redstone. We worked closely with Chainlink and Redstone and are well-versed in their supported services, including OEV, Automation, and Streams. During the development of the King protocol, we also partnered with LayerZero to enable cross-chain functionality for the KING token.

Some of our works:

• Compound: Optimsim Deployment
  • USDC
  • USDT
  • WETH
• Compound: Development Updates
• Compound: Sandbox
• Compound: Migrator
• Compound: Rewards V2
• Compound: OEV Research
• Hard Swap
• King Protocol

Project Team:

• Pavlo Horbonos - Solution Architect.
  Pavlo has over 8 years of experience as a blockchain developer, team lead, architect, and security lead. His background as an auditor provides valuable expertise for building reliable security solutions, complemented by a strong foundation in R&D. He has experience both developing blockchains from scratch and bootstrapping them using the OP Stack.
• Philipp Taruta - Lead Solidity Engineer.
  Philipp will take the lead on the blockchain layer overall, with a focus on smart contract development. He previously worked closely with Pavlo in the auditing space, which brings valuable experience to the project. Philipp's most recent project was leading the development of Hard Swap, a fork of the V3 DEX.
• Dmitriy Babenko - Researcher. CTO at WOOF!
  Dmitriy will serve as an advisor for critical technical decisions and will facilitate communication between WOOF! and the OP Foundation. He is a core contributor to projects such as Compound Finance, Kava, Ronin, Avalanche, and many others.

The team will be expanded to include an additional Solidity developer, two backend developers, and a DevOps engineer.

Overall, our team is committed to delivering the project to the highest quality standards and is ready to allocate additional resources from our team of 30 developers if needed.

---

Please describe your proposed solution based on the above Solution Criteria (if applicable):

To achieve the goals stated in the Mission Request, WOOF! will develop several components of the infrastructure. Based on the high-level specification presented in the mission and based on the available Interop specification, WOOF! conducted an analysis of the connected risks, technological challenges, later integration issues, and other circumstances to be overcome. Based on the internal research conducted by WOOF! engineering team, we see the next approach to the oracles interop architecture - presented as a list of components to be developed with connected corner points.

1. The Standard
The standard development should be based on two cornerstones: easy integration and simple interface with no ambiguity.

To achieve the first requirement, the WOOF! team will:

• Conduct a comparative analysis of available oracles, price feeds, and price sources among those implemented within the Optimism ecosystem.
• As a result, the team analyses the differences in data formats, approaches to onchain data storage, differences in offchain infra and parameters of the onchain feed update process (e.g. frequency, pushed data, maturity, number of verifications, amount of aggregated data, timestamping, etc).
• All these data will be used to create a standard for Interop, ensuring high compatibility and a minimal number of steps necessary for migration.

As a result, there will be enough data to develop instructions and whole procedures to help existing price feed providers seamlessly integrate the Interop infrastructure. These data will also be included in the standard development to simplify the integration of the Interop Oracle infrastructure for DeFi projects in the Optimism ecosystem.

This approach also includes choosing the protocol to be the first to integrate the Interop infrastructure and serve as a “beta-testing playground.”

To achieve the second requirement, the WOOF! team sees the following key points:

• The team will develop an ERC/EIP-based standard for the Optimisim ecosystem to ensure that the formal description follows the accepted web3 community guidelines.
• The standard will include the data format for the price feeds - so that Oracles will have a unified format for logging messages into the Supervisor;
• That will include the message standard that should be prepared for further querying within the cross-chain interactions.
• The standard for the information fetching on the target chain. That will be the final link on the standard - so the dApp will fetch the info via the SC based on the standard-based interface, which will fetch the crosschain message prepared also via the standard, and that can be verified through the OP Supervisor based on the standard-based log emitted by the price feed provider.

Artifacts:

• ERC/EIP based standard for Interop Oracle.
• Analysis of existing price feed providers solutions.
• Procedures and instructions for price feed providers for quick integration of the Interop oracle standard.
• Guidelines for the DeFi protocols to adopt the standard.

2. Onchain Layer
The standard itself is insufficient for the price carrier layer (which the Interop Oracle infra will be). Thus, it should be followed by the implementation of the standard, which will start from the smart contracts implemented for each side of the price delivery pipeline—price feed providers and target dApps.

We see the following key points:

• We will develop the standard library for the integration of the Interop Oracle pipeline into the SC of target dApps.
• This library will include the connector and messages querrier for simple interaction with available price feeds (Wormhole-like approach).
• The row of connectors for the price feed providers. The idea is to either develop an individually developed Connector (based on the standard interface) for the price provider or include it directly in the Accumulator contract—that will depend on the result of the comparative analysis and on how the provider is ready for the integration with the standard.
• Each chain within the Optimism Interop ecosystem will receive the Accumulator contract, which will serve as a messaging hub for the chain (trusted source of logs for the OP Supervisor). Thus, there will be no need to track each provider's messages, but focusing on the aggregated source. So, the Accumulator contract and all Connectors will implement the message composing mechanism.
• Each chain within the Optimism Interop ecosystem will have the Requester contract, which will mediate quote requests from SC’s to the OP Supervisor.

Keypoints to be included in the standard implementation:

• Source chain identifier.
• Target chain identifier.
• Source price feed provider identifier.
• Asset identifier (based on both target/source chains' ids, tickers, and SC addresses).
• Timestamp of the quote.
• Maturity of the quote - in terms of sources aggregated and TWAP rounds accumulated.
• The quote itself is converted into universal units.
• Formatting/conversion details—While the message should include raw data, the standard library will adjust the format as necessary.

3. SDK for dApps
Since dApp is more than SC in the core, the standard implementation should also include an SDK to integrate the price fetching mechanism into the dApp. Therefore, WOOF! team sees the next key points:

• SDK will be TypeScript-based since TypeScript is currently the most web3-friendly and adopted language.
• SDK will include modules for interactions with the Requester contracts for each chain, with their latest addresses included in SDK itself.
• SDK will include the precompiled requests examples and included multicall contract call example, so the dApp will not need to develop these components on its own.
• The SDK will include documentation and integration examples, along with the sandbox dApp example deployed on a test environment.

SDK will also reference APIs for quick interactions with the predefined price feeds requesters (e.g. for bluechip assets), though the API component will be developed separately.

4. Infrastructure
We will build the infrastructure for the Interop Oracle layer. That includes:

• Offchain relayers - for messages receiving and storing, for providing the messages to the target chains, and for the communication with the OP-Supervisor.
• Indexer - for the messages storage and pre-compilation based on each price feed provider update. In this way, even if the quote is not requested immediately, it will be stored for a particular price feed provider for a certain block and will be available for later inspection.
• Balancing infrastructure - each service will be containerized and orchestrated to avoid overloading and to make sure that enough relayers are available at each moment.

5. Other
We will also work on the following items during the whole development pipeline:

• Documentation - a gitbook covering the standard library, Connector implementation guidelines for price providers, interactions with Accumulator and Requester contracts, and the SDK reference.
• Tutorials and manuals - step-by-step guidelines for dApps for integration with the Interop Oracle layer, the list of examples, and the testnet sandbox as a live example of the integration.
• Website - as a point of information Accumulator for the Interop Oracle layer
• Infrastructure - orchestration of relayers and other services.
• Guidelines - for running the relayer or integration of the price feed via the Connector, etc.
• Projects onboarded list

---

Please outline your step-by-step plan to execute this Mission, including expected deadlines to complete each piece of work:

Month 1: Research and Analysis

• The phase of active research of the price providers in the Optimism ecosystem is described in the “Standard” section of the application.
• Definition of the Oracle Standard, development of the first guidelines.
• The choice of the projects and price providers to be adopted first.
• Conducting of the research for the details of interaction with the OP-supervisor.

Months 1-2: Oracle Standard and SC Standard library development

• Early start of the SC development - general interface for the target (consumer protocol) side.
• Standard development and its formal verification.

Months 2-3: Accumulator contract and Connectors

• Development of the price feed producers side of the onchain layer;
• Integration of the first price providers (in the testnet mode or beta mainnet mode).
• Testing stage development and early testnet deployment.

Months 3-5: Requester contract, relayers, full pipeline testing

• Development of the offchain services for message delivery.
• SDK development.
• Integration with the OP-Supervisor.
• Finalization of the target consumer side of the onchain layer.
• Full testing stage development, end-2-end testing.
• Early adoption by target protocols (in the testnet or beta-mainnet mode).
• Onboarding of the first target protocols.

Months 4-6: Infrastructure building

• Stabilizing the pipeline.
• Scaling of the developed services.
• SDK release and end-2-end testing of the whole pipeline.
• Finalization of guides and instruction on relayers running and interactions with the Interop Oracle layer.
• Development of the stable scalable infrastructure.

Month 6: Release and adoption

• Development of the mainnet version of the protocol.
• Support of the testnet sandbox.
• Release of documentation, SDK, tutorials.
• Mainnet release.

Note: WOOF! development pipeline is built upon the following principles:

• Smart Contracts First: Core SC are started as early as possible to speed up the development of the next components.
• Real-time Documentation: Documentation, manuals, and guidelines are created once the component is ready to avoid delays between the component delivery and its documentation.
• Testing: The pipeline includes intensive testing for each component: 100% unit test coverage for SC, integration and end-to-end testing for relayers and other services, and stress testing for the infrastructure.
• Scaling: The modular approach in SC development, the containerized development of service, or the infrastructure development approach are generalized, as we always expect scaling to come after the release of each component.

---

Please define the critical milestones that should be used to determine whether you’ve executed on this proposal:

• Early June: The Oracle Standard release.
• End of June - early July: Onboarding of the first price provider.
• End of August: Onboarding of the first target consumer protocol.
• September: Testnet release of the onchain layer (SC deployed on testnet, documentation, sandbox access).
• Early October: Testnet release of the SDK (package available on NPM, documentation, sandbox access).
• End of October: Testnet release of the whole pipeline (sandbox access, code published on GitHub, instructions on relayer launch).
• November: Mainnet release (SC deployed on target chains).

Please list any additional support your team would require to execute this mission (financial, technical, etc.):

None, except periodic consulting with the OP-Supervisor and crosschain protocol development team on details of the integration plan.

---

Please check the following to make sure you understand the terms of the Optimism Foundation Mission program:

• I understand my grant for completing this Foundation Mission will be locked for one year from the date of proposal acceptance.
• I understand that I will be required to provide additional KYC information to the Optimism Foundation to receive this grant.
• I understand my locked grant may be clawed back for failure to execute on critical milestones, as outlined in the Collective Grant Policies.
• I confirm that I have read and understand the Collective Grant Policies.

[0xludobianco]

Team Lead: Please specify the best point of contact for your team

Ludovico Bianco

Contact info:

Tg handle: @ludobianco
Mail: ludovico@substancelabs.xyz

L2 recipient address:

0x2e125385273F057Cb1d2ec55Af4Bd656e07b0387

Please list the members of your team and link to any previous work:

Substance Labs brings deep, hands-on experience in building secure, modular infrastructure for cross-chain communication, with a focus on public goods and protocol-agnostic standards. Over the past decade, the team has been involved in foundational interoperability initiatives—from pioneering oracle systems to developing frameworks for trust-minimized cross-chain state verification.

Our core contributions include:

• Oraclize / Provable – One of the first oracle services on Ethereum, enabling real-world data to be securely delivered on-chain.
• pNetwork – A cross-chain interoperability protocol that facilitated billions in value transfer through secure bridges.
• Sygma – A modular interoperability layer for cross-chain messaging, enabling composability across ecosystems.
• Hashi – An oracle aggregator that enhances security by validating cross-chain messages through multiple independent oracles.
• State Sharing Network (SSN) – A trust-minimized block header relaying system enabling verified state access across any-to-any chains.
• Safe Crosschain – A framework enabling Safe accounts to verify and execute actions on remote chains using trustless state proofs.
• Aztec Confidential Cross-chain Bridging - (WIP) Building a privacy-preserving, trust-minimized cross-chain bridge between Aztec and Optimism.

Substance Labs Team

• Thomas Bertani – A blockchain entrepreneur since 2012, Thomas has pioneered oracles, bridges, and blockchain co-processors since 2014. He founded Oraclize/Provable, one of the earliest oracle services bringing real-world data on-chain, and later founded pNetwork, a cross-chain interoperability protocol that facilitated over $1.2 billion in cross-chain volumes at its peak​.
• Georgios Gontikas – A blockchain expert since 2017, Georgios led Hashi’s development from its inception and played a key role in the zk Bridge for Gnosis Chain. He was previously leading the Sygma interoperability protocol at ChainSafe. Later, he served as Head of Bridges at Gnosis, overseeing cross-chain integrations and bridge security enhancements​.
• Mauro Piazza: a senior blockchain developer working on production grade blockchain oracles, bridges and message passing protocols, specifically Hyperlane and Trusted Execution Environments.
• Alessandro Manfredi - A prolific blockchain developer and architect, who has built a range of complex blockchain protocols since 2017.

What makes your team best-suited to execute this Mission?

Substance Labs brings deep, hands-on experience in building secure, modular infrastructure for cross-chain communication, with a focus on public goods and protocol-agnostic standards. Over the past decade, the team members have been involved in foundational interoperability initiatives—from pioneering oracle systems to developing frameworks for trust-minimized cross-chain state verification.

The track record of our members includes the creation of Oraclize/Provable, one of the earliest oracles on Ethereum; the launch of pNetwork, a cross-chain protocol that moved billions in value; and the development of Sygma, a general-purpose cross-chain messaging protocol, built while leading product at ChainSafe.
More recently, we developed Hashi, an oracle aggregator for additive security used to secure Gnosis and Lukso’s canonical bridges; the State Sharing Network (SSN), which enables verified access to cross-chain state through block header relaying; and Safe Crosschain, a trustless execution framework for Safe accounts.

These efforts have earned support through multiple grants, such as the ones from Optimism, Arbitrum, and GnosisDAO, and recognition from Uniswap’s bridge assessment.
Our infrastructure is currently live across major networks—including Ethereum, Optimism, Base, Arbitrum, and Polygon—and supports real-time relays and storage proof verification visible through the Hashi Explorer.

Our core team includes:

• Thomas Bertani – Blockchain innovator since 2012, founder of Oraclize/Provable and pNetwork.
• Georgios Gontikas – Former Product Lead at ChainSafe and Head of Bridges at Gnosis; led the creation of Hashi.
• Mauro Piazza - Senior engineer with experience in production grade backend services, oracles services and message passing applications.
• Alessandro Manfredi – Senior engineer with extensive multi-chain infrastructure experience.

Our proposed solution introduces a directive-based oracle system built on Hyperlane, offering a standardized, modular approach to executing cross-chain instructions. By decoupling application logic from trust assumptions, and supporting customizable Interchain Security Modules (ISMs), this framework enables scalable, secure, and flexible oracle use cases—ranging from cross-chain state reads to off-chain data feeds and verifiable randomness—tailored for the Superchain ecosystem.

Please describe your proposed solution based on the above Solution Criteria (if applicable):

We propose to leverage the ubiquitous Hyperlane protocol as a general-purpose, interchain communication standard that will serve as an oracle system on the OP Superchain. Our solution centers on the concept of “directives”—a standardized way to encode and execute instructions across chains. By abstracting the oracle logic into modular, reconfigurable components, our architecture decouples application-level operations from underlying trust models.

The “Directives” Standard

Encoding Schema:
Each directive is represented as a structured message:

[directive_type, directive_name, directive_args]
Example:
A directive to compute a sum would appear as:

[MAGIC_NUMBER, [DIRECTIVE_MATH, DIRECTIVE_SUM, [42, 3]]]

• Here, the receiving Interchain Security Module (ISM) would execute the addition and return 45.

• Extensibility:
  Directives can be defined for varied use cases, including:

  • Chain State Queries: e.g., reading block headers or specific storage values using directives like ETH2__BLOCK_ANCHORED_LOG or EVM_VIEW.
  • Off-Chain Data Reads: e.g., fetching price feeds or VRF outputs.

• Customizable Trust:
  The same base messaging format is used regardless of the underlying ISM. Users choose an ISM according to their trust preference—ranging from a “trusted/centralized ISM” (for simple or performance-critical use cases) to decentralized options (e.g., one that integrates Chainlink) for enhanced trustlessness.

System Architecture

Our architecture comprises several components:

• Smart Contract templates/libs:

  • An abstract oracle contract, based on a Directives-ready ISM, that handles Hyperlane messages encoded with directives and their answers.

  • An utility library to simplify developer integration and use of oracles for price feeds, foreign state read and VRF.

• Interchain Security Modules (ISMs):

  • The ISM is responsible for the directive’s validation and execution. We will provide multiple example ISMs that showcase different security models:
    • a simple centralized one for price feeds.
    • a Chainlink-based one for VRF and price feeds.
    • an Hashi-based one for reading the state of a foreign blockchain.

• Off-Chain Relayers and Utility Libraries:

  • Relayer infrastructure that gathers external data, encodes it into directives, and dispatches messages via Hyperlane.
  • A node SDK to handle directives.

• Developer Documentation & Templates:

  • Detailed guides and tutorials showing how to create new directives, integrate new oracles via ISMs, and use them securely.
  • Open-source repositories with example contracts, tests, and integration samples.

Use Cases

• Cross-Chain State Reads:
  Enable querying of on-chain state across different chains using directives such as ETH2__BLOCK_ANCHORED_STORAGE or EVM_VIEW.

• Price Feeds & Randomness (VRF):
  Use tailored directives with customizable ISMs to deliver dependable price data or verifiable random numbers for decentralized applications.

• Off-Chain Data Integration:
  Leverage the directives framework to provide oracle services for any external data by enabling off-chain relayers to securely feed data on-chain.

Benefits

• Modularity & Flexibility: Developers can choose and swap ISMs without modifying the higher-level oracle logic.
• Scalability: The inherent modularity of Hyperlane coupled with our directive abstraction makes the system scalable across hundreds of chains.
• Developer-Friendliness: Fully documented libraries, standard templates, and examples will drastically lower the barrier to integration.
• Future-Proof Architecture: As new oracle use cases emerge, the directive format provides a flexible foundation to incorporate additional functionality.

Please outline your step-by-step plan to execute this Mission, including expected deadlines to complete each piece of work:

Phase 1 – Research, Directives Standard, & Architectural Blueprint (Month 1–2: May 1 – June 30, 2025):

• Research & Analysis:

  • Gather requirements for diverse use cases such as chain state queries, off-chain data reads, and verifiable randomness (VRF).

• Directives Standard Definition:

  • Formally define the encoding schema for directives ([directive_type, directive_name, directive_args]).

  • Specify extensibility options and trust customization mechanisms, ensuring that the system supports both centralized and decentralized Interchain Security Modules (ISMs).

• Architectural Blueprint:

  • Develop detailed design documents and system architecture diagrams covering smart contract templates/libraries, various example ISMs (centralized for price feeds; Chainlink-based for VRF; Hashi-based for foreign state queries), off-chain relayer infrastructure, and the node SDK.

• Deliverable: Publish the complete technical docs and architectural blueprint on GitHub as a reference for subsequent stages.

Phase 2 – Development of Smart Contract Templates & Prototype ISMs (Month 3–4: July 1 – August 31, 2025):

• On-Chain Component Development:

  • Implement an abstract oracle contract that can process Hyperlane messages encoded with directives.

  • Create and document an utility library to enable developers to interact seamlessly with the deployed oracle contracts for price feeds, foreign state reads, and VRF.

• Prototype ISMs:

  • Develop three prototype ISMs to demonstrate varied trust models:

    • A simple centralized ISM for handling price feeds.

    • A Chainlink-based ISM for delivering VRF and enhanced price feed security.

    • A Hashi-based ISM for secure foreign state read operations.

• Testing & Iteration:

  • Conduct unit and integration tests on a local/test network to validate directive parsing, execution, and response protocols.

• Deliverable: A working prototype that validates the core functionality of the directives framework, with documented tests and example implementations.

Phase 3 – Off-Chain Relayer & Node SDK Integration (Month 5–6: September 1 – October 31, 2025):

• Off-Chain Relayer Development:

  • Build robust relayer services that aggregate external data, encode it as directives, and dispatch messages via the Hyperlane protocol.

• Node SDK Development:

  • Develop a comprehensive Node SDK that facilitates the directive lifecycle—from encoding to relaying and decoding—making integration straightforward for developers.

• End-to-End Integration Testing:

  • Validate the full workflow across off-chain relayers, smart contracts, and ISMs on test networks by simulating real-world data feeds and cross-chain state requests.

• Documentation:

  • Release initial developer guides, integration examples, and sample projects to support the SDK and relayer setup.

• Deliverable: A complete integration of the off-chain and on-chain components demonstrating a seamless end-to-end directive workflow.

• Audit Preparation & Coordination (Overlapping Phase – Begins late Phase 3, completes in Phase 4):

  • Submit the codebase for an OP-sponsored audit, including smart contracts, ISMs, and relevant libraries.

  • Collaborate directly with auditors during the review process, supporting technical clarifications and implementing required fixes.

  • Ensure final audited code is production-ready and prepared for mainnet deployment.

Phase 4 – Mainnet Deployment & Comprehensive Documentation (Month 7–8: November 1 – December 31, 2025):

• Mainnet Deployment:

  • Deploy the production-ready smart contracts, ISMs, and relayer infrastructure on the OP Superchain mainnet.

• Complete Documentation:

  • Finalize and publish detailed tutorials, developer guides, and API reference materials covering the entire oracle system.

• Deliverable: A production-grade, fully documented oracle system live on mainnet with initial integrations demonstrating real-world use cases.

Please define the [critical milestone(s)](https://gov.optimism.io/t/collective-grant-policies/5833#p-25088-critical-milestones-and-clawback-8) that%C2%A0that) should be used to determine whether you’ve executed on this proposal:

• Milestone 1 – Directives Standard & Architectural Blueprint (By June 30, 2025):

  • Outcome: Publication of the technical whitepaper and complete architectural design on GitHub detailing the encoding schema, modular ISM options, and overall system architecture.

  • Significance: This milestone validates the conceptual foundation and ensures alignment on requirements before development commences.

• Milestone 2 – Prototype Smart Contracts & ISMs (By August 31, 2025):

  • Outcome: Delivery of an abstract oracle contract along with a utility library and three prototype ISMs (centralized, Chainlink-based, and Hashi-based) tested on a development network.

  • Significance: Demonstrates the viability of the directives framework and confirms that the core on-chain components are capable of processing and executing directives as expected.

• Milestone 3 – Integrated Off-Chain Relayer & Node SDK (By October 31, 2025):

  • Outcome: Successful integration and end-to-end testing of the off-chain relayer and the Node SDK with the on-chain modules, validated through simulated real-world data feeds and cross-chain executions on a test network.

  • Significance: Ensures that the full system—combining off-chain data aggregation, directive encoding, relaying, and on-chain processing—is robust and ready for scaling.

• Milestone 4 – Mainnet Deployment (By December 31, 2025):

  • Outcome: Full production deployment on the OP Superchain mainnet accompanied by complete, publicly available documentation, tutorials, and established early integrations with at least two projects.

  • Significance: Confirms the system’s operational readiness, ensures real-world applicability, and provides a solid foundation for further ecosystem growth and adoption.

Please list any additional support your team would require to execute this mission (financial, technical, etc.):

The audit cost is not included in the budget for this proposal. We expect it to be covered separately through Optimism-sponsored audit programs. However, we are fully committed to supporting the entire audit process, including technical iterations and direct coordination with the auditors.

Please check the following to make sure you understand the terms of the Optimism Foundation Mission program:

• I understand my grant for completing this Foundation Mission will be locked for one year from the date of proposal acceptance.
• I understand that I will be required to provide additional KYC information to the Optimism Foundation to receive this grant.
• I understand my locked grant may be clawed back for failure to execute on critical milestones, as outlined in the Collective Grant Policies.
• I confirm that I have read and understand the Collective Grant Policies.

[opmxwell]

Thanks everyone for the submissions! The applications are now closed and the team(s) will be selected by April 25th.

[kacperkozi]

Herodotus Interop Oracle Standards & Infra for OP Superchain Application

Please verify that your team members below:

• Team Lead: Kacper Koziol (Co-founder, Herodotus)
• Contact info: kacper@herodotus.dev
• L2 recipient address: 0x17C2D875CB397D813eAE817DaFD25807E348Df07

Please list the members of your team and link to any previous work:

• Kacper Koziol (Team Lead): Co-founder of Herodotus. Led previous Optimism grants and initiatives Herodotus was involved in.
  https://x.com/kacperkozi
• Marcello Bardus: Co-founder of Herodotus. Leads Herodotus's engineering, focusing on zero-knowledge proofs and protocol design. https://x.com/0xmarcello
• Bartosz Nowak: Head of Research at Herodotus, specializes in low-level cryptography and protocol research. He co-led the development of "Integrity," a STARK proof verifier written in Cairo, and developed "Swiftness," a Rust implementation of the Cairo-VM STARK verifier.
  https://x.com/bartolomeo_diaz
• Filip Krawczyk: Software Engineer at Herodotus, co-led the development of "Integrity" and contributes to smart contract development and protocol engineering at Herodotus.
  https://x.com/_fmkra
• The Herodotus team comprises experienced engineers and researchers specializing in cryptography (specifically ZKPs), distributed systems, protocol engineering and smart contract development.

Previous Relevant Work & Experience:

• Optimism Cycle 11 Grant – Storage Proofs Implementation: Herodotus received a Cycle 11 Optimism grant to develop Storage Proofs on Optimism. We successfully delivered, creating contracts allowing Optimism L2 to access Ethereum L1 data in a trustless manner. We generalized this solution to support all OP Stack chains (Optimism, Base, Zora, World Chain, etc.), making it essentially plug-and-play for any new OP chain. This gave us deep familiarity with Optimism’s architecture and the broader Superchain Ecosystem.
  • Grant Proposal & Discussion: https://gov.optimism.io/t/cycle-11-herodotus-storage-proofs/5630
  • Confirmation of Completion: https://gov.optimism.io/t/cycle-11-herodotus-storage-proofs/5630/15 (See comments confirming delivery for Snapshot X needs)
  • Open source L2 Indexer:
    https://github.com/HerodotusDev/L2-indexer
• Snapshot X Integration – Cross-Chain Governance: We collaborated with Snapshot Labs to integrate Storage Proofs into Snapshot X, their onchain voting protocol. This enables verification of token balances/state across chains for governance (e.g., L1 tokens voting on L2) without bridging assets, maintaining trustlessness. So far this was implemented in production on Starknet, and mainnet support for OP Stack is actively under development as part of a Season 6 Mission grant with Snapshot Labs.
  • Season 6 Mission Application (with Snapshot): https://gov.optimism.io/t/mission-request-cross-chain-voting/8517/6
  • Snapshot X onchain voting Info: https://snapshot.mirror.xyz/F0wSmh8LROHhLYGQ7VG6VEG1_L8_IQk8eC9U7gFwep0
• Worldcoin (World Chain) Integration & Grant: In Q1 2024, Herodotus was included as one of World Chain’s launch partners and we were selected as Worldcoin Foundation Wave 1 Grant recipients to bring Storage Proofs to World Chain (OP Stack). We built a solution named Turbo which is a “data access middleware” giving World Chain contracts synchronous access to Ethereum (and other chain) data via Storage Proofs.
  • Announcement: https://world.org/blog/announcements/meet-worldcoin-wave1-community-grants-recipients
  • Grant Recipient Page:
    https://world.org/grant-recipients/wave1/herodotus
• OP Stack Research: Our team has been actively researching ways to improve OP Stack interoperability, and have authored research on a “Reputation-Centric Light Client Framework for Optimistic Rollups,” exploring faster finality for cross-chain reads while acknowledging challenges like the fraud proof window.
  • EthResearch Post: https://ethresear.ch/t/reputation-centric-light-client-framework-for-optimistic-rollups/19988

What makes your team best-suited to execute this Mission?

Herodotus combines practical experience (previously having completed several codebase audits and successful integrations) with deep domain knowledge in zero-knowledge proofs and operating critical protocol infrastructure in production environments. Our team has been a leader in Storage Proofs, zk-coprocessors, and provable cross-chain communication infrastructure. We have delivered on Optimism grants before, integrated with major platforms like Snapshot, and been recognized by external ecosystems (Worldcoin). We approach this mission with a strong foundation of relevant work and a passion for advancing the Superchain vision of seamless interoperability.

• Core Technology & Trust Model:
  Our core technology, Storage Proofs, directly addresses the mission's goal of enabling "trustless, cheap, and fast cross-chain data reads." Unlike solutions relying on separate consensus/messaging protocols or hardware-based trust (like TEEs), Storage Proofs cryptographically verify the provenance of on-chain data using only the source chain's consensus security and native Superchain messaging for relaying block headers. This offers a maximally trust-minimized model aligned with Web3 principles, relying purely on on-chain data and established cryptographic primitives.
• Proven Delivery & Operational Infrastructure: We are not proposing a research project; we're extending a working system. Our core Storage Proofs infrastructure is operational on OP Stack testnets (Optimism Sepolia, World Chain Sepolia) and Ethereum Mainnet. Support for chains like Zora and Base was previously added, as can be seen in the L2 Indexer README, but requires some updates to become operational again. Our successful completion of the Cycle 11 grant and ongoing Season 6 work with Snapshot demonstrate our reliability and long-term commitment to the Superchain ecosystem.
• OP Stack & Superchain Experience: Our prior work required deep integration with OP Stack specifics, including generalizing our solution to be "plug-and-play" for new OP chains. Our system is designed to leverage Superchain-native messaging efficiently, fitting naturally into the intended architecture.
• Standardization & Integration Expertise: Through our work on Storage Proofs and collaborations like Snapshot X, we have practical experience in designing secure cross-chain protocols and contributing to standards for data access.
• Clear Adoption Pathway: Our ongoing collaboration with Snapshot Labs provides a direct and immediate pathway for adopting the developed interop oracle standards within the significant governance market segment on the Superchain, serving as a powerful blueprint for broader ecosystem adoption.

In summary, we combine battle-tested technology, practical deployment experience on OP Stack, relevant research insights, and a clear path to impactful adoption, making us the ideal team to deliver this critical infrastructure for the Superchain.

Please describe your proposed solution based on the above Solution Criteria (if applicable):

We propose to design and implement a comprehensive Interop Oracle Standard for the OP Superchain, along with the necessary contracts and infrastructure to make it easy for any OP Stack chain to adopt. The standard will leverage our existing work on Storage Proofs to empower developers and users to seamlessly move information (not just tokens) across OP Chains with the same security assurances as the underlying chains.

• Define Interop Oracle Standards:
  We will author a proposal for an Interop Oracle Standard specifying interfaces and processes for inter-chain state proofs. This will define a common format for submitting and verifying Storage Proofs on OP Chains, ensuring any chain adopting the standard can act as either a source or destination of cross-chain state queries.

  • Deliverable: A detailed specification document defining:
    • Request Formats: Standardized way to request specific state proofs (chain ID, block ID, contract, slot/key).
    • Proof Formats: Efficient serialization for Storage Proofs (Merkle Mountain Ranges, Merkle Patricia Tries).
    • Verification Interfaces: Standard on-chain interfaces (e.g., verifier contracts) for validating proofs against state roots.
    • Header Relay: Procedures for securely relaying source chain block headers via Superchain-native messaging.
    • Security Model: Clear documentation of trust assumptions (L1/L2 security, native bridge security, cryptography).
      We will ensure flexibility (handling balances, NFTs, arbitrary storage) and gas efficiency. The draft standard will be shared publicly for community feedback.

• Develop Smart Contract Templates:
  We will develop modular, production-ready smart contract templates implementing the standard.

  • Deliverable: A suite of smart contracts in a public repository, including:
    • Core Contracts: contracts for data ingestion (requesting proofs), verification (validating Storage Proofs against headers received via native messaging), and cross-chain reads of any state variable.
    • Use Case Examples: Specific, well-documented examples built on core templates for:
      • Superchain data fetching: Retrieving and storing of block hashes for any chain in a secure way.
      • Price Feeds: Demonstrating fetching token prices cross-chain (e.g., Uniswap V2 asset pair price).
      • State Reads: Accessing arbitrary contract state or account balances cross-chain (e.g., Accessing Optimism state from World Chain).
      • Advanced Use Cases (Compute/RNG/ZK): While the core protocol reads existing state, we will provide guidance and potentially example interfaces showing how data fetched via Storage Proofs can be consumed by systems like our Herodotus Data Processor (HDP) for off-chain computation, ZKP generation/verification, or even generating pseudo-randomness based on verified cross-chain entropy sources, addressing the full scope of examples mentioned in the mission request.

• Build Infrastructure & Tools:

  We will provide essential off-chain infrastructure (Indexer/Prover) and developer tools, leveraging our existing Herodotus API services.

  • Deliverable:
    • Indexer Service: Extend our existing Herodotus Indexer to support monitoring popular Superchains and maintain updated state roots/proof components.
    • API: User-friendly API abstracting proof generation and on-chain verification calls, available via Herodotus Cloud.

• Provide Documentation & Developer Guides:

  Comprehensive documentation is key for adoption.

  • Deliverable: Publicly available documentation including:
    • Protocol Specification: Detailed explanation of the standard, proof construction, and contract logic.
    • Integration Guides: Step-by-step tutorials for developers and OP Chain teams (e.g., "How to verify balance of an account from one OP Stack chain on another").
    • Reference Implementations: Sample code and potentially demo applications.
    • API Documentation: Thorough guides for using off-chain services and libraries.
      We will conduct recorded workshops/presentations for community education at the end of the mission.

• Go-to-Market Plan / Adoption & Ecosystem Integration:

  Our plan aligns with the mission's request: Define standards -> Build contracts/infra -> Release tools/docs -> Onboard providers/projects.

  • Strategy:
    • Snapshot X Integration: Leverage our existing partnership to implement the standards use for cross-chain governance, providing immediate value and visibility.
    • Ecosystem Outreach: Engage other OP Stack projects to encourage pilot integrations (multi-chain NFTs, Superchain bridges, etc.).
  • Deliverable:
    To meet the Foundation’s expectations of real-world impact, we will actively pursue the adoption of the oracle standard across the Superchain. Our goal is that by the end of the mission, at least 3 OP chains will have support for the interop oracle standard and at least 3 Superchain projects are using it on mainnet.
    Success will be measured by the number of chains/integrations adopting the standard, aiming to establish this as the most secure and widely used method for trustless state reads across the Superchain.

Please outline your step-by-step plan to execute this Mission, including expected deadlines to complete each piece of work:

We provide a phased timeline with clear milestones to ensure timely delivery and alignment with the Foundation’s expectations. We are ready to begin immediately upon approval and estimate a 10-month timeline for full completion, with deliverables released incrementally:

• Month 1-4: Research & Specification: Research and finalize the requirements/design for the Interop Oracle Standard. This includes reviewing Optimism’s latest interop architecture (e.g. any native message-passing developments), writing an initial spec, gathering feedback from OP Labs and other stakeholders, and sourcing feedback from the developer community on the Optimism forum. Refine based on feedback.
• Month 5-6: Prototype Contracts & Infra: Implement a first iteration of the core smart contracts. Simultaneously, adapt the existing Herodotus indexer to support any new data required for OP Chains (e.g. if not already supported), and ensure it follows the standard. This will validate our approach early, demonstrate its developer ux, and leave room for adjustments if needed.
• Month 7-8: Testing & Refinement: Test the system across multiple scenarios: different chains, various data types (ERC20 balances, ERC721 ownership, arbitrary storage). Test smart contract templates and fix any bugs or performance issues.
• Month 9: Deployment & Documentation: Deploy the oracle contracts on Optimism Mainnet and one or two other popular OP chains (likely World Chain Mainnet or another popular Superchain) as an initial rollout. Publish all documentation (developer docs, integration examples, API usage) and conduct a community workshop/feedback session to collect feedback and walk through the deployment.
• Month 10: Adoption Push & Handover: Work closely with partner teams (Snapshot, and other OP chains’ dev teams) to integrate the standard into live applications. For example, assist Snapshot Labs in using the oracle standard for a governance trial on Optimism, or help an OP chain project implement a cross-chain feature using our infra. Gather basic usage metrics and testimonials. By mid-month, prepare a final report for the Foundation detailing the work completed, including links to the spec, code, docs, and evidence of adoption.

We believe this timeline is realistic and accounts for the critical path (spec → prototype → audit → deploy → adopt). If selected, we will remain communicative on our development, providing updates on GitHub and/or the Optimism forum.

Please define the critical milestone(s) that should be used to determine whether you’ve executed on this proposal:

1. Publish the Interop Oracle Standard Draft (by end of Month 3).
   • Deliverable: Publicly accessible specification draft detailing architecture, security, formats, interfaces, and messaging procedures, incorporating initial feedback.
2. Develop smart contract templates implementing the standard and deploy a demo (e.g. on Optimism Sepolia) demonstrating one chain verifying state from another using a basic UI or script (by end of Month 6).
   • Deliverable: Functioning deployment on Superchain Devnet/Testnet demonstrating state read between two OP chains using prototype contracts (core + examples like price feed) and basic tooling. Public testnet addresses & repositories provided.
3. Mainnet deployment on Optimism Mainnet and two other popular OP chains with full documentation available (by end of Month 9).
   • Deliverable: Smart contracts deployed on Optimism Mainnet and at least two other OP Superchains. Public release of final documentation & guides.
4. Mission Completion (end of Month 10) with at least 3 chain deployments, and publishing a final report on the optimism forum detailing the work completed, including links to the spec, code, and docs.
   • Deliverable: Final report published, demonstrating successful mainnet deployments and initial adoption efforts (e.g., Snapshot X integration progress).

Please list any additional support your team would require to execute this mission (financial, technical, etc.):

• Financial: The 154k OP grant as specified in the Mission Request to fund the team working on the mission. (Note: Security audit costs are assumed to be potentially covered by separate Optimism programs. If not covered, additional funding specifically for the audit might be required.)
• Non-Technical: Support in connecting with OP Chain teams and potential pilot partners once we get to month 8 of the mission.

Please check the following to make sure you understand the terms of the Optimism Foundation Mission program:

• I understand my grant for completing this Foundation Mission will be locked for one year from the date of proposal acceptance.
• I understand that I will be required to provide additional KYC information to the Optimism Foundation to receive this grant
• I understand my locked grant may be clawed back for failure to execute on critical milestones, as outlined in the Collective Grant Policies
• I confirm that I have read and understand the Collective Grant Policies

[opmxwell]

Upon examination, none of the above applications have been chosen by the Developer Advisory Board.

The deadline will now be extended and applications will re-open for this Mission for another week.

The application deadline is now Tuesday, May 6th at 19:00 GMT. Any applications submitted before this deadline will be considered, thank you!

[chiro-hiro]

Upon examination, none of the above applications have been chosen by the Developer Advisory Board.

The deadline will now be extended and applications will re-open for this Mission for another week.

The application deadline is now Tuesday, May 6th at 19:00 GMT. Any applications submitted before this deadline will be considered, thank you!

I'm willing to have your comments and criticizations, it would be great to transparent the review process to the community.