The Digital Passport: A Record No One Can Revoke

How an identity document that lives on an open network actually works: what it proves, what it does not prove, and why irrevocability has a price.

"An identity that can be taken away certifies not you, but the one who issued it."

— Koan #46, Maksim Valentinovich Galatin

Introduction. The night after which a person stopped being visible

The email arrives at 3:40 in the morning. Subject line: "Your account has been suspended." Inside, a single sentence about a violation of community guidelines. Which guideline, which post, which day — not stated. The person is asleep and finds out in the morning.

In the morning he opens his mail — instead of messages, the same sentence. He opens his phone — the app has thrown him back to the login screen, the password is accepted, and then it goes no further. Photographs that piled up in the cloud on their own for nine years will not open. A conversation with someone who is no longer alive will not open either.

He finds the appeal form. The explanation field holds a couple of hundred characters, and there is nowhere to attach documents. He writes that he broke nothing and sends it.

The answer comes four hours later: decision upheld. No link to the specific post, no name of whoever reviewed it, no way to reply. Judging by the timing and the wording, the appeal was handled by the same automation that made the original decision.

Then the part begins that you do not think about at the moment of the block. That address was the login for a dozen other places: the work chat, the cloud with documents, the store holding five years of receipts, the account with the phone carrier. The "Sign in with…" button now returns an error. The personal domain is registered to the same address, and the renewal notice will land in a mailbox that cannot be opened. Subscribers gathered over years are on the far side of the wall — they cannot be taken along and cannot be warned.

A week later he still does not know exactly what happened. Not because someone refused to explain. Because there is nobody to do the explaining: there is no human being on the other side.

This scene was not invented for effect. What follows are documented cases where it played out exactly like that, and an examination of one question: can there exist a record about a person that cannot be switched off along with an account.

Chapter 1. Every document you hold was issued by someone — and can be taken back

The shape of the problem

Take any document that identifies you and ask a single question: who issued it?

There is always an answer. And that same answer tells you who can take it away.

This is not a conspiracy and not malice. It is the architecture. A document is not a thing but an acknowledgement: someone with authority asserts that you are you. As long as the assertion is maintained, the document works. The moment the party who asserted it goes quiet or changes its mind, the document turns into a picture.

The difference between a state passport and a user account is not one of nature but of timescales and procedure. A passport is seized under law, with grounds stated, with recourse to a court. An account is closed under service rules that the service itself wrote, and can be appealed only to the service itself.

It is worth pausing on this thought, because it is counterintuitive. It feels as though a document is an object: a plastic card, a sheet of paper with a stamp, a line in a profile. In reality the object is only the carrier of an assertion. Value is not created by the carrier but by the living connection to whoever maintains the assertion. Sever the connection and what remains in your hand is a thing without content. That is precisely why losing an account is felt more sharply than losing an object: what disappears is not a file but the confirmation that you stood behind that file.

What the companies themselves say

This is not speculation: the right to close an account is written directly into the terms of service, and it is written in calm language.

Google, in its terms of service, reserves the right to suspend access or delete an account in the event of material or repeated breach of the terms and policies, and also where the law requires it or where a user's conduct creates harm or legal risk. The same document promises advance notice and an opportunity to explain — with a caveat: where reasonably possible, and with a list of exceptions.

YouTube phrases it similarly: the service may suspend or terminate access to part or all of the service, including where it believes conduct creates risk for users, third parties or the company itself.

Look at how the sentences are built. Everything turns on the judgement of one side: "if we reasonably believe", "where reasonably possible". The other side does not participate in the construction. It learns the outcome.

This, incidentally, is not a reproach aimed at lawyers. There is no other way to write such a document: a service has to be able to react quickly to abuse, and an obligation to review every case by hand under an adversarial procedure would make the work impossible. The problem is not in the text of the agreement but in the fact that a user has no second footing — nothing that keeps working once the first footing is removed.

Documented cases

February 2021, United States. Two fathers — one in San Francisco, one in Houston — photographed inflammation on their small children at the request of medical staff, so the doctor could see it remotely. The images synced automatically to the cloud. An algorithm classified them as child sexual abuse material. Google reported the matter to law enforcement without notifying the fathers, and reviewed not only the flagged images but the entire archive of one of them. The San Francisco police and the Houston police investigated and found nothing: no offence had been committed. The accounts were not reinstated afterwards — the company declined to restore them even once the error was plainly established. The men lost their email, their photographs, their videos, and in one case their phone number as well. The case was reported by Kashmir Hill in The New York Times and analysed by the civil-liberties organisation EFF in August 2022.

What matters here is not the algorithm's mistake — algorithms make mistakes, that is expected. What matters is that a document of innocence issued by the police carried no force inside a system the police did not issue. One issuer does not honour another issuer's paper unless it is obliged to.

2025, Meta platforms. According to BBC reporting, tens of thousands of users worldwide complained of mistaken bans on Instagram and Facebook, including accusations of the gravest categories of violation. More than 500 people contacted the newsroom directly and described losing photographs that mattered to them and seeing their businesses put at risk. A petition against mass bans and the absence of human support gathered more than 25,000 signatures. Some accounts were restored after the newsroom asked questions about specific cases; in one episode the company apologised for the error.

The second point deserves a slow re-reading. The working method of appeal turned out to be contacting a major newsroom. Not the appeal form — a journalist. That method is unavailable to the overwhelming majority, and it says nothing about the procedure; it says the procedure is absent.

The verification badge. On 20 April 2023, Twitter (now X) removed the blue checkmarks from every account verified before the change of ownership. The badge became a marker of a paid subscription — at that point eight dollars a month on the web in the United States. The checkmark was not taken away for misconduct: the rule changed. The mark meaning "this really is that person" turned out to be not a property of the person but a service offered by the platform.

Service shutdowns. Google+ was closed to ordinary users on 2 April 2019, after which the contents of accounts and pages began to be deleted. Microsoft retired Skype on 5 May 2025; access to chat and call history was left available until January 2026. Nobody broke any rules. The product simply ended, and with it ended the part of a biography that lived only inside it.

