upgrade any wallet to post-quantum in one transaction with ZK proofs and a hidden public key
Starknet native privacy infrastructure
lightclient made two EIP-8141 changes: letting the payer approve before the sender, a simpler alternative to the guarantor role, and removing RLP call batches from the default account now that frame batching exists. The first was merged by accident, reverted and resubmitted. ethresear.ch proposed using EIP-7702 and ZK proofs under a hidden public key to upgrade any EOA to post-quantum security in one transaction.
(lightclient), submitted and merged: an alternative to the #11555 guarantor role, which the author finds simpler; it was meant to be a draft, so #11579 reverted it (submitted and merged) and #11580 resubmitted it.
EIP-8141: allow payer to approve before sender (lightclient), submitted and merged: an alternative to the #11555 guarantor role, which the author finds simpler; it was meant to be a draft, so #11579 reverted it (submitted and merged) and #11580 resubmitted it.
EIP-8141: allow payer to approve before sender (lightclient), submitted and merged: an alternative to the #11555 guarantor role, which the author finds simpler; it was meant to be a draft, so #11579 reverted it (submitted and merged) and #11580 resubmitted it.
(pochenai), submitted: restores the transaction level metadata role of the legacy input field (such as ERC-8021 attribution suffixes) in AA transactions; it is not part of EVM execution but must be in both the sender and payer signature hashes so relayers and builders cannot swap it.
18:07: the EOA delegates via EIP-7702 to a contract that only accepts ZK proofs of ECDSA knowledge under a hidden public key, with no address change, no asset migration and no consensus change; 87 ms to prove, 65 ms to verify and a 226 KB proof on Apple M1.