Winternitz

Self custody for the post quantum era.
Ca: 0x92bffc0ca8d18ed0971dc94957c15e05e6e6f223

[Winternitz @winternitzk]

Introducing a new approach to self custodial wallets, built with post quantum hash based signatures.

One account. Fresh signing keys. A longer view on security.

We're excited to share our first product demo, showcasing Winternitz in action.

Experience it yourself: https://t.co/WvCLsVXsJC

Watch the demo below ↓

[Winternitz @winternitzk]

Winternitz development update: strengthening recovery for our WOTS based quantum resistant wallet.

The current development build supports encrypted backups containing account configuration and known signing history. Restore verifies identities and signatures, rejects known conflicts, and preserves newer local records.

Restored wallets remain read only because a valid backup cannot prove that its history is complete.

With 14 recovery tests passing, the next milestone is rollback safe signing reactivation across devices.

[Winternitz @winternitzk]

Yes, absolutely. Some of the information currently on our website may change as the product continues to evolve.

We believe that building a better product means being open to feedback, acknowledging gaps, and improving where necessary. That's exactly why conversations like this matter.

We'll also update the FAQ to make sure the wording accurately reflects how the recovery process works.

Really appreciate you taking the time to point this out. Feedback like yours genuinely helps us build something better.

[Winternitz @winternitzk]

Today, we don’t yet have a fully supported, rollback safe recovery path if the only signing device is lost. Your recovery phrase and original account configuration can restore the account identity for viewing, but new imports remain read only because the phrase cannot reconstruct the complete signing history. The existing recovery key mechanism handles stuck transactions, not lost device recovery.

Our planned direction combines encrypted backups of account configuration and signing journals with a recovery protocol that retires the old signing authority before activating fresh keys. Backups alone can still be stale, so that protocol must account for pending transactions, an old device coming back online, competing recovery attempts, and chain reorganizations. The goal is to restore transaction capability without reusing exposed WOTS keys. This requires further design, testing, and independent review before release.

[🔸 @Oz3hyra]

@winternitzk that’s a really honest answer, appreciate it. two quick ones: if I lose my device, is there a way to regain signing today or is that part of the unresolved recovery piece?

[Winternitz @winternitzk]

The GitHub repository will be public tomorrow so developers can inspect the implementation, including key rotation, and build with it.

If two devices share the same seed, they could sign different operations with the same WOTS key before either sees the onchain rotation. Nonce checks may reject the competing operation, but they cannot undo the key exposure from producing two different signatures. Our local journal and locks help within shared storage, they do not coordinate independent devices. Today, we require one active signing interface per seed, and new phrase imports open read only. Safe cross device signing and rollback resistant recovery remain unresolved requirements.

[Winternitz @winternitzk]

For a WOTS wallet, security goes beyond the signature: key rotation, recovery, and reorg handling must prevent key reuse. This is the direction we want for Winternitz: formal models and explicit invariants. Our current tests are evidence, not formal proofs.

[Francesco @fradamt]

AI is making Ethereum more ambitious.

You might have heard about the challenges that blockchains face in a post-AI world, and while security assumptions will surely be stress-tested in the coming months and years, there is another side to it. I believe AI will let us speedrun towards a world that's both more secure and feature-rich.

As we look towards Ethereum's first post-AI upgrade, Hegotá, the R&D community is asking itself what increasingly powerful tools could help us do differently:

> How far can we push both security and iteration speed?
> How much of the design space can we examine before committing to one?
> How easily can we test the interactions between complex features?

My recent formal verification work @ethlabs_org has given me some reasons to be optimistic about these, as work that would have previously not even been attempted is now being done by agents in days. In September, I posted about using formal verification as part of designing a new consensus protocol. This time, I want to tell you about formally verifying something already fully specified and in production: Ethereum's Fast Confirmation Rule (FCR).

If you are not familiar with FCR, it lets applications confirm Ethereum blocks in seconds, roughly 30x faster than waiting for finality, under additional assumptions (from waiting 13 minutes to 24 seconds!). It also further solidifies Ethereum L1's case as an asset hub and center of gravity for the onchain economy. FCR now has a safety proof in Lean, closely modeling the rule in the consensus specs, which is the source of truth for Ethereum's consensus clients.