Domains. A domain name is not bought forever; it is registered for a term. ICANN maintains a separate guide for those preparing court orders and law-enforcement requests for the seizure of domains, describing what data the registry and registrar need in order to comply quickly. A seized domain usually starts showing a notice page from the agency involved. All of this is lawful machinery, and the point is not whether it is good or bad; the point is that the address at which people find you does not belong to you.

Why appeals rarely help

An appeal is submitted to the same party that made the decision. This is not an abuse — it follows from the same architecture: if the document exists by virtue of the issuer's acknowledgement, then disputes about the document are settled by the issuer.

Then arithmetic takes over. Decisions are made by automation, because the volume cannot be worked through by hand. There are as many appeals against automated decisions as there are decisions — which means the appeals are handled by automation too. The result is a closed loop: the system reviews itself and confirms itself.

Regulators have noticed. The European Digital Services Act (DSA) requires platforms to give users a clear statement of reasons when content is removed, visibility is restricted, monetisation is withdrawn or an account is suspended — including whether the decision was taken by automated means, and a description of the routes of redress. Those statements of reasons are collected in an open EU transparency database. This is a real step forward. But look at what it is aimed at: it improves the procedure at the issuer. The dependence on the issuer stays exactly where it was.

What exactly is lost

It is worth listing plainly, because at the moment of a block the list looks shorter than it is:

• years of correspondence, including with people who can no longer be asked anything;
• photographs and video, if the only copy lived in the cloud;
• contacts, and the means of warning the people who read you;
• access to other services where you clicked "Sign in with…";
• payment history, receipts, subscriptions, the linked phone number;
• income, if the audience and the orders existed only there;
• and the hardest one to name: the confirmation that you were there all that time.

The last item is not poetry. A person's presence online today is their biography: where they studied, what they did, who they spoke to, what they thought at thirty. When that is erased by a single decision, what is erased is not an archive but the provability of a past.

The question this article was written for

Can there exist an identity record that does not depend on whoever issued it? A record that cannot be switched off along with an account, closed along with a service, seized by order, or lost when the rules change. Not because the issuer is kind and promised not to do that — but because the issuer technically has no such capability.

The question is not ours. On 19 July 2022 the W3C consortium ratified the standard for Decentralized Identifiers (DID) — identifiers which, in the consortium's own description, require no central issuing authority and are portable between service providers. In other words, the industry has already conceded the point: tying identity to a single issuer is a defect of design, not a law of nature.

What follows is an examination of one attempt to answer that question in practice: what can be recorded in a way that outlives everyone who recorded it — and, just as important, what such a record cannot do and never will.

Chapter 2. Self-sovereign identity in plain language

Behind the phrase "self-sovereign identity" (SSI) sits a one-line thought: a document about a person should be held by that person, not only in the database of whoever issued it. Everything else is a consequence. To see why this is a question at all, take any act of document-checking apart.

Three parties

Every scene involving a document has three participants.

The one who certifies (issuer). A university, a bank, a ministry, an employer. It asserts something about a person: "graduated", "customer since 2019", "cleared for category B".

The one who presents (holder). The person. They hold the diploma, the card, the certificate.

The one who checks (verifier). An HR department, a landlord, a border officer, a form on a website.

This is not a metaphor. Exactly those three roles are written into the W3C Verifiable Credentials Data Model 2.0: the issuer formulates claims and creates the credential, the holder possesses and presents it, the verifier receives and processes it.

The scheme looks obvious right up until one question: what is the verifier's confidence actually resting on?

Why the verifier is forced to trust the issuer

The HR department looks at the diploma. Paper with a stamp proves nothing by itself — what proves something is what stands behind it: the university registry, which can be phoned. Authenticity checking is a query to the owner of a database. From this follow three consequences that usually go unnoticed.

1. The check lives exactly as long as the issuer does. The university closes, the bank fails, the agency is reorganised — the document is still in your hand, and there is nowhere left to confirm it.
2. The issuer sees every check. Who asked, when, on what pretext. That is data about a person which the person never handed to anyone: it comes into existence from the very act of verification.
3. The issuer can change its mind. Revoke, block, close off registry access, rewrite the rules. In this scheme the holder has not a single lever.

A secure blank — watermarks, a hologram — cancels none of that. It proves the paper was printed on the right press, not that the entry in the registry still exists.

What changes when the document lives on an open network

Cryptography gives two things that require no trip to anyone. Integrity: change one character and the signature breaks — not "looks suspicious", but arithmetically does not add up. Provenance: a signature verifies against one key, not a similar one.

Verification stops being a request and becomes a computation. The practical difference:

• the verifier asks the issuer nothing — which means the issuer never learns a check occurred;
• whether the issuer's server is running stops mattering;
• anyone can repeat the check themselves, a year later, from another country, without permission.

The shift sounds technical, but it is about power. While verification is a request, the database owner holds a switch and a log: it can decline to answer, and it can see who asked. When verification is a computation, there is no switch, no log, and nobody to ask permission from.

Our Digital Passport is the simplest instance of this scheme: the document is written once to the open Arweave network and from that moment is readable by anyone without our involvement. How it is built inside is the subject of Chapter 3; what matters here is only that it belongs to this class of solution and not to the class of "a profile on a website".

The standards: DID and Verifiable Credentials

The industry builds this on two bricks — both open W3C standards.

DID (Decentralized Identifiers) — an identifier that no registrar issues. It resolves to a document containing the holder's public keys, and those keys verify the holder's signatures. DID 1.0 became a W3C Recommendation in July 2022 — over formal objections from Google and Mozilla. Mozilla argued that practical interoperability had not been demonstrated and that the specification delegated everything to a registry of some fifty "methods"; Google asked that ratification wait for at least three mature methods, because the core cannot be assessed in isolation from them. The objections were overruled, but in substance they have not been answered. Version 1.1 was published as a Candidate Recommendation on 5 March 2026 and as of August 2026 is still a candidate.

