search

mlabs-haskell / plutus-use-cases

Plutus Use Cases
Apache License 2.0
13 stars 9 forks source link

Testing of ProvideRewards #116

Open zygomeb opened 3 years ago

zygomeb commented 3 years ago

this is a slightly tricky one. currently the tokens are distributed between the depositors on a token-to-token basis (i.e it doesn't try to weigh one token as being worth some fraction of the other. that system requires access to some trusted DEX or a lot of them, quite a LOT of math and would be prone to bugs.) -- that is, each token gets sent to all influence holders with T * ownInfluence/total, that is proportional to the % of influence, rounded.
This means that when a token is not given in a sufficiently large amount, it will have some tokens not be spent. See the test cases.

I refer to the reward tokens here as REW1, REW2 ... and to wallets W1, W2...

should give all to one wallet when it is the only one to have deposited should give 0 REW to both wallets that have deposited 1 GOV each, returning 1 REW to caller when called with 1 REW should give 1 REW to two wallets that have deposited 1 GOV each, returning 1 REW to the caller, when called with 3 REW should give 1 REW to W1, which has deposited 6 GOV, and 0 REW to W2, which deposited 4 GOV when called with 1 REW should give 2 REW to W1, which has deposited 6 GOV, and 1 REW to W2, which has deposited 3 GOV, when called with 3 REW

zygomeb commented 2 years ago

currently provideRewards is broken -- needs to scoop out PKH out of the datum instead. not priority to get it fixed as a new spec is on the horizon