completed
Agora: Plutus governance module
Current Project Status
Complete
Amount
Received
$100,000
Amount
Requested
$100,000
Percentage
Received
100.00%
Solution

We are building Agora; a simple and composable Plutus on-chain governance lego to unlock B2DAO economic models and open source DAO tooling.

Problem

Web2 B2B & B2C companies can’t efficiently provide their services to DAOs, they operate at a disadvantage compared to the DAO2DAO model.

Addresses Challenge
Feasibility
Auditability

Liqwid

3 members

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

<u>v1</u>

Governor

Treasury

Staking pool

Proposals

Effects

<u>v2</u>

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

<u>Draft phase</u>

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.

<u>Voting phase</u>

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.

<u>Lock phase</u>

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.

<u>Execution phase</u>

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

  1. B2DAO Economic Model: Agora governance library will help B2B/B2C companies submit proposals to provide their services to Cardano DAO's in a streamlined process that does not currently exist on-chain toda

  2. Open Source Tooling: Agora will be open sourced shortly with a structure in place for Cardano ecosystem developers to contribute to the librar

  3. DAO2DAO Economic Model: Agora helps unlock the full potential of cross-protocol governance transactions between 2 or more Cardano DAO

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

close

Playlist

  • EP2: epoch_length

    Authored by: Darlington Kofa

    3m 24s
    Darlington Kofa
  • EP1: 'd' parameter

    Authored by: Darlington Kofa

    4m 3s
    Darlington Kofa
  • EP3: key_deposit

    Authored by: Darlington Kofa

    3m 48s
    Darlington Kofa
  • EP4: epoch_no

    Authored by: Darlington Kofa

    2m 16s
    Darlington Kofa
  • EP5: max_block_size

    Authored by: Darlington Kofa

    3m 14s
    Darlington Kofa
  • EP6: pool_deposit

    Authored by: Darlington Kofa

    3m 19s
    Darlington Kofa
  • EP7: max_tx_size

    Authored by: Darlington Kofa

    4m 59s
    Darlington Kofa
0:00
/
~0:00