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

A Practical Guide: Turning Real-World Documents into Verifiable Proofs on Public Chains

This playbook is your go-to resource for converting real-world documents and data--like identity, ownership, cash flows, NAV, and trade documents--into verifiable, machine-checkable proofs on public chains. We’ll be diving into modern attestations, privacy-preserving web data proofs, and the latest production oracle tooling.

Here’s what you can expect:

• Concrete Architectures: We discuss solutions that are actually in use and working in 2024-2025.
• Vendor Comparisons: Get the rundown on the best options available so you can make informed choices.
• Implementation Checklists: We provide handy checklists to streamline your process and ensure you cover all your bases.

Let’s get started!

---

Why this matters now

• Tokenized Treasuries and funds are quickly becoming essential collateral for both crypto-native and institutional workflows. Back in March 2025, tokenized Treasuries hit a whopping ~$4.2B market cap. By June, data from rwa.xyz showed they were worth around ~$7.2B, thanks to key players like BlackRock (BUIDL), Franklin (BENJI), Ondo, and Superstate. (coindesk.com)
• On March 13, 2025, BlackRock’s BUIDL crossed the $1B mark in AUM, adding share classes across multiple chains and gaining traction as collateral at major venues. This is a clear sign that on-chain verifiability and composability are stepping up into production-grade capital markets. (prnewswire.com)
• Tokenized funds are also stepping up their game operationally. Superstate has rolled out “continuous pricing,” which means they’re providing a second-by-second NAV per share and linking that data to on-chain integrations. This is exactly the kind of verifiable data needed to make a real impact in DeFi and automated treasury flows. (superstate.com)

If you’re diving into RWAs, the big question isn’t really about whether we can mint a token anymore. Instead, it’s about whether counterparties can quickly and privately verify our off-chain data and decisions while keeping trust to a minimum. In this post, we’ll walk you through how to make that happen.

---

The verifiable data problem (and failure modes to avoid)

RWAs are influenced by various off-chain facts such as identity/KYC eligibility, chain of title, custody balances, price/NAV, trade documents (like eBLs), and covenant checks. Here are some common ways things can go wrong:

• Screenshots and PDFs lacking provenance metadata (easy to spoof; can’t be machine-verified).
• API calls that just say “trust us” without any cryptographic transport proofs (vulnerable to MITM/extraction risks).
• Outdated oracles that can't confirm when or where a fact came from.
• Compliance issues that don’t include revocation status or lifecycle events integrated onchain.

Two recent moves toward standardization have really opened the door for solving this at scale:

• On May 15, 2025, W3C Verifiable Credentials (VC) 2.0 officially became a W3C Recommendation. This marks a big step forward with its focus on interoperable data models, JOSE/COSE security, Data Integrity proofs, and handy revocation methods like Bitstring Status Lists. Check out more details here.
• The momentum around ERC‑3643, a permissioned token standard, is really picking up steam. In March 2025, DTCC jumped on board, joining the association to back regulated tokenization flows. This standard is a game changer for securities-like RWAs, helping to cut down the risks of having to “invent your own compliance token.” You can read more about it here.

---

From source documents to onchain proofs: a reference architecture

Here’s a modular pipeline that you can take on fully or just pick and choose from. We’ll point out tools that really stand out in terms of production quality.

0) Gate access and bind participants to onchain identities

• Offchain sessions: Let's make signing in a breeze with Ethereum by using Sign‑In with Ethereum (EIP‑4361). What this means is that every action you take on the API or dashboard is cryptographically linked to your wallet, whether it's a standard EOA or a 1271 smart account. This cool feature allows you to connect future attestations and signatures back to the same subject. Check it out here: (eips.ethereum.org)
• Permissioned asset rails: For those regulated real-world assets (RWAs), you can issue tokens as ERC‑3643 and support them with an ONCHAINID-based eligibility graph. This setup makes it super easy to enforce on-chain transfer rules that include KYC, geographic restrictions, or even holder-count limits. Dive deeper into it here: (erc3643.org)

Practical tip: If you’re just looking for straightforward transfer restrictions and don’t really need all the bells and whistles of ERC‑3643, definitely check out ERC‑1404. It could be a great fit for your needs! You can find more details here.

1) Capture, normalize, and sign source documents

