-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MVP of assurance contract contracts + tests #44
base: dev
Are you sure you want to change the base?
Conversation
} | ||
|
||
function _allocate(address[] memory, uint256[] memory, bytes memory, address) internal virtual override { | ||
revert("AssuranceContract: Allocate not implemented"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
need to integrate the payout/refund txns here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why? Isnt allocate in this case the pledge
logic?
revert("AssuranceContract: Allocate not implemented"); | ||
} | ||
|
||
function _distribute(address[] memory, bytes memory, address) internal virtual override { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
would be nice if i just got a distribute function that could natively handle any type of distribution (merkle, drips, or otherwise)...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree. In this example however what would distribute do? like allocate - pledge, I think distribute should hold the logic of claimFunds
} | ||
|
||
function _register(address[] memory, bytes memory, address) internal virtual override returns (address[] memory) { | ||
revert("AssuranceContract: Register not implemented"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think the current allo pool uses just naked addresses. need to use allo registry items per https://github.com/allo-protocol/allo-v2.1/blob/dev/contracts/core/Allo.md#register-recipient.
would be nice if this could be inherited from an upstream contract..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You could make use of the RecipientsExtension
. Using the _register
from the extensions includes this check
allo-v2.1/contracts/strategies/extensions/register/RecipientsExtension.sol
Lines 293 to 296 in c583e0e
if (_recipientIdOrRegistryAnchor != address(0)) { | |
if (!_isProfileMember(_recipientIdOrRegistryAnchor, _sender)) { | |
revert UNAUTHORIZED(); | |
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Took a peek, great effort! 🔥
I left a couple of comments when it comes to the logic for allocate
and distribute
. An improved design could be, having an extension AssuranceExtensions
handling the logic for pledging and refunding along with some hooks, for added flexibility for custom code, and having a strategy CrowdFundAssuranceStrategy
that uses this extension and integrates pledge into allocate (from extension) and claim funds for distribute to beneficiary.
} | ||
|
||
/// @notice Mapping of pool IDs to Campaign structs | ||
mapping(uint256 => Campaign) public campaigns; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see you have this mapping here, does this mean the strategy would be re-usable for multiple campaigns after each one finishes? If so it would be cleaner to also include a createCampaign
function for pool managers that will basically create the campaign like you do in initialize
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i believe pool ID
here is also reffering to the ID of the campaign, this might confuse people with Allo's pool IDs
} | ||
|
||
function _allocate(address[] memory, uint256[] memory, bytes memory, address) internal virtual override { | ||
revert("AssuranceContract: Allocate not implemented"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why? Isnt allocate in this case the pledge
logic?
revert("AssuranceContract: Allocate not implemented"); | ||
} | ||
|
||
function _distribute(address[] memory, bytes memory, address) internal virtual override { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree. In this example however what would distribute do? like allocate - pledge, I think distribute should hold the logic of claimFunds
} | ||
|
||
function _register(address[] memory, bytes memory, address) internal virtual override returns (address[] memory) { | ||
revert("AssuranceContract: Register not implemented"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You could make use of the RecipientsExtension
. Using the _register
from the extensions includes this check
allo-v2.1/contracts/strategies/extensions/register/RecipientsExtension.sol
Lines 293 to 296 in c583e0e
if (_recipientIdOrRegistryAnchor != address(0)) { | |
if (!_isProfileMember(_recipientIdOrRegistryAnchor, _sender)) { | |
revert UNAUTHORIZED(); | |
} |
An assurance contract is a type of agreement in which participants commit to funding a public good or project only if a threshold of contributions is met. If the total pledged contributions reach the predetermined amount, the project moves forward, and participants fulfill their financial commitments. If the threshold isn't met, no one is obligated to contribute, and the project does not proceed.
This mechanism reduces the free-rider problem in public goods funding by ensuring that participants only pay if the project can be fully funded and implemented. It provides a way to align the interests of contributors, ensuring that everyone’s contributions are contingent on the collective success of the funding effort.
This PR adds an assurance contract and passing tests to the allo 2.1 repo
Features
Run it yourself with