Needs to be investigated but I suspect this to be Coingecko limitation for Arbitrum

Looking into this now, it looks like on production it's calling coingecko to get a price like this:

https://api.coingecko.com/api/v3/simple/token_price/xdai?contract_addresses=0xFd086bC7CD5C481DCC9C85ebE478A1C0b69FCbb9&vs_currencies=eur&x_cg_demo_api_key=

Correct me if i'm wrong, but on production it should be using arbitrum one as the asset platform, so using:

https://api.coingecko.com/api/v3/simple/token_price/arbitrum-one?contract_addresses=0xFd086bC7CD5C481DCC9C85ebE478A1C0b69FCbb9&vs_currencies=eur&x_cg_demo_api_key=

The contract address is from Arbitrum, so when it's called using xdai the contract address is wrong and everything is coming back as 0 value.

@rdig if this sounds right, i'll work on correcting the asset platform in these urls

Looking into this now, it looks like on production it's calling coingecko to get a price like this:

https://api.coingecko.com/api/v3/simple/token_price/xdai?contract_addresses=0xFd086bC7CD5C481DCC9C85ebE478A1C0b69FCbb9&vs_currencies=eur&x_cg_demo_api_key=

Correct me if i'm wrong, but on production it should be using arbitrum one as the asset platform, so using:

https://api.coingecko.com/api/v3/simple/token_price/arbitrum-one?contract_addresses=0xFd086bC7CD5C481DCC9C85ebE478A1C0b69FCbb9&vs_currencies=eur&x_cg_demo_api_key=

The contract address is from Arbitrum, so when it's called using xdai the contract address is wrong and everything is coming back as 0 value.

@rdig if this sounds right, i'll work on correcting the asset platform in these urls

If that is the case, then that does seem like a straight forward solution :) perhaps it should be an environment variable.

I think I've got it working using the environment variables that we currently have (network_id) and updating the asset_platform map that we use in the coingecko config to handle all the possible network_ids that we currently support. I'll check with the other devs to see what they think.