Some takeaways:

> FCR is safe! Under its assumptions, confirmed blocks remain canonical. On top of the manual proofs from the paper, we now have Lean proofs of this for the actual spec, additional evidence for applications considering FCR!

> The bulk of the formal verification work took just a 4-5 days (check out the animation!), with agents working mostly unsupervised. We should be very ambitious about using this as a tool at scale.

> After verifying the current rule, it was easy to adapt the model to the upcoming Gloas changes. Immediately, this surfaced a subtle bug caused by changes to fork choice. The problem was in the spec itself and not a gap in the model. The safety proof would not go through, and the agents could precisely pinpoint what was causing it to fail. The bug is now fixed, and formal verification of the corrected protocol goes through.

Iteration is never quite over, even for "finished" features like FCR, because the protocol keeps evolving around them. A formal model lets us ensure that key properties keep holding throughout the evolution of the protocol. With these capabilities, Ethereum can and should keep upgrading faster, tightening fork timelines and exploring more ambitious features, while still raising the security bar.

This picture has been getting much clearer over the past few months, and the past week confirmed it for me, as @drakefjustin and @corcoranwill brought together 100+ Ethereum researchers, cryptographers and formal verification experts in Cambridge for six days of workshops on post-quantum cryptography, formal verification and fast finality. Beyond its own workshop, formal verification was the omnipresent star of the week: everyone is using Lean and doing amazing things with it! Piece by piece, Ethereum's technological core is being rebuilt for the post-AI age.

The excitement was palpable, the sense of optimism was pervasive, and every talk and conversation carried a level of ambition I'd never seen before. The Ethereum R&D machine is upgrading itself, and we will see the outcome of that on the network sooner than you think.

[Winternitz @winternitzk]

For a WOTS wallet, security goes beyond the signature: key rotation, recovery, and reorg handling must prevent key reuse. This is the direction we want for Winternitz: formal models and explicit invariants.

[Francesco @fradamt]

AI is making Ethereum more ambitious.

You might have heard about the challenges that blockchains face in a post-AI world, and while security assumptions will surely be stress-tested in the coming months and years, there is another side to it. I believe AI will let us speedrun towards a world that's both more secure and feature-rich.

As we look towards Ethereum's first post-AI upgrade, Hegotá, the R&D community is asking itself what increasingly powerful tools could help us do differently:

> How far can we push both security and iteration speed?
> How much of the design space can we examine before committing to one?
> How easily can we test the interactions between complex features?

My recent formal verification work @ethlabs_org has given me some reasons to be optimistic about these, as work that would have previously not even been attempted is now being done by agents in days. In September, I posted about using formal verification as part of designing a new consensus protocol. This time, I want to tell you about formally verifying something already fully specified and in production: Ethereum's Fast Confirmation Rule (FCR).

If you are not familiar with FCR, it lets applications confirm Ethereum blocks in seconds, roughly 30x faster than waiting for finality, under additional assumptions (from waiting 13 minutes to 24 seconds!). It also further solidifies Ethereum L1's case as an asset hub and center of gravity for the onchain economy. FCR now has a safety proof in Lean, closely modeling the rule in the consensus specs, which is the source of truth for Ethereum's consensus clients.

Some takeaways:

> FCR is safe! Under its assumptions, confirmed blocks remain canonical. On top of the manual proofs from the paper, we now have Lean proofs of this for the actual spec, additional evidence for applications considering FCR!

> The bulk of the formal verification work took just a 4-5 days (check out the animation!), with agents working mostly unsupervised. We should be very ambitious about using this as a tool at scale.

> After verifying the current rule, it was easy to adapt the model to the upcoming Gloas changes. Immediately, this surfaced a subtle bug caused by changes to fork choice. The problem was in the spec itself and not a gap in the model. The safety proof would not go through, and the agents could precisely pinpoint what was causing it to fail. The bug is now fixed, and formal verification of the corrected protocol goes through.

