# Allo Protocol research

After thoroughly researching the Allo protocol and its nine smart contracts, it appears that certain aspects of the protocol can be improved upon and simplified.

Many of the contracts do essentially the same thing while the core functionality is localized in a few functions. Does it make sense to have 9 contracts to manage or could it be simpler and more flexible?

## Challenges in working with the protocol
- Requires deployment of 9 contracts just to run
- To create a round requires deployment of several contracts
- Not clear how to extend with services like EAS for attestations
- `msg.sender` is often used thus not compatible with Relay services

Below is a list of the contracts and a short description of what they do.

## Contracts

**MerklePayoutStrategyFactory**

- Update implementation contract
- Deploy implementation contract

**MerklePayoutStrategyImplementation**

- Update Merkle distribution (merkle root and metadata)
- Set ready for payout boolean (is checked when calling update distribution and payout)
- Withdraw funds to address (only round operator and if round has ended)
- Payout distribution (an array of { index, grantee, amount, projectId, merkleProof } is sent and verified against the merkle root)
- Transfer amount to grantee
- Get balance of funds in contract

**ProgramFactory**

- Update implementation contract
- Deploy Program implementation contract

**ProgramImplementation**

- Update metadata (yes, it just updates a variable)

**ProjectRegistry**

- Create project (adds projectID and metadata to mapping) and set project owners
- Add project owner
- Remove project owner
- List project owners
- Update project metadata (only project owner)

**RoundFactory**

- Update Allo settings
- Update Round implmentation contract
- Deploy Round implementation contract

**RoundImplementation**

- Config for:
- applications start / end time
- round start / end time
- voting strategy contract
- payout strategy contract
- match amount
- Update config
- Check if round is active
- Set ready for payout
- Check funds in contract is more than match amount funds
- Transfer protocol and round fees
- Set MerklePayout to ready for payout
- Withdraw funds if round operator
- Apply to round
- Add projectID and application metadata to mapping
- Set application status (to pending, approved, rejected, canceled)
- Get application status for application index
- Vote (calls voting strategy contract if round is active)

**QuadraticFundingVotingStrategyFactory**

- Update QuadraticFundingVotingStrategy implmentation contract
- Deploy QuadraticFundingVotingStrategy implementation contract

**QuadraticFundingVotingStrategyImplementation**

- Vote
- transfer funds from voter to a grantAddress (which is set by the frontend)

**AlloSettings**

- Update protocol fee and treasury address

## Obersvations

As you may have noticed, a major part of the protocol is repeated across several contracts:

- **Update and deploy implementation contract** (4 contracts)
- The update function sets a variable to a new address pointing to an implementation contract
- Deploy creates a clone of the implementation contract and initializes via encoded parameters
- **Adding and updating metadata** (3 contracts)
- **Emit events**
- **Transfer funds** (ETH or ERC20)
- from round to payout contract
- from payout contract to organizer
- from voter to recipient

I would say the important parts of the logic can be found in a few functions that:

- Transfer funds from Round contract to Payout contract (is this necessary though)
- Update Merkle root for distribution
- Distribute funds to projects (matching pool payout)
- Transfer funds to projects (voting)

I believe the architecture could benefit from some simplification and improvements to flexibility.

Reducing the number of contracts and simplification could promote a more easily understandable and accessible protocol, leading to better adoption by developers and round organizers.

## Questions for discussion

- Is the protocol architecture using the correct abstractions?
- Is it flexible enough to extend? For example an EAS integration?
- Why does it require 9 contracts and is it possible to simplify?
- Does the ProjectRegistry need to handle ownership of the projects?
- What can be done to improve adoption of devs and organizers?
- Is there willingness to rewrite the protocol?