Moves bytes-extended into a std-lib-extended package instead, where I've added an expect function for the Option and Result types to more easily have more friendly revert messages when unwrapping these types
Fixes #8, #44, and #6 (there's a new configurable feature)
A note on the token exchange rate scale
Note that unlike the Solidity version, this uses a TOKEN_EXCHANGE_RATE_SCALE of 1e19 instead of 1e10. We originally chose 1e10 in Solidity because we wrongly assumed native tokens will generally be on the same order of magnitude, this is what LZ uses, and didn't put too much thought into the implications.
However the Fuel base asset is going to have 9 decimals, not 18, which means that the conversion between the Fuel base asset and remote tokens like Ethereum is going to many orders of magnitude different!
These are the best options I see:
Provide more precision in the 128 bit token exchange rate to account for decimal differences in the exchange rate. Note len(str(2 ** 128)) = 39, so 19 decimals of precision means there would be 20 digits on the left side of the decimal and 19 on the right. This is more equal than the currently used 10 decimals
Have the IGP also store the # of decimals of remote chains and use this when performing the conversion. The exchange rate would then be exchange rate between whole tokens.
I ended up going with (1) because it doesn't require more storage reads, but I could see 2 being useful
We may want to consider making a change to the Solidity implementation to be consistent - though note that for high decimal chains (18) that want to quote payments for low decimals chains (9, like Fuel), this involves a higher exchange rate on chain, which means that they're not impacted by only having 10 decimals of precision. E.g. an exchange rate posted to Ethereum that would signify the remote has 9 decimals but otherwise has the exact same value would be 1e9 * 1e10
interchain-gas-paymastercontract, which is a port of https://github.com/hyperlane-xyz/hyperlane-monorepo/blob/main/solidity/contracts/igps/InterchainGasPaymaster.solstorage-gas-oraclecontract, which is a port of https://github.com/hyperlane-xyz/hyperlane-monorepo/blob/main/solidity/contracts/igps/gas-oracles/StorageGasOracle.solbytes-extendedinto astd-lib-extendedpackage instead, where I've added anexpectfunction for the Option and Result types to more easily have more friendly revert messages when unwrapping these typesFixes #8, #44, and #6 (there's a new
configurablefeature)A note on the token exchange rate scale
Note that unlike the Solidity version, this uses a TOKEN_EXCHANGE_RATE_SCALE of 1e19 instead of 1e10. We originally chose 1e10 in Solidity because we wrongly assumed native tokens will generally be on the same order of magnitude, this is what LZ uses, and didn't put too much thought into the implications.
However the Fuel base asset is going to have 9 decimals, not 18, which means that the conversion between the Fuel base asset and remote tokens like Ethereum is going to many orders of magnitude different!
These are the best options I see:
len(str(2 ** 128)) = 39, so 19 decimals of precision means there would be 20 digits on the left side of the decimal and 19 on the right. This is more equal than the currently used 10 decimalsI ended up going with (1) because it doesn't require more storage reads, but I could see 2 being useful
We may want to consider making a change to the Solidity implementation to be consistent - though note that for high decimal chains (18) that want to quote payments for low decimals chains (9, like Fuel), this involves a higher exchange rate on chain, which means that they're not impacted by only having 10 decimals of precision. E.g. an exchange rate posted to Ethereum that would signify the remote has 9 decimals but otherwise has the exact same value would be
1e9 * 1e10