Verifiable Credentials — the format of the credential itself. The VC 2.0 family became a W3C Recommendation on 15 May 2025, as seven documents at once: the data model, Data Integrity 1.0, the EdDSA and ECDSA cryptosuites, securing via JOSE/COSE, Controlled Identifiers 1.0 and Bitstring Status List 1.0.

What this gives in practice:

• a common format — a verifier can parse a credential from an unfamiliar issuer without a bilateral agreement;
• selective disclosure — you can show "over 18" without showing a date of birth;
• revocation — Bitstring Status List: the issuer publishes a bitmap of statuses and the verifier reads the relevant bit.

And here is the crux for our subject. The standard does not abolish trust in the issuer; it formalises it. The specification says so directly: verifiers trust particular issuers with respect to particular claims, and apply their own rules. Mathematics will prove that this specific university signed the certificate. Whether the university is worth believing is a question beyond mathematics. And the status list restores part of the old dependency: since the issuer maintains revocation, you have to go back to the issuer.

Our passport is not a VC-standard credential — it is JSON in a schema of our own. There is no revocation in it: there is nothing to revoke with. That is a deliberate fork in the road, and Chapter 4 treats it as a trade-off rather than an unfinished feature.

eIDAS 2.0: the European identity wallet

EU Regulation 2024/1183 entered into force on 20 May 2024. Under it, each of the 27 member states is obliged to provide citizens with at least one Digital Identity Wallet (EUDI Wallet). The clock runs from the implementing acts adopted on 28 November 2024 — which by the common reckoning makes the deadline 24 December 2026. The regulated private sector — banks, telecoms, healthcare, large platforms — is obliged to accept the wallet roughly a year later.

Technically the wallet is close to the SSI idea: credentials sit on the phone, and selective disclosure is supported. Two formats are mandatory — SD-JWT VC and ISO/IEC 18013-5 mdoc (the same one used by mobile driving licences); W3C VC 2.0 is admitted as an optional third.

The difference from our approach lies in the root of trust. Each state maintains a national trusted list: who may issue credentials, who may be a wallet provider. The European Commission maintains the list of lists (LoTL) and signs it. Verification is a chain: signature on the document → issuer present in the national list → list present in the LoTL → Commission's signature.

The state has not gone anywhere. It has stopped being the place you send a query to, but it remains the source of who to believe. For driving licences and tax certificates it should not be otherwise — that is simply a different problem from ours.

Readiness is uneven: Germany announced a launch for 2 January 2027 — nine days after the legal date; the Netherlands signalled it will not make it; Malta expects to go live with partial functionality.

The United States took a different road, and the difference is instructive. There is no federal identity document and no single national wallet. What exists instead is a technical rulebook: NIST Special Publication 800-63, Digital Identity Guidelines, whose Revision 4 was finalised in July 2025 after a near four-year process, two public drafts and around six thousand public comments. It is built around three graded scales — Identity Assurance Level (proofing), Authentication Assurance Level (login strength) and Federation Assurance Level (how assertions are passed between systems) — set out across three volumes: 800-63A on enrolment and identity proofing, 800-63B on authentication and authenticator management, 800-63C on federation and assertions. Revision 4 expanded requirements around fraud in proofing, added controls against injection attacks and forged media such as deepfakes, admitted syncable authenticators (synced passkeys), and brought subscriber-controlled wallets into the federation model. Note what this is and is not: guidance addressed to federal agencies and the systems people log into, not a law creating a document that anyone must accept.

Where Americans actually meet a digital credential is at state level, through the mobile driver's licence. As of early 2026 roughly twenty-one states plus Puerto Rico issue an mDL conforming to ISO/IEC 18013-5 — the same technical standard the European wallet uses for mdoc credentials — and a couple of states run mobile ID apps outside the standard, which are correspondingly not accepted at TSA checkpoints. The result is a patchwork: the credential is real, the cryptography is genuine, and the issuer is a state motor vehicle agency that can suspend or revoke exactly as it always could. The phone changed the carrier, not the architecture.

The United Kingdom sits somewhere between the two. Its digital identity and attributes trust framework, launched as a voluntary industry scheme, was placed on a statutory footing by Part 2 of the Data (Use and Access) Act 2025, which received Royal Assent on 19 June 2025; sections 32 to 44 were commenced on 1 December 2025. The Office for Digital Identities and Attributes (OfDIA) now maintains a public register of certified digital verification services — 46 providers offering 64 certified services as of July 2026 — together with a designated trust mark, UK CertifID, and a framework whose version 1.0 was published on 9 June 2026 to take effect that September. Alongside it runs GOV.UK Wallet, a credential store inside the GOV.UK One Login app: the HM Armed Forces Veteran Card went live first, with the digital driving licence following through 2026, and the government's stated plan is for all services to offer a digital alternative to paper or card credentials by the end of 2027. A separate announcement on 26 September 2025 set out a digital ID that would become mandatory for Right to Work checks by the end of the Parliament, subject to consultation.

Line those three up beside eIDAS 2.0 and the same shape shows through each of them. All four make the credential portable, put it in the holder's pocket, and cut down on pointless queries to the issuer. None of them changes who decides. A DMV can withdraw an mDL; OfDIA can remove a provider from the register; a national trusted list can drop an issuer; and in every case the holder's copy stops verifying. That is the correct design for a driving licence, and it is worth saying plainly rather than sneering at: a licence should be revocable, because the thing it certifies can be withdrawn. The question this article asks is narrower — whether anything at all can be recorded that behaves differently.

The difference between all of these and the approach described here fits in one sentence. Under eIDAS 2.0 and its cousins you carry the document, and the state issues and revokes it. In a record on an open network you carry the document, and nobody can revoke it — including whoever wrote it.

Where self-sovereign identity does not work

It does not verify the person. Cryptography answers the question "is this record authentic and unaltered?", not the question "is this person who they claim to be?". SSI does not solve the binding of a record to a living human being — the literature calls this the binding problem, and next to it stands Sybil: without centralised registration nothing prevents one person from creating as many identities as they like.

It does not confer rights. A record on a network does not open a border, does not grant credit, does not replace a passport, a licence or a visa.

