Is DeFi safe? A smart contract auditanswers part of that question, but not all of it. An audit provides assuranceabout the code reviewed; security also depends on economic design, governance,infrastructure and the organisation operating the protocol.
After BailSec audited 1inch Aqua, 1inchinvited Vik from our team to discuss audit limitations and the securityimplications of Aqua's shared-liquidity design. This article draws on that interviewwith 1inch to explain what we assess, where an audit's assuranceends and how users and partners should interpret the results.
Many of the risks we assess extend beyondobvious code bugs. Five areas deserve particular attention.
The ecosystem. A protocoldepends on the environment in which it runs. Flash-loan liquidity manipulation,variations in common token standards and potential breaks caused by futureEthereum Virtual Machine (EVM) hard forks can all affect its security.
Composability. The ability tocombine protocols is a core value of DeFi. It also means a system can be usedin ways its authors never intended. Assessing those interactions requiresexperience in protocol security and a broad understanding of how people usesmart contracts.
Design patterns. Establishedstandards, including Ethereum Request for Comments (ERC) specifications, andwell-understood techniques support robust interactions. Using establishedpatterns for familiar problems allows auditors to focus on the parts of aprotocol that are genuinely new.
Economic attacks.Second-order vulnerabilities include the free option problem, impermanent loss,deleveraging, depegs, bad debt and statistical arbitrage. Assessing these riskstakes expertise beyond code review, including knowledge of how decentralisedfinancial products behave in practice. Our explanation of front-running vulnerabilities examines onerelated class of attack.
Governance. What happens if atrusted party is no longer trustworthy? A well-designed protocol uses defencein depth and limits even privileged roles to the minimum permissions needed toperform their functions.
An audit gives a high degree of assurancethat a system behaves as designed. It is not proof that the code is bug-free orcannot be hacked. That distinction matters when interpreting both the reportand the claim that a protocol has been audited.
Scope and time matter.Auditors review specified parts of a system within an agreed timeframe. If aclient introduces additional complexity during the engagement, the originalestimate may no longer allow the intended level of coverage.
Experienced auditors can still make mistakes. At BailSec, we rigorously test the experienced security researcherswe hire. This reduces the chance of missing a substantial vulnerability, but itcannot eliminate human error.
Finding density is a signal.Numerous findings rated Medium or above suggest that more bugs may remain evenafter the fix review. In that situation, we recommend another round of audits.Good initial design remains essential; our guide to smart contract audit readiness explains howteams can prepare.
Post-audit changes fall outside the original assurance. Auditors cannot ensure that later changes avoid new bugs orpreserve the invariants checked during the audit. These invariants are theconditions the system is intended to maintain. Changes after the engagement aremade at the project's own risk and are not recommended without further securityreview.
Formal verification also has limits. Itestablishes that the reviewed code matches a formal specification, but thatspecification may be incomplete or miss an attack vector. The code eventuallydeployed may also differ from the code reviewed. Neither a manual audit norformal verification can establish that exploitation is impossible.
In our assessment, infrastructure and keycompromise are now the largest root cause of losses across the ecosystem bydollar value. Unless explicitly included in the scope, a smart contract audittypically does not review those components.
Modern protocols combine contracts withAPIs, front ends, infrastructure and other off-chain systems. Some componentscontain intellectual property or trade secrets that a project does not discloseto an external contract auditor. A contract review alone therefore cannotestablish that the full system preserves the intended security properties.
Good contract design can substantiallyreduce this risk. Where practical, teams can move off-chain logic fullyon-chain and minimise the mutability of on-chain components. Robust, immutablesystems allow manual review to eliminate exceptions and assumptions, providinga higher degree of assurance. Off-chain components also need their own securityassessment.
Security attestations and certificationsaddress the organisation that builds, deploys and operates a protocol. Theyhelp provide assurance about how smart contracts, off-chain components andoperational processes work together.
SOC 2 and ISO 27001 address controls suchas access management, key management, change management, vendor risk andincident response. Change controls provide assurance that new versions preservethe system's intended invariants. These frameworks also provide evidence thatan organisation has taken steps to reduce supply-chain risk, while controlsover endpoints and personnel reduce exposure to some insider attacks.
A SOC 2 Type I report reflects controls ata particular point in time. A Type II report covers controls over a period.Neither SOC 2 nor ISO 27001 can prevent every hack, but they reduce risksarising from weaknesses in the components and processes they cover.
These attestations and certificationssignal organisational seriousness and maturity. They also show how centralsecurity is to the product. Treating them as a rubber stamp overlooks the workrequired to obtain them. Equally, obtaining them does not mean a company hasabandoned a crypto-native ethos.
Users and partners should read the scopeand any exceptions. They should not infer that deployed smart contract code issecure: a controls assessment is not a code security audit. As discussed in theinterview, deployed contract code is outside that scope, and the companydetermines the scope of a SOC 2 examination. A Type I report should not betaken as evidence that controls have operated continuously over time.
1inch Aqua combines customisable strategieswith shared capital. A maker supplies liquidity through a strategy; a takerinteracts with that strategy to execute a trade. The same maker capital cansupport several strategies at once, increasing capital efficiency whilechanging the risks that must be assessed.
Aqua gives makers considerable flexibilityin how they construct strategies. The software used to build those strategiesmust follow robust compositional rules to avoid invalid configurations thatcould cause losses. Shared capital also increases a maker's exposure to aneconomically vulnerable strategy: a single risky strategy can potentially causelosses equal to all the deployed capital.
Takers explicitly select the makerstrategies they consider most liquid. This differs from a typical automatedmarket maker (AMM), where multiple liquidity providers pool capital into onestrategy and the calculation required to interact with it is independent of thenumber of providers.
Liquidity stays in the maker's wallet untila taker fills against a position. This eliminates certain classes of attackthat can drain funds held in liquidity pools, improving the security posture ofthe design. Makers can also cut exposure to unwanted strategies by docking themor revoking allowances.
Some risk shifts rather than disappears:from balances held in pools to ERC-20 allowances, the permissions that allow acontract to transfer tokens. In our assessment, the overall security posture isan improvement, but allowance management and strategy security remainimportant.
The smart contracts ensure that liquiditycannot be used twice. However, one strategy can run out of available liquiditybecause a neighbouring strategy has consumed the shared balance. Off-chainsystems unaware of this design may also count that balance more than once,overstating aggregate market depth, total value locked (TVL) or availableliquidity.
The order in which takers consume liquiditycan affect the price of subsequent swaps. Systems routing through Aqua needenough knowledge of the architecture to sequence interactions carefully. Fortakers, the main risk is that a maker runs out of capital during a swap becausecollateral is shared; routing logic must account for that dependency.
Every swap must include an appropriateslippage limit check to guard against adverse execution and attacks involvingmaximal extractable value (MEV) and front-running. Flexible execution does notremove that requirement.
These points describe Aqua's threat modeland integration considerations. They should not be read as a list ofvulnerabilities discovered in the audit. The BailSec final security audit report for 1inch Aquais the reference for the reviewed scope and documented findings. Itsconclusions apply to the code and scope identified in that report.
Aqua's audit indicates that its authorstake security seriously and provides evidence that the system has improved fromits initial implementation. Completing an audit with an experienced team movesa protocol towards greater security, but security remains a process rather thana finished state.
Users and partners should consider both theaudit evidence and their own exposure:
· Limit potential losses. Avoid exposing yourself to losses you cannot tolerate from a DeFiposition.
· Quantify risk where possible. Assess whether expected returns are favourable after accounting forthe risks.
· Read the audit report. Examine its scope, findings and limitations instead of treating anaudit badge as a guarantee. We recommend reading our reports and make themavailable through our public audit collection.
· Use AI summaries as a reading aid. Non-technical readers can use an LLM to summarise findings and askfollow-up questions. Check important conclusions against the report itself.
Does a smart contract auditguarantee that a protocol is safe?
No. It provides assurance about thereviewed system, within a defined scope and timeframe. It cannot prove that thecode is bug-free or immune to exploitation.
What does a smart contract auditusually leave out?
Unless included in the engagement, ittypically excludes off-chain infrastructure, APIs, front ends and keymanagement. Those components need separate attention.
Do SOC 2 or ISO 27001 establishsmart contract security?
No. They address organisational controlsand the systems within their scope. They do not replace an assessment ofdeployed smart contract code.
What makes Aqua different from atraditional AMM?
Funds remain in the maker's wallet until aposition is filled, and one balance can support multiple strategies. Thisremoves certain classes of pool-draining attack while introducingshared-liquidity dependencies and leaving risks associated with allowances andindividual strategies.
For the conversation behind this article,read Vik's full interview on the 1inch blog.
Planning a security review? ContactBailSec about a smart contract audit.