• Trade documents and titles: Check out the OpenAttestation/TradeTrust patterns--this means you can use either DNS‑TXT “document store” commitments on-chain or DNS‑DID signed JSON documents. The cool part? The trust anchor is DNS, so most companies already have control over it. Plus, anyone can verify issuance and revocation. (docs.tradetrust.io)
• Legal certainty for transfer of title: TradeTrust is in sync with MLETR and has been successfully used in real-life electronic Bill of Lading (eBL) and Delivery/Payment (D/P) processes between countries (like SG and India). This means you can move towards completely paperless and legally binding trade documents. (imda.gov.sg)
• Identity, accreditation, and eligibility: You can issue claims as W3C VC 2.0 credentials (think “qualified purchaser,” “accredited investor,” or “KYC‑passed”). These are signed by your KYC vendor and can be revoked through status lists. They work seamlessly on-chain or off-chain and play nice across different wallets. (w3.org)

At this stage, you’ll get a structured payload, which comes in the form of JSON or JSON-LD, along with a signature and some public metadata. This metadata includes the issuer, schema, and revocation method.

2) Store with tamper evidence and query‑ready indexing

• Content-addressed storage: You can archive your documents or normalized JSON files to IPFS or Arweave, and then the hash will serve as your on-chain reference.
• Verifiable offchain analytics: If you ever need to crunch some numbers over big datasets (think rolling NAV or concentration limits), check out Space and Time’s Proof of SQL. It lets you prove that your queries against offchain tables were executed correctly using clean, untampered data, with either on-chain or off-chain verification. This is super handy when you need to show something like “NAV = f(positions, marks) at time T” without having to expose all the rows. You can find more details on GitHub.
• Tamperproof SQL ledger semantics: If you want to ensure audit-friendly governance around your data warehouse, you can tap into these features, which include archival, role-based access, and IPFS backups. More info is available on Space and Time's blog.

Output: CIDs, along with optional verifiable query results and proofs.

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

Not every source is going to sign the data for you. Here are two practical approaches you can take:

• TLSNotary (PSE/Ethereum Foundation): This tool uses MPC‑TLS to notarize what you see on a website over TLS. It’s awesome for selectively sharing info and creating portable signatures. As of 2025, it’s got your back with TLS 1.2 support, and TLS 1.3 is coming soon. Perfect for bank statements, custodial balances, or transfer confirmations when the website doesn’t offer an “oracle” product. Check it out at tlsnotary.org.
• DECO/zkTLS or similar: Chainlink’s DECO Sandbox brings a zkTLS-style solution to the table, letting you authenticate web data without changing anything on the server. This is super useful for things like “proof of funds,” KYC checks, or sanctions screenings that need to be attested for on-chain use. Dive into the details at blog.chain.link.

Output: a signed “web transcript proof” that shows who said what and when--keeping everything private.

4) Transport facts onchain, with the right oracle pattern

Match the Oracle to the Job:

Here’s a fun little guide to help you connect the right oracle to their respective gigs. Check it out!

Feel free to dive into each one’s story and see how they fit into their roles!

• Programmatic API pulls and custom compute: Chainlink Functions makes it easy for a Decentralized Oracle Network (DON) to run your code against APIs, gather results, and post everything to your contract. Plus, it supports secrets management and subscription billing, making it perfect for your personalized RWA data pipelines. Check it out here: (docs.chain.link)
• High-frequency price/NAV streams with on-chain verification: Chainlink Data Streams offer cryptographically signed reports that come in under a second, letting contracts verify on demand. This is just what you need for continuous NAV or intraday marks, especially in those low-latency situations. Learn more at: (docs.chain.link)
• Collateral backing checks: Chainlink Proof of Reserve (PoR) lets you wire reserve attestations into your token’s mint logic. If reserves dip too low, it can pause minting/redeeming or trigger circuit breakers--super crucial for tokenized funds, wrapped assets, or stablecoins. For details, go to: (chain.link)
• Low-latency market data with “pull” semantics: Pyth offers both pull and push feeds across chains, with the pull feature being great for when you need updates on demand without breaking the bank on gas fees. Want to find out more? Head over to: (pyth.network)
• Modular/pull oracle with OEV and liquidation-aware flows: RedStone’s setup keeps on-chain updates to a minimum and comes with specialized modes (like Atom and Bolt) designed for liquidation-sensitive DeFi and high-throughput scenarios. They also provide RWA/NAV data specifically for institutional tokens. Dive into it here: (blog.redstone.finance)
• Event truth with human-time windows: UMA’s Optimistic Oracle v3 lets you assert facts (like “debtor X missed payment on date T”) within a dispute period. This is really handy when the data needs a bit of human touch or relies on off-chain audit logs. UMA has successfully processed tens of thousands of assertions with a low dispute rate. Check it out on GitHub: (github.com)

