From 0055e652cdc9b9cacf111d21126d757d8ae42c83 Mon Sep 17 00:00:00 2001 From: Marco Date: Fri, 3 Jan 2025 20:33:35 +0100 Subject: [PATCH 1/8] typo Allo.md --- contracts/core/Allo.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/contracts/core/Allo.md b/contracts/core/Allo.md index efb09a1f4..b7f172e0b 100644 --- a/contracts/core/Allo.md +++ b/contracts/core/Allo.md @@ -220,7 +220,7 @@ sequenceDiagram * **Strategy** Smart contracts implementing fund allocation and distribution logic for each pool. Strategies can be custom or cloneable and determine how funds are managed within a pool. -In summary, the "Allo" smart contract provides a framework for creating and managing pools with customizable fund allocation and distribution strategies. It leverages access controls, mappings, and functions to enable various actions within the protocol. The contract is designed to support a ecosystem, enhancing the efficiency and transparency of fund management in Ethereum-based applications. +In summary, the "Allo" smart contract provides a framework for creating and managing pools with customizable fund allocation and distribution strategies. It leverages access controls, mappings, and functions to enable various actions within the protocol. The contract is designed to support an ecosystem, enhancing the efficiency and transparency of fund management in Ethereum-based applications. ## User Flows @@ -304,4 +304,4 @@ In summary, the "Allo" smart contract provides a framework for creating and mana ### Distribute Funds to Recipients * Users can distribute funds to recipients using a pool's distribution strategy by calling the `distribute` function. - * The function requires the `_poolId`, `_recipientIds`, and `_data` as parameters, and it passes the data to the strategy for distribution. \ No newline at end of file + * The function requires the `_poolId`, `_recipientIds`, and `_data` as parameters, and it passes the data to the strategy for distribution. From 0b7b26b276dc14a892d6b49b35c9e158ff5006b7 Mon Sep 17 00:00:00 2001 From: Marco Date: Fri, 3 Jan 2025 20:34:16 +0100 Subject: [PATCH 2/8] typo IStrategy.sol --- contracts/core/interfaces/IStrategy.sol | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contracts/core/interfaces/IStrategy.sol b/contracts/core/interfaces/IStrategy.sol index 0e2ed5425..d43d168d4 100644 --- a/contracts/core/interfaces/IStrategy.sol +++ b/contracts/core/interfaces/IStrategy.sol @@ -93,7 +93,7 @@ interface IStrategy { /// @return The ID of the strategy function getStrategyId() external view returns (bytes32); - /// @notice Checks whether a allocator is valid or not, will usually be true for all strategies + /// @notice Checks whether an allocator is valid or not, will usually be true for all strategies /// and will depend on the strategy implementation. /// @param _allocator The allocator to check /// @return Whether the allocator is valid or not From f43f89af5eebc9e45b02b4b5696b5deeeed03386 Mon Sep 17 00:00:00 2001 From: Marco Date: Fri, 3 Jan 2025 20:34:44 +0100 Subject: [PATCH 3/8] typo SpecTemplate.md --- contracts/strategies/SpecTemplate.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contracts/strategies/SpecTemplate.md b/contracts/strategies/SpecTemplate.md index d5cebf0e1..e865fa948 100644 --- a/contracts/strategies/SpecTemplate.md +++ b/contracts/strategies/SpecTemplate.md @@ -25,7 +25,7 @@ Explain the logic for determining how recipients are added to the strategy's poo - What criteria determine the eligibility of a recipient to register in this strategy? Are there any specific requirements or conditions? - Are there any additional custom functions or conditions for verifying recipient eligibility? - **Recipient information** - - How does a recipient identify themselves? Is it through an address like msg.sender, do they need an profile registered at the `Registry` contract, or another mechanism? + - How does a recipient identify themselves? Is it through an address like msg.sender, do they need a profile registered at the `Registry` contract, or another mechanism? - If through the Registry, can the pool creator set a custom registry? - Which address is returned by `registerRecipient` and represents the `recipientId`? - Can the address that receives the funds be different from the recipient's profile? From 892f37a869b73838a30d0db05e2386fc4be5e2f3 Mon Sep 17 00:00:00 2001 From: Marco Date: Fri, 3 Jan 2025 20:35:12 +0100 Subject: [PATCH 4/8] typo Spec.md --- .../strategies/_poc/donation-voting-custom-registry/Spec.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contracts/strategies/_poc/donation-voting-custom-registry/Spec.md b/contracts/strategies/_poc/donation-voting-custom-registry/Spec.md index 9bb3ffded..c954d1523 100644 --- a/contracts/strategies/_poc/donation-voting-custom-registry/Spec.md +++ b/contracts/strategies/_poc/donation-voting-custom-registry/Spec.md @@ -31,7 +31,7 @@ In this strategy, recipients must submit an application and be approved by pool - prospective recipients must provide the projects address as `recipientId`, which serves as the unique identifier for their registration - **Recipient eligibility** - Pool manager has the option to enable two separate eligibility requirements on this contract: - - Requiring recipients to have an registry profile in order to apply + - Requiring recipients to have a registry profile in order to apply - Requiring recipients to submit answers to questions, stored in metadata - This metadata may include information for the front end on required / optional questions, but the contract only needs to check for whether metadata has been submitted - The pool manager should have a function that enables them to edit the pool metadata, which is callable at any point From bf33bfa12d18bc7ac355f2ab875c9373c9b6707f Mon Sep 17 00:00:00 2001 From: Marco Date: Fri, 3 Jan 2025 20:35:43 +0100 Subject: [PATCH 5/8] typo README.md --- contracts/strategies/_poc/micro-grants/README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/contracts/strategies/_poc/micro-grants/README.md b/contracts/strategies/_poc/micro-grants/README.md index 1f86e6b69..fb2d720e0 100644 --- a/contracts/strategies/_poc/micro-grants/README.md +++ b/contracts/strategies/_poc/micro-grants/README.md @@ -186,7 +186,7 @@ Only in `MicroGrantsStrategy.sol`: ### Allocating to a Recipient -* Valid Allocator initiates a allocation request +* Valid Allocator initiates an allocation request * An allocator can vote only once for a recipientId * An allocator can choose to: accept/reject a recipient * If the allocator accepts the recipient, we check to see if the recipient has approvals which are equal to the approvalThreshold, then the funds are distributed to the recipient @@ -197,4 +197,4 @@ Only in `MicroGrantsStrategy.sol`: * Verifies if sender is authorized to withdraw funds. * Checks if the pool is inactive. * Decreases the pool amount by the requested withdrawal amount. -* Transfers the requested amount to the sender. \ No newline at end of file +* Transfers the requested amount to the sender. From 5ea1bc489126ecf5ec7387391e2c6fbf3ad1258c Mon Sep 17 00:00:00 2001 From: Marco Date: Fri, 3 Jan 2025 20:36:15 +0100 Subject: [PATCH 6/8] typo Spec.md --- contracts/strategies/_poc/qv-hackathon/Spec.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contracts/strategies/_poc/qv-hackathon/Spec.md b/contracts/strategies/_poc/qv-hackathon/Spec.md index 9b56c3ebf..c2f0cde90 100644 --- a/contracts/strategies/_poc/qv-hackathon/Spec.md +++ b/contracts/strategies/_poc/qv-hackathon/Spec.md @@ -16,7 +16,7 @@ In this strategy, recipients do not need to apply — they are automatically add - update metadata for this pool ### Allocation logic -In this strategy, only wallets that hold a specific NFT are eligible to allocate. Allocations can only be submitted during a allocation window that is set by the pool manager. Each allocator gets a budget of "voice credits", which they can use to "purchase" votes on as many recipients as they would like. The number of votes each allocator can give to a recipient is equal to the square root of the number of voice credits they spend on that specific recipient. Votes can be fractional. +In this strategy, only wallets that hold a specific NFT are eligible to allocate. Allocations can only be submitted during an allocation window that is set by the pool manager. Each allocator gets a budget of "voice credits", which they can use to "purchase" votes on as many recipients as they would like. The number of votes each allocator can give to a recipient is equal to the square root of the number of voice credits they spend on that specific recipient. Votes can be fractional. - **Allocator Eligibility** - Wallets are only eligible if they hold a specific NFT. - Pool managers must have the ability to configure which NFT is required in order to vote. From 0c563bde0a02f56bfadfc75001d7d682c06b91e8 Mon Sep 17 00:00:00 2001 From: Marco Date: Fri, 3 Jan 2025 20:36:56 +0100 Subject: [PATCH 7/8] typo Spec.md --- contracts/strategies/_poc/qv-nft-tiered/Spec.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contracts/strategies/_poc/qv-nft-tiered/Spec.md b/contracts/strategies/_poc/qv-nft-tiered/Spec.md index c09b4cce1..cf3883b45 100644 --- a/contracts/strategies/_poc/qv-nft-tiered/Spec.md +++ b/contracts/strategies/_poc/qv-nft-tiered/Spec.md @@ -32,7 +32,7 @@ In this strategy, recipients must submit an application and be approved by pool - If a recipient's current status is `Accepted`, then their application info is updated and their status is changed to `Pending` (global and local) ### Allocation logic -In this strategy, pool managers are able to set multiple NFTs as their eligibility gates for allocators. As long as a wallet holds at least one of those NFTs they are marked as `eligible`. Allocations can only be cast during a allocation window that is set by the pool manager. Each allocator gets a budget of "voice credits", which they can use to "purchase" votes on as many recipients as they would like. The budget of voice credits is dictated by the NFT(s) that the allocator holds. The number of votes each allocator can give to a recipient is equal to the square root of the number of voice credits they spend on that specific recipient. Votes can be fractional. +In this strategy, pool managers are able to set multiple NFTs as their eligibility gates for allocators. As long as a wallet holds at least one of those NFTs they are marked as `eligible`. Allocations can only be cast during an allocation window that is set by the pool manager. Each allocator gets a budget of "voice credits", which they can use to "purchase" votes on as many recipients as they would like. The budget of voice credits is dictated by the NFT(s) that the allocator holds. The number of votes each allocator can give to a recipient is equal to the square root of the number of voice credits they spend on that specific recipient. Votes can be fractional. - **Allocator Eligibility** - Pool managers need a function to indicate which NFTs will be used to determine eligibility in the pool. - As part of this, they need to be able to indicate how many voice credits each NFT is worth. For example, a wallet holding `NFT-A` may get 100 credits, while a wallet holding `NFT-B` may get 250 credits. From 3127616f4296703e117fed2b7c96f98e8ae65717 Mon Sep 17 00:00:00 2001 From: Marco Date: Fri, 3 Jan 2025 20:37:26 +0100 Subject: [PATCH 8/8] typo MockStrategy.sol --- test/utils/MockStrategy.sol | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/test/utils/MockStrategy.sol b/test/utils/MockStrategy.sol index d2364f7bc..5edd0d5d4 100644 --- a/test/utils/MockStrategy.sol +++ b/test/utils/MockStrategy.sol @@ -80,7 +80,7 @@ contract MockStrategy is BaseStrategy { return PayoutSummary(_recipientId, 0); } - // simply returns whether a allocator is valid or not, will usually be true for all + // simply returns whether an allocator is valid or not, will usually be true for all function _isValidAllocator(address _allocator) internal view override returns (bool) { surpressStateMutabilityWarning; return _allocator == address(0) ? false : true;