Feat: enable `cast` to accept stupid URN prefixes; fixes bug with ENS parsing too

[sambacha]

Component

Cast

Describe the feature you would like

I want

cast nonce eth:0xC66C8aa97065f327fe94B6c845ACd7E5aA6f6117

to work like

cast nonce 0xC66C8aa97065f327fe94B6c845ACd7E5aA6f6117
22

Additional context

$ cast nonce eth:0xC66C8aa97065f327fe94B6c845ACd7E5aA6f6117
Error:
ens name not found: eth:0xC66C8aa97065f327fe94B6c845ACd7E5aA6f6117

This suggests incorrect parsing for detecting ENS names, as : is disallowed in ENS grammar.

[mds1]

Are you specifically referring to ERC-3770? If so, that's a nice idea—instead of using the --chain or --rpc-url flag for commands, support ERC-3770 syntax and automatically change the env var that's used for RPC URL or Etherscan API key, based on the shortName

This suggests incorrect parsing for detecting ENS names, as : is disallowed in ENS grammar.

IIRC the logic here is just: if the input isn't a hex address, try parsing it as an ENS name, i.e. there's no explicit checks on what's allowed/disallowed by ENS grammar

[sambacha]

Are you specifically referring to ERC-3770? If so, that's a nice idea—instead of using the --chain or --rpc-url flag for commands, support ERC-3770 syntax and automatically change the env var that's used for RPC URL or Etherscan API key, based on the shortName

This suggests incorrect parsing for detecting ENS names, as : is disallowed in ENS grammar.

IIRC the logic here is just: if the input isn't a hex address, try parsing it as an ENS name, i.e. there's no explicit checks on what's allowed/disallowed by ENS grammar

Yes I only have good ideas.

Yours,

Herr Bacha

[DaniPopes]

This is out of scope, cast doesn't know or care about chain ID when making RPC calls, nor would it do anything different if it did.

[sambacha]

This is out of scope, cast doesn't know or care about chain ID when making RPC calls, nor would it do anything different if it did.

Thats because the user would do something different if it saw incongruent results with the expected chainId.

This is for the users reassurance, its an aesthetic choice.

Also our own RPC service provides one endpoint: supplying the chainid routes the request accordingly. This makes managing multi network workflows much easier in practice.

Please reopen this issue

[mds1]

I think this could be useful and is worth discussing, so going to reopen.

For context, a lit of short name prefixes is maintained in https://github.com/ethereum-lists/chains

I keep a ton of rpc urls as env vars in my zshrc, and am often running cast <stuff> -r $[CHAIN_NAME_RPC_URL], and a shorthand for that would be handy. Two implementation ideas:

• Canonical env var names of SHORT_NAME_RPC_URL or CHAIN_NAME_RPC_URL are automatically used when referencing an address in cast using the eth:0x123... syntax
• Rely on foundry.toml to define the mapping from prefix to RPC URL, but this does not enforce short name consistency between projects using the existing standard.

[fvictorio]

An alternative to avoid envar hell would be a cast config command that can be used to add networks aliases. For example:

cast config add network eth https://...

(or cast alias or whatever)

and then you can do either cast block-number -r https://... or cast block-number -r eth.

This same idea could be used to add other aliases, for example cast config add address dai 0x..., so I think it makes sense to put it behind a top-level command.

[mds1]

That's a really nice idea. Addresses often also need to be chain specific, so we might need to expand that second example to something like cast config add address dai 0x... --network eth. Then when using -r eth in a cast command, that's how you specify the chain, so cast call dai "totalSupply()(uint256)" -r eth knows to use the eth network dai address from my config.