It does not abolish trust; it relocates it. You still have to believe the issuer. What disappears is only the dependence on the issuer's servers and the issuer's goodwill.

Irreversibility cuts both ways. What is written cannot be changed, deleted or revoked. This protects against arbitrary erasure — and it means a typo in a name stays forever, and a person who changes their mind cannot take the record back. The only available move is to write a new one and leave both standing.

The weak point is the human. A lost key is not recoverable by anyone — the flip side of the fact that nobody can take it away.

The standards are still in transit. VC 2.0 has been a Recommendation since May 2025; DID 1.1 has been a candidate since March 2026 and remains one. Infrastructure where an arbitrary credential is checked by an arbitrary verifier with no prior arrangement does not yet exist.

Three ways of saying "this is me"

The "who can revoke it" row is the one this whole exercise was undertaken for. And it is also the reason not to issue such a document thoughtlessly.

Chapter 3. How the CODE Eternal Digital Passport is built

It is a file, not a picture

Half the questions dissolve the moment the main thing is said: the passport is a text file in JSON format. You can open it in Notepad. There are no stamps inside it, no signatures, no photograph — only fields and values typed in ordinary characters.

This file is written once to the Arweave network and receives a transaction address of 43 characters. The address works simultaneously as a link and as a checksum: a different set of bytes would produce a different address. The document can be opened through any gateway on the network — https://arweave.net/<address> — and exactly the bytes that were written come back. After writing, the file cannot be altered or deleted — not by the person it was issued to, and not by us.

Here is what it consists of:

There is no email address in the document. This is probably the most important decision in the entire design, and it deserves separate treatment.

Why a fingerprint of the email rather than the email itself

A one-way function is an operation that is easy to perform and impossible to undo. A household example: stir a tin of blue paint into a tin of yellow. A second's work and you have green. Nothing on earth will separate it back into blue and yellow: the paint does not remember what it was made from.

sha256 works the same way. It takes any text and returns 64 characters. The same text always gives the same 64 characters, on any computer in the world. But from those 64 characters there is no way back to the original text — not because it is forbidden, but because there is nothing to go back from.

In a real passport it looks like this:

378e447d96ee98f8c44ce50c75a9805d68cede0886ccec932a9a4050bee41bc2

Why we do not write the email address in the clear. The document is public and permanent at the same time, and that combination is more dangerous than either property alone. A public address on an open network is an address the first email harvester will collect and bury under spam. An address is also half a login: knowing it, all that remains is to guess the password. And permanent means it cannot be taken back: there is no delete button on such a record and there never will be. One irreversible step, and a person acquires a lifelong target.

The fingerprint solves the problem differently. The owner can prove at any time that the record is theirs: take their email, compute sha256 of it — a one-line command, available on any computer — and compare it with what stands in the document. Match: the record is theirs. No match: it is someone else's.

Honesty is required here. A fingerprint is not anonymity. It stops someone reading the address, but it does not stop them testing a guess: anyone who already suspects what a person's email is can compute sha256 of it and compare exactly as the owner does. Unsalted hashes of email addresses have long been regarded as a pseudonym rather than anonymity — against lists of leaked addresses they are cracked with an ordinary dictionary run.

What the fingerprint does deliver reliably: you cannot write an email to a hash. A robot crawling the network for addresses will not extract a single working one from our records.

The document number CE-XXXXXXXX

The number is not issued and is not stored anywhere. It is computed: take the first eight characters of the fingerprint, raise them to upper case, put CE- in front.

378e447d96ee98f8...  →  CE-378E447D
6495fb95eae56f47...  →  CE-6495FB95

Both numbers can be checked right now: open either of the live links below and the Passport ID field will contain exactly that.

The number's durability follows from the fact that it is derived rather than assigned. There is no counter that can drift. There is no lookup table to be lost when a database is migrated. There is nobody who has to remember which number was given to whom. The same email gives the same fingerprint, the fingerprint gives the same number, and that will hold in twenty years even if not a single server or database of ours remains: the number is recomputed from the document itself, by anyone.

And here too honesty is required. Eight hexadecimal characters is about 4.3 billion combinations. Plenty for a number you can read out over the phone without confusing it with a neighbouring one, but not enough to treat as unique forever. The real identifying marks are different: the 43-character transaction address and the full 64-character fingerprint. The CE- number is for humans; those two are for verification.

Why the record cannot be changed

An ordinary website stores data for as long as somebody pays for hosting. Stop paying and the data is gone. Arweave is built the other way round: you pay once, at the moment of writing.

That single payment is split. A small part goes to those accepting the file right now, the rest goes into a common storage endowment. The base price is calculated as 200 years of storage at today's disk prices, and the endowment lives off its yield. Since storage grows cheaper over decades, the endowment's purchasing power rises and the horizon stretches beyond the calculated one. How robust this construction is, and what happens if the assumption fails, is examined in Chapter 4 — the risks are named there.

Beyond that, the design of the network itself takes over. The file lands in a block, the block is confirmed, copies propagate across nodes. An "alter" operation simply does not exist in the protocol — there is only "write". You can write a new document, but the old one stays where it is and both remain visible. Worth noting separately is how the blocks are linked: each new block references not only the previous one but also a randomly chosen old one, so substituting a single record after the fact breaks the whole construction rather than one link.

For our example it looks like this. The network's response for transaction address mGLT…:

block_height: 1975726
number_of_confirmations: 130

The first is the number of the block the record landed in. The second is how many blocks the network has stacked on top since; that number rises by itself and never falls.

The other side of this is stated honestly: we do not have a delete button either. A typo in a manifesto stays a typo. A text a person will regret in a year stays a text. That is the price of irrevocability, and it is paid by whoever issues the document.

What an outsider sees, and what they do not

Separately: the record is tagged as a CODE Eternal passport, so it can be found on the network without knowing the address — through the general listing of such records. "Public" here means public in earnest, with no qualifications. Anyone who does not want their name and manifesto lying in the open forever should not issue the document. There will be nobody to ask to reverse that decision.

