Hey, seems like we’ve both been working on the same problem. Wanted to drop a few notes from working on pq-sap.gwei.domains and writing things down at skas.gwei.domains.
Backing research
I’m still quite new to PQ, so I heavily relied on this paper when looking into ML-KEM for discovery. Most of the work since then has been trying to reproduce things, measure them, and figure out which parts should actually belong in the proposal.
Hybrid approach
During the research I also came across X-Wing, which got me prototyping again. ML-KEM-768 + X25519 sounds like a reasonable fallback against a classical break of either component.
There are some benchmarks and notes in the repo. The extra bytes are fairly cheap; the extra curve operation during scanning is more noticeable. And keeping the shared secret secure doesn’t necessarily keep the recipient anonymous, which needs its own analysis.
Ideally I’d like to leave room for both ML-KEM and a hybrid option without creating a separate scheme ID for every combination.
Scheme ID 2
To not do everything at once, I basically came back to keeping the proposal primarily about key exchange and address derivation. Spending is still a moving part on the protocol level, and I’d rather collect more data before setting it in stone.
Your scheme 6 already goes in that direction. What I’m wondering is whether classical spending could fit there as well. If discovery stays the same and only the account’s verifier changes, does that really need another scheme ID?
Different discovery formats still need to be distinguishable, of course.
Account abstraction
The useful change for me was deriving a contract account instead of an EOA. That lets the account decide how spending works, while the discovery part only needs to know how to derive the correct destination.
The shared secret alone isn’t enough to spend, since the sender knows it too. The account still has to check a separate recipient-only secret.
I’ve also been experimenting with frame transactions: deploy the account, verify authorization, handle sponsorship, then execute the spend. Quite a few things to explore there without dragging all of them into the discovery spec.
Stealth Meta Registry
There are a few questions around ERC-6538 as well. It already supports ERC-1271, but also accepts ecrecover authorization. What happens to that path once the account moves to PQ authorization? We shouldn’t leave the old key able to replace the meta-address.
Circle’s proposed ecrecover change and EIP-8151 are interesting from that perspective.
I’d also like to keep naming services and off-chain sharing as options. They still need a secure way to authenticate and update the SMA, but I don’t think discovery should depend on one registry.
Spending alone
This is where the benchmarks got slightly depressing. Some of the paths work, but the costs are difficult to justify.
SPHINCS- C13 was a nice surprise and the cheapest verifier I tested. Unfortunately, our direct route reveals the same public key on spending, linking those accounts. Hiding it inside a ZK proof works too, but adds proving costs, and the current UltraHonk backend isn’t PQ-sound.
As you mentioned, in-mempool signature and proof aggregation could change the economics quite a bit. Another reason for me to keep spending flexible while that work develops.
k1 spending
The ML-KEM + secp256k1 spending route was also suggested by an external contributor. It’s currently documented separately, but I’ve been looking at how classical and PQ spending could fit under the same discovery scheme through different account implementations.
Curious what you think about drawing the boundary there, and whether we could share some of the implementation work