RE: Programming Diary #28: Thoughts on the problem of overvaluation
Unfortunately, they're still not correct because there's still an error in the Condenser (which only becomes apparent when the cut-off rule takes effect, which probably didn't happen when the Condenser was being developed). I will suggest a fix for this.
Ah... I knew there was a reason why I didn't like pegging the so-called "median" to track the haircut price. I thought it was harmless, but it always seemed like a kludge. But yeah, of course any value depending on that would be wrong. By a lot, right now.
I guess the argument was that it's not wrong in terms of the internal SBD price, but it's labeled with a "$" (at least in the US), and of course the external SBD price isn't anywhere near the peg, so reporting in terms of SBDs is confusing, at best.
I compared this with one of your posts:
This was the display according to the current code:
... and so it should actually be correct:
The total amount in $ does not change.
The only difference is that 31 STEEM are not paid out. However, the amount for SP is correct if the curator amounts are also included.
I'll have to take a closer look to see where the code needs to be changed and which amounts should be included.
I'm confused about where the second screen shot comes from, but I think you're showing basically the same as what I was seeing.
Here's a an example after payout time with no beneficiary rewards in play.
At the haircut price, $6.20 is about 24 STEEM. At actual dollar value, it's about 36. The actual rewards seem to match the haircut price.
Which means the actual dollar amount of the distributed STEEM and SP would be closer to 2 * $4.05 = $8.10. Similarly, it looks to me like your second screenshot probably matches the STEEM/SP distribution, but not the dollar value. The dollar value of 42 STEEM is in the neighborhood of $7.14, not $10.93.
No idea how I have never noticed this before. It's a substantial difference. Or maybe I just forgot, but it seems like something I would have remembered. Or maybe I had overlooked it due to the previous inclusion of TRX values.