PIP 1- BTC++, BTC on Ethereum diversified


BTC on Ethereum diversified



BTC++ it’s a weighed allocation between the different representations of Bitcoin on the Ethereum.


There is a race for bridging Bitcoin to the Ethereum Network. a number of projects have made steps in that direction with adopting solutions that go from 100% custodian services to mechanism design that might result in economic finality for a trustless swap of BTC<->ETH.

Each project has different tradeoffs in terms of security, even assuming the assumptions are correct the risk associated with bugs on the system makes holding those tokens risky in isolation.

Screen Shot 2020-03-26 at 2.22.54 PM


Deploy a BTC Pie which holds a set of different representations of Bitcoin in the Ethereum network called BTC++ deployed as a Balancer Pool.

Benefits for users

  • Users who want to have controlled exposure to different BTC on Ethereum don’t have to deal with complicated and/or expensive rebalancing procedures.

  • Holders of WBTC/pBTC/imBTC/sBTC… who have those tokens sitting idly in a wallet can now put them to work so they can effortlessly earn fees.

Why Balancer pools

Balancer is a nascent ecosystem with significant improvements compared to other AMM out there. They are a week away to launch to the masses and there is currently no BTC pool available. Claiming the first mover advantage and bootstrapping that ecosystem would have several benefits:

  • BTC++ could easily become the largest pool in the Balancer ecosystem, which means most of the trades would be routed through the BTC++ pool.

  • Having a pool with only BTC tokens it’s more convenient for liquidity providers than Uniswap as there is no ETH exposure and the impermanent loss it’s minimized.

  • BTC++ can become a core asset for future Pie that need exposure to Bitcoin.

If this is the first time you are seeing this term, please refer to this article by @pintail. In summary, the impermanent loss is the loss in value when investing liquidity in a pool compared to just holding tokens.

Allocation without synthetic tokens

As for now, I’m considering 3 tokens to start with. In the future, multiple tokens could be considered such as renBTC, tBTC, pegnet BTC, etc.

Token Custodian Initial Allocation
wBTC wBTC Network 0.25
pBTC Provable Things 0.25
imBTC The tokenized Bitcoin 0.25
sBTC Synthetix 0.25

Screen Shot 2020-04-07 at 11.11.40 PM
Excel file

Usecase for traders

  • Arbitrageurs can easily profit by leveling market inefficiencies between DEXs and even CEXs on BTC coins by confidently keep exposure to BTC only in the pools.

  • Ethereum Smart Contracts seeking liquidity for a variety of other use cases (liquidation positions, trading, etc.) have a single point to look at for all their Bitcoin liquidity needs.

Proposed fees

Liquidity Provider DAO
0.2 0

[EDIT: removed DAO fees for now]


:no_good_man: put all your :egg: into a :basket:

Nice proposal, I like it.

Controlled exposure

Having multiple representations of BTC in a standard Balancer pool with trading enabled does not control exposure. You end up exposed with 100% of your assets in the pool to the failure of a single protocol.

Simplified example using Uniswap for some context:

Random centralised stable coin: RCSC

  • Alice add liquidity to a ETH/RCSC pool which keeps an even distribution of 50/50 in terms of value.
  • Bob steals RCSC minting keys, RCSC goes BRRR, driving the value to near zero.
  • Bob then dumps RCSC into the pool taking the Ether for free.
  • Alice loses both the value in ETH and RCSC suffering a permanent loss.

If Alice would have just hodld RCSC and ETH she would have only lost value of the RCSC.

These types of losses can be prevented by implementing a circuit breaker which stops accepting RCSC if the amount of the pool crosses a certain threshold relative to the totalSupply of the pool tokens.
This could break compatibility with the Balancer ecosystem however.

Liquidity fees

By default liquidity fees go to the liquidity providers. We can push an update to enable a fee going to the DAO but I think we should leave it out of the scope for the initial launch.

Having multiple representations of BTC in a standard Balancer pool with trading enabled does not control exposure.

This statement is only true in case of an asset failure.

Seems to defeat the purpose, users concerned about the failure of an asset should hedge by purchasing options or insurance.

This statement is only true in case of an asset failure.

Yes but its not controlled exposure as far as I can see. I’m not saying its a bad thing for the initial launch

Seems to defeat the purpose, users concerned about the failure of an asset should hedge by purchasing options or insurance.

Users holding BTC++ would need to insure themselves against failure of each of the underlying assets covering their entire share in the BTC++ pool for each of them. I’m not saying we should break compatibility or that It would necessarily be the case. A circuit breaker would be great as under normal circumstances it would not get triggered anyway.

BTC++ is a very smart approach as it spreads the risk among alternative solutions, each of those having unique features. Kudos! :clap:

Alice from pTokens here - if you want to know more about pBTC, happy to answer any questions.


