> ## Documentation Index
> Fetch the complete documentation index at: https://docs.inkwell.finance/llms.txt
> Use this file to discover all available pages before exploring further.

# Loan Lifecycle

> How Leviathan loans move from application through funding, active deployment, and completion or default.

> **CONFIDENTIAL & PROPRIETARY © 2026 Inkwell Finance, Inc. All Rights Reserved.**
>
> This document is for informational purposes only and does not constitute legal, tax, or investment advice, nor an offer to sell or a solicitation to buy any security or other financial instrument. Any examples, structures, or flows described here are design intent only and may change.

## Overview

Every Leviathan loan follows a defined lifecycle managed by the `leviathan-core` Solana program. Each stage has explicit entry and exit conditions enforced on-chain — loans cannot skip stages or transition without meeting the required criteria.

## Lifecycle Stages

```mermaid theme={null}
graph LR
    A[Application] --> B[Underwriting]
    B --> C[Approval]
    C --> D[Funding]
    D --> E[Active]
    E --> F[Repayment]
    F --> G[Completion]
    E --> H[Default]
    H --> I[NPL Auction]
```

### 1. Application

The borrower submits a loan application specifying:

* Requested capital amount and term
* Intended use of funds (which protocols, chains, and strategies)
* Revenue sources that will service the debt

The application is recorded on-chain as a loan account in `PENDING` state.

### 2. Underwriting

The protocol's credit scoring system (`leviathan-score`) evaluates the borrower:

* On-chain credit score is queried or computed
* Risk tier determines eligible terms, rates, and limits
* Off-chain ML models may contribute additional analysis via oracle feeds

Underwriting is not a manual approval — it is a programmatic assessment based on the borrower's on-chain history and credit profile.

### 3. Approval

If the borrower meets the credit criteria, the loan transitions to `APPROVED` state:

* Loan terms are finalized (principal, rate, term, repayment cap)
* Policy parameters are set (whitelisted destinations, daily limits, allowed functions)
* InkPact agreement hash is recorded on-chain (see below)

### 4. Funding

Capital is drawn from the lending pool (`leviathan-pool`) and deployed:

* Pool reserves are checked for available liquidity
* Funds are transferred to a policy-gated dWallet on Sui
* The borrower's policy sandbox is activated with the approved destination set

### 5. Active

The borrower operates within their policy sandbox:

* **Session keys** enable trading and operations without per-transaction lender approval
* **Keepers** monitor positions and enforce health checks
* All borrower transactions are verified against policy by `leviathan-verifier`

Revenue begins flowing through RevenueSplitter contracts on EVM chains, with splits automatically directing a portion to loan repayment.

### 6. Repayment

As revenue accumulates:

* Revenue oracles report repayment progress back to Solana
* The loan's outstanding balance decreases
* Borrowers may also make voluntary additional repayments

### 7. Completion

When the repayment cap is reached or the term expires with full repayment:

* The loan transitions to `COMPLETED` state
* Policy restrictions on the dWallet are released
* Remaining capital returns to the borrower's full control
* Pool depositors' share of returned capital (principal + interest) is reflected in LP token value

### Default Path

If a borrower fails to meet repayment obligations:

* Health checks detect the shortfall
* The loan transitions to `DEFAULTED` state
* The protocol can initiate enforcement actions through the dWallet
* Non-performing loans may proceed to NPL auction

## Policy Enforcement

Throughout the active phase, the borrower's capital operates within a **policy sandbox**:

* **Whitelisted destinations** — only pre-approved contracts and addresses can receive transactions. Attempts to interact with non-whitelisted targets are rejected before signing.
* **Daily limits** — time-bounded caps on transaction volume prevent rapid capital extraction, even to approved destinations.
* **Function-level controls** — policies restrict not just which contracts are callable, but which specific functions. A borrower approved for trading may be blocked from withdrawal functions on the same protocol.

Policy parameters are immutable for the duration of the loan unless modified through governed on-chain mechanisms.

## Keeper Automation

Keepers are automated agents that perform time-sensitive protocol operations:

| Keeper                   | Role                                                               |
| ------------------------ | ------------------------------------------------------------------ |
| **Drawdown keepers**     | Execute scheduled capital deployments after loan activation        |
| **Position monitors**    | Track borrower positions across chains and flag policy violations  |
| **Health check keepers** | Compute health factors and trigger warnings or enforcement actions |

Keepers operate through delegated execution — they have permission to call specific protocol instructions but cannot access borrower funds directly.

## InkPact Agreements

InkPact provides on-chain agreement verification:

* A cryptographic hash of the loan agreement document is stored on-chain at approval
* Both parties can independently verify that the on-chain terms match the signed agreement
* The hash is immutable once recorded — neither party can claim different terms after the fact

InkPact does not store the agreement itself on-chain — only a verifiable fingerprint. The full document is maintained off-chain by the parties.

## NPL Auctions

When a loan enters default and cannot be recovered through standard enforcement:

* The non-performing loan position is listed for auction
* Qualified participants can bid on the distressed position
* The winning bidder assumes the loan's rights and enforcement capabilities
* Proceeds from the auction are distributed to affected pool depositors

NPL auctions provide a market-based resolution mechanism, allowing the protocol to clear defaulted positions without indefinite deadlock.