13. RandProof Forge: Verified Multi-Backend Compute

RandProofCompute (Section 11) already defines the core off-chain computation primitive: a client submits a ComputeRequest, a compute agent executes of

[Layer 1: Core]

RandProofCompute (Section 11) already defines the core off-chain computation primitive: a client submits a ComputeRequest, a compute agent executes off-chain and submits a ComputeResult, a 24-hour challenge window allows other agents to dispute, and the agent earns its fee once the window closes without a successful challenge. RandProof Forge is the next evolution of that primitive, extending it in two directions Section 11 leaves open: which backend actually executes the computation, and what certificate type is possible to issue once it has.

Forge does not replace RandProofCompute. Every Forge request is, underneath, a RandProofCompute ComputeRequest; Forge adds a backend-routing layer and a model-fidelity certificate format on top of the existing submit-challenge-finalize lifecycle Section 11 already specifies.

13.1 The Gap Forge Closes

Section 11’s compute agents are, in practice, RandProof’s own keeper operators, the same Tier 2 and Tier 3 nodes already running entropy attestation and automation duties. This works for any computation a keeper can run locally, which is most of the listed use cases in Section 11: weighted randomness algorithms, DeFi risk calculations, DAO proposal impact modeling, compliance report generation. It does not extend to two cases Section 11 does not address: AI models too large for any single keeper to host, and proprietary AI models with no available weights for any keeper to run at all. Forge introduces the routing and certificate logic needed to serve both, without changing the underlying ComputeRequest and challenge-window mechanics Section 11 already specifies and that RandProofCompute’s existing stake and slashing rules already govern.

13.2 Two Execution Tiers


Tier	Definition
Forge Native	Execution occurs on RandProof’s own keeper hardware, the same compute agents already defined in Section 11. Scoped to models small enough for a single keeper to host locally.
Forge Routed	Execution occurs on external backends RandProof does not control: other decentralized compute networks, coalitions of keepers each holding one shard of a too-large model, or closed proprietary APIs. RandProof’s keeper network verifies or attests the result without itself holding the weights.

Both tiers share the same ComputeRequest format, the same challenge window, and the same compute-agent stake and slashing rules already defined in Section 11. They differ only in where execution happens and, consequently, what can be certified about it.

13.3 Three Model Categories

Forge classifies every requestable model into one of three categories, since the category determines which tier can serve a request and which certificate type that request can produce.


Category	Description	Certificate Possible
A, Keeper-Hostable	Open weights small enough for a single compute agent to run locally	Full fidelity certificate, via Native or Routed
B, Sharded	Open weights too large for one keeper, requiring distributed execution across a coalition each holding a shard	Fidelity certificate scoped to the distributed execution, via Routed only
C, Closed API	Proprietary models with no available weights; only the API call itself is observable	Provenance-only certificate, via Routed only

13.4 Two Certificate Types: A Required Distinction

Forge introduces two certificate types, and the difference between them is not a matter of degree. A fidelity certificate states that a specific model, identified by a weight hash, produced a specific output on a specific input, confirmed by independent agent re-execution within the existing Section 11 challenge window. A provenance certificate states only that a declared API endpoint was called with a declared input and returned a declared output, observed and signed by a compute agent. Provenance certificates cannot confirm which model produced the response behind a closed API, since the weights are never available to hash or independently rerun.

These are not two strengths of the same guarantee; they are two different guarantees. Every Forge certificate must state plainly which type it is, and the two must never be visually or programmatically interchangeable. A client requiring fidelity-grade trust must be able to reject a provenance-only certificate by category, not have to read the fine print to discover the difference.

13.5 Forge Native: Execution Flow


Phase	Description
1. Request	Identical to Section 11’s existing flow: client submits ComputeRequest(taskType, inputHash, fee) on-chain, restricted here to Category A models.
2. Primary execution	A compute agent, selected by the existing keeper rotation, executes inference and submits ComputeResult(outputHash, proof, agentId), returning output to the requester immediately, optimizing for latency.
3. Independent re-execution	Per Section 11’s existing 24-hour challenge window, other compute agents may independently re-run the same input through the same declared model and submit an alternative result if theirs diverges.
4. Certificate issuance	If no successful challenge occurs within the window, a fidelity certificate is issued referencing the original ComputeResult. If a challenge succeeds, the dispute resolves under Section 11’s existing slashing rules and no fidelity certificate issues for the disputed result.

Forge Native changes nothing about Section 11’s underlying stake, slashing, or challenge-window economics; it adds a model-category restriction and a standardized fidelity certificate format on top of a result that already survived the existing dispute process.

13.6 Forge Routed: Scope

Forge Routed extends the same ComputeRequest pattern to Category B and Category C models, and to Category A requests where Native capacity is unavailable. This requires two additions beyond what Section 11 already specifies:

A backend registry recording, for every external execution source, its category, its current track record, and any registration bond it has posted.
Shard-coalition attestation for Category B: multiple compute agents, each holding one shard of a too-large model, must jointly attest that their combined distributed execution produced the claimed output, a multi-party extension of Section 11’s existing single-agent challenge mechanism.

Full specification of the backend registry and shard-coalition attestation logic is reserved for a future revision of this document. This section establishes their scope and their relationship to Section 11’s existing mechanics, not their contract-level design.

13.7 Keeper and Compute Agent Economics

Forge does not introduce a new fee or staking model. Compute agent earnings, the existing 5 to 15 percent of compute task fee specified in Section 11, and the existing minimum stake apply identically whether an agent is serving a Forge Native request or participating in Forge Routed verification. Forge’s only economic addition is the backend registration bond described in Section 13.6, which applies solely to external Routed backends, not to RandProof’s own compute agents.

13.8 Use Cases

[Layer 2: Production Deployment]

For AGENT5050 and BIT5050-native agents

AGENT5050’s existing inference calls, raffle eligibility evaluation, anomaly detection, winner summary generation, can be served directly through Forge Native, with a fidelity certificate attached to the same ComputeResult lifecycle Section 11 already governs, rather than requiring a separately purchased verification step.

For requesters needing models too large or too closed for any keeper to host

Forge Routed, once fully specified, extends the same registry to Category B sharded models and Category C closed APIs, with the certificate type making explicit which guarantee, fidelity or provenance only, applies to a given request.

13.9 What Forge Does Not Claim

Forge Native does not claim availability for any model outside Category A; capacity is bounded by what compute agents can host, and a request fails explicitly rather than silently downgrading its certificate type.
Forge does not claim price competitiveness against raw decentralized compute marketplaces; its value proposition is a result and a certificate from a single bonded, slashable source, not the lowest cost per token.
Forge Routed, once specified, will not claim fidelity-equivalent certification for Category C models; a provenance certificate is a weaker guarantee than a fidelity certificate, and the two will never be presented interchangeably.
Neither tier claims to validate the correctness of a model’s output; consistent with Section 11’s own scope, Forge certifies that a claimed computation occurred as described, not that its result is factually correct.

13.10 Honest Status

Forge’s Native tier is an extension of RandProofCompute’s existing, specified ComputeRequest and challenge-window mechanics (Section 11), restricted to Category A models and packaged with a standardized fidelity certificate; it has not yet been implemented or audited separately from the underlying RandProofCompute logic it builds on. Forge Routed, the backend registry, and shard-coalition attestation for Category B exist at the scope and positioning level only in this document, with full contract-level specification reserved for a future revision.

13. RandProof Forge: Verified Multi-Backend Compute

On this page