Monad Proposes Flexible, Upgradeable Account Authentication

Monad Proposes Flexible, Upgradeable Account Authentication

Overview

August 25, 2026.

A Monad protocol discussion is proposing a fundamental change to the relationship between an account and the key that controls it: keep the address fixed, but make its authentication replaceable.

Context

Under the draft, an account would hold an AuthConfig in state. That configuration could include several authenticators and separate policies for signing transactions and changing the configuration itself. A user could replace a lost key, add a passkey, require guardian approval, or adopt a future post-quantum scheme without sending assets to a new account. The address would remain 20 bytes and would not change after creation.

That sounds like account abstraction, but the proposal is deliberately narrower. It is an authentication architecture for protocol accounts, not a complete smart-wallet product. That distinction is where both its value and its unresolved work become clear.

Draft status: the forum proposal is a design and architecture draft. Concrete implementation details, gas schedules, RPC interfaces, and final compatibility rules remain subject to change.

The Address Stops Being the Key

Operational Impact

For a conventional externally owned account, the address is derived from one secp256k1 public key. Control of the account and identity of the account are therefore tied together. Lose the key and control is lost. Suspect compromise and the safest response is usually to create another address and move everything.

That migration is more disruptive than transferring a token balance. An address can accumulate transaction history, approvals, allowlist status, protocol positions, reputation, payment relationships, and human recognition. Moving assets does not automatically move those dependencies.

Operator Actions

The Monad proposal separates those concepts. The address becomes the durable account identity. Authentication becomes mutable account state. Rotating an authenticator changes who can authorize the account, not which account it is.

For new accounts, the draft derives the fixed address from the genesis authentication configuration. Later changes do not alter it. Existing accounts without an AuthConfig continue to behave as ordinary secp256k1 accounts and can opt in through an AuthConfigManager precompile.

What an AuthConfig Contains

Risk Watch

The draft configuration includes a version, authenticator identifiers, the authenticators themselves, a signing policy, and a separate reconfiguration policy. Its initial scheme roster lists:

• secp256k1 ECDSA
• P-256 ECDSA
• WebAuthn P-256 passkeys
• Ed25519
• ML-DSA post-quantum signatures
• ZK-OAuth

Policies are built from authenticator IDs and threshold expressions. That supports familiar structures such as one-of-two, two-of-three, or combinations of a daily signing key and a more protected recovery set. The signing policy authorizes ordinary transactions. The reconfiguration policy decides who may add, remove, rotate, or upgrade authenticators.

New authenticators must prove possession before activation. A configuration change also carries a version to prevent replay and takes effect after an execution delay, described in the current draft as three blocks. That delay creates a small response window instead of making a hostile change instantaneous.

The proposed model keeps the account and assets fixed while transaction signing and protected recovery follow separate policies.

Recovery Without Moving the Account

Consider a user whose normal signer is a phone passkey. Their reconfiguration policy could require two approvals from a hardware key and two independent guardians. If the phone is lost, the recovery group can add a replacement passkey and retire the old one. The account address, balances, applications, and history stay where they are.

The same mechanism supports compromise response. A suspicious key can be removed without a rushed migration across every token, position, approval, and application. An account can also upgrade its cryptography in place. The inclusion of ML-DSA is strategically important because it creates a protocol path for moving to a post-quantum authenticator without abandoning an established address.

That does not make recovery risk disappear. It changes its shape. Guardians can collude, devices can be lost together, and users can accidentally create a policy they cannot satisfy. Recovery safety depends as much on product design and education as it does on the threshold expression enforced by the protocol.

Product Review: High Leverage, Not Yet Product-Complete

From a product perspective, this is one of the more consequential account proposals Monad could adopt. It improves security without asking users to understand a new address every time their setup changes. A wallet could start with a passkey, offer a hardware key for high-value actions, add trusted recovery factors, and later improve the scheme without breaking the user's identity.

Stable addresses also reduce ecosystem coordination costs. Exchanges, payroll systems, allowlists, subscriptions, games, and social products can continue recognizing the same account after a security upgrade. Protocol-enforced policies give wallets a common base instead of forcing every product to invent a different smart-account recovery system.

The strongest product opportunity is a simple default with visible recovery health. A wallet should be able to say whether recovery is configured, whether the factors are independent, when they were last tested, and whether a pending change is waiting through its delay. Advanced threshold controls can exist, but users should not need to design Boolean policy trees to stay safe.

The proposal is not product-complete yet. It needs a standard read interface, predictable events, simulation behavior, hardware-wallet support, explorer visibility, and clear failure messages. The forum discussion has already raised the need for methods such as eth_getAuthConfig, reliable config_version exposure, and a safe way for simulation and tracing tools to handle authorization. Those details determine whether wallets can make the feature understandable.

User Review: A Better Failure Model With New Responsibilities

For users, the largest benefit is straightforward: a lost key no longer has to mean a lost account. A compromised signer can be removed, a passkey can replace a seed phrase for routine use, and stronger authentication can be introduced as an account becomes more valuable.

