lachlanglen commented 3 months ago

New features:

[x] Add tags on a Pot, perhaps also a pot_type field, to indicate to frontends which kind of Pot this is and how it should be interacted with
[x] Allow payouts to be issued individually, include a memo
[x] Allow owner to control matching pool / redistribute matching pool funds if they desire (are there any limitations for this?)
[x] Add optional compliance_period_ms and compliance_end_ms (similar to cooldown period) as a way to get projects to complete required steps to get funds before they are forfeited/released/redistributed
[x] Allow owner/admins to blacklist accounts (donors)
[x] Allow owner/admins to blacklist projects, even after round is live or has ended (this may have no impact within the contract, but is an on-chain external indicator)

Bugfixes/Chores:

[x] Remove versioning (not needed since contracts are locked and therefore can't be upgraded anyway, just increases code size and deployment cost)
[ ] Handle case where a payout fails so payout can be retried e.g. with new account (currently all_paid_out is set to true in admin_process_payouts and isn't reverted to false in the case of a payout failure, and this prevents admin_process_payouts from being run again) / _OPEN QUESTION: Figure out solution with all_paid_out, e.g. should be set manually by admin? Or determined on front-end?_
[x] Fix this bug - it saves the original transaction signer as the donor_id on the Donation record, which in the case of a DAO proposal will record the donor as the final account that approved the proposal and triggered the function call, not the DAO itself. We should have really saved env::predecessor_account_id() as donor_id in memory at the top of the function call stack and passed it through.
[ ] Don't allow any settings changes once pot is complete - OPEN QUESTION: What is definition of pot being complete?
[x] Fix this net_amount bug
[x] Return empty vec when no donations for donor, rather than unwrapping/panicking

Backlog:

[ ] Fill out events (not really necessary at this point since we are successfully indexing based on method calls currently, with the exception of pot_config updates)
[ ] Allow comment threads on applications
[ ] Options to require github, tg, website, deck, team members etc. for application

Summary

[Brief overview of the enhancement and why it is needed or desired]

Motivation

[More detailed explanation of the motivation for the enhancement, including any benefits it would provide]

[Detailed description of the enhancement, including how it would work and any design considerations]

[Discussion of any alternative solutions that were considered and why the proposed solution is preferred]

[Identification and mitigation of any potential risks associated with the enhancement]

[List of criteria that must be met for the enhancement to be considered accepted]

[Any other relevant information, such as links to related issues or pull requests]

lachlanglen commented 3 months ago

@codingshot if you have any list of items you want fixed/added in v2 of the Pot contract, can you add here? Thanks

codingshot commented 1 week ago

Allow owner to control matching pool / redistribute matching pool funds if they desire (are there any limitations for this?)

i think still to just projects or refund account, so can't just send to wherver needs to be projects
payouts individually should alway allow set (mark as apid and read if person has been paid)