Incorrect asset for devnet

[petertonysmith94]

We export assets that can be easily consumed by the end user.

• The assetId is currently 0x0000…. (or baseAssetId), is incorrect for devnet and testnet.

  • Expected: 0xf8f8b6283d7fa5b672b530cbb84fcccb4ff8dc40f8176ef4544ddb1f1952ad07

• The chainId for devnet should be 0.

Reported by @LuizAsFight

[LuizAsFight]

I think beta5 can be removed and devnet changed to zero. as we will drop support to beta5 when devnet gets released

[LuizAsFight]

about the baseAssetId its a bigger problem
my first thought for this:

• the static definition assets should not be exported anymore. create a isBaseAsset flag, so we don’t need to inform the address for the base assets, and can identify it later on next topic
• create a getAssets which receives the provider and sort out the correct baseAssetIds to the assets that are needed. also it can filter out the assets that are not from the provider chainId

[Torres-ssf]

@LuizAsFight Why we should remove the static assets?

I reckon that the baseAssetId is not something that's going to change on Test-net/Main-net.

[arboleya]

@Torres-ssf Do you know why baseAssetId became dynamic?

[LuizAsFight]

@LuizAsFight Why we should remove the static assets?

I reckon that the baseAssetId is not something that's going to change on Test-net/Main-net.

@Torres-ssf its not to remove static assets, instead its to keep it, but remove only the specific mocked asset ids 0x00000...

a quickfix would be to just replace the assetId from testnet eth to be "0xf8f8b6283d7fa5b672b530cbb84fcccb4ff8dc40f8176ef4544ddb1f1952ad07"

[LuizAsFight]

ref #2394

[arboleya]

@xgreenx @LuizAsFight As we briefly discussed last week, should we use a hardcoded assetId value in the JSON for now and re-think the approach if/when the situation changes?

[petertonysmith94]

Should add a new entry for testnet - or renamed devnet?

[xgreenx]

We should add a new entry

[xgreenx]

@xgreenx @LuizAsFight As we briefly discussed last week, should we use a hardcoded assetId value in the JSON for now and re-think the approach if/when the situation changes?

Yes