# Infrastructure & Architecture

### Introduction

Lava Finance is built on a modular, cross-chain architecture designed for speed, security, and composability. The protocol combines intent-based execution, vault-centric liquidity management, decentralized oracle networks, and non-custodial asset handling into a unified infrastructure layer.

This section details the technical components that power the Lava ecosystem — from trade execution to yield distribution to real-world asset tokenization.

### System Architecture

<figure><img src="/files/gd0Q3F6n47ZTI2ehHdg5" alt=""><figcaption></figcaption></figure>

### Intent-Based Execution System

Traditional DEX architecture forces users to interact directly with liquidity pools. This creates slippage, MEV exposure, and fragmented liquidity across chains.

Lava replaces this with an intent-based model where users declare outcomes and solvers compete to deliver them.

**Intent Lifecycle**

| Stage          | Description                                                       |
| -------------- | ----------------------------------------------------------------- |
| 1. Creation    | User specifies desired outcome (asset, direction, size, leverage) |
| 2. Signature   | Intent signed off-chain — no gas until execution                  |
| 3. Broadcast   | Intent distributed to solver network                              |
| 4. Competition | Solvers quote execution prices, compete for fill                  |
| 5. Selection   | Best quote wins based on price, speed, and reliability score      |
| 6. Execution   | Winning solver executes trade on-chain                            |
| 7. Settlement  | User receives position with deterministic pricing                 |

**Intent Structure**

```
Intent {
    user: wallet_address
    action: LONG | SHORT | CLOSE
    asset: bAAPL | BTC-PERP | EUR/USD | ...
    size: uint256
    leverage: uint8 (1-100x)
    max_slippage: uint16 (basis points)
    deadline: timestamp
    signature: bytes
}
```

Intents are chain-agnostic. A user on Solana can express an intent that a solver fills using liquidity on Arbitrum — settlement abstracted from the user.

**Benefits**

* **Zero AMM slippage**: No bonding curves or pool imbalances
* **MEV protection**: Intent abstraction prevents front-running
* **Cross-chain liquidity**: Solvers aggregate across all connected venues
* **Gas efficiency**: Users pay only on successful execution
* **Deterministic pricing**: Price locked at intent acceptance

### Solver Network

Solvers are the execution backbone of Lava. They are specialized operators that compete to fill user intents at optimal prices.

**Solver Requirements**

| Requirement       | Description                                                  |
| ----------------- | ------------------------------------------------------------ |
| Stake             | Minimum $LAVA stake as collateral against malicious behavior |
| Liquidity Access  | Connections to CEXs, DEXs, OTC desks, and market makers      |
| Infrastructure    | Low-latency systems for real-time quote generation           |
| Reliability Score | Track record of successful, timely fills                     |

**Solver Economics**

Solvers earn profit from:

* Spread between quoted price and actual execution
* Volume-based rebates from liquidity venues
* Protocol incentives for maintaining uptime and fill rates

Solvers pay fees to the protocol for each successful fill. These fees flow to staking vaults and liquidity providers.

**Solver Selection Algorithm**

```
Score = (Price Quality × 0.5) + (Speed × 0.2) + (Reliability × 0.2) + (Stake Weight × 0.1)

Winner = MAX(Score) among all valid quotes within deadline
```

The algorithm prioritizes price while rewarding consistent, fast execution. Solvers with higher stakes and better track records gain preference in tie-breakers.

**Solver Slashing**

Malicious or negligent behavior triggers slashing:

| Violation                    | Penalty                      |
| ---------------------------- | ---------------------------- |
| Failed fill after commitment | 1% of stake                  |
| Price manipulation attempt   | 10% of stake + ban           |
| Collusion detection          | 25% of stake + permanent ban |
| Repeated timeout             | Temporary suspension         |

Slashed funds flow to affected users and the protocol treasury.

### Vault Architecture

Vaults are the liquidity and yield infrastructure of Lava. All protocol assets flow through vault contracts.

**Vault Types**

| Vault            | Function                            | Assets             | Yield Source        |
| ---------------- | ----------------------------------- | ------------------ | ------------------- |
| Staking Vault    | Hold staked $LAVA and stablecoins   | $LAVA, USDC        | Protocol fee share  |
| Liquidity Vault  | Provide execution depth for solvers | USDC, USDT         | Trading fees        |
| Collateral Vault | Hold bTokens as loan collateral     | bAAPL, bTSLA, etc. | —                   |
| Reserve Vault    | Protocol treasury and reserves      | Multi-asset        | Governance-directed |

