9. RandProof for Tokenized Assets and Real-World Asset (RWA) Verification

Sections 1 through 8 describe RandProof's core fairness and randomness products. Sections 10 through 31 cover the rest of the protocol -- on-chain mechanics, economics, the security audit, node and mobile operations, and per-chain integration. This section sits between them deliberately: it describes a related but distinct problem RandProof's underlying attestation mechanism can also address, proving that a claim about a real-world asset backing an on-chain token is true, right now, without trusting a single party to say so. The two problems share the same shape -- "can I trust what one party reports about something I cannot directly observe" -- and RandProof's existing multi-keeper attestation primitive, built and tested as EntropyAttestation.sol (Section 7, Section 29), generalizes to both. This section is written with the same standard the rest of this document holds itself to: what is a tested, working mechanism versus what is a roadmap item that does not yet exist as code.

Honest framing before anything else: RandProof is not the first or only attestation infrastructure for tokenized assets. Chainlink's Proof of Reserve and Chronicle Protocol's Proof of Asset (used by BlackRock's BUIDL fund as of March 2026) are large, established, and already secure trillions of dollars in cumulative transaction value across DeFi and institutional finance. RandProof does not claim to replace this infrastructure or claim first-mover status. What RandProof offers is a specific, different trust mechanism -- explicit multi-party dispute-and-slash with a published, adversarially-audited security history -- as an alternative or complement to single-oracle-network reporting, not a claim of exclusivity.

9.1 Four Distinct Verification Products, Not One

"RWA verification" is not a single problem. RandProof separates it into three distinct products, because they require different evidence, different attestation mechanics, and carry different honesty obligations about what is and is not provable on-chain. Conflating them -- treating a valuation opinion as if it were a verifiable fact, for example -- is itself a trust failure this section is designed to avoid, not repeat.

9.1.1 RandProofReserve: Reserve and Collateral Attestation

The claim being verified: a specific custodian holds a specific quantity of a specific asset, unencumbered, backing a specific quantity of tokens, as of a specific timestamp. This is the proof-of-reserves problem familiar from stablecoin and tokenized-commodity issuance. It is the strongest near-term fit for RandProof's existing mechanism, because the underlying claim is a single observable fact (a balance, a vaulted quantity) that independent parties checking the same source will either agree on or clearly disagree on -- the same structural property that makes the 2-of-3 attestation model work for entropy sources like ANU QRNG.

Mechanism: Mechanism: at least 3 independently-assigned keepers each query the same attestation source for a given asset -- a custodian's signed attestation API, a vault auditor's published report, a bank balance feed -- on a fixed schedule (e.g. every 24 hours, or on-demand before a redemption). If 2 of 3 reports agree, the reserve figure is accepted and written on-chain as a ReserveAttestation record: token address, attested reserve amount, timestamp, and the attesting keepers. If reports disagree, the same dispute mechanism used for entropy sources applies: the attestation is marked Disputed rather than guessed at, a 24-hour challenge window opens, and a keeper confirmed to have reported a false figure forfeits a bond and risks slashing. A disputed reserve attestation is a meaningful, visible signal to anyone relying on the token -- it does not silently default to the most recent good attestation, which would hide the disagreement.

This is, structurally, the same EntropyAttestation.sol primitive (Section 29, AV-108) with the data source changed from "what value did ANU QRNG return" to "what reserve balance did the custodian's attestation API return." The accept/dispute/slash logic does not need to be rewritten; the off-chain keeper script's fetch target changes. This is a meaningfully different statement from "this is built" -- the contract that exists today (EntropyAttestation.sol v3) handles entropy claims specifically; a generalized RandProofReserve contract that accepts arbitrary claim sources is a planned extension, not yet written, even though the underlying logic it would reuse is tested and deployed to testnet.

9.1.2 RandProofValue: Valuation and NAV Attestation

The claim being verified: an asset's value, as of a specific timestamp, per a specific stated valuation methodology. This is harder than reserve attestation, and this document is explicit about why: valuation is sometimes a single observable fact (a fund's published NAV, read from the fund administrator's API) and sometimes a genuine judgment call (a real estate appraisal, a private loan's mark-to-market value) where independent qualified parties can legitimately disagree without either being dishonest.

