fuels-ts
fuels-ts copied to clipboard
Incorrect asset for devnet
We export assets that can be easily consumed by the end user.
- The
assetId
is currently0x0000….
(or baseAssetId), is incorrect for devnet. - The
chainId
for devnet should be 0.
Reported by @LuizAsFight
I think beta5 can be removed and devnet changed to zero. as we will drop support to beta5 when devnet gets released
about the baseAssetId its a bigger problem my first thought for this:
- the static definition
assets
should not be exported anymore. create aisBaseAsset
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
@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 Do you know why baseAssetId
became dynamic?
@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"
ref #2394
@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?
Should add a new entry for testnet
- or renamed devnet
?
We should add a new entry
@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