**Staking Vault Mechanics**

<figure><img src="/files/nhVeDmvOGHMpII1EZx6Q" alt=""><figcaption></figcaption></figure>

Yield distribution occurs continuously. Users can claim accrued rewards at any time. Principal withdrawal subject to tier lock period.

**Liquidity Vault Mechanics**

Liquidity vaults provide depth for solver execution:

1. LPs deposit stablecoins into vault
2. Vault issues LP tokens representing share
3. Solvers draw on vault liquidity for trade execution
4. Trading fees accumulate in vault
5. LPs redeem LP tokens for principal + fees

Utilization rates determine APY. Higher trading volume = higher LP returns.

**Collateral Vault Mechanics**

bToken holders can deposit assets as collateral to borrow USDC:

| Parameter             | Value                                     |
| --------------------- | ----------------------------------------- |
| Collateral assets     | bAAPL, bTSLA, bNVDA, bGOOGL, bAMZN, bMSFT |
| Loan asset            | USDC                                      |
| LTV ratio             | Up to 70%                                 |
| Liquidation threshold | 80%                                       |
| Interest rate         | Variable (utilization-based)              |

Borrowers retain exposure to underlying asset. No taxable event triggered. Interest payments flow to protocol revenue.

### Oracle Infrastructure

Lava relies on decentralized oracle networks (DONs) for accurate, tamper-resistant data across all operations.

**Oracle Functions**

| Function             | Data Required                     | Update Frequency |
| -------------------- | --------------------------------- | ---------------- |
| Trade execution      | Real-time asset prices            | Sub-second       |
| Position marking     | Mark prices for PnL calculation   | Per block        |
| Liquidation          | Threshold prices for margin calls | Per block        |
| Proof-of-Reserve     | bToken backing verification       | Hourly           |
| Collateral valuation | bToken prices for borrowing       | Per block        |

**Oracle Providers**

| Provider          | Role                                              |
| ----------------- | ------------------------------------------------- |
| Chainlink         | Primary price feeds for crypto assets             |
| Pyth Network      | High-frequency price feeds for Solana             |
| Custom DON        | Synthetic stock prices from equity data providers |
| Reserve Attesters | Proof-of-Reserve for bToken backing               |

**Price Feed Architecture**

**Manipulation Resistance**

* Multiple independent data sources per asset
* Outlier detection and removal
* Time-weighted average prices (TWAP) for liquidations
* Circuit breakers on extreme price movements
* Multi-sig oracle updates for critical parameters

### Cross-Chain Infrastructure

Lava operates natively across Solana and EVM L2s without requiring users to bridge assets manually.

**Supported Networks**

| Network    | Type            | Finality | Primary Use                               |
| ---------- | --------------- | -------- | ----------------------------------------- |
| Solana     | L1              | \~400ms  | High-frequency trading, primary execution |
| Arbitrum   | L2 (Optimistic) | \~250ms  | EVM liquidity access, DeFi integrations   |
| Base       | L2 (Optimistic) | \~250ms  | Coinbase ecosystem, retail onboarding     |
| Future L2s | —               | —        | Expansion based on liquidity and demand   |

**Cross-Chain Execution Flow**

Users interact on their preferred chain. Solvers handle cross-chain routing internally. Settlement is abstracted — users receive positions without managing bridges.

**Unified Liquidity**

Traditional multi-chain protocols fragment liquidity. Lava's solver network aggregates liquidity across all connected chains into a single execution pool:

| Traditional Model        | Lava Model                    |
| ------------------------ | ----------------------------- |
| Separate pools per chain | Unified liquidity via solvers |
| User bridges manually    | No bridging required          |
| Slippage varies by chain | Consistent execution quality  |
| Arbitrage across chains  | Solvers arbitrage internally  |

**Message Passing**

Cross-chain state synchronization via:

| Method         | Use Case                                |
| -------------- | --------------------------------------- |
| Wormhole       | Asset transfers, vault state sync       |
| LayerZero      | Governance messaging, parameter updates |
| Native bridges | L2-specific operations                  |

Critical operations require multi-chain confirmation. Governance actions propagate to all deployed chains.

### Smart Contract Architecture

