The dangerous failure in moving value is not theft. It's the half-finished transfer.

A transfer that fully succeeds is fine. A transfer that cleanly fails — nothing sent, nothing received — is annoying but safe; you try again. The state that ruins trust is the one in between: your side says the value left, the other side never saw it arrive. Now there are two histories that disagree about the same fact, and no authority in the room to say which one is true. Every system that moves value has to answer one question before it does anything else: how do you make sure a transfer either completely happens or completely doesn't — with no third possibility?

The usual answer is to put a referee in the middle. A bank, a payment network, a global blockchain — some single ledger that both sides defer to, so there's only ever one story. That works, and it costs you the thing NAOMS exists to protect: you no longer hold your own records. The referee does. This week we shipped a first, deliberately narrow answer that keeps the record in your hands and still refuses to half-finish.

What actually shipped

One person can send value to another, and it lands in the recipient's balance on a different device. No bank. No central ledger. No global consensus. A transfer you make on your device credits your friend's balance on their device, and both devices end up agreeing on the new totals — without ever consulting a third party that both sides trust.

First, the thing this is not. The value moving here isn't money, and it isn't a currency or a security. It's a record of mutual obligation — a shared IOU between two people who have chosen to keep accounts with each other. When we say "send value," we mean: update the honest, shared history of what the two of you owe one another. That distinction isn't legal throat-clearing; it's the whole design. A currency needs the world to agree on it. An IOU between two friends needs only those two friends to agree — which is exactly why it can work with no referee.

Where the value lives

Every pair of people on NAOMS who decide to connect share a private history — an append-only record that both of them can write to, that records the facts of their relationship, and that neither can secretly rewrite. Think of it as a shared notebook only the two of you can open, where nothing already written can be erased.

The value between you lives on a dedicated page of that shared notebook — a per-relationship ledger, sitting on the same private two-party history, that tracks the running balance of who owes whom. Because that ledger belongs to your relationship and not to any central server, there is no global list of everyone's balances anywhere, and there doesn't need to be. Your balance with each friend is a fact that only the two of you keep, and only the two of you need.

Why it can't half-finish

Here is the mechanism that makes a half-finished transfer impossible: a transfer requires both of your devices to co-sign it. Not one signature — two. Your device signs, and the other person's device must also sign, before the transfer is real. Two signatures, both required, no exceptions.

That single rule is what closes the dangerous middle state. A transfer can't be recorded as "sent" on your side unless the other side has already put its signature on the very same transfer. The two signatures are on one act, so there is no moment where your history says the value left but theirs hasn't recorded it arriving. Either both signatures exist and the transfer is fully real on both sides, or they don't and it isn't real anywhere.

And when the other person's device simply can't be reached — they're offline, the network is down — the system does not improvise. It refuses. You get a plain "can't reach the other party to co-sign" refusal, and nothing is credited. It does not optimistically mark the value as sent and promise to reconcile later. A one-sided credit that's waiting to be confirmed is precisely the half-finished state we set out to make impossible, so the design would rather give you an honest "not now" than a hopeful lie.

flowchart TD
  A[You start a transfer on your device] --> B[Your device signs it]
  B --> C{Can the other person's device be reached to co-sign?}
  C -- No --> D[Refused: co-signer unreachable · nothing is credited on either side]
  C -- Yes --> E[Their device co-signs the same transfer · two signatures on one act]
  E --> F[The transfer is recorded on the shared two-party history]
  F --> G[Your balance and their balance both update to the same totals]
  G --> H[Both devices converge — no bank, no central ledger, no global consensus]

There's one more honest property worth naming. Because both sides keep the same shared history and every transfer is co-signed, the two devices converge to the same balances on their own — and if anyone ever tries to cheat, by spending the same value twice or conjuring value that was never agreed, that violation is detectable. It shows up when the two histories are reconciled, and it's accounted for honestly rather than silently absorbed. The system doesn't promise cheating is impossible; it promises cheating can't hide.

The honest edges

This is a first slice, and it is genuinely narrow. We'd rather draw the boundary sharply than let you imagine it's bigger than it is.

What shipped is bilateral, non-transferable mutual credit: a two-person IOU ledger. It works beautifully for exactly two people who keep accounts with each other. It does not yet do the harder things:

• Paying someone in the same room, with no network at all. The offline, face-to-face path — where two devices settle directly between themselves with nobody else reachable — is not shipped yet.
• Value that circulates. These IOUs don't yet pass through a chain of people. A credit between you and one friend can't yet flow onward to a third person and a fourth, the way a passed-around token would. It stays between the two of you.
• Shared and community-governed forms. Value committed against a future obligation, and value minted or held by a group treasury under its own governance, are still ahead of us — not in this release.

And there are a few rough edges we found and filed honestly rather than papering over: a background syncing loop we've parked, and a couple of places where the error message you get when you try to pay someone who's offline is less precise than it should be. None of them let value half-finish — that invariant holds — but they're real, and they're written down as follow-on work, not hidden.

Earning the claim

We have to tell you one more thing, because leaving it out would make this a worse and less honest piece.

This is not the first time we tried to say this was done. Back on June 10th, an earlier version of this exact claim was declared finished — and then retracted, because when the proof behind it was examined first-hand, it didn't hold up. The sign-off was pulled. We don't get to keep a "done" that can't survive scrutiny, so we didn't.

The version you're reading about now explicitly supersedes that retraction. It stands on a proof that was verified first-hand, by actually watching a transfer made on one device land as a balance on another, and watching an unreachable co-signer produce a refusal instead of a phantom credit. The claim is the same sentence it was in June. What changed is that this time it's true, and we checked.

That sequence — claim, retract, rebuild, verify — is not an embarrassment we're confessing. It's the Honesty axiom doing its job. A claim about value is exactly the kind of claim that must be earned rather than asserted, and the only way we know to earn it is to be willing to take it back when it isn't real. This one is.

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

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