Single-source valuation: Where the valuation source is a single published figure (fund NAV, an exchange-quoted price, an index value), RandProofValue uses the identical 2-of-3 attestation mechanism as RandProofReserve -- this case is structurally a reserve attestation with a price instead of a balance, and carries the same honest caveat that the generalized contract does not yet exist.

Judgment-based valuation: Where the valuation is a genuine judgment (appraisal-based real estate, private credit marks, fine art), RandProof does not claim to adjudicate a single "true" value, because doing so would misrepresent what is actually knowable. Instead, RandProofValue is designed to attest to a different, honest claim: that N independent, named, qualified appraisers each submitted a valuation within the same defined window, and to publish the resulting set -- median, range, and dispersion -- on-chain as the attested record. This is a transparency and provenance function, not an adjudication function, and the whitepaper does not claim otherwise.

9.1.3 RandProofProvenance: Asset Registry and Double-Pledge Prevention

The claim being verified: a specific physical or legal asset has been tokenized exactly once, across however many chains and issuers exist, and is not simultaneously backing two different tokens or securing two different loans. This is the double-pledging problem -- the same warehouse receipt, the same property title, or the same serialized collectible being used as collateral more than once, on the same chain or across different chains.

What this requires: Unlike RandProofReserve and RandProofValue, this is not a generalization of the existing 2-of-3 attestation primitive. It requires a registry: a mapping from a real-world asset's unique identifier (a vault lot number, a property title number plus jurisdiction, a certificate hash) to exactly one active token reference, checked before any new tokenization is permitted to proceed. This registry needs a single source of truth across chains, since the same physical gold bar cannot legitimately back a token on Base and a separate token on Solana at the same time. The natural design mirrors RandProof's existing treasury-consolidation pattern (Section 32.10.2): one canonical registry contract on a single chain (Base, for consistency with existing infrastructure), with other chains' contracts checking against it via cross-chain messaging.

Honest status: This is the most valuable of the four products long-term and the least built today. The cross-chain messaging pattern it depends on is the same pattern already flagged as a real, named risk elsewhere in this whitepaper's audit log (AV-89, gossip network partition; AV-106, per-chain pause inconsistency) -- a cross-chain registry is exactly the kind of infrastructure those findings warn is harder to secure than a single-chain contract. RandProofProvenance is disclosed here as a roadmap product requiring new contracts, a new registry design, and its own dedicated adversarial audit before any deployment, following the same process EntropyAttestation.sol went through (Section 29, Rounds 1 through 10) before its own testnet deployment.

9.1.4 RandProofCertify: File, Document, and Media Attestation

A fourth product in this attestation family, distinct from the other three rather than a variant of any of them: this certifies that a specific file (an image, document, video, or any other byte sequence) existed, unaltered, at a specific fetch target, as of a specific on-chain timestamp, attributed to a specific publisher. It reuses EntropyAttestation.sol's proven 2-of-3 agreement mechanism with the payload changed from "what value did an entropy source return" to "what is the hash of the file at this fetch target," verified by 3 independently-assigned keepers who each fetch the target and compute the hash themselves -- the publisher never gets to simply assert a hash with nothing for keepers to check it against.

This is explicitly NOT a tool for determining whether content IS AI-generated, manipulated, or authentic in any creative or editorial sense -- that is a classifier's opinion, not an observable fact independent parties will reliably agree on the way they agree on a file hash, the same reasoning that keeps RandProofValue's judgment-based mode (Section 9.1.2) from claiming to adjudicate a single "true" appraisal. A publisher can disclose AI-generation status, authorship, or any other claim in a free-text label field; this contract verifies that the labeled hash matches what keepers independently fetched, not that the label's claim is itself true. It also does not guarantee ongoing integrity after certification -- a publisher who replaces the file at the same fetch target afterward is not stopped by this contract, the same limitation any notary or timestamping service has -- and it is complementary to, not a replacement for, C2PA/Content-Credentials-style provenance embedded inside a file at creation time by a camera or editing tool.

