Bug bounty

Overview

Atomic runs an open bug bounty for security researchers. The program covers every part of the protocol that could materially affect user funds, and reward bands scale with the demonstrated impact of the finding.

Scope

In scope:

• Smart contracts - AtomicTrading, AtomicLendingPool, AtomicPositionRegistry, AggregatorRouter. Both V2 (live) and V3 (testnet, mainnet on launch).
• Trading engine - order panel logic, slippage computation, liquidation triggering, TP/SL execution.
• Lending pool - deposit/withdraw flows, queue logic, yield accounting.
• Frontend at app.atomic.green - XSS, CSRF, supply chain, secrets in build output.

Out of scope:

• Third-party dependencies (Uniswap V3 contracts, KyberSwap router, 0x router) - report those to the respective teams.
• Social engineering against team members or other users.
• Anything requiring physical access to a user's device.
• DoS / rate-limit issues against api.atomic.green (covered separately by infrastructure hardening).
• Findings that require already-compromised user keys.

Severity tiers

| Tier | What qualifies | |---|---| | Critical | Loss of user funds. Unauthorized access to lending pool capital. Bypassing the liquidation threshold to drain positions. | | High | Forced incorrect liquidation. Significant fee miscalculation. Material protocol malfunction without direct fund loss. | | Medium | Restricted-impact issues without direct fund loss - e.g. incorrect yield accounting that self-corrects, edge-case revert paths. | | Low | Minor defects, frontend bugs without security impact, code-quality issues with no exploit path. |

Reward bands per tier are calibrated to industry norms for a protocol of Atomic's TVL and are published in full ahead of V3 launch. Critical findings are paid in USDC.e, in the same week the patch ships.

Reporting guidelines

A good report includes:

1. Affected component - contract, function, or page.
2. Detailed description - what the bug is, why it matters.
3. Reproduction - steps, transactions, or PoC code that demonstrates the issue.
4. Impact - what an attacker could do with this finding.
5. Suggested fix if you have one (not required).

Reports without reproduction or with vague impact claims are deprioritized - not because the team doesn't care, but because they often turn out to be already-known or non-issues.

Triage timeline

• 48 hours - initial response and severity classification.
• 7 days - patch designed and tested for Critical/High, longer for Medium/Low.
• 30 days - patch deployed (longer for changes requiring re-audit).

Researchers are kept in the loop throughout. Public disclosure timing is coordinated - typically after the patch is live and adopted.

Safe-harbour terms

Researchers acting in good faith under this program are explicitly allowed to:

• Test against the protocol on testnet without restriction.
• Test against mainnet at small scale, provided no other users are harmed.
• Hold positions purely to demonstrate a finding (close them after, don't extract value beyond what's necessary to prove the issue).

Atomic will not pursue legal action or chain-analysis against good-faith researchers. The line between "researcher" and "attacker" is drawn by intent and disclosure timing - disclose to the team, don't extract funds, and you are safe.

Hall of fame

Researchers whose reports led to deployed patches are credited (with their permission) on a hall-of-fame page published alongside the patch. If you prefer to remain anonymous, that's also fine - say so in your report.

Contact

• Email: info@atomic.green
• Discord: Atomic official server, DM a core contributor (roles visible in member list)
• PGP: published in the repo for encrypted reports