Overview
Atomic's on-chain footprint is small by design. Three core contracts plus a thin router layer cover everything. All contracts are verified on Arbiscan; addresses are listed on Contract addresses.
V2 is live on Arbitrum since 2022 (audited by Halborn). V3 is in final development with a Halborn audit scheduled for Q2 2026 ahead of public launch. The architecture below describes V3.
Core contracts
AtomicTrading
The trading contract. External interface for opening, closing, and managing positions. Holds no user funds at rest - it is purely an execution layer that orchestrates between the wallet, the lending pool, and the aggregator.
Key external functions:
openPosition(market, side, margin, leverage, maxSlippage)- opens a new leveraged position.closePosition(positionId)- closes a live position.setStopLoss(positionId, price)/setTakeProfit(positionId, price)- update conditional close triggers.liquidate(positionId)- keeper-only entry point; closes a position that has hit its liquidation threshold.
AtomicLendingPool
The single USDC.e pool. Custodian of all lender deposits, lender of last resort to the trading contract, and accountant for accrued yield.
Key external functions:
deposit(amount)- supplier deposit, mints internal accounting balance.withdraw(amount)- supplier withdrawal, subject to available idle capital.borrow(amount)/repay(amount)- restricted to the trading contract; cannot be called by external users.
The pool maintains a strict invariant: total borrowed ≤ total supplied. Every borrow is tied to a live position whose liquidation threshold guarantees repayment.
AtomicPositionRegistry
Canonical state of every open position. Read-only for everything except the trading and liquidation paths.
Stores per position: trader, market, side, margin, leverage, entry price, borrowed amount, liquidation price, TP/SL targets, and timestamps.
Keepers and frontends read this registry to surface live positions and identify candidates for liquidation.
Router layer
A thin contract layer that translates between Atomic's internal interface and the aggregators it calls:
AggregatorRouter- receives swap parameters fromAtomicTrading, calls KyberSwap or 0x via their respective routers, returns settlement.
This layer exists so that adding or replacing an aggregator does not require touching the core trading contract. KyberSwap and 0x are both wired in V3; new aggregators can be added without protocol upgrade.
What is and isn't upgradeable
| Contract | Upgradeable? |
|---|---|
| AtomicTrading | No - immutable after deployment |
| AtomicLendingPool | No - immutable after deployment |
| AtomicPositionRegistry | No - immutable after deployment |
| AggregatorRouter | Yes - can be redeployed and pointed to by the trading contract config |
| Per-market parameters (max leverage, min margin, etc.) | Yes - by protocol admin, no impact on existing positions |
Upgrading AggregatorRouter requires deploying a new version and migrating; it does not affect open positions because position state lives in the registry, not the router.
When a market's max leverage is reduced, existing positions at the old leverage continue to operate at their entry parameters. The lower limit applies only to new positions opened after the change.
Source code
All contracts are verified on Arbiscan. Source is open and reproducible from the verified bytecode.
Verified addresses, ABIs, and subgraph endpoints: Developers → Contract addresses.
Audits
V2 contracts: audited by Halborn. V3 audit: scheduled with Halborn for Q2 2026, full report published on completion. See Security → Audits.
Bug bounty
Smart contracts are in scope of the continuous bug bounty. Critical/High/Medium/Low severity tiers; contact via Discord or info@atomic.green. See Bug bounty.