Hey, I have a question.
I just now changed the payout address to my exodus wallet for storj coins,
Can you tell me if the payout for june has been already paid? or if not, will the new address work?
Regards
Iāve checked on the ether scan and the payout wasnāt yet sent to my old or new address, so Iām not sure if the new address will apply if I changed it just now?
I do not have this information, however, the payout should happen in the first two weeks of the month, if your node is eligible to receive a payout (see Minimum payout threshold).
The change of the wallet address will be applied to the next payout window.
It will apply next month. The June payout will be sent to the address they had for you at the-end-of-June. Even though the payouts havenāt actually been sentā¦ yetā¦ you changed your address a couple days too late.
did you have this situation yourself before? That sucks
It doesnāt suck: it makes sense. The wallet youāre using at the end of the monthā¦ is what receives the payout for that month.
Did you have this situation yourself?
Why does the existence of a personal anecdote matter to you?
To change payout address update it and restart the node. The payout address is taken from the database at the time the payout invoice is generated. There is no snapshotting at the end of the month. (Check cmd/satellite/compensation.goā , cmd/satellite/compensation.go, and generateInvoicesCSV)
Can anyone confirm this? Iām getting 2 different answers here.
I literally gave you links to a proof. What other confirmation do you need? Another anecdote?
Technical topics are not decided by popular vote. The source is published. You can verify yourself.
will look into them, thx
How do we know when payout function is called and what database state is used? I remember they used database snapshots for bloom filter generation so they could do the same for payments.
There are some processes within Storj Inc. that operate on a backup of the primary database. IIUC, we donāt know whether payments is one of them.
Sure, that would be a good thing to do. But why would they use days old snapshot/backup and not the most recent one? There is no logical reason to do so.
If payout is sent on 10th of the month ā it will likely have state within a day. Not since last month.
Do I know for sure? No. But it would make no sense otherwise.
It makes sense to capture all the info you need for monthly payoutsā¦ as close to the end of the month as possible. Even just for internal financial reports: you donāt want some months to include 35-days of payouts then the next month only 25 days. Consistency is important.
When the payouts are sent to SNOsā¦ has nothing to do with anything. Only capturing how-much and to-who at the end of the month.
The reason for generating bloom filters off a backup is because it would otherwise increase load on the production database. I donāt know whether this would also be the case here, but it would be one logical reason.
You literally didnāt give links to a proof. He asked about timing. You gave no info about timing.
Code exists to export invoice data: thatās awesome! But when is it run?
The code snows that interval for computation is last month and the wallet address is current from live record. not from a state as of last month, as you suggested.
If the whole universe is snapshotted ā nobody can see that, so the point is moot.
Bloom filter is computationally intensive. Accounting is not. But sure, we can assume itās also acted on a snapshot.
There is no evidence that itās done on a mouth boundaries. Moreover, itās logical to compute payouts from whatever state, and then send payouts to current wallets, and not stale ones from last month.
Anyway. The whole discussion is moot. Who cares it gets sent to new or old wallet.
And absence of evidence is not evidence of absence.