17. RandProof Custody Proof: Reserve and Collateral Attestation at Scale

Section 9 of this document already introduces RandProofReserve and RandProofProvenance as roadmap concepts for tokenized real-world assets, noting exp

[Layer 1: Core, Design Stage]

Section 9 of this document already introduces RandProofReserve and RandProofProvenance as roadmap concepts for tokenized real-world assets, noting explicitly that the underlying attestation logic, generalized from EntropyAttestation.sol’s existing 2-of-3 multi-keeper pattern, is tested for entropy claims but not yet written for arbitrary reserve claims. RandProof Custody Proof formalizes that roadmap item as its own named product: continuous, decentralized proof that a custodian’s claimed backing for an on-chain token matches reality, independent of any single custodian’s self-report.

17.1 Relationship to Section 9

This section does not replace Section 9’s existing disclosure; it names and structures the product Section 9 already described as a roadmap item. RandProofReserve and RandProofProvenance, as specified in Section 9, are the underlying mechanisms; RandProof Custody Proof is the product name and go-to-market framing under which both are offered to stablecoin issuers, tokenized RWA platforms, and other custodial-backing use cases.

17.2 Execution Flow


Phase	Description
1. Reserve Source Registration	A custodian or issuer registers a ReserveAttestationRequest: the claimed reserve source (a bank attestation API, an on-chain wallet address, or both), the claimed backing ratio, and a check_interval.
2. Independent Verification	N keepers independently query the declared reserve source, following the same independent-fetch pattern established in RandProof Oracle (Section 14.2), since a reserve check is, structurally, a specific kind of external data feed.
3. Commit-Reveal and Publication	Keepers commit and reveal their independently-observed reserve figures; consensus produces a timestamped, on-chain ReserveAttestation appended to the issuer’s continuous reserve history, the same pattern as RandProof Audit’s continuous record (Section 16.2).
4. Cross-Chain Registry (for multi-chain issuance)	Where a single physical or off-chain asset backs tokens issued on more than one chain, a canonical registry, the same single-source-of-truth pattern already disclosed in Section 9 for RandProofProvenance, prevents the same reserve from being claimed as backing for two separate token issuances simultaneously.

17.3 Threat Model


Threat	Mitigation
Custodian provides a falsified attestation API response	Identical mitigation to RandProof Oracle: multi-keeper independent fetch means the custodian would need to compromise the attestation API itself to fool all keepers simultaneously, not merely one party’s reporting.
Same reserve claimed as backing for tokens on multiple chains	Addressed by the canonical cross-chain registry (Section 17.2, Phase 4), already disclosed in Section 9 as the hardest, least-built part of this product family.
Reserve source goes offline or becomes unverifiable	A failed verification round is itself a meaningful on-chain signal and is published as such, rather than silently extending the prior attestation’s validity.

17.4 Use Cases

[Layer 3] Stablecoin issuers publishing continuous, decentralized proof-of-reserve rather than relying on periodic manual attestation reports.
[Layer 3] Tokenized real-world asset platforms (commodities, real estate, private credit) requiring ongoing custody verification distinct from a one-time issuance audit.
[Layer 3] Cross-chain bridge operators requiring continuous proof that locked collateral on the source chain matches issued representation on the destination chain.

17.5 Honest Status

RandProof Custody Proof inherits the honest status already disclosed in Section 9 for RandProofReserve and RandProofProvenance: the underlying multi-keeper attestation primitive is implemented and tested for entropy claims specifically (EntropyAttestation.sol v3), and reusing it for arbitrary reserve claims is a planned generalization, not yet written. The cross-chain canonical registry required for multi-chain issuance is, per Section 9’s own assessment, the most valuable and least-built component of this entire product family, requiring its own dedicated adversarial audit before any deployment.