Molt Wallet

Molt is a smart wallet that retires its signing key after every transaction.

[Molt Wallet @useMolt]

We are opening up Molt today: a smart wallet in which every key signs exactly once.

It is worth starting from first principles, because the problem is subtle. An ethereum address is not a public key; it is a hash of one. So an address that has never signed is protected by keccak, and an address that has signed is protected by the elliptic curve discrete log problem. These are very different assumptions. The first is about as conservative as cryptographic assumptions get. The second is the one that quantum computers are known to break, and the one where AI-accelerated mathematics could plausibly find a "naive factoring -> GNFS" style improvement that we simply have not been smart enough to find ourselves.

Today, the act of using a wallet silently moves it from the first category to the second, permanently. Your first transaction publishes your public key, and every transaction after that is signed by a key whose public half has been sitting on chain for years.

The useful way to think about this is not "will ECDSA break" but "for how long is each key exposed while it still has authority". We cannot know when (or if) the curve falls. What we can control is the exposure window. For a normal wallet, that window is the lifetime of the wallet: often years, ie. ~10^8 seconds. The question Molt asks is how close to zero you can push it.
The construction: Molt is an ERC-4337 account where every operation commits to the address of the next signer, and validation atomically retires the key that signed it. The address never changes; the authority behind it moves forward one key per transaction. Note what this means. At any moment, the only key with authority is one whose public key has never been seen - it exists on chain only as a hash commitment. So the live key is protected by keccak, and ECDLP only ever protects keys that have already been retired. A retired key, once recovered, is a correct answer to a question that no longer matters.

The exposure window collapses from the lifetime of the wallet to the time between broadcast and inclusion: a few seconds. That is roughly seven orders of magnitude.

Multisig is where the construction is cleanest. In a Molt shared wallet, approvals are gathered offchain and verified independently on each signer's device, and every approving signer rotates within the same transaction that executes. The signatures that eventually become public belong, by the time anyone can read them, to keys that have already lost their authority. Instead of "gracefully degrading" if ECDSA falls, the multisig simply does not degrade.

Two consequences we accept deliberately. Molt does not sign offchain messages (ie. no ERC-1271), because a signature that does not rotate the key is an exposure with no corresponding retirement. And every key derives deterministically from a single seed, so one recovery phrase reconstructs the entire key history - rotation without migration.

What this does not solve, stated plainly: during those few seconds, the key is still an ECDSA key. An adversary who can break secp256k1 in less time than a block takes defeats this design too. Molt does not make ECDSA safe; it makes the time ECDSA must stay unbroken short, and conservative assumptions have far more hope of holding over seconds than over years.

The deeper point is that this account model is already a one-time signature scheme in structure: each key authorizes exactly one message, then is gone. That is precisely the shape of hash-based signatures like WOTS. So the natural next step is to place a hash-based verifier inside the same rotation logic, at which point authorization rests on hash functions alone and the remaining window closes too. Hash-based > everything else, in the situations where hash-based is possible at all, and authorizing your own wallet is one of them.

Concrete TLDR:

An unused address is protected by a hash; a used one by ECDLP. Wallets today move you from the first to the second without asking

In Molt, the only key with authority is always one whose public key has never been seen
Exposure goes from the lifetime of the wallet to the time between broadcast and inclusion: ~10^8 seconds to ~10

Shared wallets: offchain approvals, and every approver rotates in the executing transaction
Not post-quantum yet; hash-based signatures slot into the same structure next

Live on Ethereum Sepolia and Base Sepolia, same address on both. No mainnet funds until the contracts have an independent audit and published source.

https://t.co/23ttXuUhNE
$MOLT: 0x17e9de0b92099691f013239cb20beebe2c453394

[Molt Wallet @useMolt]

Existing Molt wallets can now move onto hash-based keys in place.

The original promise of Molt was "your address never changes, only the key behind it does." It turns out that promise extends further than we first used it: not just to which key, but to what kind of key.

An ECDSA Molt wallet signs one final ECDSA transaction. That transaction retires the key that signed it, as every Molt transaction does, and in the same step switches the wallet's verification to WOTS one-time signatures over keccak256, committing to its first hash-based key. The key numbering simply continues. From the next transaction on, nothing about the wallet depends on elliptic curves.

The address doesn't change. Balances, tokens, approvals and history don't move. There's no migration, which matters, because migrations are where people actually lose funds.

Try it at https://t.co/23ttXuUhNE: Your wallet → Upgrade this wallet. Then try to drain it with a retired key.

Next: hardening ahead of an external audit.

[Molt Wallet @useMolt]

A short update on the token side, and then back to the actual work.