Output: on-chain proofs, signatures, or assertions that are all set for contract use.

5) Verify onchain and enforce policy

• Attestation layers:
  • The Ethereum Attestation Service (EAS) is pretty cool--it lets you create schema-based attestations with resolvers. It works seamlessly across mainnet and Layer 2 solutions, plus it’s got your back for both on-chain and off-chain attestations. Check it out here: attest.org.
  • Verax (from Linea/Consensys) offers a shared registry that features “portals” and subgraphs to help you find what you need. It's super handy for building cross-app trust registries and reputational graphs. Dive into it here: github.com.
• Contract checks: Make sure to verify signatures using EIP‑712, and don’t forget about EIP‑1271 for smart-account signers. Also, check out oracle-specific verifiers like Chainlink's report verification libraries and Pyth/RedStone adapters.
• Automate controls: You can wire Proof of Reserves (PoR) or attestation results right into your token logic. Think about using it to pause minting or burning, manage collateral haircuts, set up redemption gates, or enforce covenants.

6) Observe, audit, and revoke

• Create index attestation graphs and set up dashboards for regulators and auditors.
• Set up revocation processes for Verifiable Credentials (VCs) and attestations, including Bitstring Status Lists and on-chain revoke functions. Check it out here: (w3.org).
• Make sure to document the “why” behind state changes: store the CID for each underlying document and the hash for every on-chain rule evaluation.

---

Concrete patterns by asset type

A) Tokenized U.S. Treasuries and money funds

• Market context to anchor design:
  • BUIDL hit a significant milestone, crossing $1B in assets under management (AUM) on March 13, 2025. They also rolled out new share classes across different chains in November 2024, with plans for even more expansion in March 2025. Plus, it's now recognized as collateral on platforms like Crypto.com and Deribit. (prnewswire.com)
  • The market for tokenized Treasuries has really taken off, skyrocketing from about $1.7B in mid-2024 to around $7.2B by June 2025. Big players like Ondo, Franklin, BlackRock, and Superstate are leading the charge. (coindesk.com)
  • Superstate rolled out a cool feature called “continuous pricing,” which brings continuous NAV/S into play. This makes it possible for super smooth atomic-like integrations and enhances composability. (superstate.com)
• Data you really need to double-check:
  • Positions and custody balances (like BNY Mellon for USTB) → find those archived statements or API extracts that are notarized through TLSNotary/DECO; make sure the CID is included in an EAS attestation, which should reference the NAV proofs. (superstate.com)
  • NAV and AUM → run some proofs to show that NAV was calculated from positions and official marks; don’t forget to publish PoR or signed NAV updates using Chainlink Functions/Data Streams; you might want to think about PoR gating for mint/redemptions. (docs.chain.link)
• Here's the implementation outline:
  1. We’ll grab custodian statements every day using TLSNotary, making sure to redact to just the balances we need and then anchor the CID on-chain. Check it out here: (tlsnotary.org).
  2. The NAV service will run a Proof of SQL on the positions and prices; once that’s done, we’ll post the results along with the proof. Our contracts will handle verification or do some spot-checking off-chain. More details can be found at (github.com).
  3. Lastly, Chainlink PoR/Functions will push a signed NAV/AUM report to the fund’s controller, and we’ll apply some guardrails for the mint/redeem process. Learn more at (chain.link).

B) Private credit, receivables, and trade finance

• Documents: You can create invoices, purchase orders, eBLs, and warehouse receipts as OpenAttestation/TradeTrust verifiable documents using DNS‑TXT or DNS‑DID. This way, lenders can quickly verify the issuance and transfer of titles. Check it out here!
• Legal enforceability: Make sure you’re aligned with MLETR/ETDA regulations. TradeTrust has shown how eBLs and D‑P flows can work together seamlessly in real-time. More details are available here.
• Onchain triggers: For late payments or dilution events, you can assert these through UMA’s optimistic oracle, which includes a dispute window for borrowers to challenge things. This effectively ties the credit facility’s state machine to verifiable offchain events. Check out the specifics on GitHub.

C) Real estate and titles

• KYC/eligibility: Let’s issue investor credentials using VC 2.0 and stick to those ERC‑3643 transfer rules. You can check it out here: (w3.org)
• Title packets: We can easily notarize chain-of-title documents with OpenAttestation. Don’t forget to store those CIDs! Then, we just publish an EAS attestation that says “Title as of date T held by entity X," and we’ll handle revocation when ownership changes. More details are here: (docs.tradetrust.io)

