> ## 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.

# How It Works

> Account setup, capital deployment, risk management, and revenue capture in Leviathan Prime Brokerage.

> **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

Leviathan Prime Brokerage accounts are built on the same non-custodial, policy-gated infrastructure as Credit Line and Embedded Lending — extended to support multi-protocol capital deployment with portfolio-level risk management.

```mermaid theme={null}
graph LR
    A[Account Setup] --> B[Policy Configuration]
    B --> C[Capital Deployment]
    C --> D[Active Trading]
    D --> E[Revenue Capture]
    E --> F[Risk Monitoring]
    F --> D
```

## Account Setup

When a user onboards to Prime Brokerage, they receive a **policy-gated dWallet** — a multi-chain smart wallet controlled by Ika's 2PC-MPC threshold signature scheme.

Key properties of the dWallet:

* **Non-custodial** — neither the user nor Leviathan holds the full private key. Signing requires participation from both the user and the Ika network.
* **Multi-chain** — the same dWallet can sign transactions on Solana, EVM chains, Bitcoin, and Sui natively. No bridging or wrapping required.
* **Policy-gated** — every transaction must pass through the on-chain policy engine before it is co-signed. Unauthorized actions are rejected at the signing layer.

The dWallet is the user's margin account. All capital deployment, trading, and revenue flows pass through this wallet, subject to the configured policy.

## Policy Configuration

Each Prime Brokerage account is configured with a policy that defines the boundaries of permitted activity:

### Whitelisted Destinations

The set of protocols and contracts the user can interact with:

* Approved DEXs for trading
* Approved lending protocols for yield deployment
* Approved liquidity pools for LP positions
* Any other on-chain contracts the user's strategy requires

Destinations are approved during account setup and can be modified through governed on-chain mechanisms. The user cannot unilaterally add new destinations.

### Daily Limits

Time-bounded caps on transaction volume:

* Prevent rapid extraction of capital, even to approved destinations
* Configurable per destination or as an aggregate across all destinations
* Reset on a rolling basis

### Function-Level Controls

Beyond contract-level whitelisting, policies can restrict which specific functions on approved contracts are callable:

* A user approved for trading on a DEX may be blocked from calling withdrawal functions on that same DEX
* Deposit functions on a yield vault may be approved while emergency withdrawal functions are restricted
* Function selectors are validated by `leviathan-verifier` before co-signing

This granularity ensures that even within approved protocols, the user can only perform actions consistent with the intended strategy.

## Capital Deployment

Once the account is configured, the user draws down capital from their credit line:

1. **Credit line evaluation** — the user's on-chain credit score determines their available credit and terms
2. **Drawdown** — capital is drawn from Leviathan lending pools into the policy-gated dWallet
3. **Multi-protocol deployment** — the user deploys capital across whitelisted protocols using the dWallet

Capital is not locked to a single protocol. The user can allocate across their approved destination set — trading on one DEX, providing liquidity on another, and depositing into yield vaults — all from the same dWallet, under the same policy.

## Session Keys

For users running automated trading strategies, **session keys** enable continuous execution without repeated wallet signing:

* **Scoped** — each session key is authorized for specific operations only (e.g., "trade on DEX A and DEX B", "rebalance between yield vaults X, Y, Z")
* **Time-bounded** — keys expire after a configured duration. No automatic renewal.
* **Nonce-tracked** — every action increments an on-chain nonce, preventing replay of previously signed transactions
* **Revocable** — keys can be revoked immediately by the user or the protocol if policy violations are detected

A typical setup: the user creates a session key scoped to their approved trading venues with a 24-hour expiry. Their trading bot uses this key to execute strategies continuously. At expiry, a new session key must be explicitly created.

Session keys allow automated strategies to run at speed while maintaining the security invariant that all actions stay within policy bounds.

## Risk Management

### Portfolio-Level Health Monitoring

Keepers continuously monitor Prime Brokerage accounts at the **portfolio level**:

* Track positions across all deployed protocols
* Compute aggregate portfolio health considering cross-protocol exposure
* Account for position correlations and concentration risk
* Factor in unrealized PnL, collateral values, and outstanding loan balances

This is distinct from per-loan health tracking in Credit Line. A Prime Brokerage account may have positions across five protocols — the health factor reflects the combined risk of all positions, not just individual ones.

### Health Factor Thresholds

| Health Factor         | Status      | Action                                                       |
| --------------------- | ----------- | ------------------------------------------------------------ |
| Above target          | Healthy     | No action required                                           |
| Approaching threshold | Warning     | User notified, may be asked to reduce exposure or add margin |
| Below threshold       | At risk     | Automated position reduction may be triggered                |
| Critical              | Liquidation | Keeper-initiated enforcement to protect lender capital       |

### Automated Enforcement

When a portfolio's health deteriorates beyond configured thresholds:

1. **Warning** — the user is notified and given time to adjust positions
2. **Partial liquidation** — keepers may reduce exposure on the most at-risk positions
3. **Full enforcement** — in severe cases, the dWallet's policy can be tightened to prevent further capital deployment until health is restored

All enforcement actions are executed through the existing keeper and policy infrastructure — no manual intervention or custodial key access is required.

## Revenue Capture

As the user's strategies generate revenue (trading profits, yield, LP fees), revenue flows through the same capture mechanism used across all Leviathan products:

* **RevenueSplitter contracts** on EVM chains automatically split revenue between user operations and loan repayment
* **Revenue oracles** report repayment progress back to the Solana loan account
* **Automated repayment** reduces the outstanding loan balance without manual transfers

The split ratio is configured at loan origination. As the user generates revenue across multiple protocols, all revenue flowing through the dWallet is captured and split according to the agreed terms.

## Traditional vs. DeFi Prime Brokerage

|                       | **Traditional Prime Brokerage**                         | **Leviathan Prime Brokerage**                            |
| --------------------- | ------------------------------------------------------- | -------------------------------------------------------- |
| **Custody**           | Custodial — prime broker holds assets                   | Non-custodial — dWallet with threshold signing           |
| **Transparency**      | Opaque — positions and risk managed behind closed doors | Transparent — all positions and policy on-chain          |
| **Access control**    | Centralized — broker decides permissions                | Policy-gated — rules enforced by smart contracts         |
| **Risk management**   | Internal risk models, manual margin calls               | On-chain health factors, automated keeper enforcement    |
| **Revenue capture**   | Manual settlement, periodic reconciliation              | Automated splitter contracts, real-time oracle reporting |
| **Cross-venue**       | Multi-exchange via broker relationships                 | Multi-protocol via dWallet with destination whitelists   |
| **Audit trail**       | Internal records, periodic reporting                    | Full on-chain history, publicly verifiable               |
| **Counterparty risk** | Broker insolvency risk                                  | Minimized — non-custodial, no single point of failure    |

<Note>
  **Shared Infrastructure**

  Prime Brokerage builds on the same core infrastructure documented in the [Credit Line](/leviathan/credit-line/overview) section — dWallets, policy gates, session keys, keepers, credit scoring, and transaction verification. The distinguishing feature is multi-protocol scope with portfolio-level risk management, rather than per-loan or per-protocol isolation.
</Note>

## Next Steps

<Card title="Prime Brokerage Overview" icon="building-columns" href="/leviathan/prime-brokerage/overview">
  Back to the Prime Brokerage product overview
</Card>