Since this is the first alternative asset for bnUSD minting on Balanced, I feel it’s best to be very conservative and treat this like a test run. If things proceed smoothly, the debt ceiling, borrow LTV, and liquidation LTV can be adjusted later on to match or exceed sICX’s offering (since BTC is a less-volatile asset).
Please let me know if you have thoughts on the proposed details.
I’d agree with the proposal with just a one proposed change.
Because of how liquidations work on Balanced, I’d propose to keep the liquidation ratio consistent at 85%. The current liquidation logic doesn’t return any leftover collateral to the borrower. At 75%, that would imply a 25% penalty to the borrower which I think is too harsh. Rather than adjusting the liquidation logic, I think a 15% penalty is fair for most (if not all) collateral types.
At some point, we can work on changing the liquidation logic for a fixed 10% fee to the borrower and sweep any leftovers to their account, but not a priority imo.
I’d also be open to a higher debt ceiling, but no strong opinion there.
I think most values seem fine. Could do with a higher debt ceiling and a Liquidation LTV of 85. I like the Locking ration of 20% almost guaranteeing we wont see any liquidations of BTC very soon, need to give the ones running bots time to adapt.
I am buzzing! This is an exciting step for Icon and Balanced. I like your proposal, but would also like to see @benny_options suggested change made.
I have been championing the idea of a stable coin backed by bitcoin for a long time! Nice to see something come into fruition on Icon/Balanced, kudos to the devs/team who are busting their chops building this for us.
Ideally in the future I’d prefer to see trustless Bitcoin bridged onto Icon, and then used as collateral in Balanced. Until then (if it’s ever possible), I think using a Binance chain backed Bitcoin is a very exciting idea (my understanding is we can’t have trustless Bitcoin atm because Bitcoin lacks complex smart contract functionality).
It would be great for us all to have an open discussion about the risks that are inherent in this new bridged Bitcoin. How it could negatively affect Balanced? Do we have more/new flash loan risks? We’re adding new smart contract risk (from the Bitcoin), and no doubt other things.
This update also added the ability to add dex priced assets. This is where we would be very vulnerable to flash loan attacks and similar. Which is why i would be against such a collateral.
With a oracle priced asset we have the “attack” vector of wrong oracle prices.
But with all collateral’s there is smart contract risk. Where the risk is usually infinite mint problems. Which is why the debt ceilings has been introduced. Which we can raise incrementally so a malicious actor can only steal up to the ceiling.
So for BTC and mabye later ETH we are putting trust in the foundation/bridge team. Which i am fine with for the moment. And even more fine with after the audit is complete.
So for risks in the beginning i would like to see us having lower debt ceilings that what we would be able to retire from the reserve/daofund in case of a infinite mint.
Also don’t need to worry to much about bscBTC (on BNB side) being hacked i think. Since there a currently a lot larger platforms to attack with that power.
From what I see, yield often trumps trust.
Yield will have to outperform the existing options for decentralized BTC yield to attract capital from outside our ecosystem. Otherwise it will only be used by existing Balanced users wanting to diversify.
The infinite mint issue was recently showcased when Acala added Interlay BTC as collateral and a bug in the iBTC:aUSD pool got exploited.
We have a DAO fund sitting at $1.6M value, which is a good buffer to combat exploits when a debt ceiling is in place. Of course when more and more assets are being added the DAO fund in itself may not be sufficient, but not all collateral options will be exploited at the same time either.
250,000 bnUSD represents 16% of our current DAO fund value. Seems fine to me.
Liquidation ratio is not really set in percentages it set in ratio which is 11765=85% so just some rounding being handled differently when reading and setting the proposal i think. Will double check with frontend team