Improve strategy decentralisation (cryptoeconomics)

[An-dz]

⚠️ ATTENTION ⚠️

• This issue IS NOT for user/investor questions, including about knowing the current state of the strategy centralisation or security, make those on our social medias. The text below should also already explain clear enough the current state.
• This issue IS for discussing improvements and redesigning the current strategies. The current code has many comments and documentation to explain what's going on.
• We'll delete any comments that fall under the first category or promotional (spam) comments like "Just use X protocol, they are the best in class, cryptoeconomically secure, stonks, wow..."

⚠️ ATTENTION ⚠️

How it works

Our current strategy(ies) works like the following:

1. Someone calls it to start a request with API3
2. The contract then calls API3 Oracle for Heimdall data
3. API3 calls back the contract with the data from Heimdall
4. Someone applies the new weights in the pool

The problem

This entire process requires us to trust both API3 and Heimdall, which is not ideal since even if they are good actors there's always the risk they could be breached by bad actors (external or internal).

Mitigation

Because of that our strategy employs some mitigations to prevent such attacks.

The first one is that new weights are always gradual, even if bad weights are applied they would take 24 hours to be fully set. This one won't change no matter what new code we develop.

To prevent bad actors from depleting the API3 wallet (the one that calls back) only an updater can initiate a request to API3. The problem here is that there's no incentive for the updater to actually do what it should do, currently this updater is the Kassandra Foundation since on its own best interest it wants to maintain Kassandra working. The updater can be modified by the DAO.

When receiving the data the strategy has a suspectDiff parameter, this is a percentage of how much should the data coming from API3, the social score, should change, in both directions, from the last social score received to trigger an auto-suspension of the strategy. Or in other words, if the social score that is being received deviates by suspectDiff percent from the social score received 24h ago, the strategy will automatically pause and reject this response. The suspectDiff can be changed by the DAO. The first call to the strategy always triggers this event.

Since the data can be rigged even if inside the suspectDiff, there needs to have some way to pause the strategy if this is noticed. For that there's a watcher role whose power is to pause and resume the strategy when they see fit. They are also responsible for resolving the suspended calls from suspectDiff auto-pausing, choosing to reject or accept the new weights, after all, the data could be good even if growing or shrinking faster than expected. The problem here is pretty clear, the watcher could troll the strategy and nothing would happen to them. For now this role is maintained by the Kassandra Foundation, again because on its own best interest it won't shoot itself on the foot. And the watcher can be modified by the DAO.

Right now we are trying to come up with a cryptoeconomically secure way of handling that, decentralising this to the maximum extent possible, i.e. as many participants as possible, no one or nine users, but tens or hundreds. With real loss on trolling and incentives for good actors.