Verifiable data solutions for RWAs: From source documents to onchain proofs

A practical, end-to-end playbook for taking real‑world documents and data (identity, ownership, cash flows, NAV, trade docs) and turning them into verifiable, machine‑checkable proofs on public chains—using modern attestations, privacy-preserving web data proofs, and production oracle tooling. We include concrete architectures, vendor comparisons, and implementation checklists that reflect what’s actually working in 2024–2025.

---

Why this matters now

• Tokenized Treasuries and funds are becoming core collateral for crypto‑native and institutional workflows. In March 2025, tokenized Treasuries hit a record ~$4.2B market cap; by June, rwa.xyz data cited a ~$7.2B market value, driven by issuers like BlackRock (BUIDL), Franklin (BENJI), Ondo, and Superstate. (coindesk.com)
• BlackRock’s BUIDL surpassed $1B AUM on March 13, 2025, has added share classes across multiple chains, and is being accepted as collateral at major venues—clear signals that on‑chain verifiability and composability are moving into production‑grade capital markets. (prnewswire.com)
• Tokenized funds are also evolving operationally: Superstate introduced “continuous pricing” (second‑by‑second NAV per share) and is wiring those data to onchain integrations—precisely the kind of data that must be verifiable to be useful in DeFi and automated treasury flows. (superstate.com)

If you’re exploring RWAs, your main risk is no longer “can we mint a token?” It’s “can counterparties verify our offchain data and decisions quickly, privately, and trust‑minimized?” This post shows how to do that.

---

The verifiable data problem (and failure modes to avoid)

RWAs depend on offchain facts: identity/KYC eligibility, chain of title, custody balances, price/NAV, trade docs (e.g., eBLs), and covenant checks. Typical failure modes:

• Screenshots and PDFs with no provenance metadata (spoofable; not machine‑checkable).
• “Trust us” API calls without cryptographic transport proofs (MITM/extraction risks).
• Stale oracles that can’t attest to when/where a fact originated.
• Compliance without revocation status or lifecycle events wired onchain.

Two recent standardization moves make this solvable at scale:

• W3C Verifiable Credentials (VC) 2.0 became a W3C Recommendation on May 15, 2025—locking in interoperable data models, JOSE/COSE security, Data Integrity proofs, and revocation mechanisms like Bitstring Status Lists. (w3.org)
• ERC‑3643 (a permissioned token standard) is coalescing industry momentum, with DTCC formally joining the association in March 2025 to support regulated tokenization flows. For securities‑like RWAs, this standard reduces “invent your own compliance token” risk. (dtcc.com)

---

From source documents to onchain proofs: a reference architecture

What follows is a modular pipeline you can adopt in whole or in part. We’ll highlight tools with strong production signals.

0) Gate access and bind participants to onchain identities

• Offchain sessions: implement Sign‑In with Ethereum (EIP‑4361) so every API/dashboard action is cryptographically linked to a wallet (EOA or 1271 smart account). This allows you to bind later attestations and signatures to the same subject. (eips.ethereum.org)
• Permissioned asset rails: for regulated RWAs, issue the token as ERC‑3643 and back it by an ONCHAINID‑based eligibility graph. This lets transfer rules enforce KYC/geographic/holder‑count constraints onchain. (erc3643.org)

Practical tip: keep ERC‑1404 in mind for simple transfer restrictions if you don’t need full ERC‑3643 semantics. (github.com)

1) Capture, normalize, and sign source documents

• Trade documents and titles: use OpenAttestation/TradeTrust patterns—either DNS‑TXT “document store” commitments on chain or DNS‑DID signed JSON documents. The trust anchor is DNS, which most enterprises already control, and issuance/revocation are verifiable by any party. (docs.tradetrust.io)
• Legal certainty for transfer of title: TradeTrust is aligned with MLETR and has been used in live eBL and D/P flows across jurisdictions (e.g., SG‑India), giving you a path to paperless, enforceable trade documents. (imda.gov.sg)
• Identity, accreditation, and eligibility: issue claims as W3C VC 2.0 credentials (e.g., “qualified purchaser,” “accredited investor,” “KYC‑passed”), signed by your KYC vendor and revocable via status lists. These can be consumed on- or offchain and are interoperable across wallets. (w3.org)

Output of this stage: a structured payload (JSON/JSON‑LD) plus a signature and public metadata (issuer, schema, revocation method).

2) Store with tamper evidence and query‑ready indexing

