TL;DR​

DefiTuna AMM combines concentrated liquidity, on-chain limit orders, and leveraged liquidity provision in a unique AMM design. This article focuses on the Anchor smart contract that implements this protocol, specifically examining:

• Program Architecture: A hybrid AMM with integrated limit order book, implemented as a multi-instruction Anchor program
• Key Instructions: initialize_pool, create_position, place_limit_order, swap, leverage_position
• Account Structure: Complex PDA hierarchies for pools, positions, orders, and leveraged positions with proper rent management
• Mathematical Core: Concentrated liquidity calculations with leverage multipliers
• Security Patterns: Comprehensive validation, owner controls, and reentrancy protection through Solana's native constraints

Introduction​

DefiTuna AMM represents an innovative approach to decentralized exchanges by integrating traditional AMM mechanics with orderbook-style limit orders and leverage capabilities. This Anchor smart contract implements the core on-chain logic that makes this possible, providing developers with a practical example of advanced Solana DeFi programming patterns.

The program follows a modular architecture with separate handlers for pool management, position creation, order placement, and swap execution. All state is managed through PDAs to ensure secure ownership and access control.

Architecture Diagrams​

Account Relationships​

Instruction Flow for Limit Order Execution​

Account Structure​

PDA Derivation Example​

#[account]
#[derive(InitSpace)]
pub struct Pool {
    pub base_mint: Pubkey,
    pub quote_mint: Pubkey,
    pub fee_rate: u16, // basis points
    pub protocol_fee_rate: u16,
    pub tick_spacing: i32,
    pub current_tick_index: i32,
    pub liquidity: u128,
    pub sqrt_price: u128,
    pub fee_growth_global_0: u128,
    pub fee_growth_global_1: u128,
    pub protocol_fees_0: u64,
    pub protocol_fees_1: u64,
    pub bump: u8,
}

// PDA derivation for pool
let (pool_pda, pool_bump) = Pubkey::find_program_address(
    &[
        b"pool",
        base_mint.as_ref(),
        quote_mint.as_ref(),
    ],
    program_id
);

## Instruction Handlers Deep Dive

### 1. `initialize_pool` - Pool Creation

This instruction creates a new liquidity pool with specified parameters:

```rust
#[derive(Accounts)]
pub struct InitializePool<'info> {
    #[account(mut)]
    pub payer: Signer<'info>,
    
    #[account(
        init,
        payer = payer,
        space = 8 + Pool::INIT_SPACE,
        seeds = [
            b"pool",
            base_mint.key().as_ref(),
            quote_mint.key().as_ref()
        ],
        bump
    )]
    pub pool: Account<'info, Pool>,
    
    pub base_mint: Account<'info, Mint>,
    pub quote_mint: Account<'info, Mint>,
    
    pub system_program: Program<'info, System>,
}

pub fn initialize_pool(
    ctx: Context<InitializePool>,
    fee_rate: u16,
    tick_spacing: i32,
    initial_sqrt_price: u128,
) -> Result<()> {
    let pool = &mut ctx.accounts.pool;
    
    // Validate parameters
    require!(fee_rate <= MAX_FEE_RATE, ErrorCode::InvalidFeeRate);
    require!(tick_spacing > 0, ErrorCode::InvalidTickSpacing);
    
    // Initialize pool state
    pool.base_mint = ctx.accounts.base_mint.key();
    pool.quote_mint = ctx.accounts.quote_mint.key();
    pool.fee_rate = fee_rate;
    pool.tick_spacing = tick_spacing;
    pool.sqrt_price = initial_sqrt_price;
    pool.current_tick_index = calculate_tick_from_sqrt_price(initial_sqrt_price);
    pool.bump = ctx.bumps.pool;
    
    Ok(())
}

### 2. `create_position` - Concentrated Liquidity Position

Creates a position with liquidity concentrated between specified ticks:

```rust
#[derive(Accounts)]
#[instruction(position_id: u64)]
pub struct CreatePosition<'info> {
    #[account(mut)]
    pub owner: Signer<'info>,
    
    #[account(
        seeds = [
            b"pool",
            pool.base_mint.as_ref(),
            pool.quote_mint.as_ref()
        ],
        bump = pool.bump
    )]
    pub pool: Account<'info, Pool>,
    
    #[account(
        init,
        payer = owner,
        space = 8 + Position::INIT_SPACE,
        seeds = [
            b"position",
            pool.key().as_ref(),
            owner.key().as_ref(),
            &position_id.to_le_bytes()
        ],
        bump
    )]
    pub position: Account<'info, Position>,
    
    #[account(mut)]
    pub token_account_a: Account<'info, TokenAccount>,
    #[account(mut)]
    pub token_account_b: Account<'info, TokenAccount>,
    
    pub token_program: Program<'info, Token>,
    pub system_program: Program<'info, System>,
}

#[account]
#[derive(InitSpace)]
pub struct Position {
    pub pool: Pubkey,
    pub owner: Pubkey,
    pub liquidity: u128,
    pub tick_lower: i32,
    pub tick_upper: i32,
    pub fee_growth_inside_0_last: u128,
    pub fee_growth_inside_1_last: u128,
    pub tokens_owed_0: u64,
    pub tokens_owed_1: u64,
    pub bump: u8,
}

pub fn create_position(
    ctx: Context<CreatePosition>,
    position_id: u64,
    tick_lower: i32,
    tick_upper: i32,
    liquidity_delta: u128,
) -> Result<()> {
    let pool = &mut ctx.accounts.pool;
    let position = &mut ctx.accounts.position;
    
    // Validate tick bounds
    require!(tick_lower < tick_upper, ErrorCode::InvalidTickRange);
    require!(tick_lower % pool.tick_spacing == 0, ErrorCode::TickNotSpaced);
    require!(tick_upper % pool.tick_spacing == 0, ErrorCode::TickNotSpaced);
    
    // Calculate required token amounts
    let (amount_a, amount_b) = calculate_liquidity_amounts(
        pool.sqrt_price,
        tick_lower,
        tick_upper,
        liquidity_delta
    );
    
    // Transfer tokens from user
    transfer_tokens_in(
        &ctx.accounts.token_account_a,
        &ctx.accounts.token_account_b,
        amount_a,
        amount_b,
        &ctx.accounts.token_program,
        &ctx.accounts.owner
    )?;
    
    // Update position state
    position.pool = ctx.accounts.pool.key();
    position.owner = ctx.accounts.owner.key();
    position.liquidity = liquidity_delta;
    position.tick_lower = tick_lower;
    position.tick_upper = tick_upper;
    position.bump = ctx.bumps.position;
    
    // Update pool liquidity
    update_ticks_liquidity(pool, tick_lower, tick_upper, liquidity_delta, true)?;
    
    Ok(())
}

