ERC-8441: Serendipity in BAAL

Hey hey, just a few weeks left before Devcon in Mumbai, so it's time to wrap things up!

BAAL

As usual, my serendipity worked out in a way that the most boring and non-unique piece of work I was doing (and for some reason decided to focus on, more reflections in the final report) got published first as research and then as ERC-8441[1] (BAAL, am I too 1337 and the only one to see it?).

The proposed scheme combines ML-KEM-768 encapsulation with a secp256k1 ECDH exchange through a hybrid KEM combiner. Both recipient keys are public, and the shared secrets, with both ciphertexts bound in, are combined through SHA3-256.

Asymmetric guarantees

The hybrid has an asymmetry worth spelling out. If ECDH falls to a quantum attack, ML-KEM preserves both the payment secret and recipient anonymity. If the less-researched ML-KEM shared-secret security fails, ECDH may still protect the spending secret, but it can't repair a failure of ML-KEM recipient anonymity, meaning transactions can be tracked.

As everyone can read between the lines, a pure ML-KEM scheme was dropped in favor of this combined one. And because it still relies on a key derivation formula for an EOA, there's no space for seamless migration in the future; we'd have to create another scheme. Scheme 6, the account-abstracted one, waits its turn.

My interpretation is that ERC-8441 is designed to finally ship the simplest yet still missing privacy tool for the Kohaku SDK and offer wallets a ready implementation. The biggest deviation from the original spec is the 1-byte scan tag optimization that isn't possible here: the recipient has to do the full ECDH and ML-KEM decapsulation before checking it. Implicit rejection makes the tag the only cryptographic prefilter, so a match has to be confirmed against the announced stealth address before it counts as a discovery.

Considering the amount of announcements and keys registered in the Stealth Meta-Address Registry, I'm quite bearish on the immediate impact: the canonical announcer logged one announcement in 24 hours, and its last ten span 24 days. More interesting designs may unveil closer to the Hegota hardfork, with frame transactions carrying the spending path.

Ten comments

During week 16 I reached out to the author to discuss some gaps in the design and offered to co-present the proposal at the EPF day, summarize the actual work and see how I could contribute to future work. A few days later I got the reply that the proposal was posted with an ERC number assigned, so I went to leave comments on the specification[2]. The authors also opened a discussion thread[3] listing where they'd most like feedback, and one of the six is KEM anonymity, a proof that ML-KEM-768 ciphertexts don't reveal their recipient. Exactly where my formal-verification work aims.

The short version of the ten:

• schemeId 2 is skipped; might not be worth skipping it.
• Wire format: an abstract inconsistent with §3, and the st:eth:0x… URI prefix needs its own parsing spec.
• The viewingKey in one section is the tracking key, in another it's recomputed from it; the terminology needs to unify.
• The FIPS 203 §7.2 key check before first use is a double-measure against corrupted registry records. Is it?
• A Decaps rejection case is unreachable behind §3's length check.
• The §2.7 check rules can be simplified to a checkStealthAddress(stealthAddress, ephemeralPubKey, viewingKey, spendingPubKey) reference.
• Once viewing_sk leaks, it decodes all future transfers; the original scheme's caveat should be stated.
• Since discovery is the weakest part (protocols already skip strict 5564 conformance and compute off-chain), scanner-side cost figures belong next to the gas measurements.
• The conformance-vector generator should still reference the plan rows it deliberately skips, not make them look like they never existed.

Currently they weren't directly answered or resolved, so I'll probably leave things where they are and come back to the collaboration once the feedback is addressed.

Proofs or it didn't happen

By now I'm focusing on closing the assumed gaps in the specification with my knowledge of Lean 4 and VCVio. The latter seems to be missing some important primitives the proofs would require. So I created an issue[4] proposing generic KEM recipient-anonymity games: ciphertext-only and key-revealing ANO-CCA, with the precise terminology (ANO-CCA, IK-CCA, or something more explicit) left to the maintainers, because papers disagree. As a follow-up I could research FO anonymity preservation and instantiate the result for ML-KEM. The issue also flags two missing shared-secret primitives: an ECDH-KEM with IND-CPA proven from a Diffie–Hellman assumption (SP 800-227[5] doesn't claim ECDH-KEM is IND-CCA), and a composite KEM proving the KeyCombineCCA_H combiner IND-CCA when either component is. Neither of those establishes who the ciphertext hides; that's what the anonymity games are for.

So far, Lean 4 and the missing VCVio tools look like the most straightforward way for me to contribute to this proposal.

A dozen parallel efforts

Seems like a dozen folks were working on the same problem with not much coordination[6], and with all the recent events it's become quite clear how to materialize it, accounting for all the preferences, NO LATTICE SPENDING PATH included, as well as the requirements for trustlessness of the architecture.

Bunker mode

Also, since Vitalik did a great reply[7] to Justin Drake's callout[8] for a bunker mode, it should become more obvious why stealth addresses are one of the great choices for privacy. They combine some weak sender privacy (sorry, but if you send me money I might want to know who you are) with the ability to easily rotate funds through self-sends to fresh addresses that never produced a transaction, so their public keys stay protected. The one nuance from the same week's discussion: register carefully or share meta-addresses off-chain, because the registry is the exposure.

The bigger takeaway for me is elsewhere in that reply: hash-based > lattice-based wherever hash-based is possible at all, and if lattices remain, be paranoid about parameter sizes. ML-KEM-768 with a classical fallback is exactly the architecture you get when you take that seriously for encryption. Hash-only can't do public-key encryption, but a hybrid can degrade gracefully.

Reflection

While writing and reading that summary it occurred to me how easily I engage in conversation on ethresear.ch, the ERC repo, VCVio, and so on, and I figured out how useful this whole experience has been to me. If not for EPF, I'd probably stay in mostly read-only mode with some rare occasional contributions.

Next

The rest of week 17 is going to be about contributing to VCVio (I hope so) to get the necessary tooling for formal verification of ERC-8441, and perhaps iterating on the spec.

One more quest and an interesting tool to play with just unveiled itself: I'm planning to look in detail at the testnet called Daisugi[9], essentially a testing playground for post-quantum migration that seems to have transaction aggregation enabled already.

जल्द ही फिर मिलेंगे!