# LTIP May ## May 30th Updates: https://github.com/grants-stack-frontier/allo-v2/blob/49a4ab64286733ae4f2f01b25f2faa14e19deebf/contracts/strategies/ltip-simple/README.md ### Actions: - Keep fetching data as we have been. - We deploy the most basic version of the Voting contract: - Indexing - What we do next: - While we build out the frontend BB will research snapshot - Round manager will call the Allo contracts directly: - TO WHAT EXTENT IS ALLO INDEXING THE DATA WE NEED??? ### Next steps: { ProjectId, description, amount, } - PLEASE SOME DIAGRAM - Chiali: - Design a UI for applying to a UI using a project - If project owner visits project page, show ability to apply to program (Small, mid, large | amount) - Make sure to include all the necessary data (Reason, statement, external reference (link) get rest from an application from projects) - We also need a payout step, for example once a project is accepted, and the requirements are fulfilled there needs to be a pay to allow someone to transfer funds to applicant - Deploy the strategy as it is: **Bitbeckers** - Set up a round (Program) with us as operators: **Bitbeckers init script** - Create a project: **Jip** (needs to be registered in allo registry) - Submit an application: **Jip** In the UI - Approve application (Operators): **All team** In the UI ##### Where is all the data????????????????? ### Entities: - Program: (What is a round, small, mid and large cap) - Project: (The user who has a profile) - Application: - Project is applying to Program ##### Program: - This stores the applications - This manages the voting data - This handles the funds, as well. ##### Projects: - Sourced from Grantstack: So creation and read is from the grantstack graph - Can apply to multiple PROGRAMS - Can a project apply to the same program multiple times: - Cannot apply twice at the same time - Cannot apply twice in a row ##### Applications: - They are not being indexed anywhere, as they are on the CUSTOM round instance. - The state of the application is stored on IPFS. After being created on frontend. - What IPFS solution are we using on the frontend - Pinata Does it support JSON - The pointer to IPFS is stored on the application which is stored on the program instance ##### Council Members: - Let's get them from Tally: - All council members are not operators for all programs - On intialization, we fetch the council members, can we make it a readable field on the program contract - this reading happens on Allo-stack - They are members of a safe? - Defined at round creation - They have admin rights on the round ------------------ ## Zakk meeting: Next meeting: - Morning of 13th June - 5pm - 6pm CET - On perpetual rounds: - Submitting applications phase is timed in original contracts - It will be a continious process while different projects can be in different phases (review, in pay, etc..) - Program will run for a year, in previous programs it only ran for a few weeks/months - JIP: - Payouts are not done in a single point in time for all applications - How many types of programs, what is the bar referring to? - Total amount that is up for grabs - Replinish amounts within programs - Program creation flow: - It is not a priority to build out a program creation flow, but the optional should be available. - Indicate the program creation flow is part of the next version - Infrastructure: - totally separate project, will not be merged into grantstack - We must bring our fork up to date - On maintainance: - We need to provide ongoing support - There will be multiple handoffs to manage: - 1. From RG to Gitcoin - 2. From Gitcoin to Arbitrum ### Bitbeckers: - On perpetual round: - No end date - can people apply multiple times? Can they reapply if rejected - Expect to be put in touch with tech people - On indexing: - 3 separate data sources - Will we use Allo Indexer? - It's looking like a no, so we will need to run our own indexer - We could run our own graph to index the contract - Weighing 6 different APIs in exchange for pointing and pulling from Contract directly - Should we consider using a trad DB - Council vs Delegation issues: - How do we secure from allowing - Introducing snapshots: look into tally - Openzepplin is worth looking into - Research this topic and make a decision once BB and Zakk agree #### Scenarios: 100m available, once it's all distributed: - Program is done - Or program funds replenished - People can still apply to program ----------------------- ## Action plans: - Bitbeckers must meet with Zakk - A decision needs to be made on whether they or us will handle the issue - We are already running forks and we can boot up Vercel and revive the infrastructure. - Questions: - Is this perpetual rounds? - Are the only 3 programs? (small medium large) - Is round admin something we need to build for? - Who is running the Infrastructure? - Where do they expect to operate a round? - On their site? - Is it a separate application build on protocol, or is it grantstack ### What needs to happen: - Indexing new strategies Bitbeckers built: - Voting: - Hedgy: Vesting plan for NFT - Strategy is new, so infra might not work for it. ### Strategy: - In a round a council member creates a round, which creates an instance of custom strat - Project applies to round with application amount - Stored in round as a pending application - Council can approve/reject application - Delegates can then vote by allocating their token amounts to accepted application - If accepted application is above threshold, it's status is accepted - When accepted, any user can initiate vesting. - Vesting that's created is a Hedgy - Existence of Hedgey is stored in round - We can query round to get Hedgey details - If group fails, application can be cancelled - Cancelled applications cannot reply ### Responsibility of the contracts: - Operates the round - Application: - Accept - Reject - Cancellation - Voting - Vesting: Payouts - Role management? --------------------------------------- # May 23rd updates: ### Prototype: [Delegate bulk voting:](https://www.figma.com/proto/pBsKNmb3fEPfVIs2XEQjk3/ARB-EasyRGPF?page-id=4%3A326&type=design&node-id=757-4636&viewport=899%2C729%2C0.21&t=fqew2g1j1F6ciGdE-1&scaling=scale-down&starting-point-node-id=757%3A4636&show-proto-sidebar=1) ### Designs Council flow: ![image](https://hackmd.io/_uploads/SyUq1fCXC.png) Project flow (Public): ![image](https://hackmd.io/_uploads/HJQh1GC7R.png) Delegate flow: ![image](https://hackmd.io/_uploads/Bkh0kG0m0.png) ### Contracts: You can check the open items per epic: https://github.com/orgs/grants-stack-frontier/projects/2 85% done, ETA is June 1st ### Data fetching: - We have fetched all the necessary info aside from the contract being built via graph, indexer, and apis ### Frontend: - Program page: https://arb-easyrgpf-frontend.vercel.app/programs - Create project: https://arb-easyrgpf-frontend.vercel.app/programs/create - Project details: https://arb-easyrgpf-frontend.vercel.app/programs/detail - Landing page: https://arb-easyrgpf-frontend.vercel.app/ - Delegate: https://arb-easyrgpf-frontend.vercel.app/delegate ## What's next: - Finishing delegate & council flows frontend templates - Connecting data into frontend - Integrating contract functionality into frontend. ------------- ## Issues to unblock: **Bitbeckers:** "There are a few open items left and I'm trying to schedule something with Zacc. It's specifically about the weighted allocation based on delegator balance. Depending on the complexity of the solution, and therefore tests, I suspect 5-10 hours left before it's ready for peer audit with the GC team. So pretty on track for the 30-40 hour estimate"