Sealed accounts
Not as a policy, and not as a promise anybody has to take on trust. A consumer's key is sealed under their own password before it is split three ways, so the two services this operator runs can put their parts together and get a ciphertext they cannot open. The page below does that in front of you, with the real values, and reads the consequences off the public chain.
The sealed key is split into
3parts
One on the device, one with each of two services. The key itself is never divided — it is encrypted first, and the ciphertext is what gets split.
A recovery needs
2of them
Any two, and the password. Losing the phone is the ordinary reason anybody recovers anything, so the phone must not be one of the two required.
Both services together get
ciphertext
Not a policy and not a rule anybody enforces. They hold parts of an encrypted blob, and the password that opens it was never sent to either.
Before a key may leave
–
Reading the chain.
A password cannot authorise a transaction; only a key can. So every account design is an answer to where the key lives and who can use it. Holding it server-side makes the operator a custodian of everybody's money. Holding it on the phone under a password makes a lost phone a lost account, which is not viable for a national system serving people who lose phones. This is the third answer, and the ORDER is the whole of it: seal the key under the owner's password, and split the sealed blob. Split the raw key instead and the two services below reconstruct it between them — so “no single service can move your money” would be true while “not even both of them can” was false, and the second is the one that matters when one company runs both.
Three parts make three pairs, and each pair is a different accident. None of them signs anything — the device does that on its own, every day, without asking either service. What a pair does is rebuild the key when the device can no longer do it.
| These two | Rebuild the key | When |
|---|---|---|
| Device + Custodian | Moving to a new phone | The old handset still works, so its part is still readable. One service is enough and nothing has to be approved by anybody. |
| Recovery + Custodian | The phone is gone | The ordinary disaster, and the reason the device is not one of the two required. Two approvers from different teams, 72 hours’ notice, and the parts are released a further 24 hours after that — time in which the real owner can still say it was not them. |
| Device + Recovery | The operator disappeared | If the custodian stopped existing. This is the edge that makes the custodian optional rather than trusted. |
| Custodian + Recovery, without the password | Nothing | Both of the operator’s own services, together. They rebuild a ciphertext and stop there. This row is the product — the three above are what it buys, and the demonstration below is this row. |
Below, the splitting runs for real, in about a millisecond. Press the first button and a sealed key is divided into three parts in front of you; press it again and the three parts are different, because the division uses fresh randomness every time. Press the second and the custodian's part and the recovery service's part are put back together — the case that matters, because one company runs both.
What is real and what is not, exactly. The sealed value is real: it was produced by the same Go code the services run, from the key and password printed beside it, and it is read from the file that code's own tests answer to. The splitting is real and runs here. The SEALING is not run in this page — it is Argon2id over 128 MiB, which would mean shipping a cryptography library to every visitor, and this page used to load 19 MB of WebAssembly, which is the mistake not to repeat.
Nothing loads until you ask. The arithmetic is a few hundred bytes of JavaScript.
Who holds it, the first sixteen bytes, and what it is. Abbreviated because the point is that they differ, not what they say.
Nothing yet.
History, and labelled as such. These two payments were made under the threshold scheme this page used to describe, where a signature genuinely needed two shares. That scheme was replaced on 2026-09-22 — a deal is between a buyer and a seller, so nothing co-signs, and the device signs alone. The transactions are left here because they happened and anybody can check them; they are not a demonstration of what runs today. Read live from yamale-devnet-2, not written into this page.
| Transaction | Block | Signed by | Result |
|---|---|---|---|
| Reading the chain… | |||
The claim above has an obvious price, and a page that made the claim without naming it would be selling half a story. If no single share can sign, can the person whose money it is ever hold their own key?
Yes. It is theirs. But there is no seed phrase to hand over — the key was never written down, as words or otherwise, and has never existed in one piece. What leaves is the key itself, assembled for the first time, on the holder's own device.
It will not be twenty-four words, and nobody should accept twenty-four words from anyone claiming to be us. BIP39 words are entropy fed through a derivation: a phrase encoding these key bytes would import into any ordinary wallet and arrive at a different key at a different address. The holder would see an empty account and conclude the platform had lost their money. So what is handed over is a private key, labelled as one.
Three steps, every one of them signed by the account itself. The operator cannot request a disclosure on somebody's behalf, cannot refuse one, and cannot shorten the wait for a favoured customer or lengthen it for an inconvenient one — the delay is a chain parameter, not a setting in the platform's software.
The waiting period exists for one person: the holder whose phone was taken an hour ago. Once a key is out nothing protects them — a freeze does not bind a key somebody holds in plaintext, and re-enrolling seals and splits the same key, so a disclosed key signs for ever. Time plus notice is the only protection left, and every enrolled device is told the moment a request is made.
Read the acknowledgement in full. It is the exact text whose hash is recorded on the chain when somebody confirms — which is what makes "they agreed to version 1" a claim anybody can check rather than one they must take on trust.
Being exact about this is worth more than looking finished.
Yamale