### 3. `place_limit_order` - Orderbook Integration

Creates a limit order that sits on the order book until matched:

```rust
#[derive(Accounts)]
#[instruction(order_id: u64)]
pub struct PlaceLimitOrder<'info> {
    #[account(mut)]
    pub owner: Signer<'info>,
    
    #[account(
        seeds = [
            b"pool",
            pool.base_mint.as_ref(),
            pool.quote_mint.as_ref()
        ],
        bump = pool.bump
    )]
    pub pool: Account<'info, Pool>,
    
    #[account(
        init,
        payer = owner,
        space = 8 + LimitOrder::INIT_SPACE,
        seeds = [
            b"order",
            pool.key().as_ref(),
            owner.key().as_ref(),
            &order_id.to_le_bytes()
        ],
        bump
    )]
    pub order: Account<'info, LimitOrder>,
    
    #[account(
        mut,
        token::mint = pool.base_mint,
        token::authority = owner
    )]
    pub user_token_account: Account<'info, TokenAccount>,
    
    #[account(
        init,
        payer = owner,
        token::mint = pool.base_mint,
        token::authority = order,
        seeds = [
            b"order_vault",
            order.key().as_ref()
        ],
        bump
    )]
    pub order_vault: Account<'info, TokenAccount>,
    
    pub token_program: Program<'info, Token>,
    pub system_program: Program<'info, System>,
}

#[account]
#[derive(InitSpace)]
pub struct LimitOrder {
    pub pool: Pubkey,
    pub owner: Pubkey,
    pub order_id: u64,
    pub tick: i32,
    pub amount: u64,
    pub is_bid: bool,
    pub filled_amount: u64,
    pub status: OrderStatus,
    pub bump: u8,
}

pub fn place_limit_order(
    ctx: Context<PlaceLimitOrder>,
    order_id: u64,
    tick: i32,
    amount: u64,
    is_bid: bool,
) -> Result<()> {
    let order = &mut ctx.accounts.order;
    
    // Validate tick alignment
    let pool = &ctx.accounts.pool;
    require!(tick % pool.tick_spacing == 0, ErrorCode::TickNotSpaced);
    
    // Transfer tokens to order vault
    let transfer_ctx = CpiContext::new(
        ctx.accounts.token_program.to_account_info(),
        Transfer {
            from: ctx.accounts.user_token_account.to_account_info(),
            to: ctx.accounts.order_vault.to_account_info(),
            authority: ctx.accounts.owner.to_account_info(),
        }
    );
    
    transfer(transfer_ctx, amount)?;
    
    // Initialize order
    order.pool = ctx.accounts.pool.key();
    order.owner = ctx.accounts.owner.key();
    order.order_id = order_id;
    order.tick = tick;
    order.amount = amount;
    order.is_bid = is_bid;
    order.filled_amount = 0;
    order.status = OrderStatus::Open;
    order.bump = ctx.bumps.order;
    
    // Emit order placed event
    emit!(OrderPlaced {
        pool: ctx.accounts.pool.key(),
        owner: ctx.accounts.owner.key(),
        order_id,
        tick,
        amount,
        is_bid,
        timestamp: Clock::get()?.unix_timestamp,
    });
    
    Ok(())
}

### 4. `swap` - Execution with Order Matching

Executes a swap, potentially matching against limit orders:

```rust
pub fn swap(
    ctx: Context<Swap>,
    amount: u64,
    sqrt_price_limit: u128,
    is_exact_input: bool,
) -> Result<()> {
    let pool = &mut ctx.accounts.pool;
    
    // Calculate swap amounts
    let (amount_in, amount_out, sqrt_price_new, liquidity) =
        compute_swap_step(
            pool.sqrt_price,
            sqrt_price_limit,
            pool.liquidity,
            amount,
            pool.fee_rate,
            is_exact_input
        )?;
    
    // Check against limit orders in this tick range
    let matched_orders = find_matching_orders(
        pool,
        pool.current_tick_index,
        get_tick_from_sqrt_price(sqrt_price_new),
        !is_exact_input // opposite side of trade
    );
    
    let mut total_matched = 0;
    for order_info in matched_orders {
        let order_account = &ctx.remaining_accounts[order_info.index];
        let mut order = Account::<LimitOrder>::try_from(order_account)?;
        
        let match_amount = min(order.amount - order.filled_amount, amount_out - total_matched);
        
        // Execute against limit order
        execute_against_limit_order(
            &mut order,
            match_amount,
            &ctx.accounts.token_program,
            &ctx.accounts.user_token_account,
            &ctx.accounts.order_vaults[order_info.vault_index]
        )?;
        
        total_matched += match_amount;
        if total_matched >= amount_out {
            break;
        }
    }
    
    // Update pool state
    pool.sqrt_price = sqrt_price_new;
    pool.liquidity = liquidity;
    
    // Apply fees
    let protocol_fee = amount_in
        .checked_mul(pool.protocol_fee_rate as u64)
        .unwrap()
        .checked_div(10_000)
        .unwrap();
    
    if is_exact_input {
        pool.protocol_fees_0 = pool.protocol_fees_0
            .checked_add(protocol_fee)
            .unwrap();
    } else {
        pool.protocol_fees_1 = pool.protocol_fees_1
            .checked_add(protocol_fee)
            .unwrap();
    }
    
    Ok(())
}

### 5. `leverage_position` - Leveraged Liquidity

Enables leveraged liquidity provision with up to 5x multiplier:

