Let’s take a few examples:
Gmail, “we do not read your mail to serve you ads” but if you pay for Workspace, “we will not train Gemini on your data” - so what if I don’t pay? Is there a sentence on that buried deep in the wall of text? Maybe. I live in Denmark where schools got in trouble for handing out Chromebooks to kids because of unclear boundaries and guarantees.
Meta is more direct. The products, Facebook, Instagram are ad platforms - and your data is “public” anyway… at least some of it. So anyone (if they would allow scraping) could do it - but they saw it first.
As a third example take card-payments. The large duopoly Visa and Mastercard are pretty straight about it: Yes, analytics, modeling, AI and “product development” happen on your data (and let me add you also pay for their services). Maybe Mastercard more than Visa. But smaller schemes like American Express are also in the game. It’s business.
The common theme of course is that inspecting your data brings benefits to you as a user. Who doesn’t want to fight card-fraud, email-spam or hateful posts on social media? That obviously only works if we can see the data - and we will also need to know “who you are” such that we can sanction you in case of a breach of terms.
A public post like this one is sort of “fair game”. I even put my name on it. If I didn’t want people and machines to notice my opinions I could have stayed under the tinfoil hat. But my post in that group of parents on Facebook? My email? Or my payments?
Eventually Fully Homomorphic Encryption (FHE) could save the day. Still want to look for spam or fraud in my data without actually reading it? Yeah, some day. Maybe even possible to run inference from an encrypted query - so welcome Private-ChatGPT!
But let’s be honest. It will not be free on the platforms: Increased compute and now limited possibilities to “extract” other value from the data. And you better read up on your math degree if you want to be really sure what is possible given a specific encoding. But it’s probably the holy grail for some use cases. When it scales.
End-to-end encryption of course could also shield your data from intermediaries. So that works fine if the platform is built like that. But the metadata and key agreements in groups? And again: Only while the platform stays like that. Everyone and their mom can put “end-to-end encrypted” on the box. But what’s really in the box is a bit of another story.
So let me present another comparatively stupid and simple alternative, which I think matches how “not so tech oriented” people assume things work today: Hand the data directly to the intended receiver. Do not mail your letter without an envelope - or better yet: Deliver it yourself. Out of sight, out of reach.
Well, how is that supposed to work then, you may ask. In this vast digital universe, where should I drop my letter to you? And if I pay you with a digital “note” (it even contains a signature from a real bank and all), what’s stopping me from giving the exact same bytes to another merchant? In fact: Let’s post it on the Internet, so more people can share it.
So are we talking Peer-to-Peer (P2P)? That doesn’t seem to solve any of those issues above, right? Adding on top of “what if you are not home/on”? So even if you rented an “endpoint” where I could deliver my mail - I still need to find you. So you could publish the IP/Port and the type of service (here is my “phone number”). Tricky if you need to change it later. So DNS then, that’s old as the Internet itself and just works (tm). But the UX and the cost? And each of my kids and the wife need an entry too? Okay, circle back to self hosting a mail server and a domain. Spammers ruined that one, didn’t they? Practically only established mail service providers are accepted in that game.
So let’s say that we actually had a shared and open service where I could bind a SHA of my name to an IP/Port of that service. Then you would be able to resolve “lars szuwalski” or whatever handle to an endpoint. Why not just the name? Of course I can make the service reject letters from unknown senders - but I could also not post the address in plain-text on the Internet. Let’s say I could update it when I got tired of one host and wanted to move to another. If it was really cheap to “write” in this registry I could easily change and add as I liked.
Then what about the payment? Digital money would be easy - but you need to know who owns a note at any point in time. So imagine the service above could map the SHA of that note to, say, a public key. And to hand it over to someone else would be signing the update of that entry with the matching key - and putting your public key on the note. And we just agreed it would be easy and cheap to update. So that could work for tickets and other such items as well, right?
The point is that current architectures don’t work like that. And the UX on established systems have been polished to the point where you don’t even notice the pill when you swallow. But those architectures are not handed down by God. Alternatives could be built. We do not need to walk around digitally naked.
Look at the footer: Well, it’s not working yet - so I’m not here to sell you anything. Just wanted to share my thoughts. Thanks for reading this far. Have a nice weekend!
]]>Vouchers, tickets, payment claims, receipts, licenses, account statements, certificates, shipping documents, credentials. They may be JSON, PDF, XML, CBOR, protobuf, plain text, or something more enterprise-shaped, but the pattern is familiar: create a document, sign it, send it, store it, process it.
Developers already know how to do this. We know how to hash documents, sign them, move them through apps, QR codes, NFC, RFID, HTTPS endpoints, files, merchant systems, and mobile wallets. We know how to transform and store them.
The hard part starts when the document crosses an organizational boundary.
A shop receives a voucher and wants to know whether it was already spent somewhere else.
A venue scans a ticket and wants to know whether the holder still controls it.
A merchant receives a payment claim and wants to know whether that same claim was also sent to another merchant.
A verifier receives a credential and wants to know whether the issuer has revoked or superseded it.
These are lifecycle questions. Not “what does the document say?” but “is this document still the current, valid version that someone is allowed to act on?” That is global state.
Today, the usual answer is: ask the database. But whose database?
That is where banks, card networks, platforms, issuer portals, SaaS registers, and reconciliation systems enter the picture. Someone governs the shared register. Everyone else integrates with it, waits for it, pays for it, or trusts it.
EC Protocol explores a different split:
Keep the documents wherever the application wants. But track their lifecycle through handles in a shared verification network.
The document carries the meaning. The hash of it is the handle. EC tells you whether that handle is still current.
Let’s explore a style of document application that becomes possible in that world.
Suppose you want to build a gift card, voucher, or payment-claim system. That is not simple with today’s infrastructure.
You could define a document format:
issuer: MallAuth
value: 100
currency: DKK
expiry: 2027-12-31
schema: https://example.net/schemas/voucher-v1
issuer_public_key: ...
issuer_signature: ...
Define canonical serialization, so everyone hashes the same bytes.
Define signature rules.
Define what counts as a valid transfer, redemption, revocation, or split.
None of that requires special infrastructure. It is ordinary document processing.
When the system hands the document to a customer, it does this:
token_id = hash(document)
create token_id, owner = user_public_key
This registers the token in EC under the user’s public key. The user’s wallet checks the issuer signature, verifies that the issuer is trusted, computes the document hash, and confirms that the resulting token ID is controlled by the user’s key.
At this point, EC does not know the voucher terms. It does not know the customer identity. It does not need the document contents.
It only knows that this hash exists as a token, and that the user’s key currently controls it.
The issuer created the meaning. EC tracks the lifecycle.
Now the user wants to spend 30 units at a shop and keep 70 as change.
The wallet, or a transformer endpoint, creates two child documents. Each child is a full copy of the parent with one new section appended.
The 30-unit child:
issuer: MallAuth
value: 100
currency: DKK
expiry: 2027-12-31
issuer_public_key: ...
issuer_signature: ...
---
split:
value: 30
salt: random_salt
The 70-unit change document:
issuer: MallAuth
value: 100
currency: DKK
expiry: 2027-12-31
issuer_public_key: ...
issuer_signature: ...
---
split:
value: 70
salt: same_random_salt
The wallet or a transformer endpoint computes:
parent_token = hash(parent_document)
shop_token = hash(child_document_30)
change_token = hash(child_document_70)
Then it submits one atomic EC transaction:
destroy parent_token, signature(user_public_key)
create shop_token, owner = shop_public_key
create change_token, owner = user_public_key
Notice that the signature for the existing parent_token is part of the transaction, and that the public key of the change_token does not need to be the same key used for the parent.
This write requires access to an EC node with write capability. A wallet provider, issuer, merchant, gateway, or user-operated node could provide that path. Reads are open, so even if the merchant submits the actual transaction, the user can check the result independently.
But the document logic itself is ordinary:
There is no voucher balance database in the middle.
There is still shared infrastructure. The difference is that it tracks document lifecycle by hash, not application-specific balances, accounts, or voucher records.
When the shop receives the 30-unit document, it can verify it without asking the issuer for the full document history.
Because each child is a copy of the parent with a section appended, the shop can reconstruct the ancestry by removing sections from the end. For this split, the 30-unit child also contains enough information to derive the matching 70-unit change document: the original value, the split amount, and the shared salt.
For example:
hash(synthetic_child_document_70)
hash(child_document_30)
hash(parent_document)
If the document had gone through five transfers or splits, the shop could derive those earlier states the same way: remove the last section, hash; remove the next section, hash; continue back to the issuer-signed root.
Then the shop queries EC for those token IDs.
Those reads are open. A verifier does not need to be the issuer, the owner, or a member of a private platform. Any node can be an entry point for queries, and a client can discover the network from a small set of bootstrap nodes.
The shop checks:
For low-value cases, one query path may be enough. For higher-value cases, the shop can query multiple nodes, store signed answers, and wait for stronger confidence before granting value.
The important thing is that read verification is not locked behind the issuer’s API.
Users, merchants, issuers, auditors, intermediaries, and validators can all check current and recent historical state directly from the EC network. But only if they hold the document, and that matters. EC nodes never see the document contents. There is no global document store to leak, steal from, or scrape.
When the shop accepts the voucher, it can consume the 30-unit token or transfer it back to the issuer for settlement.
For example:
destroy shop_token
or:
transfer shop_token, owner = issuer_public_key
The issuer then settles according to its own business rules.
EC does not make the voucher valuable. The issuer does. EC makes the voucher independently transferable and verifiable before redemption.
A shop does not need to trust the customer’s wallet. It does not need to trust another shop. It does not need direct access to the mall’s live database.
It needs the issuer key, the document, and EC queries.
A payment claim can use the same pattern.
A bank, fintech, marketplace, local currency system, or prepaid issuer signs a claim document. A user holds it. A merchant receives it. The merchant checks EC before granting value. The issuer settles when the claim is redeemed.
This is not “trustless money.”
It is issuer-backed value with portable document custody.
The issuer remains the trust anchor. The merchant still cares whether the issuer is good for settlement. Legal and commercial relationships still matter.
But the shared state register no longer has to be governed by one bank, one platform, one card network, or one merchant database.
The issuer signs meaning. The user carries custody. EC tracks lifecycle. The merchant verifies before acting.
If the user signs two incompatible successors, the result is not two clean payments. The conflict becomes visible at verification or redemption.
The attack does not create money. It creates evidence. Since the issuer will eventually check the document chain and redeem only valid claims, intermediaries have the same incentive: verify before accepting, or risk holding worthless claims.
An EC-based document application would still need normal software.
The issuer needs:
The user wallet needs:
The merchant or verifier needs:
Gateways and infrastructure providers can offer:
But none of these actors need to host the canonical voucher database.
The document is carried by the parties. EC provides the shared lifecycle check.
Today, shared lifecycle usually means one of a few things.
Trust the issuer’s live database. Integrate with a dominant platform. Use a bank or card network. Publish state to a global ledger. Reconcile later and accept fraud windows.
EC proposes a different split:
That is the interesting part.
A voucher can move between parties without every shop sharing a backend.
A payment claim can be verified before redemption without every merchant depending on the issuer’s live API for every step.
A ticket can be held by the user, transferred as a document, and consumed at entry.
A credential can be presented from a wallet while EC answers whether it is still live, revoked, or superseded.
EC does not replace existing institutions. It changes who has to govern the shared state register.
This does not solve everything.
EC does not automatically provide issuer honesty, legal enforcement, privacy, key recovery, offline finality, good redemption policy, or good document design.
If a document leaks private data, EC does not make it private. If an issuer refuses to redeem, EC does not make them honest. If a user loses their key, the application needs a recovery policy. If a high-value claim lives for a long time, it may need monitoring and stronger verification.
But those are application design problems around a smaller primitive.
Instead of asking every participant to join the same platform, you ask them to agree on document formats, issuer keys, and EC verification rules.
If EC worked at global scale, many multi-party applications would not need a shared application database for document lifecycle.
They would need shared document rules and a public lifecycle check.
That is the part worth exploring: not a new asset class, not a platform that owns the register, not a world where every business object is uploaded into someone else’s infrastructure.
Just signed documents, hashes, ordinary transport, and an open network that answers one question:
Is the thing I hold still current?
Which workflows already move documents but depend on someone else’s register?
What could be built if users could safely carry the state themselves?
Where does this model fail?
The EC Protocol repo, simulator reports, and design documents are at EcProtocol/EcNode. The README is the best starting point.
]]>The usual answer is simple: put the records in a database.
That works beautifully until the parties do not want the same operator to control the database. Whoever runs it can censor, rewrite, selectively enforce, lose, or surveil the shared state. Sometimes that trust is acceptable. Sometimes it is exactly the problem.
The other familiar answer is a global ledger: replicate the state widely, globally order transactions, and make the history publicly auditable.
That solves one class of trust problem, but it buys that solution with global coupling. Everyone is tied, directly or indirectly, to the same ordering machine. The system needs broad quorums, committees, fork-choice rules, permanent history, or incentive machinery to keep the whole thing moving in one direction.
This raises a question:
Can we share state without trusting one operator, but also without forcing every record through one global consensus system?
EC Protocol is an experiment in that third way.
EC does not try to make every participant agree on every event.
Instead, it treats shared state as local. Records are assigned to token neighborhoods. A commit requires evidence from the relevant neighborhood, not from the whole world. The goal is not a single universal history of everything. The goal is that, for a given record, the relevant peers can detect conflicts and avoid accepting multiple incompatible outcomes.
That is a narrower and more achievable target.
EC is not “no consensus.” It is no global consensus over all records.
The protocol’s job is to make conflicts visible, attributable, and hard to profit from.
A lot of distributed safety machinery is built around conflicting histories. If two incompatible transactions exist, the system needs some way to decide which one wins. That often leads to global ordering, fork choice, or Byzantine agreement.
But many real applications have an important property:
A valid state transition must be signed by the owner.
A payment must be signed by the payer. A voucher transfer must be signed by the holder. A ballot must be signed by the voter’s credential. A name update must be signed by the current controller.
The network can delay messages. It can censor messages. It can replay messages. It can route messages badly.
But it cannot manufacture a valid owner-signed conflict.
Only the key-holder can do that.
That changes the shape of the problem. A conflict is no longer anonymous noise injected by the infrastructure. It is signed evidence that a specific key equivocated.
The protocol does not need to prevent someone from signing twice. Cryptography cannot stop you from using your own key badly. What the protocol can do is make sure that signing twice does not silently create two valid outcomes.
In EC, the interesting safety claim is not “conflicts never happen.”
Conflicts absolutely can happen. A malicious or careless owner can sign incompatible records.
The claim is that, in the application classes EC is designed for, a visible conflict usually harms the signer rather than helping them.
The network’s job is to ensure that conflicting contenders become visible to the relevant neighborhood, and that applications can treat conflict evidence as invalidating, freezing, or burning the claim.
Suppose a payer signs two incompatible payments using the same spendable claim.
In a naive system, that might look like an attempt to get free money. In an EC-style system, the conflict is evidence against the payer’s own claim.
At redemption, the issuer or recipient does not merely ask “do I have a signed payment?” They ask whether the payment committed cleanly, and whether conflicting contenders exist.
If one payment wins, the conflict is visible. If neither resolves, the payer has created a stalled or suspicious claim. What they do not get is two clean redemptions.
The attack does not create money. It creates evidence.
A voucher has the same structure.
The holder can sign a transfer. If they sign two incompatible transfers, they are not duplicating value. They are damaging their own entitlement.
The issuer can see that the voucher history contains a conflict and reject, freeze, or burn the voucher according to the application rules.
Again, the network did not need to make double-signing impossible. It needed to make double-signing visible.
Voting is even cleaner.
A double ballot should not count as two votes. It should count as evidence that the credential equivocated.
The natural application rule is simple: if a voter credential signs conflicting ballots, the ballot counts as zero or is escalated into a dispute process.
The attacker’s payoff is not “two votes.” The attacker’s payoff is, at best, destroying their own vote.
Name registries and public-key infrastructure have a similar pattern.
If the controller of a name signs conflicting ownership records or incompatible delegations, that conflict weakens the authority of the key that signed it.
A relying party does not need every name update in the world to be globally ordered forever. It needs conflict-visible evidence around the name or token being resolved.
That suggests a different architecture for name ownership: local verification, explicit delegation, visible equivocation, and bounded history.
These examples have something in common.
They involve owner-signed state transitions where equivocation naturally damages the equivocator’s own claim.
That does not make all attacks disappear. It does not solve censorship, key theft, denial of service, bad issuers, or bad application rules.
But it does mean that the most important conflict case has a different character.
The network is not trying to globally order away every possible contradiction. It is trying to expose contradictions so that the application can apply the obvious rule:
If you signed incompatible claims, you do not get to profit from both.
The current EC simulator has been testing this under conflict-heavy conditions.
Under 30% conflict load across 2000 peers, meaning nearly a third of all tokens had competing signed transactions, the run produced:
In plain language: we did not observe cases where the losing side of a conflict committed, and we did not observe multiple incompatible winners.
There was also an important measurement correction.
An earlier metric made convergence look much worse than it was. We were undercounting success because committed blocks that had already been extended were dropping out of the success measurement. After correcting that, apparent convergence moved from roughly 7% to roughly 93%.
That correction matters. This project is still research-stage, and the point is not to polish the numbers into a sales pitch. The point is to make the protocol measurable enough that wrong interpretations can be found and fixed.
If this model holds, it opens up an architectural space between centralized databases and global ledgers.
You do not need one operator to own the database.
You also do not need every participant to store, order, and validate every record forever.
Instead, EC aims for:
That last point is important. EC is not trying to build a new economy around consensus. It is trying to make shared state cheap enough and local enough that many applications can use it directly.
Bounded retention is part of the design philosophy too. Many systems treat deletion, expiry, and the right to be forgotten as awkward layers on top of permanent infrastructure. EC explores the opposite direction: shared state with retention limits built into the protocol shape.
This is not a claim that EC is production-ready.
It is not a claim that local neighborhoods magically solve all adversarial behavior.
It is not a claim that every application fits this model.
And it is definitely not a claim that networks cannot censor, delay, partition, or attack routing.
The narrower claim is the interesting one:
For owner-signed state transitions, conflict can be treated as attributable evidence instead of something that must always be prevented by global ordering.
That is the idea worth testing.
EC Protocol is currently a Rust reference implementation and simulator suite. The simulator works. The claims are being sharpened. The gaps are real.
Where does local neighborhood consensus fail under adversarial topology, churn, censorship, or key compromise?
Which applications do not fit the self-punishing conflict model?
What breaks this reasoning entirely?
The repo, simulator reports, and design documents are at EcProtocol/EcNode. The README is the best starting point.
]]>