Skip to main content

Migration for Service Providers

Energi Core Gen 3 is a completely new development based on go-ethereum 1.8.27 codebase. The current Gen 2 blockchain is going to be terminated. All Gen 2 coins will be migrated a secure way to Gen 3. It is NOT a coin swap. The process is designed this way for clear transparency and to minimize possible scams related to parallel network operation.

It is expected that service provider integration is similar to Ethereum JSON-RPC in terms of account and transaction handling.

danger

Only Pay-to-Pubkey-Hash (P2PH) addresses can be migrated through the procedure. Multisigs and Pay-to-Script-Hash (P2SH) wallets ARE NOT supported. Please send all coins to a Pay-to-PubKey Hash (P2PKH) wallet BEFORE the migration time.

New software availability:​

It is expected that each peer runs the latest available software release at the moment of migration, but not older than the minimum required in the migration announcement (see below).

Releases are available via the download page.

General blockchain migration overview:​

  1. Energi Core will announce the exact block for migration to occur and minimal software version to use.
  2. Once the Blockchain reaches the block, it will get halted at the exact block hash, which will be identified by standard Consensus. No side chains would be possible.
  3. Gen 3 infrastructure is expected to be pre-deployed with Genesis block #0 by then.
  4. Energi Core will take a verifiable snapshot of Gen 2 blockchain state and publish it.
  5. The snapshot will be used to create a special block #1 which will setup a special Gen 2 coin migration smart contract.
  6. Initial staking will be done via Delegated Proof-of-Stake of the migration smart contract. All rewards will go into our Treasury.
  7. At block #2, anyone will be able to claim Gen 2 coins via special zero-fee transactions using Gen 2 key signatures.
  8. Anyone, who is late to prepare, will be just unable to use the network, but coin migration should be available through the lifetime of the Gen 3 network, or until the Consensus changes.

Service provider migration suggestion:​

All service providers are expected to stop any transaction activity at least 60 blocks before the migration for general safety reasons.

danger

Note: Service Providers are unable to control when deposits are sent to process that properly. It is possible that deposited, but not accounted amount cases occur. After migration, service providers are expected to use new Gen 3 addresses which correspond to Gen 2 addresses in Variant A to process deposits a regular way.

Variant A - the "gen3migrate" command:​

  1. Wait for Gen 3 block #1.
  2. Generate a new Gen 3 wallet.
  3. Run Energi Core Gen 2.
  4. Use gen3migrate 0x..{gen3address}....
  5. The time taken depends on count of accounts with funds.
  6. On any error, the procedure can be repeated until all funds are migrated.
  7. The debug.log will have the details of migrations made.
info

This is the simplest option to be used by the majority of users, but it requires to solve incomplete deposits problem.

Note: this is not the most secure and reliable approach.

Variant B - dumpwallet:​

  1. Upon creation of block #1, service providers are expected to extract their private keys via a regular Gen 2 dumpwallet command.
  2. The result file to be fed into energi.claimGen2CoinsImport(password, file) Gen 3 node console command.
  3. For each private key with coins on associated Gen 2 address, the local node will create a keystore file and claim coins into Gen 3 address via 1:1 scheme. The "password" will be used to encrypt keystore files.
  4. New Gen 3 deposit addresses are expected to be used for regular processing.
  5. Some migrated change addresses will need to be combined manually afterwards.
danger

Note: both Bitcoin and Ethereum use ECDSA scheme with 256-bit keys and secp256k1 curve. However, there is a different approach to derive addresses from public keys.

Variant C - custom private key management:​

Upon creation of block #1, service providers are expected to use:

energi.claimGen2CoinsDirect(password?, dst, base58_privkey)

Gen 3 node console command for each private key. It is expected that "dst" is a Gen 3 address existing in a local wallet as keystore file or via hardware wallet.

Variant D - combine & resolve deposits manually:​

It is also possible to combine all coins into a single new Gen 3 account as assumed by ordinary wallet migration. In this case, service providers will have to manually resolve all possible not processed deposit issues.

danger

Note: there is also a flexible option to manually create a zero-fee transaction to claim Gen 2 coins, but that can be much more error prone.

Variant E - ordinary wallet migration suggestion:​

The procedures above do not fit ordinary user wallet cases. It is expected that most users use energi.claimGen2CoinsCombined(password?, dst, file) command to combine all Gen 2 coins into a single Gen 3 address as Ethereum does not assume change addresses existence.

For most user convenience, we also provide Nexus dApp which also supports serverless web-based Gen 2 coin claiming feature without any need to run a local node.

Public API endpoints:​

Core Node:​

This is Ethereum-like JSON-RPC with Energi extensions.

  1. Mainnet: https://nodeapi.energi.network
  2. Testnet: https://nodeapi.test.energi.network

Blockscout Explorer:​

This is Blockscout specific API.

  1. Mainnet: https://explorer.energi.network/api
  2. Testnet: https://explorer.test.energi.network/api

Example daemon launch command​

This is an example how to run a node for RPC usage.

./bin/energi3 \
--datadir /var/lib/energi3/.energicore3 \
--cache 2048 \
--nousb \
--gcmode archive \
--maxpeers 128 \
--rpcvhosts '*' \
--ws --wsaddr 0.0.0.0 --wsport 39795 \
--rpc --rpcaddr 0.0.0.0 --rpcport 39796 \
--rpcapi debug,eth,net,shh,txpool,web3,masternode,energi \
--wsapi debug,eth,net,shh,txpool,web3,masternode,energi \
--rpccorsdomain '*' --wsorigins '*'

Overview of useful API​

Account & transactions API:​

  • personal_newAccount(password)
  • personal_unlockAccount(account, password, 0[, staking_only])
  • nrg_sendTransaction({from: '0x...', to: '0x...', value: '0x...'})
  • nrg_getBlockByNumber(number)
  • nrg_getTransactionByHash(hash)

Migration API:​

  • energi_listGen2Coins()
  • energi_searchGen2Coins(owners[], include_empty) - search by Base58
  • energi_searchRawGen2Coins(raw_owners[], include_empty) - search by raw Hex
  • energi_claimGen2CoinsDirect(password?, dst, base58_privkey) - claim one key to specific address
  • energi_claimGen2CoinsCombined(password?, dst, file) - claim all coins from Gen 2 file dump to specific address
  • energi_claimGen2CoinsImport(password, file) - claim all coins from Gen 2 file dump to the same private keys imported into current instance
  • admin_validateMigration(snapshot_file)

Masternode Token API:​

  • masternode_collateralBalance(addr)
  • masternode_depositCollateral(addr, amount[, password])
  • masternode_withdrawCollateral(addr, amount[, password])

Masternode Registry API:​

  • masternode_listMasternodes()
  • masternode_stats()
  • masternode_masternodeInfo(owner_or_mn)
  • masternode_announce(owner, enode[, password])
  • masternode_denounce(owner[, password])

Budget API:​

  • energi_budgetInfo() - list all budget proposals and their current state

Miner API:​

  • miner_setMinerNonceCap()
  • miner_stakingStatus()