Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fallback to Token metadata when the metadata is not accessible via the Contract entity #1506

Open
hectorgomezv opened this issue May 6, 2024 · 2 comments
Labels
enhancement New feature or request

Comments

@hectorgomezv
Copy link
Member

hectorgomezv commented May 6, 2024

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 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.
@hectorgomezv hectorgomezv added the enhancement New feature or request label May 6, 2024
@fmrsabino
Copy link
Contributor

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? 🤔

@hectorgomezv
Copy link
Member Author

hectorgomezv commented May 6, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants