Architecture

Overview

The design is built around one property: the trade is the settlement. Every leveraged position is a real on-chain swap with real liquidity behind it. There's no synthetic balance sitting in a protocol vault.

Three contracts and a couple of off-chain helpers carry the whole system.

On-chain components

Trading contract

The entry point for every position. When you open one, it:

1. Pulls margin USDC.e from your wallet.
2. Borrows the leveraged portion from the lending pool.
3. Calls the aggregator router to swap into the target asset.
4. Writes the position to the registry.

Closing reverses each step in a single transaction.

Lending pool

Holds depositor USDC.e and lends it to the trading contract on demand. Tracks per-depositor balances, accrues yield from the fee streams, and enforces the withdrawal queue when utilisation is high.

The pool's solvency invariant: every dollar of borrowed capital is backed by an open position whose liquidation threshold guarantees recovery. See Risk model.

Position registry

Stores the state of every open position - trader, market, side, margin, leverage, entry price, borrowed amount, liquidation threshold. The registry is what keepers watch, and what the close flow reads.

Off-chain components

DEX aggregators

KyberSwap and 0x handle the actual routing. Swaps end up filled across whatever Arbitrum DEXes have the best price at that moment - Uniswap V3, Camelot, Curve and anything else the aggregators reach. Atomic doesn't run its own order book; the aggregator handles best execution.

The frontend queries both aggregators and picks the better quote per trade. Both are wired up for redundancy: if one is down or returns a worse price, the other takes the trade.

Keeper network

Independent operators watching the position registry against on-chain prices, ready to call liquidate() when the 88% threshold is crossed. Keepers compete for the bounty paid on each liquidation.

The bounty mechanics and operator setup are in Keeper network.

Data flow on a position open

User wallet
 │ approve USDC.e (one-time)
 │ sign open transaction
 ▼
Trading contract
 ├─ pull margin USDC.e
 ├─ borrow notional from Lending pool
 ├─ call aggregator router (KyberSwap or 0x)
 │     └─ swap routed across Uniswap V3 / Curve / etc.
 ├─ write position state to Position registry
 └─ emit OpenPosition event
 ▼
Block sealed → position is live

Closing reverses the diagram in one transaction. A liquidation is the same flow, started by a keeper instead of the position owner.

What's deliberately not here

A few patterns common to other perpetual DEXes that Atomic doesn't use:

• A price oracle. Marks come from on-chain DEX liquidity. Removes a major attack surface - oracle manipulation, oracle pause. See Oracle design.
• A vault holding margin. Margin stays in your wallet until the transaction executes. No deposit/withdraw flow, no idle capital parked in the protocol.
• A funding rate. Positions are real swaps, not perpetual contracts referenced to a synthetic mark.
• Admin upgrades with arbitrary powers. Critical contracts are immutable. Operational changes go through the standard deployment process and don't touch existing positions.

Composability

The contracts emit standard events on every state change: OpenPosition, ClosePosition, LiquidatePosition, Deposit, Withdraw. Anyone can subscribe to those events to build dashboards, automated strategies or risk monitors. The indexed schema lives in Subgraph.

The trading contract exposes a clean external interface for opens and closes. The SDK wraps it for the common cases.