-
Notifications
You must be signed in to change notification settings - Fork 137
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
[Proposal] 17: User Defined Coupon Expiry w/ FPSBA #16
base: master
Are you sure you want to change the base?
[Proposal] 17: User Defined Coupon Expiry w/ FPSBA #16
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
|
I'd change this minimum Euclidean distance. Shorter expiry is riskier, therefore it has first priority (probability of getting paid after expiry is 0 with 100% confidence). Thereafter, ties should be sorted by the lowest premium. I understand this would totally change this proposal. Still, think it is worth pointing it out. |
I was trying avoid sorting twice and it was simpler for me to weight the importance of both lowest yield and lowest expiry equally. Feel free to implement that sorting algo. |
…ce calcs, starting adding tests for new state/setter/getter functions
)) |
…started tests for auction stuff from regulator tests
…s untill total redeembale is emptied - need to make total redeemable a function of previous non dead auction internals
Is there also a web 3 provider? |
And is it possible for 0? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wauw....very good work! Thnx for all your effort...and also quick! Can we maybe test if it works properly ?
Summary
Description
An auction is initiated for every epoch, during that epoch people may place bids -> {how much they want to pay, max coupons they want to buy, the epoch they want coupon to expire}. Bids that exceed the max coupon to token ratio are rejected immediately. Tokens that are in the wallets at the time of bidding, but not by the time of settlement are ignored and not filled.
At the end of the epoch:
if TWAP > 1, the auction is canceled, coupons are auto-redeemed in order of placement in prior auctions that were successfully settled (i.e first place winners in each auction first, then second place, etc until redemption pool is empty). Rate of expansion is determined by prior auction internals (inverse of avg of the avg yields of the individual auctions that still have non expired coupons in them, this will allow for market driven dynamics to determine the rate of token growth), not by hard-coding in the protocol.
if TWAP < 1, the auction is settled and coupons assigned in order and tracked on chain within an auction based on min euclidean distance of yield and expiry (i.e. the person that submitted the smallest yield, smallest expiry gets filled first and the most amount of esd they are willing to burn) until all are filled, the next auction is created.
Tests have been implemented for coupon bid and auction settlement (auto-redemption tests are in progress). Thanks to everyone for helping me flesh this out in the discord conversations.
Tracking
Status: Pre-proposal
Implementation: