Last updated 8 months ago
Web2 B2B & B2C companies can't efficiently provide their services to DAOs, they operate at a disadvantage compared to the DAO2DAO model.
We are building Agora; a simple and composable Plutus on-chain governance lego to unlock B2DAO economic models and open source DAO tooling.
This is the total amount allocated to Agora: Plutus governance module.
As DAO's on Cardano grow stronger (developer.member count, treasury size, complexity of protocol linked to the DAO) they will naturally attract web2 B2B/B2C companies offering them products and services. The problem is without a standard governance framework for these companies to effectively participate in governance. A comprehensive on-chain governance for Cardano DAOs to efficiently transact with B2B/B2C companies must extend far beyond voting. The entire process of proposal submission, delegation in both draft and vote stages (liquid democracy), proposal execution (if a successful grant proposal this involves sending treasury funds) must be included for a governance framework to become the standard in Cardano.
Agora: end-to-end on-chain governance module
We modeled Agora after the Compound Governor Apha design pattern which is the premier governance module used in Ethereum DeFi (Compound, Uniswap, Gitcoin, Fei). Tally is a popular Ethereum wallet focused on perfecting the DAO UI for active governance token holders and they exclusively list DeFi protocols that run the Governor Alpha contract, as it's the emergent standard.
So what is it?
Agora is a set of Plutus smart contracts that compose together to form a governance system.
B2B/B2C companies, DAOs, dApps and community members will be able to use Agora to:
-create a proposal (or submit a draft proposal)
-vote on active proposals; any token holder can cast a token-weighted vote.
-delegate their vote; any token holder can assign their vote to anyone (including to draft proposals, which helps them reach any minimal threshold required to get the proposal into an active vote phase)
-lock; anyone can lock a proposal after it passes. Locking starts the timelock delay until proposal execution (only relevant for proposals that have successfully passed)
-execute; anyone can execute a locked proposal after the timelock delay (only relevant for proposals that have completed timelock phase)
Goals:
Agora aims to reduce duplication in Cardano DAO tooling development and to serve as a one-size-fits-all governance library for decentralized projects on the Cardano blockchain.
Agora aims to be modular and flexible for specific needs but presents an opinionated architecture.
Non-goals:
Agora is not a DAO. It doesn't have tokenomics or even a token. It is simply a Plutus library for governance.
Agora doesn't aim to provide any primitive tools for Plutus that are not governance-specific. For this, see plutus-extra*.
Feature Roadmap for Agora v1 & v2
v1
Governor
Treasury
Staking pool
Proposals
Effects
v2
Rewards distribution
Escrow staking pool solution
Agora Overview
This section gives an overview of the technical design of the proposals system for introducing, casting votes and executing governance proposals.
Proposals
Initiating a proposal requires the proposer to have more than a certain amount of governance tokens (GT) staked in the system e.g. 5GT. This is checked by consuming the UTXO representing the user's stake. Initiating a proposal creates a script, which will handle all voting interactions. Any fungible Cardano native asset (including ADA) can be used as a governance token.
Voting
The life-cycle of a proposal is neatly represented by a state machine diagram attached below*.
The 'draft' phase being the initial state, and 'executed' and 'failed' being the terminating states. Please note that this state-machine representation is purely conceptual and should not be expected to reflect technical implementation.
When may interactions occur?
Consider the following 'stages' of a proposal:
S: when the proposal was created.
D: the length of the draft period.
V: the length of the voting period.
L: the length of the locking period.
E: the length of the execution period.
Voting Phases
Draft phase
During the draft phase, a new UTXO at the proposal script has been created. At this stage, only votes in favor of co-signing the draft are counted. For the proposal to transition to the voting phase, a threshold of GT will have to be staked backing the proposal. This threshold will be determined on a per-system basis and could itself be a 'governable' parameter.
Voting phase
In the voting phase, users may utilise their stakes to vote in-favour or in-opposition to a proposal. This will add their vote to the relevant count. There is potential for contention within the system and therefore voting on proposals may have to be rate-limited. The method by which a user's stakes are weighted and the thresholds required for proposals to pass are determined on a per-protocol basis.
Lock phase
Upon completion of the voting phase, a proposal will either have been passed or failed. A delay between the passing of a proposal and execution of its effects will be enforced, to allow users to prepare for incoming changes to the system. It'll further give the system maintainers opportunity to intervene, in the case of a hostile action.
Execution phase
Failed proposals will not be interacted with further. The only value they will contain is their state thread tokens and the minimum ADA requirement, so little of worth is lost.
Successful proposals will be verified by the governor component, which will issue 'governance authority tokens' (GATs) to a proposal's separate 'effects'. The burning of these tokens will be a pre-requisite for system changes to be made, therefore the possession of one will serve as a form of 'licence' for making the changes.
There will be a deadline before which a proposal's effects will have to be executed. As any passed proposal's effects will necessarily have been supported by the community, it can be presumed that community members will have be incentivised to ensure the effects are enacted soon after the proposal has been passed.
The first four key metrics to measure in this challenge are directly addressed by the Agora implementation:
Agora will enable significantly more Cardano DAO's to benefit from business solutions sourced through competitive proposal rounds.
Agora will also scale DAO2DAO models on Cardano via a standard process for cross-protocol governance transactions (streamlined greatly if both DAOs are running Agora). We have already seen significant DAO2DAO deal sizes in Ethereum, specifically wrt to treasury diversification.
Agora will also increase the quality of B2B/B2C proposal submissions since the process for submitting a proposal will be a simple form accessible from multiple UIs the labor intensity of submitting (a major deterrence to web2 companies submitting B2B proposals today) is removed.
Additional funding from other sources will be available to B2B/B2C companies which provide quality services to DAO/dApp communities. This is no different than web2 companies getting referrals for new work from their existing client networks (they key here is reputation can be scaled faster when a company is providing the same quality service to several DAOs simultaneously).
Implementing EVM smart contract design patterns has been the largest challenge building Agora to date. We have overcome this by reverse engineering the Governor Alpha framework targeting the Plutus eUTxO model.
Agora v1 will be open source and freely available for developers to use soon. We have already completed most of the functionality required for v1 including delegated voting. We aim to deliver the complete v1 functionality shortly after open sourcing the library and building out the v2 features plus any additional functionality requested by Cardano DAO infrastructure developers.
Contributions to the library to date include Plutus developers at Liqwid Labs, MLabs and ADAO.
Budget breakdown:
Engineering hours: 1000
Total budget request: $100,000
Feature Total Time
Extending the Agora functions to manage Stake Validators …………………………………..175
DAO Treasury ………………………………….. 25
Multisig functions ………………………………….. 50
Implementing Plutarch testing tools (apropos-tx) …………………………………………………100
Golden files via plutarch-test ..............................................................................50
Proposal Effect script templates ………………………………..100
Governor script that acts as central authority wrt minting Authority Tokens and initializing proposals .……...…………………………………100
Monomorphic proposal script to track progress of proposals …………………………………………………75
Implement a monomorphic staking pool parameterized over only system parameters.………………………………………………………………………………………..100
Security Audit………………………………………………………………………………………………..125
Documentation and guides ………………………………………………………………………………………..75
Agora frontend app UI/X ………………………………………………………………………………………..100
Total Time………………………………………………………………………………………………..1075 engineering hours
Total Budget request $100,000
Liqwid Labs: A team of expert Haskell / Plutus engineers and full stack developers building the 1st native lending and borrowing protocol on Cardano.
CTO Emily Martins has been a professional Haskell developer for 6+ years and is a polyglot capable of building secure, concise code in multiple languages.
MLabs is a top-tier Haskell development shop in the Cardano ecosystem. As IOG Plutus Partners they work closely with the Plutus team focused on improving tooling and off-chain infrastructure for Plutus developers. Over 80 Haskellers strong working on innovative community projects including:
-SundaeSwap
-Ardana
-Plutus IOG team
Experienced gained over the course of building Liqwid and our work with one of the most prolific early Plutus development firms gives us access to the most talented group of Haskell / Plutus developers in the ecosystem. Developers working on Agora are applying their aggregate Plutus expertise to successfully deploy this governance product on Cardano.
Website: https://liqwid.finance/
Challenge Statement: "How can Cardano-based solutions help meet real business needs and what would be their impact?"
Proposal Impact: High
KPIs
# of B2B/B2C companies submitting proposals using Agora.
# of contributors (once library made open source)
# of commits from Cardano ecosystem developers
# of forks of the governance module
# of Cardano DAOs running Agora for their governance
# of Cardano DAO2DAO transactions facilitated via Agora
Proposal Milestones: 3, 6, and 12 Months Post-Funding
3 Months: Completed v1 functionality (Governor, Treasury, Staking pool, Proposals, Effects) and collaborating with ecosystem developers to include additional feature requests. Comprehensive documentation covering each function in the governance module.
6 Months: Completed v2 functionality (Rewards distribution, Escrow staking pool solution) and including additional feature requests.
12 Months: Integrations with other DAO tooling/applications (e.g. any Tally/Snapshot wallet solutions), app UI/X for interacting with Agora from a simple to use web app.
This is a new proposal
NB: Monthly reporting was deprecated from January 2024 and replaced fully by the Milestones Program framework. Learn more here
Multiple senior Haskell/advanced Plutus engineers building Agora smart contracts and the expert MLabs Cardano ecosystem developers (IOG Plutus Partner) with over 80 Haskell developers working on some of the ecosystem's largest projects including:
-SundaeSwap
-Ardana
-Plutus