Thanks @alicecorsini, 'm excited to have Thomas speaking tomorrow during the community call, personally I’m interested in the roadmap to decentralization of pBTC aka how do we get more nodes running.

1 Like

Can you discuss this idea with the balancer team so that we don’t break composability?

Sure, to be fair the EVM and solidity are a bigger basket, the Ethereum network even bigger, TCP and UPD even even bigger, internet cable even even even bigger, planet hearth the even even even even bigger. :rofl:


This is a key element for the pTokens system that we are actively working to roll out. We’ll be releasing more details in the coming weeks (Thomas will be discussing this tomorrow), but here is a sneak peek: https://www.youtube.com/watch?v=sIAT2-b4N1A&feature=youtu.be&t=1907

1 Like

Nice video, I like the iterative approach.

1 Like

About the circuit breaker, some suggestion from Fernando from Balancer:

  • Built in circuit breakers are coming in v2

Since PieDAO manages the pool we can monitor for funky stuff and stop trading as soon as we understand one asset is failing, in this regard the real-time Risk statistics explored by the discussion with Gauntlet Network would be helpful.

For now, there can be a DAO signed tx prepared to be broadcast with a huge gas price similar to Maker’s emergency shutdown.

This is fine because it just halts trade until you guys decide what to do

Will discuss with balancer team once I have a more concrete proposal.
Exposure to possible collapse of a single asset does not outweigh the generated revenue from being a liquidity provider in my opinion. So I think its fine for now.

Some risk can be prevented and some can’t. Having protection from the risk of an asset failing while still being able to generate fees from providing liquidity can be a selling point for the cash++ product. I don’t see how, other from being fun the matroesjka doll argument is applicable.

In light of the Maker situation with the unfortunate liquidation auctions I think we should think about how we phrase these products and communicate the possible risks they bring. The exposure is controlled price wise but the risk of failure is multiplied.

In terms of actionable steps I will continue development of the pool as it is now. And think about a proposal for circuit breakers and discuss it with the Balancer team.

It’s true the pool can be paused but most of these attacks can be executed within a single transaction making it impossible for the DAO to respond.

EDIT: Found out about circuit breakers in Balancer v2 so we’ll migrate to v2 when the time comes.

Great point, feel free to draft a risk report document that should be transparently linked in the frontend. From my side, I don’t think anybody here is trying to miscommunicate anything, would be great to have that by launch.

Generally speaking I don’t think there is a way to completely remove risk, the probability of one of those assets failing before there is a circuit breaker seems thin while possible. This is stuff for a Term of Service.

Chaosnet ethos makes sense to me as long everybody involved know their risk.


I agree. Shouldn’t a risk analysis be part of a proposal for a new Pie? I would rather focus on development instead of writing reports.

It’s not about trying to miscommunicate, the current phrasing of the proposal might be a little open for interpretation.

1 Like

A Uniswap alert type seems suffient.

1 Like

Do I have to lock this thread? :rofl:

You both make valid points. Let’s just agree that:

  • A balancer pool is quite literally a basket of different assets as are all PIEs
  • The meme was meant as a theoretical concept, not a literal one
  • Holding one asset is riskier than holding multiple assets
  • Using DeFi is inherently risky
  • The circuit breaker would be awesome and make the product less risky
  • We all know it’s important to stay compatible with Balancer
  • Also:


I’ll make sure the frontend has a risk disclosure.


I think it’s too much of a hassle for the end user to buy up to 3 individual insurances. It would be awesome if you could include that automatically in the BTC++ Pie. Haven’t found any service that is currently offering insurance on synthetic BTC. Maybe indirectly with options?

1 Like

We could open some options on a protocol like Opyn. Finding liquidity for those might be an obstacle.

I like the idea of embedded insurance, it’s a bit of a complicated product tho, from an operational perspective I think it might work like this.

There is a iBTC++ Pie (i == insurance) which only holds the insurance positions following the weights, when people are minting/buying BTC++ there is a checkbox saying something like:

:white_square_button: Add insurance to this 0.4 BTC++ position.

Basically you would receive a BTC++ + iBTC++, assuming liquidity is enough to insure large positions they could be put together in a single token. Thoughs?

1 Like

With regards to possible risks regarding collapse of one of the underlying assets.

Currently Balancer does not support circuit breakers but they plan to support them in V2 which is expected to launch in 2021.

After some discussion with the core contributors I propose the following intermediate solutions in this order:

  1. We implement a bot which watches the prices of the underlying assets on decentralised exchanges and immediately halt trading if one of those assets has a fast decline in price.

  2. We offer a Pie which includes insurance through options like Alessio suggested and possibly let the DAO provide the liquidity needed to offer them. These options would insure the underlying value of the pool in BTC.

  3. We work together with the balancer team to speed up the development of the circuit breaker without breaking compatibility. And migrate the pool to a complete Balancer V2 implementation when that launches.

I feel comfortable this would sufficiently cover the risks associated.