The key lives nowhere.
And you can verify that for yourself.
AERKey signs on behalf of institutions — transactions, smart contracts, payment instructions, settlement messages — without anyone, anywhere, ever holding the key. The key as a single object does not exist. What exists is a distributed agreement among hardware-attested enclaves, scattered across multiple continents and multiple independent clouds, that together produce a valid signature when, and only when, the institution's own rules permit. The output is an ordinary ECDSA signature. The infrastructure underneath is anything but ordinary.
An educational conversation between two industry veterans · AERKey · ~9 min
Seventeen years of paper over the same crack.
For nearly two decades, every blockchain signature has begun with a single private key in someone's custody. Hardware wallets put it behind a chip. Multi-signature schemes put copies behind several chips. Institutional custody platforms put it behind threshold cryptography — real progress, but with the same residual weakness underneath: the platform operator is trusted to run the system honestly, on infrastructure they own, with code their customers cannot independently verify.
The losses tell the story. Mt. Gox, FTX, Ronin, Wormhole, dozens more — collectively billions of dollars, all traceable to compromised keys or to single points of trust that turned out to be single points of failure. The seed phrase, in one form or another, has remained the deepest vulnerability in the entire digital asset stack.
AERKey exists because the answer to "where is the key?" should not be "trust us." It should be: nowhere, and you can verify that for yourself.
A distributed agreement, not a stored secret.
AERKey runs as a small number of hardware enclaves distributed across multiple independent clouds and across multiple continents. When a key is created, each enclave independently generates its own cryptographic share inside protected memory. Any threshold of shares can produce a valid signature, but no individual share, and no subset below the threshold, reveals anything about the eventual signing key. The full key is never assembled. There is no moment in the system's history where it exists in one place to be stolen.
Every step runs inside attested hardware. The cloud providers themselves cryptographically prove that the code inside each enclave is the code that should be there, untampered, and that no operator — including AEREDIUM — can see inside. On top of that primitive sits USIG, our patented anti-equivocation primitive (USPTO 63/977,868), which gives each enclave a hardware-attested counter that makes equivocation by any signing node impossible rather than merely difficult. This is the property the rest of the category cannot offer without licensing the patent, and it is what allows AERKey to achieve Byzantine fault tolerance with fewer signing nodes than every alternative requires.
The signature that comes out is ordinary. The architecture that produces it is not.
Four audiences, one primitive.
From the individual user to the sovereign treasury, the safety property is structural rather than behavioural — you cannot accidentally compromise something you never had.
A category of products has emerged. Then there is AERKey.
The leading platforms in institutional custody have built genuinely capable products. They distribute keys into shares, run them inside secure enclaves, offer policy engines, and together secure trillions of dollars. They are not weak products. The difference between them and AERKey is not what they do — it is who runs them, and on what terms.
Decentralized cryptography. Centralized everything else.
Once you look at how a typical platform in this category is actually engineered, rather than how it is marketed, the shape is consistent. The cryptographic distribution is sound. The architecture around it is not designed to remove the vendor from the trust path. The vendor is the trust path.
- Two of three signing nodes are operated by the vendor on the vendor's infrastructure — majority signing control sits with the vendor by construction.
- The customer's signing node runs inside one cloud provider's enclave, not three.
- Remote attestation is generated by the vendor's own server and validated by the vendor's own loading executable; customers are told there is "no need" to verify enclave signatures independently.
- The policy engine sits inside the same component as the signing code, in the same trust domain — compromise the component and the policy goes with it.
- The audit log is a vendor-stored record. Auditors read what the vendor chooses to show them.
The cryptography prevents key extraction. Vendor dependency was never the property the underlying cryptography was designed to address. For a regulated institution, that residual risk is exactly the risk its mandate exists to avoid.
Decentralized by architecture, not by configuration.
AERKey is built so that the vendor — including AEREDIUM itself — is structurally absent from the trust path. The properties are preconditions of the architecture, not deployment choices that can be reversed.
- Signing nodes distributed across multiple independent clouds across multiple continents; no single vendor or jurisdiction can compromise the system.
- Hardware attestation is open — any counterparty, auditor, or regulator can independently verify that signing occurred inside legitimate enclaves running legitimate code, without taking AEREDIUM's word for it.
- Policy is bound to the cryptographic signing layer in a way that means policy and signature are the same act — not separately compromisable.
- Patented anti-equivocation primitive (USIG, USPTO 63/977,868) gives a structural moat the category cannot replicate without licensing.
- The audit log is anchored to the AEREDIUM blockchain — neither AEREDIUM nor any subsequent operator can quietly rewrite the record without leaving a permanent visible gap.
The trust assumption shifts from "we trust our custody vendor to remain honest, solvent, and uncompromised" to "we trust open cryptography across three jurisdictions, anchored to a public ledger." The category's leading platforms are very well-run vendors. AERKey is a structural alternative to needing to choose one.
Rules enforced by the signing primitive itself.
Every key issued by AERKey is governed by the Policy Engine — a programmable rule set, sealed inside the enclaves themselves, that defines what the key may sign and under what conditions. Spending limits per day, per hour, per transaction. Whitelisted destination addresses. Time-of-day restrictions. Multi-party approval workflows above threshold values. Velocity controls that throttle suspicious patterns. Counterparty exclusions for sanctioned addresses.
None of this runs as a smart contract, which would lock policy to a single chain and add gas costs to every operation. It runs inside the cryptographic signing layer itself, which means it works identically across every chain AERKey supports, present and future — because the policy fires before the signature is produced, and the chain only ever sees the result.
The Policy Engine also separates roles. Auditor tokens grant read-only access across all signing activity. Partner tokens grant read-only access scoped to a single client's namespace — the institution can see everything about its own signing and is structurally blind to every other client's data, because the partner token cannot produce a query that returns it. This is not a configuration that could be turned off by mistake. It is the architecture.
An audit that AEREDIUM itself cannot rewrite.
Every signing operation — every signature, every policy evaluation, every key generation, every share refresh — emits an audit entry. The entries are gathered into a Merkle tree, and the root is periodically anchored to the AEREDIUM blockchain. This is the part that closes the loop.
The AEREDIUM blockchain is a public, EVM-compatible Layer 1 in its own right, running on the same hardware-attested validator architecture. When an AERKey audit root is anchored, the anchor itself is signed by a quorum of threshold validators on the blockchain consensus layer — which means it cannot be forged, cannot be quietly rewritten, and cannot be omitted without leaving a permanent gap visible to any auditor with the public record. Even AEREDIUM staff, with full internal access, cannot rewrite the audit log without breaking the anchor — and breaking the anchor is visible to everyone.
The audit is not produced by AEREDIUM and shown to the auditor on AEREDIUM's screen. It is produced by the cryptographic protocol itself, anchored to a public ledger AEREDIUM does not control alone, and verifiable by any party with the relevant credentials and a network connection. For a customer's risk officer, an external auditor, or a regulator, the distinction between those two propositions is everything.
A structural answer to a problem the industry has papered over.
A bank can use AERKey and know that its custody operation cannot be compromised by insider collusion, cloud-provider failure, vendor bankruptcy, or any single point of trust — because none of those single points exist.
A corporate treasury can replace the seed-phrase, hardware-wallet, multi-sig, hot-wallet, cold-wallet, ceremony, and approval-workflow patchwork with one unified primitive that does all of it at once and produces an audit trail no party — including AEREDIUM — can rewrite.
A government can run CBDC, reserves, or sovereign settlement on infrastructure that does not depend on any single private company in any single jurisdiction.
An individual can stop being one shoulder-surf away from losing everything.
The answer AERKey gives is that the key lives nowhere, and the trust is placed not in a company but in cryptography, attested hardware, public-ledger anchoring, and the impossibility of multiple independent clouds across multiple continents being simultaneously compromised. That is a higher floor of safety than any custody product has previously offered, and it is the reason institutions that have looked seriously at the alternatives have started to look at this.
Contact us for more information about AERKey.
AERKey is live now. Access is available on request before testnet, which opens in June 2026. Mainnet follows in August 2026. Engagement begins with a mutual NDA and a scoping conversation.