The best way to interact with smart contracts is through their ABI. They describe functions, events, errors, and the like. They are fundamental for calling functions, and retrieving event data. Sometimes, however, it's hard to have hold of the ABIs of all contracts your application may indirectly interact with.
But why would you need the ABIs of contracts you don't even interact with directly? Well, if you call a contract that calls another contract, and this contract, in turn, raises an error, the contract you first called may propagate the error to you, and you'll have to figure out how to decode it.
You will easily decode canonical errors, like Error(string), Panic(uint256), but custom errors can have any signatures, like NotEnoughBalance(address,uint256,uint256). We need, therefore, a way for the developer to easily recover a signature from its selector, with little to no extra burden in terms of dependencies.
✔️ Solution
One solution is to use a signature database, like OpenChain's.
The database can be interacted with through this well-documented HTTP API.
From the consumer's side, they can query this database in many ways.
📚 Context
The best way to interact with smart contracts is through their ABI. They describe functions, events, errors, and the like. They are fundamental for calling functions, and retrieving event data. Sometimes, however, it's hard to have hold of the ABIs of all contracts your application may indirectly interact with.
But why would you need the ABIs of contracts you don't even interact with directly? Well, if you call a contract that calls another contract, and this contract, in turn, raises an error, the contract you first called may propagate the error to you, and you'll have to figure out how to decode it.
You will easily decode canonical errors, like
Error(string),Panic(uint256), but custom errors can have any signatures, likeNotEnoughBalance(address,uint256,uint256). We need, therefore, a way for the developer to easily recover a signature from its selector, with little to no extra burden in terms of dependencies.✔️ Solution
One solution is to use a signature database, like OpenChain's. The database can be interacted with through this well-documented HTTP API. From the consumer's side, they can query this database in many ways.
castcommands:4byte,4byte-decodeand4byte-eventFrom our side, we can upload the selectors of all of our contracts through
forge.📈 Subtasks
forge selectors upload --all