With Uniswap v4, the Uniswap protocol expanded from supporting liquidity providers and swappers to providing a powerful and permissionless liquidity platform for DeFi developers. The Uniswap Foundation was responsible for ecosystem support in this transition and was looking for a grantee to provide technical and strategic input leading up to the launch of Uniswap v4 and the exploration of a new L2 (Unichain).

✨ Looking for help building your protocol? Just DM “Protocol” on Twitter.

Brief

In June 2023 we wrote a small piece about the brilliance of Uniswap v4’s design.

Less than a year later, in April of 2024, the Uniswap Foundation selected Auditless to create the Protocol grants category. From the Announcement post:

As we discussed in our blog post last week, the Uniswap Foundation’s new Protocol grants funding category will support continued Uniswap Protocol innovation, and facilitate stronger feedback loops between our stakeholders and protocol development. With this new funding category we aim to improve the experience for our swappers, LPs, developers, and more for years to come.

However, funding future protocol innovation comes with a specific set of challenges: this work is highly consequential, and requires significant context and product vision to execute well. To implement successfully and to provide the best outcomes for the ecosystem, the Uniswap Foundation sought out a strategic advisor to lead protocol and market research initiatives, design a holistic roadmap, and collaborate with and guide our grantees.

The grant started off exploratory in its scope but the Unichain opportunity was validated pretty quickly and soon became the primary focus of Protocol grants due to its large potential.

The Auditless team produced over 70+ different deliverables in preparation for launch in February 2025 and while we can't feature them all (especially sensitive long-form memos), here are some of our favorites across the 4 pillars of the project.

1. Exploration
2. Program Management
3. Grants
4. Growth

1. Exploration

One of the earliest things we worked on was formulating a view on the evolution of liquidity using Wardley mapping. The analyses focused on the swapping and issuance landscapes, two crucial themes for DeFi.

It's great to see how many of these (then emergent) areas are now covered either by the L2 or various hook designs on Uniswap v4.

Other selected work:

• Developed a strategy memo for Unichain + Uniswap v4
• Completed various strategic analysis (competitive, value chain mapping, basis for competition, job map analysis)
• Developed a routing strategy for Uniswap v4
• Provided feedback on rollup stack evaluation
• Ran a workshop on rollup internals for the entire Uniswap Foundation team

2. Program Management

Auditless handled the initial program management for Unichain culminating in a dedicated offsite in Brussels organized by our team in parallel to UniDay. We also helped hire a Unichain lead who took over the work stream.

Other selected work:

• Built several cross-work stream, CRM trackers and an initial roadmap
• Ran project planning & check-in motions
• Recommended unichain.org and uniscan.xyz domains 🙂

3. Grants

While identifying how best to support Unichain developers, we gathered comprehensive data on major grant/growth programs for 6 leading chains and evaluated them for efficiency.

From there, we discarded anything that didn't maximize impact per $ invested and developed a set of initiatives targeted at helping builders along their journey from inception to scale.

We built an initial system for triaging, tagging and tracking incoming applications and ran the process directly during the initial burst period, then handed over to the Uniswap Foundation's internal ops team.

To facilitate the allocation of builder grants, we developed a custom UI for individual committee members to evaluate grantees in an unbiased and easy way.

The entire process is up and running and funding the most innovative new teams building on Unichain.

Other selected work:

• Helped prepare a Uniswap v4 routing RFP resulting in this whitepaper showing that universal routing is possible
• Built a prioritized partners tracker with 200+ tracked companies
• Developed an RFP for community management

4. Growth

We formulated 8 key verticals for DeFi growth and analyzed/prioritized viable candidate partners (both in DeFi and developer infrastructure) to guide pre-launch BD conversations.

We helped structure the incentives campaign and set its strategic, quantitative objectives. From our research, it was evident that many teams overspend on incentives or realize very low ROI so we discarded several incentive structures that were proven ineffective in practice.

Similarly, we identified assets to target for initial liquidity and designed the Unichain/L2 tracking dashboards developed by Allium to monitor the chain's growth.

Other selected work:

• Developed an RFP for the Unichain incentives program
• Researched special situations (e.g., Uniswap market share increase, stablecoin volume changes on other rollups, transaction volume drivers on other rollups)
• Built several Dune queries & dashboards
• Developed detailed growth projections and scenario analyses for Unichain
• Published theses on key Unichain/Uniswap v4 opportunities for builders:
• Uniswap v4 is the Sanctum of Restaking
• Uniswap v4 and Onchain Investment Banking
• Why You Should Build on Unichain Now
• Bunni: How To Build a Leading Uniswap v4 Hook

It was a privilege to support the launch of a top OP Stack/Superchain rollup and to work with the talented and professional Uniswap Foundation team and other grantees/partners during this pivotal year.

We're excited to see Unichain & Uniswap v4 house the next generation of DeFi innovations.

📬 Want more research from Auditless? Subscribe to the Newsletter.

Unichain: Behind the Scenes was originally published in Auditless on Medium, where people are continuing the conversation by highlighting and responding to this story.

With Uniswap v4, the Uniswap protocol expanded from supporting liquidity providers and swappers to providing a powerful and permissionless liquidity platform for DeFi developers. The Uniswap Foundation was responsible for ecosystem support in this transition and was looking for a grantee to provide technical and strategic input leading up to the launch of Uniswap v4 and the exploration of a new L2 (Unichain).

✨ Looking for help building your protocol? Just DM “Protocol” on Twitter.

Challenge

In late 2023, we were approached by the Uniswap Foundation to contribute to two major initiatives, a next-generation liquidity layer (Uniswap v4) and a DeFi focused L2 (now known as Unichain). To facilitate the exploration and launch of these initiatives, they needed a grantee to conduct technical and strategic research, planning and program management.

The Uniswap Foundation is the leading grant maker in the Uniswap Ecosystem, expecting to allocate over $130M in grants & incentives into 2026. As Uniswap reaches platform-scale, the Foundation has been instrumental in growing and empowering Uniswap developers as well as supporting governance and financial planning.

Solution

Auditless worked hand-in-hand with the Uniswap Foundation team, external stakeholders & advisors as well as other grantees to:

• Conduct research and provide technical input on topics such as rollup architecture, routing and help inform strategic/grant priorities;
• Run initial program management for Unichain, help evaluate product talent to support the transition to an internal team;
• Support the development of a growth strategy for Unichain;
• Design and help launch several grant initiatives for Unichain developers.

Results

Five months from launch, Unichain is now a top rollup with several flagship deployments such as Uniswap v4 (and various hook teams), Euler, Morpho, Venus, Velodrome and Compound. It is powered by the OP Stack and brings various improvements through partnerships with Uniswap Labs and Flashbots.

+$1B in TVL (+$1.2B in TVS)

Auditless developed the initial RFP for Unichain’s liquidity incentives campaign and provided input on incentive targets, assets to incentivize as well as campaign strategic and quantitative objectives.

The campaign has already exceeded expectations and catapulted Unichain to the top of the L2 leaderboard in TVL, creating a strong foundation to attract further developers, users and liquidity to the chain.

The superposition of Unichain and Uniswap v4 also provides clear differentiation for Unichain as a DeFi-focused liquidity hub chain in a crowded rollup market.

+765 Unichain builder submissions pre launch

Auditless helped shape the Builder Open Call Grants, Infinite Hackathon Grants and Retro Hackathon Grants, which were carefully designed to help identify and back grassroots builders.

These grants reached over 700 submissions before the chain was launched. The programs are now fully operationalized and grants are being rewarded and announced to teams on an ongoing basis with a goal to identify and accelerate the next-generation of DeFi builders.

📬 Want more research from Auditless? Subscribe to the Newsletter.

Unichain Reaches $1B in TVL was originally published in Auditless on Medium, where people are continuing the conversation by highlighting and responding to this story.

Aera is the world’s first autonomous, data-driven treasury management protocol. It allows treasuries and crypto institutions to achieve highly personalized objectives using a trust-minimized execution mechanism that taps into the best onchain opportunities.

Auditless is a web3-native protocol studio focused on protocol strategy, design & development. We help crypto protocols improve their performance through strategic advisory and protocol development.

As we recently announced, Auditless has been tasked with supporting the Aera Foundation in developing future versions of the protocol.

✨ To than end, we are hiring several protocol engineers at different seniorities. If you're interested in the opportunity, please check out the Jobs page and apply.

If you're wondering if this is the right opportunity for the next stage in your career, allow me to share some context.

Aera is solving a real and unique problem

Existing protocol treasuries form a large and underserved market. Due to friction in governance processes, regulatory burdens and the communication challenges associated with decentralized organisations, the majority of capital in these treasuries is sitting idle.

As Matthew Liu articulated for Blockworks:

The evolving crypto landscape cannot survive without crypto-native firms taking a more proactive approach toward treasury management. By blending traditional financial wisdom with crypto’s unique dynamics, firms can build a solid treasury framework that will help them navigate uncertainty and capitalize on opportunities.

So if the market is substantial and the appetite to act is there, why haven't existing solutions worked?

For one, nobody has figured out how to do treasury management in a decentralized or trustless way while preserving the dynamics of what is needed to respond to a rapidly evolving crypto market.

Most existing treasury management solutions effectively fall into one of three buckets:

• One-time treasury diversification. These approaches are explicit about what yield farms they prefer and usually allocate capital into a set of vaults. This is your grandfather's retirement fund but applied to crypto treasuries. Principled but hopelessly static.
• Centralized treasury management. The DAO elects a treasury manager who is somewhat restricted by smart contracts and effectively has a very broad remit around asset class choices and investment strategies. Breaks a lot of the properties that DAOs seek to achieve like credible neutrality, limiting points of failure and others.
• Inaction by democracy. The DAO only makes large reallocation decisions based on voting. Usually these decisions are driven by point-in-time proposals from DAO service providers who have their own incentive sets and don't lead to comprehensive objective-driven strategies.

Note that these three pillars form a perceived treasury management trilemma between Decentralization, Principled allocation and Effective allocation.

Faced with three choices that are fundamentally unappealing DAOs choose to keep their capital largely unallocated.

Aera breaks the treasury management trilemma

Aera is a solution that achieves all three desirable properties: trustless, principled & responsive treasury management. Here's how that works:

• Aera achieves responsiveness and efficacy by using off-chain guardians. Guardians are able to build complicated data pipelines and strategies to ensure that treasuries are managed using best available market instruments, are risk-aware, liquidity-aware and otherwise responsive to market conditions.
• Aera achieves trustlessness by limiting what guardians can do at the protocol level. A comprehensive hooks contract is used in each vault that limits the types of actions that a guardian can take and how they can impact the vault, bounding possible loss. Every action a guardian takes happens with assets that are approved, with actions that are whitelisted and with consequences that are within the approved parameters of the treasury owner. Safety first. Trustlessness will further improve as the initial permissioned model will evolve to a permissionless implementation with progressive decentralization.
• Aera achieves principled strategies through the use of a custom objective function for each treasury. The stated objective function serves as a point of alignment between the DAOs objectives and the guardians' actions. Guardians are incentivized to act only in ways that improve the objective function of the vault and not limited to simple strategies like seeking yield without consideration of insolvency.

Aera is built on a modular and extensible stack

Treasury management is a highly complex and easily obfuscated problem domain.

The “obvious” solution to a problem is can easily be convoluted and led to an accumulation of custom features, points of centralization and other forms of tech debt.

The entire Aera team fought against complexity, carefully evaluating what should exist onchain vs. off-chain and how Aera could serve a very wide array of institutions while being easy to reason about from a security perspective.

The result was a simple and modular protocol:

➡️ For more detail on how that works, you can read the behind the scenes.

🖥️ If you are just curious about the codebase, here’s the GitHub of the first two versions including audits.

Aera has traction

Perhaps most importantly, a growing number of DAOs are already running parts of their treasuries on Aera, lending credibility to the overall value proposition and our ability to deliver on it with a protocol.

One of the contributing factors to this is that Aera has a non-parasitic nature. It's a protocol that can happily exist to operate a tactical subset of a larger treasury and is additive and collaborative to existing treasury management offerings in the market.

For parts of treasuries that need to be responsive, principled and trustless, Aera can be used, sized and tuned appropriately.

The friction of deploying an Aera vault is already smaller than most alternative treasury management approaches today.

The Aera documentation transparently explains what's involved in vault operations today.

What's next?

Aera's successful start begets the question of the future.

There are clear vectors along which Aera will expand both vertically and horizontally.

On the vertical front, Aera's whitepaper outlines the vision behind decentralized treasury management driven by off-chain intelligence. There are many exciting problems to solve and translate into elegant protocol solutions in what is a category-defining protocol.

On the horizontal front, the Aera protocol has the privilege of being able to experiment with and use some of the latest tools in DeFi. A treasury needs to generate yield, trade tokens, borrow, provide liquidity and do many other functions that necessarily interact with a large surface area of DeFi.

It's the responsibility of the Aera core team to continuously and safely incorporate newly emerging protocols and ERC standards on the market to keep improving vault performance for clients. We are early adopters of ERC4626 for instance and are looking at many other standards.

As a protocol engineer for Aera, you will think about and write code that solves problems which other teams haven't even attempted to solve. You will do so in a highly collaborative way, working closely with the Gauntlet team and our external partners.

You will also help evolve our systems around shipping secure smart contracts. We have explored and adopted many modern practices like executable specifications, invariant testing, internal security reviews, extensive inline protocol documentation, explicit trust models and will continue to add to this list.

Simply put — you won’t be building the 20th DEX or lending protocol with a slightly different trading or interest rate curve.

If you're excited by solving challenges in unknown territory, you should definitely consider applying.

The best way to start a conversation is via the Jobs page.

Why the future is exciting

Ultimately, progress at Aera means progress in treasury management across crypto.

Improving the reliability and speed at which treasuries can fund and achieve their objectives means more progress, more public goods and a more stable and competitive crypto industry.

It's a worthy mission that will benefit long-term crypto-aligned token holders and not just drum up the next wave of speculation.

Work on Aera and help shape the future of treasury management was originally published in Auditless on Medium, where people are continuing the conversation by highlighting and responding to this story.

Auditless is a web3-native protocol studio focused on protocol strategy, design & development. We help crypto protocols improve their performance through strategic advisory and protocol development.

Five years ago (in December 2018), I left my job at McKinsey to start Auditless and build crypto developer tools focused on security.

I kept exploring various product ideas while consulting crypto companies, building developer tools and smart contracts.

It was easily the hardest and most rewarding part of my professional career.

Today feels like Day 1 again.

