Every security architecture eventually answers the same question: what happens when a key is compromised? The obvious answer is to freeze it. The harder answer is: who gets to pull that trigger, how fast, and what stops that power from being abused?
In traditional finance, freezing an account means calling a back-office team, escalating through a compliance workflow, and hoping the chain of custody documentation survives an audit. In crypto lending, it means revoking a signing key — and if that revocation isn’t governed correctly, you’ve either left a compromised key active too long, or handed someone a unilateral power over member collateral that no examiner should ever sign off on.
Aetherum solves this with an explicit, on-chain freeze governance model. It is not a policy. It is enforced by the contract.
HOW FREEZE AUTHORITY WORKS
Every credit union that deploys Aetherum holds two classes of keys. The Admin Key lives in cold storage at the board level. Loan officers hold Operational Keys for day-to-day signing — authorizing collateral deposits, loan disbursements, and collateral releases.
If a loan officer’s Operational Key is suspected compromised, the Admin Key can freeze it immediately. There is no delay, no help desk ticket, no waiting for a vendor response. The freeze takes effect on-chain in the same block as the transaction — and from that moment, the frozen key cannot authorize any collateral movement, regardless of what the holder tries to sign.
Every freeze event is written to the AuditTrail contract: which key was frozen, which Admin Key authorized it, and the exact block timestamp. That record cannot be altered or deleted after the fact.
“The freeze takes effect on-chain in the same block as the transaction. From that moment, the frozen key cannot authorize any collateral movement — regardless of what the holder signs.”
WHAT THE ADMIN KEY CANNOT DO
Freeze authority sounds powerful — because it is. So the design question becomes: what constrains it? Two things.
First, the Admin Key can freeze Operational Keys instantly, but Admin Key rotation itself carries a mandatory 48-hour timelock. If someone attempts to rotate the Admin Key — the master authority over the entire lending system — the credit union has 48 hours to detect and challenge it. A compromised Operational Key cannot accelerate or bypass that window. Even a compromised Admin Key cannot silently replace itself without leaving a 48-hour window for the board to intervene.
Second, no key freeze — at any tier — can block a member’s emergency collateral recovery. If a credit union becomes operationally unreachable, a member can initiate the recovery process regardless of the state of the institution’s keys. Only the cold-storage Admin Key can veto that recovery during the review window. A frozen Operational Key has no veto authority at all.
Freeze authority flows in one direction: down the key hierarchy, never up. An Operational Key cannot freeze the Admin Key. A frozen key cannot unfreeze itself. And no combination of Operational Keys — compromised or otherwise — can override the member recovery path. This is architecture, not policy.
WHAT THE EXAMINER SEES
When an NCUA examiner asks about a freeze event — what triggered it, who authorized it, what happened to active loans during the freeze period — they don’t need to request records from Aetherum or from the credit union’s internal systems. They query the AuditTrail contract directly.
The on-chain record shows the freezing Admin Key, the frozen Operational Key, the block timestamp, and every collateral event that preceded and followed the freeze. If the credit union subsequently restored the key or issued a replacement, that rotation is in the same record. The examination packet builds itself from facts that neither party can revise after the fact.
That matters during routine examination. It matters even more if a freeze event becomes part of a larger inquiry — because the record existed from the moment of the transaction, not from the moment someone prepared a response.
WHY THIS IS DIFFERENT
Most crypto lending platforms treat key revocation as an operational event — something handled through an admin dashboard, logged to a database, and surfaced through API calls to the vendor. That means the freeze record is controlled by the vendor. If the vendor’s infrastructure is down, or if the vendor relationship ends, that record becomes inaccessible.
Aetherum’s freeze events live on Sepolia’s public ledger. They are readable by any party with an RPC connection. The credit union doesn’t need Aetherum’s cooperation to prove what happened, when it happened, and who authorized it. That’s not a feature we added for compliance optics — it’s the property of writing governance events to a public, append-only ledger in the first place.
Every freeze event produces an immutable on-chain record: freezing key, frozen key, block timestamp, and preceding collateral state. No API credentials required. No vendor cooperation required. Queryable by any standard RPC call — independently, at any time, for any period in the contract’s history.
THE BOTTOM LINE
Freeze authority is not an edge case. It is a core part of how any institutional key management system gets stress-tested — by examiners, by auditors, and eventually by real incidents. The question isn’t whether your system can freeze a key. The question is whether the governance around that power is legible, constrained, and independently verifiable.
Aetherum’s answer is on-chain. Credit unions can show any examiner exactly who holds freeze authority, what limits apply to it, and a complete chronological record of every time it has been used — without calling us first.