Other Proposal : Aragon DAO Rules

Aragon DAO
#1

Vote is live here.

After months of preparation and stakeholder consultations, the AA is proposing the Aragon DAO Rules : an objective, plain english description of the smart contract permissions of the Aragon DAO. The Aragon DAO Rules are meant to replace the function of a Charter, as the core governance document.

The Aragon DAO Rules intentionally center the smart contracts granting governance permissions to Ethereum addresses, and push human-layer guidelines, and practices to the edges.

Since DAOs first launched in 2016, they were always meant to put code at the center, humans at the edges. Our delegated voting DAO is lean, minimal, and simple. With the principles of antifragility in mind, we created a DAO that ideally can survive paradigm shifts in the industry and the world. In order to create an unstoppable organization, we need to center what is unstoppable: blockchain technology.

The Aragon DAO will be deployed with the initial set of smart contract permissions described in the Aragon DAO Rules. This deployment will form the default governance settings. The governance settings of the smart contracts—permissions and parameters—are meant to evolve over time, as we experiment, learn, and build on the initial deployment. No funds will initially be transferred to the DAO and low quorum and threshold parameters will be set until we can assess the level of governance participation to inform parameter setting, such as quorum and threshold, with data based on experience rather than estimation.

This Forum post will be up for discussion for a period of 7 Days and will be followed by a binary (yes/no) item by item signaling vote for a period of 7 Days. The Aragon DAO Rules were informed by extensive stakeholder consultations and feedback over the past 6 months.

The Aragon DAO Rules are the numbered items in bold. Additional commentary was added below the numbered items in italics, to provide additional details and clarification to support and facilitate the Forum discussion. Only the text of the numbered items in bold will be put to an item by item signaling vote and included in the final Aragon DAO Rules document.

Aragon DAO Rules

IPFS: [link to document]

The Aragon DAO is an [aragonOS](link to source code) smart contract deployment on Ethereum mainnet at [addresses](link to etherscan) that accepts inputs, grants permissions, and executes on-chain transactions as described in the [Aragon DAO Rules](link to IPFS).

The Aragon DAO is defined as the smart contracts granting permissions to Ethereum addresses to participate in governance. The preamble references the source code and smart contract deployment via hyperlinks. Hyperlinks are used throughout the Charter as a dynamic source of truth, to avoid relying on manual changes to the text-based rules document.

The following items define the conditions that Ethereum Addresses must meet in order to have permission to send input transactions (wrap, delegate, undelegate, initiate, vote, execute, veto, pause, resume, mint, burn) to the governance systems of the Aragon DAO.

