Skip to main content
CONFIDENTIAL & PROPRIETARY © 2025 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.

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 FactorStatusAction
Above targetHealthyNo action required
Approaching thresholdWarningUser notified, may be asked to reduce exposure or add margin
Below thresholdAt riskAutomated position reduction may be triggered
CriticalLiquidationKeeper-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 BrokerageLeviathan Prime Brokerage
CustodyCustodial — prime broker holds assetsNon-custodial — dWallet with threshold signing
TransparencyOpaque — positions and risk managed behind closed doorsTransparent — all positions and policy on-chain
Access controlCentralized — broker decides permissionsPolicy-gated — rules enforced by smart contracts
Risk managementInternal risk models, manual margin callsOn-chain health factors, automated keeper enforcement
Revenue captureManual settlement, periodic reconciliationAutomated splitter contracts, real-time oracle reporting
Cross-venueMulti-exchange via broker relationshipsMulti-protocol via dWallet with destination whitelists
Audit trailInternal records, periodic reportingFull on-chain history, publicly verifiable
Counterparty riskBroker insolvency riskMinimized — non-custodial, no single point of failure
Shared InfrastructurePrime Brokerage builds on the same core infrastructure documented in the Credit Line 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.

Next Steps

Prime Brokerage Overview

Back to the Prime Brokerage product overview