Monad’s “Flexible and Upgradeable Account Authentication” draft, posted on August 21 by Kushal Babel and Jan Camenisch, would allow wallet accounts to add, rotate or retire authenticators whi
Monad’s “Flexible and Upgradeable Account Authentication” draft, posted on August 21 by Kushal Babel and Jan Camenisch, would allow wallet accounts to add, rotate or retire authenticators while retaining a fixed 20-byte account address. By separating the address from the credentials controlling it, the proposal could allow access recovery after a key is lost or compromised, or a move to a different signature scheme, without moving assets to a newly created wallet. The design remains a draft and does not yet include a detailed implementation specification.
Under the draft, an account’s address would remain fixed at 20 bytes rather than being tied permanently to one authentication setup. The associated authentication configuration could change over time, allowing an account to retain its existing address while changing the authenticators authorised to control it.
The authors identify recovery from lost or compromised keys and in-place migration to new signature schemes as intended uses. In each case, the authentication configuration, not the fixed address, would be updated.
The draft is broader than a one-for-one replacement of a conventional wallet key. It supports multiple authenticators and threshold policies, allowing an account’s authentication configuration to accommodate more than one approved credential or a rule requiring a threshold of approvals.
Rather than limiting changes to a single signature type, the proposal names secp256k1, P-256, WebAuthn passkeys, Ed25519, ML-DSA post-quantum signatures and ZK-OAuth verification—options that span authentication arrangements from passkeys to multisignature-style threshold controls.
CoinDesk reported on August 25 that the proposal could enable key recovery, passkeys, multisignature controls and post-quantum upgrades without moving assets or changing wallet addresses. That description follows from the draft’s central separation of address and authentication configuration, though the eventual user experience and technical implementation have not been set out in detail.
For account holders, the relevant distinction is between an address used to identify the account and the set of methods permitted to authorise it. Monad’s draft proposes to make the latter adaptable while preserving the former.
Changes would be processed through a proposed AuthConfigManager precompile. The draft says a new authentication configuration must include proof of possession before it can be accepted, a requirement intended to establish control of the authenticators being added.
Approved changes would not take effect immediately. They would activate after Monad’s current three-block execution delay, according to the proposal.
The proposed account-change process includes the delay and the proof-of-possession requirement. But the forum post does not provide, in the material published with the draft, a detailed implementation specification for how the design would be deployed.
The proposal is still at an early stage. CoinDesk noted that it lacks a detailed implementation specification, leaving open how the proposed architecture, supported authenticators and account-change flow would ultimately be implemented.
What Monad has put forward is therefore an account-authentication design rather than a completed product rollout: a fixed 20-byte address paired with a mutable configuration capable of accommodating recovery, new authentication methods and threshold arrangements. Whether and how that model reaches implementation remains unresolved in the current draft.
Disclaimer: This article is provided for informational purposes only. It is not offered or intended to be used as legal, tax, investment, financial, or other advice.
