RWA Token Analysis: What OnChainRisk Checks in a Tokenized Asset

Why a normal token scanner is not enough for an RWA

A conventional token scanner reads bytecode and transfers. For a tokenized real-world asset that is only the outermost layer. The token is a claim on something off-chain — a fund share, a treasury bill, a note — and the interesting questions are about the gap between the contract and the asset: who issued it, what legal claim it represents, what the issuer can do to your balance, and which of those answers are observed versus merely asserted.

As the due-diligence guide puts it, on-chain observation, an issuer statement, a governing document, a regulatory record and an independent verification are five different kinds of evidence. RWA analysis is the product that keeps them separate instead of flattening them into one verdict.

Current scope: an Ethereum-mainnet contract address

RWA V1 currently analyzes Ethereum-mainnet token contracts. The analysis is anchored to a specific Ethereum contract address, rather than trying to identify an asset from a ticker, symbol or token name. RWA recognition is then resolved against the product's registry and evidence authorities — the contract address fixes which object is analyzed; it does not by itself establish the real-world asset.

That precise scope is deliberate: the analysis is only as trustworthy as the on-chain object it is pointed at, and a contract address is an unambiguous subject to anchor to.

Recognition, and why it fails closed

Rather than forcing every address into “RWA” or “not RWA,” the system distinguishes authoritative from operational states. A contract can be recognized, recognized but out of the current product scope, determined not to be an RWA, or simply unrecognized — and, separately, the registry it is checked against can be present, authoritatively absent, or temporarily unavailable.

The design fails closed: an operational inability to establish something is never rewritten as a negative finding. “We could not check the registry right now” is not “this is not an RWA,” and an unknown or unsupported registry state is not evidence of absence. That distinction runs through the whole report.

What Preview shows

A recognized, product-eligible asset has a high-level Preview and, where eligible, a deeper Full report. Preview is structural identity only — it does not leak the evidence-rich Full material. Where established, Preview can show the recognized result, the contract and network, the asset name/class, the issuer name and jurisdiction, a verified ERC-20 observation, a recognized RWA standard family, the presence of a standardized permissioning interface, and a coarse data-acquisition completeness indicator.

Full is a per-report purchase, and it is owned permanently once bought (more on the model at the end). Preview is not a free copy of every Full section.

What a Full report can investigate

Depending on the asset and the available evidence, a Full report can cover: asset and contract identity; ERC-20 detection; the recognized RWA standard family; a standardized permissioning-interface presence; proxy architecture, upgradeability, minting, pause, freeze/blocklist and forced-transfer/clawback capabilities; privileged controllers and roles; acquisition completeness; legal ownership/title evidence; the underlying claim and representation; the issuer and operating parties; dated reserves/portfolio composition; redemption terms and mechanics; offering/regulatory material; documentary controls; and the provenance of every fact.

Not every report contains every section. A category appears only when the analysis actually has evidence for it — the sections below are what the report can include, depending on the asset.

Token standard, RWA standard family and permissioning

The analysis can establish that a contract implements ERC-20, and can identify a primary RWA standard family where present — currently ERC-3643 (the T-REX permissioned-token standard) and ERC-7943 (uRWA). This list is primary and non-exhaustive. If the standard family cannot be established, the correct result is unknown — not “a plain, unrestricted ERC-20.” Absence of a detected family is not a finding of absence.

For a recognized ERC-3643 or ERC-7943 asset, the report can note that the relevant standardized permissioning interface was observed (for ERC-3643, an identity-registry + compliance module; for ERC-7943, the uRWA interface). Observing the interface means a mechanism exists. It does not mean a given holder is eligible, that the token is legally compliant, that any specific wallet is approved, that transfers are currently blocked, or that every transfer restriction has been characterized.

On-chain controls and privileged controllers

The report has positive-only detection for control capabilities: proxy architecture, upgradeability, minting, pause, freeze/blocklist and forced-transfer/clawback. A detected control means the capability was established in the analyzed contract/runtime at the observed blockchain state. It does not prove the capability has ever been — or ever will be — exercised, nor that the issuer intends to, nor that a given holder is currently affected. And the inverse matters just as much: if a capability is not established, that is not a finding that the token “cannot be frozen” or that the contract is “non-upgradeable.” Unknown is not false.

