Protocol Guild Architecture

Some disclaimers: not a solidity dev, probably very inefficient/exploitable/etc. Very rough mental model!

Architecture

Let's start with a rough diagram:

I imagine the guild having the following components:

1. Receipients list: a mapping of all eligible receipient addresses, along with their weights/points/etc. We should assume this list and weights can change over time.
2. Epochs: a "time bucket" to better subdivide grant streams and to use as a reference point for list updates. This could maybe be done "each block", but feels even more inefficient. Also, perhpas these epochs store some metadata about whether tokens for a specific recipient have been claimed in this epoch.
3. Streams: a donation to the guild. Streams need to specify which epoch to start at, as well as a duration/vesting period. A number of token is sent alongside the stream, and every epoch makes available stream total / duration tokens, until the current epoch > start epoch + duration. It may be possible to have tokens pre-vest partially by having start epoch be earlier than the current epoch.

When someone claims their rewards, as 0xA..A does at the end of the diagram, we assume they are claiming for the current epoch and all preceeding ones. If they've already claimed tokens from a previous epoch, we should not send them more. If they haven't claimed tokens for this epoch, we iterate over each stream and calculate:

• The total amount of tokens from this stream available during this epoch;
• The caller's share of tokens in this epoch (note: might change from epoch to epoch, but stays constant during an epoch).

Then, we send the caller their proportional share of tokens. Repeat for each stream, for each unclaimed epoch.

Nice Properties

1. No "middle layer": tokens are stored in the contract and unlocked as epoch passes.
2. Permisionless donations: anyone can specify their donation amount and duration.
3. Supports updating receipients list.

Problems

1. Feels very inefficient:
   • Need to iterate over each stream, each epoch, when claiming;
   • Need to transfer each token when claiming;
   • Need to store if tokens claimed for each epoch;
   • Need to keep track of historical weightings.
2. Need to write the smart contract from scratch. If this holds significant value, will be a honeypot and hence need to be audited.
3. Doesn't design admin permissions as a core component. Perhaps the right design is centered around the multisig holders vs. the receipients.