Reading both proposals back-to-back as a docs engineer, not a protocol researcher, three
things would help implementers regardless of which direction wins:
1. Terminology drift between the two specs. scheme_id and validation frame are
overlapping concepts with different vocabularies. Anyone reading both specs in sequence,
wallet devs especially, will trip on this. A shared glossary in the specs would save
hours.
2. Migration semantics are absent. Both EIPs describe the new transaction shape but
neither covers the actual flow: how does an existing EOA owner rotate to a new scheme?
What does the wallet UX look like? What are the failure modes during migration? The gas
tables don’t answer “what does this cost a user once they want to upgrade.”
3. “Implementer summary” sections are missing. Both specs would benefit from a stanza at
the top distinguishing what node implementers need from what wallet implementers need,
since they’re two audiences with different priorities. Right now the specs read as
protocol-first, which makes them dense for the people building on top.
The hybrid direction @Giulio2002 sketched (immediate PQ security via SchemedTransactions,
Frame Transactions deferred) is reasonable from a shipping standpoint, but the migration
docs story becomes even more important in that world because implementers will span two
transaction shapes over time.
Happy to contribute a “reading both specs as a wallet implementer” companion doc if it
would help the authors pressure-test the current drafts.