PIP 8 - Proposed modification to BTC++ Allocation

Relaying the proposal from Mike in Discord.

Hey all tried to submit this proposal via Forum but access was denied. Any ideas? Also happy to modify given the current convo.

Adding renBTC to BTC ++ Proposal renBTC is a tokenized representation of BTC on the Ethereum blockchain. It is an ERC20, backed 1:1 with real BTC, and is redeemable at any time for real BTC. renBTC is a product of Ren:

RenVM https://etherscan.io/token/0xEB4C2781e4ebA804CE9a9803C67d0893436bB27D
Wiki & Github: https://github.com/renproject/ren/wiki
RenVM Contracts: https://docs.renproject.io/developers/docs/deployed-contracts
RenVM Network Center: https://mainnet.renproject.io/

Token Custodian Proposed Allocation

wBTC wBTC Network 0.20
pBTC Provable Things 0.20
imBTC tokenized 0.20
sBTC Synthetix 0.20
renBTC Ren 0.20

64.93 / 4 = 16.232 BTC per 25%
64.93 / 5 = 12.986 BTC per 20% *3.246 BTC reduction per allocation

Happy to modify this proposal to meet the team’s requirements and/or satisfy other proposed approaches. This is just an initial submission to get the convo started. Further, RenVM and by virtue renBTC can facilitate a native BTC to BTC ++ on-ramp, so glad to pursue this here or in a separate proposal.

4 Likes

I think that now would be a good time to revisit both the overall goal of BTC++ as well as the allocation of the pie.

Question about the goal of BTC++

What is the goal of BTC++? Is it to minimize risk for BTC++ token holders compared to holding just one form of tokenized BTC? If that is the case, I think the original point made by @mickdegraaf in the original thread still stands and should be re-examined. A personal question that I have is what is the fundamental rationale for using Balancer and having tradable pies, as opposed to having a system closer to that of an index fund? Is the idea to incentivize people to mint BTC++ by offering the Balancer trading fees?

Allocation of BTC++ underlying assets

Several people on the Discord have taken issue with the presence of imBTC and pBTC in the BTC++ pool. Some of the reasons highlighted by members include the lack of on-chain liquidity for these tokens and the recency of their deployment. In the following, I will suggest a draft framework for BTC++ allocation.

First, I assume that BTC++ should aim for the following:

  • Risk minimization: users become holders of BTC++ because they want to gain exposure to Bitcoin price action on the Ethereum blockchain, while minimizing the risk of failure by holding only one representation of Bitcoin

  • On-chain liquidity: it should be easy for users to enter or exit a BTC position on-chain. That is, even if one of the underlying tokenized BTC can “easily” be minted (resp. redeemed) from (resp. to) the Bitcoin blockchain, this incurs more steps, more fees, and is more time consuming: redeem BTC++ for underlying tokens -> redeem tokens to the Bitcoin blockchain -> transfer BTC obtained to an exchange -> sell BTC. As such, arbitrage becomes cumbersome and potential users might find this offer more risky than simply holding one liquid asset. My suggestion is thus that on-chain liquidity, i.e. the ability to directly sell the tokenized BTC an Ethereum DEX should be part of the criteria.

From there, I suggest that we should work on a scoring system in the same spirit that what was used for USD++ V2 when considering the allocation of the underlying tokenized representations of BTC. Here are some possible parameters of such scoring system:

  • Synthetic vs. backed
  • Trust minimizing? (composite of auditable balance, audited code, fully open source or not)
  • Track record (TVL over time)
  • On-chain liquidity (relative to total holdings of the Pie)

I’m not sure about the exact weights yet, although I have a subjective, qualitative preference. We can look at some of the different alternatives of tokenized BTC on that basis.

sBTC:

Synthetic asset overcollateralized at 750% by SNX, a volatile asset as of writing this. To my knowledge, the underlying contract is audited, verified on Etherscan, and the owner is 0x000000. This asset is relatively liquid compared to the BTC++ cap thanks the the sBTC curve pool.

wBTC:

WBTC is a physically backed BTC representation. It is operated by a consortium of industry actors and the supply is auditable on-chain. The Ethereum contracts have been audited a year and a half ago. The token has a relatively long track record of a large value locked without a hack. It requires trust in the consortium, or in the fact that members of the consortium won’t be compelled by authorities to blacklist some addresses. There is a very large liquidity across Ethereum DEXs.

pBTC:

pBTC is a very new token from the Kyber team. It aims to become decentralized in the future, but although audited by one company, the protocol is currently operated by only one node with closed source code and it is not clear to me how to easily verify that the Bitcoin Balance held by the custodian equals that of circulating pBTC. It is also highly illiquid on-chain with only ~39 pBTC in circulation.

imBTC:

imBTC is very new and supported by a fully centralized tokenized BTC provider called Tokenlon. It is supposedly 100% backed by BTC. It is claimed that the imBTC contracts have been audited but no link can be found to such audits. It isn’t clear to me how to verify the underlying BTC reservers.

renBTC:

renBTC is a new entrant that aims to be a decentralized, trustless tokenized BTC solution using a novel sMPC algorithm, a novel sMPC optimized consensus method, a novel P2P networking layer. The renBTC token contracts have been audited, but the clients are still under audit and close source, so there is still quite a lot of trust involved. The BTC backing the tokens can be audited at this Bitcoin address..

tBTC: (unreleased)

tBTC also aims to be decentralized and trustless. It is not released yet. It uses established cryptographic and networking primitives to secure Bitcoin deposits. The code is fully open source and audited. It is not released yet but I am including it for future discussions.

Considering all of the above, my subjective and qualitative proposal for allocation would look something like this:

60% WBTC
30% sBTC
10% renBTC

Or maybe we are not comfortable with synthetic assets and we only want physically backed BTC?

If/when pBTC and imBTC get more liquidity / audits / clout, they would be slowly added. Similarly, once TBTC is released and running for at least a few weeks without issue, it would be added in a proportion similar to that of renBTC (but slightly more since it’s fully open source). Months from now when renBTC and tBTC will have been running for a while and are both fully open source, I think it could shift to something like this:

20% WBTC
10% sBTC
30% renBTC
40% TBTC

Anyway, this is all very indicative, I just want to start a broader discussion. We should focus on a “proper” scoring rule first.

2 Likes