Lava's smart contracts are modular, upgradeable (via governance), and audited.

**Core Contracts**

| Contract        | Function                               | Chain Deployment |
| --------------- | -------------------------------------- | ---------------- |
| IntentRouter    | Receives and validates user intents    | All chains       |
| SolverRegistry  | Manages solver registration and stakes | Primary (Solana) |
| ExecutionEngine | Processes solver fills, settles trades | All chains       |
| StakingVault    | Manages staked positions and rewards   | All chains       |
| LiquidityVault  | Holds LP deposits, distributes fees    | All chains       |
| CollateralVault | Manages bToken collateral and loans    | All chains       |
| bTokenFactory   | Mints and burns bTokens                | Primary (Solana) |
| OracleConsumer  | Interfaces with price feeds            | All chains       |
| FeeDistributor  | Routes protocol revenue to recipients  | All chains       |
| Governance      | Manages proposals and voting           | Primary (Solana) |

**Upgradeability**

Contracts use a proxy pattern for upgradeability:

| Upgrade Type                       | Process                                              |
| ---------------------------------- | ---------------------------------------------------- |
| Minor (bug fixes)                  | Multisig approval (3/5 threshold)                    |
| Major (new features)               | Governance vote + timelock (48h)                     |
| Emergency (critical vulnerability) | Emergency multisig (4/5 threshold) + immediate pause |

All upgrades are transparent. Bytecode changes published before execution. Users can exit positions during timelock if they disagree with upgrade.

### Risk Management System

Lava implements multiple layers of risk management to protect users and protocol solvency.

**Position Risk**

| Mechanism           | Description                                                    |
| ------------------- | -------------------------------------------------------------- |
| Margin requirements | Initial margin based on leverage and asset volatility          |
| Maintenance margin  | Minimum margin to keep position open                           |
| Auto-deleveraging   | Reduces position size before liquidation in extreme conditions |
| Liquidation engine  | Closes underwater positions to protect LPs                     |

**Liquidation Process**

```
Position Health = Collateral Value / Position Value

If Health < Maintenance Threshold:
    1. Liquidation bot detects underwater position
    2. Oracle price verified (TWAP for manipulation resistance)
    3. Position closed at market price
    4. Remaining collateral returned to user (minus liquidation penalty)
    5. Penalty distributed to liquidator and protocol
```

Liquidation penalty: 5% of position value

* 3% to liquidator (incentive)
* 2% to insurance fund

**Insurance Fund**

Protocol maintains an insurance fund to cover:

* Liquidation shortfalls (position closed below debt)
* Oracle failures or manipulation
* Smart contract exploits (post-audit discovery)

Fund sources:

* Liquidation penalties (2% allocation)
* Protocol revenue (10% allocation)
* Governance-directed treasury allocation

**Circuit Breakers**

| Trigger                                    | Action                            |
| ------------------------------------------ | --------------------------------- |
| Price move > 20% in 5 minutes              | Trading paused for affected asset |
| Liquidation cascade (>10% of OI in 1 hour) | Auto-deleverage activated         |
| Oracle stale (>60 seconds)                 | New positions blocked             |
| Vault utilization > 95%                    | Withdrawals throttled             |

Circuit breakers are automatic. No manual intervention required. Trading resumes when conditions normalize.

### bToken Infrastructure

bTokens are synthetic representations of real-world equities, backed 1:1 by underlying shares.

<figure><img src="/files/kacyIswkZxy02fiSe6ia" alt=""><figcaption></figcaption></figure>

**Proof-of-Reserve System**

| Component             | Description                                   |
| --------------------- | --------------------------------------------- |
| Custodian             | Regulated entity holding underlying shares    |
| Attestation frequency | Hourly                                        |
| Verification method   | Oracle network queries custodian API          |
| On-chain proof        | Merkle root of holdings published to contract |
| User verification     | Any user can verify their bToken is backed    |

If reserves fall below 100% backing:

1. Minting paused immediately
2. Governance notified
3. Custodian required to restore backing within 24h
4. If unresolved, redemptions prioritized (FIFO)

**Corporate Actions**

bTokens reflect corporate actions on underlying shares:

| Action       | bToken Treatment                          |
| ------------ | ----------------------------------------- |
| Dividends    | Converted to USDC, distributed to holders |
| Stock splits | bToken supply adjusted proportionally     |
| Mergers      | bToken converted to new entity or USDC    |
| Delistings   | bToken redeemed at last traded price      |

