RWA capabilities

ChainRender is a rendering + on-chain-verification layer, not an asset platform: it issues nothing and custodies nothing. Its floor guarantee is a faithful render of on-chain state — never a guarantee that the underlying real-world fact is true. For real-world assets that makes it strong at displaying and cryptographically verifying asset state, and deliberately silent on custody, settlement, and legal wrappers. Every resolver below is deployed on all three testnets (Sepolia, Robinhood, Circle Arc), ownerless and immutable, view-only, and fails closed — a reverting or missing source renders "unavailable", never a fabricated value.

Proof of Reserve

ProofOfReserveResolver reads a reserve source (an attested reserves figure and/or a Chainlink Proof-of-Reserve feed) and a token's totalSupply(), and renders reserves, supply, and a coverage ratio, with freshness enforced (a stale feed renders STALE, not a number).

Args are caller-supplied — abi.encode(feed, token, fracDigits, maxStaleSeconds) — so the resolver has no embedded dependency and the same deployment reads any feed/token the caller points at. Because the coverage ratio is computed on-chain from view calls, an honest reserve display grades A: an under-collateralised position renders as exactly that (e.g. 95%), never hidden.

ERC-3643 permission display

Erc3643PermissionAdapter reads an ERC-3643 permissioned-token stack — its identity registry and compliance module — and renders holder/compliance state. It is display, not enforcement: it shows whether a transfer would be permitted; it never gates one. Anything that moves value or grants a role must re-check on-chain (a view call's result can be computed against any address a caller claims).

Its reads are genuine on-chain view calls, so the data edge is on-chain — but because the identity registry and compliance module are mutable, authority-controlled dependencies (an admin can change verification or freeze state at any block), the capability is graded ≤ C on the dependency axis. That is the honest trust envelope: the render is a faithful snapshot of a mutable authority's current state, not a trustless guarantee.

Credential lifecycle (issuer-binding, expiry, revocation)

CredentialStatusRegistry is an ownerless, issuer-scoped registry where an issuer can attest, renew, and revoke a credential, each with an expiry; CredentialLifecycleResolver renders its state. This closes the gap left by a bare "member-of-set" proof: a credential now has a real KYC/accreditation lifecycle.

Status is derived from an on-chain read (data edge on-chain); the expected-issuer binding means a credential attested by the wrong key reads as UNKNOWN rather than being silently trusted. As with ERC-3643, the registry is a mutable authority, so a credential badge is a faithful render of the issuer's current attestation — not proof the underlying claim is true.

Tokenized-vault NAV (ERC-4626 / ERC-7540)

VaultResolver reads a tokenized vault — the standard shape for tokenized treasuries, money-market funds, and other yield-bearing RWA wrappers — and renders its share price and queue state trustlessly. It covers both the synchronous ERC-4626 surface and the asynchronous ERC-7540 redemption/deposit queue in one resolver.

Args are caller-supplied — vault4626 takes abi.encode(vault, assetDecimals, shareDecimals, field); vault7540 takes abi.encode(vault, controller, requestId, assetDecimals, shareDecimals, field) — so the same deployment reads any 4626/7540 vault the caller points at. Both read genuine on-chain views and grade A on the data edge. The trust boundary is the vault's own accounting: convertToAssets / totalAssets are what the vault reports, not a claim that its valuation is correct — the card states this, exactly like the Proof-of-Reserve and oracle cards. It fails closed to "unavailable" on a non-vault, a revert, or degenerate decimals (_pow10 guards decimals > 36).

The Explorer demonstrates it over an immutable DemoVault (no setters) so the NAV and queue render live; re-point the slot args at a real ERC-4626/7540 vault with no code change. This composes with por-coverage (backing) and price (NAV in USD) for a full tokenized-vault panel, and closes the top RWA gap beyond proof-of-reserve.

What this is not

There is deliberately no chain-level compliance enforcement (no deployed identity registry / partitions / freeze / forced-transfer of our own), no custody, no settlement or on-ramp, and no legal-wrapper enforcement. Render-time gates are UX, not a security boundary. The genuine RWA differentiator here is the honest floor: on-chain reads rendered faithfully, with the trust grade telling you exactly how much to trust each one.

On the roadmap — watch list

• ERC-8262 (Zero-Knowledge Compliance Oracle, Draft). A standard for on-chain ZK compliance attestations (AML/sanctions) via UltraHonk proofs. Not implemented. If a live ERC-8262 oracle appears, the in-scope fit is a display-only compliance-status resolver in exactly the ERC-3643 mould above — render the oracle's boolean/ attestation, never be the oracle. Its UltraHonk proving system is the Barretenberg/Noir stack already chosen for the credential/privacy surface, so the toolchain aligns if the prover side is ever built.