Where established, the report can show the privileged controllers tied to actual roles and addresses, distinguishing descriptive on-chain types — an externally-owned account, a multisig, a timelock/governor, another contract, or unknown — and can enumerate roles within bounds (fully enumerated, partially enumerated, interrupted, capped, or non-enumerable). This is an on-chain control observation, not a governance-quality judgment: “multisig observed” is a fact about structure, not a verdict that governance is “secure.”

Legal, issuer, reserves, redemption and offering evidence

Where evidence exists, the Full report can include structured material about legal ownership and title, what the token represents, backing and the underlying claim, wrapper layers, the issuer or legal entity, and jurisdiction. This material is presented as claims and evidence, tied to sources — the report does not assert legal conclusions from token metadata, does not prove you legally own the underlying asset, and is not legal advice.

It can identify the issuer and operating parties from issuer disclosures, governing agreements or regulatory filings, keeping the brand, issuer, fund, manager and custodian distinct rather than collapsing them into one entity — and it does not invent a party it has not established.

For supported assets, it can display dated reserves/portfolio composition from issuer-published breakdowns, SEC-filed fund composition, or issuer overviews — preserving whether a figure is issuer-published or independent, its as-of date, and published-versus-recomputed values. A dated issuer disclosure is a dated issuer disclosure: it is not continuous or independent proof of reserves.

Where documented, it can surface redemption terms, mechanics and routes — how the issuer describes redemption and what process it depends on, which is not a statement that any particular person is eligible to redeem. And it can include source-backed offering/regulatory material — claimed regulatory bases, offering eligibility, registered-fund or private-placement terms, investor classes — drawn from filings and agreements. A claimed regulatory basis in a filing is exactly that: it is not government or SEC approval, not a finding of legal compliance, and not a statement that the asset is available to all investors.

Documentary controls vs observed on-chain capability

For assets whose governing documents support it, the report can surface documented transfer-authorization, issuance/burn-integrity and remediation obligations. These are kept strictly separate from on-chain observations: a document stating that a control right or obligation exists does not prove on-chain enforcement, that a transfer is currently blocked, that a wallet is currently restricted, or that a control is being exercised. “Documentary control” and “observed on-chain capability” are different columns in the evidence, and the report keeps them that way.

Evidence provenance — the core idea

This is the heart of the product. The report does not give every fact the same status. Full-report facts preserve provenance and source references where the underlying evidence provides them, and the report distinguishes authorities such as on-chain verified, issuer claim, independent evidence and derived. The same principle the due-diligence guide argues for conceptually — that an issuer statement is not a governing document is not a regulatory record is not an independent verification — is operationalized here: the report is designed to preserve how an established fact is known rather than flattening different evidence authorities into one status.

Acquisition completeness is not a risk grade

A Full report carries an explicit acquisition-completeness ledger across seven on-chain sections: proxy architecture, controller discovery, role enumeration, controller screening, token standard, capability discovery and transfer control. Each is complete, degraded or unavailable. This describes whether the data-acquisition work finished — nothing more. “Complete” does not mean the asset is safe, and “unavailable” does not mean it is unsafe; it means acquisition did or did not finish for that section.

Why “unknown” is a valid result

When evidence is insufficient, the report says so — unknown, not evaluated, not observed, or degraded/unavailable acquisition — rather than inventing a positive claim. This is a design choice, not a gap to hide: the product prefers an honest unknown over a fabricated certainty. It mirrors the argument in why binary “clean/dirty” labels misread blockchain risk: unknown is neither safe nor unsafe, and collapsing it into either is how false conclusions start. It is also why the report does not reduce to a single number — a risk score is a useful triage input elsewhere, but an RWA's evidence is too heterogeneous to compress into one figure without losing the authority behind each fact.

What the report can and cannot conclude

The clearest way to read the report is to keep the observation separate from the inference someone might be tempted to draw from it.

Preview vs Full, and ownership

Preview is the high-level identity view. Full is the evidence-rich report, available as a one-time purchase per RWA report — and once purchased it is owned permanently. A subscription does not grant Full access to RWA reports; only an explicit per-report purchase does. Each authoritative analysis is persisted with its own report ID and a frozen evidence snapshot (model and registry versions, registry snapshot hash, Worker release provenance, the subject contract and the evidence), so a report preserves the exact evidence used for that analysis. It does not silently turn an old report into current state; re-analysis is a separate, explicit step when appropriate.

Where to go deeper

If you want the conceptual framework behind all of this — the questions to ask before trusting any tokenized asset — read The Token Is Not the Asset: a practical due-diligence guide for RWA investors. This product turns that checklist into a structured, source-preserving report for a single Ethereum contract.