The purpose of the Aragon DAO Rules is to describe the permissions granted by smart contracts in plain english (rather than Solidity). In order to participate in the governance of the Aragon DAO, you must have an Ethereum Address with the conditions described to have permission to engage with the governance systems of the Aragon DAO.

  1. Any Ethereum Address with [Aragon Network Token (ANT)](link to address) has permission to wrap it in the [ANT Wrapper App](link to address) to receive an equal amount of wrapped ANT (wANT). Any Ethereum Address with wANT has permission to unwrap it in the [ANT Wrapper App](link to address) to receive the original amount of ANT. The wrapping of ANT and unwrapping of wANT in the [ANT Wrapper App](link to address) is permitted at any time. wANT is non-transferrable.

    ANT must be converted into wrapped ANT (wANT) in order to be compatible with the delegated voting permissions of the smart contracts. Only wANT can be used to vote in the Aragon DAO. wANT is not transferable and can be wrapped or unwrapped at any time.

  2. Any Ethereum Address has permission to delegate or undelegate to any Ethereum Address at any time in the [TAO Voting App](link to address).

    wANT Holders can delegate or undelegate at any time. wANT Holders do not need to delegate their tokens, they can simply vote without delegating.

    Delegates can see which addresses have delegated their vote to them, but they do not have the option to accept or refuse delegation, they can simply choose whether or not to participate by voting.

  3. Any Ethereum Address with the required ANT amount has permission to initiate a Proposal to the Aragon DAO. The Proposal is automatically put into a Delay Period by the [Delay App](link to address) for the duration specified in the Proposal parameters and the required ANT amount is locked. When the Delay Period expires the ANT is automatically unlocked.

    1. [Budgeting Proposal](link to parameters): A Proposal to signal or withdraw funds from the [Budget Vault](link to address).

      Delay Period: 7 Days

      Voting Period: 7 Days

      Delegate Voting Period: 7 Days

      Swing Voting Window: 1 Day (before the Voting Period ends)

      Swing Voting Extension: 3 Days (added to the end of the Voting Period)

      Locked ANT: 5000

      Minimum Quorum: 0.03

      Minimum Level of Support: 0.5

    2. [Governance Proposal](link to parameters): A Proposal to signal or change permissions and parameters.

      Delay Period: 7 Days

      Voting Period: 7 Days

      Delegate Voting Period: 7 Days

      Swing Voting Window: 1 Day (before the Voting Period ends)

      Swing Voting Extension: 7 Days (added to the end of the Voting Period)

      Locked ANT: 5000

      Minimum Quorum: 0.03

      Minimum Level of Support: 0.5

    ANT Holders do not need to wrap ANT (wANT) to make a proposal.

    To submit a proposal, ANT Holders must hold the minimum amount of ANT required to be locked for the delay period specified in the proposal parameters. After the delay period, the ANT is unlocked. The locked ANT cannot be slashed, it is simply locked and returned. The amount of ANT required to initiate a proposal can be changed with a governance proposal.

    The initial deployment has two proposal types, requiring different sets of permissions and parameters. Each proposal must be submitted to the proper TAO Voting App. Clear instructions will be provided in a DAO Wiki and/or directly in the UX of the DAO.

    Initially, all parameters will be set with low quorum and level of support, in order to allow us to adjust with experience and data. Over time, the Budgeting Proposals should have lower parameters to allow for ease of signaling and smaller transfers of funds. The Governance Proposals should have higher parameters to protect the security of the other vaults.

  4. Any Ethereum Address has permission to initiate the Voting Period for a Proposal if the duration of the Delay Period is reached. When the Voting Period is initiated, a snapshot is created containing the wANT balance and delegation for all Ethereum Addresses at that block.

    When the delay period ends, any Ethereum address can move the proposal to vote (as it will not automatically be moved). A snapshot is taken at the beginning of the vote period, capturing the voting power of ANT Holders and Delegates.

  5. Any Ethereum Address with wANT or delegated to by another Ethereum Address with wANT has permission to vote on a Proposal during the Voting Period. If the expected outcome of the vote changes during the duration specified in the Swing Voting Window, prior to the end of the Voting Period, the Voting Period is extended for the duration specified in the Swing Voting Extension. When an Ethereum Address that is delegating to another Ethereum Address votes on a Proposal, it overrides the vote of the delegated Ethereum Address.

    Delegates may vote on proposals on behalf of wANT Holders. However, wANT Holders may vote directly to override the vote of their Delegates. Both wANT Holders and Delegates have the same duration window to vote.

    A change in the vote outcome during the final day of the Voting Period triggers a 3 or 7 day extension of the Voting Period (see Proposal parameters in item 3). This helps prevent any last minute attempts to swing and manipulate a vote outcome.

  6. Any Ethereum Address has permission to execute a Proposal after the vote is passed. A Proposal passes if the quorum and level of support reach their minimum threshold parameters by the end of the Voting Period. The quorum and level of support are calculated with values from the snapshot and using a definition of wANT voting supply as the total wANT held by or delegated to the Ethereum Addresses that voted on the Proposal.
    6.1. Quorum is the wANT voting supply divided by the total wANT supply.
    6.2. Level of support is the wANT voting supply in support of the Proposal divided by the wANT voting supply.

    A vote passes when the voting period expires and the quorum and level of support in the parameters are met. When a vote passes, any Ethereum address can execute the transaction on-chain, as it will not automatically execute.

  7. The [Aragon Shield Multisig](link to multisig address) has permission to set the [parameters](link to parameters) of the [Guardian DAO](link to address) and mint or burn an [Aragon Guardian Token (AGT)](link to address) in the [AGT App](link to address). AGT is non-transferable.

    Guardians will be appointed and removed by trusted parties in a multisig. The trusted parties will define the scope of the role of Guardians and set the parameters of the Guardian DAO, according to the needs of the DAO as it evolves.

  8. Any Ethereum Address with AGT is a Guardian and has permission to vote to veto, pause, or resume a Proposal in the [Guardian DAO](link to address). When the quorum and level of support of a veto is reached, the Proposal immediately expires and does not move to the Voting Period. When the quorum and level of support of a pause is reached, the Delay Period is paused. When the quorum and level of support of a resume is reached, the Delay Period is resumed at the time it was paused.

    Vote Period: 7 Days

    Quorum: 0.01

    Threshold: 0.01

    During the delay period, Guardians can vote to veto, pause or resume proposals with AGT in the Guardian DAO. The parameters set in the Guardian DAO must be met in order for the action to be executed. The parameters of the Guardian DAO are set by the trusted multisig.

    Guardians are a security mechanism. The scope of the role of Guardians will not be set and cannot be enforced on chain. Since the scope of their veto power is not enforceable by code, it requires additional definition and agreements. Their scope should be limited to veto malicious proposals within narrowly defined constraints. Holding them accountable to certain behaviors and actions requires a contractual agreement, which will be enacted separately and will evolve with the needs of the DAO.

