What the proof tokens mean
Every recorded event carries a proof token — a long string of characters shown beside the entry. Share certificates carry one too, printed on the face along with a link and a QR code.
Why one shareholding shows several different tokens
This is the question everybody asks, and the answer is that they are not three tokens for one thing. They are one token each for three different things that happened.
Register a member and allot them shares, and you will see:
| Where | Token for | What it says |
|---|---|---|
| Register of members | member.registered |
This person became a member on this date |
| Movements | share.allotted |
These shares came into existence and went to them |
| Certificates | certificate.issued |
This certificate was issued evidencing that holding |
Three separate facts, recorded separately, because they are separately true. A member can exist holding nothing. Shares can be allotted without a certificate having been printed yet. A certificate can be cancelled while the member remains on the register.
If one token covered all three, you could not record any of them happening on their own — and in a real company they routinely do.
The same logic runs through the rest of the record. Cease a member and a second token appears beside them, for the cessation: the registration and the cessation are two events, and the register shows both.
What a token actually proves
That this entry was recorded here, at that time, and has not been altered since.
Anyone can check one, without an account, at swiftregistry.app/verify/ followed by the token —
which is where the QR code on a certificate points.
That is genuinely useful: a shareholder, a bank, or a buyer's solicitor can confirm that the certificate in their hand corresponds to a record that still exists and still matches. They do not have to take the company's word for it, or ours.
What a token does not prove
That the fact recorded was true. Nothing can prove that. If a wrong address is entered, the chain faithfully and permanently records that a wrong address was entered.
That the event happened when the entry says. A transfer dated 2020 but transcribed in 2026 is evidence of a record made in 2026 about something said to have happened in 2020. The system is careful to say so rather than blur it — a certificate printed from a transcribed register states on its face that the history was transcribed and confirmed, not witnessed.
What a stranger learns from checking one
Deliberately very little. The verification page confirms the entry exists, what kind of event it was, when it was recorded, and whether it has been anchored. It does not disclose the register, the shareholder's name, the address, or the size of the holding.
Someone holding two certificates from different companies cannot even tell they came from different companies. That is intentional: a verification surface that leaked the register would be worse than no verification surface.
Anchoring
Anchoring publishes a cryptographic fingerprint of the records to an external timestamping service. Only a digest is sent — no name, no address, no holding, and nothing that could be turned back into the record.
The point is independence. An anchor is evidence that the record existed no later than the anchoring time, and that evidence does not depend on SwiftRegistry still existing, or still being honest. It is the one mechanism here that survives us — and the only check that still works if somebody stands up a convincing copy of this website.
Whether a particular entry has been anchored is shown on its verification page, and that is the only place to find out. Do not assume it from anything written here. An entry that has not been anchored is still perfectly valid: anchoring adds independent corroboration of when, it is not a seal of approval, and its absence is not a warning. No particular anchoring interval is promised.
If you are relying on a record for something that matters — a share purchase, a lender, a dispute — check its verification page for an anchor rather than taking the existence of this section as evidence that one is there.
If a token stops verifying
Take it seriously and get in touch. A certificate whose token no longer checks out is exactly the alarm this system is built to raise, and the person holding the certificate is the one best placed to raise it.