How to verify without trusting us

Verification is designed so that our participation in it is unnecessary.

Step one. Open https://arweave.net/<address> — you will see that same JSON. Not our page with our styling, but the source file.

Step two. Open the same address on a different gateway. There are hundreds of gateways, they belong to different people in different countries, and none of them is ours. The contents must match character for character: the transaction address in Arweave is the fingerprint of the data itself, and a substituted file simply will not be served under it.

Step three. Cross-check the date. The document carries a date-of-issue field, and the network separately reports which block the record landed in. The date in the document is what we wrote; the block number is what the network recorded. Had we back-dated the document, the discrepancy would be visible to everyone.

Step four. If you are checking your own document, compute sha256 of your email and compare it with the fingerprint.

After those four steps, nothing depends on us. We cannot show you one thing and somebody else another: there is one file, and it is not in our hands.

Why a display page is needed at all

The document reads perfectly well without a website — but it reads as a file. Lines of curly braces and English field names make sense to a developer and to almost nobody else. Handing that to a person is like handing them a database printout instead of a passport.

So we have a page at /passport/<address>. It fetches the file from the network and draws a document from it: a holographic strip, an embossed seal, a photo frame, a VERIFIED mark, the document fields, a fingerprint pattern, a machine-readable zone at the bottom and a QR code. The QR points at this same page — it is a "check me" code, not a "send me money" code.

What matters is what the page is not. It stores nothing. Every time, it requests the document from the network's gateways afresh — and if the first one does not answer, it goes to the second and the third, so that somebody else's outage does not look like "this passport does not exist". The page physically cannot modify the document: it is a reader, not an owner. If every one of our sites vanished tomorrow, the document would stay where it is and would still be readable at its transaction address — just without the frame and the seal.

The handle is locked forever

An ordinary service returns a name to circulation after an account is deleted: the slot is free, let the next person take it. For us that will not do.

The handle stands in the document, the document lies on a blockchain and cannot be removed from it. Giving a freed-up name to a new person would mean creating two different people under one name in a permanent record — and in ten years nobody would be able to work out which was which.

So when an account is deleted, the name does not disappear with it but moves to a separate list of locked names — and stays taken. The availability check when choosing a handle looks into that list too. The person is gone, their data is erased, and the name remains theirs.

What you will see at the live links

