discuss: Building the Payout Architecture

Hey, thelostone-mc (Aditya) here who's a team lead on the Allo Protocol team. Based on recent feedback from the governance post, I'd like to experiment by bring the community into the dicussion / sharing our thoughts as we build out milestones. Consider this a quick checkin from the Allo team with the community and keeping you in loop as we brainstorm and build feature. Would love feedback on this so that we can improve on this. TLDR: We are building the payout layer onto the allo protocol and would love to share how we are going about it in an effort to be more vocal about how are progressing the protocol. All our discussion / code / issues are open source and on Github, so if you'd like to be more involved -> that's the place I'd encourage you to checkout # discuss: Building the Payout Architecture This document aims to outline the design for - Payout architecure - Protocol Fee architecure ## Payout Architecture The payout contract like the voting contract can come in variation of flavours such as: - Bulk Transfer Payout - Merkle Claim - Drip Transfer ### What are we building The Allo team will focus on defining the interface of the PayoutStrategy (called IPayoutStrategy) via an abstract contract. Any flavour of PayoutStrategy being built would have import this abstract contract and that would offer - base function defined in the PayoutStrategy - useful modifier which may be useful for the actual implementation - virtual functions which would be specific to PayoutStrategy flavour We will also be building out MerklePayoutStrategy flavour importing this interface. This would be used as the intial payout mechanism for the rounds run on Allo and would serve as as an example for other flavour to be built. ### How are these contracts deployed ? The actual PayoutStrategy themselves would follow a factory pattern. This means every payoutstrategy would comprise of 2 contracts maintained by the Allo Team - **PayoutStrategyFactory contract** (creates PayoutStrategyImplementation for every round) - **PayoutStrategyImplementation contract** (containing the actual payout implementation) This is similar to the design of the Round, Program, and QFVotingStrategy is built. This allows us the benefits of : - Isolate payout contracts per round - Creating clones of the payout contract (making deployment cheaper for round operator) - Give us room to upgrade our contracts as the protocol evolves ### Functions offered by the IPayoutStrategy - **withdrawFunds** : timelocked function which enables operator to withdraw pot money to a preset wallet after a fixed time - **updateDistribution** : TBD by the acutal PayoutStrategyImplementation - **payout**: : TBD by the acutal PayoutStrategyImplementation ## Protocol Fee Architecture This while a seperate feature goes hand in hand with payout and hence is being together. The v1 iteration aims to build the foundation which allows - Operator to edit fee percentage until the round ends - fees are collected at the time of payout - funds would be kept in the round contract and sent to payout contract at the time of payout Once we've built this layer out, and run a tests, we'll evolve this feature and add restrictions in terms of updating fee percentage. ### Are the current contracts being upgraded ? Yes, the following contracts would need to be updated to build out the flow : - **RoundFactory** - to set the protocol treasury address - **RoundImplementation** - to charge the protocol fee and invoke PayoutStrategy payout function Any changes will be document and wll be backward compatible The actual flow : <iframe width="768" height="432" src="https://miro.com/app/live-embed/uXjVPsZg30I=/?moveToViewport=-16500,-3269,15262,7877&embedId=505109592713" frameborder="0" scrolling="no" allow="fullscreen; clipboard-read; clipboard-write" allowfullscreen></iframe> Shout out to @olsen and @andrea who helped review this document and the Allo engineering team who helped design this architecture To validate this design, I've taken a stab at writing some code to see what changes would be needed and the kinds of upgrades which would need to be done https://github.com/gitcoinco/grants-round/pull/1077