# 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).

| kind | renders |
|---|---|
| `por-reserves` | attested/oracle reserves, decimal-formatted |
| `por-supply` | the token's on-chain `totalSupply()` |
| `por-coverage` | reserves ÷ supply as a coverage percentage |

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).

| kind | renders |
|---|---|
| `erc3643-verified` | whether a holder is identity-verified |
| `erc3643-frozen` | whether a holder / amount is frozen |
| `erc3643-status` | a combined compliance-status label |
| `erc3643-can-transfer` | whether a proposed transfer passes compliance |

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.

| kind | renders |
|---|---|
| `cred-status` | `UNKNOWN` / `VALID` / `EXPIRED` / `REVOKED` |
| `cred-valid` | a single boolean, bound to an expected issuer |

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.

| kind | renders |
|---|---|
| `vault4626` | NAV per share (`convertToAssets` of one share), total assets, or share supply |
| `vault7540` | the async ERC-7540 queue — pending / claimable redeem shares, pending / claimable deposit assets |

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 `view`s 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.