[Maksim Galatin's passport](https://www.codeofdigitaleternity.com/passport/mGLTBEbJM01kbau_sgSLboLzNmZOWwWflbdZiBXUCNM) — a document with the number CE-378E447D, date of issue 2026-08-08, tier Digital DNA, handle @maksimgalatin, links to Telegram, X and a website. Below that, an "About" block, the manifesto "CODE KOAN", and a machine-readable zone with two lines: SUBJECT (the fingerprint) and TX (the transaction address).

[Fil's passport](https://www.codeofdigitaleternity.com/passport/tU82S6VwyX3I4yAGSn_M95o-Cap-sc2QrY_wR_YRq6M) — number CE-6495FB95, handle @fizikfil, the same date. Here you can see what the document looks like with fields left empty: in place of the description and manifesto there is a "scroll of memory", and in place of a tier name the words Eternal Member.

Both addresses open identically on codeofdigitaleternity.com, aifa.digital and aifa.works. And if you append the transaction address to https://arweave.net/, you will see the primary source — the file from which both documents are drawn:

https://arweave.net/mGLTBEbJM01kbau_sgSLboLzNmZOWwWflbdZiBXUCNM

Chapter 4. Boundaries: what this document does not do

With a document it is more useful to know what it does not give you than what it does. With a digital passport this is especially true: it looks like an identity document — a formal layout, an embossed seal, a VERIFIED mark, a machine-readable zone at the bottom. The appearance drags expectations behind it that the document will not bear. So the boundaries, stated directly, without softening.

It is not governmental and is not legally recognised by anyone

No state, agency, bank or university is obliged to look at it, and none will. It does not replace a passport, a driving licence, a visa, a diploma or a birth certificate. It will not get you across a border, open an account, register a marriage or get you a job.

Recognition is conferred on a document by law, not by a record on a network. States build their digital credentials by exactly that route — as in eIDAS 2.0, discussed in Chapter 2: behind such a document stands an obligation to accept it; behind ours stands only mathematics and the availability of the record.

It does not certify that you are you

Here lies the main misunderstanding, and it is worth taking slowly.

"To certify identity" means that somebody with authority checked the person and their documents and vouches for the result with their own liability: this is indeed that person. We do not do that — not at issuance and not afterwards.

"To fix the existence of a record" means something else: as of such-and-such a date, a document was written to the network in which the handle is such-and-such, the fingerprint is such-and-such, the fields are such-and-such. It is verifiable that the record exists and has not changed since. It is not verifiable that behind it stands the person whose name is in the "Name" field.

You cannot put an equals sign between those two. The document attests to time, not to identity. It answers the question "what was written, and when", not the question "who is this".

On the fingerprint specifically. As set out in Chapter 3, it hides the address from a casual glance but does not make the record anonymous. Regulators read hashing exactly that way — as pseudonymisation rather than anonymisation, with hashed data remaining personal data. The fingerprint protects against incidental reading, but not against someone who already knows your email and wants to confirm a guess.

For comparison: in the mature W3C Verifiable Credentials 2.0 model, revocation and suspension are built into the design — there is a dedicated specification for it, Bitstring Status List v1.0. We have no revocation by construction. That is a trade-off, not an unfinished feature.

The record cannot be revoked, and that works in both directions

A person changes their mind: leaves the project, changes their name, falls out with a manifesto they wrote three years ago.

What we can do: remove the document from the display on our own sites, unlink it from the account, help issue a new record stating that the previous one no longer reflects the person.

What we cannot do: delete the record from the network, alter a single character in it, or revoke it. Not at the person's request, not by our own decision, not on anyone's demand. The key that would undo it does not exist in anyone's hands.

The right to erasure collides head-on with immutability here. Article 17 of the GDPR gives a person the right to demand deletion — for instance when the data is no longer necessary for the purposes for which it was collected, or when consent has been withdrawn. The right is not absolute: paragraph three of the same article lists exceptions — freedom of expression and information, compliance with a legal obligation, archiving in the public interest and scientific research, the establishment or defence of legal claims. But there is no item on that list reading "technically inconvenient for us".

How regulators treat the conflict:

• CNIL (France), 2018 guidance: keep personal data off-chain, put only pseudonymous identifiers or hashes on-chain, and provide for deletion by destroying the key or the off-chain link — at which point the record ceases to be readable.
• EDPB (European Data Protection Board), Guidelines 02/2025: adopted in April 2025, version 2.0 on 7 July 2026. The position is stricter: do not write personal data to a chain at all, neither in clear text nor encrypted nor hashed; work out deletion at the stage of choosing the technology, not after a request arrives.

What this means for us, without self-justification. Email does not go on-chain — that is precisely the recommended arrangement. But the handle, the name and the fingerprint are on-chain, and on the regulators' reading a hash is personal data too. So the honest framing is this: a digital passport is a publication, not a row in a database. The nearest analogue is not an entry in a member area but a book that went to print and dispersed into libraries. Print runs are not recalled. That is why the document is issued as a separate, deliberate act rather than automatically on registration.

An error in the data stays forever

A typo in a name, a wrong date, a link to an account you will abandon in a year, a manifesto written at three in the morning — all of it freezes in whatever form it goes onto the network. It cannot be corrected. A new document can be issued, and then both versions live side by side: the old one with the error and the new one without.

The plan tier is a document field too, and it records the moment of issue. Move from Spark to Digital DNA and the earlier record will forever carry the earlier tier.

There is one conclusion: read every field aloud before issuing. Name, handle, description, manifesto, every link. That is the only minute in which anything can still be changed.

Losing access to your account cancels nothing

Forgot the password, lost the email, deleted the account — none of it touches the document. It is already outside our control, and regaining access to the account does not grant power over it: reissuing, editing or hiding it is impossible even after signing in.

The handle stays locked to the person even after the account is deleted. That is simultaneously a protection and a limitation — we will not be able to "free up" the name for somebody else, even if you ask.

Platform accounts follow the opposite logic, and it is worth keeping alongside for contrast: Google, for example, reviews no more than two appeals on a disabled account, after which it stays disabled and proceeds to deletion along with all its contents. Our document cannot be taken away like that — but neither can you win back the right to change it.

What happens if Arweave itself disappears

Storage there rests not on a promise but on the economic construction described in Chapter 3: pay once, the smaller part covering roughly the first 200 years, the larger part going into an endowment. Underneath it lies an assumption that the cost of storing data falls by at least 0.5% a year; historically, over half a century, it has fallen many times faster than that, so a wide margin is built in.

But it is a bet, not a law of physics. The risks, honestly:

• the assumption of ever-cheaper storage may fail, and the endowment may be invested badly;
• the endowment is denominated in the network's token, whose price moves: a sum that is more than sufficient today may be worth a fraction of that in a year;
• miners are not obliged to store everything: each has its own content policy, and the survival of a specific file rests on the number of copies and on the economic incentive to keep them;
• access to data goes through gateways, and arweave.net was historically the single such point — which is exactly why the ar.io network of independent gateways came into being.

Hence the practical point. The word "forever" means "for as long as the network's economics hold", not "under any circumstances". The document is a small JSON file: download it and keep a copy yourself. If the network one day ceases to exist, the contents will still be yours — though along with the network will go the thing it was all for: independent confirmation that the record was made at that time and has not changed since.

Why we still consider such a document useful

Because it has a property that a social media account does not have, that a platform profile does not have, and that a page on your own domain does not have: it cannot be cancelled. Not by us, not by a moderator, not by the owner of a venue, not by whoever buys that venue tomorrow. Everything listed above is the price of that property, and the price is worth paying with your eyes open.

The document does not say "this person is who they claim to be". It says: "a handle like this, with a fingerprint like this and a manifesto like this, existed on the eighth of August 2026" — and it will keep saying it for as long as the network is readable, regardless of what becomes of us, of the websites, or of the person.

Chapter 5. What it is actually for

The passport has five uses that work today, and a clear line beyond which it is useless. We will go through both — starting with the most contested.

Proof of priority

The scenario. You came up with a formulation: a product name, a paragraph of a manifesto, a scheme for how a service works. Six months later something almost identical appears from someone else, and you are left proving your case after the fact. Screenshots are no good — their date comes from your own computer.

An Arweave record settles that dispute partly. The transaction lands in a block, the block has a time, and nothing can be written in retroactively — how the blocks are chained is covered in Chapter 3. From that moment the text has a date that your laptop is not responsible for.

How this differs from a notary. A notary can do exactly the same thing: in Russia, for example, under articles 102 and 103 of the Fundamentals of Notary Legislation, a notary secures evidence, including by examining a web page and recording what was on it at a given moment; such a record is not time-limited for presentation in court. There is a technical version of the same idea — timestamps under RFC 3161: a certification authority signs the hash of your file with its key.

Courts treat such records differently in different places. In China, in September 2018, the Supreme People's Court permitted the internet courts of Hangzhou, Beijing and Guangzhou to accept evidence authenticated by blockchain, hashes and timestamps. In the European Union, Regulation 2024/1183 introduced the concept of a qualified electronic ledger: entries in it enjoy a presumption of integrity and of correct chronological ordering. Our record does not fall under that definition — such a ledger is maintained by an accredited provider, not by a public network.

And here is the limit. The record proves exactly one thing: this document with these fields existed no later than that moment. It does not prove that you are the author, that you were first in the world, or that you did not copy someone else. Somebody could have thought of the same thing earlier and not published it — the passport says nothing about them. Your rights, meanwhile, exist without the record: under the Berne Convention (182 contracting states) copyright arises at the moment a work is created, without registration or formalities. The record creates no rights. It helps with the date — and with nothing else.

A calling card that outlives platform migrations

The scenario. You give someone a link to yourself — in a CV, in an email signature, on a business card, in a talk. Three years later the link leads nowhere.

This is not pessimism, it is measured. In May 2024 the Pew Research Center found that a quarter of the pages that existed between 2013 and 2023 were already unreachable by October 2023, and that 38% of pages from 2013 had vanished. Most often the site is alive and the specific page has been removed. Whole venues disappear too: Vine shut down in January 2017 and its archive was taken down by 2019; consumer Google+, along with every profile, was deleted on 2 April 2019; and since 1 December 2023 Google has been deleting personal accounts not signed into for two years — along with the mail, the drive and the photographs.

A passport's address depends on none of those decisions. It belongs neither to a venue nor to us: as long as the Arweave network exists, any gateway will serve the document at those 43 characters.

An honest caveat: the document's fields are frozen too. Change your Telegram and the passport keeps the old handle. That is why it makes more sense to put a domain you control in the website field: a domain can be redirected, somebody else's profile cannot.

Confirmation for descendants

The scenario. The year 2090. A great-grandchild knows your name and a couple of stories. The accounts vanished long ago, the photo cloud closed along with the company.

What remains of you is 43 characters. With them the descendant opens the document and sees how you described yourself: name, handle, a short text about yourself, a manifesto, a date. Not a retelling, not somebody else's certificate — your own words.

For this to work the address has to be passed on in a human way: written into a will, printed out alongside the documents, written on the back of a photograph, engraved. It fits on one line and requires no password — that is the whole point.

And here comes the boundary. The document does not confirm that what is written is true. It confirms that a person with that handle and that fingerprint existed on that date and wrote this about themselves. By genre it is closer to a diary entry than to an archival certificate — but a diary entry with a reliable date.

Recovery after losing accounts

The scenario. Telegram was hijacked, X handed down a ban with no explanation, and the email everything was tied to is unreachable. You set up new accounts, and the first question from every acquaintance is: "Is this really you?"

The passport works as an assembly point. In the new profile you put a link to the record's address; the record shows which handles were yours and from what date. Anyone who knew you before compares one against the other: the same contacts, the same manifesto, a date preceding the incident. An impostor would have to produce a record with the same date, and they do not have one.

Honestly about the limits: a passport does not restore an account, does not influence a platform's decision, and does not prevent someone registering a similar handle elsewhere. It is an argument for people, not a key to a door.

For a community

The scenario. A group of co-authors, a guild in a game, the circle of participants in a project. You need to show the membership in a way that can be verified without going through the organiser.

A list of addresses solves the problem: each participant is one link, and anyone who wants to can read the documents directly from the network. Nobody maintains the registry, which means there is nobody to lose it, edit it on a whim, or close it down along with a website. If the organiser leaves, the list is still in everybody's hands.

An honest comparison: the decentralized identifier standard discussed in Chapter 2 solves a different problem — it has keys, authentication and key rotation. Our passport contains no keys, and it will not log you in anywhere. It is a display, not a pass.

Where it will not help

We do not verify that a person is who they claim to be. We record a fact: a handle like this, with a fingerprint like this, existed on such a date. The rest is the reader's interpretation.

How to issue your own

No paid plan is required. Issuance is open to anyone who has signed in: Spark, Family Archive, Digital DNA, or no plan at all. The tier is written into the document as a separate field — if there is no plan, it will be zero.

Step 1. Fill in the draft in your account, on the passport tab. The fields and their limits:

The draft can be edited as many times as you like. Until you press issue, nothing has gone to the network.

Step 2. Check before issuing. The list is short, but it is worth going through all of it:

• the handle — re-read it letter by letter: it stays with you forever and will not be given to anyone else even after your account is deleted;
• the name — in the spelling you want to remain in;
• the manifesto — read it aloud; the text will outlive you, and so will the typo;
• the links — open each one and confirm they work and are yours;
• the photo — one you will not be embarrassed to show in twenty years;
• the email — the fingerprint is computed from precisely that one; it will not enter the document, but the binding will be to it.

Step 3. Press issue. The site will ask again: "The passport will be permanently written to the Arweave blockchain. The data cannot be changed. Continue?" That is the only point of no return.

Step 4. Save the address. After writing, you receive those 43 characters. Check the document two ways: through the /passport/<address> page on any of our sites, and directly at https://arweave.net/<address> — the second matters more, because it shows that the record lives without us.

The issue button goes dark permanently after the first press. There will be no second passport on the same account: the system will return your existing address rather than create a new one. An error in a field cannot be corrected — not by us and not by you. Which is why step 2 takes five minutes, not thirty seconds.

Chapter 6. Questions and answers

Below are the things people ask most often.

How is this different from an NFT?

An NFT is a record of ownership: it is sold, gifted and lost together with a wallet. For most NFTs the data itself is not on the blockchain but behind a link — the chain holds a pointer, and when the server on the far side dies, all that is left of the token is a shell. The passport is built differently: the whole document goes onto the network, and ownership of it does not exist — there is a fact of publication. It cannot be bought and cannot be transferred to another address. A marketplace can hide a collection on its own site; the document has no marketplace at all.

But it is just a JSON file on the internet. Where is the value?

The value is not in the file but in the fact that nobody will rewrite it after the fact or take it down. An ordinary file lives as long as somebody pays for hosting and has not changed their mind; the Pew Research measurements cited in Chapter 5 show what that amounts to over ten years. Here you pay once, and from then on the document depends neither on our domain nor on anyone's mood.

What stops someone issuing a passport in another person's name?

Nothing. Anyone can write a document with any name into Arweave, without us — the network is open, that is its nature. Which is why the record by itself is not proof of identity, and we do not call it that. What our issuance adds: the issuing site's address inside the document, the fingerprint of an email confirmed at registration, and a date. What gets verified is not "this person is John Smith" but "on this date, this handle had this fingerprint, and we made the record". Somebody else's handle cannot be appropriated inside our system — it is locked forever; somebody else's name can be written into an outside record, and the technology will not prevent it.

Can the passport itself be forged?

A published document cannot be altered: at the transaction address lies exactly what was written. Something else can be forged — a lookalike page with anything you like drawn on it, seal and VERIFIED mark included. So the check should be made against the address, not against a handsome page: https://arweave.net/<address> will show the source document. The /passport/ page is presentation only.

What if I want to delete my passport?

You will not be able to. Not through support, not through a court, not through the Architect — no mechanism for deletion exists for anyone. You can issue a new document and treat the previous one as out of date, but the previous one stays readable. This is worth understanding before issuing: it makes sense to put only things you are prepared to live with for a long time into a manifesto.

What if your project shuts down?

The document outlives the project. The /passport/ pages will disappear with the websites, and the record will remain at its transaction address. Check right now without visiting us: https://arweave.net/mGLTBEbJM01kbau_sgSLboLzNmZOWwWflbdZiBXUCNM — bare JSON, with our servers nowhere in the chain. This is the only part of the system that does not depend on whether we are alive.

What if Arweave ceases to exist?

Then the document goes with it — that is the honest answer. The network's economics and its weak points are examined in Chapter 4; in short, it is a bet on the continuing cheapening of storage, not a guarantee. It is simply a longer bet than hosting with a monthly invoice. The sensible insurance is to download your JSON and keep a copy.

Why a fingerprint of the email rather than the email itself?

Because an open address in a permanent record is a gift to spammers with no right of recall. The fingerprint (sha256) solves one problem: a person who knows their own email computes the hash and satisfies themselves that the document is theirs. The email cannot be recovered from the fingerprint by reverse computation.

So the fingerprint means I cannot be found?

You can be found, if somebody knows what to look for. Unsalted sha256 is deterministic: take a suspected address, compute the hash, compare. Anyone who already has your email, or a list of addresses, can check whether yours is among the passports. That is exactly why regulators class hashed email as personal data rather than anonymous data. The fingerprint protects against incidental address harvesting but not against a targeted check — claiming otherwise would be a lie.

Can I issue several passports?

On a single account the issue button fires once. You can still write a new document to the network later — each record is separate, with its own date, and earlier ones are not cancelled. The point of reissuing is to update a description, a manifesto or links: the new document becomes current, the old ones remain history. The flip side: a public chronology of edits accumulates, and an unfortunate version cannot be erased from it.

What can outsiders see?

Exactly what you filled in: name, handle, description, manifesto, links, plan tier, date of issue, issuing site address and fingerprint. There is no email in the document. Conversations with AIfa have nothing to do with the passport — that memory is encrypted separately and does not enter it. This is a public page, not a private account area.

Why bother, when I could just post on social media?

A post lives as long as the platform sees fit. The case of the father in San Francisco described in Chapter 1 is about exactly this: the man broke nothing, an algorithm made the decision, and along with the account went his email, years of photographs and his phone number. A passport will not protect your account and will not bring photographs back; it is simply not in anyone's power. An Arweave record has no moderator to complain to — and nobody who can take it down.

Is it recognised anywhere?

No. It is not a government document: it does not replace a passport, a licence or a visa, it grants access to nothing and has no legal force. Recognised systems are built differently — there a state stands behind the identity, and the obligation to accept the document is written into law. Our task is smaller: to fix the fact that a person and their words existed on a given date.

How does this differ from W3C DID and verifiable credentials?

Those systems have thought through what we lack: selective disclosure of fields, verification of the issuer's signature, and above all revocation — Bitstring Status List gives a standard way to mark a credential as revoked. In mature systems revocation is considered a mandatory function, and we do not have it, deliberately. They are different instruments: a credential answers the question "is this valid right now", our document answers "was this so back then".

What happens if I change my handle or my email?

The old document does not change: it carries the old handle and the old fingerprint forever. A new record will fix the new data and a new date; the link between them is visible from the chronology of issues, not wired into the document. The handle is not released: even after an account is deleted, it will not go to anyone else.

Can a passport be inherited?

There is nothing to hand over: it is not property and not a key, and it cannot be signed over to somebody else. What is inherited is the ability to show it. A 43-character transaction address fits into a will, onto a sheet of paper, into a family archive; in fifty years an heir will need neither our websites nor anyone's permission — only the address and any gateway.

How long does it live?

As long as the network lives. Storage is paid for with a calculation of at least two hundred years ahead, but I will not promise two hundred years: no storage medium and no organisation has demonstrated such a span in practice. The sensible comparison is not with eternity but with the neighbours: a domain is renewed annually, an account rests on somebody else's decision.

Why would I want this if I do not plan to show it to anyone?

Possibly you would not. It makes sense if it matters to you that what you said does not depend on somebody else's decision: a date under an idea, a manifesto, the fact of "I was here and thought this". Otherwise a passport will not speed up your work, will not get you discounts, and will not unlock sections of a website.

Conclusion

A document that nobody can revoke is easy to mistake for a claim to power. It is not. Revocation is always somebody's right to say "you are no longer on the list": a platform's, an agency's, an algorithm's. An Arweave record confers power over nobody: it opens no doors and obliges no one to anything. It does one thing — it takes the fact of your existence out from under somebody else's decision.

The price is symmetrical. Nobody can erase your record — and neither can you. Nobody will rewrite your manifesto — and neither will you. Everything described in Chapter 4 as a limitation is not a list of shortcomings but the reverse side of the single useful property.

If you have decided anyway — three steps.

1. The draft. Name, handle, description, manifesto, links to Telegram, X and a website. All of it goes into the record in full and forever. The plan tier will be fixed as whatever it was at the moment of issue; a paid plan is not required in order to issue.
2. Reading aloud. Re-read every field letter by letter, open every link. This is the last minute in which anything can be changed.
3. Issuance. Save the transaction address: those 43 characters are your document. Check it twice — on the /passport/<address> page and directly on the network at https://arweave.net/<address>. The second method matters more: it works without us.

And to see what this looks like finished, open the two live documents: Maksim Galatin's passport and Fil's passport. Both are readable without our websites — at the transaction address, from the open network, by anyone, at any time.