FDC is best understood as a request-based attestation protocol, not as a simple recurring price-feed oracle.
The request format is unusually important: each request includes an attestation type, a source identifier, a message integrity code derived from the expected response, and a fee. That makes request authorship and response-shape commitment part of the mechanism itself.
Provider disagreement is treated as a first-class protocol problem. The bit-vote process exists specifically because some requests are unstable or only partially observable across providers, so the system needs a deterministic way to choose a canonical subset for the round.
The output model is also layered very explicitly: confirmed response hashes go into a Merkle tree, only the root is published onchain, and full responses plus proofs are fetched from a DA layer later.
The FDC client README is useful because it shows the live operator surface: C-Chain indexing, round assignment, verifier-server queues, DA endpoints, ABI config, and source-specific verifier infrastructure.
The official docs emphasize that the system is enshrined into Flare rather than bolted on as an external middleware network. That matters for comparison work because the trust and governance surfaces are tied to Flare’s own provider and relay system.
Specific source signals worth retaining
fdc/overview: best high-level map of the architecture, including the 50%+ signature threshold, Merkle-root publication, DA-layer proof serving, and current attestation-type set.
Introduction.md: strongest concise statement of FDC’s role as attesting to data external to Flare’s EVM state and using the same provider consensus as the network itself.
MakingRequest.md: most important source for mechanism analysis because it defines attestation requests, MIC construction, fee policy, LUT rules, and attestation-hash generation.
BitVote.md: the clearest source on the real bottleneck when providers disagree. It shows that subset selection and optimization over fee/support are core parts of the protocol, not operational afterthoughts.
fdc-client/README.md: useful because it exposes practical operator dependencies like verifier URLs, queues, C-chain indexing, contract addresses, and DA / FSP server endpoints.
Why this entry belongs in the corpus
It adds an enshrined attestation architecture that is neither a plain feed oracle nor a generic bridge proof.
It strengthens the oracle-and-attestation cluster by making request commitment, subset selection, and offchain proof delivery explicit comparison layers.
The durable insight is that FDC is best analyzed as a canonical-request and proof-delivery system for external facts, not just as another source of onchain data.