Aragon Agent is a fully-fledged Ethereum account owned by an Aragon organization. It's like a multi-signature account on steroids that enables organizations to interact with any Ethereum contract or protocol. Trading tokens on 0x or Uniswap, opening a Maker CDP, managing names in ENS, owning digital LAND parcels, or even breeding digital cats.
Before Agent, those interactions required taking funds out of the organization and sending them to a trusted operator. Then the operator would interact with the external contracts, and return the assets to the organization afterwards. With Agent, this can be done within the organization in a completely trustless way.
Agent also allows organizations to interact with other organizations, opening up an incredible amount of experimentation with inter-organization interactions.
An Agent represents one identity of the organization. For the external world, the Agent identity is static, even after upgrades to the governance process of the organization. This removes the need for painful migrations after governance changes.
The best way to build deep integrations with other protocols is still building an Aragon app with aragonSDK. But Agent introduces a great way to interact with external contracts without the need for building a custom Aragon app.
Interacting with Agents
Applications and contracts on Ethereum have lots of different use cases and user targets. That's why we decided to push three different interaction models for Aragon Agent:
aragonCLI Agent support (beta)
The first interaction we focused on is the aragonCLI interaction. It works through the new
dao act command introduced in the 5.4.0-beta.1 release (see release notes), available now.
Aragon 0.5.4 will be released next week with better support for Agent, featuring an update to radspec that allows to describe actions with radspec within radspec, as it can be seen in the image above.
Web3 signer integrations (coming soon)
Agents are full Ethereum accounts controlled by organizations. We foresee that users will transparently transact with decentralized applications through their Agent.
With regular Ethereum accounts, users sign transactions directly with their private key.
With this integration, the signing provider/wallet would use aragonAPI to figure out what the governance process of the organization is. It would send the transaction depending on how the action needs to be forwarded within the organization in order for their intent to go through. You would be able to interact with other dapps as if you represented your organization.
You could for example open a Maker CDP directly using their web interface. That could trigger a vote on the organization, and tokenholders would be able to approve or reject that proposal.
Users will just be using dApps as they do when managing their own accounts. But instead of executing transactions directly, how they execute depends on the organization's governance.
Agent webapp (coming soon)
We are also designing a webapp to interact with Agents and check past actions that were performed by the Agent, as well as executing new ones.
Installing Aragon Agent
Since it is in beta, Aragon Agent doesn't come pre-installed in Aragon organizations. We consider it a feature for advanced users for the time being, and it can only be interacted with using the aragonCLI. In future releases, Aragon Agent may be installed by default in new Aragon organizations.
Installing Aragon Agent into an existing organization can only be done using the aragonCLI 'dao install' command. You can check a thorough guide on how to install apps from the aragonCLI in this Aragon Forum tutorial.
Security-wise, even though the code has gone through a thorough internal code review, it still hasn't been fully reviewed by smart contract security professionals. Authio (and ConsenSys Diligence), the Aragon Network Security Partner, will be auditing the Agent smart contract code soon. Until the app has been audited, we do not recommend using it for securing valuable assets.
Agent message signing
Disclaimer: heavy technical section, feel free to jump to the Case Studies below!
In Ethereum, there are two types of accounts:
- Externally owned accounts, controlled by private keys.
- Smart contract accounts, controlled by their smart contract code.
Aragon Agent tries to mimic the behavior of an externally owned account (EOA) as much as possible. That means Agent should be able to perform any type of interaction an EOA can. It can also sign messages that some applications like 0x or Livepeer need.
Smart contract addresses aren't derived from a public key as EOAs are. So the regular way to check whether an account has signed a message (using EDCSA signature verification) doesn't work when the signer, in this case an Agent instance, is a smart contract.
Thankfully Philippe Castonguay wrote ERC1271, a standard for smart contracts to 'sign' messages. It works by responding in a concrete way when asked by other contracts whether a signature is valid for a given hash. When queried, a smart contract can perform any arbitrary checks, and then responds whether it accepts the signature as its own. The signature can be a regular ECDSA signature or anything really. Currently, Aragon Agent can respond that a signature is valid in many ways:
- Presigned hashes: Agent uses the aragonOS ACL to allow certain entities to mark a hash as signed. That will make any signature (even empty or invalid) checked for that hash a valid signature.
- Designated signer: Agent can defer checking signatures to another EOA or smart contract. For EOAs, regular eth_sign and ERC712 signatures are supported. For smart contracts, they must support ERC1271 as well. That means you can chain many Agents together by appointing another Agent as the designated signer.
Summarizing, Agent supports message signing and transaction execution, via both individual actions and EVMScript execution.
Thanks to that, Aragon Agent offers organizations all the features an EOA has. Plus it has advantage of adding a governance process before performing actions. That way, you can grant different rights over the shared account to different entities.
You can check an in-depth discussion on the technical features of Aragon Agent in this Forum discussion.
The Melon Council, which was deployed as an Aragon DAO to the Ethereum mainnet this week, is already using two Aragon Agent instances:
- The first Agent is controlled by all the members of the Melon Council. This Agent instance is whitelisted in the Melon protocol as the address that can make fee adjustments in the protocol. In order to change protocol fees, a vote needs to be approved by the Council, which will then make this Agent execute the fee setting transaction.
- The second Agent is controlled by the Melon Technical Council (a sub-group within the council). This Agent is the owner of some ENS names that point to the latest version of the Melon protocol smart contracts. If a vote is approved by MTC members, this Agent is able to change the ENS name so it resolves to a newer version of the protocol.
Managing liquidity on Uniswap
The Aragon Association is currently considering to become a liquidity provider for the ETH:ANT pair in Uniswap. Using Agent, the Aragon Association DAO (to be created) will be able to directly become a liquidity provider in Uniswap, adding or removing funds to the liquidity pool.
Aragon Agent opens the door to an unbounded amount of use cases by combining the large number of Ethereum apps with the flexibility, control, and predictability of Aragon organizations. We can't wait to see how people use Agents for all sorts things!