### API & SDK Architecture

Lava provides programmatic access for developers, traders, and AI agents.

**REST API**

| Endpoint Category | Functions                               |
| ----------------- | --------------------------------------- |
| /markets          | Asset listings, prices, trading pairs   |
| /intents          | Create, sign, submit, cancel intents    |
| /positions        | View open positions, PnL, margin status |
| /vaults           | Staking balances, yields, LP positions  |
| /btokens          | bToken balances, prices, reserve status |
| /account          | Wallet balances, transaction history    |

**WebSocket Streams**

| Stream        | Data                                   |
| ------------- | -------------------------------------- |
| prices        | Real-time price updates for all assets |
| fills         | Intent fill notifications              |
| liquidations  | Liquidation events across protocol     |
| vault\_yields | Real-time yield accrual updates        |

**AI-Agent SDK**

Purpose-built SDK for autonomous trading agents:

python

```python
from lava_sdk import LavaAgent

agent = LavaAgent(wallet=wallet, network="solana")

# Express trading intent
intent = agent.create_intent(
    action="LONG",
    asset="bAAPL",
    size=10000,
    leverage=5,
    max_slippage=50  # basis points
)

# Submit and monitor
result = agent.submit_intent(intent)
position = agent.get_position(result.position_id)

# Automated strategy execution
agent.run_strategy(
    strategy="momentum",
    assets=["BTC-PERP", "ETH-PERP"],
    risk_limit=0.02  # 2% max drawdown
)
```

SDK features:

* Intent creation and management
* Position monitoring and risk checks
* Vault interactions (staking, LP)
* Strategy templates (momentum, mean-reversion, arbitrage)
* Event-driven execution hooks

### Security Architecture

**Defense Layers**

| Layer          | Protection                                                   |
| -------------- | ------------------------------------------------------------ |
| Smart contract | Audited code, formal verification for critical functions     |
| Access control | Role-based permissions, multisig for admin functions         |
| Economic       | Solver staking, liquidation incentives, insurance fund       |
| Operational    | Circuit breakers, rate limiting, anomaly detection           |
| Infrastructure | Distributed nodes, DDoS protection, encrypted communications |

**Audit Coverage**

| Auditor    | Scope                                       | Status              |
| ---------- | ------------------------------------------- | ------------------- |
| PeckShield | Core contracts (vaults, execution, staking) | Complete            |
| —          | bToken contracts                            | Scheduled (Phase 3) |
| —          | Cross-chain messaging                       | Scheduled (Phase 2) |

**Bug Bounty Program**

| Severity                   | Reward         |
| -------------------------- | -------------- |
| Critical (fund loss)       | Up to $500,000 |
| High (protocol disruption) | Up to $100,000 |
| Medium (limited impact)    | Up to $25,000  |
| Low (informational)        | Up to $5,000   |

Bounty program managed via Immunefi. All valid reports published post-fix.

**Incident Response**

| Phase       | Actions                                         |
| ----------- | ----------------------------------------------- |
| Detection   | Automated monitoring + community reports        |
| Triage      | Severity assessment within 1 hour               |
| Containment | Pause affected contracts if critical            |
| Resolution  | Deploy fix via emergency multisig or governance |
| Post-mortem | Public report within 7 days                     |

### Infrastructure Summary

| Component  | Technology                       | Purpose                       |
| ---------- | -------------------------------- | ----------------------------- |
| Execution  | Intent-based solver network      | Optimal trade execution       |
| Settlement | Solana, Arbitrum, Base           | Multi-chain finality          |
| Liquidity  | Vault-centric model              | Unified liquidity pool        |
| Oracles    | Chainlink, Pyth, custom DON      | Price feeds, Proof-of-Reserve |
| Storage    | On-chain state + IPFS (metadata) | Position and vault data       |
| API        | REST + WebSocket                 | Programmatic access           |
| SDK        | Python, TypeScript               | AI-agent integration          |
| Security   | Audits, multisig, insurance fund | Protocol protection           |

Lava's infrastructure is designed for scale, speed, and security. Every component is modular — allowing independent upgrades without system-wide disruption. The architecture supports current products while providing a foundation for future expansion into new asset classes, chains, and use cases.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.lavadefi.io/technical/infrastructure-and-architecture.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.