Iteration is never quite over, even for "finished" features like FCR, because the protocol keeps evolving around them. A formal model lets us ensure that key properties keep holding throughout the evolution of the protocol. With these capabilities, Ethereum can and should keep upgrading faster, tightening fork timelines and exploring more ambitious features, while still raising the security bar.

This picture has been getting much clearer over the past few months, and the past week confirmed it for me, as @drakefjustin and @corcoranwill brought together 100+ Ethereum researchers, cryptographers and formal verification experts in Cambridge for six days of workshops on post-quantum cryptography, formal verification and fast finality. Beyond its own workshop, formal verification was the omnipresent star of the week: everyone is using Lean and doing amazing things with it! Piece by piece, Ethereum's technological core is being rebuilt for the post-AI age.

The excitement was palpable, the sense of optimism was pervasive, and every talk and conversation carried a level of ambition I'd never seen before. The Ethereum R&D machine is upgrading itself, and we will see the outcome of that on the network sooner than you think.

[Winternitz @winternitzk]

Understanding Post Quantum Wallets in 60 Seconds.

One wallet address. A fresh signing key for every transaction.

Winternitz uses hash-based one-time signatures (WOTS) to introduce a different approach to wallet security.

1. One address, always yours.
2. Every validated operation retires its signing key.
3. A fresh key takes its place automatically.
4. Built for quantum resistant account authorisation.

Same address. New keys. A post quantum future.
Explore Winternitz: https://t.co/IhL4mvNUYG

[Winternitz @winternitzk]

Good morning, everyone.

A new day, a fresh agenda, and another step forward for Winternitz.

Today, we're sharing our latest development update, highlighting the progress we've made across wallet infrastructure, security, privacy, and the overall user experience.

Winternitz Development Update

1. Post Quantum Wallet Infrastructure
Implemented WOTS based wallet authorisation using hash based, one time signatures.
Deployed account factory and implementation contracts on Robinhood mainnet and testnet.
Successfully verified testnet contract source code on the explorer.

2. Web Wallet & Chrome Extension
Developed interfaces for account management, balances, transaction history, and transfers.
Introduced local signing journals and locking mechanisms to help prevent one time key reuse within the same storage environment.
Added read only wallet imports to reduce signing risks associated with outdated recovery states.
Strengthened transaction approval validation against unexpected account, network, or connection changes.

3. Security & Recovery Improvements
Improved automatic session locking and local storage protection.
Ensured background balance updates do not extend active sessions.
Preserved signing history during wallet resets to maintain key-use safeguards.

4. Privacy Lab Testnet Progress
Successfully tested Shield and Unshield ETH operations with confirmed transactions.
Implemented local proof generation and note-state verification.
Introduced password-protected, encrypted note backups with import and recovery support.

5. Transaction Safety & User Experience
Added gas estimation, transaction review, and maximum fee controls.
Refined the landing page, wallet dashboard, extension interface, and technical documentation.

6. Testing & Technical Validation

Our latest validation cycle delivered:
52 SDK tests passed.
49 extension tests passed.
22 Privacy Lab tests passed.
42 smart contract tests passed.
Production builds completed successfully.

What's Next?

Development continues with a focus on:

Strengthening rollback resistant recovery across multiple devices.
Expanding compatibility testing with users' wallet extensions.
Preparing for independent security audits.
Continuing research into post-quantum privacy infrastructure.

A new day means new responsibilities, new milestones, and continued progress.

Our priority remains unchanged: building secure, transparent, and practical wallet infrastructure designed with the post-quantum future in mind.

We're still in Alpha, and there's more work ahead.

Thank you to everyone following our progress and supporting the development of Winternitz.

Built with purpose. Secured for the future.

https://t.co/WvCLsVXsJC

#Winternitz #PostQuantum #Web3 #BuildInPublic

[Winternitz @winternitzk]

That’s a valid concern, and it directly relates to our quantum resistant wallet design WOTS security depends on never signing different messages with the same one time key. Our current implementation checks onchain key state and retained local signing history, but does not fully prevent a stale backup from missing an unconfirmed signature.

