Rules: technical deployment and legal wrappers

Hey everyone! It’s Sam from the Comms team sharing an update from the last Aragon DAO discussion on November 11.

Here’s what we talked about:


What are rules? In our Governance Framework, Rules are enforced by the on-chain deployment and applicable laws, which establish the default governance model of the organization.

Lightweight structure: The technical design that follows will be the default governance model of the Aragon DAO. The default governance model is intentionally minimal to foster experimentation on the social layer and to give teams as much autonomy as possible to deliver impact. Some elements may be protected by legal wrapper(s), which may create additional rules within the ecosystem and towards the local laws of a jurisdiction.

Due diligence: The Rules are still a work in progress with decisions to be made regarding the scope of the initial deployment, as well as legal wrapper(s) that may be incorporated to protect one or more aspects of the organization. These decisions are currently in due diligence and being weighed by key stakeholders. The Aragon DAO will be deployed gradually and carefully, allowing us to test and iterate on the model before transferring a significant portion of the Treasury.

Work in progress: Please note that the diagrams below are a work in progress Names and numbers are for illustration/example purposes only. The delay periods and parameters have not yet been set. We will be careful with parameter settings, as they greatly impact security.

Overview of components

At a high level, the Aragon DAO deployment will have the following components:

  • Token Wrapping: ANT Holders must wrap their tokens to participate in governance.
  • Delegation: ANT Holders may delegate or undelegate their voting power at any time. They may also vote directly on proposals to override the votes of their Delegates.
  • Proposals: ANT Holders may submit proposals as long as they hold above the specified amount to prevent spamming attacks.
  • Delay Period: There is a delay period between the proposal and voting stage. A delay period was chosen before the voting stage, in order to preserve the integrity of on-chain execution once a vote is passed. It also creates a window for ANT Holders to wrap their tokens or update their delegation.
  • Proposal Veto: A group of Guardians appointed by Delegates may veto proposals under specific circumstances. This is a necessary safeguard against malicious proposals.
  • Guardian Appointment/Discharge: Guardians are appointed or discharged by Delegates. A trusted group of stakeholders may veto the appointment or discharge of Guardians, as a security measure in the event Guardians get compromised.
  • Vote Period: A snapshot is taken at the beginning of the vote period, capturing the voting power of ANT Holders and Delegates. Delegates may vote on proposals on behalf of ANT Holders. ANT Holders may vote directly to override the vote of their Delegate.
  • Vaults: The funds will be distributed among different vaults granting different permissions.
  • Wallet Address: Successful proposals may trigger a transfer of funds from a Vault to the wallet address designated in the proposal.


Submit: ANT Holders with a certain threshold of tokens may submit proposals. Proposals enter a delay period, where Guardians may veto the proposal.

Veto (security option): Guardians will have a clearly defined mandate (ie. stopping malicious proposals). If proposals are not vetoed during the delay period, they can proceed to the voting stage.

Vote: A snapshot is taken when the proposal is opened for the voting stage. Delegates may vote on proposals on behalf of the ANT Holder(s) they represent. ANT Holders may override the vote of their Delegate by voting directly on the proposal. ANT holders don’t have to delegate—they can choose to vote without delegation. If the proposal passes, anyone can execute the transaction.


ANT Holders who hold a certain threshold of tokens can create a proposal to have Guardians appointed or discharged. Guardian proposals may be vetoed by a trusted group of stakeholders (yet to be defined), who have a long history and commitment to the Aragon project. If the Guardian proposal isn’t vetoed, voting proceeds as described above.


The Rules will be described in the Charter. The Charter will be as concise and accessible as possible (1-2 pages). It is meant to be a plain English translation of the deployment, prioritizing technical accuracy and accessibility. It will follow the governance flow step-by-step and directly link to addresses, parameters and legal documents for ease of reference.

The draft Charter will be shared once the scope of the initial deployment and legal wrapper(s) have been agreed upon by advisors and key stakeholders.

Add questions below

If you have questions related specifically to Rules, comment them below and I will answer them or find someone who can. Thank you!


Thanks Sam, really clear and concise!

Great summary @Samantha

  1. As the process is not open, can we be transparent and name the actors making key governance decisions such as setting the delay periods and parameters that impact security?
  2. In terms of Zarghams model for Effective Freedom & Collective Autonomy which forms of relative autonomy are being empowered through governance minimization - Individual and collective political autonomy? strategic and tactical functional autonomy?
