Architecture

Project 0 is built on the mrgnLendv2 program, a Solana smart contract that manages all lending, borrowing, and risk operations on-chain. The protocol's data model consists of five core entities.

Architecture at a Glance

┌────────────┐       ┌───────────┐       ┌──────────┐
│            │       │           │       │          │
│ Group      │1─────n│ Bank      │1─────n│ Oracle   │
│            │       │           │       │          │
└────────────┘       └───────────┘       └──────────┘
      1                    1
      │                    │
      │                    │
      n                    1
┌───────────┐       ┌────────────┐
│ Margin    │       │            │
│ Account   │1───≤16│  Balance   │
│           │       │            │
└───────────┘       └────────────┘

Group

A collection of Banks. Each Group has a single administrator (typically a secure governance multisig) who has broad authority over it, and several delegate admins (limit, emode, etc.) who can perform lower-risk modifications. All the assets you see on app.0.xyz belong to a single Group overseen by the foundation.

Bank

Each asset available to borrow and lend on P0 has a Bank. This account controls all the settings for a particular asset: interest rate curves, risk parameters (asset weights, liability weights), deposit and borrow caps, oracle configuration, and fee structure. Many Banks might exist for the same underlying token. Every asset listed on app.0.xyz is a Bank.

Account

Users can create as many Accounts as they want. Accounts are per-Group, and each Account can have up to 16 positions across any Banks in that Group. The Account contains various user-specific settings and cached values, along with a LendingAccount where Balances are stored.

Balance

A Balance is an asset or liability position in a single Bank. Users cannot have both an asset and a liability in the same Bank, and can have at most one Balance per Bank. Each Account's LendingAccount holds a collection of up to 16 Balances. Balances can be blank/unused, and are always sorted in byte order by the corresponding Bank's public key.

Asset Weight

Each asset available to lend has two asset weight rates: Initial and Maintenance. The Maintenance rate is always higher. When executing a borrow, collateral is valued at price * initial weight. When a liquidator attempts a liquidation, collateral is valued at price * maintenance weight. The range between these is sometimes called the "health buffer."

For example, if a user has collateral worth $10 and init/maint rates are 50% and 60% respectively, the user can borrow $10 * 0.5 = $5. For liquidation purposes, their collateral is worth $10 * 0.6 = $6.

The LTV displayed on app.0.xyz is the Initial weight. The health shown on the portfolio page uses the Maintenance weight.

Liability Weight

Each borrowable asset also has a liability weight, split into Initial and Maintenance. The Maintenance rate is always lower. When executing a borrow, liabilities are valued at price * initial weight. When a liquidator attempts a liquidation, liabilities are valued at price * maintenance weight.

On the borrowing page, the displayed "LTV" is 1 / Initial Liability Weight, i.e. the LTV you would get if lending an asset with an Asset Weight of 1.

Oracle

Each Bank has an oracle used to determine the price of the asset it transacts in. The Group admin is responsible for picking and maintaining the Oracle. Typically, Switchboard is the oracle provider, but Pyth is also supported, and some Banks have a fixed price. An Oracle may use multiple accounts. For example, a Kamino Bank uses a price source and the Kamino reserve.

For details on confidence intervals, EMA vs spot pricing, and staleness rules, see Oracles.