OK that is a fair point. In hindsight the rewards have definitely not off-set the IL. But in the moment, of every week when we say should these 15K SOV rewards off-set the IL for the week moving forward? The answer to that question is yes. The problem is the $SOV token price kept going down and down and down. So it’s really just a timing question.
In Yago’s defense it is correct, based on the information we had at the time. But in hindsight it is not correct.
There is another issue with your calculations. You are using the theoretical SOV rewards being issued to the LM pools, not the actual. For example, the rBTC/SOV pool is advertised as issuing 30k SOV rewards per week, but that isn’t the actual total being issued. I have been tracking rewards for the last 6 months, and have the data to back this up. This issue was addressed on Discord back in November/December with CEK.
The gist is (from CEK back in December 2021):
‘The problem is the block frequency.
The smart contract distributes SOV rewards based on a fixed amount per block and assumes that blocks are mined every 30 seconds on average.
The problem arises because there are fewer blocks mined in the weekly interval and therefore fewer rewards are distributed when, on average, blocks are mined in more than 30 seconds.’
The reality is that the rewards in the pools have fluctuated between 10-14% less than what is supposed to be issued. So, roughly, 25,800 - 27,000 per week. Again, it has fluctuated back and forth since at least last October. I don’t have data to support anything prior to that.
This ‘quirk’ of the smart contract that issues rewards to LM pools affects all of the pools. There has also never been a fix issued.
Point being, for long term investors in the LMs, the ‘loss’ is magnified by not receiving 10-14% of what was advertised, in addition to the other IL calculation related issues in this conversation.
Thanks for pointing this out! If you could share data that’d be great. We can probably query from the graph the historical rewards pushed into vesting contracts and see how closely they reconcile to what has been advertised.
I’ll need to reformat, but i’ll put something together and post here in the next 24 hours.
Here is a very simple summary of the percentage of the rewards that were received relative to what was ‘due’ (assuming 30k SOV rewards/week). The following list is the date of each claim period, and the percentage of rewards received over the preceding period leading up to that date.
| 12/30/21 | 88.21% |
|---|---|
| 1/13/22 | 91.40% |
| 1/27/22 | 90.16% |
| 2/10/22 | 86.01% |
| 2/24/22 | 85.62% |
| 3/10/22 | 87.74% |
| 3/24/22 | 84.79% |
| 4/21/22 | 88.74% |
| 5/5/22 | 90.96% |
To get this data i took a snapshot every 12 hours (on occasion every 24 hours) of the total liquidity in the rBTC/SOV pool, my personal liquidity in the rBTC/SOV pool, and my accrued rewards in the rBTC/SOV pool. I could show you how the percentages fluctuate every 12 hours, but that didn’t seem like it would be any more useful than the claim period summary.
I noticed the rewards slipping from what was expected in the middle of October. Casually watched it for the next claim period, began a convo on Discord on the subject in late November, and began taking the 12 hour snapshots on December 12, 2021.
Also note that these numbers are based on my personal behavior in the LM pool, some of the numbers might be slightly different for another user, but I have confirmed with two other users on Discord that they were tracking the same behavior in the rewards. I assume any small discrepancies from user to user would occur due to withdrawal and deposit activity.
Thanks, interesting find for sure.
It would be good to know how the Pool-APY is calculated in the charts on the dapp and if it’s actually wrong.
I am not sure if we are able to track the rewards per block with the subgraph, to my knowledge this functionality does not exist.
The subgraph only shows the rewards when the users claim them. That’s why we took the reward numbers that are shown on the dapp.
It could make sense to publish the rewards per block on the dapp so the users can calculate exactly how much SOV rewards they receive per block. Would make more sense to me.
This is of course worth some concern. And also fits with the picture that the IL adjusted APY is smaller than the data currently shows. I can also personally confirm this.
However, I would like to add that our conclusions are mainly based on pool liquidity and pool volume.
We are primarily trying to manage the pool liquidity more efficiently and stabilize the token price by providing SOV incentives where they are worth it and by reducing inflation rate to more sustainable numbers, which would hopefully result in a lower IL in the SOV and Mynt pool.
Yes! this is consistent with my calculations for RBTC/SOV pool rewards. However my calculation is based on my share of the LP and tracking the changes daily, so it is not 100% accurate but reliable.
It is very interesting the analysis you are doing. I am sure that it can be measured and that what you are describing is real. It may not even be a mistake or malicious behaviour, but the consequence of using a way of counting or managing quantities over time, and of course a way of communicating it in a simple way. Perhaps explaining the frequency of the block would be complicating matters.
It should be analysed whether this way of counting rewards will continue in the same way or has to be changed. It would have to be assessed whether it can be communicated more accurately by informing that the amounts are somewhat lower and explaining the reason. We would have to see if it is considered a serious issue that would require retroactively rewarding all those who contributed to the pool from day one for what they are missing up to the expected amounts. Undoubtedly, the figure of “undelivered over expected” rewards after all these months could be significant. And it may be causing an imbalance somewhere else beyond tacoocharlie’s mind.
That said, I believe that all of the Token Circle’s analyses, conclusions and proposals remain equally valid and powerful, and we must continue to move forward on that path.
Thank you tacoocharlie for your research work and making it public!
According to my calculations, right now, my APY on the rBTC/SOV pool is 40.86% and the dapp is reporting 41.35%. Would need to track over time to get a better idea if the fluctuations converge or diverge.
I agree with your point on publishing the rewards per/block on the dapp versus the theoretical rewards (which are never achieved).
We’ve confirmed with dev team that the rewards are issued based on a 30s block assumption. We also pulled historical block timestamps and noted that block times in reality vary quite a lot, with them on average coming about every 33 seconds. This means that on average the LM reward APY’s may have been over-stated by 10%.
We’re working on better together some better analysis for this. In the meantime, I’m not sure it impacts our plan to try and trim some of the rewards and see the impact. But we do want to work on getting more precise data and charts to the community.
from @bananas_in_the_sky
looks like weekly block production varies quite a bit
mean 18718.986207
std 652.975284
min 17522.000000
25% 18173.000000
50% 18684.000000
75% 19218.000000
max 20336.000000
As far as I can tell, the expected versus delivered only began to diverge in mid October 2021, but i could be wrong about that. I was checking my rewards daily at that time, but not recording every single snapshot, just taking a mental note. I didn’t begin to notice the divergence until the mid October claim period. I found two other people on Discord who noticed the change at that point as well. I’m guessing it’s not all that difficult to track historical block creation if we really wanted to figure out exactly when it seems to have started, or if it was always present.
I had conversations with CEK over the span of a couple months (Dec 2021 - Feb 2022) on Discord, the goal from my point of view, and I think his as well, was an attempt to resolve the problem, so ultimately the full rewards were being distributed weekly. I was told, repeatedly, that the devs were aware of the issue, and that a fix would be coming ‘soon’, although it would not be an easy solution and would take some research to figure out how to solve it. After following up for about 2 months I eventually stopped asking as I assumed it wasn’t a mission critical problem for the devs, and honestly, wasn’t creating much static, so not much motivation to resolve it. I’m sure it also fell WAY down the list of priorities.
I don’t know how we would go about awarding back rewards, if they’re even warranted. I can track mine, and know how much i’ve missed, at least since December 12th, but its a big number (relative to me only), and i can’t imagine issuing back rewards would go over well in the community right now. That being said, we’ve discussed the IL concerns on this pool (and MYNT), and the back rewards do help alleviate some of that. But then we get into a conversation about whether or not it’s the community’s responsibility to insure against IL, and i can see both sides of that argument. I also see the argument that nobody would be getting any trading fees if not for the LP providers, so helping alleviate some of their loss isn’t the worst policy.
That seems consistent with my data that shows the rewards received varies (within a range).
I think this is a good assessment of the situation. I’ve been a LP since Day 1 and personally would benefit a lot from the missed rewards. However, I don’t think issuing back rewards is warranted. It’s time to move forward, push changes and reduce technical debt as much as possible. Basically, I don’t think the juice is worth the squeeze when it comes to priority of tasks to push the protocol forward.
I think a reasonable compromise is we push forward these new changes and continue iterating on improvements that require no technical dev debt. Then on the side we can continue to post charts/analysis and work off people like CEK’s work so the community is informed.
What do you think?
Thanks @TacooCharlie for the input. I updated the original cost per trade volume and cost per liquidity figures. I adjusted the advertised weekly SOV rewards to account for actual block production [actual weekly sov rewards = advertised rewards * (blocks actually produced per week/blocks that would be produced with a 30s block time)]. The key conclusions regarding which pools are expensive from a protocol point of view (are we getting bang for buck?) are not substantially changed.
As a next step, we are looking into an alternative way to represent IL adjusted APY, complementing the figures produced by @dseroy.
Agreed. I was never seeking compensation for back ‘missed’ rewards when i started the process, at best was hoping to correct the way the rewards are issued, or a compromise of adjusting the way the rewards are advertised on the dapp, something more accurate than ‘30k SOV/week’. This is a new project, and very early days, i knew what i was getting into.
Perhaps I could have explained my experience better… @yago @dseroy are correct the the APY has remained around 50% (or higher) on the SOV/btc pool. But this APY is at the time of generation, it does not calculate for the delay in release and therefore is not the true APY when the coins are available to the LP. In this case the true APY was much lower as the price was down 10x at least in that time frame. The true APY should be calculated at the time at which the coins are liquid, not generated.
In any event, this would work both ways if the price went up.
It leads me to a thought of why not allow for coins from the AMM have an option to stake immediately? Many of us who like to stake our generated coins have to wait (10% a month) 10 months with no reward just to to do it. I don’t see a downside to this for the LP or the protocol.
Yes in my opinion the APY should be calculated at the time the coin is available. But that is something that we are all aware of.
When it comes to getting an option to stake the vested rewards immediately, I think it is a very good idea! I add a portion of my fully vested rewards to long term stake from, but if we get the option to do it straight away I would add all of my rewards to staking.
Just a quick shout out to everyone involved in this exploration/assessment with so much rigor, open mind and mature manners. Missed this in the forum during the DMan days. This quality dialogue of people smarter than me makes me believe in Sovryn. Cheers folks!
This thread has been extremely insightful. For me one key takeaway is that we are paying an exorbitant amount to “rent” liquidity.
Using the USDBTC pool as an example, there is currently a total of a little over $7m of liquidity in that pool. On a weekly basis, we are paying on the order of $54k USD in the form of SOV to attract that liquidity. That implies an annualised interest rate of ˜40%. In other words, we are paying 40% interest to rent that liquidity.
This interest rate, by all accounts is high. It would be cheaper (putting aside IL for a moment) to just borrow the funds from our lending pools.
An alternative to renting is buying. Buying has higher upfront cost, but you get to keep what you buy.
So an alternative that presents itself is to buy liquidity, rather than rent it. How could we buy liquidity?
One way we could go about this would be to hold a weekly SOV dutch auction. We would sell SOV, pre-staked in 3 year vesting for BTC. The market would decide what discount to the liquid SOV price it would place on such SOV. The funds raised from these auctions could be placed in the pools which require liquidity.
With the advent of Zero and the Sovryn dollar, we could take this further. Instead of a XUSDBTC pool we could have a DLLRBTC pool (Sovryn Dollar/RBTC). Some of the BTC raised in auctions would be used to borrow DLLR at 0% interest rate and paired with BTC to provide liquidity in the DLLRBTC pool.
The BTC we raised we would get to keep and the next year or so may prove to be a fruitful time for Sovryn to acquire BTC. Further, once sufficient liquidity was raised, we could stop the auctions.
Of course, this is not entirely straightforward. There are risks and complexities.
With regards to point #3, we could potentially continue LM rewards while we were ramping up the sales process.
In any event, 40% annualised to rent liquidity is not ideal long term. Buying, instead of renting seems to be more in tune with our long term focus.
The difficult part is to get demand for us$ 7,000,000.- in sov (in exchange for btc) in those Dutch auctions under the conditions you describe. No doubt the discount will help, but will it be enough? (Maybe rights or benefits could be added to those who attend these auctions (nft, free fees, airdrops?) If this is achieved, the rest of the points you raise I think are possible.
Perhaps simultaneous auctions could be held at 1, 2 and 3 year stakes, with a smaller or larger discount depending on the time commitment, which could vary between different investors, depending on their risk aversion, even with different unstake penalties to the standard ones.
I have not analysed whether there is a risk that current stakers will unstake their sov by paying the penalty, and sell their sov to enter the Dutch auctions again at a better price. In any case, it is neutral.
I don’t know if this is in line with Sacro’s idea of reducing the stake growth rate, but on the other hand it would be a great saving for the protocol, assuming the risks described.
Finally, it remains to be seen where these sov would come from. I imagine again from the Adoption Fund. If so, I have doubts as to whether it is the proper use of this fund to provide liquidity to the protocol.
