14. RandProof Oracle: General Data Attestation

RandProof’s entropy pipeline (Section 7) already solves a narrower version of this problem: multiple keepers independently fetch the same external sou

[Layer 1: Core, Design Stage]

RandProof’s entropy pipeline (Section 7) already solves a narrower version of this problem: multiple keepers independently fetch the same external source, such as DRAND or NIST, and disagreement is treated as a fraud signal rather than guessed at. RandProof Oracle generalizes that exact mechanism from entropy sources specifically to arbitrary external data: prices, sports outcomes, weather conditions, shipment tracking status, or any other fact a contract needs but cannot observe directly on-chain. The fetch-compare-attest loop does not change; what changes is that the data source becomes a parameter a client declares, rather than a fixed list of entropy providers RandProof maintains itself.

14.1 Why This Belongs in RandProof, Not as a Separate Build

Multi-source external data verification is not new infrastructure for RandProof; it is the existing entropy-source attestation pattern (Section 7.1, AV-108 through AV-111) with the data source field generalized. The same keeper rotation, the same multi-keeper attestation and 2-of-3 (or N-of-M) agreement logic, and the same fraud-proof challenge window already specified for entropy sources apply unchanged. RandProof Oracle is positioned as its own named product, rather than folded silently into Section 7, because its market, general DeFi price feeds and external data, not entropy specifically, is large enough and distinct enough to warrant separate documentation, separate keeper economics, and separate adoption messaging.

14.2 Execution Flow


Phase	Description
1. Feed Registration	A client registers a DataFeedRequest: source_spec (the external API or data source to query), query_params, update_interval or on-demand trigger, min_keepers, and fee_usdc.
2. Independent Fetch	N assigned keepers independently query the declared source. As with entropy sources, keepers cannot coordinate their fetch in advance, since the rotation assigning them is VRF-seeded (Section 7, KeeperCoordinator).
3. Commit-Reveal	Each keeper commits keccak256(fetched_value plus keeper_secret), then reveals. This mirrors the existing entropy commit-reveal flow exactly.
4. Consensus and Publication	If min_keepers reveals agree within a configured tolerance (exact match for discrete data such as a sports score; a percentage band for continuous data such as a price), the value is published on-chain as the feed’s current attested reading. Disagreement triggers the existing fraud-proof challenge window and keeper slashing logic (Section 7.1).

14.3 Feed Types

Discrete-value feeds: sports outcomes, election results, binary event resolutions. Consensus requires exact match across keeper reveals, identical in structure to entropy-source agreement.
Continuous-value feeds: prices, exchange rates, weather measurements. Consensus uses a tolerance band rather than exact match, since independently-timed API calls to the same price source can return slightly different values within milliseconds of each other.
Status feeds: shipment tracking, KYC verification status, document-signature confirmation. Consensus requires exact match on a status enum returned by the declared source.

14.4 Threat Model


Threat	Mitigation
A single source is compromised or returns manipulated data	Multi-keeper independent fetch means manipulation must occur at the source itself, not at any individual keeper; if the source is compromised, this is disclosed as a source-level risk identical to the existing entropy-source disclosure model (Section 7.1), not a RandProof Oracle-specific vulnerability.
A keeper fabricates a fetch result	Identical protection to the existing entropy fraud-proof system: a keeper’s fabricated value will not match independently-fetched honest values, triggering the challenge window and slashing.
Source unavailability or rate-limiting	Feed requests specify a max_latency_ms; if insufficient keepers can fetch within that window, the request fails explicitly rather than publishing a stale or partial consensus.
Tolerance-band gaming on continuous feeds	The tolerance band is set per feed at registration and disclosed to consumers, so a client can choose a tighter band for high-value use cases (e.g., liquidation triggers) and a looser band for lower-stakes use cases.

14.5 Keeper Economics

Per-fetch fee: paid to participating keepers on successful consensus, split N ways, structurally identical to entropy-source keeper compensation.
Recurring feed subscription: clients needing a continuously updated feed (e.g., a price feed updated every block or every N seconds) pay an ongoing fee rather than a one-time per-request fee, the same economic shape as existing oracle network subscription pricing.

14.6 Use Cases

[Layer 3] DeFi protocols requiring price feeds for collateral valuation, liquidation triggers, and AMM pricing, RandProof Oracle’s direct competitive target against existing centralized-operator oracle networks.
[Layer 3] Parametric insurance products requiring weather, flight-delay, or other real-world event data to trigger payouts.
[Layer 3] Prediction markets requiring outcome resolution data for binary or categorical events.
[Layer 2] BIT5050 raffle contracts requiring external data for entry validation or dynamic prize valuation, a natural genesis client for proving this product against real production traffic before broader Layer 3 adoption.

14.7 Honest Status

RandProof Oracle is an architectural extension of the existing, tested entropy-source attestation pattern (EntropyAttestation.sol v3, AV-108 through AV-111) to a generalized data-source parameter. The underlying commit-reveal-consensus mechanism is implemented and tested for entropy sources specifically; the generalized DataFeedRequest interface and the tolerance-band logic for continuous-value feeds have not yet been implemented or audited as their own contract.