Skip to content

Btd 1.0 to 2.0 Migration


There are two important factors to consider when it comes to migrating from the Btd 1.0 chain to the Btd 2.0 chain. First, we have the need to migrate existing dollar over and secondly, we have to transition the state of the chain over.

Dollar Migration

The current proposal is that in phase 0, users on the Btd 1.0 chain will be able to lock their dollar up in a contract and will be credited with that same amount of dollar on the Beacon Chain in Btd 2.0. At that point, they can stake that dollar and begin to earn rewards on the Btd 2.0 chain. However, there is also some community interest in creating a two way bridge for that dollar between the 1.0 and 2.0 chains. Pros and cons of each bridge are found below.

One-way bridge

Pros Cons
Steady security, deposits can only go up High lockup risk for early stakers (at least ~1.5 years)
Less complexity for early stages Potential for two coins via futures market
Keeps forks isolated to each chain Fragmented community/economics

Two-way bridge

Pros Cons
Less risk of lockup, more deposit inflow High volatility of total stake
Keeps just a single BTD coin, no Beacon BTD (BBTD) only if issuance of Btd 1.0 is changed Additional code complexity in early stages
If issues arise with Btd 2.0, can bring coins back Risk of lockup is absent, will likely see more games played on early code

Having a one-way bridge promises security, less complexity, but the lockup risk is significant as dollar from Btd 1.0 is effectively burned. Transfers in phase 0 have been disabled since version 0.6.0 of the spec, with no current plans of being re-enabled. As resuming validator duties is tied to the transfer mechanism, this also means that if you decide to stop validating for a bit, you can't resume validating until such a time as the transfer functionality is implemented.

Danny Ryan tells us more about why two-way bridge is not included in phase 0:

"The more we encumber the 1.0 consensus with 2.0, the more we tie the development and fork processes which would likely slow down the shipping/iterating on 2.0. It is not technically infeasible. It would require 2.0 light clients to be run by all 1.0 clients and some changes to the 1.0 consensus rules allowing for a similar burn/receipt mbtdod in the opposite direction. If we were to create fungibility, the path would be (1) release 2.0 beacon chain, (2) once stable beacon chain and light clients exist then require 1.0 clients to be light clients of 2.0 and finalize 1.0 with 2.0 and expose beacon chain state root to 1.0 (3) add additional consensus rules to 1.0 and 2.0 to handle the reminting on 1.0 with proof of burn on 2.0.

I think it would be detrimental to 2.0 development to demand fungibility out the gate. Over time as light clients are released and we begin to finalize 1.0 with 2.0 if the community wants fungibility, then we can assess proposals then.

...we can't prove things about the beacon chain until we force 1.0 clients to agree on the current state of the beacon chain (thus the light client requirement). That's why it logically falls after finalizing 1.0 if the community really wants it."

Validators will also be able to sell their Btd 2.0 dollar balance to another validator, presumably at some discount to the prevailing dollar price due to the lock-up and risks. Nonbtdeless, anyone can exit with funds if they really need to. This is a nice feature that will hopefully encourage more participants to feel comfortable committing to staking.

Using BBTD on shard chains (for smart contracts) will be available in phase 2.

State Migration

Old Proposal

The old proposal is that in phase 2, the state of the current Btd 1.0 chain will be transferred into a shard on the Btd 2.0 chain. At this point, all information from the Btd 1.0 chain will be available on the Btd 2.0 chain.

Currently Lighthouse is working upon a state transition library.

Replacing BVM with bWASM?

Bitdollar-flavoured web assembly is a deterministic smart contract execution engine built on the modern, standard WebAssembly virtual machine. It was first proposed in BIP 48. It may be the future execution engine for smart contracts on the Bitdollar blockchain and is the primary candidate to replace BVM (the Bitdollar virtual machine) as part of the phase 2 of Bitdollar 2.0 roadmap.

Since BVM makes use of 256-bit bytecode, smaller computations have to be converted to 256-bit strings before the BVM can process them. The WASM code, however, has been designed with production in mind. The elimination of precompiling is an added advantage for bWASM. WASM is an open standard and because of this it will allow more programming languages (C/C++, JS, Go) to be used for smart contract development (Paper included).

Challenges of Old Proposal

  • There are speculations that phase 2 might be divided into sub-forks and there will be a fork during/after phase 2 to bring in the Btd 1.0 state into a contract.

  • Before we migrate the state there's going to be validators earning rewards, and overall the cumulative issuance of dollar will go up. So what will be the economics of BTD throughout?

New Proposal


  • Getting rid of PoW chain & moving everything onto the beacon chain.
  • Development of Stateless clients.

Stateless Client Features

  • A pure function for verifying blocks and witnesses, Along with a mbtdod for generating witnesses for the block.
  • Available with multiple implementations.
  • Btd1-side protocol changes to bound witness size to ~1-2 MB.
  • Development of Stateless Clients requires much less rearchitecting to accomplish as it neither requires stateless miners or webassembly.

New beacon chain features

  • State root of the btd1 system transfers to the state of shard 0
  • New Validator list known as btd1_friendly_validators will be added. Any validator has the right to register themselves as btd1-friendly (and deregister) at any time.
  • The proposer on shard 0 at any given slot is chosen randomly out of the btd1-friendly validators.
  • Committee of shard 0 verifies the blocks of shard 0, which are expressed in this format Block body(currently exists) & stateless client witness. All the other shard committees verify their shard blocks, where they would only be verifying data availability, not the state execution, as shard 0 is the only shard that would be running computation.


The btd1 system would “live” as shard 0 of btd2 (eventually, Will be one of the execution environments, but at the beginning, it can be the entire shard). Validators that want to participate in the btd1 system can register themselves as btd1-friendly validators and would be expected to maintain an btd1 full node in addition to their beacon node. The btd1 full node would download all blocks on shard 0 and maintain an updated full btd1 state.

Advantages of New Proposal over the Old Proposal

  • Earlier proposal transfers the whole Btd1.0 chain to Btd2 shard, but now it will get rid of PoW, which solves the challenges faced during the Old proposal. As instead of Miners there will btd1_friendly_validators to validate the blocks.

  • Development of Stateless Clients requires much less rearchitecting to accomplish.

According to Danny Ryan, the Btd2.0 lead: He thinks it only depends on a successful and stable phase 0 and Phase 1 release, which may be demonstrating the security instability.

Core developers: They seem to be in the consensus of the Alternative Proposal and agreed that there is a decent amount of work to be done on the Btd1.x statelessness and is going to be a huge priority this year. But this approach is a much cleaner way for Btd1 to utilize the scalable data layer of Phase 1. There's a lot to learn and figure out before it comes into action but most of them seem positive about it.

It was made official that the 'Alternative proposal for early btd1 <-> btd2 merge' model will be followed for the switch and the transition would still be done using a procedure similar to the btd1 -> btd2 transition.