Live
Current submission phase ends in 3 days

Ramses Exchange

The Ramses Kingdom is a next-generation decentralized exchange (DEX) suite, enhancing Uniswap V3's concentrated liquidity model. With advanced liquidity mining & a community-driven governance system, it delivers a seamless, innovative trading experience.

  • Start date8 Oct 8:00 PM UTC
  • End date29 Oct 8:00 PM UTC
  • Total awards$120,000 in USDC
  • Duration21 days

Ramses Exchange audit details

  • Total Prize Pool: $120,000 in USDC
    • HM awards: $76,800 in USDC
    • QA awards: $3,200 in USDC
    • Judge awards: $9,750 in USDC
    • Validator awards: $9,750 in USDC
    • Scout awards: $500 in USDC
    • Test coverage invitational: $20,000 in USDC
  • Read our guidelines for more details
  • Starts October 8, 2024 20:00 UTC
  • Ends October 29, 2024 20:00 UTC

ℹ️ This competition includes Rolling Triage. The submission phases are as follows:

  • Week 1:
    • Oct 8-11 (Tue-Fri): submissions open (HMs only)
    • Oct 11-15 (Fri-Tue): submissions paused for triage
  • Week 2:
    • Oct 15-18 (Tue-Fri): submissions open (HMs only)
    • Oct 18-22 (Fri-Tue): submissions paused for triage
  • Week 3:
    • Oct 22-29 (Tue-Tue): submissions open (HM + QA)

The HM pool for this audit will divided into increasing shares as the audit progresses. 10% of the HM pool is allocated for findings surfaced in Week 1; 20% is allocated to Week 2; and 70% is allocated to Week 3.

Low-risk issues (QA reports) should only be submitted in Week 3. Any QA reports submitted early will be invalidated and ineligible for awards.

Questions about rolling triage may be asked in this Discord thread.

Note: This competition will be followed by a private Zenith mitigation review.

Automated Findings / Publicly Known Issues

  • The 4naly3er report can be found here.

  • Fee-on-transfer tokens (tax tokens) are not compatible with the concentrated liquidity system.

  • Wardens who either:

    • submitted findings during the first Rolling Triage cohort, and/or
    • have earned the SR role,

    may also view preliminary known issues here, and invalidated submissions here.

Please also note:

  • Ramses is a ve33 DEX with stableswap pools, univ2 pools and univ3 pools
  • As such, wardens are advised to look carefully at modified code, vs code that has been forked intact from Univ2 and UniV3 live code.
  • Any publicly known issues - e.g. Uni V3 audits - and/or established design choices in UniV3 live code will be assumed to be out of scope for this audit as well.

Note for C4 wardens: Anything included in this Automated Findings / Publicly Known Issues section is considered a publicly known issue and is ineligible for awards.

Overview

The Ramses Kingdom is a next-generation decentralized exchange (DEX) suite, enhancing Uniswap V3's concentrated liquidity model.
With advanced liquidity mining & a community-driven governance system, it delivers a seamless, innovative trading experience.

Ramses V3 (the codebase for this competition) refines our existing contracts from our V2 deployment, removing proxies, increasing gas efficiency, and further decentralizing control of the protocol.
The primary focus of the competition is to identify any findings related to concentrated liquidity provisioning, and rewards accrual from in range positions.

Ramses V3 Systems & Architecture

contract-infographic

Links


Scope

See scope.txt

Files in scope

FileLogic ContractsInterfacesnSLOCPurposeLibraries used
/contracts/CL/core/RamsesV3Factory.sol1****116@openzeppelin/contracts/access/manager/AccessManaged.sol
/contracts/CL/core/RamsesV3Pool.sol1****621@openzeppelin/contracts/interfaces/IERC20.sol
/contracts/CL/core/RamsesV3PoolDeployer.sol1****20
/contracts/CL/core/libraries/Oracle.sol1****308
/contracts/CL/core/libraries/Position.sol1****282
/contracts/CL/core/libraries/Tick.sol1****93
/contracts/CL/gauge/ClGaugeFactory.sol1****29
/contracts/CL/gauge/FeeCollector.sol1****100@openzeppelin/contracts/proxy/utils/Initializable.sol<br>@openzeppelin/contracts/token/ERC20/utils/SafeERC20.sol
/contracts/CL/gauge/GaugeV3.sol1****393@openzeppelin/contracts/token/ERC20/utils/SafeERC20.sol<br>@openzeppelin/contracts/utils/math/Math.sol
/contracts/CL/periphery/NonfungiblePositionManager.sol1****288@openzeppelin/contracts/token/ERC721/ERC721.sol<br>@openzeppelin/contracts/token/ERC721/extensions/ERC721Enumerable.sol<br>@openzeppelin/contracts/utils/Multicall.sol
Totals10102250

Files out of scope

Scoping Q & A

General questions

QuestionAnswer
ERC20 used by the protocolAny (all possible ERC20s)
Test coverageThe contest is subject to test coverage invitational competition
ERC721 used by the protocolNonFungiblePositionManager
ERC777 used by the protocolNone
ERC1155 used by the protocolNone
Chains the protocol will be deployed onArbitrum, Avax, Polygon, OtherArbitrum, Avalanche, Linea, Scroll, Fraxtal, Polygon, Mantle, and possibly other EVM compatible chains in the future.

ERC20 token behaviors in scope

External integrations (e.g., Uniswap) behavior in scope:

QuestionAnswer
Enabling/disabling fees (e.g. Blur disables/enables fees)No
Pausability (e.g. Uniswap pool gets paused)No
Upgradeability (e.g. Uniswap gets upgraded)No

EIP compliance

None

Additional context

Main invariants

  • Users cannot withdraw liquidity from someone else's position unless explicitly given approval on-chain.
  • Gauges should never be "bricked" or revert on claiming protocol emissions if they have emissions from being voted on.
  • Only restricted roles can modify swap fee splits and dynamic fees between LPers and voters.
  • Positions minted via NFPs should not be fundamentally different in how they operate as liquidity to direct pool mints (no NFP).

Attack ideas (where to focus for bugs)

  • Finding cases where the math is irregular or returns improper results. Namely ensuring pool integrity and safety of user deposits.
  • Secondly, reward accounting being accurate and not substantially inflated or deflated from reality are crucial.

All trusted roles in the protocol

  • OZ AccessManager is used where necessary, limiting some functionality to the system "governor" who initially is a multisig of core contributors/stakeholders, but intend on moving all controls to a decentralized governance model over time.

Describe any novel or unique curve logic or mathematical models implemented in the contracts:

  • We use novel math in our position/rewards accounting system. These lay on top of the UniswapV3 pool code and are adapted within the core libraries.

Running tests

git clone --recurse https://github.com/code-423n4/2024-10-ramses-exchange.git
cd 2024-10-ramses-exchange
npx hardhat compile
npx hardhat test

To run uniswapV3CoreTests gas profiling;

npx hardhat test test/uniswapV3CoreTests/UniswapV3Pool.gas.spec.ts

Miscellaneous

Employees of Ramses Exchange 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.