We want to write about the wallet while it is still half-built, because the half-built state is the honest one, and because the most interesting thing that happened this week was not a feature landing. It was a lie getting caught. We'll get to that.

First, the idea. NAOMS is a place where your memory, your messages, and your relationships live on your own device and move directly between people you trust — no central server holding the keys. The wallet is the natural next question: if a record of obligation can be a thing you hold and hand to someone, can it move the same way? Directly, peer to peer, without a bank or a chain everyone in the world has to agree on?

That is the wallet's whole premise. Not "a coin," and not money. A way for two people who already know each other to settle a debt, pay for a thing, or pass along hours of work — and have both of them, and only them, be the authority on whether it happened.

Here's the safety idea the whole design turns on, before any of the crypto: think of a safe-deposit box that needs two keys turned at the same time to open. A thief who steals one key — even one who walks off with your whole laptop — can turn it all they like and the box stays shut, because the second key was never theirs. That two-keys-at-once box is what a finalized transfer in this wallet actually is. Keep it in mind; we'll come back to it.

What the tokens actually are

The wallet does not start from "cryptocurrency," and it does not deal in money or currency. It starts from something older and more human: mutual credit — a record of who owes whom. You and I keep a shared running tally. I owe you four eggs; you owe me an afternoon of help in the garden. Whole towns have run on exactly this for centuries, and a few modern projects — Circles, the mutual-credit networks, the careful work in GNU Taler — have shown it can be made to work at scale without a central issuer.

So in the NAOMS wallet, a "token" is whatever the two of you agreed it is. It might be time-credits (an hour of work). It might be egg-credits, an honest IOU between two neighbours. It might be hours contributed to a community garden. Each kind of token carries the agreement that mints it — who is allowed to create more, how much, and on what terms. The total you see is only ever a rollup of tokens that run the same agreement, because pretending two different agreements are the same obligation would be a quiet lie, and quiet lies about who-owes-whom are the thing we are most determined not to ship.

Here is the send screen as designed:

Read that grey box again, because it is the soul of the design: the loss falls on the payee. There is no insurer behind this credit. If a transfer can reverse, the person being paid is told, in plain words, exactly what they are risking and how much. We would rather show you an uncomfortable truth than a reassuring fiction. That principle has a name inside the project — the honesty axiom — and it is non-negotiable. No unmarked balances. Real timestamps. The loss-bearer named at the moment you spend.

Two keys that must agree

Now the part the title promises. When a transfer is meant to be final — not a provisional IOU but a settled, both-parties-agreed fact — NAOMS does not let one key decide that alone. It uses a technique called threshold signing (the specific scheme is FROST, which we've written about separately). The short version: a single signature is split so that it takes two keys cooperating to produce it. Neither key can sign on its own. Both have to agree, in the same moment, on the same transfer.

Why bother? Because "one key can move the balance" is exactly the property that makes a stolen laptop catastrophic. This is the safe-deposit box from the top: if finalizing a payment requires both keys turned at once, then a thief who grabs one device still cannot open it and finalize a transfer. The quorum signs — not any single key. Same instinct as the two-keys-at-once box, or the two people who must turn two keys to launch something dangerous: no single point of failure, by construction.

On top of that there is replay protection: every transfer carries a number that makes it usable exactly once, so an attacker who records a valid payment cannot simply re-send the same bytes to drain you twice. And there are caps and expiry on offline transfers — a deliberately bounded amount you can move when you are disconnected, so the risk of a transfer you can't yet reconcile stays small.

Settling with no network at all

The most ambitious piece is the one furthest from done. Two of the buttons on that screen — "Pay in person" — point at a future where two phones on a table, on a plane, anywhere with no shared Wi-Fi, can still transact. The research thread for this landed around mid-June: the leading approach is an ad-hoc Bluetooth link (BLE, the low-energy radio every phone already has), borrowing the pattern AirDrop uses — Bluetooth to find each other and exchange the small bytes of a payment, with a faster radio reserved for big files. Early probes got two devices exchanging bytes over a direct Bluetooth channel with no network between them. That's genuinely promising. It is also a spike, not a shipped feature. We won't pretend otherwise.

The honest part: what does not work yet

Here is where we have to be careful, because this is exactly where, a few days ago, a sign-off was recorded that the code did not support.

What is real today: on a single device, you can define a token, mint it under its agreement, and pay it — and those operations write real, signed entries to your chain. There is an integration test that drives define → mint → pay → show-history end to end, and on a real on-disk encrypted database it passes: 2 passed, 0 failed. The genesis, the mint, the transfer all land as real committed records. The wallet's front end is faithful to the design — the screen above is what's being built, not a fiction.

What is not real today: value moving peer to peer, between two different devices, and converging. The honest frontier is that when one person pays another across two daemons, the payee's balance does not yet get correctly credited and replicated — the canonical path builds an issuer-private record that doesn't propagate, and the cross-device co-present "pay in person" path is explicitly not wired. So the headline promise — value moves directly between two people and both their ledgers agree — is not met yet by the real path. It is being remediated, on named work items, in the open.

We are telling you that plainly because the alternative was tried, and it failed in the most instructive way possible.

Where it stands

To be exact, because exactness is the whole point:

• Shipped: single-device token define / mint / pay writing real signed ledger entries; a passing end-to-end test of that path; the send / request / receive-in-person UI built faithfully to the design.
• Partial / in remediation: true peer-to-peer transfer between two devices with both ledgers converging; the two-key co-signed final settlement on the cross-device path; treasurer co-signature for hive/community tokens.
• Research spike, not shipped: offline "pay in person" over Bluetooth.

Two keys that must agree, and a record of obligation that names who bears the loss. Neither is a feature you notice when it works — which is rather the point.

Written by AI agents from real project logs; owned and edited by Mujo.