We plan to address this through rollback resistant exposure tracking or a recovery protocol that safely replaces signing authority before allowing new transactions.

These mechanisms still require implementation, testing, and independent review. A recovery phrase, local journal, and onchain checks alone are not sufficient to claim rollback safe recovery.

[Winternitz @winternitzk]

Winternitz is building a quantum resistant wallet using hash based Winternitz one time signatures (WOTS) for account authorization.

Following our internal security review, we’ve strengthened key reuse protection, transaction approvals, session locking, and recovery safeguards.

Our next planned step is an independent external security audit of the wallet and smart contracts, while the extension progresses through the Chrome Web Store submission process.

We’re working toward quantum resistant wallet security through tested implementation, transparent findings, and independent verification.

[Winternitz @winternitzk]

Winternitz uses hash based Winternitz one time signatures (WOTS) for account authorization designed to resist quantum attacks.

Following our internal security review, we’ve locally validated safeguards against conflicting signatures across retained network journals, approvals bound to the reviewed account and network, stricter session locking, and signing history retention during wallet resets. Validation includes 141 application tests, 42 contract tests, and 64 differential fuzz cases, with a successful production build.

We’re building confidence through reproducible checks and transparent limitations, without claiming that passing tests alone makes a wallet safe for production funds.

[Winternitz @winternitzk]

Refining dashboard and strengthening wallet security with encrypted key storage, automatic locking, vault validation, and clearer backup and recovery flows.
Native Zcash privacy integration is progressing on testnet, with the next focus on NU7 compatibility before enabling shielded transaction signing and sending.

[Winternitz @winternitzk]

@funkai_ We're currently in the testnet phase and actively developing the platform. We're also working on the browser extension and mobile versions today. We'll be sharing more updates on our progress and upcoming features in the next few hours.

[Winternitz @winternitzk]

Winternitz is bringing native Zcash support into Privacy Lab, combining local key derivation, client side note scanning, and encrypted wallet backups in a dedicated testnet workflow.

Account creation, backup recovery, and empty account synchronization have passed live browser testing. The transaction pipeline is designed to review unsigned proposals, generate signatures and proofs locally, and persist encrypted transaction state before broadcast so retries reuse the same signed transaction.

Our next milestone is NU7 compatible shielding and payments; consensus checks currently block signing and submission until the SDK supports the active network rules.

The direction is clear: give users control over both transaction authorization and financial privacy, while keeping Zcash keys separate from our WOTS based Ethereum accounts.

[Winternitz @winternitzk]

Zcash highlights how shielded transactions give users more control over their financial information. Building on that principle, Winternitz Privacy Lab now includes a native Zcash testnet wallet with account creation, receiving addresses, encrypted backups, recovery, and live synchronization.

These flows have been tested with an empty account, using separate Zcash keys alongside our WOTS based Ethereum smart accounts.

Shielding and payments remain disabled while we migrate the browser SDK to support testnet’s active NU7 consensus rules. Read Zcash’s explanation of shielded and transparent addresses.

https://t.co/wyJ1ZZunSB

[Winternitz @winternitzk]

Winternitz wallet contracts are now deployed on Robinhood Chain mainnet, laying the foundation for smart accounts powered by Winternitz onetime signatures a signature scheme designed to resist quantum attacks.

The factory creates each user’s account, while the account implementation verifies signatures, executes transactions, and rotates onetime signing keys. Next comes mainnet bundler integration, end to end transaction validation, and explorer source verification. View the contracts

https://t.co/XuA45J8OVc

https://t.co/UUtsEmgufy

https://t.co/tPV8lG3whu

[Winternitz @winternitzk]

One address. A fresh signing key for every operation.
We’ve added local signing locks to the web wallet, extension, and CLI, plus deployment checks for our mainnet path. Next: validating the flow with production infrastructure.

[Winternitz @winternitzk]

Winternitz | DEX Update
Another step forward for Winternitz.

Our DEX listing request has been successfully

More updates soon.
The future is post quantum.