01
A denomination, not a market
You should be able to: Explain why denominating obligations in a circulating unit avoids the per-asset liquidity trap.
The illiquidity of real-world-asset tokens is structural, not a marketing failure: a token that is its own market needs buyers and sellers of that exact asset present on the same day. Most days they are not, so the token cannot trade at a fair price, or at all.
`rwa/1`’s answer is to stop giving each asset a unit. Obligations are denominated in a unit that already circulates across the whole estate, so the thing a holder holds is fungible with every other holder’s, regardless of which asset backs it. The asset is described and its obligations are recorded; the liquidity lives in the shared denomination, not in a per-asset market that has to be created from nothing.
That is the whole design intent, and everything else in the format serves it: make the denomination legible to a machine, and make the claims behind it checkable by a stranger.
Source: FlashyOS — @flashyos/assetmesh (rwa/1)
02
The document and the asset
You should be able to: Describe the served file and the fields an asset carries.
An organisation serves one `rwa/1` file at `/.well-known/rwa.json`: an issuer, an emit time, and an array of assets that may be empty — an empty register is honest. A stranger fetches it and checks it offline; there is no account, no server and no chain in the loop.
Each asset carries an id (`prefix/slug`, never reissued), a kind (Property, Instrument, Credential, Work or Place), a dotted class like `real-estate.commercial`, and a jurisdiction as an ISO code. The kind-to-prefix map is checked, not merely conventional, and it mirrors `directory/1` deliberately so an asset id resolves in the same graph as everything else the estate publishes.
So an asset is not a free-text description; it is a typed, addressable record whose identifier lives in the estate’s one namespace. That is what lets other records reference an asset by id rather than restating it — the same cite-don’t-copy discipline the vocabulary format keeps.
Source: FlashyOS — rwa/1 mirrors directory/1
03
Attestations: somebody else’s claim, dated and expiring
You should be able to: Explain the independence and expiry rules on an attestation.
An attestation is a claim about the asset — an appraised value, audited financials, custody, title — carrying what is claimed, its value, the date it is true as of, who makes it, and an expiry after that date. Money is recorded as integer minor units with a currency and decimals, never a float.
Two rules make an attestation worth anything. First, an independent claim is not the issuer’s to make: `appraised-value`, `audited-financials`, `custody`, `title`, `insurance`, `environmental` and `occupancy` may not be attested by the issuer themselves — an appraisal signed by the owner is just a number in a PDF, and the whole value of the record is that somebody else put their name to it.
Second, every attestation expires. An undated 2019 valuation presented as current is the most common way an asset record misleads without anybody lying, so decay is structural: a claim nobody restates stops counting on its own, exactly as in `directory/1` and `defined/1`.
Source: FlashyOS — an independent claim is not the issuer’s to make
04
Obligations: what a holder is owed
You should be able to: Describe an obligation and the rule that a reward may not be performance-linked.
An obligation records what a holder is owed against the asset: its kind (reward, revenue-share, equity or debt), whether its worth is performance-linked, its denomination and units, and the organisation on the hook to honour it. Every obligation answers the performance-linked question — the field is required, not optional.
It is required because of the format’s sharpest refusal: a reward may not be performance-linked. An obligation whose worth rises with rent, occupancy or sale proceeds is an investment contract nearly everywhere it is offered — a matter for counsel and a prospectus, not a loyalty programme. Making the field required means the question is answered on every obligation ever emitted, structurally, rather than in a README nobody reads.
This does not make a compliant instrument legal, and no format could. What it does is make the one shape that is reliably a security impossible to emit by accident — which is the honest limit of what a record format can do for you, stated plainly.
Source: FlashyOS — a reward may not be performance-linked
05
Five refusals, not warnings
You should be able to: Explain why the validator refuses rather than warns, and what that buys.
The `rwa/1` validator implements a small set of rules, and each is a refusal with a code, never a warning: a reward cannot be performance-linked, an independent claim cannot be self-attested, an attestation must carry an expiry after its as-of date, and so on. An invalid document does not render with a caveat; it does not validate.
Refusing rather than warning is the difference between a format that guides and one that guarantees. A warning is advice a busy issuer clicks past; a refusal is a document that cannot exist in the broken shape, so the guarantee holds for every reader without anyone having to have read the warning.
The lesson generalises past assets: when a mistake is both easy to make and expensive to make — here, accidentally emitting a security — the honest design encodes the constraint as a refusal the emitter cannot skip, not a note it can ignore. That is why every record format in this estate refuses by name rather than cautioning in prose.
Source: FlashyOS — a projection refuses rather than trims
