How safe is DeFi? BailSec’s Vik on audits, security and 1inch Aqua

An audit can reduce risk, but it can never guarantee that a DeFi protocol is safe. 1inch spoke to Vik from BailSec about what smart contract audits actually tell us, the risks that exist beyond the code and what stood out when BailSec audited 1inch Aqua.

Smart contract audits have become a standard part of DeFi security. But hacks still happen to audited protocols. And increasingly, the weak point may not be the smart contract at all.

So what does an audit really prove? And how should you assess the security of a new architecture such as 1inch Aqua?

1inch spoke to Vik from BailSec, one of the security firms that audited Aqua, about the limits of audits and the security implications of Aqua’s approach to liquidity.

When you assess the security of a DeFi protocol today, what are the biggest risks you look for beyond obvious smart contract bugs?

Many risks come from beyond the code. We look at the ecosystem itself, composability, design patterns, economic attacks and governance.

Ecosystem-level risks involve things like flash loans, liquidity manipulation, unusual token variations and potential breaks caused by future EVM hard forks.

Composability is a core value proposition of DeFi. But it also means a system may be used in ways its authors did not intend when they wrote it. Assessing that risk requires long experience with protocol security and a broad understanding of how people actually use smart contracts.

Design patterns matter as well. Established standards such as ERCs and well-understood techniques can lead to more robust interactions. A well-designed protocol uses established patterns to solve standard problems so developers can focus on the parts that are genuinely new.

Then there are economic attacks. These include second-order vulnerabilities that go beyond smart contract security and require familiarity with how DeFi products actually get used.

Finally, there is governance risk. The question is: what happens if a trusted part of the system is not so trusted? A well-designed system takes a defense-in-depth approach and limits even privileged roles to the minimum permissions they need.

How should teams think about the limits of an audit? What can a strong audit establish and what can it never guarantee?

Auditors are skilled experts, but they are limited by the scope of the engagement. We are limited both by time and by which portions of the system are under review.

An audit is also time-bound. If the client introduces additional complexity in the middle of the engagement, it may no longer be possible to achieve the coverage that the original time estimate was intended to provide.

And auditors can make mistakes. At BailSec, we rigorously test the auditors we work with and hire some of the best auditors in the space to dramatically reduce the risk that an auditing team misses a substantial bug. But that risk is never zero.

If an audit report contains many medium- and high-severity findings, that density can suggest there may be more bugs remaining after the review. In that case, we recommend engaging another audit team for a second round.

The development team might also change the code after the audit. We cannot ensure that those changes do not introduce new bugs or violate invariants that were verified during our audit.

Even without any of those issues, an audit can never guarantee that a codebase is bug-free or cannot be hacked. It provides a high degree of assurance that the system behaves as designed. It is not proof.

Even formal verification cannot ensure that a codebase is entirely free of unexpected behavior. Formal verification establishes that reviewed code matches a formal specification, but the specification itself may be incomplete. It could miss an attack vector. And the code eventually deployed may not be the code that was reviewed.

Smart contract audits used to be mostly about the contracts themselves. How much does security now depend on protecting the whole stack?

Infrastructure and key compromise have become a major root cause of losses across the ecosystem by dollar value.

Unless otherwise specified, a smart contract audit typically does not include those components. Some may also contain intellectual property or trade secrets that a project does not want to disclose to a third-party smart contract auditing firm.

That makes it difficult for us to ensure that the combination of APIs, the frontend, infrastructure and other off-chain components maintains the invariants intended by the team.

Good smart contract design can go a long way toward mitigating these risks. Where possible, logic can be moved from off-chain components on-chain, while the mutability of on-chain components can be minimized.

Immutability is a desirable quality in a robustly designed smart contract system because it reduces exceptions and assumptions and can provide a higher degree of assurance.

What do SOC 2 and ISO 27001 cover that a smart contract audit cannot?

These security controls and certifications help cover a missing component: the combination of smart contracts, off-chain components and the larger organization operating them.

The frameworks address the organization that builds and operates the system, including access controls, key management, change management, vendor risk and incident response.