• Content‑addressed storage: archive the document or normalized JSON to IPFS/Arweave (hash will become the onchain reference).
• Verifiable offchain analytics: if you need to run calculations over large datasets (e.g., rolling NAV, concentration limits), leverage Space and Time’s Proof of SQL to prove that queries over offchain tables were executed correctly against untampered data, with onchain or offchain verification. This is useful when you must show “NAV = f(positions, marks) at time T” without exposing all rows. (github.com)
• Tamperproof SQL ledger semantics (archival + role‑based access + IPFS backups) are available if you need audit‑friendly governance around the data warehouse itself. (spaceandtime.io)

Output: CIDs plus optional verifiable query results and proofs.

3) Prove authenticity and provenance of web data (without custom APIs)

Not all sources will sign data for you. Two pragmatic approaches:

• TLSNotary (PSE/Ethereum Foundation): uses MPC‑TLS to notarize what a website showed you over TLS, enabling selective disclosure and portable signatures. As of 2025 it supports TLS 1.2; TLS 1.3 is on the roadmap. Great for bank statements, custodial balances, or transfer confirmations when the site has no “oracle” product. (tlsnotary.org)
• DECO/zkTLS or similar: Chainlink’s DECO Sandbox exposes a zkTLS‑style approach that can authenticate web data in a privacy‑preserving way with no server changes—relevant for “proof of funds,” KYC checks, or sanctions screening attested for onchain consumption. (blog.chain.link)

Output: a signed “web transcript proof” attesting to who said what and when—without leaking secrets.

4) Transport facts onchain, with the right oracle pattern

Match the oracle to the job:

• Programmatic API pulls and custom compute: Chainlink Functions lets a DON execute your code against APIs, aggregate results, and post to your contract—supporting secrets management and subscription billing. Use this for bespoke RWA data pipes. (docs.chain.link)
• High‑frequency price/NAV streams with onchain verification: Chainlink Data Streams provide cryptographically signed, sub‑second reports that contracts can verify on demand—suited for continuous NAV or intraday marks in low‑latency contexts. (docs.chain.link)
• Collateral backing checks: Chainlink Proof of Reserve (PoR) wires reserve attestations into your token’s mint logic, pausing mint/redeem or triggering circuit breakers if reserves fall short—crucial for tokenized funds, wrapped assets, or stablecoins. (chain.link)
• Low‑latency market data with “pull” semantics: Pyth provides pull and push feeds across chains; pull is useful when you want updates on demand with lower gas spend. (pyth.network)
• Modular/pull oracle with OEV and liquidation‑aware flows: RedStone’s model minimizes onchain updates and has specialty modes (Atom, Bolt) for liquidation‑sensitive DeFi and high‑throughput environments; they also report RWA/NAV data for institutional tokens. (blog.redstone.finance)
• Event truth with human‑time windows: UMA’s Optimistic Oracle v3 lets you assert facts (e.g., “debtor X missed payment on date T”) with a dispute period; useful when data requires subjective evaluation or offchain audit logs. UMA has processed tens of thousands of assertions with a minimal dispute rate. (github.com)

Output: onchain proofs, signatures, and/or assertions ready for contract consumption.

5) Verify onchain and enforce policy

• Attestation layers:
  • Ethereum Attestation Service (EAS) gives you schema‑based attestations with resolvers; works across mainnet/L2s and supports both on/offchain attestations. (attest.org)
  • Verax (Linea/Consensys) provides a shared registry with “portals” and subgraphs for discoverability; useful for building cross‑app trust registries and reputational graphs. (github.com)
• Contract checks: verify signatures (EIP‑712), EIP‑1271 for smart‑account signers, and oracle‑specific verifiers (e.g., Chainlink report verification libraries, Pyth/RedStone adapters).
• Automate controls: wire PoR or attestation results into token logic (pause mint/burn), collateral haircuts, redemption gates, or covenant enforcers.

6) Observe, audit, and revoke

• Index attestation graphs and expose dashboards for regulators/auditors.
• Implement revocation flows for VCs and attestations (Bitstring Status Lists, onchain revoke functions). (w3.org)
• Persist the “why” behind state changes: keep the CID to every underlying doc and the hash of every onchain rule evaluation.

---

Concrete patterns by asset type

A) Tokenized U.S. Treasuries and money funds

• Market context to anchor design:

  • BUIDL crossed $1B AUM (Mar 13, 2025), added share classes across chains (Nov 2024, with further expansion in Mar 2025), and is now recognized as collateral at Crypto.com and Deribit. (prnewswire.com)
  • Aggregate tokenized Treasuries grew from ~$1.7B (mid‑2024) to ~$7.2B (June 2025), with issuers like Ondo, Franklin, BlackRock, and Superstate. (coindesk.com)
  • Superstate introduced “continuous pricing” (continuous NAV/S), enabling atomic‑like integrations and composability. (superstate.com)

