Add a Keeper contract to handle permit payment

[zugdev]

I've thoroughly analyzed this, and ultimately, I believe the table approach introduces way more risk than necessary. I propose we keep all related to payments on-chain, with adjustments to the current permit2 architecture. It is not common to permit directly from treasury, a standard solution to this problem is having a keeper contract. So my plan consists of the following steps:

1. Write a keeper contract (and proper test suite)

We'll deploy a keeper for each possible treasury, which is the EOA that currently is the permit signer. The contracts will have whitelist protected functions for those funding EOAs. We have a public mapping of userToBalance (address -> uint256), public token address for the reward (we can make it configurable and change a little the previous mapping). We have a permit function which we will call at the end of an issue, this will increment a user's token balance. We have a cancelPermit function that the funder can also call at any time. The user can then claim any amount at any time and isn't limited by individual rewards. We keep an on-chain log of rewards, permits, cancellations and redemptions. We could push those logs as objects to on-chain storage, whether we are on Gnosis or any other L2 gas is extremely cheap.

2. Refactor permit generation/signing to sign a keeper's reward call
3. Refactor pay.ubq.fi

As part of our plan to rollup permits, we should deploy a keeper contract, it should handle user balances and act as a middle-man in permitting a user to collect rewards from the treasury.

Generally, the keeper contract will streamline the reward distribution process by maintaining user balances for each treasury EOA and allowing users to claim their rewards non-atomically. The collection method should enable fee-taking thus supporting our business model. We should keep administrative control features enabling treasuries to cancel any rewards to any addresses. It would also not change the approval flow setup for a partner, it would behave as a permit2.

[0x4007]

@rndquu rfc

[rndquu]

@rndquu rfc

Answered in ubiquity-os-marketplace/text-conversation-rewards#64 (comment)

[ubiquity-os]

Passed the deadline and no activity is detected, removing assignees: @zugdev.