1 Like

Hi Renee,

To answer Q1, the starting point for parameter setting is in the Proposal: Transfer the Aragon Project Funds to an Aragon DAO Governed by (Delegated) ANT . The AA formed a temporary cross-functional team to drive the workstream proposing a delegate voting DAO for the AA and ANT Holders to approve/deploy/enact. We’re still defining the scope of the initial deployment, its security measures (some of which were not included in the original proposal - ex. Guardians), and funds (which will be transferred progressively as security is tested and proven - not all at once). It’s hard to discuss granular parameter settings, before these higher level decisions are made. We’re sharing our WIP even though final decisions have not been made and granular details are not set - specifically to gather feedback along the way. As soon as the scope is set, we’ll be in a better position to share the Charter and discuss specific parameters - we’ll continue to gather feedback from all stakeholders, including the broader community. It’s just important to keep in mind that parameters need to prioritize the security of the treasury - not personal opinions or preferences.


Cosmos recently had a vote in which a bunch of major changes to their system (“ATOM 2.0”) got vetoed. One of the post-vote takeaways was that the proposal should have been broken down into distinct parts and voted upon separately because voters who were generally supportive were unable to express their views on specific parts which left them with no other option than to veto the whole proposal. I bring this up as something to consider before the newly designed system for Aragon is put on a vote.


Definitely saw that and have spoken to a few Maker delegates about similar situations. Thanks for sharing!


Thank you this seems reasonable and although it’s always unfortunate to have the need for “guardians” it certainly seems understandable considering the size of the Aragon treasury and the state of DAO tooling at this time.

Appreciate the progress info and recognise work is ongoing, however my question was

…can we be transparent and name the actors making key governance decisions such as setting the delay periods and parameters that impact security?

You refer to a cross functional team.Who are the people working on this?

The workstream is intentionally function-based, rather than individual-based. Internally, core team members from tech, ops, communications and partnerships have contributed at different times - depending on the stage of the project and support needed. Externally, we have been working closely with Blossom Labs, Aragon’s legal and tax counsel, and DAO Craft. I will continue to stress that individuals and their opinions are irrelevant for the purposes of this workstream. We’re working based on accomplishing our functions and doing what is best for the organization . We are also careful to limit the scope of the workstream and protect the bandwidth of the core teams, so we can continue to ship and focus on impact. This said, the governance design of the deployment is intentionally minimal and non-prescriptive - it is limited to the instructions in the treasury transfer proposal and necessary security measures - to facilitate broad participation in shaping the organization both at launch and indefinitely.


Hey! Regarding the use of legal wrappers, we’ve recently launched our own open-source legal wrapper app, which allows wrapping any address with a legal entity (tokens, DAOs, etc.) - it’s DAO agnostic. However, currently, our team is small and we only have a handful of legal templates, so I think it could be cool to work together and set up an open, shared library, of legal templates for DAOs


I am not asking about anyone’s individual opinions on the matter. I’m seeking transparency on WHO if anyone is accountable here for making “…governance decisions such as setting the delay periods and parameters that impact security…”

You’ve indicated a proposals template that suggests the need for team description. Why would that not be equally relevant in regards to the establishment of DAO Governance?

It is good to know that many people are involved in the process but imo multiple council on the matter does not absolve accountability for the decisions being enacted. If what you are saying is that no one is accountable…well that just seems dodgy.

Addition 28/11/22: On the topic of blockchain governance

"…Existing conceptions of platform governance are therefore insufficient for understanding these systems. The question of how they are governed requires paying particular attention to the capabilities and actions of users in relation to the boundaries that are set for and by them.

Zargham et al. (2021) have helpfully named this the ‘governance surface’, which narrowly construed is the set parameters that are subjected to human oversight.

Broadly construed, the governance surface is the set of actions made available by a software system that can affect changes to the policies enacted by that software which can include adjusting who has access to set or change parts of the system in the future…

… the governance surface is knowable – a critical distinction in situations where users have rights within a system and where the system relies on the exercise of such rights…

public communication relating to a system’s design is common and expected, acting as the means by which a protocol’s human constituents understand their rights and responsibilities.

1 Like