Bridging a 8-decimaled token from mainnet
AkemiHomura-maow opened this issue · 7 comments
Describe the bug
Here's the pr I submitted #419 (which has since been merged) The bridged token has 8 decimals on Ethereum mainnet, and a decimal of 8 was marked in the json file.
But I have just found out that 10000 BITCOIN bridged from mainnet, ended up with only 0.000001 BITCOIN on Optimism.
Deposit tx: https://etherscan.io/tx/0x24d9e06d1a5d352a001c7377e9bee7dc6408e18002cb2c81d03415e9f50ec322
Reception tx: https://optimistic.etherscan.io/tx/0x4625ed722941d3ba2b3196e740415222d02675c636757f5e5c7a51eca029a830
Presumably because there's a difference in decimals of the token on mainnet and Optimism's OptimismMintableERC20. (1e8 vs 1e18) However, when calling createStandardL2Token()
on 0x4200000000000000000000000000000000000012
to create the standard L2 token contract on Optimism, no decimals are allowed in calldata so everything is in 1e18.
Expected behavior
The L2 token contract should be allowed to have 6 decimals as well
This issue has been automatically marked as stale and will be closed in 7 days if no updates
It's a good point. Looks like OP only supports 18 decimal tokens. It is possible to deploy an ERC20 token yourself and override the decimals property via extending optimisms interface. I will check in to see if making decimals configurable makes sense though but I suspect we will not make this change
I put up a POC here https://github.com/ethereum-optimism/optimism/pull/6680/files
This issue has been automatically marked as stale and will be closed in 7 days if no updates
I put up a POC here https://github.com/ethereum-optimism/optimism/pull/6680/files
tyty 🙏
This issue has been automatically marked as stale and will be closed in 7 days if no updates
This issue was closed as stale. Please reopen if this is a mistake