SGB Reward Rate - what it means

[BillyOckham]

Just now, BillyOckham said:

I don’t think this is correct.  After the lock in is done, (sometime after Thursday,) that is the amount and the delegated ratio that will be used for rewards even if you no longer have the wrapped SGB in the account.

Although…. it does depend on exactly when you sold them.

[jbjnr]

7 minutes ago, BillyOckham said:

I don’t think this is correct.  After the lock in is done, (sometime after Thursday,) that is the amount and the delegated ratio that will be used for rewards even if you no longer have the wrapped SGB in the account.

Sorry, but you've been drinking the wrong tea. The only thing that happens at the start of the epoch is the %delegation to providers is locked. If you move the SGB, wrap, unwrap etc, then rewards will change dynamically.

As it happens, I sold 50% before the start of the next epoch, so I was not expecting any rewards from them.

[brianwalden]

9 minutes ago, jbjnr said:

Sorry, but you've been drinking the wrong tea. The only thing that happens at the start of the epoch is the %delegation to providers is locked. If you move the SGB, wrap, unwrap etc, then rewards will change dynamically.

As it happens, I sold 50% before the start of the next epoch, so I was not expecting any rewards from them.

No. It's like a snapshot for the upcoming epoch. However much WSGB is in your wallet and whoever your delegations are set to, that's what's used for the whole coming epoch. You could do whatever you want with it and it won't change your rewards for that epoch.

[jbjnr]

3 minutes ago, brianwalden said:

No. It's like a snapshot for the upcoming epoch. However much WSGB is in your wallet and whoever your delegations are set to, that's what's used for the whole coming epoch. You could do whatever you want with it and it won't change your rewards for that epoch.

Dear @BillyOckhamplease accept my apologies for the vicious slander I inflicted upon you. If there are more than one of you that believe this, then it must be true and I'm wrong. This changes things. I will buy SGB every Thurs morning, lock in my delegations and sell it on Saturday, earn % income during the week and speculate on price movements of other tokens meanwhile (the xrp I bought with my SGB went up significantly, this could be interesting).

Anyone who designs a system that allows you to earn % on tokens you don't have deserves the highest respect!  

[brianwalden]

46 minutes ago, jbjnr said:

Dear @BillyOckhamplease accept my apologies for the vicious slander I inflicted upon you. If there are more than one of you that believe this, then it must be true and I'm wrong. This changes things. I will buy SGB every Thurs morning, lock in my delegations and sell it on Saturday, earn % income during the week and speculate on price movements of other tokens meanwhile (the xrp I bought with my SGB went up significantly, this could be interesting).

Anyone who designs a system that allows you to earn % on tokens you don't have deserves the highest respect!  

Yeah this is why the snapshot is at a random time over a couple of days. Imagine if you knew when it was. You could just dump it as in your wallet for an hour and then go back to doing whatever with it.

[Seoulite]

1 hour ago, jbjnr said:

This changes things. I will buy SGB every Thurs morning, lock in my delegations and sell it on Saturday, earn % income during the week and speculate on price movements of other tokens meanwhile (the xrp I bought with my SGB went up significantly, this could be interesting).

It will be interesting to see if this creates a kind of rhythm in the network and the prices. I doubt it will with SGB since the participation and rewards are not quite so high, but with Flare it might. You could see a surge in demand running up to the 'lock' period and then a surge in selling on the 'unlock' when people are not only selling locked tokens but also when the rewards are distributed.

Of course with any regular event like this it can quickly get cancelled out as people learn to drive up the price in anticipation of the demand and vice versa on saturdays.

1 hour ago, jbjnr said:

Anyone who designs a system that allows you to earn % on tokens you don't have deserves the highest respect! 

It's not so much that you are earning on tokens you don't have, you are earning on the tokens you had in the past. The snapshot just freezes the picture of the network in time. 

[BillyOckham]

1 hour ago, jbjnr said:

Dear @BillyOckhamplease accept my apologies for the vicious slander I inflicted upon you. If there are more than one of you that believe this, then it must be true and I'm wrong.

Hmmm.  Sarcasm eh?   I doubt that either of us considers it vicious slander.  
 

I’m advising what I believe to be correct.  I could be wrong.  I didn’t like that odd design myself either.

I believe a tell for the character of a person is how they react when incorrect.  As much as it smarts sometimes, I always try to own up and cheerfully admit when I am wrong.  So if proven wrong in this I will cheerfully admit it without resorting to sarcasm.

[BillyOckham]

Quote

4./ If you unwrap and or switch data providers in the middle of a rewards epoch, you are fixed to that data provider for the remainder of the current rewards week and will continue to accrue rewards from that provider

@jbjnr

