# Overview

**Arenas** brings real-world financing on-chain: approval-gated, undercollateralized credit markets, backed by off-chain legal agreements rather than posted collateral.

| Layer                              | What it does                                                                                                                |
| ---------------------------------- | --------------------------------------------------------------------------------------------------------------------------- |
| **Financing markets**              | The credit engine — pools, obligations, and the request → approve → draw down → repay lifecycle.                            |
| **Credit Delegation Module (CDM)** | Routes borrowing power from an external liquidity source into Arenas financing pools, for suppliers who want boosted yield. |
| **SomniaLend**                     | An optional, external liquidity source. Not operated by Arenas.                                                             |

***

### How it fits together

```mermaid
flowchart LR
    LP[Supplier] -->|supply collateral| SL[(SomniaLend · external)]
    SL -->|delegated borrowing power| CDM[Credit Delegation Module]
    CDM -->|supply borrowed liquidity| Markets[(Arenas markets · Somnia)]
    Markets -->|financing| Borrowers[Borrowers]
    Markets -->|yield| LP
```

* **Borrowers** get approval-gated credit from an [**Arenas market**](/key-concepts) — no on-chain collateral.
* **Suppliers / LPs** earn yield by [supplying to a pool](/financing-markets/supply) directly, and can amplify it by delegating SomniaLend credit through the [**CDM**](/credit-delegation).

***

### Where to start

* How the pieces fit → [**How Arenas works**](/how-it-works).
* The objects and terms used throughout → [**Key Concepts**](/key-concepts).
* The rules the protocol enforces → [**Arenas Protocol**](/protocol).
* Boosted yield through delegation → [**Credit Delegation Module**](/credit-delegation).
* Publish and discover financing intents → [**Intents**](/intents).

***

### Networks

Arenas operates on **Somnia** (chain `5031`).


# How Arenas works

Arenas runs **financing markets**: credit markets where borrowing is approved by a person, not collateralized by a price feed. This page is the short version of how the parts relate.

***

### The pieces

| Piece          | What it is                                                                                                               |
| -------------- | ------------------------------------------------------------------------------------------------------------------------ |
| **Market**     | One real-world financing program, configured as a contract — who may borrow, on what terms, who approves.                |
| **Pool**       | The liquidity behind a market. Suppliers deposit; borrowers draw from it.                                                |
| **Obligation** | What a borrower owes — principal, interest, and any other charges — tracked on-chain.                                    |
| **Roles**      | Who may approve, borrow, supply and operate a market. See [Roles & Permissions](/roles-and-permissions).                 |
| **CDM**        | The Credit Delegation Module, which lets a supplier route borrowing power from an external liquidity source into a pool. |

***

### What the protocol enforces

Every market, whatever it is configured for, runs the same machinery:

* The shared **request → approve → draw down → repay** lifecycle.
* Fee and permission **limits** that a market cannot exceed.
* One standardized engine for liquidity, disbursement, repayment and accounting.

See [**Key Concepts**](/key-concepts) for the vocabulary and [**Arenas Protocol**](/protocol) for the rules in detail.

***

### What makes it different

Credit is **approval-gated and undercollateralized**. There is no on-chain collateral and no price-based liquidation: a market operator or approver signs off on each request, and repayment is governed by an off-chain legal agreement. If a loan goes unpaid, the obligation can be sold on a secondary market at a discount, with proceeds refunded to the pool's suppliers.

See [Risks](/risks) for what that trade-off means in practice.

***

### Boosted yield

Suppliers can do more than deposit idle capital. The [**CDM**](/credit-delegation) lets a supplier keep collateral on **SomniaLend** — an external liquidity protocol on Somnia — delegate its borrowing power, and route the borrowed liquidity into an Arenas pool to earn the spread.

***

### Where to use it