The principle we're trying to follow with $MOLT is simple: wherever possible, replace a promise with something you can check. So, concretely:

The dev allocation is gone. All 25,321,292 MOLT bought at launch (2.5% of supply) was sent to the burn address. The dev wallet holds zero.

Tx: https://t.co/pTvxPfBhJt

Every contract is verified. The token and its launch contract on mainnet, and all seven Molt wallet contracts on Ethereum Sepolia and Base Sepolia, have source published on Etherscan and Basescan with exact bytecode matches. You can read for yourself that the token has no owner and no mint function, and that the liquidity position has no removal path.

Token info is submitted to Etherscan (logo, links, description) and is in their review queue.

Next up we've got:

Moving existing wallets onto hash-based keys in place. Molt accounts were designed to be upgradeable only through their own rotating signature. So an existing ECDSA wallet can sign one final ECDSA transaction that upgrades it to WOTS verification and commits to its first hash-based key. Same address, same balances, same history; from the next transaction on, nothing about it depends on elliptic curves. That is the "no migration" property from the original design, now applied to the signature scheme itself.

Hardening ahead of an external audit: property-based tests of the invariants that matter (a retired key can never act again; no key index is ever reused), an internal review pass, and a public security page with scope and a disclosure contact.

[Molt Wallet @useMolt]

Hash-based signatures are live on Molt testnet.

There is now a second kind of Molt wallet, authorized by Winternitz one-time signatures over keccak256 instead of ECDSA. Each key is 67 hash chains. A signature reveals one point partway along each chain, and the contract verifies it by walking every chain to its end and checking that the ends hash to the key the wallet committed to. There is no curve anywhere in that process, and so no structure for a quantum computer, or a sufficiently good AI, to exploit. The security of the key reduces to a single question: can you invert keccak256?

It fits Molt unusually well. A WOTS key can safely sign exactly one message: sign twice and you leak enough to forge. Molt already never lets a key sign twice; every key is retired by the very transaction it signs. So the rotation model didn't change at all. What changed is what the key is made of.

Try it at https://t.co/23ttXuUPDc: Your wallet → Signatures → Hash-based. Same seed phrase, separate wallet. Send twice, then try to drain it with a retired key.

Next: verified contracts and an audit, then moving existing wallets onto hash-based keys in place

[Molt Wallet @useMolt]

Now that Molt is live, it's worth being precise about what is left to do, because the roadmap falls out of one simple equation.

The risk to any signing key is roughly: (how long its public key is visible while it still has authority) × (the probability that an adversary can recover the private key within that time). Every wallet today makes the first term enormous: your public key goes on chain with your first transaction and stays there, with full authority, for as long as you use the wallet. Usually years.

Molt v1 attacks the first term. Each key signs exactly once and is retired by the very transaction it signs, so the window shrinks from years to the gap between broadcast and inclusion: a few seconds. The live key is never an elliptic curve point anyone has seen; it exists on chain only as a hash commitment.

What remains is making each term go to zero, and then making the whole thing verifiable and usable. In order:

1. Make the second term zero: hash-based signatures. Molt's account is already structured as a one-time signature scheme: one key, one message, then retirement. That is precisely the shape of WOTS, where a key is a set of hash chains that is only secure for a single use. So instead of committing to the next ECDSA address, the account commits to the hash of the next WOTS public key, and validation checks a hash-based signature instead. At that point authorization rests on the preimage resistance of a hash function and nothing else: no curves, no lattices, no structure for a quantum computer or a very good AI to exploit. The cost is larger signatures and more verification gas. On a rollup that is a few cents, and we think it is clearly the right trade. This ships to testnet first.

2. Shrink the first term toward zero: private submission. Even with ECDSA, the remaining exposure is the time a signed operation sits in a public mempool. Routing operations privately to builders means the signature is first seen by the public in the same block that retires its key. This does not remove trust so much as move it (to whoever sees the operation privately), and we'll be explicit about that tradeoff.

3. Make the trust assumption checkable: verified source, then an audit. A wallet whose security argument cannot be read is asking for faith. The contracts get published and verified, followed by an independent review before any mainnet funds.

4. Make it usable: WalletConnect. With one deliberate constraint carried over from v1: Molt will not produce offchain signatures (ERC-1271, permits), because a signature that does not rotate the key is exposure without retirement. So apps will work through transactions, which is slightly less convenient and strictly safer.

Concrete TLDR:

v1: key exposure goes from years to seconds
Next: hash-based signatures, so the exposed keys aren't breakable at all
Then: private submission, so the seconds become nearly zero
Verified source and an audit before mainnet; no shortcuts on this one
WalletConnect, without offchain signatures, on purpose

https://t.co/23ttXuUhNE