Status quo, assumptions
Membership is a very strong mental framework that has been underestimated while designing the product. The most commonly asked question after onboarding is How do I add someone to my DAO?
Right now our answer to this question is just assign them some tokens. Using the Token Manager one can assign tokens that can be transferred or not, and limit the maximum amount of tokens one account can own. Even though tokens and the Token Manager provide the right data structure for modelling membership, it is becoming clear that we still haven’t solved the problem from a product perspective.
Membership can mean different things in different types of organizations, while for a ‘capitalist corporation’ holding some tokens is an intuitive way of being a member of the organization (equivalent to a shareholder, with tokens represent voting and economic rights), in other contexts such as being a board member or having a recovery key, the token analogy is harder to grasp.
In the first release of the new Aragon client (v0.5) we decided to implement a very simple identity system building on ENS, that currently allows users (there is no UI for this yet, but it is doable at the EVM level) and DAOs to claim a name (a subdomain of
aragonid.eth) that can be used as an alias for an Ethereum address (but just as a one way mapping: name → address). One of the reasons for choosing ENS, is that it supports attaching metadata to names and two way mappings (name address) can be created using reverse name resolution.
The following are the assumptions or user stories that the rest of this proposal builds upon:
- DAO creators want to add members to their DAO.
- Members of the organization want to differentiate other members as individuals or entities, not as hexadecimal characters that are hard to remember.
- Users don’t want to be tied to one particular way to identify themselves, and different users want to identify themselves using different identity providers.
- A DAO wants to have its own unique identity as an organization, so it can be identified when interacting with other DAOs/systems/protocols.
Aragon ID v2: ENS Metadata & Identity providers
- ENS Reverse Resolution: http://docs.ens.domains/en/latest/implementers.html#reverse-resolution
- ENS Text Metadata Standard: https://eips.ethereum.org/EIPS/eip-634
An Ethereum account can only have one valid two-way mapping to an ENS name. The associated identity to this name is the Core Identity of the account (even though strictly the identity is associated to the name and not the address). The Core Identity of an account is fully controlled by the account owner, and is fully self-sovereign, and thanks to the two-way mapping, it is possible to fetch the Core Identity of an account from its Ethereum address.
However, an account can have any number of one-way mappings (name → address), and these other names can have their own identity metadata. All these other identities that an account can have are Contextual Identities. Two caveats about contextual identities under this design: a contextual identity is not necessarily set by the owner (it can be a claim from someone else about that account) and it is hard to fetch all the contextual identities of an account, but the user can always identify themselves with one of these names.
Just owning a name on a certain subdomain can signal group membership, for example all Aragon One employees could be given a
[name].a1.aragonid.eth name. Owning an address that resolves from that subdomain already means being an A1 team member, and apart from their Core Identity, their employment Contextual Identity could be just related to being part of the team (role, location, working hours…)
Using the TEXT field in the standard ENS resolver, each name can have some metadata attached to it. The name owner (not necessarily the account that the name resolves to) can add some information for a particular key or identifier.
These are two different proposals for implementing multiple identity providers with different tradeoffs:
- Using different text metadata keys for different providers (e.g.
"identity.iden3"…) and its value being the provider specific data. This implementation would make identity harder to consume (as it would involve performing a bunch of calls checking if the user uses any of the providers) and allows for potentially conflicting information as someone could be using multiple providers at the same time.
A ‘default provider’ key could store what identity provider is preferred by the user. It would make identity consumption easier, at the expense of store one extra field of data on-chain.
- Using a constant key (
"identity") and have its value be a bytes array of arbitrary length, with a prefix identifying the identity provider followed by provider specific data (an IPFS hash, a URL, a Keybase proof). Identity is very cheap to consume, but would require storing an extra 2 bytes on chain (shouldn’t be an extra cost for most blobs that would already be longer than 32 bytes).
Membership should be a core level primitive in Aragon DAOs. Being a member of a DAO wouldn’t necessarily grant members any economic or governance rights, but interfaces could be built so the Voting app could use membership as its governance base and a Membership forwarder or oracle could be created so permissions can be assigned to members.
The ability to add members and at the same time giving them an ENS name (e.g.
jorge.aragonone.eth) linked to the membership is a good way to have humanly readable names in organizations, even if the members haven’t created a profile themselves yet.
Membership to an organization shouldn’t be transferable, but unfortunately it is impossible to ensure that someone won’t transfer their identity (if rather than holding your identity in a EOA it is held in a smart account type contract). Making membership non-transferable will definitely raise the barrier for members to trade their membership/identity, but given that it is impossible to effectively protect against this (at the contract level at least, a subjective oracle could be used to penalize members that sell their membership) it is unclear whether we should claim and make membership non-transferable.
However Membership is implemented, it should expose an ERC20 compliant interface for some getters (
balanceOf(address)), to make integration with existing Voting apps easier.
Background: Aragon v0.6 (w/ Aragon ID v1)
1. Membership app (aragonOS 4 friendly)
- Cleaner architecture, Membership app is a standard aOS forwarder
- Migration for v0.6 DAOs would be non-trivial in order to re-use the ENS name and issue sub-names
- Identity of the DAO would need to be set through the Membership app(s)
- Dubious scalability for big organizations with nested groups (possible technically but the experience would be clunky)
: It would likely require resetting subdomains of
aragonid.eth with a multisig intervention. It could be done fairly trustlessly (verifying receiver of the ownership over the name is an app of the DAO). This would set a dangerous precedent, so in case we decide for this route we should also remove this power from the multisig and make the registrar trustless, as the Aragon ID readme explains.
2. Membership in Kernel (DAO Stacks)
- Improved scalability and usability of big orgs using nested DAOs
- Child DAOs could inherit some aspects from the parent DAO and the parent DAO could have complete control over its child DAOs, but they could have independent ACLs
- By baking Membership in the Kernel we would be enforcing an opinionated Membership model
- Other systems built with aragonOS may not need a core concept of Membership
- Technical cost would be 2-3x the cost of the previous proposal
: Inheritance for example in the case of app versioning: a child DAO that uses the same Voting version as the parent DAO wouldn’t need to have it stored in its own (child) Kernel, but just rely on its parent DAO for upgrades to the Voting app.
: A parent DAO agent app could have ‘root permissions’ in all its child DAOs, so the parent DAO could have complete control over them.