EIP-14: User Defined Coupon Expiry

Background:

Many have argued in some form that with the current way of couponing, there is not enough incentive for coupons with a fixed 90 epoch expiry.

Solution:

One way to address this is to allow for users to define their own expiry in multiples of the 90 epoch, such that longer dated expiration have less premium attached to them than shorter dated ones to compensate for less expiry risk.

I could see it working similarly to the existing mechanism for premium calculation multiplied by some decay factor that incorporates the min epoch multiplier. I’ve used some natural log decay, but any other decay would work fine.

I’m willing to admit that even something like this might not be enough, but perhaps it can lower the barrier for coupon entry and encourage more usage.

For example if someone entered 0 for epoch, they would have a premium multiplier of 1.0 (no change from existing), 90 more epochs -> 0.76146285961466 premium multiplier (180 epoch expiry), 180 more epochs (270 epoch expiry), 0.4088137485493062 premium multiplier.

There’s probably some egregious error in this implementation, so feel free to shoot holes in this: https://github.com/emptysetsquad/dollar/compare/master...cinquemb:master

4 Likes

Nicely done @cinquemb!! Proposal and code ftw (I haven’t reviewed the code or the tests though).

My personal concern with this is that it removes urgency from the coupon side, and adds complexity to an already hard to evaluate mechanism. There is a fork out there with 365 day expiration, and I really have my doubts about how that is going to work. So there is my bias, I guess.

In addition this side of the system is going to be heavily reworked in V2. Unless maybe they (the v2 team) are still evaluating iterations on our coupon system, my own personal opinion is that I’m not sure ESD needs to iterate on something that, as yet, hasn’t failed, and would add code complexity and UX complexity to something that is going to change in the next 6 months or so.

1 Like

Thanks for checking this out @Mike!

There is a fork out there with 365 day expiration, and I really have my doubts about how that is going to work. So there is my bias, I guess.

Yeah, I don’t think fixed expiry incentives are very good (short or long dated), nor something like a zero coupon bond (locks the protocol potentially with debt for indeterminate amount of time).

and adds complexity to an already hard to evaluate mechanism.

I think the complexity argument is fair, though I think a maturity based premium curve would reflect the complexity and risk preference of many different market participants at the same time as well as their confidence with getting back to peg which is not reflected now at all.

would add code complexity and UX complexity to something that is going to change in the next 6 months or so.

Arguably, less complexity (assuming what I implemented works like this) than the zero coupon bond proposal I’ve see in EIP-7 and the coupon auctioning method mentioned in v2.

I get that all of these are ways to try to make the price more stable (I definitely want it to be more stable so I can make loans denominated in ESD in the real world and not be in the position of risking +/- 2000 bps for +/- 100-500bps), but I think the market participants needs to set the rates, duration, premium and risk they’re willing to accept and allowing more flexibility from participants to choose what they want would be helpful for everyone and not fall into the assumption that the DAO can control everything (like people think CB’s can control everything).

Every hard-coded rate, maturity, premium, or lock duration will have unintended consequences on participant behavior, so yeah, I’m firmly not in the camp of more of that and more in the camp of designing things such that incentives in the market place are maximized so that the market makes people more money staying as close to peg as possible.

1 Like

From https://discord.com/channels/752342816033603624/752343180296323122/794773284209819709:

"I tend to not like the rigidity of predefined curves. I tend to prefer market-based discovery whenever possible.

E.g., I could see an auction mechanism being useful. Where users submit expiry/premium pairs as “offers”.

Sort the offers by lowest premium first, and break ties by shortest expiry (I have to think about that more).

Protocol keeps taking offers until enough ESD has been offered to bring the price back up to $1 (and everyone has had time to submit their bids).

Then offers are cleared in order until the price is back to $1. All remaining offers are revoked."

From: https://discord.com/channels/752342816033603624/762432915224657941/794779303484981248

“The way the auction would work is you let everyone who’s interested in bidding submit an amount of ESD they are willing to burn into coupons and the minimum yield they’re willing to accept. Surely you’ll get people interested in putting in bids at some yield (400%/30 days? I’ll take it right now). People will lock their ESD in the auction contract when they bid until the auction time. At the auction time the contract will figure the lowest yield (clearing yield) which will result in the sale of the target amount of coupons. Everybody gets the same yield (what they bid or better). People who bid a lower yield get priority in filling the auction. If the auction fails (unlikely) just carry over the unsold coupons to the next epoch’s auction. Unburned ESD gets refunded to bidders.”

PR here of final version: [Proposal] 17: User Defined Coupon Expiry w/ FPSBA by cinquemb · Pull Request #16 · emptysetsquad/dollar · GitHub

I think ALERT should be raised for this proposal. As it is explained in discord, there is no hard cap for the premium in the auction system. This means one can win 100K coupon with 1 ESD as long as the total amount of bids is less than the debt level in one auction. Personally I think many people will walk away from this project if someone can actually do such a thing—it is actually possible especially after this proposal is just implemented (the current debt is 100 million ESD).

IMO, the natural premium in each epoch can be used as a hard cap. If you extend your expiration beyond 90 epochs, you get less premium. Without a hard cap of premium, the auction system will just become a harvest machine for the professional gamers to get all the coupon in each epoch with probably zero cost if competition is missing. It is not only unfair but also very dangerous for the long-term run of this project.

This makes the assumption that someone burning 1 ESD for 100k or 1M or x coupons is sufficient for driving up the price of ESD, it is not. It also assumes that all coupons would be available for immediately redemption when twap > 1 (which currently isn’t the case)

the natural premium in each epoch can be used as a hard cap

This is hardly “natural”, its a predefined curve not determined by the market.

Without a hard cap of premium, the auction system will just become a harvest machine for the professional gamers to get all the coupon in each epoch with probably zero cost if competition is missing.

There’s no cap on coupons in an epoch with this auction, only the esd debt, if such a thing happens under this scenario you are most afraid of, then its more likely the auction would get canceled and no coupons will be assigned from all the people speculative coming in trying to get 10 billion coupons for 1ESD.