Look, you have neat calculations and complicated formulas. Please be so kind and answer me a question:
When you have an amount of Sats (rBTC in this case) and you hodl, that amount remains unchanged. Sats are Sats.
When you decide to put that amount into a pool where one side is rBTC you literally just have to look at your current amount of Sats.
There is no formula needed. The difference to your initial amount is the current Impermanent Loss. What else should it be?
Why complicate stuff so that nobody follows anymore?
I am not fabricating stuff, I am literally just looking at my pool. End of.
Tell me what my losses are if not Impermanent Loss.
So trying to sell the story that “they [rewards] mostly off-set” is just plain and simple not true.
I made some (basic) calculations of my own and came to my conclusion (nobody has to agree with that) that adding to a SOV related pool at any price below around 9k Sats will be uneconomic for me.
The only thing one could do right now is to bet on a recovery and buy SOV directly. The pool rewards would need to be thrice as much as they are now, and that is even before the cutting and reducing.
I dare say that right now every pool is a country mile distant of being attractive to add.
Of course that is just a picture of today. Tomorrow might be different again.
Look, not all IL is applied equally. So, there is no easy answer your question. For example, you could be in the pool for two weeks and experience far different IL than another person who is in for a different two week period. It also depends on when you sell your rewards versus the other person. If you and I LP during the same two week period we experience the same IL, but if I sell when $SOV is higher and you when it’s lower obviously the net APY is far different. So we cannot simply say here’s how much IL we all experienced. It is far different for every person and timing.
The intention of our analysis was to say if we took a snapshot of the IL and APY for every week since inception, what would it look like. We wanted to know if in weekly increments did our reward amounts at the time make sense. In hindsight obviously everyone experienced extreme IL because the rewards have drastically reduced in price.
If you can think of a better way to represent it, please let us know.
I don’t argue against your models and the effort you all put in.
I just strongly disagree with Yago´s reply to Keinor´s post.
“Keinor, on the basis of the chart posted by @dseroyabove, the impermanent loss has been more than completely offset by SOV rewards. Your post seems to disagree with this?”
The “more than completely offset by SOV rewards” part upset me a bit.
I wanted to clarify that reality mostly deviates from models.
In the current environment there is no offsetting losses.
And yes, the numbers I presented are just my numbers but hey, they are real and I shared them with all of you.
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.
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.
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.
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.
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.
Bang for buck - adjusted for actual block production
Cost per trade volume
Weekly cost in BTC per BTC of trade volume (BTC value of SOV reward/weekly trade volume in BTC) varies up to a factor of 37 between pools as of 2022-05-07:
Weekly cost in BTC per BTC of provided liquidity (BTC value of SOV reward/net provided liquidity in BTC) varies up to a factor of 3.5 between pools. As of May 2022:
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.
