Abstract
A post-quantum stealth address protocol is a specification one may follow to replace the vulnerable Diffie-Hellman key exchange (DHKE) with a Module-Lattice-based Key-Encapsulation Mechanism (ML-KEM). To make sure the scheme is complete, my project aimed to try different PQ signature schemes, benchmark them, and compare trade-offs for indexing, as well as to produce a formally verifiable proof alongside the specification. Correctness and completeness of the specification were covered by the unit and integration tests in Python and TypeScript.
Links
- Website: pq-sap.gwei.limo
- Updated project doc: pq-sap.md
- Project proposal: cohort-seven #269
- GitHub repo: Skanislav/pq-sap
- Blog: skas.gwei.limo
Short description
The project makes stealth address detection post-quantum by proposing a new ERC-5564 scheme ID: the announcement's ephemeral key is an ML-KEM-768 ciphertext, scanning uses a one-byte view tag, and the meta-address carries a commitment to the spending key instead of the key itself, so receive-time data hides the spending scheme entirely. Everything is built twice, in Python (the source of truth) and TypeScript, and both replay the same conformance vectors byte for byte. There are also Solidity contracts, a Lean 4 proof development, and measured gas costs. Main link: Skanislav/pq-sap.
State of the project
Status report
All five planned deliverables exist and are public: the executable Python spec, conformance vectors with negative cases, the reference library (send, scan, viewing keys, proof of possession), the cost report where every figure names its provenance, and a Lean 4 / VCVio development with no sorries and a machine-checked axiom audit. Even the stretch goal (ERC-4337 receive, scan and spend with a ZK ownership proof) got closed with real measurements — two live runs on Sepolia, one of them gasless through a paymaster (self-bundled, 8.37M gas; Pimlico-sponsored, 8.38M gas) — not with prose.
What's still open: the normative ERC text (human-written and pre-freeze by my own decision), the concrete commitment/CREATE2 privacy composition, and the fact that the only PQ verifier deployed on-chain today is a level-2 Dilithium2 profile, not the ML-DSA-65 the scheme defaults to. The full planned-vs-delivered breakdown is in the project doc.
Reflection
During this project I was able to implement the missing pieces from the existing academic research (Post-Quantum Stealth Address Protocols) by drawing on the random knowledge in my head: Kohaku's pq-account, SPHINCS⁻, frame transactions, trustless log indexing, etc. On top of that, I had the time and context to introduce myself to formal verification with Lean 4 and the VCVio library, and to get a deep dive into lattice-based cryptography and its different forms.
(Un)done
- An ERC draft for ERC-5564 with a new scheme ID. The scheme ID itself is declared and used on-chain in every test, but the normative text is deliberately human-written and pre-freeze.
Done
- Conformance vectors
- Reference library (Python, TypeScript)
- Formal verification of the specification's assumed parts, together with the VCVio games
- Benchmarks and cost reports against the elliptic-curve, hash and lattice-based commitment schemes
- The ERC-4337/ZK spend stretch goal, closed with live measurements
Pivots
- Since the beginning of the cohort I voluntarily switched to working on something far more relevant for the protocol, which turned out to be quite exciting still.
- When a third party published a very similar project on ethresear.ch along with an ERC draft, I pivoted from pushing my own scheme ID to reviewing and contributing to theirs.
Changes
When the parallel proposal emerged, I tried to collaborate where I could: providing feedback in private messages, answering on ethresear.ch, and reviewing and commenting on the ERC draft. And quite frankly, I wasn't sure how to wrap up this cohort's project.
Current usability
With all the comments and directions I contributed, ERC-8441 recently got merged, and my repository will remain as a decision and research log with a playground on Sepolia. The Ethrex devnet with frame transactions is probably not available anymore.
Current impact and future of the project
I have a strong belief that the hybrid scheme will unfortunately not be adopted by many wallets, because the improvements Hegota could bring are a much more realistic route to something interesting and usable.
To be more precise, it's clear that with EIP-8288 gas would be much cheaper and actually within reasonable prices. Key to that, there should also be keyed nonces, pre/post-tx frames, etc.
When it comes to the ecosystem, as far as I figured out, ERC-8441 will be used in the Kohaku SDK, so wallets get a universal implementation for such tools. Frame transactions are opening a whole new design space for the existing problems, which would be solved once and for all.
Potential next steps and improvements, use cases in the ecosystem
- Close the security composition. The generic KEM results (anonymity, unlinkability) are already proven in Lean; what's missing is the concrete commitment/CREATE2 privacy argument, and that's the real gate for the ERC. It's a cryptography writing and proof problem more than an engineering one.
- Feed the artifacts into ERC-8441 and Kohaku. The conformance vectors, the deployment-binding profile and the per-route spend gas table can be adopted as they are. What the project needs most now is a second pair of eyes on the commitment composition.
- Protocol-native spending. EIP-8164 native keys and EIP-8288 aggregation are the only routes where a PQ spend costs tens of thousands of gas instead of millions. Contributing test vectors, cost measurements or a reference verifier there is more leveraged than another account contract.
- Client-side scanning at scale. The scan is linear and every wallet pays it; view tags cut the constant, not the asymptotics. Verifiable log discovery (EIP-7745/8304) or sub-linear discovery would be a bigger win than shaving a few microseconds off a decapsulation.
Self-evaluation
I joined the cohort as a permissionless participant because of other full-time commitments, so frankly I didn't have the luxury to fully focus on something and make it right, and I often had to struggle with switching contexts. And even with heavy AI assistance there's not much to accelerate, because focus and deep work are the bottleneck.
What could've been different
I obviously had procrastination periods when I could've finalized the hybrid proposal, figured out that the Hegota++ design space was not yet available, and gone to work on something really cool and practical — helped with the test suites, fixed bugs, or something else. The primary reason I procrastinated is that I didn't want to post slop that nobody would read and that would just end up rotting until the PR got closed.
Usage of AI
I also had a slightly different understanding of how protocol development utilizes AI, and thought the restrictions were much higher and the quality of work expected exceptional, which is not always the case, as I saw.
Feedback about the project
This project is one of the coolest things I've ever worked on. And even though I'm trying not to take things personally, the rose-colored glasses of win-win collaboration don't seem to be working for ERCs and research areas. I probably should've kept my cards close to my chest until there was something big to report.
Activity within EPF
This was probably the most interesting and entertaining part for me. I heard and learned a lot from other folks, loved listening to everybody's updates during stand-ups, reading them and seeing how progress goes for my fellows working on the protocol while I was researching a quite vague area of practical protocol improvement.
Feedback about EPF
It could've been me, but I felt quite isolated compared to other folks while working on my project. Even though I think there could have been people I could bother for feedback, the required domain of knowledge is quite specific.
Takeaways
From this program I'm taking more than I initially expected. I was able to make it to the very end regardless of other things happening in work and life. Now I have a full understanding of the development cycle of the protocol and research: how to contribute, how to help others contribute, and where to find information and support if needed.
Getting better
I think the part about validating reports and getting the relevant people pulled in could be dedicated to a bot that would over time know the areas of expertise and be able to automatically help fellows find help, direction, or a connection with someone working on a similar thing.
Roadmap
To me it felt that one of the hardest parts of the proposal to work on was actually the roadmap, because now with AI capabilities it's extremely hard to properly estimate the work.
Contributing back to the epf.wiki
It's not something I need permission for, or somebody else does, but setting context is super useful. If the last week of the cohort were dedicated to contributing knowledge and updating the epf.wiki while the head is still fresh and knowledge is not forgotten, it could create a nice loop for the future setup of autonomous fellowships.