On questions 2 and 3, from the seller side. I run an x402 seller that quotes USDC on four EVM networks and Solana. Every EVM quote names one receiving address and the Solana quote names another. A seller set up that way is on rule 2(b) for Solana whatever it does, and for every payment if it keeps the agent wallet apart from the address that collects.
Question 2. Short validity is enough for a payee the seller stops using and still controls. A payee the seller has lost is another matter. A delegation goes out in every 402 answer, so anyone can keep a copy, and it verifies until validUntil, which can be 365 days out. If the key to a receiving address leaks, or a payment processor is let go, whoever holds that address and can change the 402 answer presents the old delegation and gets verified-delegation. That is the attacker from the Motivation, now with a valid signature. Short of waiting for validUntil, the only remedy is a new agentWallet setting, which voids every other delegation on every network at once, so all of them have to be signed again.
The draft can close this without a revocation list. Section 6 lets the registration file list payees, and the checker already reads that file at B for the endpoint rule. Make the list binding for delegations: one whose network and payTo are not in payees at B is invalid-delegation. Today it is verified-delegation with payee-not-declared beside it. Removing one line then revokes one delegation and leaves the rest alone. The cost is that a new payee then needs a file update as well as a signature, and files without payees stop verifying for delegated payees. The limit is the file’s host. Someone who controls it cannot forge a delegation, but can put back a removed line while that delegation is unexpired, and can delete the whole list if the list binds only when present. So the list should be required whenever a delegation is used, and a removal holds only where the tokenURI is content-addressed or a data: URI, which only a registry transaction by the owner or an approved operator can change. The same host can also remove lines and stop valid payments, which fails closed. I would also bring the 365-day ceiling down, since for a file served over HTTPS it stays the only bound a payer can rely on.
Question 3. The rule is right for contract wallets, and a Solana payee works as drafted because payTo is a string in the delegation. One case gets caught by accident: an agent wallet that is an EOA carrying an EIP-7702 delegation on the registry’s chain. Its code there is the 23-byte delegation indicator, 0xef0100 followed by an address, so a checker that tests for empty code refuses 2(a) on every other network and the seller has to sign a payee delegation to its own address for each one. The key still controls that address on every EVM chain, which is the reason 2(a) gives. 2(a) could treat code that is exactly the indicator as no contract code.
Douglas