-
Notifications
You must be signed in to change notification settings - Fork 408
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HIP18: Remove Oracle Forecast for DC Burn #65
Comments
I like this. It is an elegant solutions to the arbitration opportunity. One suggest for @lthiery - add some more detail about what "dynamic oracle price" means in the Solution section and how it would be implemented. I am assuming this means that a new oracle price (specifically for token burn only) would be calculated immediate upon receiving an oracle update rather than delaying 60 minutes. |
Did this HIP get consensus / voted on yet, and passed I hope? |
Rough consensus has been achieved on this proposal and I'll be marking it as approved. On behalf of the community I'm also requesting the core development team begin any necessary engineering work. This proposal has received nearly unanimous support from the community, and is debatably a "bug fix" that did not require a HIP at all. I applaud @lthiery and Helium Inc for submitting it through this process anyway, since it has been valuable to discuss and improve it in the open. In informal Discord polling, 30/31 voters (97%) voted yes to approving this. The one Rough timeline:
|
Author(s): @lthiery
Initial PR: #62
Start Date: 2020-10-28
Category: Technical
Rendered view:
https://github.com/helium/HIP/blob/master/0018-remove-oracle-forecast-for-dc-burn.md
Summary:
A new oracle price takes effect one hour in the future, to provide users with predictability when converting HNT to DC. Unfortunately, this delay provides an on-chain arbitrage opportunity via state channels. Given the delay, an actor with HNT in-hand may see the forecasted drop in HNT price and thus convert HNT into DCs. After the drop takes effect, the actor may then “spend” the DCs in a state channel, naming a colluding gateway of theirs as the beneficiary. Effectively, the actor is burning and minting HNT on-chain at a profit with very little risk. This HIP seeks to address this flaw.
The text was updated successfully, but these errors were encountered: