allo-protocol / allo-v2

Core Allo V2 Contracts

Allo Protocol

The Allo Protocol introduces a sophisticated ecosystem on the Ethereum blockchain, enabling automated and decentralized fund allocation and distribution. The protocol comprises a set of smart contracts that collectively offer an advanced framework for fund management, fee handling, and governance. The technical architecture and interactions within the protocol are explained below.

Table of Contents

• Allo Protocol
  • Table of Contents
  • Diagram
  • Contract Overview
    • Registry Contract (Registry.sol)
    • Anchor Contract (Anchor.sol)
    • Allo Contract (Allo.sol)
  • Key Functionality and Interactions
    • Profile Creation and Management:
    • Secure External Interactions:
    • Advanced Fund Allocation and Distribution:
    • Fee Handling and Treasury Management:
  • Roles and Actors
  • Conclusion
  • User Flows
    • Allo Contract
    • Registry Contract
    • Anchor Contract
    • Overall Interaction

Diagram

flowchart
    Actor --> |profile management| Registry.sol --> |deploys|Anchor.sol
    PoolManager --> |createPool for profile| Allo.sol --> |validate profile| Registry.sol

    PoolManager --> |pool manager actions| Allo.sol --> |invoke pool function| BaseStrategy.sol

    PoolManager/Recipient/Allocator --> |invoke function unique to strategy implmentation|BaseStrategy.sol

Loading

Contract Overview

Contract	Purpose
Registry.sol	Registry of profiles which offers profile management
Anchor.sol	- Contract which can receive funds / execute transaction. - Generated using identityId and name of the profile - Is linked to a profile in Registry.sol
Allo.sol	- Management of a pool - Requires a profile from registry to create a pool - Expects a strategy which implements BaseStrategy.sol - Expects all interactions with the functions on BaseStrategys.sol to happen via Allo.sol
BaseStrategy.sol	- Abstract contract which implements IStrategy.sol - Every strategy should override the internal functions to be deemed as a valid strategy - Can have other functions unique to the strategy which can be invoked directly on the strategy

Registry Contract (Registry.sol)

The Registry contract serves as the foundational building block of the Allo Protocol. It facilitates the creation, attestation, and management of profiles. A profile is a unique entity representing a user's identity within the protocol. This contract offers functions to query profiles by ID and anchor, as well as to create new profiles with personalized metadata, attestation addresses, and members.

Each time a profile generates a new anchor (during profile creation or when profile name is updated), it triggers the deployment of an Anchor Contract. These Anchor Contracts serve as versatile tools that can receive funds or fulfill other designated purposes. This dynamic mechanism enables profiles to engage in a wide array of activities within the protocol, enhancing flexibility and functionality across the Allo ecosystem.

Anchor Contract (Anchor.sol)

The Anchor contract is a vital component that enhances the capabilities of profiles. It acts as an isolated enclave, allowing profile owners to securely interact with external addresses. Profile owners can execute calls to target addresses while maintaining control over the amount of native tokens sent and the data transmitted. This contract leverages the Registry contract for verifying ownership, ensuring that only authorized users can utilize its functionality.

Allo Contract (Allo.sol)

At the heart of the Allo Protocol lies the Allo contract, a versatile and feature-rich smart contract that enables efficient and decentralized fund allocation and distribution. The contract encompasses mechanisms for handling fees, managing treasury, and defining access controls. Its comprehensive design is composed of distinct functions, variables, modifiers, and events that collaboratively enable a robust fund management framework.

Key Functionality and Interactions

Profile Creation and Management:

The Allo Protocol commences with the creation and management of profiles through the Registry contract. Users can create profiles, each uniquely identified by a profile ID. Profile metadata, attestation addresses, and members can be customized during creation. The Registry contract ensures that only authorized users can manipulate profiles by verifying ownership.

Secure External Interactions:

The Anchor contract bridges the gap between profile owners and external addresses. It provides a secure gateway for profile owners to execute calls to external contracts. Profile owners can specify the amount of native tokens and data to be sent along with the call. The Anchor contract incorporates the Registry contract to validate the ownership of the profile, assuring that only legitimate owners can access its functionalities.

Advanced Fund Allocation and Distribution:

The crux of the protocol's functionality resides within the Allo contract, which enables decentralized and automated fund management. Pools are created and managed within this contract, each with customizable strategies for fund allocation and distribution. Users can create pools, define parameters, and set strategies, while administrators and managers control the actual allocation and distribution of funds.

Fee Handling and Treasury Management:

The Allo contract incorporates a comprehensive fee management system. It allows the contract owner to set and update fee parameters, control treasury addresses, and recover funds. This fee structure ensures the protocol's sustainability and adaptability. The treasury management mechanism enhances the contract's robustness by enabling controlled fund recovery.

Roles and Actors

The Allo Protocol delegates distinct roles to participants to foster efficient governance:

• Profile Owners: Users who create profiles using the Registry contract. These profiles are central to protocol interactions, offering a unique identity for users and enabling secure external calls through the Anchor contract.

• Allo Owner: Individuals who control the Allo contract, possessing the authority to manage fund recovery, fee parameters, and treasury addresses. Their role is pivotal in ensuring the protocol's financial stability.

• Profile Member: Members of a Registry profile have specific access rights as defined by the profile's owner.

• Pool Creator A user who can create new pools using custom or cloneable strategies. They can specify metadata, strategy addresses, managers, and other parameters during pool creation.

• Pool Administrator Users with administrative control over specific pools. They can manage pool managers, enabling effective pool governance.

• Pool Manager Users who manage funds within specific pools. They can allocate and distribute funds according to the pool's strategy.

Conclusion

The Allo Protocol is a technologically advanced framework for decentralized fund allocation and distribution. By employing the Registry, Anchor, and Allo contracts in tandem, the protocol establishes an ecosystem where users can securely manage their funds, define strategies, and participate in a DeFi ecosystem that embodies transparency and user-centric governance.

User Flows

Allo Contract

• Functionality: The Allo contract is the central component that manages the creation and operation of pools, strategies, and fund allocation within the Allo ecosystem. It provides functions for creating pools, funding them, allocating funds to recipients, and managing strategies.
• Interactions:
  • The Allo contract interacts with the Registry contract to manage profiles of users and pool managers. It checks whether an address is authorized to create pools or act as a manager.
  • The Allo contract interacts with individual pool strategies (such as contracts that inherit from BaseStrategy) to perform allocation and distribution of funds based on specific strategies.
  • It interacts with the Anchor contract to execute arbitrary calls to target addresses based on certain conditions.
• User Flows:
  • Users create pools using various strategies, either by providing custom strategies or cloning existing ones.
  • Pools are funded, and the allocated funds are distributed among recipients based on strategy-specific logic.
  • Users can perform batch operations to register and allocate funds to multiple recipients simultaneously.
  • The contract manages the ownership and roles of pool managers and administrators.
  • The contract owner can manage parameters like fee percentages, base fees, and approved strategies.
  • Users can recover funds from the contract.

Registry Contract

• Functionality: The Registry contract manages user profiles and their associated permissions in the Allo ecosystem. It defines user profiles, pool managers, and administrators.
• Interactions:
  • The Registry contract interacts with the Allo contract to validate whether a user or address has the required permissions to create pools or manage them.
• User Flows:
  • Users can create profiles and associate them with addresses to establish roles and permissions.
  • Profiles can define permissions for creating pools, managing pools, and other related tasks.
  • Profiles can have multiple addresses associated with them, allowing for collaboration among users.
  • The Allo contract checks with the Registry to verify whether a user has the required permissions to perform specific actions.

Anchor Contract

• Functionality: The Anchor contract allows the execution of arbitrary calls to target addresses based on specific conditions.
• Interactions:
  • The Anchor contract interacts with the Allo contract, allowing authorized users (like pool managers) to initiate calls to external addresses.
• User Flows:
  • Authorized users, such as pool managers, can initiate calls to external target addresses using the execute function.
  • The calls can include sending native tokens along with the data to the target address.
  • These calls can be triggered as part of certain conditions or events within the Allo ecosystem.
  • This contract facilitates integration with external systems and smart contracts by allowing dynamic actions based on predefined conditions.

Overall Interaction

1. Users create profiles in the Registry contract and associate their addresses with specific roles and permissions.
2. Users, identified by their addresses and associated profiles, interact with the Allo contract to create pools, allocate funds, and manage pools.
3. The Allo contract checks user profiles with the Registry to ensure that only authorized users perform certain actions.
4. Strategies (inherited from BaseStrategy) within the Allo contract handle allocation, distribution, and management of funds based on specific logic.
5. The Anchor contract allows for dynamic execution of arbitrary calls based on predefined conditions, often triggered by events in the Allo ecosystem.
6. Together, these contracts create an ecosystem where users can manage and allocate funds according to various strategies while adhering to predefined permissions and conditions.

allo-v2's Issues

Write tests for Allo.sol

Update direct grants strategy

Spec: #66

This is part of the work to create our initial batch of allocation strategies.
Strategy hitlist
Allocation module overview
Original strategy brainstorm

Write alt registry contract

Use spec from #41

Write tests for hackathon QV

Deploy to testnets

Deploy following contracts:

• Allo core
• Registry
• Donation voting

Deploy to following chains:

• Optimism Goerli
• PGN Testnet
• Sepolia
• Goerli

Create Linear QF allocation strategy

per #11

Note: As we create strategies, we'll put them in the appropriate folders and inherit from "../../interfaces/I{Type}Strategysol". We shouldn't need to create any other files to complete this. Let's see if we can hold ourselves to that.

can we move pendingOwner into a separate mapping?

          can we move pendingOwner into a separate mapping?

just because it's not an important identity information and there is no need to pass this information when you quey an identity

Originally posted by @KurtMerbeth in #24 (comment)

Write Hackathon QV strategy

Spec: #73

Strategy hitlist
Allocation module overview
Original strategy brainstorm

Create Distribute from a Mapping strategy

per #11

Note: As we create strategies, we'll put them in the appropriate folders and inherit from "../../interfaces/I{Type}Strategysol". We shouldn't need to create any other files to complete this. Let's see if we can hold ourselves to that.

Update Registry.sol

per #11, point (3)

• update Registry.sol to align with the interface

Reminders:

• No linked lists
• Solmate Roles (with each identity having two types of roles, owner and member)
• IdentityID is just an incrementer
• attestationAddress is address(uint160(uint(keccak256(identityId, name))))

Merging Strategies

We just finished out call about merging strategies into one, and then building out a library of components instead.

This has the negatives of:

• not allowing easy mix and match cloning on chain
• requires developers to think a little more
• gives a vibe that Allo protocol is doing less

But it has the positives of:

• allowing us to modularly break down the logic more clearly
• better serve developers to help them mix and match for their own use cases (a la OZ)
• simplify the on chain logic to not require communication between strategies
• not have to worry about the interfaces between strategies

If we do this, I can imagine the reorganized repo would look something like this:

core/
    libraries/
        Metadata.sol
    Allo.sol
    Aqueduct.sol
    Registry.sol

components/
    IStrategy.sol
    BaseStrategy.sol (abstract contract, inherits from IStrategy)
    recipients/
        BaseRecipientsComponent.sol
        common/
            AllocationGating.sol
        ERC721AllocationGating.sol
        TokenBalanceAllocationGating.sol
        ...
    voters/
        BaseVotersComponent.sol
        common/
        ...
    allocation/
        BaseAllocationComponent.sol
        common/
        OffchainCalculations.sol
        ...
    distribution/
        BaseDistributionComponent.sol
        common/
        Splitter.sol
        ...

Then when a developer wants to create a strategy, they could do something like the below, and just override any functions they need (like using OpenZeppelin):

contract MyStrategy is BaseStrategy, ERC721AllocationGating, MyVotingComponent, OffchainCalculations, Splitter {}

Down the road, we can create something like https://wizard.openzeppelin.com/ to deploy mix and matches strategies automatically, or even put the components on chain.

Test strategies sandbox with Optimistic Goerli

Goal is to confirm that strategies sandbox works with our deployment on OG

Consolidate Registry.sol

per #11

• merge concepts and comments from IRegistry.sol into Registry.sol
• Remove IRegistry.sol

Update simple rfp strategy

Spec: #67

This is part of the work to create our initial batch of allocation strategies. This spec is to update the simple RFP strategy here.

Strategy hitlist
Allocation module overview
Original strategy brainstorm

Consolidate Allo.sol

per #11

• merge concepts and relevant concepts from IAllo.sol into Allo.sol
• remove IAllo.sol

Repo Cleanup

Write Tiered NFT QV strategy

Spec: #71

Strategy hitlist
Allocation module overview
Original strategy brainstorm

Write tests for Base Strategy

Create Allo.sol

per #11

• let's get to a solid V1 that is as simple as possible and accomplishes everything we need, primarily to interact with the strategies (we'll worry about view functions in a bit).

Write tests for Direct Grants simple

Make project identity able to receive funds?

I know we keep having this discussion, but wanted to open it up again (for the fourth time?)

I think we may need to make it so that identities in the project registry are able to receive and hold funds (by deploying a lightweight proxy contract that people can only interact with through the Registry, similar to how Splits works). Reason being: I think it's just too natural to distribute payments to the anchor address

allo-v2/contracts/strategies/NFTVoteWinnerTakeAll.sol

Line 142 in dd1b6b1

_transferAmount(tokenToDistribute, currentWinner, amountToDistribute);

Allo.sol

Reorganize file structure

Per #11, we want to reorganize the contracts/ folder

The structure should be:

• interfaces/
  • IAllocationStrategy.sol
  • IDistributionStrategy.sol
• core/
  • libraries/Metadata.sol
  • Allo.sol
  • Registry.sol
  • Aqueduct.sol (note the slight spelling fix)
• strategies/
  • allocation/
  • distribution/

Note: this removes the utils/ folder (which just duplicates the logic in core/libraries/Metadata.sol).

Write tests for RFP Simple

Write Simple QV strategy

Spec: #69

Strategy hitlist
Allocation module overview
Original strategy brainstorm

WHOA BUDDY — HAVE ZACH REVIEW BEFORE STARTING THE BELOW TICKETS

Write no application contract

Spec here: https://github.com/allo-protocol/allo-v2/tree/main/contracts/strategies/allocation/no-application

Distribution Strategy 1 : Splitter Distribution

Update contracts to use address as recipient ID

We decided that an address will be the core recipientId that persists throughout the Allo contracts.

Changes we need to make include (please add other tasks as needed):

• Change applyToRound() to addRecipient() respectively.
• Revise DonationVoting strategy to account for this. ** not sure yet what branch to work from for this yet. We may want to merge the add-strategy branch first to work from a clean main.

Allocation Strategy 1 : Offchain QF

Write tests for QV NFT tiered

Write tests for QV Simple

Update donation voting contract to send funds to donors

Currently the donation voting contract holds the donation funds — those funds should be sent directly to the recipients instead of being held temporarily.

Registry.sol

Skirting Fees

from @zobront
Starting a thread for us to discuss the fee skirting issue. The issue is that, since projects choose their own strategies, we can't have Allo protocol fees taken on the strategy, or users can easily skirt it. It needs to live on the core Allo.sol contract, but that poses challenges because when fees are taken may not be consistent across projects.

CURRENT WORKING SOLUTION

1. When a pool operator calls createPool(), they can add tokens and a fee is taken directly at that point. The total balance with which the pool has been funded is stored in the Allo.sol contract.

2. At any point, the operator can all fundPool() and add additional funds, and fees are taken at that point. The total balance with which the pool has been funded is updated in the Allo.sol contract.

3. When users call allocate() in a strategy that requires them to send additional funds (ie Quantitative Funding), that can be handled in two ways:
   a) If the funds go directly to the recipient, our prebuilt strategies take the fee directly at that point. If they deploy their own strategy, they could skirt this fee.
   b) If the funds go into the distribution strategy for later distribution, a function is called on Allo.sol that updates the total funding amount for the pool and takes the fee.

4. In order to trigger payouts, we call finalize() on Allo.sol. This checks the balance of the distribution strategy and, if it is greater than the stored amount of what it should be, takes any excess balance and transfers it to the Allo treasury.

ISSUES

1. An allocation strategy can be written that sends allocations straight to the recipient and pays no fees.

2. A distribution strategy can be written that skips over the finalize() function. We could add a flag to the main contract that is is now claimable once finalize() is called (which would stop claimers from using the core contract's claim() function if their distribution strategy skirts this step) but even that isn't perfect, because it doesn't account for distributions with ongoing phases.

---

from @KurtMerbeth

Additional Question, since we will have Pools with and without distribution strategies:
Are we taking only fees from the distribution, or also from allocations? @nfrgosselin

---

from @thelostone-mc

How would we ensure that the funds aren't sent directly to the DistributionStrategy and bypass the fundPool function ?

---

from @codenamejason

Can we do this by only allowing the Allocation Strategy to know the Distribution Strategy address or interact with the Distribution Strategy as the only owner? @thelostone-mc

---

from @nfrgosselin

Additional Question, since we will have Pools with and without distribution strategies:

Can you say more @KurtMerbeth? What types of pools wouldn't have distribution strategies?

Are we taking only fees from the distribution, or also from allocations?

My thinking was that the protocol would only take fees from the core pool (i.e. the distribution). Allocations could become separate income streams for strategy developers if they're creating novel strategies. So Gitcoin could deploy QF strategies that we technically take fees from, but for pools using those strategies we would actually be making fees on the distribution and the allocation. Another scenario are pools using externally-developed strategies, where the protocol would collect fees on the distribution and the strategy develop would collect fees on the allocation.

Donation voting with Passport

Strategy hitlist
Allocation module overview
Original strategy brainstorm

Bootnode Direct Grants

This spec is for the strategy that will update Bootnode's direct grants implementation for Allo v2.

Strategy hitlist
Allocation module overview
Original strategy brainstorm

Unused custom error in `DirectGrantsSimpleStrategy`

This error is declared but never used in the contract:

allo-v2/contracts/strategies/direct-grants-simple/DirectGrantsSimpleStrategy.sol

Line 48 in 3bc2f0e

error INVALID_RECIPIENT();

Enhancement ideas

From @KurtMerbeth

I would like to share my thoughts after walking through the strategy miro.
Maybe I can have your thoughts on it.

1. I would like to propose the addition of check functions for the functions in the core contract to enhance safety and usability:

   Examples:
   claim(uint _poolId, bytes memory _data) external;
   Proposed Check Function: isClaimable(uint _poolId);

   applyToPool(uint _poolId, bytes memory _data) external
   Proposed Check Function: canApply(uint _poolId, bytes memory _data)

   etc..

   These check functions will enable frontends, users and other contracts to verify if executing the corresponding operations is possible or not, based on predefined conditions or requirements.

2. I would like discuss the idea of introducing an execute function that would enable calling custom functions within Strategies through the Core contract. This feature aims to streamline pool handling and provide a unified approach for interacting with both standard and custom functions within Strategies.

   Pros:

   • Simplified Pool Handling: With the execute function, users and developers can interact with Strategies seamlessly through the Core contract, regardless of whether the functions are standard or custom. This streamlines pool handling and reduces the need to switch between different contracts, enhancing usability and developer experience.

   • Centralized Transaction Flow: By consolidating the function calls within the Core contract, the transaction flow becomes more centralized and easier to follow. This can improve the clarity and maintainability of the codebase.

   Cons:

   • Potential Security Risks: Introducing an execute function that allows arbitrary function calls to custom Strategy functions carries inherent security risks. Careful consideration must be given to access control and validation mechanisms to prevent unauthorized or malicious function executions.

   • Increased Complexity: Implementing the execute function adds complexity to the Core contract and may require additional validation and error handling logic. This can increase the development and testing effort required to ensure the robustness and reliability of the system.

3. Currently, the Core contract has a function called claim, but as we introduce distribution strategies that handle fund distribution to users, the name claim seems in some cases a bit misleading since claim is usually used as an action executed by an user.

   To address this, I suggest adding an adtional function called distribute to the Core contract. This function will be responsible for initiating the distribution of funds to users by the pool owner.

   Alternatively, we could think about introducing a new name which represents both, claim and distribute. I don't have any suggestions right now, but I was thinking about a more generic name like handleDistribution.

---

from @thelostone-mc

I would like to propose the addition of check functions for the functions in the core contract to enhance safety and usability:

I do like having these for enhancing safety check

Adding execute function.
I do see the benefit in flows like milestone based payout where :

• project owner submit milestone
• this function would exisist on the allocation strategy and in our current interface , the project owner would be forced to interact with the allocation contract instead of round
• Having the execute solves this but this feels quite scary. we could make it safer by saying no re-enterancy and maybe not payable.
  I'm split on this

rename claim as handleDistribution

In favour of this

---

from @KurtMerbeth

Having the execute solves this but this feels quite scary. we could make it safer by saying no re-enterancy and maybe not payable. I'm split on this

I feel the same. I wanted to encourage some thought on this matter.
Perhaps there is a viable way to implement something like this while ensuring safety. On the other hand, it's possible that the potential risks outweigh the benefits. Do we even consider it a problem worth addressing?

The idea of having one entry point for everything came up while I was going through the diagrams.

---

from @thelostone-mc

Would recommend having a updatePool on the interface cause we would def want to update the metadata
https://github.com/zobront/allo/blob/main/interfaces/IAllo.sol#L18

Also not relevant to the interface but we might want to add OZ multi-call to allow folks to allocate to multiple pools and stuff

---

from @codenamejason

I think multi-call here is a great idea and good call out @thelostone-mc as well as adding the updatePool() to the interface.

Do we need to return any data on an update or just emit an event?

function updatePool(bytes memory _data) external payable returns (bytes memory);

rename allowedStrategies -> cloneableStrategies

Incorrect `metadataRequired` initialization in `DirectGrantsSimpleStrategy`

allo-v2/contracts/strategies/direct-grants-simple/DirectGrantsSimpleStrategy.sol

Line 109 in 3bc2f0e

_metadataRequired = _metadataRequired;

It should have been:

metadataRequired = _metadataRequired;

Rename identity -> profile

Write tests for RFP Committee

rapped voting 🎤

Write tests for Donation voting

Write Governance QV strategy

Spec: #72

Strategy hitlist
Allocation module overview
Original strategy brainstorm

Action Plan

Thanks for the call this morning guys, and sorry I have been not as on top of it the past couple days.

I can feel things starting to sprawl a little bit, so want to make sure our actions for the rest of this week and really precise and focusing, rather than expansive.

Here is what I think needs to happen:

1) GET RID OF MOST INTERFACES

