By Albert Dadon, Founder & CEO, AEREDIUM Holdings Inc.
A Problem Worth Solving
In 2024, over $3.8 billion was stolen from blockchain platforms. Not through sophisticated zero-day exploits or quantum computing attacks. Through something far simpler: compromised private keys.
Every blockchain ever built — Bitcoin, Ethereum, Solana, all of them — relies on a single elliptic curve private key to authorise transactions. One key. Whoever holds that key controls everything. One compromised hardware wallet, one rogue insider, one phished seed phrase — and the funds are gone. Irreversibly.
This is not a bug in any particular implementation. It is the fundamental architecture of every blockchain in existence. And it may be the single biggest unsolved problem in the digital asset industry.
I believe we have found a path to solving it. We are early in this journey, and what follows is the story of how we got here — not a claim of victory, but an account of a discovery and the direction it has taken us.
An Academic Paper from Lisbon
In 2013, five researchers from the University of Lisbon, the Federal University of Santa Catarina in Brazil, and Stefanini IT Solutions published a paper in the IEEE Transactions on Computers titled "Efficient Byzantine Fault-Tolerance." The authors — Giuliana Santos Veronese, Miguel Correia, Alysson Neves Bessani, Lau Cheuk Lung, and Paulo Veríssimo — were working on a problem in distributed systems theory.
The problem was this: in traditional Byzantine Fault Tolerant (BFT) consensus protocols like PBFT (Practical Byzantine Fault Tolerance, introduced by Castro and Liskov in 1999), you need at least 3f+1 servers to tolerate f faulty ones. So to survive one bad actor, you need four servers. To survive two, you need seven. This is expensive and complex.
The Lisbon team’s insight was elegant. They asked: what if each server had a tiny tamper-proof component — a monotonic counter that only goes up — that signed every consensus message with a unique sequential number? If the hardware guarantees that a server can never sign two different messages with the same counter value, then double-signing (equivocation) becomes cryptographically impossible. Not economically punished. Not detected after the fact. Impossible.
They called this component a USIG — Unique Sequential Identifier Generator. And they proved that with USIG, you could reduce the fault tolerance threshold from 3f+1 to just 2f+1. Three servers instead of four. Five instead of seven. The math was clean, the proof was rigorous, and it was a genuine contribution to the field.
The researchers were solving the problem in front of them — making distributed clusters more efficient. That was the world they were working in. The blockchain industry as we know it today, with its billions in stolen assets and its structural key management failures, did not exist when they wrote their paper.
The Intellectual Ancestry
The USIG concept did not emerge from nowhere. It stands on the shoulders of earlier work.
In 2009, four researchers at Microsoft Research — Dave Levin, John R. Douceur, Jacob R. Lorch, and Thomas Moscibroda — published a paper at USENIX NSDI titled "TrInc: Small Trusted Hardware for Large Distributed Systems." TrInc (Trusted Incrementer) proposed something deceptively simple: a tiny hardware component consisting of nothing more than a monotonic counter and a cryptographic key. The counter only goes up. The key signs attestations binding messages to counter values. Once you’ve bound a message to counter value 7, you can never bind a different message to value 7. Equivocation is structurally eliminated.
Levin et al. demonstrated TrInc’s versatility with case studies in BitTorrent (preventing free-riding), PeerReview (accountability in distributed systems), and append-only memory. Their contribution was showing that this trivially simple primitive — a counter and a key — has remarkably broad applicability.
TrInc itself built on even earlier work: Attested Append-Only Memory (A2M) by Chun, Maniatis, Shenker, and Kubiatowicz, which proposed a trusted log facility for BFT systems. The TrInc team explicitly designed their system as a simpler, smaller alternative — arguing that protocol designers would be reluctant to assume the availability of a full trusted log, but might accept a mere counter.
Veronese et al. then took TrInc’s concept and formalised it specifically for BFT consensus as USIG, proving the 2f+1 reduction. Hyperledger Labs later produced an open-source implementation of MinBFT with USIG running inside Intel SGX enclaves.
Each of these contributions was valuable on its own terms. The researchers were working on the problems that mattered in their era — making distributed systems more reliable and more efficient. They could not have foreseen the application I am about to describe, because the problem it addresses had not yet emerged.
How I Found It
It was not until early 2026 that I stumbled upon this research.
I was not looking for ways to make distributed databases more efficient. I was looking for something that had been nagging at me for a long time: a way to eliminate human intervention entirely from the validation process of a blockchain. My reasoning was simple. If you could remove the need for human validators, the entire apparatus of "governance" — a process designed to control human impulses and verify that no one is cheating — could go away. And with it would go MEV (Maximal Extractable Value) and all the mechanisms designed to cheat the end user and enrich a new class of villains who extract value from the very people the technology was supposed to empower.
I thought: if machines could validate each other through hardware attestation, and if a cryptographic mechanism could make it physically impossible for any machine to lie or double-sign, then you would not need governance at all. You would not need staking, slashing, delegation, or validator committees. You would need only mathematics and hardware.
That is when I found the Veronese et al. paper. And I saw something that excited me enormously. These researchers had given the world a mechanism to make equivocation cryptographically impossible — but they had applied it to reducing server counts in small clusters. The application I had in mind was entirely different.
In a very short period of time, this went from an idea to working code. What enabled me to make that leap was USIG. I owe a genuine debt to those academics who provided a solution for a problem that had nothing to do with what we are trying to resolve today. They simply could not see the application, because the problem did not yet exist.
What We Are Building
The system we built is called AEGISKey.
AEGISKey eliminates the single private key entirely. There is no key to steal, because no complete key exists anywhere. The signing capability is broken into pieces and fully distributed across multiple independent, hardware-attested environments. No single machine — and no human — ever possesses the full signing authority. To produce a valid signature, a threshold of these independent environments must independently agree. The result is a standard cryptographic signature that any blockchain can verify — but the security model behind it is fundamentally different from anything that exists today.
We believe this approach has the potential to address the private key problem at its root. We are still early in proving that out, and there is a great deal of work ahead. But the foundation is in place, and what we have seen so far gives us confidence that we are on the right path.
Why AEGISKey Is Not MPC
When we describe AEGISKey to security professionals, the first response is almost always: "So it’s like MPC?"
It is not. And the distinction matters.
Multi-Party Computation (MPC) wallets have become the industry’s standard answer to the private key problem. They split key material across multiple parties who jointly compute signatures without reconstructing the full key. On paper, this sounds similar to what AEGISKey does. In practice, the differences are fundamental.
MPC is centralised. AEGISKey is decentralised. MPC wallet providers typically operate all the signing parties themselves, or distribute them across a small number of controlled environments within a single corporate boundary. The parties know each other, trust each other, and are managed by the same organisation. If that organisation is compromised — by an insider, a regulator, a court order, or an attacker — all parties can be compelled simultaneously. The distribution is operational, not architectural. AEGISKey distributes signing authority across independent, geographically separated, hardware-attested environments with no single controlling entity. Compromise of one environment yields nothing usable.
MPC trusts software. AEGISKey trusts hardware. MPC protocols run in standard computing environments. The security assumption is that the software is correct and the machines are not compromised. There is no hardware root of trust, no attestation that the code running the MPC protocol is the code that was audited. AEGISKey runs inside hardware-attested Trusted Execution Environments where the code integrity is measured and verified by the hardware itself. The host operating system, the cloud operator, and even the infrastructure provider cannot see or modify the signing process. Every signing operation carries a hardware attestation proving what code produced it.
MPC has no audit trail. AEGISKey has a complete one. This may be the most critical difference for institutional adoption, and it is worth explaining in detail.
The Audit System: Why Signing Without Proof Is Worthless
A signature without an audit trail is a liability, not an asset. If a regulator asks "who authorised this $50 million transfer and under what conditions?" the answer cannot be "our MPC provider says so." That is not proof. That is trust in a third party — the very thing blockchain was supposed to eliminate.
AEGISKey’s audit system produces independently verifiable proof for every signing operation. Not a log. Not a database record. Cryptographic proof — anchored to hardware attestation documents that can be verified by any third party without trusting AEREDIUM or anyone else.
For each signing event, the audit system records: the attestation state of every participating environment (proving the code integrity), the policy that was evaluated (proving the authorisation logic), the threshold participation (proving that the required number of independent parties agreed), and the sequential counter value from the USIG (proving that no conflicting signature was ever produced with the same counter). This is the USIG concept from the 2013 paper — but applied not to consensus messages between database replicas, but to signing operations that govern real assets.
An auditor, a regulator, or a counterparty can independently verify the entire chain: the hardware attestation proves the code was unmodified, the USIG counter proves no equivocation occurred, the policy record proves the conditions were met, and the threshold participation proves no single party acted alone. No trust in AEREDIUM required. The math speaks for itself.
Without this audit trail, even the most sophisticated signing system is just a black box. Institutions cannot adopt black boxes. They need proof. AEGISKey provides it.
The Policy Engine: Code as the Authority
The second component that distinguishes AEGISKey from MPC solutions is the policy engine.
In an MPC wallet, signing policy is typically a set of rules configured by an administrator: "require 2-of-3 approvers for transactions over $10,000," or "allow only whitelisted addresses." These policies are enforced by software running on standard servers. The policies can be changed by anyone with admin access. They can be overridden. They can be bypassed by compromising the policy server.
In AEGISKey, the policy engine runs inside the hardware-attested environment alongside the signing process. The policy is part of the measured code — meaning any change to the policy changes the hardware attestation measurement. A modified policy cannot produce valid attestation documents. The policy engine evaluates conditions programmatically at the moment of signing, and the evaluation result is included in the audit trail.
This means smart contracts can define their own signing policies that are enforced by hardware, not by humans. No human approver in the loop. No admin override. The code decides, the hardware enforces, the audit trail proves it.
For institutional clients — banks, asset managers, exchanges — this is the difference between "we trust our vendor’s security" and "we can demonstrate to our regulator exactly what happened, why it happened, and that it could not have happened any other way."
An Ongoing Journey
I want to be clear about where we are. We are at the beginning of this journey, not the end. The technology works — our consensus engine runs on a live validator network and AEGISKey is operational. But we have not yet proven this at the scale and in the production environments that will ultimately determine whether our approach succeeds.
What I can say with confidence is that the direction is right. The private key problem is real, the losses are real, and the existing solutions — including MPC — have fundamental limitations that we believe our approach can address. Whether we succeed will depend on execution, not just architecture.
I owe a great debt to the researchers whose work made this possible. Veronese, Correia, Bessani, Lung, and Veríssimo proved that a monotonic counter inside a trusted environment could transform the security properties of distributed systems. Levin, Douceur, Lorch, and Moscibroda showed that a counter and a key, simple as they are, could prevent equivocation across a wide range of applications. Castro and Liskov established the Byzantine fault tolerance framework that underpins all of this.
These researchers provided the intellectual tools. They solved problems that mattered in their time, with rigour and creativity. The fact that the world changed in ways that gave their work new and unexpected relevance does not diminish what they achieved — it amplifies it.
The academics discovered a big idea while working on small problems. We are trying to apply it to one of the biggest problems in digital finance. We will see where it takes us.
References:
Albert Dadon is the Founder and CEO of AEREDIUM Holdings Inc., a blockchain infrastructure company building institutional-grade products for the stablecoin and real-world asset economy. He is also a jazz guitarist and composer professionally known as Albare, and Chairman of the Australian Friends of Reichman University.