SIP-0012: Provide treasury funds to FastBTC

We recently reactivated an improved version of FastBTC to allow for quick and simple user onboarding. At this point, FastBTC is limited to 0.01 BTC per transaction, because of missing liquidity. It is proposed to provide 100 BTC from the Origin BTC Multisig Wallet to FastBTC to be able to lift the limitations.

More details are here: SIP-0012 - Google Docs

Update: there is now a PR for this SIP

5 Likes

Hi @Ororo can you please provide more information about how FastBTC works?

  • What is the source code of the FastBTC RSK contract? It hasn’t been verified yet in the RSK explorer.
  • Who controls the FastBTC contract? Who can upgrade it, if it is upgradeable, and who can withdraw funds from it?
  • What happens to the BTC collected by FastBTC and how is it secured?
  • The SIP mentions that FastBTC earns fees. What is the value of these fees and where do the fees go?

Edit: General observation, this is about half of the BTC raised in the Origin sale. Personally I am wary of having that much of the treasury in any sort of external system. But I could be convinced otherwise if I see the risk/reward tradeoff is worth it.

12 Likes

Why would we use the Origin BTC Wallet?

Hey, I agree with @light in terms of more transparency in how this would then be handled. Conceptually I would 100% agree that having more liquidity to onboard users is critical but the process needs to be clear. You would have all those rBTC in the fastbtc bridge that would move from an rBTC account to a multisig bitcoin wallet I guess and then, if you run out of liquidity on one side either rbtc or Btc, you would need someone to activate a rebalancing moving money through the RSK bridge.
It would be good if that process is detailed.

4 Likes

My first concern after reading the proposal is that I think more details are required as my immediate concerns are:

Is the FastBTC contract secure enough to be trusted with 100btc?

What is the end result to the fees generated?

Can we have more information on the FastBTC contract. I’ve tried to find info but as of now I’ve found nothing of significance.

What happens to the BTC acquired by the FastBTC contract?

100 Btc held in the FastBTC contract seems a tad excessive, as @light pointed out that is a hefty sum of the origin sale funds ,however, that being said I am acutely aware that RBTC is a massive barrier of entry to the project currently and it needs to addressed as soon as possible.

I think this proposal is extremely close to solving that issue but in my opinion more details would assist in casting an informed vote.

6 Likes

I agree with the sentiments expressed above. I think we should add the details requested to the Sovryn Wiki, which should also include ongoing updates as to the amounts transferred over the 2-way peg, and amounts that remain in the Exchequer multisig. This could be done by referencing the contract addresses involved. The SIP should specific the location of the this information and the frequency in which it is updated (I suggest weekly).

3 Likes

Excellent suggestion.

Why would we use the Origin BTC Wallet?

That refers to where the funds are currently held.

whatever the amount of BTC that is held, should in my opinion also be coinjoined. there will be a steady stream of BTC into the platform, and less exiting. in the middle instead of sitting in the wallet i think they should be mixing. Sovryn is about self sovereignty and privacy, i think this would be something worth considering

2 Likes

Sure. I was already expecting these sorts of questions, but was too much in a hurry when writing the SIP :wink:

What is the source code of the FastBTC RSK contract? It hasn’t been verified yet in the RSK explorer.

It is here: https://github.com/DistributedCollective/ManagedWallet/blob/master/contracts/ManagedWallet.sol and being verified on the RSK explorer while I’m writing this reply.

Who controls the FastBTC contract? Who can upgrade it, if it is upgradeable, and who can withdraw funds from it?

It is a very simplistic, non-upgradable contract. It just knows 2 roles: owner and admin. Both can withdraw funds from the contract. The owner can additionally replace the admin. The bitocracy is acting as the owner and a 3 out of 5 multisig is set as admin (0x0f279e810b95e0d425622b9b40d7bcd0b5c4b19d). The key holders are active team members (whose tokens could be slashed by governance in case of misbehaviour) and early funders.

What happens to the BTC collected by FastBTC and how is it secured?

For each user a unique deposit address is derived from a multisig, which has the same keyholders as the multisig on RSK. Therefore these keyholders have the sole access to the funds. If liquidity on RSK is running low, the funds need to be transfered via the RSK 2-way-peg in order to refill the contract.