We've lost a single source of truth on a lot of this stuff. We can split sections out later, but for now, please remove IAllo.sol and IRegistry.sol and merge all the concepts and relevant comments into Allo.sol and Registry.sol. Then we'll be in a place to work to make those files perfect.

(The strategies can keep their interfaces because that's the only possible single source of truth, since they will all be different. I would recommend we delete the BaseAllocation.sol and BaseDistribution.sol and simply inherit straight from the interface in each strategy we create.)

2) REORGANIZE FILES

This is small but will help. Let's adjust the file structure to be:

• interfaces/
  • IAllocationStrategy.sol
  • IDistributionStrategy.sol
• core/
  • libraries/Metadata.sol
  • Allo.sol
  • Registry.sol
  • Aqueduct.sol (note the slight spelling fix)
• strategies/
  • allocation/
  • distribution/

Note that this removes the utils/ folder (which just duplicates the logic in core/libraries/Metadata.sol).

As we create strategies, we'll put them in the appropriate folders and inherit from "../../interfaces/I{Type}Strategysol". We shouldn't need to create any other files to complete this. Let's see if we can hold ourselves to that.

Let's try to push this pretty quickly too, so we're operating from a clean base. This may take some time though, and it'll require consolidating interfaces and contracts that may be different, so don't rush it!

3) MAKE MAJOR REGISTRY.SOL FIXES

The current Registry.sol seems to be based on the old one, and doesn't align with the interface. I think this needs to be right before we start building complete flows.

I would recommend creating this contract to the best of our ability first. It's relatively self contained and we already know the logic.

Reminders:

• No linked lists
• Solmate Roles (with each identity having two types of roles, owner and member)
• IdentityID is just an incrementer
• attestationAddress is address(uint160(uint(keccak256(identityId, name))))

4) CREATE ALLO.SOL

I think the logic on here will actually be relatively simple, since so much work is being pushed to strategies. So let's get to a solid V1 that is as simple as possible and accomplishes everything we need, primarily to interact with the strategies (we'll worry about view functions in a bit).

5) CREATE ONE STRATEGY PAIR

Pick the easiest possible strategy pair and code them up so the whole thing works.

I would recommend doing Linear QF for allocation and "distribute from a mapping" for distribution, but whatever you guys want.

6) VIEW FUNCTIONS

Think about if there are any view functions we know we need to add, both to the strategy interfaces and to core. Today, we spoke about amountClaimable(), isClaimable() and canApply().

Also consider whether there are additional states besides None, Pending, Approved, and Rejected that should be on the base status enum that projects need to implement.

---

Let's focus on those things first. There are other features worth exploring (like multicall) but I think we will be better served to consider those peripheral things, as well as building out the roster of strategies and making sure they all work, once the core piece is built.

I recognize that everything from STEP 4 on will rely on me figuring out the "finalize question" and fee skirting, so I will focus on that to make sure it's unblocked by the time you get there.

---

How does this plan sound to everyone? If good, I would say the Allo team can choose how to divide things up to tackle STEPS 1, 2, 3 (preferably in order and not in parallel, as there's a lot of restructuring that will make merging PRs messy) while I work on the "finalize stuff" over the next 2-3 days, and then we should be in a good place to bring all that together and start getting the rest of the system working.

Please include me as a review on these PRs too, so I can stay in the loop on new work being pushed.

Thanks!

Write tests for Registry.sol

Write RFP Committee strategy

Spec: #68

Strategy hitlist
Allocation module overview
Original strategy brainstorm

Update donation voting spec

Spec: #65

This is part of the work to create our initial batch of allocation strategies. This spec is for the strategy that will replace the current Quadratic Funding implementation in Grants Stack.

Strategy hitlist
Allocation module overview
Original strategy brainstorm