Generic ERC-20 handler so approve / transfer don't fall back to raw hex

[phipsae]

Hi,

Thanks for the SDK. I integrated it (tag 0.1.3, Swift/SPM) into an iOS wallet that connects to dApps via WalletConnect, and it works great. Aave v3 supply and withdraw on Base clear-signed correctly.

One gap I ran into is that ERC-20 approves don't get clear-signed. Tokens rarely have descriptors in the registry (Base USDC only has EIP-712 descriptors, no calldata), so the SDK returns fallback / descriptorNotFound and the user has to blind-sign raw hex, right before the protocol call that clear-signs fine. Repro: the Aave v3 supply flow on Base, the approve (selector 0x095ea7b3) to USDC 0x8335...2913 falls back, the following supply clear-signs.

Since approve(address,uint256), transfer(address,uint256) and transferFrom are byte-identical for every ERC-20, one generic handler in the SDK could cover all tokens on all chains without adding anything to the registry.

To render "Approve 1 USDC" instead of "Approve 1000000 of token 0x8335...", the SDK also needs the token's symbol and decimals, and the pieces for that already exist. The embedded tokens.json already provides trusted names for well-known tokens. All other tokens can come from resolveToken, but since any scam token can call itself "USDC", those should be shown with a "not verified" marker (the existing GenericRenderWarning).

The same gap applies to the NFT standards (setApprovalForAll in particular). You're probably aware of this already, curious to hear your thoughts on the best way to solve it. Happy to discuss.

Best,
Philip

[hesterbruikman]

Thanks for trying this out @phipsae ! On the ERC20's... @llbartekll has raised the issue that we need to add a batch of common ERC20 descriptors to the registry. We'll likely need some auto-descriptor generator. Will follow up on this offline.