Domain Atlas — Treasury Approval Demo

A two-minute, no-installation demo of K-of-N multi-party approval, built entirely on Domain Atlas's existing signed-payload mechanism (SPEC.md §6.2).

Click below and this page generates three independent keypairs, standing in for three bank officers, plus a fourth for whoever's receiving the transfer. Requesting a transfer creates a real pending record on this domain's own server — nothing executes yet. Only once two of the three officers each independently fetch the exact request and sign it does the transfer actually happen: a real credential, minted live by this domain, exactly the same mint every other demo class on this site already uses. One signature alone is provably not enough, and a signature over anything other than the real request is provably rejected — try the "forge a signature" button below to see that for yourself.

What this looks like for a real organization

Swap "bank officer" for a company director, a treasury team member, or a co-signer on a shared account — the same control real corporate treasuries already use for wire approvals ("dual control," the four-eyes principle), done with signatures instead of a bank's own internal workflow tooling. Removing an officer who's left the company would use the exact same revocation mechanism every other credential in this protocol already has — no separate access-control system needed alongside it.

Step 1 — set up the demo bank

Generates three officer keypairs and one recipient keypair, all in this tab.

Step 2 — request a treasury transfer

Requires 2 of the 3 officers above to approve before it executes.

Amount Memo (optional)

Step 3 — approve as each officer

Each button below independently fetches the pending request fresh from the server and signs exactly that — never a value cached from step 2 — the same way a genuinely separate officer's own device would. This is what makes the signature mean anything: a compromised or dishonest requester showing different officers different amounts would still fail here, since every signer checks the server's own record for itself.

View raw pending request

Nothing here is faked to make the demo work: the mint on execution is a genuine signed credential from this domain, verifiable the same way every other asset on this site is (fetch .well-known/atlas-key.json, check the signature, check the revocation list). Two things this demo deliberately simplifies, stated plainly rather than glossed over: the three officer keys live in one browser tab instead of three separate devices (same single-page trick the attestation demo uses for its own second identity — the protocol works identically across genuinely separate devices, this just keeps the walkthrough to one page), and the list of who's authorized to approve is named directly on each request rather than backed by a persistent, revocable membership credential the way a real deployment should use — see this page's own source and the issuer's server-side comments for the reasoning on both. Back to the plaza.

A transfer that needs two signatures, not one

What this looks like for a real organization

Step 1 — set up the demo bank

Step 2 — request a treasury transfer

Step 3 — approve as each officer