We are working on what we think will be some of the highest impact projects in the space, onboarding and accepting new clients and hiring for a bunch of exciting roles across strategy & development.

✨ Interested in working at Auditless? Please check out the Jobs page!

But the path to get here has been painful and slow at times.

And while I wouldn't change anything, there are a few things I would tell my older self to get here faster.

It's also a good time to revisit whether I'd choose bootstrapping again if I got started today.

Let's rewind to 2018…

Finding vulnerabilities in smart contracts

It all started with trying to find vulnerabilities in smart contracts.

I spun up web3.py, wrote some simple smart contracts using Truffle and built a simple reinforcement learning agent using OpenAI Gym and SimPy.

The audit industry was just emerging and I (as many people) had the mistimed (or misguided?) view that AI could entirely automate vulnerability finding.

LLMs weren't really viable then but neither was reinforcement learning.

The problem with reinforcement learning is that it's really good at optimizing values rather than finding inflection points in functions.

Vulnerabilities were a step function — finding one is more important than optimizing the exploit for maximum impact…

So it was back to the drawing board.

Trying formal verification

The next idea was to use a solver like Z3 to identify vulnerabilities in smart contracts.

So I started tinkering with Bounded Model Checking (a technique that a formal verification tool like Halmos uses).

It quickly became clear that encoding vulnerabilities without access to specs is a lost cause.

So instead of trying to find vulnerabilities — what if we helped users generate test cases instead?

I repurposed the solver to find gaps in byte code coverage and then generate valid test cases for smart contracts.

Unfortunately in the course of doing this I learned a lot about the limits of solver performance.

In short — smart contracts that contain even a normal amount of “hard to model” functions like divisional or modular arithmetic cannot be subjected to black box analysis.

It became clear that formal verification would be a game of helping users create annotations and specs and then verifying them.

(Note: I think Certora have built exactly the right kind of company to help smart contract developers with this.)

My goal, however, was to find a SaaS product that could help a broader set of users.

Smart contract debugging

If the goal was to help people with understanding smart contracts, perhaps there was a better way to do this?

Having built a low-level debugger for the formal verifier that came in handy, I was looking for something similar for Solidity.

But debugging Solidity transactions was notoriously difficult (compared to, for instance, debugging a Rust program).

This didn't make sense as smart contracts feature no non-determinism and are pretty well-behaved state machines.

So we set out to build the best possible time traveling debugger for Solidity.

Here's a preview of what it looked like:

It encapsulated in one interface many breakthrough ideas that debuggers still don't support:

• Fast interaction
• Instant breakpoints
• State change overviews
• Low-level debugging (gas & opcodes)

The UI got great feedback from some of the best Solidity developers in the space but was never remotely bug free.

Debugging is actually a significant back-end challenge.

Not only do you essentially have to build your own VM hook, you have to keep up with network, library and compiler upgrades constantly.

I still think we discovered a better interface for smart contract debugging but for several reasons it doesn't lead to a great business:

• Smart contract developers are usually pretty advanced and have their own workflows that help them avoid debugging rather than rely on it
• Most people develop locally and it's really hard to create a seamless user experience for local debugging with a UI (it still hasn't been done in 2023)
• Existing pricing schemes for tools like Tenderly reflect that users don't really value debugging instead opting to pay for security related features like monitoring
• Crypto has an open source ethos and many people felt that the debugger should be developed for free.

We wanted to build the best debugger and charge for it to warrant building a team, not a monitoring service in order to subsidize a debugger.

And we had more ambitious ideas than for what would have been possible with an open source tool.

To do it as a bootstrapped company just didn't make sense anymore.

Having said that, it was pretty tough to stop working on a product you know “should” exist and that users want to use.

Why bootstrap

Many people (including investors) ask me why Auditless is bootstrapped when there is so much capital available.

To be honest, I didn't think I would.

