See https://potlock.org/better-pots

New features:

• 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
• Allow payouts to be issued individually, include a memo
• Allow owner to control matching pool / redistribute matching pool funds if they desire (are there any limitations for this?)
• 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
• Allow owner/admins to blacklist accounts (donors)
• 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:

• 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?
• 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?
• Fix this net_amount bug
• 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]

Description

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

Alternatives

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

Risks

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

Acceptance Criteria

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

Additional Information

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