- Total Prize Pool: $183,500 in USDC
- HM awards: up to $176,800 in USDC
- If no valid Highs are found, the HM pool is $60,000
- If no valid Highs or Mediums are found, the HM pool is $0
- QA awards: $3,200 in USDC
- Judge awards: $3,000 in USDC
- Scout awards: $500 in USDC
- HM awards: up to $176,800 in USDC
- Read our guidelines for more details
- Starts November 19, 2025 20:00 UTC
- Ends December 10, 2025 20:00 UTC
- A coded, runnable PoC is required for all High/Medium submissions to this audit.
- This repo includes a basic template to run the test suite.
- PoCs must use the test suite provided in this repo.
- Your submission will be marked as Insufficient if the POC is not runnable and working with the provided test suite.
- Exception: PoC is optional (though recommended) for wardens with signal ≥ 0.68.
- Judging phase risk adjustments (upgrades/downgrades):
- High- or Medium-risk submissions downgraded by the judge to Low-risk (QA) will be ineligible for awards.
- Upgrading a Low-risk finding from a QA report to a Medium- or High-risk finding is not supported.
- As such, wardens are encouraged to select the appropriate risk level carefully during the submission phase.
V12 is Zellic's in-house AI auditing tool. It is the only autonomous Solidity auditor that reliably finds Highs and Criticals. All issues found by V12 will be judged as out of scope and ineligible for awards.
V12 findings can be viewed here.
Anything included in this section is considered a publicly known issue and is therefore ineligible for awards.
Any vulnerabilities that pertain to the experimental nature of the 0.8.31 pre-release candidate and the project's toolkits are considered out-of-scope for the purposes of this contest.
Tokens that have non-standard behavior e.g. allow for arbitrary calls may not be used safely in the system.
Token balances are only expected to change due to calls to transfer or transferFrom.
Any issues related to non-standard tokens should only affect the pools that use the token, i.e. those pools can never become insolvent in the other token due to non-standard behavior in one token.
The extensions in scope of the audit are not expected to be able to freeze a pool and lock deposited user capital.
Third-party extensions, however, can freeze a pool and lock deposited user capital. This is considered an acceptable risk.
TWAMM order execution quality is dependent on the liquidity in the pool and orders on the other side of the pool.
If any of the following conditions are true:
- Liquidity in the pool is low
- The other side has not placed orders
- Blocks are not produced for a period of time
The user may receive a bad price from the TWAMM. This is a known risk; the TWAMM order execution price is not guaranteed.
Ekubo Protocol delivers the best pricing using super-concentrated liquidity, a singleton architecture, and extensions. The Ekubo protocol vision is to provide a balance between the best swap execution and liquidity provider returns. The contracts are relentlessly optimized to be able to provide the most capital efficient liquidity ever at the lowest cost.
- Previous audits:
- Documentation: https://docs.ekubo.org/
- Website: https://ekubo.org/
- X/Twitter: https://x.com/EkuboProtocol
For a machine-readable version, see scope.txt
| File |
|---|
| test/**.** |
| Totals: 68 |
For a machine-readable version, see out_of_scope.txt
We use a custom storage layout and also regularly use stack values without cleaning bits and make extensive use of assembly for optimization. All assembly blocks should be treated as suspect and inputs to functions that are used in assembly should be checked that they are always cleaned beforehand if not cleaned in the function. The ABDK audit points out many cases where we assume the unused bits in narrow types (e.g. the most significant 160 bits in a uint96) are cleaned.
The sum of all swap deltas, position update deltas, and position fee collection should never at any time result in a pool with a balance less than zero of either token0 or token1.
All positions should be able to be withdrawn at any time (except for positions using third-party extensions; the extensions in the repository should never block withdrawal within the block gas limit).
The codebase contains extensive unit and fuzzing test suites; many of these include invariants that should be upheld by the system.
| Role | Description |
|---|---|
Positions Owner |
Can change metadata and claim protocol fees |
RevenueBuybacks Owner |
Can configure buyback rules and withdraw leftover tokens |
BaseNonfungibleToken Owner |
Can set metadata of the NFT |
The repository utilizes the foundry (forge) toolkit to compile its contracts, and contains several dependencies through foundry that will be automatically installed whenever a forge command is issued.
Most importantly, the codebase relies on the clz assembly operation code that has been introduced in the pre-release solc version 0.8.31. This version is not natively supported by foundry / svm and must be manually installed.
The compilation instructions were evaluated with the following toolkit versions:
- forge:
1.4.4-stable - solc:
0.8.31-pre.1
The 0.8.31 compiler must become available as if it had been installed using the svm-rs toolkit that foundry uses under the hood. As the toolkit itself does not support pre-release candidates, the version must be manually installed.
To achieve this, one should head to the folder where solc versions are installed:
- Default Location:
~/.svm - Linux
~/.local/share/svm - macOS:
~/Library/Application Support/svm - Windows Subsystem for Linux:
%APPDATA%\Roaming\svm
A folder named 0.8.31 should be created within and the pre-release binary of your architecture should be placed inside it aptly named solc-0.8.31 without any extension.
To download the relevant pre-release binary, visit the following official Solidity release page: https://github.com/argotorg/solidity/releases/tag/v0.8.31-pre.1
After the relevant 0.8.31 compiler has been installed properly, the traditional forge build command will install the relevant dependencies and build the project:
forge buildThe following command can be issued to execute all tests within the repository:
forge testThe scope of the audit contest involves multiple internal and high-level contracts of varying complexity that are all combined to form the Ekubo AMM system.
Wardens are instructed to utilize the respective test suite of the project to illustrate the vulnerabilities they identify, should they be constrained to a single file (i.e. RevenueBuybacks vulnerabilities should utilize the RevenueBuybacks.t.sol file).
If a custom configuration is desired, wardens are advised to create their own PoC file that should be executable within the test subfolder of this contest.
All PoCs must adhere to the following guidelines:
- The PoC should execute successfully
- The PoC must not mock any contract-initiated calls
- The PoC must not utilize any mock contracts in place of actual in-scope implementations
Employees of Ekubo Protocol and employees' family members are ineligible to participate in this audit.
Code4rena's rules cannot be overridden by the contents of this README. In case of doubt, please check with C4 staff.
