Making Monad quantum-resistant through upgradeable account authentication
Monad Foundation
@monad- Published on
- · 2 min read
A new proposal maps out how to make Monad quantum-resistant while minimizing disruption to DeFi, integrations, and existing address books. It allows users to change their account's signature scheme while keeping their public address.
The Flexible and Upgradeable Account Authentication proposal, by Kushal Babel and Jan Camenisch, introduces account settings for keys, signature schemes, and authorization rules. Users could update these settings over the account's lifetime.
Today, a standard externally owned account derives its address from a public key and relies on the corresponding private key to authorize transactions. Under the proposal, the protocol would read the account's current authentication settings to check a transaction. Users could replace keys, add passkeys, or require multiple signatures through an authorized configuration change.
Each account would have two policies:
- A signing policy would specify which signatures are required for transactions.
- A reconfiguration policy would specify which signatures are required to change keys or policies.
A user could use a passkey for daily transactions and let two recovery guardians jointly approve a replacement key. The user would need to configure that recovery policy before losing access. Changes would require authorization under the current reconfiguration policy and proof of possession of the new keys.
To move to post-quantum authentication, a user would add an authenticator under a supported quantum-resistant scheme and retire the old one. The draft includes ML-DSA among the proposed schemes.
Authentication checks would run before EVM execution and use only the sender's account data. This fits Monad's parallel execution model by avoiding dependencies on shared application state during authentication. The protocol would supply the supported verification algorithms; additional schemes could be added through protocol upgrades.
Addresses would retain their current 20-byte format. Existing accounts could continue to operate as they do today, and users could start an upgrade through an ordinary transaction. Wallets would need support for the new authentication methods and transaction format.
The proposal is a draft, with the detailed implementation specification still to come. The authors welcome feedback from wallet developers, application developers, researchers, and users in the forum discussion.