Supply-chain attacks have also become a greater risk in recent years. These standards provide evidence that an organization has taken steps to reduce that risk. Controls over endpoints and personnel can also help reduce the risk of insider attacks.

There is an important distinction within SOC 2 between a Type I attestation, which looks at controls at a point in time, and Type II, which covers how controls operate over a period of time.

But SOC 2 and ISO 27001 are not magic bullets. Just as a smart contract audit cannot completely prevent a hack, these frameworks cannot eliminate risk. They reduce the risk caused by weaknesses in other components of the system.

BailSec audited 1inch Aqua earlier this year. What was unusual or particularly interesting about Aqua from a security perspective?

First of all, Aqua was something very fresh and new to the DeFi world, which was refreshing for us to review. It was not another fork of something else.

Aqua has a special design in two respects. It allows a high degree of customizability and flexibility in the strategies through which market makers deploy their capital. And it increases capital efficiency by allowing makers to deploy the same capital into multiple strategies.

That customizability puts more responsibility on the software components used to design strategies. They need to follow robust compositional rules and avoid invalid strategy configurations that could result in a loss of funds.

Deploying the same capital across multiple strategies also means that, while capital efficiency increases, the exposure of a maker’s capital to an economic vulnerability in a strategy can increase as well.

Another unusual feature is the requirement for takers to explicitly specify the maker strategies they interact with. That is an inversion of the typical AMM design, where multiple makers put capital into a single pool and interaction with it does not depend on the number of underlying makers.

Aqua lets liquidity remain in the maker’s wallet until a taker fills a position. Does that create additional risks?

Aqua’s design eliminates certain classes of attacks that can drain capital held in liquidity pools. Eliminating that line of attack improves the security posture of the design.

It also gives makers an effective mechanism for cutting off their exposure to undesirable strategies by docking or revoking allowances.

Some risk is not fully eliminated but instead moves from balances held in pools to ERC-20 allowances. Still, the overall posture is an improvement.

What about double-spending? If the same balance backs multiple strategies, can the same liquidity be used twice?

The smart contracts themselves ensure that liquidity cannot be used twice.

But shared capital does mean that one strategy may run out of available liquidity because a neighboring strategy has consumed it.

It is also important to keep this shared-capital model in mind when calculating aggregate market depth, TVL or available liquidity. Otherwise, off-chain components that do not understand how the system works could count the same liquidity twice.

So the liquidity cannot be spent twice by the smart contracts, but it can potentially be counted twice by off-chain systems.

Aqua gives takers more flexibility. Can that flexibility also increase risk?

Yes. The order in which liquidity is consumed by the taker can affect the price at which future swaps take place.

Off-chain components that assess liquidity therefore need enough domain knowledge to sequence interactions appropriately.

For makers, a single economically risky strategy could potentially produce losses affecting the capital deployed across strategies. For takers, the main risk is that a particular maker may run out of capital during a swap because of collateral sharing. Systems deciding how to use the available liquidity need to account for that.

All swaps should also be protected by appropriate slippage limits to reduce exposure to risks such as MEV and front-running.

Aqua has been audited. Does that mean it is safe?

An audit cannot ensure total safety. The fact that Aqua has undergone multiple audits is a strong indication that its authors take security seriously. It also provides evidence that the security of the system has been improved from its initial implementation.

But protocol security is a continuum. It is not a single state. Completing audits with multiple expert teams moves a protocol further along that continuum, but issues can still slip through an auditor’s review. That is why it is important to engage multiple teams and put as many expert eyes as possible on the contracts.

Users should also consider the risks of interacting with DeFi products and avoid exposing themselves to losses they cannot tolerate.

For sufficiently technical users and partners, the published audit reports themselves provide details about the potential pitfalls of the system and exactly what the auditing teams considered as part of their reviews.

At BailSec, we always recommend reading the reports. For non-technical users, AI tools can now also make it much easier to summarize audit findings and understand what a report actually says about a protocol’s security.

Security is never a finished job. Audits, careful protocol design and ongoing review can reduce risk, but none can turn DeFi into a risk-free environment.

For more on blockchain security, subscribe to our newsletter