Aera Protocol: Behind the Scenes
As the leading DeFi-native economic research firm, Gauntlet have pioneered ways off-chain intelligence can enhance onchain protocols through optimal control. To help DAOs make better capital allocation decisions in their treasuries, they set out to build a novel protocol and were looking for an R&D partner to help design and implement it.
🏦 Interested in using Aera for your treasury? Contact the team.
✨ Looking for help building your protocol? Just DM “Protocol” on Twitter.
Brief
With Aera, Gauntlet sought to develop a comprehensive treasury management solution.
The protocol needed to:
- Implement a highly pragmatic and current treasury management vehicle that would allow us to immediately start adding value to clients;
- Scale to support a wide variety of assets, treasury objectives and strategies;
- Provide a noncustodial implementation with strong onchain protections;
- Pave a clear path towards decentralization in accordance with the vision laid out in the Aera Whitepaper.
Here is the process we used behind-the-scenes to deliver on these concerns together with our engineering partners Blockvis and security partners Spearbit and ship two major versions of the Aera protocol.
Design
A modular treasury management solution
The protocol consists of three primary components:
- The Vault — a non-custodial contract that holds the treasury assets, handles interactions from the guardian and treasury.
- Asset Registry — a whitelist of supported assets and their pricing logic.
- Hooks — a set of hooks around common vault operations. Most importantly they constrain which guardian submissions are valid.
The protocol provides a generic interface and default implementation for each module which can evolve independently for future deployments.
Every module clearly isolates its own concerns with vault focusing on custody, the asset registry focusing on asset selection and pricing and the hooks module focusing on vault protection.
All modules act in support of the objective function defined by the treasury.
Trust model that prioritizes safety and availability of treasury funds
From the beginning, we sought to mitigate the risks of centralized treasury management solutions. Our approach was to limit the actions guardians can take in several ways:
- They can only call whitelisted contracts and whitelisted functions on these contracts
- They cannot reduce the vault value in excess of a pre-defined threshold during each 24-hour period
- They cannot create open allowances for ERC20 tokens.
In combination with only supporting highly-trusted guardians at the moment and using off-chain safeguards, this aims to achieve a multi-layer approach to security.
Equally we wanted to empower the treasury to take arbitrary actions through their funds and they can do so through the execute function.
Spec-first mindset
The Aera protocol was developed with a spec-first mindset. Throughout the course of development we used several types of specifications to build alignment, support the security process and explore variations on our ideas.
- Executional spec
The earliest Aera specification was a fully working Python prototype used to simulate and explore different execution methodologies.
This was a natural approach, given Gauntlet's expertise in economic simulation.
We used an Ethereum inspired mini-DSL to define smart contract like objects and develop targeted simulations.
2. Written spec & user documentation
Next, we developed a written specification for the different module interfaces and implementations in Aera. After that, we added user documentation from the treasury point of view ahead of developing the protocol in order to achieve our stated goal of low-friction interactions.
We used Notion for this purpose, which helped us with collaboration and supported an easy export feature to share the spec with auditors.
A version of these guides is now published in the Aera Docs.
3. Invariants
Finally, we developed a basic trust model and a set of invariants for each module.
We are continuing to explore & expand on invariant testing starting with Foundry invariants.
Building an internal security capability
We approached security audits as an opportunity not just to solidify the contracts but to train the team on security practices. We followed the Auditless Codex playbook for internal security reviews.
Even non-Solidity engineers participated in our internal audit and despite its heavily time-bound nature discovered critical issues as well as deepened their understanding of the protocol.
As a result, our latest audit by the world class Spearbit team had no critical issues and just 1 High Severity issue, which enabled the Spearbit team to add value in additional ways such as streamlining deployment, helping us plan future iterations of the asset registry and more.
Our goal is to continue developing our internal security capabilities.
A path to decentralization
The use of objective functions and guardians is intentionally included as an enabler for decentralization. The current architecture is future-proof: it can support an evolution of the guardian in a smart contract and we have completed several streams of investigative work in this direction.
Some of the most important contributions that the Aera protocol will introduce will likely come from these efforts.
Collaborative process
The most distinctive feature of our process has been the cross-functional nature of the solution. The Aera guardian logic, monitoring stack and strategies were all developed in conjunction with the protocol with many feedback loops.
Every member of the broader Aera team has contributed to both the protocol and the off-chain infrastructure that uses it in some form (and necessarily so).
The collaboration was oriented around a Product Discovery loop that resulted in a sequence of AEPs (Aera Enhancement Proposals) with prioritization derived from overall Aera product objectives.
We look forward to continuing to evolve these operating procedures to support the growth of the protocol and explore more of the treasury management idea maze.
💻 Are you interested in learning more about these contracts? You can check the source code on GitHub or the documentation.
📬 Want more research from Auditless? Subscribe to the Newsletter.
