How to Read This Document: Three Layers

RandProof is decentralized infrastructure: a bonded, slashable keeper network that turns “can I trust what one party reports” into an on-chain, verifiable fact. That core capability now spans randomness, automation, off-chain computation, external data, identity signals, continuous monitoring, and reserve verification, usable by any contract, on any of the 17-plus chains RandProof operates on, regardless of industry. This section lays out three layers so a reader can tell, at every point in the document, whether they are looking at the protocol itself, a specific production deployment of it, or the broader market it is built to serve.

0.1 Layer 1: RandProof Core

The protocol itself: EntropyAttestation, KeeperCoordinator, RandProofAutomation, RandProofCompute, RandProof Sentinel, RandProof Forge, RandProof Oracle, RandProof Identity, RandProof Audit, and RandProof Custody Proof, plus the keeper network that operates all of them. Layer 1 contracts carry no industry-specific or client-specific logic and no awareness of who is calling them. A lending protocol, a DAO, an AI inference marketplace, and a raffle contract all look identical to Layer 1: each is simply a client. Every audit finding, every test count, and every gas benchmark in this document is a Layer 1 claim, describing the protocol’s own correctness independent of any single customer.

The test for whether something belongs in Layer 1: could any party, with no prior relationship to RandProof’s team, integrate it tomorrow and get value, without writing or depending on industry-specific code? If yes, it is Core.

0.2 Layer 2: Production Deployments

Layer 2 is real-world usage of Layer 1: specific products, on specific chains, generating specific demand. The first and largest such deployment is BIT5050, a multi-chain Web3 raffle ecosystem spanning 17-plus chains, which is RandProof’s genesis client and the workload Layer 1 was originally built and tested against. Where this document describes a reference implementation tied to a named production deployment, such as a settlement-automation chain or an inference-verification use case, that is Layer 2 content: a specific client’s integration of Layer 1, not part of Layer 1 itself.

Layer 2 exists in this document for one reason: to demonstrate that Layer 1 has been proven against real production traffic, not built and shipped untested. Any future production deployment, whether built by RandProof’s own team or by an external integrator, occupies the same position in this layer that BIT5050 does today.

The test for whether something belongs in Layer 2: is this a specific client’s business logic that happens to call into Layer 1? If yes, it belongs here, not inside a Core contract.

0.3 Layer 3: General Market

Layer 3 is everything Layer 1 can serve beyond its first production client: DeFi liquidation triggers, DAO governance execution, subscription billing, AI inference marketplaces, supply-chain verification, identity and Sybil-resistance signals for agent networks, continuous protocol-safety monitoring, and reserve attestation for tokenized assets, among others. This is the layer the protocol is built for at scale, and it is the layer this document’s positioning is ultimately addressed to: developers and companies, in Web3, in AI infrastructure, and in conventional business, evaluating RandProof as infrastructure for their own product, independent of any other client’s use of it.

The test for whether something belongs in Layer 3: does this use case have no dependency on any specific Layer 2 deployment? If yes, it belongs here.

0.4 Why the Distinction Matters

• Credibility for new integrators: a protocol’s existing audit findings and test coverage are Layer 1 claims, true regardless of who is asking, and credible precisely because they were proven against a real production client rather than built in a vacuum.

• Security posture: Layer 1 contracts must hold up against any Layer 3 adopter, including ones with no relationship to RandProof and every incentive to find an exploit. A specific Layer 2 integration, where both sides of the integration are controlled by the same team, can reasonably be evaluated under a different operational bar.

• Reading clarity: a developer evaluating RandProof for a lending protocol, a DAO, or an AI inference pipeline should be able to find Layer 1 and Layer 3 content without first wading through any single client’s specific integration details.

0.5 Layer Tags Used in This Document

From Section 7 onward, subsections describing a specific product capability are labeled with the layer they belong to, in brackets at the start of the subsection: [Layer 1: Core], [Layer 2: Production Deployment], or [Layer 3: General Market]. A product that is specified as a design but not yet implemented additionally carries a Design Stage marker (for example, [Layer 1: Core, Design Stage]), so a reader can tell shipped infrastructure from design-stage products at a glance rather than only from each section’s closing status note. Sections describing shared protocol mechanics that apply identically across all three layers, such as keeper economics or threat models, are left untagged, since they apply regardless of which layer a given use case sits in.

0.6 How to Integrate

This subsection is a practical entry point for three distinct audiences: developers and companies integrating a RandProof product into an existing contract or business process, AI companies and infrastructure providers evaluating RandProof’s verification and compute layers specifically, and prospective keeper operators evaluating whether to run RandProof infrastructure themselves. Each path is summarized below; the referenced sections contain full technical detail.

For Developers and Companies: Integrating a Product

Integration follows the same four steps regardless of which RandProof product is being used.

For AI Companies and Infrastructure Providers

RandProof’s relevance to AI infrastructure specifically falls into two categories, and most evaluators will only need one.

• Verifying inference you already run or buy: RandProof Forge (Section 13) and the underlying PoIF and PoRC certificate types (Sections 13.3, 13.4) attest that a claimed model produced a claimed output, independently confirmed by a bonded keeper set. This applies whether the inference runs on RandProof’s own keeper hardware (Forge Native) or on external infrastructure RandProof verifies without controlling (Forge Routed, Section 13.6).

• Sourcing verified compute or contributing capacity: a compute agent with available GPU capacity can register as a RandProofCompute agent (Section 11) and earn fees for serving requests, subject to the existing stake and challenge-window rules; this is the supply side of the same marketplace AI companies consume from on the demand side.

• Sybil-resistant agent reputation: AI agent operators building on ERC-8004 registries can integrate RandProof Identity (Section 15) to attest counterparty trust signals before an autonomous agent transacts with another, without requiring a centralized identity authority.

For Prospective Keeper Operators

Running RandProof infrastructure is a distinct role from integrating it: a keeper operator provides the hardware and stake that make every product in this document possible, and earns fees for doing so. Hardware requirements scale by which products an operator chooses to support, from lightweight nodes sufficient for randomness attestation and automation watching, up to GPU-equipped nodes capable of serving RandProofCompute and Forge requests. Full setup and economics are covered in the Node Operator sections of this document (Sections 19 through 20, and the complete deployment runbook in Section 30).

What Integration Does Not Require

• No RandProof token purchase or holding requirement to integrate any product as a client.

• No migration of existing contract logic beyond the specific function calls being replaced, for products offered as compatible drop-in replacements.

• No relationship with BIT5050 or any other existing production deployment; every Layer 1 product is designed to be integrated independently, per the Layer 1 test defined in Section 0.1.