Skirting Fees

[allo-protocol]

Skirting Fees

[zobront]

I've spent a lot more time thinking about this and I don't think any version of the above strategy will get us 100% there.

There are tons of ways to block this behavior, but the problem is that, inherently, all of them require the strategy to cooperate. If someone is willing to create a rogue strategy, they can skip all of that, and there's no way I can see to verify it on chain. We can make it more inconvenient, but they can ultimately always make the strategy do whatever they want.

The only solution I can see is to involve off-chain watchers with a strategy blacklist to help.

Here is my thinking:

• we track in Allo.sol the total amount sent to a distribution strategy via createPool and fundPool
• when enforce the rule that, if an allocation strategy needs to send funds to a distribution strategy, it does it via a call to Allo.sol#fundPool(), meaning that they don't need to implement fees, they happen automatically
• part of the distribution strategy interface is a skim() function that takes the difference between the current balance of the distribution strategy and the amount tracked in Allo.sol and sends it to the treasury
• the off chain watcher monitors for balance changes in the asset. if it ever sees a balance chance that did NOT come from Allo.sol#fundPool(), it tries to call skim(). if skim() doesn't succeed at lowering the balance down to the tracked amount, the strategy is added to the blacklist on Allo.sol
• this blacklist is checked in all functions that come through Allo.sol, so stops the core contract from being used by any users of the pool

What do you think? It's a bit messy, but it's the only possibility I can see that actually stops them. Anything that relies fully on on chain logic and economic incentives can be skirted by just not following the rules.

[0xKurt]

Can you say more @KurtMerbeth? What types of pools wouldn't have distribution strategies?

@nfrgosselin every kind of directly allocated funds, or?
like in direct grants or similar strategies where you allocate directly to a user. ofc we could have a distribution strategy for it, but it feels a little bit too much. since calling allocate results always in a direct transfer to the user.

[zobront]

Thinking more about this, one possible attack I could see is:

• I send $1 to a strategy
• Off chain watcher calls skim()
• I backrun the skim() call with sending another $1, ensuring it's there by the end of the block
• Then, by the time the watcher sees things update, the balance is still off, and strategy gets added to blacklist

I think we'd need a way for the watcher to simulate the transaction or something to make this work. I don't have experience with this but can ask around.

[zobront]

I think I have this part solved in a way that's much more elegant.

Instead of pushing all the logic to the off chain watcher, we can have an on chain contract that can perform the logic atomically, and the off chain watcher just calls that.

contract Watcher {
    function report(address strategy, address token) external returns (bool) {
        // pseudocode
        before = token.balanceOf(strategy);
        treasuryBefore = token.balanceOf(alloTreasury);
        reported = allo.fundedAmount(strategy);

        try strategy.skim(token) {
            if (token.balanceOf(strategy) != reported || token.balanceOf(treasury) != treasuryBefore + before - reported) {
                allo.addToBlocklist(strategy);
                return false;
            }
        } catch {
            allo.addToBlocklist(strategy);
            return false;
        }
        return true;
}

This basically ensures that the skim() function is working as intended, and automatically adds them to the blocklist if it doesn't.

Then, we can:

1. Have an off chain watcher that, when new pools are created, runs a simulation to send tokens to the strategy, call this watcher, and make sure that it returns true (ie it's working properly).

2. Have an off chain watcher (or build an incentive into the function above for others to have watcher bots) that watch for all tokens transferred into the contract, check the amount funded through Allo.sol, and calls this function if there's a discrepancy.

---

This addresses the issue in the way I discussed above, but without the risk of backrunning I described, and also dramatically simplifies the off chain logic by putting the actual checks and blacklisting on chain.