17 Likes
#2

Thank you for posting this @jessicasmith! This is a good summary of the smart contract permissions. The only thing that I would ask a question on would be the Locked ANT to make a change to the permissions. This could be maybe set higher, or is there a reason to have them at the same level? Amazing work to the team involved, know how much time will have gone in to this.

2 Likes
#3

Thanks for posting this @jessicasmith, I very much agree with the general premise of centering the smart contracts (the actual DAO) which should lead towards best practises of a code-is-law mentality. This has the potential to enable clearer, faster, and more efficient governance (at the speed of software) and decrease bureaucracy.

A few questions/observations:

  1. Re: Rule #5: a proposal can be submitted using ANT not wANT, was wANT discussed as the proposal submission token instead, as it is used as the voting token? Furthermore, just below in the italic description it mentions different parameters for budgeting proposals and governance proposals, I currently see the same parameters. Maybe the wording should be adjusted:

It does mention initially all parameters will be set “low” but this doesn’t mean the “same”. Or should it say the same? As for the amount: typically within the industry, as @AClay eludes to above, permissions changing votes have higher levels of requirements to enact. Without being too pre-prescriptive should it be marginally higher than the proposal amount?

  1. Re: Rule #6. Was slashing considered a tool to use for safety during the proposal/voting period as the ANT Holders ANT will be locked?

  2. As the snapshot is taken at the beginning of the vote period, is it safe to assume that during the voting period wANT holders can already begin unwrapping their wANT to ANT? Thus the time period they would need to hold wANT to be used for a vote is moments before the snapshot is taken until immediately after and at no other point in time? Does this pose a risk?

Overall I have very few questions. It’s clear, concise, and understandable. Great work!

3 Likes
#4

Thanks for this great document @jessicasmith . I do have a few questions:

I am also interested in why or for what a user needs to lock their ANT?
Will these be slashed in case the guardians block the proposal?

A snapshot is taken at the beginning of the vote period, capturing the voting power of ANT Holders and Delegates.

Would it make more sense to take the snapshot when the proposal is created? Otherwise bigger buyers could watch out for proposals and buy/sell their ANT before the proposal moves into the voting period and thus influence the outcome.

5 Likes
#5

Let me answer these:

  1. wANT is not transferable by design, therefore it can’t be used as collateral, since it can’t be moved from one address to another one. The idea was to add simplicity to its design plus security of a token that literally can’t do anything else than voting
  2. Great you ask! It was! But due to the limited time (and complexity) we designed the system in a way that even tho it doesn’t have it right now, it can be “easily” added in the future by just changing the Delay App for an upgraded version that also slashes if desired.
  3. It is safe to assume, yes. Once the voting period starts your voting power is already calculated and fixed for that particular proposal (not for future ones oc). But if they want to keep participating they’ll need to keep it wrapped. This is how it works in all current onchain voting systems and we haven’t seen clear indications of major issues due to this design. If it’s about malicious attacks, the defence mechanism is mostly in the Guardians and Shield
2 Likes
#6

I am also interested in why or for what a user needs to lock their ANT?
Will these be slashed in case the guardians block the proposal?

Locking ANT is just to make spamming harder. It’s a big risk for Guardians getting overwhelmed by proposals they don’t have time to review. The expectations in the design is that locking, spamming attacks will become more expensive and the attempts will be more manageable by the Guardians. The funds will not be slashed by now in any case, but that can be added in the future by changing the Delay App for one that has that functionality.

Would it make more sense to take the snapshot when the proposal is created?

The other option of doing it directly when the proposal is created would allow for that as well at creation time. This at least gives more time for people to get in for proposals they care or believe might not be beneficial

4 Likes
#7

Brilliant, thanks for the response!

Good to know in the future all of these can be looked at and discussed.

#8

I join the congratulations for the great work, I really love it, easy and clear. My only concern, besides the questions already asked by @Anthony.Leuts and replied by @juareth, is about the amount of tokens to be locked for submitting financial proposals. 5000 ANT corresponds to about 10k USD at current value (but to about 60k should ANT return to its highs). How was that number chosen? I’m afraid this might be an hindrance for those who want to submit small-budget proposals (let’s say <100/200k), have you thought about providing a “facilitated” path for this type of requests?
Besides this, once again, great work!

3 Likes
#9

Huge shoutout to the AA for putting together this clean and concise Aragon DAO Rules!

Will this be a binary vote to approve or reject each clause?

Where can I see an audit report of the TAO Voting App?

Is the delay period a finite amount of time or at the discretion of Guardians?

How does become a Guardian once the DAO is deployed?