RandProofCertify.sol is implemented and tested: 26 passing tests, including 4 adversarial probes covering certificate-ID collision resistance, gas-cost behavior for long labels, per-certificate state isolation, and confirmed independence of its keeper registry from the other four contracts in this product family (Section 29.18). The actual end-user verification experience is a single public function, verifyHash(certId, candidateHash) -- anyone hashes their own copy of a file locally and checks true/false against the certified record, with no special access required. It is staged for Base Sepolia testnet deployment but is not yet integrated with EntropyAttestation.sol, LivenessGuard.sol, RandProofAutomation.sol, or KeeperCoordinator.sol, has not had an external security audit, and has no off-chain keeper logic yet for automatically fetching and hashing files the way Section 19.4's reference implementation does for DRAND/NIST.

9.2 Technical Integration: Smart Contracts and Interfaces

This section describes how an issuer's existing token contract integrates with RandProofReserve's planned interface. The interface shown is a specification for the planned generalization of EntropyAttestation.sol described in Section 9.1.1 -- it is designed to be a small, narrow addition to that already-tested contract, not a separate system, but it has not yet been written or tested as of this writing. This is stated plainly so the interface below is read as a design target, the same way every other forward-looking interface in this document is disclosed.

9.2.1 The RandProofReserve Interface (Planned)

Any issuer's token contract, on any EVM chain, would query reserve status through a minimal read-only interface:

interface IRandProofReserve {
function getLatestReserve(address token)

external view returns (

uint256 reserveAmount,
uint256 asOfTimestamp,
bool isDisputed
);
function isReserveCurrent(address token, uint256 maxStaleness)
external view returns (bool);
}

An issuer's contract calls getLatestReserve() before allowing redemption, or isReserveCurrent() as a guard inside a transfer hook. Neither function requires the issuer to trust RandProof's keepers individually -- the returned isDisputed flag reflects whether the underlying 2-of-3 attestation actually agreed, and a disputed or stale reserve is something the issuer's own contract decides how to handle (block redemptions, flag the token, alert holders), rather than RandProof making that policy decision on the issuer's behalf.

9.2.2 Integration with ERC-3643 (T-REX): the Dominant Regulated Security Token Standard

ERC-3643 is, as of this writing, the most widely adopted standard for regulated security token issuance, used by Franklin Templeton, ABN AMRO, and others, with over $28 billion in assets tokenized through it. Its architecture already separates the token contract from a Compliance contract that gates every transfer through a canTransfer() check -- the same check used today for KYC and jurisdictional restrictions. RandProofReserve integrates at exactly this point: a compliance module checks getLatestReserve() or isReserveCurrent() as one additional condition inside canTransfer(), alongside the existing identity and jurisdiction checks ERC-3643 issuers already have in place.

// Illustrative -- a RandProofReserve-aware compliance module
// added to an existing ERC-3643 Compliance contract.
function canTransfer(
address _from, address _to, uint256 _amount
) external view returns (bool) {
if (!IRandProofReserve(reserveOracle)
.isReserveCurrent(tokenAddress, MAX_STALENESS)) {
return false; // reserve stale or disputed: block transfer
}
return _baseCompliance.canTransfer(_from, _to, _amount);
}

This means RandProofReserve does not require ERC-3643 issuers to adopt a new token standard or rewrite their compliance stack -- it slots into the compliance-module pattern the standard already uses for every other transfer restriction. For issuers using plain ERC-20 with custom transfer hooks (the simpler, non-regulated path some commodity and stablecoin issuers take), the same isReserveCurrent() check can be added directly inside an overridden transfer() function.

9.2.3 Non-EVM Integration, Chain by Chain

RandProofReserve follows the same per-chain integration pattern already established for RandProofRNG in Section 32 -- the attestation logic is identical everywhere; what differs is how each chain's native programming model exposes the resulting data to an issuer's contract. As with the EVM interface above, every pattern in this subsection is a design specification for a planned extension, not a deployed contract.

