Improve financial efficiency

[bajtos]

While releasing rewards this week, I noticed the tail TXs are paying as much or even more on the gas fee than on the rewards released.

TX	rewards sum	max fee
10/13	1.5 FIL	0.7 FIL
11/13	0.74 FIL	0.69 FIL
12/13	0.23 FIL	0.66 FIL
13/13	0.005 FIL	0.25 FIL

While we can afford to pay ~2.3 FIL per week on gas fees for releasing 2.5 FIL rewards for the least-earning participants, it still feels a bit wasteful.

Proposal: implement a threshold and release rewards only for participants that have accrued at least that much FIL in unreleased rewards.

Proposed threshold: 0.01 FIL (10% of the threshold implemented in the smart contract)

For context: the first participant in the batch 10/13 had 0.0021 FIL.

[juliangruber]

I would argue this to be low priority from a financial perspective, but a DX improvement, as there need to be way less transactions.

[juliangruber]

There is one problem here:

Say we set a threshold of 0.01 FIL. If someone has 0.091 FIL in the contract and 0.009 FIL in this service, they have 0.1 FIL in total, but won't be able to be rewarded. This beaks our ToS. Any limit we set will have this risk.

Therefore I suggest to instead check against the value in the live contract, and only send to the contract if contract+service amounts are above 0.1 FIL. Wdyt @bajtos?

[bajtos]

There is one problem here:

Say we set a threshold of 0.01 FIL. If someone has 0.091 FIL in the contract and 0.009 FIL in this service, they have 0.1 FIL in total, but won't be able to be rewarded. This beaks our ToS. Any limit we set will have this risk.

I agree this is a risk.

I am not sure if the risk is large enough to require us to spend time on mitigating it.

Therefore I suggest to instead check against the value in the live contract, and only send to the contract if contract+service amounts are above 0.1 FIL. Wdyt @bajtos?

SGTM, but I'd like to understand the impact on performance. IIUC, this requires one more RPC API (?) request per participant, which can cause a significant slowdown.

[juliangruber]

I am not sure if the risk is large enough to require us to spend time on mitigating it.

I would rather have this script run for 1h than for us to have a known reason for people to sue us, which we will have to agree to.

SGTM, but I'd like to understand the impact on performance. IIUC, this requires one more RPC API (?) request per participant, which can cause a significant slowdown.

This is true, there will be one call per participant. This can be parallelized.

[juliangruber]

#46