Risk model

Overview

Lending on Atomic is non-custodial - your USDC.e is in a smart contract, not in a company's hands. The risks that remain are the standard DeFi risks made specific to this protocol's architecture.

Smart contract risk

A vulnerability in the lending pool contract, the trading engine, or any dependency could affect deposits. This is the residual risk every DeFi product carries; it cannot be eliminated, only reduced.

How Atomic reduces it

• Audits. V2 contracts audited by Halborn (live since 2022). V3 - the version going forward - has a full Halborn audit scheduled for Q2 2026 before public launch.
• Bug bounty. Continuous program covering smart contracts, trading engine, and lending pool. Critical/High/Medium/Low severity tiers, contact via Discord or info@atomic.green. See Bug bounty.
• Production track record. Live since 2022 with 99%+ uptime and zero critical security incidents to date.
• Minimal surface area. No oracle dependency (oracle attacks are a major perpetual-DEX vector), no admin keys with arbitrary upgrade power, no external bridges in the trading path.

What it does not protect

A novel vulnerability discovered after audit, or in dependencies (Uniswap V3, KyberSwap, 0x routers), could still affect the protocol. Size your deposit accordingly.

Liquidity risk

The lending pool deploys capital to back active leveraged positions. When most of the pool's capital is lent out, withdrawals cannot settle immediately - they wait until trader positions close and capital returns to the pool.

What this looks like in practice

• Normal day: Pool utilization is moderate. Withdrawals settle in the same block, just like a regular USDC.e transfer.
• High-volume day: Utilization spikes above ~85%. New large withdrawals queue; small ones still go through.
• Stress event: Utilization at 100%. Withdrawals wait until traders close (which they generally do quickly, since they pay funding-equivalent fees on every round trip). Typical wait is minutes to hours, not days.

There is no lockup by design - the queue is purely a function of borrower-pool dynamics, not a contractual hold.

Why it does not become solvency risk

The pool can be temporarily fully deployed without becoming insolvent. The 88% liquidation threshold guarantees that borrowed capital is recoverable from any underwater position before it could damage the pool. Liquidity risk is about when you get your money back, not whether.

See Trading → Liquidations for the threshold mechanics.

What is not in the risk model

A few things that often appear on perpetual-DEX risk pages - and explicitly do not apply here:

• Oracle manipulation. Atomic does not use external price oracles. Marks come from on-chain DEX liquidity directly. See Protocol → Oracle design.
• Bad-debt socialization. Trader losses cannot exceed their margin (the 88% rule, plus the 12% buffer). Lenders do not absorb trader PnL - only smart contract or routing failures could.
• Token emission risk. Lender yield is paid in USDC.e from real trading fees, not in a protocol token whose price could collapse. There is no token to depreciate.

Sizing a deposit

A reasonable approach for a sized risk:

1. Treat the deposit as DeFi-risk capital - money you can afford to lose to a smart contract event.
2. Watch pool utilization on the lending dashboard before depositing large size; deposits at 95%+ utilization will earn high APY but withdrawals will be the slowest.
3. Keep withdrawal expectations realistic: same-block in normal conditions, minutes-to-hours during sustained high utilization.