The peg between $1 and $1.10 is soft. The only real way to arb DLLR above $1 directly is to mint it and then sell it and hope that it drops in value. But that’s not very attractive if origination fees are high because you pay more in origination fees than you can earn from arbing.
I don’t disagree about considering the long-term health of Zero for stakers. You just need to make sure other stakers feel the way you do.
Well, i wont ramble further, but i absolutely could. I look forward to hearing the results of you and the teams’ considerations and discussions on this all important topic, which seemed to have fallen by the wayside for basically no explainable reason other than turning our attention to the next shiny object or “silver bullet” in bitcoinos
Updated view / ramble: i would agree to SP distributions up to 2.5%, on todays origination fee of 5%. Maybe we can have a dynamic between the origination fee and the SP distribution, but for sure i think we would want to reduce the origination fee to offset this new supplementary component of the origination fee increasing the fee by (in this example) 2.5%, or potentially reduce it further if we want originations to be sub 5% in the long term
Yes, this is considerably reducing the IMMEDIATE revenue share implications for stakers, but clearly offering much greater long term potential for ludicrously good revenue share if the product takes off, which it will if we design it for the user. And to all detractors i would simply say 1>0 is it not.
As per Onedigits implicit suggestions, maybe this could sustain zero at a minimum viable success story level for liquidations to be brought into the fold and make the stability pool an attractive proposition - while avoiding the risk of origination fees having to scale in line with usage to meet the stability pool APR as the pool grows. To enforce this, i believe we should implement Onedigits SP distributions and cap the distributions at a level which would be subject to discussion, for me it would be around 2.5% given this is supplementary to SOV staker origination fee revenue. As suggested alternatively we could implement a dynamic between the SP distribution and origination fee and hone in more on the origination fee.
Perhaps in this case we could also implement a minimum SP distribution of 1% for example when looking at a much lower origination fee lets say 2%. Perhaps my understanding is too simple but i also see that maybe even just the 1% distribution to the stability pool could sustain a great APR even as the pool grows if origination volumes increase in line with stability pool capital, which doesnt seem to be factored here. Zero is the front of house product, perhaps im too idealistic in hoping the same if not a larger number of people are using zero loans. But if we design the product to delight the end user i dont believe it is idealistic at all
The fee for the SP providers could really be divided in 2 half fees, the origination and the redemption.
While the origination fee would create incentive for people to after open the credit line, to deposit in the SP,
The Redemption fee would create incentive for people not leave the SP. because once they do redemption their Zusd, they no longer get the other half fee because they left the SP earlier.
That’s a great observation!
I think it would be good if we had a specific formula for updating the origination fee so that we don’t have to SIP over and over again. Here’s just an idea of how we might define that.
Let’s say we start with a 5% total origination fee. Let’s also make the minimum origination fee to stakers 2.5%. Every month we update the origination fee so that it would yield a 20% return based on the previous month’s origination volume and stability pool balance. Let’s call this the current stability pool origination fee (SPOF). As long as that fee is less than 2.5%, we take the SPOF out of the existing 5% origination fee and send the rest to stakers. However, if the required SPOF rises above 2.5%, we add the minimum staker origination fee (2.5%) to the SPOF and reset the total origination fee to 2.5% + SPOF (which is higher than 5% total).
This would have the advantage of simultaneously creating demand in the SP and lowering the incentive for new supply (borrowing) due to the higher origination fee.
We could also look at longer-term liquidation gains (let’s say 6 months) and factor that into the total APR in the stability pool for a 20% target. If liquidation gains alone rise above 20%, then we set the SPOF to 0%.
Another formulaic modification would be to set the target APR to double the APR paid on rUSDT in the protocol. We could use whatever value that is each month to do the calculation for the target rather than using 20%. That would provide market-based adjustments to the target interest rate. (For reference, interest on rUSDT is currently 9.41%, which would give us a target of 18.82% instead of 20%.)
Thoughts?
I was really impressed with this idea. So kind of like a daily TWAP of stability pool APR averaged over 1 month, the previous month? Gving the SPOF needed for 2x RUSDT / 20% APR for the next 30 days. It reminds me of how they calculate the 8 hour funding rate on the perpetual swap. Never-ending stability pool APR is genius if it can work
Then if SPOF is less than 2.5% set it there, if it is more, reset origination fee to the minimum 2.5% + SPOF needed to hit the target? Origination fee goes up, borrowing goes down, while maybe more zero loans are deposited to stability pool to take advantage of the higher SPOF? How does origination fee go back down in that case? More quiet volumes, less new loans, and yet SPOF continuing to rise, and set origination fee higher? In any case i believe in your idea a cap should be set on the origination fee to enforce things and not rely so much on basic incentives
When i see arbitrary 20% APR even through well designed system mechanics i just think of UST to be honest. 20% is very high. Maybe 2x RUSDT or even a lower arbitrary number like 15% and something which doesnt make all of tradfi and now crypto (after UST) raise their eyebrows
I didnt make it to your suggestions re liquidations, gotta get to work
Yeah, 20% has bad associations. 
It could be set to 1.5X of rUSDT interest rate.
I think 1.5x is great, as a baseline for pool APR regardless of borrowing conditions or liquidations that is compelling to me as one for sure.
Regarding liquidations long term cant make comments on this without including this all-important piece haha so - i would just say 6 months data is great but market cycles are typically 4 years, so imo the datapoint should just be all-time historical liquidations and a monthly average taken based on the number of months the system has been live? Or if its too much just extend 6 months as much as possible. Will be important later
And sorry yes if pool APR sustains itself through badass mechanics set SPOF = 0 but ideally this idea / mechanism is there as a system safety. Perhaps when bitcoin goes to sleep for 6 months and we want zero to keep doing its thing.
Actually i suppose if you wanted to ensure the SPOF checked more recent liquidations volumes and for the system to more closely keep up with conditions, the last 6 months of liquidations would make more sense. Appreciate ya!
I would suggest a different approach.
We set a target APY for the SP, let’s say 20%. The funds for this would come from the origination fee. If the collected fees are less than the amount needed to cover the 20% APY, all of it would go to the SP providers, resulting in an APY lower than 20%. Any amount collected beyond what is required for the 20% APY would go to the protocol/SOV stakers.
This approach allows us to adjust only the target APY in the future, such as providing an extra boost for a specific period of time, without changing the overall fee distribution logic.
Seems easier to implement and more limited in terms of a few things -
the whole basis of the stability pool is collecting APR from intense volatility periods which occur sporadically, it shouldn’t be a tight monthly ship imo. liquidation events in the early days of the pool and before it reaches large scale might come once per year or possibly less - so we would be aligning the mechanics to a foreign system imo
when there are no liquidations stakers will make no money on zero. as in 1), this by design means that the system defaults to staker revenue = 0, with out of control frequency. this has quite significant implications given zero is the only product within our present grasp - assuming we can launch it - and for at least the next year too (after bitcoinOS launches, much time is needed for sovryn layer development - it could be well over a year - with zero the only protocol revenue in the meantime)
optimizing purely for APR is effectively levering up a passive income model and trying to make it into something more active and more degen, as with 1) against the grain of the pool imo
as mentioned in 3), we optimize around APR which is effectively just agreeing to a dial setting of what our end goal is, not how to achieve it. Similarly, this suggestion offers no solution to origination fee challenges, the alternative would be to focus on those challenges and allowing origination fee to manage itself in a way which best meets the long term objective which is the pool APR
I need to ask a few clarifying questions. Are you saying that the actual fee income will be monitored to achieve a present 20% APY if possible? And this would be paid from accumulated origination fees? If that’s what you’re saying, this could be an appealing result, but it requires all kinds of new structure to implement.
It requires some kind of escrow for the funds rather than allocating them directly to stakers so that they can be paid out to the SP. It also requires tracking when SP funds were deposited and calculating the duration of funds in the pool so that users can be paid based on pro-rata time in the pool since the last payout.
Maybe you just mean a target split of the origination fee will be calculated based on activity from the previous period. In that case, you’re saying that the origination fee won’t change, but different portions of it will be paid out to achieve a 20% APY. If all of the fee is used and the APY falls short of 20%, then that’s just what happens.
Which of these scenarios do you mean? Or maybe a third that I’m missing. 
I’ve not followed Sovryn for the last 6-8 months, this morning I checked the CRs in Zero and couldn’t believe they’re sitting at over 900%.
Zero is broken.
I found this thread and I’m happy to see a solution coming, keep up the good work @one_digit .
Sorry that it took me so long to answer You.
To clarify, my initial suggestion was more aligned with the second scenario you described, where the origination fees are dynamically split based on activity from the previous period, but
at this point, I’m leaning towards the first option, where we’d implement a contract for accumulating fees and then directing them to the SP and SOV stakers based on a predefined algorithm. This would allow for more precise management of fee distribution while keeping the reward structure flexible and dynamic.
That said, even if we opt for the second option - just splitting fees to target the specific APY - we would still need a system that calculates rewards based on both the time funds were deposited into the SP and the amount of funds.
Another idea to consider is introducing a two-tier reward system for SP providers:
I lean toward doing something that is as simple as possible to implement and isn’t easily exploitable by people wanting to jump in and out of the stability pool.
I believe my suggestion of simply directing a portion of fees to existing stability pool holders is the simplest possible. It doesn’t require tracking time in the fund. If you’re in when someone borrows, you get the fee cut. That is simple, and it has the advantage that it can’t easily be gamed by people putting in funds or pulling them out at opportune times.
We could route a portion of fees to treasury and then pay current SP holders a rate based on the previous month’s fees (or some other algorithm). As long as we’re only paying people based on their current time in the pool (or time since the last epoch), that might keep the time tracking simple. I’m not sure if the current SOV payout is a per-block payout or if it keeps track of time in the pool.
It seems like increased rewards should go to SOV stakers, since that mechanism already exists and it rewards people by allowing them to vote. But figuring out how to reward based on the amount of staking isn’t straightforward to me.