Architecture

Overview

Atomic's design optimizes for a single property: the trade is the settlement. Every leveraged position is a real on-chain swap with real liquidity behind it, not a synthetic balance in a protocol vault.

Three contract surfaces and a few off-chain helpers carry the entire system.

On-chain components

Trading contract

The entry point for every position. On open, it:

1. Pulls margin USDC.e from the trader's wallet.
2. Borrows the leveraged portion from the lending pool.
3. Calls the aggregator routing contract to swap into the target asset.
4. Records position state in the position registry.

On close, the same contract 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 utilization is high.

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

Position registry

Stores the state of every open position: trader address, market, side, margin, leverage, entry price, borrowed amount, and liquidation threshold. The registry is the canonical source of truth that keepers monitor and that the closing flow reads.

Off-chain components

DEX aggregators

KyberSwap and 0x route the actual swap across Uniswap V3 (primary), Curve, and other Arbitrum venues. Atomic does not maintain its own order book; the aggregator handles best-execution.

The choice of aggregator per trade is made off-chain by the frontend, which queries both and picks the better quote. Both are integrated for redundancy - if one is down or returns a worse quote, the other takes the trade.

Keeper network

A set of independent operators that watch the position registry against on-chain prices and trigger liquidations when the 88% threshold is hit. Keepers compete for the keeper bounty paid on each liquidation.

See Keeper network for the bounty mechanics and operator requirements.

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 a single transaction. Liquidation is the same flow, initiated by a keeper instead of the position owner.

What's deliberately missing

Several patterns common in perpetual DEXes are absent from Atomic by design:

• No price oracle. Marks come from on-chain DEX liquidity. Removes a major attack surface (oracle manipulation, oracle pause). See Oracle design.
• No vault holding margin. Margin is in the trader's wallet until the moment of execution. No deposit/withdraw flow, no idle capital sitting in the protocol.
• No funding rate mechanism. Positions are real swaps, not perpetual contracts with synthetic prices.
• No admin upgrade pathway with arbitrary powers. Critical contracts are immutable. Operational changes go through the standard deployment process; existing positions are unaffected by new deployments.

Composability

Atomic's contracts emit standard events on every state transition (OpenPosition, ClosePosition, LiquidatePosition, Deposit, Withdraw). Anyone can subscribe to these to build dashboards, automated strategies, or risk monitors - see Developers → Subgraph for the indexed schema.

The trading contract exposes a clean external interface for opening and closing positions; the SDK wraps it for typical use cases.