In fact, I was interviewed by YCombinator in 2018 (they weren't convinced developer tools in crypto was a big enough market).

The only decision I made at that point was to postpone investing until I find product-market fit with a product.

I had seen too many highly skilled Founders raise pre-product market fit and end up downsizing the company.

This was a failure mode I wanted to avoid at all costs.

So I bootstrapped.

As time went on, I also realized I'm not the right person to try and build a public company.

I realized I want to chip away at this for decades rather than push for a liquidity event.

Without that mindset of fighting the best possible exit for a company, I couldn't possibly responsibly take on capital.

The one thing that worked

Throughout all of the product experimentation, I still carried on doing consulting.

None of it was supported by any kind of sales our outreach process, instead I was responding to referrals and requests from people I already knew.

These were projects in developer tools, smart contract design, smart contract development, periphery tools, market maker tooling, even doing product strategy work for a fund.

One one hand I still had the desire to develop a product (these are so much easier to scale).

On the other, consulting allowed me work on products together with companies that were better capitalized and could exploit these opportunities.

And it worked well.

So earlier in 2023, I finally decided to double down on consulting full-time, focusing on strategic product advisory and development for high-performing crypto companies and startups.

What changed

I'm finally convinced that we could build a large and fast growing company built around these service lines.

This realization didn't come overnight.

In fact, my experience of consulting had been tainted by blue chip management consulting in McKinsey and I was very aware that it had taken a 100 years to build that business.

(It's a great business but I don't have 100 years.)

It came from figuring out two things that management consulting Firms never figured out (or didn't have to):

• How to scale distribution;
• How to scale delivery.

To be fair, some of these opportunities are highly contingent on the technologies and networks available today and the specific nature of the crypto industry.

And that's why I'm particularly excited to exploit them.

What did I learn

There are too many takeaways to list but here are five:

• Make sure you know what kind of company you are building (venture funded or bootstrapped) and vet opportunities accordingly. Both models are great but they each have ideas that are not compatible with the model.
• Bias on doing more in public rather than in private. People love to see half-baked products and your thinking. Lean on oversharing to get more feedback faster.
• Don't pattern match with other companies. Instead focus on what works and eliminating bottlenecks to scale that. Unique and iconic businesses are only built this way. Learn to be unbiased and to enjoy the things that are working rather than to only work on the things you are enjoying.
• Pick the right market and stick to it. I honestly think that one of the biggest reasons Auditless is still around and thriving (other than stubbornness) was the choice to start with crypto. Every failure we've had along the way has given us a level of experience and process knowledge that is highly useful to companies in 2023.
• Most importantly — Have integrity. I've probably lost a significant amount of money by not making certain trades or recommending certain products. That has bought me the right to keep working with other high integrity people on meaningful long-term work.

I will make THAT trade any day.

On that note, I'm incredibly appreciative of everyone who has been or continues to be a part of this journey but there are two people who helped define the trajectory: Tarun Chitra and Jesse Beyroutey. You shouldn't hesitate to work with them if you get the chance.

📬 Want more research from Auditless? Subscribe to the Newsletter.

✨ Interested in helping us develop historic crypto projects? See Jobs!

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:

1. Implement a highly pragmatic and current treasury management vehicle that would allow us to immediately start adding value to clients;
2. Scale to support a wide variety of assets, treasury objectives and strategies;
3. Provide a noncustodial implementation with strong onchain protections;
4. 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 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.

1. 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.

Aera Protocol: Behind the Scenes was originally published in Auditless on Medium, where people are continuing the conversation by highlighting and responding to this story.

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.

Challenge

Protecting over $9 billion in client assets, Gauntlet is the leading DeFi-native economic research firm used by market leaders like Uniswap, AAVE, Maker, Compound and others. When they set out to improve treasury management, it became clear that a non-custodial onchain protocol would be the best vehicle to do so. Having already conducted foundational research on what a decentralized treasury management mechanism could look like (some of these ideas can be seen in the Whitepaper), they needed an R&D partner to develop these concepts into a category-shaping protocol.

Solution

Auditless worked closely with the Product, Engineering, Leadership and Business Development teams at Gauntlet as well as with our security partners Spearbit to shape & develop a trust-minimized treasury management protocol which uses current DeFi instruments and off-chain guardians to satisfy a variety of custom treasury objectives.

The live Aera protocol is pioneering custom treasury objectives for each client, a frictionless deployment process and a path to decentralization through the use of a guardian role.

Results

The Aera Foundation has now raised $8M from Jump Crypto and Bain Capital Crypto to continue scaling the protocol while protocols and institutions already manage $4.3M of their treasuries using Aera.

+$4.3M since inception

Auditless helped develop two major versions of the Aera protocol (V1 and V2), which had led to several active treasury deployments. The flexibility of the underlying smart contracts allows Aera to address distinct needs with each deployment, varying from volatility targeting, deepening liquidity, generating yield on idle holdings and diversifying treasury assets.

Clients are drawn to the trust model that Aera provides, where guardian actions are highly limited and guarded by a variety of pre and post-execution hooks that include action whitelisting, allowance checks and limits on vault value changes — all enforced onchain.

On the flipside, Aera clients have full and immediate control over their funds and are free to utilize their Aera vault as a wallet.

+$8M raised for Aera

The ideas and traction behind the Aera treasury management solution have led to partnerships with world leading crypto investors (Source: PR Newswire):

“The Aera team has developed a much-needed solution perfect for crypto-native organizations looking to responsibly manage their treasuries,” said Stefan Cohen, partner at Bain Capital Crypto. “Aera is the first solution of its kind for DAO treasury management and was built by a team that’s amazingly well equipped to usher in a new era of responsible decentralized finance growth.”

📬 Want more research from Auditless? Subscribe to the Newsletter.

Aera Finance Raises $8 Million To Scale DAO Treasury Management was originally published in Auditless on Medium, where people are continuing the conversation by highlighting and responding to this story.

The best Solidity developers can program in Yul (an intermediate language used in Solidity code compilation) and understand the EVM. They do this because it helps them understand security vulnerabilities and optimize their code to make it efficient. They also do this because it's fun. At an extreme, OpenSea's Seaport protocol was written with significant amounts of assembly code.

Starknet also has an intermediate language called Sierra, built as a stable layer to allow for rapid iteration and innovation at the Cairo 1.0 language level. While not absolutely essential to write efficient programs (Starknet contracts written in high-level Cairo will be orders of magnitude more efficient than hand-optimized Solidity contracts), reading Sierra code can help us get a deeper understanding of the underlying type system, security risks and improving efficiency where it matters (e.g., reducing the storage footprint or execution steps in highly recursive functions).

For Cairo 0.x programmers, Sierra is the bridge between our past and the future, a familiar blueprint guiding our craft. Let's take a look.

If you'd like to follow along, you can generate readable Sierra output for your contracts by using the make sierra command in the Minimal Cairo 1.0 Template. This effectively runs cairo-compile . -r on your code. While Sierra is reported as stabilized, the present examples are accurate as of March 2023.

Starting from the bottom

The natural place to start is with a function that does nothing:

The Sierra output is organized into 4 separate sections always presented in the same order. First come the type declarations. Next, declarations of built-in library functions that will be used. Then the sequence of statements and finally the declared Cairo functions.

A couple of observations:

• The Unit type () is a special case of an empty struct and is used as a default return type for procedures (functions without a declared return type)
• New temporary variables are created and indexed using square brackets ( [0] and [1] )
• Statements have the following form <libfunc>(<inputs>) -> (<outputs>); , i.e., we don't see the more traditional [0] = struct_construct<Unit>();
• Code blocks are separate from Cairo function declarations. A function is tied to a specific block of code by starting at a dedicated statement index location (note the do_nothing@0 which indicates that the function begins at the first statement).

Types & Code generation

Sierra output can be used to understand how built-in types are used in compilation. Consider this simple function to add two felt values:

The output above is simple enough, showing us how function arguments become unnamed variables in statements.

Let's try a more complex type like u128 :

In this case, the output is much larger given that u128 is not a primitive type. This is reflected well in the function declarations:

• Our add function now has a phantom argument with a type of RangeCheck . This is a note to include the ZK circuit to help with felt comparisons, which is needed to perform addition. A welcome change from Cairo 0.x where built-ins had to be explicitly provided
• We see that some additional functions were generated in this case. These functions were included based on traits defined in the Cairo core library ( corelib). In short, any Cairo code needed for compilation will be present in the final Sierra output.

Control Flow

To study how control flow is represented, we can use a recursive function to compute the factorial:

In line 22, a function_call libfunc is used to make the recursive call. We also see the jump construct in line 13. The jump label is the index of the statement so jump() { 28() }; would take execution to row 29.

Learning more

I hope that this has been a useful teaser on how to read Sierra. Cairo smart contract developers and auditors alike shouldn't hesitate to jump down into Sierra to understand how their contracts work. There is a lot more going on behind the scenes, but Sierra strikes a good balance between readability and insight.

Reading Sierra: Starknet's secret sauce for Cairo 1.0 was originally published in Yagi Finance on Medium, where people are continuing the conversation by highlighting and responding to this story.

Yagi is a yield aggregator and keeper network on StarkNet. After announcing our first vault and being humbled by the interest from early depositors, the focus shifted to build more and better vaults on top of foundational yield opportunities in the StarkNet ecosystem.

After building a vault on top of a lending protocol, the next goal was to build on top of an AMM (automated market maker). I had the pleasure of meeting Rohit from JediSwap in the Amsterdam hackathon and we started to explore what we can do together. It became clear that the JediSwap community represented a healthy combination of grassroots energy and a deep understanding of DeFi as we brainstormed the needs of different market participants. It also became clear that we could start addressing those needs by developing a joint liquidity product.

Today, I'm pleased to announce that the DAI-ETH vault is available for testing on StarkNet Goerli.

The naive joint liquidity vault

JediSwap is an automated market maker that allows liquidity providers to provide liquidity for traders who can use different pools to trade between pairs of assets. Liquidity providers need to provide both assets in a pool in a specific ratio in exchange for liquidity fees (0.3% on trades distributed in proportion to liquidity provided).

To provide liquidity, a user must obtain and provide liquidity in both assets. For example, a user with only ETH needs to first trade to get DAI and then provide both ETH and DAI to provide liquidity in the pool. Our joint liquidity vaults simplify this process by only requiring one asset (either ETH or DAI) to start earning fees on JediSwap.

We are launching two different vaults, an ETH vault and a DAI vault whose positions are combined to provide liquidity on JediSwap.

You can go ahead and interact with these vaults right now at https://www.yagi.fi/vaults.

Are the vaults fair?

The magic of the vaults lies in their ability to account for how much of the liquidity share is owned by the ETH depositors and DAI depositors. In practice, this is done by simply returning the corresponding ETH and DAI in the liquidity share with no additional trading.

This works because JediSwap is a constant product market maker with a 50–50% weight distribution. This means that the reserves of both assets are valued equally in the pool.

To illustrate, consider that the current ETH price is $1500 and depositors are depositing 1 ETH and 1500 DAI in the vault respectively. The value of both parts is equal to $1500. Now consider an ETH price movement to $2000. In this case, the vault now holds 1732 DAI and 0.866 ETH after arbitrage. Why?

Note that the product is retained: 1732 x 0.866 ~ 1500 x 1.

And the spot price is now: 1732 / 0.866 = 2000.

The dollar value of both positions, however, is still equal to $1732.

In short, this means that each depositor is effectively holding an instrument that behaves like a liquidity share and follows the general equation of returns equals fees less impermanent loss as discussed here. Note: this is only true if the pool is effectively arbitraged. If the pool spot price deviates from the market price, then one side could be more valuable than the other.

Issues with the experimental vault

The current vault has a known griefing issue. In particular, vault shares are minted on every deposit meaning that users could trigger deposits maliciously when the spot price is not in agreement with the market price. Furthermore, they could do this while directly manipulating the spot price themselves.

We will address this vulnerability in upcoming versions but feel like an intermediate release on testnet is useful to improve our understanding of how to safely integrate with JediSwap and begin to educate our community on liquidity provision.

Future iterations of the vault will involve an exciting use of the Empiric oracle, Yagi keepers and other aspects we discussed at length in the StarkNet House talk.

Dive into L2 yield with us

Interested in L2-native and trustless yield opportunities on StarkNet whether as a developer, investor or user? Join our Discord.

Thanks

This launch would not have been possible without the following individuals:

• Thanks to Rohit Goyal from JediSwap for help in developing the vault concept
• Thanks to Prince Arora from JediSwap for help in reviewing the vault implementation and providing detailed technical information.

The first structured product on StarkNet: earn JediSwap liquidity fees in 1-click was originally published in Yagi Finance on Medium, where people are continuing the conversation by highlighting and responding to this story.

Earlier this year, Yagi launched as the first keeper network on StarkNet. On the way, we've hit several milestones such as powering innovative applications (e.g., Topology's Isaac game), building a community and collaborating with many teams in the space.

In terms of verticals, there is promising early adoption of Yagi Automation in Gamefi but we are only scratching the surface in terms of DeFi use cases.

Vaults as a major use case for keeper networks

Keepers thrive when automation can add value in an economically sustainable way and one of the most common applications is the re-balancing and management of automated vaults.

As we started thinking about how to spur more innovation on the vault side, we met with other great teams that are building yield solutions on StarkNet: Yearn (bringing L1 yield to StarkNet), Magnety (building managed vaults) and Sandclock (building multi-chain vaults). These products are fantastic and we expect to be passionate early adopters, however, these teams are not yet using keepers at the scale we would expect given their importance.

We think that keeper networks on StarkNet will enable a fourth use case that so far has been neglected: trustless L2 native yield.

What do we mean by Trustless L2-native yield?

L2-native yield comes from economic activity on L2 protocols like AMMs, lending markets and other primitives rather than from mainnet. We see StarkNet as more than just a cheap way to interact with existing protocols on mainnet — it will become a thriving financial ecosystem in its own right.

To be trustless, assets need to be managed by smart contracts and economic systems rather than individuals. Any intervention by individuals or concentration of power should be limited through strict incentives (e.g., such as those managed by a keeper network).

We think the recently launched ERC4626 vault standard will be an enabler for the development of more trustless vaults. ERC4626 facilitates composability of yield sources and vaults by enforcing clear patterns and guidelines. Earlier this year we built a reference implementation of the ERC4626 vault standard in Cairo.

The above ideas led to a hackathon project in StarkNet's DevConnect event in Amsterdam which we are now happy to release…

Introducing Yagi Vaults

Yagi Vaults is an aggregator for ERC4626 vaults that complements Yagi Automation, our keeper network. As a demonstration, we developed an xBank lending vault that you can use to lend ETH to xBank's algorithmic money market (detailed in a future post). At this time, it's one of the earliest fully-functional ERC4626 vaults on StarkNet and you can interact with it starting today.

Existing vault users may wonder why this interface is so simple.

We didn't hesitate to take advantage of StarkNet's architecture. For example, StarkNet account abstraction supports native multi-calls so deposits only require 1 transaction. We don't need to issue a separate approve transaction anymore.

For now, this is still an experimental testnet release which will more than likely to contain bugs. Our goal is to create more opportunities for our community to interact with StarkNet and fix issues to make the product more robust. As always, you can get in touch with us on Twitter or Discord to report any issues.

What's next?

We have plans to improve the interface while developing more yield sources directly with other early partners and pave ways to integrate our keeper network at the heart of these vaults.

We are particularly excited to work with teams building new types of primitive financial markets such as exchanges, stable coins, derivatives, lending products or other vaults we could build on top of. We also hope that this inspires other teams building vaults to use the ERC4626 standard and Yagi Automation and we would be happy to help there as well.

Dive into L2 yield with us

Interested in L2-native and trustless yield opportunities on StarkNet whether as a developer, investor or user? Join our Discord.

Thanks

This launch would not have been possible without the following individuals:

• Thanks to Nick Chikovani from Altzone for help in exploring XBank's contracts and building a lending vault prototype
• Thanks to Timothy Arslan from xBank for kindly answering questions about the integration
• Thanks to Janek from Argent and StarkWare team for debugging help during the hackathon
• Thanks to Francesco Ceccon from Apibara for help in leveraging his excellent hooks library
• Last but not least, thanks to Louis Guthmann, Uri Kolodny and the rest of the StarkWare team for relentless help and support.

Trustless L2-native yield has arrived on StarkNet was originally published in Yagi Finance on Medium, where people are continuing the conversation by highlighting and responding to this story.

Summary. In this post, I will argue that Cairo can effect the coming wave of provable computation in the same way that Solidity has enabled composable computation. Cairo is the native programming language of StarkNet, a Layer 2 network designed to scale Ethereum.

—

It's regrettable when we see smart contracts merely as an extension of finance (DeFi) or a generalization of the web (web3). Smart contract networks are really platforms for composable computation.

Ethereum embeds certain standards that allow its computer programs to interoperate:

• Transparent byte code (no hidden web APIs)
• Standardized API structure (called the ABI)
• Guaranteed uptime (each app is hosted on multiple machines, per-app Denial of Service is uneconomical)
• Built-in payment infrastructure (no reliance on 3rd parties like Stripe)
• Full deployment and transaction lineage
• Friction-less contracting between different application layers (governance, ownership, etc.).

These constraints can impair developer productivity (see critiques of web3) but has also incentivize composition and re-use of stateful applications at an unprecedented scale.

Solidity was the first mainstream language for composable computation

Solidity was created as a simple language that is compatible with the above standards. It provided:

• Basic state machine functionality (state, access, updates, etc.)
• No access to non-composable primitives (e.g., external data feeds)
• Interfaces for contract-to-contract interaction (means of composition)
• Built-in gas metering for transaction fees
• Performant access to the underlying virtual machine (assembly).

While existing programming languages can be adapted to service composable computation, they need a combination of extension (adding interfaces for composition) and restriction (removing all forms of non-determinism and external access) that is difficult to incorporate. Moreover, the compilers of these languages were defined to optimize a completely different performance metric (execution footprint) than is required to optimize Solidity code (gas costs).

Introducing Provable Computation

StarkNet's scalability tool, ZK Roll-ups, enable a new paradigm called Provable Computation. In this paradigm, we retain all the benefits of composable computation but also allow programs to prove they have been executed without having to be re-run.

This simple idea allows us to move from a network (Ethereum) where validating a transaction requires re-running it to a better network (StarkNet) where transactions are validated by validating the proof that they have been executed with a certain outcome, a much more economical operation.

Because this paradigm is so different, it also requires a different computing model, effectively turning programs into number theoretical equations rather than executing them on a machine.

What programming language could we use possibly use for this?

Solidity vs. Cairo

It's natural to consider Solidity. For one, it already supports composition (calling other smart contracts) and is widely adopted. Two, there are a range of applications that are deployed on Solidity that can be easily migrated to other Layer 2 solutions (including zkSync which supports Provable Computation). Three, Solidity has a well-maintained multi-layer compiler that can be adapted to serve different use cases.

But Solidity is not native to provable computation. Any compiler that takes idiomatic Solidity code and translates it into proofs will struggle with the following issues among others:

• Reliance on inefficient data structures like uint256 and operations on them
• Mutability at the language level
• Lack of efficient built-ins
• No low-level access.

Technical detail. In practice, there are 2 different technologies for proving general programs (SNARKs and STARKs). Instruction sets favored by SNARKs are better suited as a compilation target for languages like Solidity. STARKs offer more scalability while having a less natural instruction-set. So when we say “Solidity is not an efficient language for provable computation, we really mean two things: 1) Solidity can be efficiently encoded to SNARKs, but they are not as scalable as STARKs 2) Solidity is not the optimal language to compile to STARKs since constructs that are common in Solidity are “costly” for STARKs. [1]

Cairo has solutions for all the above:

• A low-level field integer data type called felt is available (alongside a uint256 type)
• The Cairo language is idiomatically write-once (like a functional programming language)
• A growing list of built-in non-deterministic hints is being developed for common computations
• Cairo provides full low level access to underlying primitives. [1]

Yes, programming in Cairo is also more challenging and ecosystem tools are still maturing. But the whole point of scaling Ethereum is to transcend existing limitations and build better composable applications. If so, why stop at Solidity?

Surf the paradigm with us

Interested in the potential of provable computation on StarkNet whether as a developer, investor or user? Join our Discord.

—

[1] Cairo Whitepaper, https://www.cairo-lang.org/cairo-whitepaper/

Provable vs. Composable Computation or why Cairo will supersede Solidity was originally published in Yagi Finance on Medium, where people are continuing the conversation by highlighting and responding to this story.