Will the DAO be refunding gas fees to whoever executes the transaction? And why is this execution not automatic after the end of a vote?

Thank you for all the work you and the AA have put into this.

1 Like
#10

Thanks @Anthony.Leuts for your questions and @juareth for the technical answers. Re parameters - both vaults are being deployed with the same lower threshold and quorum. However, they are meant to be adjusted asap, as we gather data with participation (token wrapping, delegation, voting). When they are changed the budget parameters should be lower and more accessible and the governance parameters should be higher and more secure. I’ll adjust the main post to make this clearer. Thanks for the flag!

2 Likes
#11

Thanks @MathiasAragon, I’ll just second @juareth on his answers. Re the snapshot, the delay period is partially intended to give ANT Holders the opportunity to wrap and delegate/undelegate during that 7 day window. It could be a double edged sword for security, but the window is equally important to give ANT Holders concerned with a proposal the chance to jump in to the governance process.

2 Likes
#12

@juareth and @jessicasmith

Thanks for the answers ^^
I agree with the double-edged sword, that’s why I wanted to raise the possibility in case nobody thought of it. But it seems you guys covered everything :smiley:

#13

Thanks @Jim and welcome to the Forum!

Yes - each clause will be put to a binary (yes/no) vote.

The deployment is currently being audited, although it is built on many pre-audited and battle tested Aragon components. I’ll let @juareth chime in here with more detail.

The Guardians will be appointed by a multisig of trusted members of the project. Currently, we are only putting the technical functionality/design to vote. The scope and appointment process for Guardians will be a fast follow, prior to the first transfer of funds.

Good question re gas fees, we have not planned for refunds but can explore via a proposal to the DAO if needed. Execution delays are a function of the Delay and TAO Voting Apps. Essentially, delayed execution (rather than automatic execution) can be used (or not) to add security mechanisms such as veto permissions. Again, I’ll let @juareth chime in re technical feature. We chose to front load the veto before putting proposals up for vote, rather than veto the execution of transactions after votes are passed by the community. This results in needing an Ethereum address to execute transactions manually.

1 Like
#14

@AClay + @Incandenza

Re locked ANT : This is meant to be adjusted higher or lower, depending on the needs of the DAO, over time. We are proposing to deploy with mid-high locking requirements, to avoid spamming and overwhelm. This is a security decision, particularly as we get the Guardians up and running. In theory, budgeting proposals should be made more accessible over time and governance proposals should be made more secure over time, but that will be up to wANT Holders and delegates to vote on in a governance proposal.

4 Likes
#15

Thanks for the clarification @jessicasmith! It makes a lot of sense

#16

Hi there Incandenza! Thanks for your feedback.

I agree with you on the fact that 5.000 ANT is a significant number and that may be a too high friction to certain types of proposals. However, this parameter may be changed by Delegates at any point in time to decrease that bar.

We opted to start with a higher bar from an operational security / risk management perspective. We’d rather start slow but with solid steps, other than having a very low ANT lock parameter and get swamped with small value proposals.

It’s important that we successfully try out the new architecture, with all its components. Lock, Delay App, TAO Voting… even to “veto” a given test proposal just to “test in production” not only the “code Rules” but also the required human intervention.

I also believe that while that number may be high for lots of individuals, proposers who can’t afford to gather those ANT amounts or pool enough resources may submit a request to larger ANT holders to submit the proposal in their behalf. It’s not ideal, but may be a hacky solution.

3 Likes
#17

If this is the case could a Delegate use delegated ANT to create proposals?

#18

That’s unfortunately not possible from a technical standpoint.

#19

Good, wasnt really too fond of the idea. Just wanted some clarification. Thanks @jessicasmith

#20

Amazing work Jess. The new Aragon Governance Framework has really shaped the way I’ve been thinking about the new DAO (and governance more broadly). I’m super excited to see these Rules as one of the first deliverables to be published that use the language of the framework.

Two pieces of feedback - one small, one big:

  • The preamble (the two bolded paragraphs before the numbered list) is confusing to me. It sounds like the Rules are describing inputs and permissions while the on-chain deployment controls the execution. I think it should be framed as all being on-chain and the Rules describe it all.
  • Most of the bullets are describing specific permissions that Ethereum Addresses have. This is a great structure, and I think the bullets could be even more compelling if that was doubled down on consistently across all of them, with a single permission per item. For example, if they all followed a format of “Ethereum addresses that [some condition] have permissions to [initiate some transaction]” it would be easier to parse through the formal logic, and would probably even be easier to read from a “plain English” perspective. I think it could help simplify them too to reduce redundancy. For example, #3 is like a higher level description of permissions that are subsequently described in both #4 and #7.

Hope that makes sense!

2 Likes