The listing asks. The wallet answers yes or no.
RESOnance matches a renter's sealed verdict — or a buyer's sealed position at a bid — against what a listing requires, and learns nothing else. It holds no signing key — which is not a policy but the reason a catalogue can be trusted with a match it has no power to forge.
A market that can prove itself
The housing market runs on assertions today. An agency says it chose fairly; a listing says the home is still available; a report says how long rentals take, or what homes sold for. None of it can be checked by anyone who did not write it. Two mechanisms change that: a public log that nobody can rewrite, and a viewing booker that runs on verdicts instead of phone calls.
- Fair process, provableEvery public act in a rental or a sale — the listing, the mandate, the applications and bids, the credentials, the award — is a leaf in a signed log that can only grow. An agency no longer asserts that it ran a lawful procedure: the order of events is there to be checked, by a regulator or a municipality, without asking anyone for access.
- Sale prices on the recordA completed sale closes on the catalogue with its price and date, and an estimate is drawn from the catalogue's own closed sales — asking against transaction price, price per square metre, by city — so a buyer compares against what homes actually sold for.
- Figures nobody can inflateHow long a rental took, how many applied, whether it completed — published per listing and derived from the log, so a figure is checked against the record rather than trusted from whoever reports it. A market index across listings is what this makes possible; none is published yet.
- A viewing only for someone who qualifiesThe verdict comes before the viewing, not after. No credential, no booking; a renter below a listing's published income requirement cannot take a slot unless the agent admits them, and that decision is logged. No slot goes to someone who could never be chosen, and no renter travels to a home they cannot get.
- Viewings without the phone callsSlots are booked by the renters themselves, first come, with no score; deadlines and the waiting list run on their own. The agent's time goes to the decision, not the calendar.
- Viewing times any portal can showPublished on the open standard's open-house resource, with their timezone, so any consumer of the catalogue can show them beside the listing.
Keyless, and provably so
The catalogue issues nothing and signs nothing. It verifies what renters and buyers present and publishes what owners list, and holds no key for either. A wire contract and a source-wide guard 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 match is made against predicates rather than against a file: where a criterion is met at the issuer-computed tier, what the catalogue learns is a sealed yes-or-no — meets the requirement at this rent — and not the income behind it. The wire carries predicates today, which is what makes the next step cheap: a zero-knowledge proof can be layered in behind the existing seam without re-issuing a single credential.
On a sale it renders what the issuer stated about a buyer and computes nothing itself. A buying agent may present a buyer's position on their behalf, and the catalogue accepts it only while the buying mandate that authorises it is live.
Every event in a Merkle tree. No person in it.
Each act in a rental or a sale 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. What it gives the market is a history that nobody — not the agency, not us — can quietly rewrite.
Three requests, no account and no permission
- The signed headOne commitment to the whole log, signed with ES256 — by Ravel, not by RESOnance 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
Published
Process facts, per listing: how long a rental took, how many applied, whether it completed; for a sale, its closing price and date. Facts about the transaction, not about the people in it.
Withheld
Anything that could isolate a person. No per-person handle exists on the public record at all. Facts about a rental are published as they are; figures derived from people, such as how many applied, and any agency with fewer than ten lettings are shown in ranges, not exact values, until at least ten stand behind them.
Viewings that run themselves, up to the choice
The agent sets a viewing window, and it divides into slots of a fixed length. Renters who hold a verdict book a slot themselves, first come — there is no score and no lottery — and can add it to their own calendar. A limited waiting list stands behind the slots and moves up on its own when a place frees. The process runs on timers: the draft is reviewed within 48 hours, and a decision is due no later than 72 hours after the last viewing.
Automation stops where the law says it must. Who is chosen is a person's decision, checked by a second, and every step before it — the booking, an override, the invitation — is recorded in Ravel's hash-chained audit log. Ravel runs the viewings; RESOnance is where the renter meets them.
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.
Most 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.
A sale is served on the same resource, as the standard's Residential property rather than
a Residential Lease: its price and price condition — costs payable by the buyer, or free of
them — what is sold (full ownership, an apartment right, a share), the occupancy and, with a tenant, the
lease that passes to the buyer. The Dutch market stage travels beside the standard's status, so an
under-bid sale is visible without bending the standard's own field.
That layer is written down as a working profile, not left as columns for a
reader to reverse-engineer: every extension field with its type, its vocabulary, and the
statutory instrument it carries — article 7:274b of the Civil Code for the senior designation,
7:274d for the student one, the Affordable Rent Act for the bands, article 7:232 for the
arrangements that are not tenancies at all. Five vocabularies are served as a RESO
Lookup resource, so a consumer discovers the permitted values from the wire rather
than from us.
The naming carries the distinction that matters to anyone else who might use it.
Twenty of the twenty-two extensions are
Local_NL_ — Dutch-market concepts another implementer could adopt without
adopting us. Two are Local_Tenon_: our own
signed-liveness mechanism, marked as a vendor extension. Drop those two
and the rest of the profile still stands, which is the point of separating them.
⚠ It is a working profile written by one implementer, not a ratified one. No Dutch body has adopted it and RESO has not reviewed it. It is offered as the thing that did not exist — a written account of what a catalogue must carry to describe a Dutch rental lawfully — and it says so on its own first page.
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.