Developer Docs

Learn more about the Habtor Network and OVM 2.0

FAQs

1. What is the Gas Price on Habtor L2?

   The Gas Price on L2 changes every 30 seconds with some smoothing to reduce sharp discontinuities in the price from one moment to the next. The maximum percentage change from one value to another is capped to not more than 5% in the gas price oracle. For example, if the current gasPrice is 10 Gwei then the next gasPrice will be between 9.5 and 10.5 Gwei. Like on mainchain, the current gas price can be obtained via .getGasPrice() and is typically around 10 Gwei.

2. What are the decimals for tokens on the Habtor L2?

   In general, the decimals on L2 mirror those of L1. You can check decimals using the blockexploer.habtorscan.com, for example:

   https://blockexplorer.habtorscan.com/tokens/0x66a2A913e447d6b4BF33EFbec43aAeF87890FBbc/token-transfers

   Exception: Note that the decimals on Bsc Testnet are generally 18, whereas on L2 mainnet they mirror the Bsc mainnet L1 decimals.

   You can also check the decimals of course by calling the token contracts:

   const decimals = await this.ERC20_Contract.attach(tokenAddress).connect(this.L2Provider).decimals()
   //typical values are 18 or, in some rare but important cases, 6

3. How do I bridge funds from L1 to L2?

   There are two methods, the classical bridge and the fast bridge. You can see an example of the classical bridge here. There is working code here.

4. Do you support EIP-2470: Singleton Factory?

   Yes! ERC-2470 is deployed to 0xce0042B868300000d44A59004Da54A005ffdcf9f on the Habtor L2. The address on the Habtor L2 is the same as on BSC mainnet.

5. How do I follow cross domain (xDomain) transactions and their status?

   There are 4 different mechanisms for following the status of a transaction.

   1. The Habtor Blockexplorer (for L2) and Bscscan (for L1)

   2. Running a typescript watcher

   3. Using the Habtor atcher-api

   4. Third-party analytics

   These methods are described here.

Historical Notes for users of OVM 1.0 - the OVM 2.0 Changeset

The v1 to v2 changes reduced the differences between the OVM and EVM so that developers can implement their contracts with just one target in mind, instead of managing OVM idiosyncrasies with separate contracts. Here is the list of changes to watch for, in case you are used to v1:

1. Contracts whose source code has not been verified on Bscscan will be wiped out along with their storage.

2. Contracts whose source code has been verified will be recompiled with the standard Solidity compiler. As a result of this:

   1. The EXTCODEHASH and CODESIZE of every contract will change. Any hardcoded values will break.

   2. The address generated by CREATE2 may be different (it depends on the constructor code).

   3. Code size will no longer be increased during compilation. Any custom OVM work that required reducing code size could now be reverted.

3. BNB will no longer be ERC20 compatible.

   1. Users will no longer be able to transfer and interact with BNB as an ERC20 located at 0x4200000000000000000000000000000000000006.

   2. Please let us know if you rely on this functionality on Habtor mainnet currently as we will have to migrate those balances to a standard WBNB contract which will be deployed to a new TBD address

   3. The Transfer event currently emitted on BNB fee payment will be removed

4. Our fee scheme will be altered. Learn more

5. EOAs will no longer be contract wallets

   1. Currently, every new EOA in Habtor network deploys a proxy contract to that address, making every EOA a contract account.

   2. After the upgrade, every known contract account will be reverted to an EOA with no code.

   3. To best handle the upgrade, we recommend you write your contracts to handle normal EOAs and to make no assumptions around EOAs having code or additional OVM-specific functionality.

6. Gas usage will decrease to be the same as on L1 Bsc mainnet.

   1. Currently, the OVM results in an increase in gas usage because of compiled OVM opcodes, sometimes inflating gas costs by up to 10x the costs on L1 Bsc mainnet.

   2. With this OVM upgrade, gas usage on Habtor mainnet should now exactly match the expected gas usage from a deployment to (L1) Bsc mainnet in almost all cases.

7. Certain opcodes will have updated functionality:

   1. NUMBER - block.number in L2 will now correspond to the L2 block number, not “Last finalized L1 block number” like it used to. Any project currently using block.number must check that this will not break their implementation. The L1 Block number will be made accessible via a new pre-deployed contract.

   2. COINBASE is set by the sequencer. For the near-term future, it will return the OVM_SequencerFeeVault address (currently 0x4200000000000000000000000000000000000011)

   3. DIFFICULTY will return 0

   4. BLOCKHASH will return the L2 block hash. Note that this value can be manipulated by the sequencer and is not a safe source of randomness.

   5. SELFDESTRUCT will now work just as it currently works in the EVM.

   6. GASPRICE will now return the l2GasPrice

   7. BASEFEE will be unsupported - execution will revert if it is used.

   8. ORIGIN will be supported normally.

8. Certain OVM system contracts will be wiped from the state. We will remove:

9. OVM_ExecutionManager

10. OVM_SequencerEntrypoint

11. OVM_StateManager

12. OVM_StateManagerFactory

13. OVM_SafetyChecker

14. OVM_ECDSAContractAccount

15. OVM_ExecutionManagerWrapper All other OVM pre-deploys will remain at the same addresses as before the re-genesis

16. TIMESTAMP will function the same as before, updating with each new deposit or after 5 minutes if there has not been a deposit. TIMESTAMP will still correspond to "Last Finalized L1 Timestamp"