• Data you must verify:

  • Positions and custody balances (e.g., BNY Mellon for USTB) → archived statements or API extracts notarized via TLSNotary/DECO; CID placed in an EAS attestation, referenced by NAV proofs. (superstate.com)
  • NAV and AUM → run proofs that NAV was computed from positions and official marks; publish PoR or signed NAV updates via Chainlink Functions/Data Streams; consider PoR gating mint/redemptions. (docs.chain.link)

• Implementation sketch:

  1. Custodian statements fetched daily using TLSNotary, redact to balances-in-scope, anchor CID onchain. (tlsnotary.org)
  2. NAV service runs Proof of SQL over positions and prices; post result + proof; contracts verify or spot‑check offchain. (github.com)
  3. Chainlink PoR/Functions pushes a signed NAV/AUM report to the fund’s controller; mint/redeem logic applies guardrails. (chain.link)

B) Private credit, receivables, and trade finance

• Documents: invoices, purchase orders, eBLs, warehouse receipts → issue as OpenAttestation/TradeTrust verifiable docs with DNS‑TXT or DNS‑DID; lenders verify issuance and transfer of title instantly. (docs.tradetrust.io)
• Legal enforceability: align to MLETR/ETDA regimes; TradeTrust has demonstrated live interoperable eBL/D‑P flows. (imda.gov.sg)
• Onchain triggers: late‑payment or dilution events asserted via UMA’s optimistic oracle with a dispute window for the borrower to contest, binding the credit facility’s state machine to verifiable offchain events. (github.com)

C) Real estate and titles

• KYC/eligibility: issue investor credentials as VC 2.0 and enforce ERC‑3643 transfer rules. (w3.org)
• Title packets: notarize chain‑of‑title docs via OpenAttestation; store CIDs; publish an EAS attestation “Title as of date T held by entity X”; revocation on change of ownership. (docs.tradetrust.io)

---

Choosing the right oracle/attestation tool: a simple matrix

• Deterministic, frequent numeric data (price, NAV, utilization): Chainlink Data Streams, Pyth, RedStone. If low latency and on‑demand costs matter, prefer pull designs (Pyth/RedStone). If you need onchain verification and DON‑level SLAs, Chainlink Data Streams fits. (docs.chain.link)
• Collateral backing or reserve checks: Chainlink Proof of Reserve with mint/redeem circuit breakers. (chain.link)
• Arbitrary API compute with secrets: Chainlink Functions. (docs.chain.link)
• Subjective/offchain events (defaults, fraud flags): UMA Optimistic Oracle v3. (github.com)
• Web data with privacy: TLSNotary or DECO/zkTLS to notarize HTTPS transcripts without server changes. (tlsnotary.org)
• Graphs of who attested to what: EAS (schemas/resolvers) or Verax (registry/portals). (attest.org)

---

Emerging best practices we recommend in 2025

• Standardize on VC 2.0 for identity/eligibility credentials; prefer JOSE/COSE or Data Integrity cryptosuites depending on your stack; use Bitstring Status Lists for high‑scale revocation. (w3.org)
• For securities‑like RWAs on public L2s, adopt ERC‑3643 to encode transfer rules. DTCC’s 2025 adoption signals downstream interoperability with market infrastructure. (dtcc.com)
• Use attestations as “indexes” into heavier artifacts. Put only fingerprints (hashes, CIDs, proof IDs) onchain; keep raw docs offchain under legal controls.
• Treat NAV and risk metrics as verifiable computations, not just numbers. If you can’t replicate the result from position snapshots and marks, it’s not verifiable. Proof of SQL and DON‑verified reports are your friends. (github.com)
• Bake controls into token logic. Connect PoR/NAV thresholds to automated circuit breakers or redemption caps to reduce operational risk. (chain.link)
• Publish machine‑readable schemas (EAS/Verax) and subgraphs early so integrators can consume your attestations without reverse‑engineering. (docs.ver.ax)

---

Implementation checklist (what we ship in 6–10 weeks)

1. Data inventory and schemas

• Identify every fact your contracts need: identity, balances, docs, price/NAV, events.
• Define schemas for EAS/Verax and VC contexts; map revocation pathways.

1. Source acquisition and notarization

• For websites with no APIs: choose TLSNotary or DECO flow; define redaction policy and time‑stamps. (tlsnotary.org)
• For APIs: implement Chainlink Functions tasks with threshold‑encrypted secrets; define SLAs and retries. (docs.chain.link)

1. Storage and indexing

• Archive originals to IPFS/Arweave; index CID ↔ attestation IDs; for analytics, set up Proof of SQL pipelines. (github.com)