Solana, Program-Derived Accounts (PDAs)

Pattern: A ReserveAttestation is stored as a PDA, addressed deterministically from the token's mint address (the same pattern RandProofRNG already uses for its Solana entropy-result accounts, Section 32.3). An issuer's Anchor program reads the PDA directly via a cross-program invocation -- no oracle polling needed, since the attestation account is itself the canonical on-chain record. Disputed attestations are represented by a status field on the same account, readable in the same call.

Sui, Shared Objects

Pattern: A ReserveAttestation is a versioned shared Sui object, consistent with Sui's object-centric model already used for RandProofRNG's Sui deployment (Section 32.6). An issuer's Move module takes the shared object as a parameter and reads its fields directly; Sui's object versioning means a stale read is structurally impossible -- the issuer's contract always sees the latest committed version or the transaction aborts, which is a stronger staleness guarantee than a polled oracle pattern provides on most other chains.

Cardano, Off-Chain BLS Aggregation, On-Chain Datum

Pattern: Cardano's eUTXO model means the attestation result is written as a datum attached to a UTXO at a known script address, with the keepers' BLS signature aggregation happening off-chain before submission, the same constraint already disclosed for RandProofRNG's Cardano deployment (Section 32.4, and AV-69's broader non-EVM contract-risk disclosure, which applies identically here: Cardano's off-chain signature verification means this chain's attestation trust model is not on-chain-verifiable in the way Solana's or Sui's is, and that gap is not closed by extending the attestation mechanism to RWA data).

TON, Actor-Model Messages

Pattern: Following the same pattern as RandProofRNG's existing TON deployment (Section 32.5), a ReserveAttestation is delivered as an internal message to the issuer's contract, processed asynchronously per TON's actor model. An issuer that needs an on-demand reserve check (rather than waiting for the next scheduled attestation message) sends a request message and awaits the asynchronous reply, rather than making a synchronous call as on EVM chains.

Polkadot, Asset Hub, XCM

Pattern: Consistent with RandProof's existing Polkadot integration (Section 32.7, Section 32.10.1's native XCM USDC settlement), a ReserveAttestation for an asset issued on Polkadot's Asset Hub is itself an Asset Hub-native record, readable by any parachain via XCM without a third-party bridge -- the same bridge-free design principle already adopted for treasury settlement (AV-49) applies to attestation data for the same reason: a third-party bridge is unnecessary risk when the data and the consuming contract are both within reach of native cross-consensus messaging.

9.3 Use Cases by Market Segment

The same four products apply differently depending on who is relying on the attestation and what is at stake if it is wrong. This section separates retail, business, commercial, and institutional use cases rather than treating "RWA" as a single market, since the verification depth and dispute consequences differ meaningfully across them.

9.3.1 Retail

• Tokenized commodities and stablecoins: A holder of a tokenized-gold or tokenized-commodity product checks RandProofReserve's public attestation record before buying or redeeming, without needing to trust the issuer's own marketing claims or a single self-reported audit PDF.

• Fractional real estate and fund tokens: A retail investor in a tokenized real estate or private credit fund sees RandProofValue's published appraiser set (median, range, dispersion) rather than a single unverifiable number from the fund sponsor, making it visible when valuations are thin, contested, or based on a small number of appraisers.

9.3.2 Business and Small Commercial

• Invoice and receivables financing: A small business tokenizing invoices or receivables for working-capital financing uses RandProofReserve to attest that the underlying receivable still exists and has not been collected or written off, which is the same double-counting risk that has caused real losses in invoice-financing fraud cases historically.

• Warehouse receipts and inventory financing: A regional warehouse or commodity storage operator issuing tokenized warehouse receipts uses RandProofReserve attestations as the on-chain proof that physical inventory still matches issued receipts, reducing reliance on a single operator's self-attestation.

9.3.3 Commercial and Mid-Market Institutions

• Private credit and fund tokenization: A mid-size asset manager tokenizing a private credit fund uses RandProofValue's single-source mode (Section 9.1.2) to attest the fund's published NAV on a recurring schedule, giving token holders a verifiable, disputable record rather than a quarterly PDF.

