The most dangerous object in any sovereign system is the private key, because it is a perfect proxy for you. Whoever holds it can sign as you, spend as you, rotate your identity as you. Encrypt the disk, sandbox the process, hide the bytes — it does not matter. At the moment of signing, the whole key has to exist somewhere, and at that moment a single compromise is total.

NAOMS's answer is to stop letting any one key be enough. The technique is called threshold signing, and the specific scheme is FROST — Flexible Round-Optimized Schnorr Threshold signatures. The promise is simple to state and subtle to build: a signature that looks like an ordinary single signature to everyone who verifies it, but that can only be produced by a quorum of keys cooperating. No single key. The quorum signs, not any one member.

Splitting a signature, not a secret

Most people's first instinct for "don't trust one key" is to make copies — give the key to two devices, hope one stays safe. That is strictly worse: now there are two things to steal.

The opposite instinct — Shamir's secret sharing — is closer but still wrong for this job. Shamir splits a secret into shares that you reassemble to use. The problem: at the instant you reassemble, the whole key exists in one place again, which is exactly the moment you were trying to eliminate.

FROST's move is the clever one. The key is split into shares that are never reassembled. Each shareholder computes a partial signature using only their own share. A coordinator collects enough partials — t of them, the threshold — and combines them into one final signature. The full private key is never reconstructed, not even for a microsecond, not even on the machine doing the combining. What comes out the other end is an ordinary Schnorr/Ed25519 signature that any standard verifier accepts, with no idea it was made by a committee.

So a t-of-n FROST key means: there are n shareholders, any t of them can together sign, and fewer than t — no matter how many keys they steal — can do nothing.

Two layers: the key in memory, and the key across devices

NAOMS applies this idea at two distances, and it's worth keeping them separate because they protect against different attackers.

Layer one: the key in memory, on one device. Even on a single laptop, the signing key never sits in process memory as a usable whole. It lives in a separate, sandboxed signing process, split 2-of-2, with each share XOR-masked against a random pad that is re-randomized on a timer, locked into memory so it can't be swapped to disk, and marked unreadable until the instant of use. Signing happens unmask → operate → remask in microseconds. The upshot is that the secret simply isn't sitting in plain memory to be scraped: it's masked, the pages are locked and excluded from crash dumps, and the usable whole only exists for microseconds during a signature. This layer is shipped. It defends against malware reading your RAM and against a careless crash dump leaking your identity. (It pairs with a deeper guarantee: when you're away, your identity is asleep and the daemon holds no usable signing key at all.)

Layer two: the key across your devices. This is the one the title is really about. Here the shares live on different physical machines — your laptop, your phone — and producing a signature for an identity-critical action requires those devices to cooperate in real time. Each co-signer shows you a prompt, you approve, the device emits its partial signature, and only when enough partials come back does the action go through. A thief with your laptop alone holds one share of a t-of-2 key. One share signs nothing.

This is scoped deliberately. Cross-device threshold signing guards the identity-critical actions — rotating your identity, adding or revoking a trusted key, changing the threshold itself. The everyday, high-volume signing (syncing, appending to your own chain) uses a fast per-device operational key, because making you approve a quorum ceremony for every routine event would be unusable. The rule is: the rarer and more dangerous the action, the more keys must agree.

Inside the ceremony

The cross-device flow is a real protocol with real failure modes, and the interesting engineering is in the parts that go wrong.

Generating the key without ever assembling it. Before anyone can sign, the devices need a shared t-of-n key — but if some setup step ever held the whole key, the whole scheme is pointless. NAOMS runs a distributed key generation step that produces each device's share directly, so the master private key has no birthplace. The signer exposes this as a first-class operation alongside the per-round signing primitives.

Getting a share to a new device safely. When you enroll a second device, it needs its share — and that share must cross the gap between machines without ever being readable in transit. NAOMS seals each share into an envelope using ephemeral Diffie-Hellman to agree a one-time secret, a key-derivation step to stretch it, and authenticated encryption to seal it. The plaintext share bytes never cross the boundary; the receiving device's own signing process opens the envelope inside its sandbox. There are matching produce-envelope and install-envelope surfaces, plus a redistribute path (built on verifiable secret sharing, so a new set of devices can be handed fresh shares without ever rebuilding the master) and a forget-share path for cleanly dropping a share during recovery. These are real, working surfaces in the signer bridge — not placeholders.

Binding what you see to what you sign. A nasty class of attack: a malicious coordinator shows you "approve rotating your phone in" on screen while the bytes it actually asks you to sign mean "add the attacker's key as trusted." FROST doesn't prevent this on its own — it signs whatever message it's given. NAOMS closes it by binding the human-readable purpose into the signed pre-image with a canonical, deterministic encoding, so the signature is over the purpose you were shown. Sign for "rotate," and the bytes cannot be reused to mean "add trusted key."

An attack we found in the act of building it. This is the kind of honesty the project runs on, so we'll name it. While migrating signing call-sites, a review caught that some cross-device handshake signatures were static and replayable — an attacker who observed one legitimate handshake could replay the exact same signed tuple in a fresh session and inject unauthorized trust. It was fixed by binding a fresh per-handshake nonce into the signed pre-image, then hardened further with short-lived staples and a proactive revocation notice. The lesson that keeps recurring: a signature that doesn't bind which session, which purpose, which moment is a signature waiting to be replayed. (The same fresh-nonce discipline shows up at the transport layer, in the challenge-response handshake between the terminal client and the daemon.)

When a co-signer goes dark

Real devices fall asleep, lose signal, wander out of Bluetooth range mid-ceremony. Plain FROST is unforgiving here: if you've committed to a signing round with a specific set of participants and one drops, the round aborts and everyone retries from scratch. With three devices and a threshold of two, losing one can void a ceremony that the other two were perfectly capable of completing.

There is a known fix in the literature — a robustness wrapper (ROAST) that lets a ceremony adapt to the responsive set and finish as long as a threshold of signers are still answering, with fresh nonces per attempt so nothing is ever replayed. NAOMS has this scoped and understood — and deliberately deferred. The honest reasoning: it's only worth the added complexity once real usage shows ceremonies actually failing often enough to matter. Building robustness against a problem you haven't measured is its own kind of waste. So it sits in the backlog, gated on telemetry, not on enthusiasm.

Honest status, as of writing

Because "we use threshold signatures" can mean anything from a slide to a shipped system, here is exactly where it stands:

• Shipped: the in-memory 2-of-2 split in the sandboxed signer — masked, locked, unreadable-until-use, so the secret isn't sitting in plain memory to be scraped.
• In test: cross-device t-of-N FROST for identity-critical actions — the crypto core, distributed key generation, sealed share delivery, redistribution, purpose-binding, and the governance-signature checks are built and passing their unit and integration tests. What's still being finished is the long tail: migrating every last verifier and signing call-site onto the purpose-bound path, and the full end-to-end multi-device flow driven through the real pairing UI. It is not yet a button a user presses across two phones.
• Deferred: robustness against mid-ceremony dropouts — scoped, not started, waiting on evidence it's needed.

We'd rather you know that the cross-device layer is in test and incomplete than read a confident claim that it's done. The principle, though, is settled and worth holding onto regardless of which milestone it's on: no single key. Not the one in your RAM, not the one on your stolen laptop. The quorum signs, or nothing does.

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