```rust
pub fn leverage_position(
    ctx: Context<LeveragePosition>,
    leverage_id: u64,
    position_key: Pubkey,
    leverage_multiplier: u8,
    collateral_amount: u64,
) -> Result<()> {
    require!(leverage_multiplier >= 1, ErrorCode::InvalidLeverage);
    require!(leverage_multiplier <= MAX_LEVERAGE, ErrorCode::ExceedsMaxLeverage);
    
    let position = &ctx.accounts.position;
    let leveraged_position = &mut ctx.accounts.leveraged_position;
    
    // Calculate borrowed amounts
    let total_liquidity_value = calculate_position_value(position, ctx.accounts.pool.sqrt_price);
    let collateral_value = calculate_token_value(collateral_amount, ctx.accounts.pool.sqrt_price);
    
    let max_borrow_value = collateral_value
        .checked_mul(leverage_multiplier as u64)
        .unwrap()
        .checked_sub(collateral_value)
        .unwrap();
    
    // Create leveraged position
    leveraged_position.position = position_key;
    leveraged_position.owner = ctx.accounts.owner.key();
    leveraged_position.leverage_multiplier = leverage_multiplier;
    leveraged_position.collateral_amount = collateral_amount;
    leveraged_position.borrowed_amount_0 = calculate_borrow_amount_0(total_liquidity_value, max_borrow_value);
    leveraged_position.borrowed_amount_1 = calculate_borrow_amount_1(total_liquidity_value, max_borrow_value);
    leveraged_position.bump = ctx.bumps.leveraged_position;
    
    // Health check: ensure position remains safe
    let health_ratio = calculate_health_ratio(leveraged_position, ctx.accounts.pool.sqrt_price);
    require!(health_ratio > MIN_HEALTH_RATIO, ErrorCode::InsufficientCollateral);
    
    Ok(())
}

## Mathematical Formulas

### Concentrated Liquidity Calculations

The amount of token X and Y required for a liquidity position between ticks $t_L$ and $t_U$ is given by:

$$
\Delta x = \Delta L \cdot \left( \frac{1}{\sqrt{P}} - \frac{1}{\sqrt{P_U}} \right)
$$

$$
\Delta y = \Delta L \cdot \left( \sqrt{P} - \sqrt{P_L} \right)
$$

Where:
- $\Delta L$ is the liquidity delta
- $\sqrt{P}$ is the current square root price
- $\sqrt{P_L}, \sqrt{P_U}$ are square root prices at lower and upper ticks

### Swap Computation

For a swap with fee $f$ (in basis points):

Effective amount in after fees:

$$
\Delta x_{eff} = \Delta x \cdot \left(1 - \frac{f}{10^4}\right)
$$

Output amount:

$$
\Delta y = \frac{y \cdot \Delta x_{eff}}{x + \Delta x_{eff}}
$$

### Leverage Health Ratio

$$
\text{Health Ratio} = \frac{\text{Position Value}}{\text{Borrowed Value} \cdot \text{Liquidation Threshold}}
$$

Positions are liquidated when:

$$
\text{Health Ratio} < 1
$$

## Solana & Anchor Best Practices

### 1. Account Validation Patterns

Always validate accounts using Anchor's type system:

```rust
#[account(
    constraint = token_account.mint == pool.base_mint,
    constraint = token_account.owner == owner.key()
)]
pub token_account: Account<'info, TokenAccount>,

### 2. Compute Unit Optimization

Use iteration limits and batch processing for order matching:

```rust
const MAX_ORDERS_PER_SWAP: usize = 10;

for i in 0..min(remaining_orders.len(), MAX_ORDERS_PER_SWAP) {
    // Process order
    if compute_units_remaining() < SAFE_COMPUTE_LIMIT {
        break;
    }
}

### 3. Token-2022 Compatibility

Handle transfer fees by checking received amounts:

```rust
let balance_before = token_account.amount;
transfer(transfer_ctx, amount)?;
let balance_after = token_account.reload()?.amount;
let received_amount = balance_after.checked_sub(balance_before).unwrap();

### 4. Event Emission for Indexers

Emit structured events for easy off-chain processing:

```rust
#[event]
pub struct SwapEvent {
    pub pool: Pubkey,
    pub trader: Pubkey,
    pub amount_in: u64,
    pub amount_out: u64,
    pub sqrt_price_before: u128,
    pub sqrt_price_after: u128,
    pub liquidity: u128,
    pub timestamp: i64,
}

## Security Considerations

### 1. Access Control

All critical operations use PDA-based authority:

```rust
#[account(
    seeds = [b"config"],
    bump = config.bump,
    constraint = config.admin == admin.key()
)]
pub config: Account<'info, ProtocolConfig>,

### 2. Input Validation

Validate all user inputs with appropriate bounds:

```rust
require!(tick_lower < tick_upper, ErrorCode::InvalidTickRange);
require!(fee_rate <= MAX_FEE_RATE, ErrorCode::InvalidFeeRate);
require!(amount > 0, ErrorCode::ZeroAmount);

### 3. Arithmetic Safety

Use checked arithmetic to prevent overflows:

```rust
let total = amount_a
    .checked_add(amount_b)
    .ok_or(ErrorCode::ArithmeticOverflow)?;

### 4. Reentrancy Protection

Solana's transaction model prevents reentrancy, but validate cross-program interactions:

```rust
// Ensure token accounts belong to the expected mints
require!(
    token_account_a.mint == pool.base_mint &&
    token_account_b.mint == pool.quote_mint,
    ErrorCode::InvalidTokenAccount
);

### 5. Oracle Manipulation Protection

Use time-weighted prices for sensitive operations:

```rust
let price = calculate_time_weighted_price(
    pool.sqrt_price_history,
    Clock::get()?.unix_timestamp
);

## How to Use This Contract

### Building and Deploying

```bash
# Build the program
anchor build

# Deploy to devnet
anchor deploy --provider.cluster devnet

# Verify deployment
solana program show --programs

### Example TypeScript Client

```typescript
import * as anchor from "@coral-xyz/anchor";
import { Program } from "@coral-xyz/anchor";
import { DefiTunaAmm } from "../target/types/defi_tuna_amm";

async function createPosition() {
  const provider = anchor.AnchorProvider.env();
  anchor.setProvider(provider);
  
  const program = anchor.workspace.DefiTunaAmm as Program<DefiTunaAmm>;
  
  const [poolPda] = anchor.web3.PublicKey.findProgramAddressSync(
    [
      Buffer.from("pool"),
      baseMint.toBuffer(),
      quoteMint.toBuffer()
    ],
    program.programId
  );
  
  const positionId = new anchor.BN(Date.now());
  const [positionPda] = anchor.web3.PublicKey.findProgramAddressSync(
    [
      Buffer.from("position"),
      poolPda.toBuffer(),
      provider.wallet.publicKey.toBuffer(),
      positionId.toArrayLike(Buffer, "le", 8)
    ],
    program.programId
  );
  
  const tx = await program.methods
    .createPosition(
      positionId,
      -6000, // tick_lower
      6000,  // tick_upper
      new anchor.BN(1000000) // liquidity
    )
    .accounts({
      pool: poolPda,
      position: positionPda,
      owner: provider.wallet.publicKey,
      tokenAccountA: tokenAccountA,
      tokenAccountB: tokenAccountB,
    })
    .rpc();
    
  console.log("Transaction signature:", tx);
}

