Open hectorgomezv opened 6 months ago
This should be done on a case by case (decision on the caller). This functionality is already provided by the AddressInfoHelper
.
Is the issue then related with a specific feature or use-case? 🤔
The main goal would be to have the same metadata that is available on the transactions mappings (which use AddressInfoHelper
as you pointed out) when calling the Contract
endpoint directly (/v1/chains/:chainId/contracts/:contractAddress
) if I'm not wrong. And when calling it directly, AddressInfoHelper
plays no role.
I guess the clients could host this logic (fallback to one or another entity) if we provide a /token/:tokenAddress
endpoint (mimicking the Transaction Service), but the CGW doesn't provide it. So I think it's a fair question if we prefer to "combine" both sources or provide a second endpoint and let the clients implement the fallback.
Description
There are many ERC20 contracts where the Safe Transaction Service holds the token metadata available (displayName, logoUri) in the
/token/{address}
endpoint, but it's missing on our/contract/{address}
endpoint.It would be convenient for the clients to have the
token
metadata available on thecontract
entity.Requirements