@dob asked for key use cases this proposal does not cover. I have one, and the useful part is that it does not need a new testnet type. The types already proposed can carry it.
Signing with a real key, on the hardware the key actually lives on. Type 3 reaches this already. An anvil fork accepts eth_sendRawTransaction, so a transaction signed on a device executes against the real deployed contracts. I signed setRewardCaller on a Trezor, broadcast it to a local fork and it was included, from recovered as the device’s address, status success, the mapping written. No mainnet transaction and no orchestrator needed.
What is missing is that nothing in the described workflow asks for that run. The word “sign” does not appear anywhere in the proposal. The types are described in terms of cheat codes and simulated state, and the use cases listed, Explorer and Subgraph development, do not involve producing a signature. That is a reasonable default for testing contract logic, and the effect is that the signing path never comes up.
It matters because LIP-118 exists to move the stake-holding key onto hardware. When I actually did that and looked at the screen, the call renders as two pages of raw hex with the delegate address split across the page break. Screens, reproduction and the fix are in my reply on the LIP-118 thread rather than here, since that is where the design discussion lives:
I should say that I did not review LIP-118 while it was open either, so this is a gap I walked into, not one I spotted from outside.
For what it is worth, the fixes are in flight:
- an ERC-7730 descriptor for BondingManager, so hardware wallets render these calls as text instead of hex: ethereum/clear-signing-erc7730-registry#2978
- the proxy resolver that descriptor and decoding tooling both need, since ManagerProxy keeps no implementation pointer in a standard slot: shazow/whatsabi#216 and argotorg/sourcify#2959, both merged
- three against MetaMask so software wallets decode our contracts properly: metamask-extension/#45819, #46086 and #46089
The testnet step is the one piece I cannot do from outside, which is why it is the only thing I am asking for here.
The suggestion, which is small: for any change that alters what the stake-holding key must sign, add a run with a real signer on type 3 and attach the screens. No new infrastructure, four commands on the fork tooling already in this proposal, and the kind of thing a reviewer can do in ten minutes.
It also bears on your second point about 2.0. If migration mechanics need that key to sign something new, and the only review available on the hardware wallet is raw calldata across two screens, operators drift back to hot keys for the sake of a software wallet that can at least name the function. That would undo what LIP-118 set out to enable, and it is cheaper to find out while the spec is still open.