---

Choosing the right oracle/attestation tool: a simple matrix

• For reliable, often updated numeric data like price, NAV, or utilization, check out Chainlink Data Streams, Pyth, and RedStone. If you’re all about low latency and want costs on demand, Pyth or RedStone would be your go-tos. But if on-chain verification and DON-level SLAs are what you need, Chainlink Data Streams is the way to go. (docs.chain.link)
• When you need collateral backing or reserve checks, Chainlink Proof of Reserve with mint/redeem circuit breakers is a solid choice. (chain.link)
• For arbitrary API computations that require secret handling, check out Chainlink Functions. It’s pretty handy! (docs.chain.link)
• When it comes to subjective or off-chain events like defaults or fraud flags, UMA Optimistic Oracle v3 is worth a look. (github.com)
• If you need web data but want to keep things private, consider using TLSNotary or DECO/zkTLS to notarize HTTPS transcripts without needing to make any server changes. (tlsnotary.org)
• For tracking who attested to what, you can rely on EAS with its schemas and resolvers, or Verax, which offers a registry and portals. (attest.org)

---

Emerging best practices we recommend in 2025

• Let’s stick with VC 2.0 for identity and eligibility credentials. It's best to go for JOSE/COSE or Data Integrity cryptosuites based on what you’re working with. For high-volume revocation, consider using Bitstring Status Lists. (w3.org)
• If you’re dealing with securities-like RWAs on public L2s, it’s a good idea to use ERC‑3643 to define your transfer rules. The DTCC’s 2025 adoption shows that there’s promise for better interoperability with market infrastructure. (dtcc.com)
• Think of attestations as your “indexes” to more complex artifacts. Just put fingerprints (like hashes, CIDs, proof IDs) on the blockchain and keep the actual documents off-chain, securely managed under legal controls.
• Remember to treat NAV and risk metrics as verifiable computations, not just random numbers. If you can’t back up the results from position snapshots and marks, then it’s not really verifiable. Proof of SQL and DON-verified reports will definitely help you here. (github.com)
• Build controls right into your token logic. Link PoR/NAV thresholds to automated circuit breakers or redemption caps to help minimize operational risk. (chain.link)
• Don’t forget to publish machine-readable schemas (like EAS/Verax) and subgraphs early on. This way, integrators can use your attestations without having to reverse-engineer anything. (docs.ver.ax)

---

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

1. Data inventory and schemas

• Figure out all the details your contracts require: things like identity, balances, necessary documents, price/NAV, and any events that might pop up.
• Create schemas for both EAS/Verax and VC contexts; make sure to outline revocation pathways clearly.

2) Source Acquisition and Notarization

• For websites without APIs: Go with either TLSNotary or DECO flow. Just make sure to set up your redaction policy and time-stamps. Check it out here!
• For APIs: You'll want to set up Chainlink Functions tasks using threshold-encrypted secrets. Don’t forget to define your SLAs and retry strategies. You can find more details here.

3) Storage and Indexing

• Store your original files on IPFS or Arweave, and make sure to link the CIDs with their attestation IDs. For your analytics needs, consider setting up Proof of SQL pipelines. Check it out here: github.com

4) Onchain Transport

• Choose your oracles: For those numbers, go with Data Streams, Pyth, or RedStone. For events, UMA is your go-to, and use PoR for reserves. Don’t forget to wire everything to your controller contracts. Check out the details here!

5) Verification and Policy

• Create verifiers like EIP‑712 and EIP‑1271, set up EAS/Verax resolvers, and develop policy modules for functions like pause, limit, and mint-gates.

6) Observability and Audits

• Set up dashboards that show attestation graphs and proof freshness; make sure to emit events with the relevant CID/proof IDs.

Key KPIs:

• Data freshness (in minutes)
• Proof generation cost/time
• % coverage (how many facts have proofs)
• Dispute rate (specifically for optimistic flows)
• Mean time to revoke/replace credentials

---

Real‑world example blueprints

• Tokenized Fund NAV Pipeline
  • Inputs: We pull in custodian balances from TLSNotary, our positions database (warehouse), and prices from Data Streams or Pyth.
  • Compute: We run a Proof of SQL for our NAV, perform a secondary DON verification, and set up a Proof of Reserves feed for those AUM guardrails.
  • Outputs: You’ll get the EAS attestation “NAV_t”; the controller keeps things in check by enforcing mint/redeem caps if the NAV or AUM starts to go off track. (tlsnotary.org)