From https://www.ftso.com.au/songbird-network/2021/09/24/vote-delegation-reward-epoch-explained.html

 

Edited October 7, 2021 by BillyOckham
Formatting and added tag

[jbjnr]

6 minutes ago, BillyOckham said:

Hmmm.  Sarcasm eh?   I doubt that either of us considers it vicious slander.  

You misunderstand me. Sarcasm yes, but only because I accused you of drinking the wrong tea, so it wasn't the most vicious slander really, but I wanted to add some drama to my day. My apology was sincere. I thought you must be an idiot, but it was I who was incorrect.

I can't really believe anyone would build a rewards system on top of tokens you've possibly sold already - but if that's the way it is, then so be it. I will be investigating ways of gaming this (but not announcing anything here).

[jbjnr]

7 minutes ago, BillyOckham said:

and will continue to accrue rewards from that provider

Yes. This is what I understood. The % delegation is locked in to the providers you selected - but I did not see anywhere that it says that you continue to receive rewards even after moving the tokens away, only that when transferring from one wallet to another, the % delegation to providers is honoured (and I assumed, on the new amounts in the wallet). 

[BillyOckham]

8 hours ago, jbjnr said:

You misunderstand me.

Oh, sorry, I did misunderstood the situation….   my apologies.

 

8 hours ago, jbjnr said:

I can't really believe anyone would build a rewards system on top of tokens you've possibly sold already - but if that's the way it is, then so be it.

I think I have an inkling of why they might have…  more in a moment.

 

8 hours ago, jbjnr said:

but I did not see anywhere that it says that you continue to receive rewards even after moving the tokens away

I am not sure the FAQ is definitive,  and it seems like a very strange design, but the fact that it mentions unwrap indicates that yeah, rewards are paid on phantom tokens.  
 

Note that the odd lock-in design doesn’t permit a voting double spend so they have designed it to be logically consistent at least.

But why do it?  I think it might be a performance factor.  
 

The smart contract that pays the rewards perhaps can more quickly read and write an internal dataset of balances and ratios and cumulative reward built at the time of the lock-in and updated per round than it could query the blockchain at the end each of round.

Thats just a wild ass guess.  I have no evidence, knowledge or indication that it is correct.  And if each round is four minutes then the contract does have oodles of time to work…  so I could easily be wrong about performance being a limiter and hence the kludge.

Thanks for the discussion, sorry I misunderstood you.

 

[JASCoder]

Regarding the practicality of monitoring all the balances of all accounts which have staked wSGB to an oracle...

It's likely the process workflow of the payout contract operates something like this:

1. Every week sometime after Thurs at 14 UTC, it will build a payout table 
2. It would walk thru the oracle list, scanning and recording the balances of all staked accnts
3. On Saturday the process tabulates all payout amounts of all recorded staked accounts of all oracles 

To enforce a project requirement that all staked accounts must maintain their wSGB balances for every minute of every hour of every day of the cycle's week, seems excessively onerous - and would drive up the platform's operational costs massively. 

Unless I'm missing something here ? 

@BillyOckham @jbjnr

[BillyOckham]

@JASCoder I don’t really want to build castles in the air coming up with possible architectures.  I only speculated a bit about the process to answer my own “why do it that way?” question.

There are many possible solutions to doing that thing….   at some point there may be doco explaining it all.  That does tend to lag way behind the code though.

[Seoulite]

10 hours ago, jbjnr said:

I can't really believe anyone would build a rewards system on top of tokens you've possibly sold already

I think it's more simple than that. It's just a weekly snapshot/airdrop cycle. The snapshot for Flare happened last december and people received SGB based on that last month. The principle with rewards is the same but the time frame is shorter and it is repeated every week. Apart from that, you are being airdropped rewards based on what was in your wallet at the snapshot.

[PunishmentOfLuxury]

2 hours ago, JASCoder said:

Regarding the practicality of monitoring all the balances of all accounts which have staked wSGB to an oracle...

It's likely the process workflow of the payout contract operates something like this:

1. Every week sometime after Thurs at 14 UTC, it will build a payout table 
2. It would walk thru the oracle list, scanning and recording the balances of all staked accnts
3. On Saturday the process tabulates all payout amounts of all recorded staked accounts of all oracles 

To enforce a project requirement that all staked accounts must maintain their wSGB balances for every minute of every hour of every day of the cycle's week, seems excessively onerous - and would drive up the platform's operational costs massively. 

Unless I'm missing something here ? 

@BillyOckham @jbjnr

Slight correction: Neil from FTSO.AU said on Discord that the delegation lock block occurring sometime between Thurs and Sat is not (randomly) chosen until the end of the epoch. There's no way of knowing it until 08.41 UTC Sat.