The less obvious benefit is continuity. Users do not need to rebuild their on-chain identity after recovery. That matters to people who hold more than transferable tokens: liquidity positions, attestations, governance history, game assets, reputation, or access tied to a specific address.

There are important boundaries. Protocol transaction authentication is not the same as every signature an application may accept. Contracts using ecrecover, Permit2-style approvals, or other off-chain signatures will not automatically understand a new AuthConfig. Retiring a transaction signer may therefore not invalidate every old application authorization. Wallets must show this difference clearly and help users revoke relevant permits.

EIP-7702 also needs careful treatment. The proposal notes that delegations already installed on an account remain until the account re-delegates or undelegates under its new policy. Rotating a compromised key is not, by itself, a cleanup of previously delegated account code.

Cross-chain use introduces another product risk. The same visible address could have different authentication configurations on different chains unless wallets coordinate rotations everywhere. An account recovered on Monad might still be vulnerable elsewhere. A good wallet will need to present authentication state per chain rather than imply that one rotation automatically protects every deployment of that address.

Compatibility Is More Nuanced Than 'Existing Accounts Are Unaffected'

The backwards-compatibility story is strong, but it has conditions. An existing account with no configuration remains a standard EOA. Once it opts in, a legacy transaction is valid only when its recovered ECDSA key alone satisfies the effective signing policy. A threshold policy can therefore require the proposal's new transaction format and compatible signing software.

That new transaction type carries an explicit sender, authentication data, and an optional initial configuration. It touches the mempool, account state, consensus verification, execution, RPC tooling, indexers, wallets, and hardware signers. This is a protocol-level feature with an ecosystem-sized integration surface.

The draft also proposes an on-chain key-to-address index for discoverability. That can make account lookup easier, but it adds state, requires stale entries to be removed correctly, and creates privacy questions by making relationships between credentials and accounts easier to query. Several forum participants argue that some discovery should remain in wallets or indexers instead.

How It Relates to Ethereum Account Abstraction

EIP-7702 lets an EOA set executable code, enabling batching, sponsorship, and more flexible account behavior. It does not by itself separate the account from the authority of its underlying key. The Monad draft targets that specific identity and authentication coupling.

EIP-8130 and EIP-8141 explore broader native account-abstraction models, including configurable validation and transaction frames. The Monad discussion needs to resolve whether its narrower design complements those standards or creates avoidable divergence for wallets and tooling. Interoperability is a product concern, not only a standards concern.

What the Draft Deliberately Does Not Solve

The native policy language is intentionally minimal. It supports authenticator and threshold logic, but stateful spending limits, automatic expiry, time-to-live controls, and arbitrary user-defined verifiers are outside the current scope. Those richer controls would still need application or contract support, or future protocol work.

Post-quantum support is also a direction rather than a finished deployment guarantee. ML-DSA is listed as an initial authenticator type, but verification cost, transaction size, gas pricing, hardware support, and the governance process for adding or updating schemes need a concrete specification. The protocol roster makes verification predictable, but adding new algorithms would require network coordination.

BitCtrl View

BitCtrl supported the direction in the forum because the user and product value is real. Self-custody should not force a permanent choice between one fragile key and a complete migration to a new identity. Separating identity from authentication gives Monad a stronger foundation for passkeys, recovery, multi-factor approval, and cryptographic upgrades.

Our more detailed view is that adoption should be measured by safe recoverability, not feature count. The proposal succeeds only if ordinary users can understand their current policy, test recovery before an emergency, recognize pending changes, and see which permissions survive a key rotation.

The protocol can enforce a policy. The product still has to make that policy safe to live with.

What To Watch Next

• the concrete transaction, gas, and state specification
• standard RPC reads, events, simulation, and trace behavior
• wallet, hardware signer, explorer, and indexer adoption
• treatment of Permit2, ecrecover, and other application-level signatures
• EIP-7702 delegation cleanup during key compromise
• cross-chain authentication configuration and recovery UX
• privacy and state costs of the proposed key-to-address index
• interoperability with EIP-8130 and EIP-8141

Bottom Line

The proposal replaces a brittle assumption at the center of self-custody: that one address must remain bound to one key forever.

If Monad can preserve compatibility while wallets make configuration and recovery genuinely understandable, fixed-address authentication could materially improve both account safety and product usability. It gives users a better answer to lost keys, compromised devices, stronger multi-factor policies, and future post-quantum migration.

But this is still a draft architecture. The hard part now is not proving that mutable authentication is useful. It is specifying every edge where users, wallets, applications, and chains may disagree about who controls the account.

That is the standard the proposal should be judged against.

Sources

• Flexible and Upgradeable Account Authentication proposal
• BitCtrl product and user perspective in the Monad forum
• EIP-7702: Set EOA account code
• EIP-8130: Account abstraction
• EIP-8141: Frame transactions
• Web Authentication Level 3
• NIST FIPS 204: Module-Lattice-Based Digital Signature Standard