• Collateralized lending against tokenized RWAs: A commercial lender accepting tokenized RWAs as loan collateral uses RandProofReserve to verify collateral backing before disbursing, and (once built) RandProofProvenance to verify the same collateral has not already been pledged elsewhere -- directly addressing the double-pledging risk that is one of the most-cited concrete failure modes in RWA lending today.

9.3.4 Institutional

• Institutional custody and treasury products: A custodian or trust company holding the underlying assets for a large tokenized treasury or money-market fund (the BlackRock BUIDL-style use case) uses RandProofReserve as a complementary or alternative attestation layer to existing oracle infrastructure, with the explicit differentiator described in Section 9.4 being the dispute-and-slash mechanism rather than a claim of superior data accuracy.

• Cross-chain institutional issuance: An institution running a tokenized fund across multiple chains (a real, growing pattern as tokenization platforms expand beyond a single chain) uses RandProofReserve's identical per-chain attestation pattern (Section 9.2.3) to get the same verification logic on every chain it operates on, rather than integrating a different oracle solution per chain.

• Regulatory and audit visibility: A regulator or auditor reviewing a tokenized security under ERC-3643 or equivalent regimes can independently read RandProofReserve's on-chain attestation history -- including any disputed attestations and their resolutions -- as a permanent, tamper-evident record, which is a meaningfully different artifact than a periodic third-party audit letter.

9.4 Honest Competitive Position and Roadmap

RandProof's actual claim is narrower than "the standard for tokenized assets," and this section states that narrower claim precisely rather than implying more than is true. The RWA attestation market is already served by large, established infrastructure -- Chainlink's Proof of Reserve and Chronicle Protocol's Proof of Asset chief among them, the latter integrated into BlackRock's BUIDL fund as of March 2026. RandProof's differentiator is not coverage, scale, or incumbency, none of which RandProof currently has in this market. The differentiator is the specific trust mechanism: an explicit, on-chain, disputable 2-of-3 attestation with bonding and slashing for confirmed false reports, backed by a published adversarial security history (136 attack vectors analyzed across 14 audit rounds as of this writing, Section 29.18) -- versus the more common pattern of a decentralized oracle network reporting a value backed by node operator reputation and stake, without the same explicit per-claim dispute window.

Status of each product as of this writing:

• RandProofReserve: Reuses the tested, testnet-deployed EntropyAttestation.sol 2-of-3 attestation mechanism (Section 29, AV-108-111; 31 passing tests). The generalized contract accepting arbitrary off-chain claim sources (rather than entropy sources specifically) does not yet exist as code -- it is a planned, scoped extension of an already-audited primitive, not new, unaudited design.

• RandProofValue: Single-source mode shares RandProofReserve's status above. Judgment-based (appraiser-set) mode requires new aggregation logic not yet designed in code, beyond the conceptual specification in Section 9.1.2.

• RandProofProvenance: Requires a new cross-chain registry contract that does not yet exist in any form, depends on cross-chain messaging patterns already flagged as carrying real risk elsewhere in this audit log (AV-89, AV-106), and requires its own dedicated adversarial audit before any deployment, following the same process applied to EntropyAttestation.sol. This is the most valuable and least mature of the four products.

• RandProofCertify: Implemented and tested as RandProofCertify.sol (26 passing tests, 4 adversarial probes, Section 29.18) -- the most mature of the four products in code terms, since it reuses EntropyAttestation.sol's exact attestation mechanism rather than requiring new aggregation or registry logic. Staged for Base Sepolia testnet deployment; not yet integrated with any other contract in this product family; no off-chain keeper automation yet for fetching and hashing files.

None of the four products described in this section have been integrated into KeeperCoordinator.sol (Section 19), which now exists as a tested MVP (Section 29.16) but does not yet call into EntropyAttestation.sol or any of the other three contracts in this product family. This section describes a coherent extension of RandProof's tested attestation mechanism into a new problem domain, not a claim that RWA verification or file-certification services are available today.