Explore incentives to push splits

[CodeSandwich]

0xsplits protocol has a nice feature of tipping the person who triggers splitting and pays the gas. They've implemented it as a configurable percentage of the split funds which goes to the caller. This way the network keeps flushing itself, especially during low gas price periods. If there are bots involved, we can expect the tip for the caller to be around the lowest possible gas cost to push the split. The regular splits receivers don't really lose anything, somebody needed to pay for the gas anyway. It's even better, because it's done optimally and in form of a tax proportionally divided between all the receivers. E.g. if there are 100 receivers and each gets just 50$, nobody will ever trigger splitting, it makes no financial sense. But if the caller tip is 10%, each will get only 45$ but the bot may actually make it a reality because it'll get 500$ which is enough to cover the gas.

An approach like this is worth exploring, either by copying the 0xsplits solution or by inventing something similar but better suited for us.

[CodeSandwich]

@xmxanuel came up with more more ideas:

• split a percentage to an unkown caller (msg.sender)
• define a split percentage together with an absolute maximum (maybe the msg.sender shouldn't get 0,1% if someone drips a million).
• define a split as an absolute value instead of percentages
• ask this contract address (by calling a standard interface method) how much i should give certain address X
  • image this feature for msg.sender to refund the gas-costs
  • someone could implement a better incentive mechanism by still using our drip hub contract

[CodeSandwich]

The simplest version mimicking 0xsplits can be done with a new app and no changes to the protocol.

Let's call it an AutomationApp and assume that it has an app ID 42. The user with user ID 00..0AB who wants to enable automated splitting should add a user ID 00...0420...00 to their splits configuration with some weight. The AutomationApp allows anybody to collect for user ID 00...0420...00. A bot is then incentivised to call receive and then split for user ID 00..0AB, because in the end it can collect for user ID 00...0420...00 and get its reward.

AutomationApp may expose a helper function like this:

function collect(uint256 assetId, uint256[] receive, uint256[] split, address collector) public {

When called it receives each of the user IDs from receive, then splitss each of the user IDs from split and finally collects for user ID 00...0420...00 and sends the rewards to collector.

Alternatively AutomationApp can support transactions batching.

[gh0stwheel]

This is a really neat design! I love that it provides an option for incentives without any changes to the protocol.

We should definitely look into deploying an instance of AutomationApp and writing up some example code for how to use it once v0.2 is live on mainnet and audited.