Risk model

Overview

Lending on Atomic is non-custodial. Your deposit sits in a smart contract per asset, not in a company's hands. The risks that remain are the usual DeFi risks, made specific to this protocol's design.

Smart contract risk

A vulnerability in any of the lending pools, the trading engine, or any dependency could affect deposits. This is the residual risk every DeFi product carries. You can reduce it; you can't eliminate it.

How Atomic reduces it

• Audits. Atomic contracts have been audited by Halborn and live in production since 2022.
• Bug bounty. Continuous program covering smart contracts, the trading engine and the lending pools. See Bug bounty.
• Track record. Live since 2022 with 99%+ uptime and no critical security incidents.
• Small attack surface. No oracle dependency (oracle attacks are a major perp-DEX vector). No admin keys with arbitrary upgrade power. No external bridges in the trading path.

What it doesn't cover

A new vulnerability found after audit, or one in a dependency (Uniswap V3, KyberSwap, 0x routers), could still affect the protocol. Size your deposit with that in mind.

Liquidity risk

Each pool deploys its capital to back leveraged positions that need that specific asset. When most of a pool's capital is out on loan, withdrawals from that pool can't settle immediately - they wait until trader positions close and the capital returns.

In practice

• Normal day. Utilisation on most pools is moderate. Withdrawals settle in the same block.
• High-volume day. Utilisation on the actively-traded pools spikes above ~85%. Large withdrawals from those pools queue; small ones still go through.
• Stress event. Utilisation at 100% on a given pool. Withdrawals from that pool wait until traders close. Average position lifetime on Atomic is short, so even peak-utilisation queues clear in minutes to hours rather than days.

There's no lockup. The queue is purely a function of borrower-pool dynamics, not a contractual hold. Each pool queues independently - a tight USDC.e pool doesn't slow down withdrawals from the WBTC pool.

Why this isn't solvency risk

A fully-deployed pool isn't an insolvent pool. The 88% liquidation threshold makes sure borrowed capital is recoverable from any underwater position long before it could damage the pool. Liquidity risk is about when you get your money back, not whether.

The threshold mechanics live in Liquidations.

Asset-price risk

Yield on a pool is paid in the same asset you deposited. Your USD-denominated PnL is the yield plus the asset's price move while you held it.

• USDC.e pool. Yield is paid in USDC.e. Negligible price exposure on the principal.
• WETH and WBTC pools. Yield is paid in WETH or WBTC. Principal moves with ETH or BTC.
• ARB, GMX, LINK, UNI pools. Yield is paid in the same token. Principal carries the full price exposure of that asset.

A high APY on a longer-tail pool doesn't compensate for a 40% drop in the underlying token. Match the pool to your existing exposure.

What's not in the risk model

A few risks that show up on other perp-DEX pages but don't apply here:

• Oracle manipulation. Atomic doesn't use external oracles. Marks come from on-chain DEX liquidity. See Oracle design.
• Bad-debt socialisation. Trader losses can't exceed their margin (the 88% rule, plus the 12% buffer). Lenders don't absorb trader PnL.
• Token emission risk. Lender yield is paid in the asset you deposited, not in a separate protocol token whose price could collapse.

Sizing a deposit

A reasonable rule of thumb:

1. Treat the deposit as DeFi-risk capital - money you can afford to lose to a smart contract event.
2. Look at the specific pool's utilisation before depositing real size. Depositing at 95%+ utilisation earns the highest APY but withdrawals from that pool will be slowest.
3. Set realistic expectations on the exit: same-block when the pool has idle capital, minutes to hours during sustained high utilisation.
4. On non-stable pools, treat the deposit as a position in the underlying asset, not as a pure yield play.