> For the complete documentation index, see [llms.txt](https://docs.arenas.fi/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.arenas.fi/atomica/atomica-protocol.md).

# Atomica Protocol

Arenas Financing Markets run on top of the **Atomica Protocol** — the credit engine that powers every market. Atomica defines the on-chain building blocks (markets, pools, obligations and roles) and the standard lifecycle a financing goes through, from request to repayment. You don’t interact with Atomica directly; you use an Arenas market, and Atomica enforces the rules underneath.<br>

***

### What Atomica is

Atomica is a **configurable, credit-based financing engine**. Instead of the overcollateralized, auto-liquidating model of typical money markets, Atomica implements **approval-gated, undercollateralized credit**: liquidity providers fund pools, borrowers request financing, a permissioned approver signs off, and repayment is governed by an off-chain legal agreement rather than a collateral ratio.

Every Arenas market is an Atomica market configured for a specific real-world program (for example `Brazil – Coffee – USDC`). All markets share the same engine, so they behave consistently and stay within the same protocol-level limits.

***

### Core building blocks

| Component                         | What it is                                                                                                                                                              |
| --------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **FinancingMarket**               | The market contract. Holds the borrower request/approval/draw-down/repayment logic and routes funds to and from pools.                                                  |
| **FinancingMarketAdapter (pool)** | The liquidity pool (pool-v2). LPs deposit the asset token and receive pool shares; the adapter supplies capital to the market when a financing is drawn down.           |
| **Access-token NFT**              | A borrower’s eligibility credential in a market. Owning the access token is what lets an address create requests and draw down — there is no ERC-20 collateral to post. |
| **Obligations**                   | On-chain accounting of what a borrower owes: principal, interest, and other obligations, tracked per financing.                                                         |

***

### The financing lifecycle

A financing moves through a fixed sequence of on-chain steps. Each step maps to a role and a market-contract call:

1. **Request** — the borrower calls `requestFinancing` (interest accrues over time) or `requestFixedFinancing` (a fixed repayment amount). Requests can be revised (`modifyRequest`) or withdrawn (`closeRequest`). No token approval is needed — eligibility is the access-token NFT.
2. **Review** — an **Approver** reviews the pending request and either `approveRequest` (optionally for a **partial** amount) or `declineRequest`. Approval does **not** move any funds.
3. **Draw down** — the borrower calls `receiveFinancing` to disburse an approved request. Liquidity is sourced from one or more pools by passing **lender intents** (packed `address+id` tranches) **sorted by rate ascending**, so the cheapest capital fills first. The recipient address can differ from the borrower’s wallet. Fills can be partial if pool capacity is short.
4. **Repay** — anyone (not only the borrower) can repay at any time: `repay` for a full payoff, or the fine-grained `payInterest` / `repayPrincipal` / `payOtherObligations`. Loans are effectively open-ended; repayment is enforced by the signed agreement, not by an on-chain health factor.

There is **no collateral-based liquidation**. A non-performing obligation can instead be sold on a secondary market at a discount, with the recovered amount refunded directly to the affected pool’s LPs.

***

### The liquidity side (LPs)

Liquidity providers interact with the **pool adapter**, not the borrower flow:

* **Deposit** — approve the asset token and `deposit` into the pool to receive pool shares that accrue interest as borrowers repay.
* **Withdraw** — withdrawals are a **two-step, delayed** process: `createWithdrawRequest`, then `executeWithdrawRequest` after the pool’s `withdrawDelay`. If liquidity is locked in active obligations, a request may be fulfilled proportionally.

***

### Roles

* **Market Operator** — configures the market within protocol limits and (absent a separate approver) reviews requests; earns a share of interest as a market fee.
* **Approver** — the permissioned role that approves or declines financing requests.
* **Liquidity Provider (LP)** — supplies capital to pools and earns interest and incentives.
* **Borrower** — holds the access token, creates requests, draws down, and repays.
* **Curator** — arranges liquidity and pool relationships for a market.

***

### What the protocol guarantees

Whatever a specific market configures, Atomica ensures that:

* All markets follow the same **request → approve → draw down → repay** lifecycle.
* Fees and permissions stay within predefined protocol **limits**.
* Liquidity, disbursement and repayment use the same **standardized engine and accounting**.
* Only allowlisted addresses can deploy new markets on a product.

***

### Supported networks

Atomica markets are deployed on the following networks (see **Deployed Contracts** for addresses):

| Network      | Chain ID | Type    |
| ------------ | -------- | ------- |
| Base         | 8453     | Mainnet |
| Arbitrum One | 42161    | Mainnet |
| Boba Network | 288      | Mainnet |
| Base Sepolia | 84532    | Testnet |
| Sepolia      | 11155111 | Testnet |