Security Overview

Best Practices 🔐

We strongly recommend following security best practices when interacting with Rubicon:

• Use a hardware wallet or multi-signature wallet for significant positions
• Always clear-sign your transactions and verify the contract addresses
• Follow proper wallet security hygiene

Security Hub

• Audits - public audit contests and reports covering Rubicon smart contracts.
• Bug Bounty - responsible disclosure guidance and bounty context.
• Risks - protocol and DeFi risk disclaimer.
• Deployments - canonical contract address reference.

Protocol Security Architecture 🏗️

Rubicon's security is built around a multi-layer liquidity stack. Each component undergoes testing, verification, and review appropriate to its role in the protocol.

Rubicon CLMM 📈

Rubicon CLMM is a fork of Uniswap V3, with contracts verified onchain for public review.

Audits

Please review current security audits on the Audits Page.

Expected Interactions

When using CLMM, you should expect:

1. Initial token approvals: Approve the relevant position manager or router contract to spend your tokens
2. Liquidity management: Mint, increase, decrease, or collect fees from range-based LP positions
3. Swap execution: Direct wallet transactions through CLMM routing contracts

Addresses

See our CLMM Deployments page.

Rubicon Gladius ⚔️

Our next-generation intent-based trading system. Built as a derivative fork of Uniswap X with extended functionality for partial fill limit orders.

Audits

Please review current security audits on the Audits Page.

Expected Interactions

Gladius uses a signature-based intent trading system:

1. Initial Setup

   • One-time approval of the Permit2 (opens in a new tab) contract (a widely-used, shared contract across DeFi)
   • No other contract approvals needed
   • Note: Native ETH is not supported as an input - users must wrap to WETH first (hence "Wrap and Swap" or "Wrap and Trade" UI prompts)

2. Trading Flow

   • Each trade is a gasless signature (intent to trade)
   • Signatures include time duration and slippage parameters
   • Orders typically execute via dutch auction pricing or limit orders
   • Your order is either filled within your specified terms or nothing happens

3. Execution Process

   • Signatures are broadcast to the filler network
   • First executor to include your order in a block executes the trade
   • Executors can be market makers, bots, or other traders
   • Partial fills are possible for limit orders optionally

Addresses

See our Gladius Deployments page.

Rubicon Classic 📚

Our fully on-chain order book system for peer-to-peer trading, live on Optimism since 2021 with continuous auditing and iteration in production.

Audits

Please review current security audits on the Audits Page.

Expected Interactions

When using Classic, you should expect:

1. Initial token approvals: Approve the Market or Router contract to spend your tokens (not needed for native ETH inputs)
2. Transaction execution: Direct wallet transaction for order placement/execution

Addresses

See our Classic Deployments page.

Aquila AMM 🌊

Aquila is our automated market maker system, a direct fork of Uniswap V2. We've made minimal, namesake-only changes to this battle-tested AMM codebase.

Audits

While Aquila itself is currently unaudited, it is a direct fork of the extensively audited Uniswap V2 protocol. All contracts are verified on-chain and open source.

Expected Interactions

When using Aquila, you should expect:

1. Initial token approvals: You'll need to approve the Router or Pair contracts to spend your tokens (not needed for native ETH inputs)
2. Transaction execution: After approval, a direct wallet transaction for the swap/add/remove liquidity

Addresses

All contracts are verified and open source. See our Aquila Deployments page.

HFT Vaults 🧭

HFT Vaults are Rubicon's Gamma Strategies V1 Hypervisor fork for managed CLMM liquidity. They package paired deposits into vault shares while a trusted market maker manages active ranges.

Audits

Please review current security audits on the Audits Page. Users should treat automated liquidity vaults as active DeFi infrastructure with strategy, smart contract, and market risks.

Expected Interactions

When using HFT vaults, you should expect:

1. Initial token approvals: Approve vault contracts to spend deposited assets
2. Vault deposits and withdrawals: Receive or redeem vault shares representing managed CLMM liquidity exposure
3. Strategy risk: Vault performance depends on range management, market conditions, and liquidity execution

Addresses

See our CLMM Deployments page for current related contracts.

Bug Bounty Program 🐛

We actively encourage responsible disclosure of security vulnerabilities and possibly compensate security researchers for their efforts.