The SIP mentions that FastBTC earns fees. What is the value of these fees and where do the fees go?

The fee is currently set to 5000 sats, but it would be better to have a fee in % of the transferred amount with a minimum of 5000 sats (to cover tx fees). The height of the % as well as the minimum fee could be part of this SIP or a separate one. Suggestions?

The fees are being accumulated on the BTC multisig.

I’m going to update the SIP to reflect this information in a bit.

2 Likes

I agree, I will provide the necessary information to the wiki team.

One more note regarding the ongoing transfers over the 2-way-peg: Because of the way the RSK 2-way-peg is designed, the multisig cannot send the funds over the peg directly, but we need to use a single private key. This means that for a time period of 24h the assets to be transferred are being controlled by a single person. This is why the amount is to be transferred in batches and the person(s) in charge should be slashable by governance in case of misbehaviour (and therefore have enough at stake).

1 Like

I think we can leave it to the FastBTC admins to set the fee and if SOV holders have strong feelings about what the fee should be then they could pass a SIP to set a different fee. Whatever the fee is though, it should be transparent. And in this SIP I would say something like “The fee is currently X but is subject to change based on market conditions.”

there is now a PR for this SIP

I was following until here: 🥸🧐?

“This means that for a time period of 24h the assets to be transferred are being controlled by a single person. This is why the amount is to be transferred in batches and the person(s) in charge should be slashable by governance in case of misbehaviour (and therefore have enough at stake).”

——————————————-

Im gonna have to ask…doesn’t this go against important decentralization standards?

Will user be able to trust the peg with such a glaring single p of f?

The f being the fact that the whole 100btc being proposed, is being transferred to a private person with full control for a whole 24 hr period. I mean, It only takes a few seconds, maybe less, for that whole 100btc to be stolen and what about the safety of this key development team member? How many other key developers will know who this person is and when they’ve received this transaction and the control of the 100btc?

If this proposal is to be actually accepted

maybe refine and decentralize the ongoing transfer contract, making certain there is an actual 2-way peg without the proposed “crutch” 24hr period.
Because…
What if liquidity is 1000btc in the future? What if liquidity is 10000btc in the future? This person gets everyone’s liquidity offering in their hands for a full 24hrs?

Will the governance provide protections and insurance for the funds and for this key developer who magically gets everyone’s money?

Isn’t it true that at an any level of liquidity this kind of flaw is not really responsible in a decentralized market? I mean, especially one named soveryn after individuals who never lost ownership of their lands and assets. Yet in this proposed system, one seemingly “super sovryn” gets all the other soveryns contributions for a whole day and night…? I feel this is definitely not right.

I think Sovryns should be comfortable in the pool and know that it’s going to grow exponentially and that they can sleep well because they’re able to trust verifiable, well-tested code, and not have to go back to establishing fragile human trust. :pray:

2 Likes

I agree that this is not pretty, but it’s a limitation of the RSK 2-way-peg, which is the only way to get larger sums of RBTC onto the system, and there is nothing we can do about it.

That’s why the amount is to be transfered in batches and not at once and the person in charge has to have sufficient SOV at stake.

1 Like

This limitation, amongst others, is one of the main reasons why we are building our own BTC peg. (and I’m not speaking of fastBTC which is here to satisfy the immediate needs, but not to stay long-term)

4 Likes

I agree that it is frightening from a centralization perspective, I hope that it could be altered to be more decentralized in a truly “soveryn” way but it seems that we are limited because of the RSK peg so maybe this temporary solution is all we have at the moment. Is there an ETA on Soveryn Btc peg?

I hope, we’ll ask everyone to help us test the system on testnet next week!

1 Like

Regarding the process for sending batches from the multisig…

Will there be a mechanism to ensure that the funds of batch n have arrived safely in their final destination before batch n+1 is released?

I would like to know, why 100 BTC?
What lead you up to this number, or is it just an arbitrary amount?

Also I think that another extremely important thing is that we have enough liquidity on the DAPP itself.

Both the bridges and the dapp itself need to have sufficient liquidity for things to run smoothly, and for that reason I think that we should talk about both supplying Liq onto FastBTC and providing liquidity on the Sovryn trading platform. Before allocating a massive chunk to one with no discussed plans for the latter.

1 Like