---
sidebar_position: 1
slug: overview
title: FDC
authors: [lukaavbreht, filipkoprivec]
description: The Flare Data Connector (FDC) enables secure, onchain attestation of external data.
tags: [intermediate, ethereum, fdc]
keywords: [flare-fdc, ethereum, flare-data-connector, evm, flare-network]
unlisted: false
---

import ThemedImage from "@theme/ThemedImage";
import useBaseUrl from "@docusaurus/useBaseUrl";
import YouTubeEmbed from "@site/src/components/YouTubeEmbed";

The **F**lare **D**ata **C**onnector (FDC) is an [enshrined oracle](/support/terminology#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.

## Key Features

- **Network-Level Security**: Data attestation requires reaching a 50%+ signature weight from data providers, ensuring decentralized consensus.
- **Efficient Onchain Storage**: Verified data is stored in a Merkle tree, with only the Merkle root stored onchain to minimize costs.
- **Easy Offchain Accessibility**: Data providers serve attestation responses and Merkle proofs offchain through a Data Availability (DA) Layer, ensuring efficient data retrieval.
- **Proof-Based Verification**: Smart contracts validate Merkle proofs against the stored Merkle root, ensuring only authentic data triggers contract actions.
- **Extensible Attestation Types**: New attestation types and data sources can be added through provider consensus, ensuring adaptability.
- **Current State**: A proof can only be constructed for current states (transactions, API responses...), where a current state is a state no older than 14 days.
- **Proof Availability**: Once the proof is constructed it remains available indefinitely.
- **Security**: Although bitvoting information is public, it is insufficient to construct the Merkle proof without doing the verification work.

## Architecture

<ThemedImage
  alt="FDC Architecture Diagram"
  sources={{
    light: useBaseUrl("img/docs/fdc/overview/fdc-architecture.light.svg"),
    dark: useBaseUrl("img/docs/fdc/overview/fdc-architecture.dark.svg"),
  }}
/>

1. **Data Verification**: The FDC verifies user-submitted attestation requests.
2. **Merkle Representation**: Verified responses are organized into a Merkle tree, with only the Merkle root stored onchain.
3. **Attestation Usage**: Users retrieve attestation responses and Merkle proofs from data providers and submit them to smart contracts.

:::tip[Interested in learning more?]
For a detailed explanation of the FDC mechanism, read the [FDC whitepaper](/pdf/whitepapers/20240224-FlareDataConnector.pdf).
:::

### Data Availability Layer

The Data Availability Layer (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 onchain version.

Operating a DA Layer is permissionless—anyone can run a DA Layer service by sourcing data from an [Flare Entity](/run-node/flare-entity).

<ThemedImage
  alt="DA Layer Diagram"
  sources={{
    light: useBaseUrl("img/docs/fdc/overview/da-layer.light.svg"),
    dark: useBaseUrl("img/docs/fdc/overview/da-layer.dark.svg"),
  }}
/>

## Attestation Types

FDC currently supports seven attestation types, each serving specific verification needs. Below is an overview of these types, with detailed explanations available in their respective sections:

- **AddressValidity**: Validates the format and checksum of addresses on specified chains.
- **EVMTransaction**: Verifies and retrieves transaction details from EVM-compatible chains (`ETH`, `FLR`, `SGB`).
- **JsonApi**: Fetches and processes any Web2 data using a JQ transformation, then returns it as ABI-encoded output. (Currently only on Coston & Coston2).
- **Payment**: Confirms and fetches payment transaction details from non-EVM chains (`BTC`, `DOGE`, `XRP`).
- **ConfirmedBlockHeightExists**: Verifies block existence and confirmation status.
- **BalanceDecreasingTransaction**: Validates if a transaction reduces an address's balance.
- **ReferencedPaymentNonexistence**: Confirms the absence of specific payments within time intervals.

The first three attestation types are the most generally useful, while the last three are primarily used in **FAssets**.

## Workflow Overview

For all attestation types, the workflow follows the same general steps.
Due to the waiting period between steps **2** and **3**, where the round is finalized, the process is split into multiple sections.

### General Workflow

1. **Request Submission**: Users submit attestation requests to the [`FdcHub`](/fdc/reference/IFdcHub) smart contract.
2. **Batch Processing**: Data providers group requests based on 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`](/network/fsp/solidity-reference/IRelay) 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

<ThemedImage
  alt="User Workflow Diagram"
  sources={{
    light: useBaseUrl("img/docs/fdc/overview/user-workflow.light.svg"),
    dark: useBaseUrl("img/docs/fdc/overview/user-workflow.dark.svg"),
  }}
/>

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`](/fdc/reference/IFdcHub#requestattestation) from `FdcHub` and pay the required fee.
4. **Track Submission**: Record the block timestamp and calculate the voting round.
5. **Wait for Finalization**: The voting round concludes, and 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**: Establish data-driven triggers.
2. **Receive Data**: Accept attestation responses and proofs from users.
3. **Verify Proofs**: Use the [`FdcVerification`](/fdc/reference/IFdcVerification) contract to validate the response against the Merkle root.
4. **Act on Data**: Utilize the verified data for computation or decision-making.

### 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**: Construct a Merkle tree from validated responses.
7. **Sign and Submit**: Collect signatures representing 50%+ weight and submit the Merkle root to the [`Relay`](/network/fsp/solidity-reference/IRelay) contract.
8. **Serve Data**: Provide attestation responses and proofs via the DA Layer.

The **Flare Data Connector (FDC)** is a critical infrastructure component for the Flare ecosystem, enabling smart contracts to access **secure, attested external data** while maintaining trustless verification through **Merkle proofs**. By integrating the FDC, developers can create more **reliable, decentralized applications** across multiple blockchains.

## Watch the video

<YouTubeEmbed videoId="4mAT1v8gZMQ"></YouTubeEmbed>