1. Onchain transport

• Select oracle(s): Data Streams/Pyth/RedStone for numbers, UMA for events, PoR for reserves. Wire to controller contracts. (docs.chain.link)

1. Verification and policy

• Build verifiers (EIP‑712/1271), EAS/Verax resolvers, and policy modules (pause/limit/mint‑gates).

1. Observability and audits

• Expose dashboards for attestation graphs and proof freshness; emit events with CID/proof IDs.

Key KPIs:

• Data freshness (minutes), proof generation cost/time, % coverage (facts with proofs), dispute rate (for optimistic flows), and mean time to revoke/replace credentials.

---

Real‑world example blueprints

• Tokenized fund NAV pipeline

  • Inputs: Custodian balances (TLSNotary), positions DB (warehouse), prices (Data Streams/Pyth).
  • Compute: Proof of SQL for NAV; secondary DON verification; PoR feed for AUM guardrails.
  • Outputs: EAS attestation “NAV_t”; controller enforces mint/redeem caps if NAV/AUM deviate. (tlsnotary.org)

• eBL‑backed receivables

  • Inputs: TradeTrust eBLs (DNS‑TXT issuance), bank D/P confirmations notarized via TLSNotary.
  • Oracle: UMA assertion “invoice settled on T” with 48–72h dispute window.
  • Onchain: pool share payouts trigger when settlement attestation confirmed. (docs.tradetrust.io)

• Permissioned real estate fund units

  • Token: ERC‑3643 with ONCHAINID; transfers gated by VC 2.0 “QIB/QP” credentials and geography claims.
  • Registry: Verax/EAS to expose investor eligibility attestations to distributors/compliance bots. (erc3643.org)

---

Vendor and tooling snapshot (2025 signal strength)

• Chainlink: Functions (custom compute), Data Streams (low‑latency signed reports), PoR (reserve checks). (docs.chain.link)
• Pyth: low‑latency pull/push feeds across many chains. (pyth.network)
• RedStone: modular pull oracle with liquidation‑aware “Atom” and ultra‑fast “Bolt”; expanding RWA/NAV data. (blog.redstone.finance)
• UMA: Optimistic Oracle v3 for arbitrary facts with dispute windows; >60k assertions milestone. (outposts.io)
• TLSNotary / DECO: privacy‑preserving proofs of HTTPS data. (tlsnotary.org)
• TradeTrust/OpenAttestation: production frameworks for verifiable trade docs aligned to MLETR. (imda.gov.sg)
• EAS / Verax: generalized attestation layers with schemas, resolvers, and explorers. (attest.org)
• Space and Time: Proof of SQL for verifiable analytics over offchain datasets. (github.com)

---

What “great” looks like in 2025

• Every material claim about the asset (eligibility, title, balances, NAV, events) is represented as a signed attestation with an auditable trail to the underlying document or transcript proof (CID).
• Calculations are verifiable, not opaque; where possible, they’re reproduced deterministically via ZK‑verified queries or DON‑verified reports. (github.com)
• Controls are enforced by code: mints/redemptions gated by PoR; covenants wired to assertions; price/NAV freshness enforced in collateral haircuts. (chain.link)
• The system is legible to integrators: schemas and subgraphs are public; dispute windows and revocation methods are documented.

---

How 7Block Labs can help

Our RWA Verifiable Data Accelerator delivers a production pilot in ~8–10 weeks:

• Week 1–2: schema design (VC 2.0, EAS/Verax), oracle selection, and threat modeling.
• Week 3–5: source data notarization (TLSNotary/DECO), storage, and PoSQL pipelines; deploy attestations registries. (tlsnotary.org)
• Week 6–8: onchain controllers (ERC‑3643 if needed), verifiers, and policy automation (PoR/NAV gates). (erc3643.org)
• Week 9–10: observability, audits, and go‑live runbooks.

You don’t have to tokenize everything at once. Start by making your offchain truths verifiable—then let composability do the rest.

---

Further reading and signals

• Tokenized Treasuries growth and BUIDL milestones. (coindesk.com)
• VC 2.0 standards family (data model, JOSE/COSE, Data Integrity, status lists). (w3.org)
• TradeTrust/OpenAttestation guides (DNS‑TXT, DNS‑DID issuance and verification). (docs.tradetrust.io)
• Oracle design patterns (Data Streams, Functions, PoR; Pyth/RedStone pull vs push). (docs.chain.link)
• UMA Optimistic Oracle v3 usage and metrics. (github.com)
• Proof of SQL docs and examples. (github.com)

---

7Block Labs builds verifiable data foundations so your RWA doesn’t just exist onchain—it proves itself, continuously.