Start with the seal on an envelope
Imagine that you close a letter and pour hot wax on the flap. The seal does not stop anyone from opening the letter — it stops anyone from opening it and pretending they did not.
The hash is that seal, made of mathematics. In PING it comes from the SHA-2 family — the same one the rest of the industry has audited for two decades — and it comes out as a number of 64 characters (256 bits) computed from the content. Change one comma in the content and the whole number becomes another one, unrecognizable. There is no way back: nobody rebuilds the content from the hash, and nobody can manufacture a different content that gives the same hash.
Now the idea that makes everything work. When you seal a letter, you put the seal of the previous letter inside it. The second letter contains the seal of the first; the third contains the seal of the second, and so on…
See what this costs a forger. Changing the first letter changes its seal — and that seal is written inside the second one. So the second changes. Which changes the third. And so on to the last.
That is why it is called a chain: touch one link in the middle and every link that came after it breaks. There is no way to repair it without redoing everything — and redoing everything means redoing what was already published outside, which nobody can do.
The link — one per movement of yours
Every movement of your money is born as a link in your chain. A transfer you send, a value that arrives, the network fee for a conversion out of PING, a battery top-up: one movement, one link.
The link holds what happened, the time, your signature, and the seal of the previous link. No money moves in the wallet without becoming a link — and that is what makes the chain complete: a chain with a hole proves nothing.
Here is the part that usually surprises people: the chain is yours, and only yours. Every wallet in the federation has its own. When you transfer to someone, two links are born — one outgoing in your chain, one incoming in theirs — and each one lives on its own side, joined by a shared reference.
There is no single queue where the whole world writes. That is why the network does not jam: two people transacting at the same time compete for no place at all, because they write in different books.
The height counts movements, not transfers. If your chain is at #507, that means there have been 507 movements of your money since the beginning — including network fees, top-ups and values received. It is not the number of transfers you sent, and it is never anyone else's number.
The anchor — one root per hour, published outside
The chain on its own has an honest limit: it lives in a database that somebody operates. If the operator rewrote every chain and signed everything again, the result would be internally consistent — and a lie.
Note that the problem is not distrust of the operator: it is that nobody should have to trust. A system that asks the operator for good faith is exactly the bank we are trying to leave.
The anchor exists to close that gap. Once per hour, the federation takes the seals of every chain of every wallet and summarizes them in a single hash — the root of that hour. And that number leaves home — it goes to nodes in other jurisdictions, to independent registries, to places where no operator of the network has the power to erase anything.
From the instant the root is published, the past is locked. Rewriting a link from yesterday would require changing yesterday's root — which is already published in places beyond the reach of any operator. Any device that holds the old root detects the difference at once — and yesterday's root is on many devices, in many countries.
The link proves the lineage. The anchor proves the when. That is why both exist: the link is cheap and parallel, and the anchor is what makes the record enforceable against a third party — usable in a dispute, in front of someone who trusts neither side.
The two numbers on the screen
When you open the Integrity proof, two numbers appear side by side. They have no arithmetic relation to each other — and that is exactly what makes them useful.
Local
#507- whose
- yours. No other wallet has this count
- counts
- your movements, one by one
- grows
- when you move money
- proves
- that your sequence is intact: nothing was inserted, removed or moved around
Global
#4,561- whose
- everyone's. It is the same number on anybody's screen
- counts
- the hours the network has already sealed
- grows
- on its own, every full hour — even if you do nothing
- proves
- the when: that your record existed before that root went out
Why the Global one gives away nothing about you: it is the same for everybody. Two people in the same hour see the same #4,561 — and a number that is equal for everyone says nothing about anyone. It is that property that allows publishing it in a newspaper, at a notary, in another network.
Why a federation, and not a server
A single server has a problem that no cryptography solves: it can simply stop serving you. It does not have to forge anything — refusing is enough, or being forced to refuse by whoever has power over it.
The federation is the answer to that: several independent nodes, in different jurisdictions, each one with a public reputation and a name of its own. A court order in one country reaches one node; a blackout reaches another; neither of them reaches the network.
But look at the design, because it matters more than the number of nodes: the nodes order, they do not authorize. What they do is say in which order the records came in, and break ties when there is doubt. They cannot create a unit of PING, they cannot sign in your place and they cannot lie about a balance — because validity does not come from them, it comes from the signature and from the proof.
It is that separation that makes the federation infrastructure and not authority. And it is what allows replacing a node without replacing the truth. If one leaves, is captured or lies, what it stated stays verifiable by any other. And its lie becomes publicly detectable: two signed roots for the same hour are mathematical proof of bad faith.
Elastic decentralization
Here is the thesis that ties this chapter together: the defense of the network grows together with its value.
A network is worth what its network effect is worth — every new connection makes it more useful for all the others, and usefulness turns into value. But value is also what attracts adversity: nobody attacks an empty network. So the same curve that makes the network worth having is the one that makes it a target — and that coincidence is what the architecture uses.
Full decentralization on day one costs latency, coordination and money, to defend something nobody wants to attack yet. And a network that dies for lack of use is not a secure network: it is a dead network. That is why the design is elastic — the number of nodes in the federation multiplies as the network becomes worth attacking, and each new level buys resistance to a different kind of adversity:
- Failure — a node goes down, a data center catches fire, a cable breaks. Solved with redundancy: any node replaces any node.
- Jurisdiction — a legal order reaches whoever operates inside one country. Solved with geographic spread: the order that stops one node does not reach the others.
- Capture — somebody takes control of a node and starts lying through it. Solved with quorum: a root is valid only with the signature of several, and the lie of one becomes visible to all.
- Collusion — several nodes agree among themselves. This is the hardest one, and the defense is arithmetic: with 2f+1 signatures, capturing less than a third changes nothing — and the more nodes there are, the more expensive collusion becomes.
- Censorship — the network refuses to record you. No cryptography solves this, only an alternative: with independent nodes, whoever is refused by one asks another.
That is the technical meaning of Byzantine resistance: it is not to assume that the participants are honest, it is to keep working even if some of them are not — and without needing to know which.
But the elasticity only goes up — and that is what makes it honest. The number of nodes grows; what never loosens are the four decisions you cannot add later: a signed link, an anchor published outside, a record that only grows and data already in private form. Without them, decentralizing tomorrow would mean starting from zero — and the whole past would become the word of whoever was operating. That is why this chapter can be read today: what it describes is already in its final form, even before the mesh grows dense.
The Merkle path — the bridge between the two numbers
One piece is missing. If the root of the hour summarizes millions of movements in a single hash, how do you prove that yours is inside it — without anyone having to send you everybody else's movements?
With a tree. The movements of the hour are hashed in pairs: two become one, those two become one, and so on until only one is left — the root. Since each level is half of the one below it, an hour with a million movements is only twenty levels tall.
To prove that your movement is in the root, all you need are the siblings along your path to the top: about twenty hashes. With them, your device recomputes the climb — your movement with its sibling gives a number, that one with the next sibling gives another, twenty times — and arrives at the root. If it gives the same number that was published, it is proved.
Twenty hashes are less than a thousand bytes. It fits in a QR code, it works without internet, and it reveals nothing about anyone else's movements — the siblings are only scrambled numbers.
1 hour with 1,000,000 movements → 20 levels of tree (2²⁰ = 1,048,576)
20 hashes × 32 bytes → 640 bytes of proof per movement
1 anchor per hour × 24 × 365 → 8,760 anchors/year ≈ 1.8 MB
1 anchor per day × 365 → 365 anchors/year ≈ 46 KB — 4.6 MB per century
That is why an ordinary phone can be a witness to the whole network: it does not keep the network, it keeps the roots — and the roots of a century of history would fit in an email attachment.
What happens when you tap Verify
The button runs three verifications, in this order — and the screen shows all three, one by one. It is deliberate: a proof that does not say what it proved is a claim.
First: your chain closes. The device recomputes the seal of each of your links and verifies that each one contains the previous one, from the newest back to the beginning. This verification is purely local: it works offline, forever, and it depends on no server of ours.
Second: your links are inside the anchors. Using the Merkle path, it climbs from your transaction to the root of its hour. This is the verification that joins your #507 to the network's #4,561.
Third: the anchor matches the root published outside. It compares the root it holds with the one published in places that obey no operator of the network. This is the strongest of the three — the only one that holds against anyone, including the whole federation acting together.
What your device does not do — and it is on purpose: it does not recompute the root. Recomputing would require the movements of every wallet in that hour, which would be impossible on a phone and the end of everyone's privacy. The device proves the path to the root. That is different, it is enough, and it is what keeps the proof compatible with privacy.
The verification also runs on its own, without you asking: when the wallet opens, and when a new anchor closes. In those two moments it is incremental — a few links, milliseconds. The button exists for when you want to exercise the verification, not because the verification depends on you.
And when the verification does not close
Start where it matters: a seal that does not verify is a fact about a link, not about your money. The value has not moved, the balance is the same, and the strips and minutes already printed still verify.
There are seven possible reasons, and five of them involve no bad faith at all. That is why the wallet never shows a generic alarm screen: it says which reason it was, and it says what that reason means.
- not seriousThe device has no network
The first two verifications passed; only the comparison with the published root was missing. The screen says "two of three verify" and shows which ones — because there was no failure, there was a partial verification. It is the most common case of all.
- not seriousAnchors are missing on this device
Your newest movements are later than the last anchor this device downloaded. Nothing is wrong — it simply does not have the roots of those hours yet.
- not seriousThe app is out of date
The verification here uses a formula older than the one the network signs today. It is not about your records: it is the app that has to update before it verifies.
- lowIncomplete data on the device
An old backup restored, a sync interrupted, a Merkle path missing. Syncing again solves it, and nothing has to be redone.
- mediumA link does not close
It can be damaged data here — or the copy on this device differing from the one the network keeps. And the screen says exactly that: this device cannot tell the two cases apart. Fetching the network's copy breaks the tie.
- unknownIt could not conclude, and the device does not know why
It says that it does not know. It does not pick the most serious cause on its own — nor the mildest one, which would be the same guess in reverse.
- highThe anchor does not match
The recomputed root differs from the one published outside. It is the only serious cause, and the only one that triggers the serious response: the network stops accepting new records and enters an audit.
The serious response: stop writing, never undo
If the anchor does not match, the network freezes the present instead of erasing the past. The sequencer stops accepting new records, and:
reading stays whole — the balance reads, the statement reads, minutes stay valid, strips already printed still verify. Nobody loses anything; only new facts stop coming in until the audit closes.
And the rule with no exception: nothing is ever undone. To revert a record is to rewrite the past, and a book that rewrites once stops being worth anything forever. A correction here is a new record on top, with a new time, pointing to the old one. The error stays visible, and so does the repair.
The one who detects it is your phone, not the federation. Millions of devices verifying again are the alarm system — and that is why the anchor has to leave: no federation can be the auditor of itself. When a device finds a divergence, the warning goes to the operators and to the independent witnesses at the same time. Sending it only to the operator would be handing the complaint to the accused.
If it breaks, does it break for everyone?
No — and the answer comes from the structure, not from a promise. Since every wallet has its own chain, a problem in one does not contaminate the others.
If the data on your device is corrupted: it affects your device only. No other wallet notices, and syncing solves it.
If one of your links is wrong on the server: your chain is under suspicion from that point forward. The others stay intact, because they do not chain onto yours.
And the counterparty of your transfer is not contaminated: their link lives in their chain. The two are joined by a shared reference, not by chaining — each side proves on its own.
The anchor is the only truly shared point. If it is wrong, the problem belongs to everyone in that window of time. But note exactly what is lost: the links stay chained and signed; what is suspended is the proof of time for those hours, until the audit closes.
In one line: the damage spreads in the dimension of time, never in the dimension of the balance.
The archive in your pocket
At the foot of the screen there is the anchor archive. It shows what your device already keeps and offers to extend it — and the first line is precisely the one that says you are already covered.
The daily spine, from the origin, you already have. That is 365 roots per year, 46 KB — and it is enough to verify, because each daily root summarizes the 24 of the day before. The hour-level detail of the last 90 days is already there too, and it is where recent proofs happen.
The button offers the optional step: extend the hour-level detail back to the origin. Do not choose between daily and hourly — the daily one is a photograph of the hourly ones, and the two are zoom levels of the same thing.
What changes is the reach, not the security. With the daily spine you prove "it was there on that day"; with the hour-level detail, "it was there in that hour". The cryptographic strength is identical — it is the same chain of hashes. For money, the day is almost always enough.
And whoever joins today does not have to reproduce the whole history. They take a recent and trustworthy root — from an external publication — and verify from there forward. If downloading back to the origin were a requirement, the cost of joining would grow forever, and the phone would stop being able to be a witness.
For those who want the design underneath
The rest of the chapter was written to be understood without technical vocabulary. This section names the same things with the terms of the literature, for whoever is going to audit.
The structure is a block-lattice: one chain per account, one block per transaction, parallel writers with no global consensus on the hot path. A transfer is double-entry — two legs joined by a correlation identifier, one in each chain. Atomicity does not come from a global lock: it comes from the anchor window, which closes both legs or closes neither.
The anchor commits three roots per window, not one: the heads of every chain (the state), the transactions of that window (for point proof in log N) and the set of nullifiers in an indexed tree — the only way to prove absence, that is, that a spend never happened. There are three cadences: ~1 s for the immediate experience, 1 h for what every device keeps, 1 day for the spine that crosses decades.
Privacy does not come from hiding the ledger: it comes from the shape of the data. What is public are cryptographic commitments and nullifiers — hashes. Values and owners never appear, and that is why anyone can run a full node without reading anybody's balance. A per-batch validity proof guarantees that no unit was created or destroyed; the recursive version, further ahead, keeps the node at a constant size.
The exact function, for whoever is going to verify: both the seal of each link and the seal of the roots is a SHA-512 truncated to 256 bits — SHA512-T256. ⚠️ Note that this is not the NIST SHA-512/256: the initial vector is different, and verifying with the wrong function returns a different number. That is the difference between auditing and thinking you audited.
The choice is not about quantum computing — it is about who is able to verify. SHA-512 is faster than SHA-256 on a 64-bit processor, truncated it fits in a tree node with nothing to spare, and it is in the native crypto of every browser: your phone verifies without downloading any library. Two decades of cryptanalysis came for free. There was a temptation to use a hash designed for proof circuits — cheaper to prove, younger in audit. It was refused where it does not pay off: the trees of one hour are small, independent and discarded once anchored. The only tree that crosses time is the privacy one, and that one is born later, with a hash of its own. You do not pay today the price of a circuit that does not exist yet.
And every anchor says which hash it used. It is the same rule as the signature, and it exists for a simple reason: whoever verifies a record of yours twenty years from now needs to know what it was sealed with — and not guess it. A record that does not declare its own function is a record that ages illegible.
And the security boundary, said without euphemism: a node can censor — it can refuse to order a new record. What it cannot do is hide from you what is yours: your chain, your notes and the paths that prove their inclusion live on your device, and withholding what is already in the owner's hand is no power at all. It also cannot forge a signature, cannot rewrite the past without being seen and cannot allow a double spend — all three are refused by any device that verifies. It is that list, and not a declaration of good intentions, that defines what the wallet protects you from.
Why the anchor is also the defense against the quantum computer: one day today's signatures will be breakable. What saves today's signature is not its mathematics — it is the root of that hour, published outside, at a time when forging it was impossible. Breaking the key decades from now does not put a record inside a root of today. The anchor converts "this signature is valid" into "this signature existed before" — and it is the second statement that crosses the turn.
What you take from this chapter
Three sentences, and they are enough.
- Your chain is yours. Every movement of yours seals the previous one, and verifying that works on your device, offline, forever.
- The anchor belongs to everyone. One root per hour, published where no operator rules — it is what makes your record usable in front of someone who trusts nobody — not even whoever operates the network.
- The green seal is worth something because it can be absent. The wallet never paints the ✓ without having recomputed, never calls "secure" what is merely "not verified", and never hides from you that the verification did not close. A seal that always appears is not a seal — it is decoration.