The app is at [app.arenas.fi](https://app.arenas.fi); the lending experience at [arenas.fi](https://arenas.fi).


# Key Concepts

This page defines the objects and terms used throughout the docs, so the rest of the pages stay short.

***

### The building blocks

| Concept                      | What it is                                                                                                                                                                           |
| ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Financing Market**         | The market contract for one real-world program (e.g. `Brazil – Coffee – USDC`). Holds the request → approve → receive → repay logic and routes funds between borrowers and pools.    |
| **Pool (Financing adapter)** | The liquidity side of a market. LPs deposit the asset token and receive **pool shares**; the pool supplies capital to the market when a borrower draws down.                         |
| **Asset token**              | The single ERC-20 a market uses for both supply and repayment (typically a stablecoin such as USDC).                                                                                 |
| **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.          |
| **Financing request**        | A borrower’s ask: an amount, a minimum acceptable amount, a rate ceiling (or fixed repayment), and a duration. Reviewed before any money moves.                                      |
| **Financing**                | An active loan created once an approved request is drawn down. Tracks obligations until repaid.                                                                                      |
| **Obligations**              | The live on-chain accounting of what a borrower owes on a financing: **principal**, **interest**, and **other obligations**.                                                         |
| **Intent**                   | A standing liquidity offer from a pool — an amount available at a given rate. Draw-downs are filled from intents, cheapest first. See [Intents & Liquidity](/intents-and-liquidity). |

***

### Two kinds of financing

A request is created as one of two types, fixed at request time:

* **Interest-accrual** — interest accrues over time against a borrower-set **rate ceiling** (`maxRate`). Open-ended; repay principal and accrued interest whenever due.
* **Fixed-repayment** — the borrower commits to a single **fixed repayment amount** over a set **duration**, rather than an accruing rate.

***

### The lifecycle at a glance

Every financing follows the same path. The important detail — often misunderstood — is that **approve and receive are two separate steps**:

```mermaid
flowchart LR
    A[REQUESTED] -->|approver authorises amount| B[APPROVED]
    B -->|borrower draws down| C[ACTIVE / FILLED]
    C -->|repay principal + interest| D[Repaid]
    A -->|closeRequest| E[CLOSED]
    B -->|closeRequest| E
```

* The **approver** authorises an amount (possibly partial). This moves **no funds** — it opens a **timed receive window**.
* The **borrower** later **draws the money down themselves** inside that window, with liquidity auto-selected from lender intents.

See [Financing Request Lifecycle](/financing-request-lifecycle) for the full state machine and statuses.

***

### Undercollateralized & approval-gated

Unlike a typical money market, Arenas has **no on-chain collateral and no price-based liquidation**:

* Eligibility is the **access token**, not locked collateral.
* Every draw-down requires an **approver’s** sign-off.
* Repayment is backed by an **off-chain legal agreement**, enforced off-chain.
* A non-performing loan can be **sold on a secondary market** at a discount, with proceeds refunded to the pool’s LPs.

See [Roles & Permissions](/roles-and-permissions) for who can do what, and [Risks](/risks) for how these trade-offs are managed.

***

### Supported networks

| Network | Chain ID | Type    |
| ------- | -------- | ------- |
| Somnia  | 5031     | Mainnet |


# Arenas Protocol

The **Arenas Protocol** is the credit engine behind every financing market. It defines the on-chain building blocks — markets, pools, obligations and roles — and the standard lifecycle a financing goes through, from request to repayment. As a user you work with a market; the protocol enforces the rules underneath it.<br>

***

### What it is

Arenas is a **configurable, credit-based financing engine**. Instead of the overcollateralized, auto-liquidating model of typical money markets, it 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.

Each market is 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, the protocol 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

Arenas markets are deployed on **Somnia**:

| Network | Chain ID | Type    |
| ------- | -------- | ------- |
| Somnia  | 5031     | Mainnet |


# Roles & Permissions

Arenas markets are **permissioned by role**. Each action in a market is gated to a specific party, and no single role can move funds on its own. This page maps every role to what it can and cannot do.

***

### The four roles

| Role                        | Responsible for                | Key actions                                                   |
| --------------------------- | ------------------------------ | ------------------------------------------------------------- |
| **Borrower**                | Requesting and repaying credit | Create / modify / close a request, draw down (receive), repay |
| **Approver**                | Credit decisions               | Approve (full or partial) or decline a request                |
| **Liquidity Provider (LP)** | Funding the market             | Deposit into a pool, request and execute withdrawals          |
| **Curator**                 | Liquidity relationships        | Arrange pools and terms that supply a market                  |

> A **Market Operator** configures the market within protocol limits and, when there is no separate Approver, also performs the review. The Operator earns a share of interest as a **market fee**.

***

### What each role can do

#### Borrower

* Must hold the market’s **access token (NFT)** — this, not collateral, is the eligibility check. The NFT is never transferred by these actions; only ownership is checked.
* Can **create** a request (`REQUESTED`), **modify** it while still `REQUESTED`, or **close** it while `REQUESTED` or `APPROVED`.
* Can **draw down** an approved request during its receive window. Funds can be sent to a **recipient address that differs** from the borrower’s wallet.
* Cannot self-approve. Cannot draw down more than the approved amount.

#### Approver

* Reviews pending requests and either **approves** — optionally for a **partial** amount — or **declines**.
* Approval **authorises an amount and opens a timed receive window**; it does **not** transfer funds.
* Is a distinct address from the borrower; a borrower can never approve their own request.

#### Liquidity Provider (LP)

* **Deposits** the asset token into a pool and receives **pool shares** that accrue value as borrowers repay.
* **Withdraws** via a two-step, delayed flow (request → wait → execute). See [Withdraw](/financing-markets/withdraw).
* Bears the market’s credit risk: LP share value can fall if borrowers default.

#### Curator

* Arranges the **pools and liquidity terms** that fund a market, and the intents that make capital available to borrowers.
* Works with the Market Operator on pool configuration and incentives.

***

### Separation of powers

The security of a market comes from splitting authority across roles:

```mermaid
flowchart LR
    B[Borrower] -->|requests| M[(Financing Market)]
    A[Approver] -->|authorises amount| M
    B -->|draws down within window| M
    L[LP / Pool] -->|supplies liquidity via intents| M
    M -->|disburses to recipient| R[Recipient]
```

* The **borrower** asks, but cannot authorise.
* The **approver** authorises, but does not move or hold funds.
* The **LP / pool** funds, but does not decide who borrows.
* The **market contract** enforces that all three line up before a single token is disbursed.

***

### Permission notes

* **Access-token gating:** only the access-token owner (or an address on the request’s trigger list) may request or receive.
* **Partial approvals:** the approved amount always stays within the borrower’s requested `[minAmount, amount]` band.
* **Receive window:** the window is snapshotted at approval time and stays fixed even if market configuration changes afterward.

See [Financing Request Lifecycle](/financing-request-lifecycle) for how these permissions play out step by step.


# Financing Request Lifecycle

A financing is not a single transaction — it moves through a **state machine**, and each transition is performed by a different role. The step most people miss is that **approval and draw-down are separate**: an approver authorises an amount, and the borrower later draws it down themselves.

***

### The states

```mermaid
stateDiagram-v2
    [*] --> REQUESTED: borrower creates request
    REQUESTED --> REQUESTED: modifyRequest
    REQUESTED --> APPROVED: approver authorises (full or partial)
    REQUESTED --> CLOSED: closeRequest / declined
    APPROVED --> ACTIVE: borrower draws down (receive)
    APPROVED --> CLOSED: closeRequest
    ACTIVE --> Repaid: repay principal + interest
    Repaid --> [*]
```

| State         | Meaning                                                                              | Who moves it next      |
| ------------- | ------------------------------------------------------------------------------------ | ---------------------- |
| **REQUESTED** | Request created, awaiting review. Can still be edited or cancelled.                  | Approver (or borrower) |
| **APPROVED**  | An amount is authorised and a **timed receive window** is open. No funds have moved. | Borrower               |
| **ACTIVE**    | Financing drawn down; obligations accrue until repaid.                               | Borrower (repay)       |
| **CLOSED**    | Request cancelled or declined before draw-down.                                      | —                      |

***

### Step 1 — Request

The borrower creates a request against a market, choosing:

* **Amount** and **minimum amount** — the acceptable fill band `[minAmount, amount]`.
* **Type** — interest-accrual (with a **rate ceiling**) or fixed-repayment (a **fixed repay amount** over a **duration**).
* **Recipient** — where funds should land (defaults to the access-token owner).

No token approval is needed; eligibility is the **access token (NFT)**. While in `REQUESTED`, the borrower may `modifyRequest` or `closeRequest`.

***

### Step 2 — Review (approve ≠ fund)

An **Approver** reviews the request and either:

* **Approves** it — optionally for a **partial** amount within the requested band — which **opens a receive window** (an earliest and latest time to draw down), or
* **Declines** it.

> **Approval moves no money.** It authorises an amount and starts a clock. This is the key difference from collateral-based lending, where borrowing is instantaneous.

The receive window is **snapshotted at approval** and does not change even if the market is reconfigured later.

***

### Step 3 — Draw down (receive)

Inside the receive window, the **borrower** draws the money down. Liquidity is sourced from the pool’s **lender intents**, selected automatically **cheapest-rate-first** — the borrower does not hand-pick lenders in the standard flow. See [Intents & Liquidity](/intents-and-liquidity).

A draw-down can **partially fill** if pool capacity is short, and the borrower can draw again (up to the approved amount) while the window is open. Because on-chain capacity can change between approval and draw-down, a fill is only final once the transaction settles. Possible outcomes:

| Outcome              | Meaning                                                             |
| -------------------- | ------------------------------------------------------------------- |
| **Success**          | Financing becomes `ACTIVE`.                                         |
| **Lack of capacity** | Not enough lender liquidity available right now.                    |
| **Rate exceeded**    | The only available liquidity is priced above the request’s ceiling. |
| **Below minimum**    | The achievable fill is under the request’s `minAmount`.             |

***

### Step 4 — Repay

Once `ACTIVE`, **anyone** (not only the borrower) can repay — in full or in part — at any time. Repayment is enforced by the **off-chain agreement**, not by an on-chain health factor, so there is no price-based liquidation. See [Repay](/financing-markets/repay).

If a loan is not repaid, the obligation can be **sold on a secondary market** at a discount, with proceeds refunded to the affected pool’s LPs.


# Financing Markets

Financing Markets are **credit markets** configured for specific real-world financing programs and **governed by a Market Operator**.\
Each market has its own liquidity, interest model and borrowers set, but all of them run on the same financing products described on the [Arenas Protocol](/protocol) page.

***

### What is a Financing Market?

A Financing market is a dedicated financing pool for a specific use case, for example:

> `Brazil – Coffee – USDC`

A market can define:

* **Seniority of tranches repayment** (whether it is a higher risk (junior pool - higher interest and later repayments), or a lower risk (senior pool - lower interest and earlier repayments),
* **What is being financed** (sector / type of good (service) / program),
* **Which base asset is used** for deposits and obligations (capital token - i.e. USDC),
* **How interest is priced** for borrowers,
* **Who is** **allowed to borrow** in that market.
* **What is being financed** (sector / geography / program),
* **Which collateral is used** for deposits and loans (capital token)

Under the hood, the market is a configurable smart contract that follows the rules of the underlying financing product.

***

### Roles in a Financing Market

* **Market Operator**
  * Sets up the market parameters within product limits.
  * Approves or rejects **financing requests**.
  * Earns a share of interest as a **market fee**.
* **Liquidity Providers (Lenders)**
  * Supply the capital token to the market and receive **LP tokens**.
  * Earn interest (and possible incentives) from funded obligations
  * Are subject to the market’s **liquidity and withdrawal rules**.
* **Borrowers**
  * Create a **financing application** (borrower specific NFT) on a particular financing market.
  * Submit **financing requests** with desired obligation amount. Requests are based on a specific financing application and linked to it.
  * Sign a **real-world** contract (financing agreement) for that market’s program.
  * Receive funds only after **Market Operator** (or **Approver**) **approval** and sufficient liquidity in market pools. It can be a partial approval of the requested amount, and it can be borrowed a part of the approved amount up to available liquidity and other financing request parameters/ limitations.

Financing Markets are therefore the place where Arenas connects on-chain liquidity with **off-chain**, **program-specific** **financing terms**/ **agreements**.


# Supply

Deposit the asset token into a Financing Market pool and earn yield as borrowers repay.

Supplying is how **Liquidity Providers** fund a Financing Market. You deposit the market’s asset token (e.g. USDC) into a **pool** and receive **pool shares** that grow in value as borrowers pay interest back into the pool.

***

### How it works

1. **Approve** the asset token for the pool’s financing adapter.
2. **Deposit** the asset into the pool. Your deposit becomes available to borrowers as **intents** (see [Intents & Liquidity](/intents-and-liquidity)).
3. The pool **mints pool shares** to you, representing your claim on the pool’s assets plus accrued yield.

```mermaid
sequenceDiagram
    participant LP as Liquidity Provider
    participant Adapter as Financing adapter (pool)
    participant Pool as Financing pool

    LP ->> Adapter: 1. Approve asset token
    LP ->> Adapter: 2. Deposit assets (ERC-20)
    Adapter -->> Pool: 3. Supply liquidity (becomes intents)
    Pool -->> LP: 4. Mint pool shares
```

***

### What you earn

Your pool shares accrue value from:

* **Interest** borrowers pay on active financings.
* Optional **upfront incentives** borrowers pay to attract capital.
* Optional **reward programs** funded by the market or third parties.

There is no fixed APY — returns track the actual performance of the market’s loans.

***

### Things to know

* **Capacity caps.** A pool may have a deposit **cap**; when reached, deposits are paused until capacity frees up. `cap = 0` means unlimited.
* **Pool phases.** Some pools only accept deposits in certain phases (e.g. an accumulation window). Deposits revert when the current phase disallows them.
* **Credit risk.** Pool share value can fall if borrowers default — supplying is not risk-free. See [Risks](/risks).
* **Withdrawals are delayed.** Redeeming is a two-step, time-locked process — see [Withdraw](/financing-markets/withdraw).


# Withdraw

Redeem your pool shares for the underlying asset plus accrued yield, via a two-step delayed withdrawal.

Withdrawing converts your **pool shares** back into the underlying asset, including accrued yield. Unlike supplying, withdrawing is always a **two-step, time-locked** process — even when the delay is set to zero.

***

### The two steps

```mermaid
sequenceDiagram
    participant LP as Liquidity Provider
    participant Adapter as Financing adapter (pool)

    LP ->> Adapter: 1. createWithdrawRequest (locks shares)
    Note over LP,Adapter: wait for withdrawDelay
    LP ->> Adapter: 2. executeWithdrawRequest (after delay)
    Adapter -->> LP: 3. Return assets + accrued yield
```

1. **Create a withdrawal request.** This locks the shares you want to redeem. There is **one active request per LP**, and it **cannot be cancelled** once created.
2. **Execute the request** after the pool’s `withdrawDelay` has elapsed. The same wallet that created the request must execute it, and receives the assets.

***

### Why the delay

The delay lets the pool manage liquidity that is temporarily locked in active financings. If much of the pool is lent out, a request may be:

* **Fulfilled proportionally** — you receive the redeemable share now, with the remainder following as loans are repaid, or
* **Delayed** until enough borrowers repay.

The protocol always returns either assets or shares; it does not freeze your funds without a claim.

***

### Things to know

* **One-way lock.** `createWithdrawRequest` locks your shares immediately and cannot be reversed — plan the amount before submitting.
* **Same wallet executes.** Only the wallet that created the request can execute it, after the delay.
* **Availability.** Withdrawals are subject to unborrowed liquidity in the pool at execution time.

See [Supply](/financing-markets/supply) for the deposit side and [Intents & Liquidity](/intents-and-liquidity) for how your capital is put to work in between.


# Borrow

Request approval-gated, undercollateralized credit from a Financing Market — request, get approved, then draw down yourself.

Borrowing on Arenas gives you access to liquidity **without posting on-chain collateral**. Instead of an instant, collateral-backed loan, borrowing is **approval-gated** and happens in two distinct stages: an approver **authorises** an amount, and then **you draw it down**.

***

### Before you start

* You need the market’s **access token (NFT)** — this is your eligibility, in place of collateral.
* You sign the market’s **real-world financing agreement** off-chain. This legal contract, not a collateral ratio, is what backs repayment.

***

### The flow

```mermaid
sequenceDiagram
    participant Borrower
    participant Market as Financing Market
    participant Approver
    participant Pool as Pools / intents

    Borrower ->> Market: 1. requestFinancing (amount, terms)
    Approver ->> Market: 2. approveRequest (full or partial) → opens receive window
    Note over Borrower,Market: approval moves NO funds
    Borrower ->> Market: 3. receiveFinancing (draw down within window)
    Pool -->> Market: 4. Fill from intents (cheapest rate first)
    Market -->> Borrower: 5. Disburse to recipient address
```

#### 1. Request

Create a **financing request** specifying the amount you want, a **minimum acceptable amount**, and either:

* a **rate ceiling** (interest-accrual financing — interest accrues over time), or
* a **fixed repayment amount** over a set **duration** (fixed-repayment financing).

You can edit or cancel the request while it is still pending.

#### 2. Approval (no funds move yet)

An **Approver** reviews the request and either approves it — possibly for a **partial** amount — or declines it. Approval **does not transfer money**. It authorises an amount and **opens a timed receive window** (an earliest and latest time to draw down).

> This is the single most important difference from collateral lending: approval and funding are **separate**. You are cleared to borrow, but you pull the funds yourself.

#### 3. Draw down (receive)

Within the receive window, **you** call draw-down. Liquidity is assembled automatically from the pool’s **intents**, cheapest rate first (see [Intents & Liquidity](/intents-and-liquidity)) — you don’t pick lenders. Funds are sent to the **recipient address** on the request, which can differ from your wallet.

A draw-down may **partially fill** if capacity is short; you can draw again up to the approved amount while the window is open. Because capacity can change between approval and draw-down, the fill is only final once the transaction settles:

| Outcome              | Meaning                                           |
| -------------------- | ------------------------------------------------- |
| **Success**          | Financing is now `ACTIVE`.                        |
| **Lack of capacity** | Not enough lender liquidity right now.            |
| **Rate exceeded**    | Available liquidity is priced above your ceiling. |
| **Below minimum**    | Achievable fill is under your `minAmount`.        |

***

### Repayment & risk

* Repay any time — see [Repay](/financing-markets/repay). Loans are open-ended and governed by the signed agreement, not a health factor.
* There is **no price-based liquidation**. If a loan goes unpaid, the obligation can be **sold on a secondary market** at a discount, with proceeds refunded to the pool’s LPs.

***

### At a glance

| Stage               | Who acts | Funds move?                      |
| ------------------- | -------- | -------------------------------- |
| Request             | Borrower | No                               |
| Approve / decline   | Approver | No                               |
| Draw down (receive) | Borrower | **Yes** — disbursed to recipient |
| Repay               | Anyone   | Yes — back into the pool         |

For the complete state machine and statuses, see [Financing Request Lifecycle](/financing-request-lifecycle).


# Repay

Repay an active financing — in full or in part — against live on-chain obligations. Anyone can repay, at any time.

Repaying settles an **active financing**. There is no health factor and no forced liquidation clock — repayment is driven by the off-chain agreement — but interest keeps accruing on interest-accrual loans, so the payoff amount grows until you pay.

***

### What you owe

A financing’s debt is tracked on-chain as **obligations**, split into:

* **Principal** — the amount drawn down.
* **Interest** — accrued charges (for interest-accrual financings).
* **Other obligations** — any additional amounts defined by the market.

The live obligations are the source of truth for an exact payoff — a displayed “left to repay” figure is only an estimate between blocks.

***

### Ways to repay

```mermaid
sequenceDiagram
    participant Payer
    participant Market as Financing Market

    Payer ->> Market: 1. Approve asset token (if allowance short)
    Payer ->> Market: 2. repay (full) — or payInterest / repayPrincipal
    Market -->> Market: 3. Update obligations, route funds to pool
```

| Method                    | Effect                                                      |
| ------------------------- | ----------------------------------------------------------- |
| **Repay (full)**          | Pay off principal + interest + other obligations in one go. |
| **Pay interest**          | Clear accrued interest only.                                |
| **Repay principal**       | Reduce outstanding principal.                               |
| **Pay other obligations** | Settle any additional obligations.                          |

Repayment first requires an ERC-20 **approve** of the asset token to the market if your allowance is short.

***

### Things to know

* **Anyone can repay.** Repayment is not restricted to the borrower — any address can pay down a financing.
* **Partial repayment is allowed.** You don’t have to clear the whole loan at once.
* **Repaid funds return to the pool**, increasing the value of LP shares for suppliers.
* **No collateral liquidation.** If a loan goes unpaid, recovery runs through the **off-chain agreement**; the obligation may be **sold on a secondary market** at a discount, with proceeds refunded to the affected pool’s LPs.

See [Borrow](/financing-markets/borrow) for how a financing is created and [Financing Request Lifecycle](/financing-request-lifecycle) for the full state machine.


# Intents

An **intent** is a signed, published statement of what a participant wants to do in a market — the terms they are looking for, ahead of any financing request. Intents let originators, suppliers and borrowers signal interest and find a counterparty before anything is committed on-chain.

Intents are available in the app under **Intents**.

> Not to be confused with [**Intents & Liquidity**](/intents-and-liquidity), which covers supply-side intents — how a pool's capital is matched against a draw-down once a financing exists. This page is about publishing and discovering intents in the first place.

***

### What an intent contains

Each intent has two parts:

* A **public summary** — visible to anyone browsing the market, so the intent can be discovered.
* A **private detail document** — the full terms, readable only by addresses permitted to view it.

The document is stored in content-addressed storage and its hash is recorded on-chain, so an intent cannot be altered after publication without the change being visible.

***

### Who can do what

| Action                  | Who                                         |
| ----------------------- | ------------------------------------------- |
| Publish an intent       | Addresses on the market’s **creators** list |
| View the public summary | Anyone                                      |
| View the private detail | Addresses on the market’s **viewers** list  |

Both lists are held on-chain and controlled by the market. If your address is not on the creators list, the publish action is unavailable; if it is not on the viewers list, you see the summary but not the detail.

***

### Publishing an intent

1. Open **Intents** and choose **Create Intent**.
2. Fill in the intent — the public summary and the private detail.
3. **Sign** with your wallet. The signature authorizes publication and binds the intent to your address.
4. The detail is encrypted for the market’s viewers list, the document is stored, and its hash is written on-chain.

Once published, an intent is visible in the market’s intent list. Discovery is the point: a counterparty who can read the detail can act on it, typically by opening a [financing request](/financing-request-lifecycle).

***

### Relationship to financing

An intent is **not** a commitment and moves no money. Nothing is borrowed, supplied or approved by publishing one. It is a discovery step that sits before the [request → approve → draw down → repay](/financing-request-lifecycle) lifecycle, which remains the only path by which capital actually moves.


# Intents & Liquidity

When a borrower draws down an approved financing, the money doesn’t come from a single undifferentiated pool balance — it comes from **intents**. An intent is a standing offer of liquidity from a pool at a specific rate. This page explains how intents fill a draw-down.

***

### What an intent is

An **intent** is a pool’s commitment to lend:

| Property             | Meaning                                             |
| -------------------- | --------------------------------------------------- |
| **Source pool**      | The financing adapter (pool) providing the capital. |
| **Available amount** | How much of the intent is still unfilled.           |
| **Rate**             | The rate at which this capital is offered.          |
| **Validity window**  | The time range during which the intent can be used. |

A single market can have **many intents** at different rates, from one or several pools.

***

### Cheapest-first filling

When a borrower draws down, the protocol fills the requested amount from intents **sorted by rate, ascending** — the cheapest capital is used first, then the next cheapest, and so on until the draw-down amount is covered:

```mermaid
flowchart LR
    R[Draw-down: need 100k] --> S{Sort intents by rate}
    S --> I1[Intent A · 6% · 40k]
    S --> I2[Intent B · 8% · 40k]
    S --> I3[Intent C · 11% · 50k]
    I1 --> F[Fill 40k @6%]
    I2 --> F2[Fill 40k @8%]
    I3 --> F3[Fill 20k @11%]
```

* Each intent fills to capacity before the next is used.
* Filling stops once the draw-down amount is reached — leftover intents stay available for others.
* The borrower’s effective rate is the **blended** rate of the intents that filled the loan.

***

### Automatic selection

In the standard borrower flow, **intent selection is automatic**. The app picks the optimal set of intents and packs them into the draw-down transaction; the borrower simply confirms. A read-only preview may show the selected capacity, the number of intents used, and the resulting rate. Manual intent picking exists only as an advanced option.

***

### Guardrails

Because intents are priced offers with limited capacity, a draw-down respects the request’s terms:

| Guardrail          | Effect                                                                                                                                                          |
| ------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Rate ceiling**   | For interest-accrual requests, intents priced above the borrower’s ceiling are not used (and if that’s all there is, the draw-down fails with *rate exceeded*). |
| **Minimum amount** | If the achievable fill is below the request’s `minAmount`, the draw-down is rejected rather than partially settled.                                             |
| **Capacity**       | If total usable intent capacity is short, the draw-down either partially fills or fails with *lack of capacity*.                                                |
| **Validity**       | Expired or not-yet-valid intents are skipped.                                                                                                                   |

Because on-chain intent capacity can be consumed by other borrowers between approval and draw-down, the final fill is only known once the transaction settles — see [Financing Request Lifecycle](/financing-request-lifecycle).

***

### Where intents come from

Intents are created on the **liquidity side** of a market. LPs [supply](/financing-markets/supply) capital into a pool, and the pool (arranged by a **Curator**) makes that capital available as intents. This is how Arenas connects **passive LP deposits** to **program-specific borrower demand** without either side pricing the other manually.


# Credit Delegation Module (CDM)

The **Credit Delegation Module (CDM)** connects an external liquidity source — **SomniaLend** — to Arenas financing pools, so a supplier can put idle SomniaLend collateral to work earning Arenas yield.

***

### What it does

The CDM automates the **borrow-from-SomniaLend, supply-to-Arenas** strategy in one place:

1. A supplier keeps collateral on **SomniaLend** (earning its base supply yield).
2. They **delegate borrowing power** to the CDM using the standard credit-delegation interface.
3. The CDM **borrows against that delegated power** and **supplies the liquidity into an Arenas pool**.
4. Because the pool's supply yield exceeds the borrow rate, the supplier earns the **spread** as bonus yield — on top of the base supply yield they keep.

```mermaid
flowchart LR
    S[Supplier] -->|1. supply collateral| SL[(SomniaLend · external)]
    S -->|2. approveDelegation| CDM[Credit Delegation Module]
    CDM -->|3. borrow onBehalfOf| SL
    CDM -->|4. supply| Pools[(Arenas pools · Somnia)]
    Pools -->|spread / yield| S
```

***

### Credit delegation (the mechanism it builds on)

The CDM uses SomniaLend’s native credit delegation — nothing forked or reimplemented:

* The supplier (**delegator**) calls `approveDelegation` on the relevant **`VariableDebtToken`**, authorizing the CDM (**delegatee**) for an amount.
* The CDM calls `borrow` on the **`Pool`** with the delegator’s address as `onBehalfOf`.
* SomniaLend’s own rules still apply: eMode category must match, and a borrow that would push the delegator’s **health factor** below the liquidation threshold reverts. Collateral must be supplied before the borrow executes.

***

### Contract address

On **Somnia** (chain `5031`):

| Name                            | Address                                                                                                                             |
| ------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
| Credit Delegation Vault Factory | [`0x7d16B631B2134D48Fa6be13445191023dbF8D557`](https://mainnet.somnia.w3us.site/address/0x7d16B631B2134D48Fa6be13445191023dbF8D557) |

Each supplier’s delegation runs through a vault deployed by this factory. Addresses for the liquidity layer are published by SomniaLend — see [docs.somnialend.finance](https://docs.somnialend.finance).

***

### Risk

This is a **leveraged** position. The borrowed amount accrues interest, the delegator’s collateral remains subject to SomniaLend’s health-factor and liquidation rules, and the financing itself carries credit risk. The bonus only holds while pool yield exceeds the borrow cost. See [Risks](/risks).

***

> **SomniaLend is an external protocol**, not operated by Arenas. Arenas uses its publicly available liquidity and the standard credit-delegation interface. It is one optional liquidity source, and it sets its own market parameters and risk rules. See [docs.somnialend.finance](https://docs.somnialend.finance) and [app.somnialend.finance](https://app.somnialend.finance).


# Risks

Arenas offers decentralised access to the liquidity but the process is not without risks. Robust risk management measures, including smart contract audits and carefully set risk parameters, are in place to help mitigate risks. Below is an overview of key risks and mitigation efforts.

### Smart Contract Risk

Smart contracts can contain software bugs or other vulnerabilities within the protocol code and the underlying tokens. To mitigate these risks, Arenas has undergone multiple external third-party professional audits. Additionally, the protocol plans to run a continuous bug bounty program to incentivize external developers to identify and report any issues they may find so they can be fixed.

### Oracle Risk

Arenas relies on third-party oracles for price feeds and external data, such as redemption ratios for liquid staking tokens. This reliance introduces potential risks such as incorrect valuations if an oracle fails or is compromised. To reduce this risk, Arenas uses decentralised oracles like Chainlink, which provide tamper-resistant data feeds, greater reliability, and security measures.

### Repayment Risk

As Arenas use undercollateralized financing and off-chain signed financing agreement there is always a risk of a partial repayment of the financing principal and/ or interest, or a total non repayment.

Partially such a risk is mitigated by the use of the financing request approval, at which stage the borrower should be inspected thoroughly. But even a good borrower can have financial troubles in the future.\
For such a case there is another mitigation possibility - a non performing obligation liquidation and the sales process on the secondary markets. A discounted value after the obligation being sold is paid back directly to liquidity providers.

<br>


# FAQ

#### How is this different from typical DeFi lending protocols?

Traditional DeFi money markets are **overcollateralized**: you lock more value in collateral than you borrow, and on-chain liquidations enforce repayment.\
Arenas Financing markets are **credit-based and approval-gated**:

* **No on-chain collateral**.
* **Market Operator** (or **Approver**) approval is required for obligations.
* Every loan is backed by a **real-world legal agreement**, not just smart-contract rules.

***

#### Do I need to provide on-chain collateral to borrow?

No. Borrowers **do not** post on-chain collateral.\
Instead, you:

1. Create a **financing application** and financing request.
2. Sign a **real-world financing agreement contract** off-chain.
3. Wait for **Market Operator** (or **Approver**) approval and disbursement.

***

#### What happens if a borrower does not repay?

Because there is no on-chain collateral to liquidate:

* The protocol will show the loan as **in default** on-chain.
* Recovery relies on the **off-chain enforcement** of the signed loan agreement.
* Losses from defaults can affect the **value of lender LP tokens** in the affected pool.
* Liquidated obligation can be sold on a secondary market at a discount and the earned amount will be refunded to the affected pool.

Exact processes for handling defaults depend on the legal and operational framework of each market.

***

#### Can I withdraw my funds at any time as a lender?

You can **request a withdrawal at any time**, but:

* Withdrawals are **subject to available liquidity** in the pool.
* If much of the pool is lent out, your request may be:
  * **Partially fulfilled**, with the rest staying as LP tokens.
  * **Delayed** until more loans are repaid.

The protocol always returns either assets or LP tokens; it does not “freeze” your funds without a claim.

***

#### How do borrowers receive the funds?

After a financing request is approved:

* The executor (you or a designated address) calls the protocol to **initiate the obligation**.
* The **Financing Market Adapter** sends the obligation amount to the recipient address specified in the financing request.

This address can be different from the borrower’s own wallet if the deal structure requires it.

***

#### How is interest for lenders generated?

Lenders earn from:

* **Interest payments** from borrowers on active loans.
* Potential **upfront incentives** borrowers pay to attract more capital.
* Optional **reward programs** funded by the protocol or third parties.

All of this is reflected in the **growing value of LP tokens** over time.

***

#### Who can be a Market Operator?

A Market Operator is a **permissioned role** responsible for:

* Reviewing financing requests if there is no separate financing Approver role.
* Approving or rejecting new financing requests.
* Monitoring portfolio quality and market configuration.
* Making agreements with Pool Curators to attract liquidity to the market.
* Support market operational activity by making control over upgradable settings.

The specific criteria for who can act as a Market Operator and how they are appointed depend on the specific market and governance setup.

***

#### Is yield guaranteed?

No. Yield is **not guaranteed**.

* If borrowers repay on time, lenders can earn **interest and rewards**.
* If borrowers default, or if markets change, returns may be **lower than expected or negative**.

Always evaluate the risks before supplying or borrowing.

***

#### Where can I see the contract addresses?

The Arenas contract address is published on the [Credit Delegation Module](/credit-delegation) page; SomniaLend publishes its own at [docs.somnialend.finance](https://docs.somnialend.finance).\
Always verify that the address you interact with matches the documented one for your network