Sovereignty Research

Core thesis

Digital trust architectures are usually drawn from the top down: a state register, an electronic document, cryptography, an information system, a record of the completed transaction.

Yet the whole construction can depend on a far more mundane event.

A person walks up to a counter.

Another person is supposed to check their identity.

And the result of that check becomes a fact for every link that follows.

A trust architecture exists not in what is written, but in what is done.

A small field experiment carried out in Ukraine in 2021 showed how wide the gap between the two can be.

Nine Ordinary Transactions

The experiment grew out of a practical question: what does electronic identification look like — not in a regulation and not in a developer’s slide deck, but in real life?

Nine ordinary transactions were carried out at three postal operators — Nova Poshta, Ukrposhta and Justin. In seven of them, an electronic passport in the Diia application was presented.

The result was unambiguous:

7 presentations of an e-passport → 0 checks comparing the presenter’s face with the photograph of the document holder.

The experiment took place during mandatory mask-wearing. In none of the seven cases was the presenter asked to lower the mask for visual identification. In the two remaining episodes, at Justin, no document was requested at all.

So across nine observed transactions, the normatively significant act — establishing the customer’s identity — was either not completed or not performed at all.

Video of the experiment

Nine episodes are not a statistical estimate of the Ukrainian postal sector. But the same check skipped seven times in a row, by seven different clerks, is hard to read as one inattentive employee’s isolated mistake.

In the observed series, the exception was not the error.

The exception was the check itself.

The Digital System Was Working

This is an essential detail.

Diia was not hacked. The electronic passports were valid. One-time codes were generated and accepted. The information systems processed the transactions.

That is precisely what makes the case interesting. The failure was not inside the digital infrastructure — it was on the boundary between a digital credential and a physical person.

The system could reliably establish:

a valid electronic document belonging to person X was presented.

But a different question remained:

is the person at the counter actually person X?

Answering it was the job of the local participant in the procedure. If they did not, the next digital layer could not recover the omitted step. It received only the result.

A Credential Is Not a Person

Here it helps to separate three objects.

Credential validation — whether the document, key or other identifier is valid. Identity verification — whether the person using that credential has actually been established. Attestation — what result of the procedure was written into the system and passed on.

In normal operation they follow one another so habitually that they look like a single event. Technically, they are three different events.

A valid credential does not prove the identity of the presenter. A record of a successful check does not prove that the check was actually carried out properly.

The 2021 experiment showed both gaps in plain sight.

A record of verification is not verification.

What a Paper Passport Used to Leave Behind

Before electronic documents spread, Ukrainian institutions recorded the presentation of a passport in a simple way: they took a scan or copy of the document.

The meaning of that artefact was limited. It showed that the institution had recorded the performance of a normatively required action — that some document had been presented, that someone had come in, that a procedure requiring a document had formally taken place. But the scan itself was poor evidence of who exactly stood before the clerk.

If a dispute arose later, the burden of showing that the transaction had been properly carried out fell on the institution. Copies of documents carried little weight in court practice; even a handwritten date and signature did not always help, because the quality with which such artefacts were produced, stored and reproduced varied widely.

It was an imperfect system. But its imperfection was visible. A weak procedure left a correspondingly weak trace.

A Digital Trace Can Be Stronger Than the Event

Electronic identification changes that ratio.

After a digital transaction, what remains is not a mere copy of a document but a machine-readable result produced by state infrastructure:

identification successfully completed.

The next participant in the chain was not at the counter. They do not know whether the clerk looked at the face. They do not know whether the presenter lowered the mask. They do not know whether the mandatory human step of the procedure was performed at all.

They see the result. And the higher the trust in the digital infrastructure, the more natural it is to treat that result as proof that the entire preceding procedure was carried out correctly.

An evidentiary asymmetry appears:

the reliability of the record can grow faster than the reliability of the event it attests.

The practical burden in a dispute shifts with it. Previously an institution had to defend a weak set of its own documents; now a person has to challenge a formally strong record produced by trusted digital infrastructure.

This is not about the formal allocation of the burden of proof under the law. It is about the parties’ actual evidentiary position.

A Qualified Signature Shows the Same Problem from the Other Side

A qualified electronic signature creates a related but distinct problem.

A handwritten signature is produced by the signer’s body at the moment of signing. It can be forged, but the act and the person are physically bound.

The private key of an electronic signature exists separately from the person. Whoever actually controls the key can produce a cryptographically valid signature, regardless of whether they are its legal owner.

Verification of a qualified signature therefore establishes a very important but narrower fact:

the operation was signed with this key.

By itself it does not establish:

that the registered owner personally used this key at that moment.

The entire construction of non-repudiation thus rests on a presumption of the owner’s sole control over the key. That is a reasonable normative requirement — but a normative requirement is not an observed fact.

A key can be handed over. It can be copied, if the medium allows. It can be used by an employee, an accountant, a relative or an intruder. And if a trust architecture does not study the actual practice of credential control, it starts to mistake the intended mode of use for the real one.

The Diagram Does Not Show the Practice

Here is the more general conclusion.

An engineering diagram shows the correct route:

credential → verification → attestation → trusted decision.

But security is not determined by the arrows between the boxes. It is determined by what people actually do inside each box.

Whether they check the face. Whether they hand over keys. Whether they take the required copies. Whether they compare identifiers. Whether the action can later be reconstructed. And what happens when following the procedure gets in the way of speed, convenience or the usual workflow.

By practice we do not mean the steps a regulation prescribes. We mean what is actually and regularly done — the stable, repeated behaviour of real people at real counters. A rule that is written but not enacted is not part of the architecture; it is a wish.

None of that can be derived from a regulation. None of it can be read off an API description. And a cryptographic model does not show it. You have to look at the practice.

Trust architecture is an empirical object.

Why This Matters Again in 2026

Five years on, the old experiment took on an unexpectedly new significance.

Ukraine’s Starlink whitelist is also built as a chain of trust. The local side establishes the applicant’s identity and the device’s details; the registration result is passed on; SpaceX accepts it as the basis for deciding on network access for a specific terminal.

The operator was not at the registration counter. It did not see the applicant. It did not observe the local check. It received the result.

The July reports by Ukrainian law-enforcement authorities of mass unlawful terminal registration through the postal channel do not prove that clerks in 2026 behaved as the observed clerks did in 2021. That would be an unverified transfer.

The connection between the two cases is different. The 2021 experiment showed that the human action on which a digital chain of trust rests can systematically disappear from the real procedure without causing any technical failure of the system. In 2026, the price of the quality of such procedures became military — and the local registration layer became something an adversary would deliberately target.

Bottom line

Digital identification has no separate “digital reality” independent of the people who use it.

The cryptography can be sound. The credential can be valid. The database can run without error. The record can be genuine.

And none of that yet means that the event the record is meant to attest happened the way the architecture assumes.

Assessing a trust architecture therefore does not begin with its ideal diagram. It begins with a question:

What actually happens at the counter?

This is also where sovereignty is decided. A whitelist is a sovereign instrument: the state keeps the register and decides who reaches the network. But that control is only as real as the institutional capacity to make the prescribed procedure actually happen on the ground. Where that capacity is missing, the sovereign act exists on paper while eroding in practice — the register says one thing, the counter does another. Like the architecture beneath it, sovereignty does not hang in the air; it is exercised in practice, or it erodes.

Without knowing the facts on the ground, there is no way to know whether the system works the way its model assumes.

A trust architecture exists not in what is written, but in what is done.