Monad has put forward a draft design that would let wallet users add, rotate, or retire their login keys without ever changing their 20-byte account address. The proposal, dated August 21 and written by Kushal Babel and Jan Camenisch, is called “Flexible and Upgradeable Account Authentication.” It's still early — the document has no detailed implementation spec — but it attacks a core pain point: losing a key too often means losing the account.
Separating the address from the key
The basic idea is to break the link between an account's address and the keys that control it. Right now, most crypto addresses are derived from a private key. Lose that key and you lose access, or you're forced to move assets to a brand-new address and update everyone you transact with. Monad's draft flips that. The address stays fixed while the authenticators — the things that prove you own it — can be swapped out.
That separation opens the door to key recovery. If a key is lost or compromised, a user can rotate in a new one without moving funds. It also means the account can migrate to a different signature scheme later on, even one that doesn't exist yet. No asset transfer, no address change, no re-notifying counterparties.
What the proposal supports
The draft isn't limited to the standard secp256k1 curve. It covers a wide range of authenticators: P-256, WebAuthn passkeys, Ed25519, ML-DSA post-quantum signatures, and ZK-OAuth. Users could rely on multiple authenticators at once, or set threshold policies where more than one is required to approve a transaction.
So a user could pair a hardware key with a passkey, or require two-of-three across different devices. The design also allows retiring an old authenticator once it's no longer needed, which keeps the account clean over time.
How changes get processed
All of this runs through a proposed precompile called AuthConfigManager. To add or retire an authenticator, the user sends a request to that contract. The precompile checks proof of possession — that you actually control the current authenticator — and then imposes a three-block activation delay before the change takes effect.
That delay is the safety valve. It gives the user a short window to notice if an unauthorized change has been submitted. It's not a panic button, but it's a buffer against a key being swapped out by someone else.
Early stage, open questions
This is a draft, and a rough one at that. There's no detailed specification for how the precompile will behave, how gas costs work, or how the activation delay will be enforced in practice. The authors call it early-stage, and the document leaves room for the design to shift before anything reaches a testnet.
The next step is community review. Monad hasn't announced a timeline for implementation or a rollout. Whether this draft becomes a working feature, and whether it finds adoption beyond Monad, will come down to feedback from developers and users.
