You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 the contract entity.
Requirements
When the metadata is not available for a Transaction Service Contract, try to gather it from the Transaction Service ERC20 Token entity.
The text was updated successfully, but these errors were encountered:
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
The text was updated successfully, but these errors were encountered: