It accepts bitcoin as collateral, allows emitting or borrowing USDK against it, an ICRC stablecoin, and the protocol appropriates your collateral if its value falls below your outstanding loan.
The principle is simple: each USDK is backed at least 1 to 1 with a dollar worth of bitcoin at all times.
It is not a demo, but rather more of an applied-research prototype that although is by no means intended to be secure, includes several security features, themselves prototypes of the real thing, and a realistic data structure and processes: it serves not primarily for display but as groundwork for the real thing.
Sincere thanks to each of the many people who have helped here on the forum, on Discord, and on Github with a large number and wide breath of questions and issues.
Not yet open source but will be before launch. If there’s interest and if all security concerns can be ironed out, I expect that will happen this year. Ideally much sooner but I’m aware of the time audits and thinking everything through can take. There have been many unexpected surprises so far.
Happy to talk about the code or advice from what I’ve gathered if of any use.
You were one of the first people who helped me by the way. I couldn’t have gotten the initial prototype going without fixing the Basic Bitcoin example, which you alerted people about and it got done. Appreciated.
When i Pay Back USDK by sending USDK to kobvp-jyaaa-aaaag-qbw3a-cai2p-bravr-7d5ft-a5oug-6ezfp-roor6-m43nn-kfbz3-kw35r-rzdeu-rzyaq-h6,It can work in DAPP
From ICLight Wallet to Pay-Back address :Transfer fail
From Bitfinity wallet to Pay-Back address : Fail to transfer token
How to convert Pay-Back address to a supported address format for ICLight Wallet , Bitfinity and so on?
I hope that the data can be updated dynamically in real time on the web page,
and that the mechanism such as collateral is more permission-free, more automated, and more convenient to use
Yes, unfortunately third party wallets don’t support sending tokens to accounts of non-null subaccount. This is necessary for the protocol because all accounts are controlled by a single canister, meaning they have a single “owner”—the canister, and therefore the only possible differentiator is the subaccount.
But it is only provisory, not integrated to those wallets, and I believe is changing officially this month / week, if it wasn’t decided in the last working group meeting.
The feature to send to those wallets is the best the ecosystem supports today. No transfer back supported by them yet.
so this depends on them really.
What do you mean by this? The data should update dynamically though at bitcoin speed, and everything is permissionless. It can take ~50 seconds to fully load all the user’s data and balances (it checks through the IC’s bitcoin integration, not via a call to an explorer), and then, if you stay on the site everything keeps updating every 10-20 seconds. If you see different behaviour please let me know.
I am wondering how it works. I can imagine one sends the contract BTC and borrows (overcollateralized)
USDK for 70% of the current BTC value. In the event that the BTC price drops, the contract I suppose should sell the BTC for USD so USDK doesn’t depeg? How does it sell it if there isn’t USD in IC, perhaps it’s using IC Chain-key signatures & Ethereum or sells it for Cycles? Or is it supposed to depeg.
You’re right in that this prototype only includes the most central pieces in a simplified form, but is missing other key pieces including a redemption mechanism, which is what enforces the peg: without getting into too much detail the way it works is that you’re able to redeem, for a small fee, one USDK for one dollar worth of bitcoin, bitcoin which is taken from a stability pool or otherwise from other borrowers’ collateral, which (in normal situations and again without getting too deep into the weeds) very slightly reduces everyone’s collateral and correspondingly and proportionately partially repays their debt.
If you’re interested in details, the main inspiration for this design comes from this protocol: GitHub - liquity/dev: Liquity monorepo containing the contracts, SDK and Dev UI frontend., though Backed USD won’t be a direct implementation or pure adaptation of it on the IC. There are a couple of substantive design differences, in exploratory phase, none of which are currently firmly decided on, primarily with a view to, if possible to do securely, further simplify that already elegant protocol.
From README.md “Stability is maintained via economically-driven user interactions and arbitrage, rather than by active governance or monetary interventions. The protocol has built-in incentives that encourage both early adoption and the operation of multiple front ends, enhancing decentralization.”
When market or environmental problems or other problems occur ( for example 1, 2 …), which affect user interactions and arbitrage, when it is necessary to automatically or gradually automatically adjust the mechanism according to the changes in the market or environment, so as to maintain relatively better stability,
Then active efficient governance or monetary interventions are needed ，In order to form a resultant force!
Also considering regulatory, legal and other issues ( for example 1 …), we may need SNS1 communities or others to cooperate in multiple ways, SNS1 communities in some cases are decentralized agent (something like NNS and Named Neurons,SNS1 communities could be
Named Neuron )
SO WE are a community of interests or destiny to improve efficiency and reduce costs, and help eacjh other to stimulate incentives, adoption, and more!