---
tags: pg
---

# 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.