### Required Pre-Instructions

For complex operations like leveraged positions, you may need to:

1. Create associated token accounts
2. Approve token transfers
3. Initialize required PDAs
4. Fund accounts with minimum rent

## Extending the Contract

### Adding New Instructions

1. Define new account structs in `#[derive(Accounts)]`
2. Implement handler function with proper validation
3. Add to the `lib.rs` module exports
4. Update IDL generation

### Customization Points

- **Fee Models**: Modify `compute_swap_step` for dynamic fees
- **Order Types**: Extend `LimitOrder` for different order types (FOK, IOC)
- **Leverage Models**: Add new collateral types or liquidation mechanisms
- **Oracle Integration**: Incorporate Pyth or Switchboard for price feeds

### Testing Strategies

```rust
#[tokio::test]
async fn test_swap_with_limit_order_match() {
    let mut test = ProgramTest::new(
        "defi_tuna_amm",
        id(),
        processor!(processor::Processor::process)
    );
    
    // Add accounts and mints
    test.add_account(mint_pubkey, mint_account);
    
    let (mut banks_client, payer, recent_blockhash) = test.start().await;
    
    // Create and place limit order
    let place_order_ix = Instruction {
        program_id: id(),
        accounts: place_order_accounts,
        data: place_order_data,
    };
    
    // Execute swap that should match
    let swap_ix = Instruction {
        program_id: id(),
        accounts: swap_accounts,
        data: swap_data,
    };
    
    let transaction = Transaction::new_signed_with_payer(
        &[place_order_ix, swap_ix],
        Some(&payer.pubkey()),
        &[&payer],
        recent_blockhash
    );
    
    banks_client.process_transaction(transaction).await.unwrap();
}

## Conclusion

The DefiTuna AMM smart contract demonstrates advanced Anchor patterns for building sophisticated DeFi protocols on Solana. By combining concentrated liquidity, limit orders, and leverage in a single program, it showcases how to manage complex state relationships while maintaining security and efficiency.

Key takeaways for developers:
1. Use PDA hierarchies for secure ownership and access control
2. Implement mathematical operations with overflow protection
3. Design for composability with other Solana programs
4. Emit comprehensive events for off-chain indexing
5. Optimize for compute units in iteration-heavy operations

This contract serves as a foundation for building next-generation AMMs that bridge the gap between traditional order books and automated market makers.

TL;DR​

• Kamino Lend is a high-performance lending protocol on Solana with over $2.68B TVL, using a peer-to-pool model for capital efficiency
• This Anchor smart contract implements core lending functionality: reserve management, borrowing, collateralization, and liquidations via CPI integration
• Key Instructions: init_reserve, deposit, withdraw, borrow, repay, liquidate with Anchor CPI to SPL token program
• Account Architecture: Extensive use of PDAs for reserve state, obligation tracking, and interest rate calculations with proper rent management
• Anchor Patterns: Comprehensive use of #[account] macros, #[derive(Accounts)] structs, and init_if_needed for gas-efficient deployments
• Mathematical Core: Utilization-based interest rates with compound interest accrual using exponential formulas and health factor calculations

Introduction​

Kamino Lend represents the cutting edge of Solana lending infrastructure, implementing a sophisticated peer-to-pool model that balances capital efficiency with risk management. With over $2.68B in Total Value Locked, the protocol's architecture has proven its robustness at scale, making it an essential case study for understanding production-grade DeFi systems on Solana.

Architectural Philosophy​

The protocol's design is built on three foundational principles:

1. Capital Efficiency Through Pooling: Unlike peer-to-peer lending models, Kamino aggregates liquidity into shared pools, maximizing utilization and providing instant liquidity for borrowers and lenders.

2. Risk Isolation via Reserve Architecture: Each asset operates as an independent reserve with its own risk parameters, interest rate models, and collateralization ratios, preventing contagion across markets.

3. Composability First: The contract is designed as a building block for higher-order DeFi primitives, enabling strategies like leveraged yield farming, delta-neutral positions, and automated portfolio management.

This guide examines the architectural patterns and design decisions that enable Kamino Lend to operate at scale, focusing on account structures, state management, mathematical models, and system invariants rather than implementation details.

Architecture Diagrams​

Account Relationships and PDA Hierarchy​

Deposit Instruction Flow​

Account Structure Table​

| OracleAccount | External | N/A | Price feed for asset | Pyth/Switchboard account |

Core Lending Primitives​

1. Reserve Initialization Architecture​

Reserve initialization establishes the fundamental infrastructure for a lending market. Each reserve represents an isolated pool for a single asset type, with its own economic parameters and risk profile.

Account Hierarchy:

• Reserve PDA: Central state account storing liquidity metrics, interest rates, and configuration
• Liquidity Vault: Token account holding deposited assets, controlled by the reserve PDA
• Collateral Token Mint: Represents depositor shares (similar to LP tokens in AMMs)
• Fee Receiver: Accumulates protocol revenue from interest spread
• Oracle Account: External price feed for collateral valuation

Design Decisions:

1. PDA-Based Authority: The reserve PDA acts as the authority for all token operations, eliminating the need for separate signer management and ensuring atomic operations.

2. Idempotent Initialization: Using init_if_needed patterns allows for graceful handling of concurrent initialization attempts, critical for permissionless market creation.

3. Parametric Risk Models: Each reserve stores its own loan-to-value ratio, liquidation threshold, and interest rate curve, enabling fine-tuned risk management per asset.

Economic Configuration:

• Optimal utilization target (typically 80%)
• Base and slope interest rate parameters
• Liquidation bonus and close factor
• Reserve factor for protocol revenue

2. Deposit Mechanism: Share-Based Accounting​

The deposit system implements a share-based accounting model where depositors receive collateral tokens (cTokens) representing their proportional ownership of the reserve's assets.

Mechanism Flow:

1. Interest Accrual: Before any operation, the reserve accrues accumulated interest, ensuring all depositors benefit proportionally from lending activity.

2. Exchange Rate Calculation: The system calculates how many cTokens to mint based on the current ratio of total deposits to outstanding cTokens. This rate increases over time as interest accrues.

3. Atomic Token Operations: User assets transfer to the reserve vault and cTokens mint to the user in a single transaction, preventing partial execution.

4. State Updates: Reserve metrics update atomically, maintaining invariants around total supply and collateral.

Mathematical Core: The exchange rate between underlying tokens and cTokens uses compound interest:

Where both numerator and denominator grow with interest accrual. For deposit amount $A$:

3. Borrowing Architecture: Multi-Collateral Risk Management​

The borrowing system enables users to take loans against deposited collateral while maintaining solvency through a health factor mechanism.

Obligation Structure:

Each user has a single Obligation account per lending market that tracks:

• Deposits: Array of collateral positions across multiple reserves
• Borrows: Array of loan positions with accrued interest
• Health Factor: Real-time solvency metric
• Last Update: Timestamp for interest calculation

Risk Management Layers:

1. Per-Asset LTV Ratios: Each collateral type has a maximum loan-to-value ratio (e.g., SOL at 80%, meme coins at 50%), determining borrowing power.

2. Cross-Collateral Aggregation: Users can borrow against multiple collateral types simultaneously, with total borrowing power calculated across all deposits.

3. Utilization Caps: Each reserve has maximum utilization limits to ensure liquidity for withdrawals.

4. Dynamic Health Checks: Before and after each borrow, the system validates that the user's health factor remains above the minimum threshold.

Borrow Operation Flow:

• Accrue interest on both reserve (to update rates) and obligation (to account for existing debt growth)
• Validate borrowing power exceeds requested amount
• Check reserve hasn't exceeded utilization limits
• Execute token transfer from reserve to user
• Update obligation's debt tracking with current cumulative borrow rate
• Recalculate and validate health factor post-operation

Health Factor Calculation: The health factor determines liquidation risk:

Where:

• $\text{collateralValue} = \sum (\text{collateralAmount}_i \times \text{price}_i)$
• $\text{borrowedValue} = \sum (\text{borrowedAmount}_j \times \text{price}_j)$
• $\text{ltvRatio} = \text{loan-to-value ratio per asset (0-1)}$

4. Liquidation System: Incentive-Driven Solvency​

Liquidation is the protocol's self-healing mechanism, allowing third-party actors to restore under-collateralized positions to health by repaying debt in exchange for discounted collateral.

Trigger Conditions:

• Health factor falls below 1.0 (typically triggered by collateral price drops or borrow rate increases)
• Position becomes mathematically insolvent when debt value exceeds collateral value adjusted for LTV

Economic Incentive Structure:

1. Liquidation Bonus: Liquidators receive a percentage bonus (e.g., 5-10%) on the collateral value they seize, compensating for gas costs, price execution risk, and market making.

2. Partial Liquidations: Most protocols limit single liquidation amounts (close factor of 50%) to prevent excessive slippage and give borrowers a chance to add collateral.

3. Dutch Auction Potential: Some implementations use declining bonuses over time to optimize protocol value capture.

System Protection Mechanisms:

• Oracle Validation: Multiple price sources prevent manipulation-based fake liquidations
• Slippage Bounds: Maximum collateral withdrawal per transaction prevents reserve depletion
• Reserve Insurance: Protocol retains a portion of liquidation proceeds as bad debt insurance

Liquidation Flow:

1. External actor identifies under-collateralized position
2. Liquidator repays portion of user's debt to the reserve
3. System calculates collateral owed based on repayment amount, asset prices, and liquidation bonus
4. Collateral transfers to liquidator at discount
5. Obligation updates with reduced debt and collateral
6. If health factor restored above threshold, position remains open; otherwise, additional liquidations possible

Interest Rate Architecture​

Utilization-Based Rate Model​

Kamino implements a kinked interest rate curve that dynamically adjusts based on capital utilization, balancing supply and demand while preventing excessive leverage.

Rate Curve Design:

Borrow Rate |
            |              /
   Max      |            /
            |          /  (Steep slope)
            |        /
   Optimal  |------/
            |    /  (Gradual slope)
   Min      |  /
            |/________________
            0%    80%    100%  Utilization

Economic Rationale:

1. Below Optimal Utilization (0-80%):

   • Gradual rate increase encourages borrowing
   • Low rates attract borrowers when liquidity is abundant
   • Prevents capital from sitting idle

2. Above Optimal Utilization (80-100%):

   • Steep rate increase protects lender liquidity
   • High rates incentivize debt repayment
   • Discourages excessive leverage during high utilization

Compound Interest Accrual:

The protocol uses continuous compound interest with per-slot precision:

Where:

• $C_t$ = cumulative borrow rate at time $t$
• $C_0$ = cumulative borrow rate at time $0$
• $r$ = periodic rate (borrow rate per slot)
• $\Delta t$ = slots elapsed

Each user's debt grows proportionally to the cumulative rate, ensuring fair interest distribution across all borrowers regardless of when they entered positions.

State Management Architecture​

Obligation Account Design​

The Obligation account represents a user's complete position across the lending protocol, aggregating all collateral deposits and outstanding loans.

Account Structure Philosophy:

• Single Account Per User: One obligation account per lending market simplifies account management and enables atomic cross-collateral operations
• Dynamic Arrays: Variable-length vectors for deposits and borrows allow users to interact with multiple reserves without account reallocation
• Cached Computations: Health factor and market values cached with timestamps to avoid redundant oracle reads

State Transitions:

┌─────────────────────┐
│  Obligation Created │
│  (Empty)            │
└──────────┬──────────┘
           │
           ▼
   ┌───────────────┐
   │  Add Deposit  │ ──────┐
   └───────┬───────┘       │
           │               │
           ▼               │
   ┌───────────────┐       │
   │  Borrow Asset │       │
   └───────┬───────┘       │
           │               │
     ┌─────▼────────┐      │
     │  Monitoring  │◄─────┘
     │  (Active)    │
     └──┬───────┬───┘
        │       │
        │       └──────────┐
        │                  ▼
        │         ┌────────────────┐
        │         │  Liquidation   │
        │         │  (if HF < 1.0) │
        │         └────────┬───────┘
        │                  │
        ▼                  ▼
 ┌──────────────┐   ┌─────────────┐
 │ Repay + Exit │   │  Restored   │
 └──────────────┘   └─────────────┘

Health Factor Calculation Architecture:

The health factor aggregates risk across all positions:

1. Collateral Valuation: Each deposit multiplied by its asset price and LTV ratio
2. Debt Valuation: Each borrow multiplied by its asset price and accrued interest
3. Risk-Adjusted Ratio: Total weighted collateral divided by total debt

A health factor below 1.0 indicates technical insolvency and triggers liquidation eligibility.

Solana-Specific Design Patterns​

Account Model Optimization​

Fixed-Size Account Design:

Kamino optimizes for Solana's account-based model by using predictable account sizes:

• Reserve Accounts: ~400 bytes with fixed-size configuration structs
• Obligation Accounts: Dynamic sizing with capacity limits (max 10 deposits, 5 borrows)
• Market Accounts: Global configuration with reserve registry

Benefits:

• Predictable rent costs
• Efficient reallocation patterns
• Reduced compute units for account validation

Compute Unit Management​

The protocol implements several strategies to minimize compute consumption:

1. Early Returns: Simple validation checks before expensive operations
2. Batched Operations: Combine multiple token transfers in single CPI calls
3. Lazy Interest Accrual: Only update rates when users interact, not globally
4. Cached Oracle Reads: Store price data with timestamps to avoid redundant oracle calls within the same slot

Cross-Program Invocation Architecture​

Token Program Abstraction:

Supports both SPL Token and Token-2022 programs through a unified interface:

• Dynamic Program Detection: Checks token mint's owner to determine program version
• Fee Handling: Token-2022 transfer fees automatically calculated and accounted
• Extension Support: Compatible with interest-bearing tokens and other Token-2022 features

Authority Patterns:

• PDA Signers: All token operations use PDAs as signers, eliminating private key management
• Seed Derivation: Deterministic PDA generation enables permissionless interactions
• Authority Hierarchy: Multi-tier access control with admin, operator, and user roles

Security Architecture​

Multi-Layer Access Control​

The protocol implements defense-in-depth with hierarchical permissions:

Authority Tiers:

1. Protocol Owner: Can update global parameters, add new reserves, emergency pause
2. Market Authority: Manages individual market configurations and risk parameters
3. Reserve Manager: Adjusts interest rate models and asset-specific settings
4. Emergency Guardian: Limited to circuit breaker activation only

Time-Locked Operations:

Critical parameter changes require a multi-step process:

• Proposal Creation: Admin proposes parameter change
• Timelock Period: Mandatory waiting period (e.g., 24-48 hours)
• Execution Window: Limited window after timelock to execute
• Cancellation Rights: Separate guardian can veto dangerous changes

This prevents malicious or accidental instant changes to critical parameters like liquidation thresholds or interest rate curves.

Oracle Security Framework​

Multi-Oracle Support:

The architecture supports multiple oracle providers (Pyth, Switchboard, Chainlink) with:

• Primary/Secondary Validation: Cross-check prices between two independent sources
• Deviation Thresholds: Reject prices that differ by more than acceptable bounds
• Staleness Checks: Enforce maximum age for price data
• Confidence Intervals: Validate oracle-reported confidence levels

Price Manipulation Protection:

• TWAP Integration: Time-weighted average prices smooth out flash crashes
• Circuit Breakers: Halt operations if price volatility exceeds thresholds
• Reserve-Level Config: Each asset has its own oracle security parameters

Economic Security Mechanisms​

Circuit Breakers:

Automatic safeguards trigger during extreme conditions:

• High Volatility: Restrict borrowing when asset prices fluctuate rapidly
• Critical Utilization: Limit withdrawals when reserves approach depletion
• Oracle Failure: Gracefully degrade to safe state if price feeds unavailable
• Bad Debt Accumulation: Emergency shutdown if protocol becomes insolvent

Gradual Limits:

Rather than hard cutoffs, the protocol implements smooth degradation:

• Borrowing limits decrease proportionally as utilization approaches maximum
• Liquidation bonuses increase as health factors deteriorate
• Interest rates accelerate non-linearly at extreme utilization

This prevents sudden state changes and gaming around threshold boundaries.

Integration Architecture​

Client-Side Design Patterns​

PDA Derivation Strategy:

Clients must derive the same PDAs as the on-chain program to construct transactions:

• Deterministic Address Generation: Seeds must match exactly (lending market ID, mint address, user wallet)
• Bump Seed Caching: Store bump seeds after first derivation to avoid recomputation
• Account Validation: Always verify derived PDAs match expected program-owned accounts

Transaction Construction:

Typical interaction flow:

1. Fetch On-Chain State: Read current reserve and obligation data
2. Compute Off-Chain: Calculate expected outcomes (cTokens minted, health factor after borrow)
3. Derive Accounts: Generate all required PDAs
4. Build Instruction: Construct transaction with correct account order
5. Simulate First: Always simulate before sending to detect issues
6. Send and Confirm: Submit transaction and wait for confirmation

Health Factor Monitoring​

Continuous Position Monitoring:

Applications should implement:

• WebSocket Subscriptions: Listen for obligation account changes
• Oracle Price Tracking: Monitor collateral price movements
• Alert Thresholds: Warn users when health factor approaches liquidation
• Auto-Rebalancing: Optionally implement automated deleveraging

Risk Management Integration:

• Display health factor prominently in UI
• Show liquidation price for each collateral asset
• Provide safety margins (e.g., recommend 150%+ health factor)
• Enable one-click position closing during volatility

Extensibility and Composability​

Extension Points​

The architecture provides several extension mechanisms:

1. New Collateral Types

Adding support for new assets requires:

• Initializing a new reserve with appropriate risk parameters
• Configuring oracle integration for price feeds
• Setting LTV ratios, liquidation thresholds, and interest models
• Optional: Custom logic for exotic token types (rebase tokens, yield-bearing assets)

2. Advanced Financial Primitives

Flash Loans: Atomically borrow without collateral within a single transaction:

• Borrow assets from reserve
• Execute arbitrary logic (arbitrage, collateral swaps, etc.)
• Repay loan + fee before transaction completes
• If repayment fails, entire transaction reverts

Key Design:

• Callback mechanism allows user-defined operations
• Fee structure incentivizes liquidity provision
• Atomicity guarantees protocol safety

Isolated Markets: Create separate lending markets with different risk profiles:

• Blue-chip assets with conservative parameters
• Experimental tokens with higher collateral requirements
• Stablecoin-only markets for capital efficiency

3. Strategy Integrations

Higher-order protocols can build on lending primitives:

• Leveraged Yield Farming: Loop deposits and borrows for amplified yields
• Delta-Neutral Strategies: Short via borrowing while holding spot positions
• Automated Vaults: Manage user positions with algorithmic rebalancing
• Portfolio Optimization: Automatically adjust allocations based on rates

System Validation Strategies​

Testing Dimensions:

1. Economic Correctness:

• Interest accrual over extended periods
• Exchange rate calculations under various utilization levels
• Health factor updates with multiple collateral/borrow positions
• Liquidation math verification

2. State Invariants:

• Total cTokens supply equals sum of user balances
• Reserve liquidity matches vault balance minus borrowed amount
• Sum of all health factors remains non-negative
• Interest never decreases over time

3. Edge Cases:

• Maximum utilization scenarios
• Oracle price extremes (sudden crashes, stale data)
• Concurrent operations on same obligation
• Token account edge cases (zero balance, closed accounts)

4. Security Scenarios:

• Unauthorized access attempts
• Manipulation via price oracle gaming
• Flash loan attack vectors
• Reentrancy patterns

Simulation-Based Testing:

• Monte Carlo simulations with random market conditions
• Stress testing with historical volatility data
• Fuzz testing with random input combinations
• Long-running scenarios (millions of slots)

Conclusion​

The Kamino Lend architecture exemplifies production-grade DeFi protocol design on Solana, demonstrating how to build secure, scalable, and composable financial infrastructure. Its success managing over $2.68B in TVL validates the architectural decisions across multiple dimensions.

Key Architectural Principles​

1. Risk Isolation Through Reserve Design: Each asset operates independently with its own parameters, preventing systemic contagion while enabling tailored risk management.

2. Share-Based Accounting: The cToken model elegantly handles proportional interest distribution and enables composability with other DeFi protocols.

3. Health Factor as Central Invariant: A single, continuously monitored metric ensures system solvency while providing users with clear risk visibility.

4. Incentive Alignment: Liquidators, lenders, and borrowers all have economic incentives that maintain protocol stability without relying on centralized actors.

5. Defensive Design: Multiple layers of validation, circuit breakers, time-locks, and oracle security create resilience against edge cases and attacks.

Architectural Lessons for Builders​

For Protocol Developers:

• Design account structures for predictable costs and efficient operations
• Build mathematical models with fixed-point arithmetic precision
• Implement gradual degradation rather than hard cutoffs
• Create extension points for future features without compromising core security

For Integrators:

• Understand PDA derivation patterns for reliable transaction construction
• Monitor on-chain state continuously for position management
• Implement robust error handling for network instability
• Design UIs that make risk transparent to end users

For Auditors:

• Verify mathematical correctness of interest and health calculations
• Test state invariants under extreme market conditions
• Validate oracle security and manipulation resistance
• Check access control at every privilege boundary

Future Evolution​

The architecture is designed to evolve:

• Support for new collateral types (LSTs, yield-bearing assets, RWAs)
• Cross-chain integration via bridges and messaging protocols
• Advanced rate models incorporating external market signals
• Governance-driven parameter optimization based on empirical data

Kamino Lend demonstrates that Solana's account model, when properly architected, can support complex financial logic at scale. The protocol serves as both a critical infrastructure piece for Solana DeFi and a reference implementation for builders creating the next generation of on-chain financial systems.

This architectural analysis focuses on design patterns and system structure. For implementation details and deployment instructions, consult the official Kamino documentation and audited source code.

TL;DR​

• Raydium AMM is a hybrid decentralized exchange combining AMM liquidity pools with Serum's central limit order book (CLOB) for deeper liquidity and tighter spreads
• This Anchor-based adapter smart contract enables seamless interaction with Raydium's non-Anchor programs using Cross-Program Invocations (CPI)
• Core implementation focuses on swap functionality through CPI to Raydium's main AMM program, handling complex account validation and state transitions
• Account architecture utilizes PDAs for routing, token vault management, and fee collection with deterministic address derivation
• Key Anchor patterns demonstrated include: CPI with non-Anchor programs, complex account validation, PDA-based routing, and token account management

Introduction​

Raydium AMM represents a sophisticated evolution of decentralized exchange design on Solana, merging traditional automated market maker (AMM) liquidity pools with Serum's central limit order book. This hybrid model enables both passive liquidity provision and active market making strategies, creating deeper liquidity and tighter spreads than pure AMM designs.

This article focuses on an Anchor-based adapter smart contract that interfaces with Raydium's native (non-Anchor) programs. The adapter implements essential DeFi primitives—primarily swap operations—through cross-program invocations (CPI), managing complex account relationships and state validation. While Raydium's core programs are written in raw Rust, this adapter demonstrates how to build maintainable, secure interfaces using Anchor's framework.

Architecture Overview​

Raydium's architecture follows a modular design where the Anchor adapter serves as an entry point, delegating core logic to Raydium's optimized non-Anchor programs. This separation allows:

1. Adapter Layer: User-friendly Anchor interface with simplified account management
2. Core AMM Logic: High-performance swap execution in Raydium's native program
3. Order Book Integration: Real-time price discovery through Serum DEX

Account Structure Diagram​

Account Structure​

The adapter manages complex account relationships, validating each account's constraints before delegating to Raydium's core program.

Primary Accounts Table​

| Account | Type | Purpose | Validation |

|---------|------|---------|------------|

| user | Signer | Transaction signer, pays fees | mut, signer |

| adapter_state | PDA | Adapter configuration and fee tracking | mut, seeds = [b"adapter", program_id] |

| raydium_program | Executable | Raydium's main AMM program ID | address = RAYDIUM_AMM_ID |

| pool | State | Raydium pool account (reserves, fees) | mut |

| pool_authority | PDA | Controls pool's token vaults | seeds = [pool.key().as_ref(), b"authority"] |

| token_vault_a | Token Account | Pool's reserve for token A | mut |

| token_vault_b | Token Account | Pool's reserve for token B | mut |

| user_token_a | Token Account | User's source token account | mut |

| user_token_b | Token Account | User's destination token account | mut |

| token_program | Executable | SPL Token program | address = TOKEN_PROGRAM_ID |

| system_program | Executable | System program | address = SYSTEM_PROGRAM_ID |

| serum_market | State | Serum order book market | mut |

Adapter State PDA Structure​

#[account]
#[derive(Default)]
pub struct AdapterState {
    /// Bump seed for PDA derivation
    pub bump: u8,
    /// Total swap volume processed through adapter
    pub total_volume: u64,
    /// Fee basis points collected by adapter (0-10000)
    pub fee_bps: u16,
    /// Total fees collected
    pub fees_collected: u64,
    /// Owner with upgrade privileges
    pub owner: Pubkey,
    /// Whether adapter is paused
    pub is_paused: bool,
}

impl AdapterState {
    pub const LEN: usize = 8 + // discriminator
        1 + // bump
        8 + // total_volume
        2 + // fee_bps
        8 + // fees_collected
        32 + // owner
        1; // is_paused
}

## Instruction Handlers Deep Dive

### Core Swap Instruction

The swap instruction implements the primary trading functionality, validating all accounts and delegating to Raydium via CPI.

```rust
#[derive(Accounts)]
pub struct Swap<'info> {
    #[account(mut)]
    pub user: Signer<'info>,
    
    #[account(
        mut,
        seeds = [b"adapter", program_id.as_ref()],
        bump = adapter_state.bump,
        constraint = !adapter_state.is_paused @ AdapterError::AdapterPaused
    )]
    pub adapter_state: Account<'info, AdapterState>,
    
    /// CHECK: Validated by constraint against known Raydium program ID
    #[account(address = RAYDIUM_AMM_ID)]
    pub raydium_program: AccountInfo<'info>,
    
    #[account(mut)]
    /// CHECK: Raydium validates this account
    pub pool: AccountInfo<'info>,
    
    #[account(
        seeds = [pool.key().as_ref(), b"authority"],
        bump
    )]
    /// CHECK: PDA authority for pool vaults
    pub pool_authority: AccountInfo<'info>,
    
    #[account(mut)]
    /// CHECK: Validated by Raydium program
    pub token_vault_a: AccountInfo<'info>,
    
    #[account(mut)]
    /// CHECK: Validated by Raydium program
    pub token_vault_b: AccountInfo<'info>,
    
    #[account(
        mut,
        constraint = user_token_a.owner == user.key() @ AdapterError::InvalidTokenOwner
    )]
    pub user_token_a: Account<'info, TokenAccount>,
    
    #[account(mut)]
    pub user_token_b: Account<'info, TokenAccount>,
    
    pub token_program: Program<'info, Token>,
    pub system_program: Program<'info, System>,
    
    /// CHECK: Serum market account for price reference
    #[account(mut)]
    pub serum_market: AccountInfo<'info>,
}

