The listing asks. The wallet answers yes or no.

Keyless, and provably so

The catalogue issues nothing and signs nothing. It verifies what renters present and publishes what landlords list, and holds no key for either. A wire contract and a source-wide scan fail if that ever changes, so the asymmetry is enforced by the build rather than by convention.

It reads the issuer keylessly too. Trust is resolved through a configured allowlist of issuer base URLs, which is why the trust layer already carries issuers other than itself — a credential from the European Commission's reference issuer verifies end to end, on the same path as one of ours.

A Dutch profile of an open standard

Listings are served on the RESO Web API — the data standard the industry already speaks — validated as valid metadata on Data Dictionary 1.7 by RESO's own tool, run against the live catalogue rather than a local build. Sixty-two fields on the property resource: forty the standard's own, twenty-two local extensions.

Twelve of those extensions derive from Dutch statute rather than from us — the rent segments created by the Affordable Rent Act, the points score that determines them, the legal rent ceiling that follows, the room-rental permit regime, the energy label and the property valuation that feed the score, and the contract and construction designations the Civil Code defines. The rest are market convention or the catalogue's own plumbing, and the distinction is not cosmetic: a field that encodes a statute changes when the statute changes, and one that encodes a convention does not.

Stated at the level the artifacts support: this is a served schema with its derivations recorded, not yet a published specification a third party could implement from alone.

Every event in a Merkle tree. No person in it.

Each act in a letting becomes a leaf in a log built as an RFC 9162 Merkle tree — the construction that made the web's certificate authorities auditable. Leaves hash upward until the whole history is a single value, and that value is what gets signed.

Three requests, no account and no permission

• The signed headOne commitment to the whole log, signed with ES256 — by the orchestrator, not by the catalogue serving it.
• An inclusion proofThe audit path from any single entry to that head, in log n steps rather than n.
• A consistency proofWhether an older head is still contained in today's. This is the request that catches a rewritten history.

A doctored history can always be re-signed into a tree that looks sound on its own. What it cannot do is still produce the root an earlier head was already signed over — so the third request is the one that decides. The responses, with a proof walked through end to end, are on the evidence page.

What is published, and what is withheld