• eBL‑backed receivables
  • Inputs: TradeTrust eBLs (using DNS‑TXT issuance) and bank D/P confirmations, all nicely notarized through TLSNotary.
  • Oracle: We use UMA to assert that the “invoice settled on T,” giving a 48-72 hour window for disputes.
  • Onchain: When the settlement attestation is confirmed, pool share payouts get triggered. (docs.tradetrust.io)
• Permissioned Real Estate Fund Units
  • Token: ERC‑3643 with ONCHAINID; transfers are gated by VC 2.0 “QIB/QP” credentials and geographic claims.
  • Registry: Verax/EAS to show investor eligibility attestations to distributors and compliance bots. (erc3643.org)

---

Vendor and tooling snapshot (2025 signal strength)

• Chainlink: Check out their Functions for custom compute, Data Streams that deliver low-latency signed reports, and PoR for reserve checks. You can learn more here.
• Pyth: They've got some seriously quick pull/push feeds that work across multiple chains. If you're curious, dive into the details here.
• RedStone: This one's a modular pull oracle that features a ”Atom” for liquidation awareness and an ultra-fast “Bolt” for speed; plus, they’re expanding their RWA/NAV data offerings. Get the scoop here.
• UMA: Their Optimistic Oracle v3 is designed for handling arbitrary facts with dispute windows, and they just hit a milestone with over 60k assertions! Find out more here.
• TLSNotary / DECO: They offer privacy-preserving proofs of HTTPS data, which is really cool. Check it out here.
• TradeTrust/OpenAttestation: These frameworks are all about creating verifiable trade documents that align with MLETR regulations. Learn more here.
• EAS / Verax: They provide generalized attestation layers complete with schemas, resolvers, and explorers. Discover the details here.
• Space and Time: Their Proof of SQL is perfect for verifiable analytics over datasets that aren't on-chain. Check it out on GitHub.

---

What “great” looks like in 2025

• Every claim about the asset--like eligibility, title, balances, NAV, and events--comes with a signed attestation that you can actually trace back to the original document or proof (CID).
• Our calculations are clear and easy to verify; whenever possible, they're done upfront through ZK‑verified queries or DON‑verified reports. Check it out here: (github.com).
• We enforce controls using code: mints and redemptions are gated by Proof of Reserve (PoR), covenants are linked to assertions, and we keep things fresh with price/NAV checks that affect collateral haircuts. Find out more at (chain.link).
• The whole system is super clear for integrators: schemas and subgraphs are available for anyone to view, plus we’ve documented dispute windows and revocation methods.

---

How 7Block Labs can help

Our RWA Verifiable Data Accelerator can roll out a production pilot in about 8 to 10 weeks:

• Week 1-2: We’ll kick things off with schema design focusing on VC 2.0 and EAS/Verax. We’ll also dive into oracle selection and start some threat modeling to keep everything secure.
• Week 3-5: Next, we’ll work on notarizing source data using TLSNotary and DECO. We'll set up storage solutions and get those PoSQL pipelines going. Plus, we'll deploy some attestation registries. Check it out at (tlsnotary.org).
• Week 6-8: During this phase, if necessary, we'll integrate on-chain controllers (think ERC‑3643), set up verifiers, and automate some policies using PoR/NAV gates. Learn more at (erc3643.org).
• Week 9-10: Finally, we’ll focus on observability and audits, wrapping things up with go-live runbooks to ensure a smooth launch.

You don’t need to tokenize everything all at once. Just kick things off by verifying your offchain truths, and then let composability take care of the rest.

---

Further reading and signals

• The world of tokenized treasuries is booming, hitting a record market cap of $4.2 billion, thanks in part to the recent crypto correction. Check out the full story on CoinDesk.
• The new VC 2.0 standards family has arrived, covering everything from data models to JOSE/COSE, data integrity, and status lists. Dive into the details on W3C.
• Need a hand with TradeTrust/OpenAttestation? These guides cover DNS‑TXT and DNS‑DID issuance and verification to help you get started. You can find more info over at TradeTrust Docs.
• If you're looking into oracle design patterns, there’s a lot to unpack with data streams, functions, and Pyth/RedStone approaches, whether you prefer pull or push. Explore it all on Chainlink Docs.
• Curious about how to use the UMA Optimistic Oracle v3? You can check out the usage metrics and more on their GitHub.
• Looking for some insights on Proof of SQL? The documentation and examples are waiting for you on GitHub.

---

7Block Labs creates solid, verifiable data foundations, ensuring that your RWA isn’t just floating around on-chain--it continuously validates itself.