#[derive(AnchorSerialize, AnchorDeserialize)]
pub struct SwapArgs {
    /// Amount of token A to swap (max to spend)
    pub amount_in: u64,
    /// Minimum amount of token B to receive (slippage protection)
    pub min_amount_out: u64,
    /// Referral fee destination (optional)
    pub referral_account: Option<Pubkey>,
}

The swap execution involves several key mathematical operations for fee calculation and slippage protection:

**Effective Input Amount Calculation** (after adapter fees):
```latex
$$dx_{eff} = dx \cdot (1 - f_{adapter})$$

Where $dx$ is the input amount and $f_{adapter}$ is the adapter fee in basis points.

**Raydium's Swap Formula** (simplified constant product with order book integration):
```latex
$$dy = \begin{cases} 
\frac{y \cdot dx_{eff}}{x + dx_{eff}} & \text{if AMM only} \\
\text{CLOB\_FILL} + \text{AMM\_FILL} & \text{hybrid execution}
\end{cases}$$

**Slippage Validation**:
```latex
$$dy_{actual} \ge dy_{min}$$

Where $dy_{min}$ is the user-specified minimum output.

### Implementation Details

```rust
pub fn swap(ctx: Context<Swap>, args: SwapArgs) -> Result<()> {
    let adapter_state = &mut ctx.accounts.adapter_state;
    
    // Calculate adapter fee (if any)
    let fee_amount = if adapter_state.fee_bps > 0 {
        args.amount_in
            .checked_mul(adapter_state.fee_bps as u64)
            .ok_or(AdapterError::MathOverflow)?
            .checked_div(10000)
            .ok_or(AdapterError::MathOverflow)?
    } else {
        0
    };
    
    let effective_amount_in = args.amount_in
        .checked_sub(fee_amount)
        .ok_or(AdapterError::InvalidFeeCalculation)?;
    
    // Update adapter statistics
    adapter_state.total_volume = adapter_state.total_volume
        .checked_add(args.amount_in)
        .ok_or(AdapterError::MathOverflow)?;
    
    adapter_state.fees_collected = adapter_state.fees_collected
        .checked_add(fee_amount)
        .ok_or(AdapterError::MathOverflow)?;
    
    // Prepare CPI to Raydium
    let raydium_program = ctx.accounts.raydium_program.to_account_info();
    let cpi_accounts = raydium::cpi::accounts::Swap {
        pool: ctx.accounts.pool.clone(),
        pool_authority: ctx.accounts.pool_authority.clone(),
        token_vault_a: ctx.accounts.token_vault_a.clone(),
        token_vault_b: ctx.accounts.token_vault_b.clone(),
        user_token_a: ctx.accounts.user_token_a.to_account_info(),
        user_token_b: ctx.accounts.user_token_b.to_account_info(),
        serum_market: ctx.accounts.serum_market.clone(),
        token_program: ctx.accounts.token_program.to_account_info(),
    };
    
    let cpi_args = raydium::instruction::Swap {
        amount_in: effective_amount_in,
        min_amount_out: args.min_amount_out,
    };
    
    // Execute CPI to Raydium
    let cpi_ctx = CpiContext::new(raydium_program, cpi_accounts);
    raydium::cpi::swap(cpi_ctx, cpi_args)?;
    
    emit!(SwapEvent {
        user: ctx.accounts.user.key(),
        amount_in: args.amount_in,
        fee_amount,
        timestamp: Clock::get()?.unix_timestamp,
    });
    
    Ok(())
}

### Instruction Flow Diagram

```mermaid
sequenceDiagram
    participant U as User
    participant A as Anchor Adapter
    participant R as Raydium AMM
    participant T as Token Program
    participant S as Serum

    U->>A: swap(amount_in, min_amount_out)
    Note over A: Validate all accounts
    Note over A: Calculate adapter fees
    Note over A: Update adapter state
    
    A->>R: CPI: swap(effective_amount_in, min_amount_out)
    R->>S: Query order book for best price
    S-->>R: Return available liquidity
    
    alt Order book has liquidity
        R->>T: Transfer from Serum vaults
    else Use AMM liquidity
        R->>T: Transfer from AMM vaults
    end
    
    Note over R: Execute hybrid swap logic
    R->>T: Transfer tokens to user
    T-->>R: Confirm transfer success
    R-->>A: Return swap result
    A->>A: Emit SwapEvent
    A-->>U: Transaction complete