Skip to main content

FDC

The Flare Data Connector (FDC) is an enshrined oracle designed to validate external data for Flare's EVM state. It allows users to submit attested data that smart contracts can trust, eliminating the need for direct reliance on users for data integrity.

  • Network-level security: Data attestation requires reaching a 50%+ signature weight from data providers, ensuring decentralized consensus.
  • Efficient onchain storage: Verified data is represented in a Merkle tree, with only the Merkle root stored on-chain. This minimizes storage costs while preserving data integrity.
  • Easy offchain accessibility: Data providers serve attestation responses and Merkle proofs offchain through a Data Availability (DA) Layer, enabling efficient data retrieval without sacrificing trust.
  • Proof-based verification: Smart contracts validate Merkle proofs against the stored Merkle root, ensuring that only authentic data can trigger contract actions.
  • Extensible attestation types: Support for new attestation types and data sources can be added through provider consensus, ensuring the FDC remains adaptable to evolving data needs.

Architecture​

FDC Architecture DiagramFDC Architecture Diagram
  1. Data Verification: The FDC verifies user-submitted attestation requests.
  2. Merkle Representation: Verified responses are organized into a Merkle tree. Only the Merkle root is stored on-chain.
  3. Attestation Usage: Users retrieve attestation responses and Merkle proofs from data providers and submit them to smart contracts.
Interested in learning more?

For a detailed explanation of the FDC mechanism, read the FDC whitepaper.

Data Availability Layer​

The Data Availability (DA) Layer provides API endpoints for querying offchain attestation data. Accessing this data is trustless, as users can independently compute and compare Merkle roots against the on-chain version.

Operating a DA Layer is permissionless, Anyone can run a DA Layer service by sourcing data from an FTSOv2 data provider and FDC attestation provider.

FTSO Price ComparisonFTSO Price Comparison

Workflows Overview​

General Workflow​

  1. Request Submission: Users submit requests to the FdcHub smart contract.
  2. Batch Processing: Data providers group requests by emission timestamps.
  3. Data Retrieval: Providers fetch and format responses, creating a Merkle tree of hashed responses.
  4. Consensus Storage: Once signatures representing 50%+ weight are collected, the Merkle root is submitted to the Relay contract.
  5. Proof Retrieval: Users fetch attestation responses and proofs from the DA Layer.
  6. Verification and Action: Smart contracts verify proofs and use the attested data if valid.

User Workflow​

  1. Identify Data Needs: Determine the required attestation type and data source.
  2. Prepare Request: Format the request with the expected response hash (MIC).
  3. Submit Request: Use requestAttestation from FdcHub and pay the base fee (fee varies by attestation type).
  4. Track Submission: Record the block timestamp and calculate the voting round.
  5. Wait for Finalization: Wait for the voting round to conclude. A relay contract event signals finalization.
  6. Fetch Data: Retrieve responses and proofs from the DA Layer.
  7. Submit to Smart Contract: Provide responses and proofs for verification.

Smart Contract Workflow​

  1. Define Triggers: Define data events that trigger specific actions.
  2. Receive Data: Accept responses and proofs from users.
  3. Verify Proofs: Use the FdcVerification contract to validate the response against the Merkle root.
  4. Act on Data: Use the verified data for decision-making or computation.

Data Provider Workflow​

  1. Collect Requests: Group requests by emission timestamps.
  2. Retrieve Data: Fetch responses from verifier servers.
  3. Validate Responses: Ensure data validity using MIC and LUT checks.
  4. Submit BitVectors: Indicate valid requests using BitVectors during the "choose phase" (90-135 seconds into the round).
  5. Achieve Consensus: Aggregate BitVectors to form a consensus BitVector.
  6. Create Merkle Tree: Build a Merkle tree from validated responses.
  7. Sign and Submit: Collect signatures representing 50%+ weight and submit the Merkle root to the Relay contract.
  8. Serve Data: Provide attestation responses and proofs through the DA Layer.