Security & Access Control - Multiliquid Protocol

Security Overview

The Multiliquid Program is built with institutional-grade security as a core requirement. Every instruction, account validation, and state transition has been designed with security-first principles, incorporating multiple layers of protection and comprehensive access controls.

Program Security

Anchor framework and secure coding practices

Access Control

Multi-tiered permission model

Pause Controls

Multi-level emergency pause capabilities

Admin Transfer

Secure admin handover mechanism

Program Security

Anchor Framework

The program is built exclusively using the Anchor framework, providing: Type Safety:

Automatic account serialization and deserialization
Compile-time account constraint validation
Strong typing for all instruction parameters

Account Validation:

Owner checks on typed accounts; unchecked and remaining accounts require explicit validation
PDA derivation verification via seeds constraints
has_one constraints for relationship validation

Security Features:

Built-in discriminator checks to prevent account confusion
Automatic rent-exemption verification
Safe arithmetic operations with checked math

Core Security Mechanisms

1. Program-Derived Addresses (PDAs)

All program accounts are derived deterministically using PDAs:

// Example: Pair account derivation
#[account(
    seeds = [
        PAIR_PREFIX,
        liquidity_provider.key().as_ref(),
        quote_token_mint_address.key().as_ref(),
        base_token_mint_address.key().as_ref()
    ],
    bump = pair.bump,
)]
pub pair: Account<'info, Pair>,

Security Benefits:

Accounts cannot be spoofed or substituted
Deterministic derivation enables verification
No external account addresses stored unnecessarily

Capital provider liquidity vaults use an additional authority separation:

// Capital provider vault authority derivation
#[account(
    seeds = [VAULT_AUTHORITY_PREFIX, liquidity_provider.key().as_ref()],
    bump,
)]
pub lp_vault_authority: UncheckedAccount<'info>,

Vault token accounts are associated token accounts owned by this capital provider’s vault_authority PDA. The global program_authority PDA is reserved for protocol fee vaults, so one capital provider’s vault authority cannot sign for another capital provider’s liquidity.

2. Signer Validation

All privileged operations require appropriate signatures:

// Admin-only operation
#[account(
    has_one = admin,
)]
pub global_config: Account<'info, GlobalConfig>,
pub admin: Signer<'info>,

// Operation restricted to the capital provider
#[account(
    has_one = liquidity_provider,
)]
pub pair: Account<'info, Pair>,
pub liquidity_provider: Signer<'info>,

3. Integer Overflow Protection

All arithmetic operations use checked math:

// Safe multiplication with overflow check
let result = amount
    .checked_mul(price)
    .ok_or(ErrorCode::MathOverflow)?;

// Safe division with zero check
let output = numerator
    .checked_div(denominator)
    .ok_or(ErrorCode::MathOverflow)?;

4. Input Validation

Every instruction validates inputs before execution:

Amounts must be greater than zero
Basis points must be within valid range (0-9900)
Pair redemption and discount fees must sum to less than 10000 BPS
NAV sources must have valid decimals (0-9)
Asset types must match expected values

Token Security

SPL Token Integration

The program uses Anchor’s SPL token helpers for safe token operations:

// Safe token transfer using CPI (checked variant)
transfer_checked(
    CpiContext::new(
        token_program.to_account_info(),
        TransferChecked {
            from: user_token_account.to_account_info(),
            to: vault.to_account_info(),
            authority: user.to_account_info(),
            mint: mint.to_account_info(),
        },
    ),
    amount,
    decimals,
)?;

Security Features:

Automatic account ownership validation
Mint address verification
Sufficient balance checks

Token-2022 Support

The program supports both SPL Token and Token-2022:

Automatic program detection based on mint owner
Compatible with Token-2022 extensions
Safe handling of both token standards

Access Control System

The program implements a sophisticated multi-tier permission model:

Admin Role

Holder: GlobalConfig.admin Permissions:

Operation	Description
`init_global_config`	Initialize program configuration (one-time)
`update_global_config`	Update fees, fee wallet, pause state
`set_new_admin`	Propose new admin address
`confirm_new_admin`	Accept admin role (new admin)
`init_asset_config_account`	Register new tokens
`update_asset_config_account`	Update token NAV sources
`set_lp_protocol_fee_config`	Set capital provider protocol-fee overrides
`set_paused_for_asset`	Pause/unpause assets
`set_paused_for_lp_stable_config`	Pause/unpause capital provider configs

Security Considerations:

Admin should be a multi-signature wallet
Two-step transfer prevents accidental handover
Swap program starts paused by default

Capital Provider Role

Holder: Address specified as liquidity_provider in pair creation Permissions:

Operation	Description
`init_pair`	Create trading pairs
`update_pair`	Configure fees and pause state
`close_pair`	Permanently close a pair
`add_liquidity`	Deposit tokens to vault
`remove_liquidity`	Withdraw tokens from vault
`set_paused_for_lp_stable_config`	Pause own capital provider config
`set_lp_treasury_enabled`	Enable or disable own Treasury routing
`close_lp_fee_account`	Close own protocol-fee token account
`close_treasury_position`	Close own empty Treasury position

Security Considerations:

Each capital provider controls only their own pairs
Cannot affect other capital providers’ configurations
Pair pause state defaults to unpaused at creation, and capital providers can pause or unpause their own pairs with update_pair

User Role (Permissionless)

Holder: Any wallet Permissions:

Operation	Description
`swap`	Execute token swaps
`claim_fees`	Trigger fee distribution to fee wallet

Security Considerations:

Swaps validated against multiple pause states
Slippage protection via min/max amount parameters
Fees always sent to configured fee wallet (not caller)

Treasury Roles

The Treasury program has separate permissions:

Role	Permissions
Manager	Configure Treasury and supported assets, pause deposits/redemptions, manage vault balances, and update user yield
Oracle authority	Post daily rates, subject to the configured APY limit
User	Deposit, redeem, and close an empty position; interest accrual can be triggered by any caller

Manager transfer uses set_pending_manager followed by accept_manager. The manager and the program upgrade authority are separate roles.

Pause Control System

The program implements a comprehensive four-level pause system:

Pause Hierarchy

Level 1: Global Pause

Controlled by: Admin via update_global_config Effects:

Blocks ALL swap operations
Blocks liquidity operations
Blocks fee claims
Global configuration, asset pause, and capital provider pause controls remain accessible; update_pair requires an unpaused program

Use Cases:

Emergency halt during security incident
Program maintenance or upgrade preparation
Regulatory requirement

Level 2: Asset Pause

Controlled by: Admin via set_paused_for_asset Effects:

Blocks swaps involving this specific asset
Other assets remain operational
Affects all pairs using this asset

Use Cases:

Token-specific security issue
NAV oracle malfunction
Compliance requirement for specific asset

Level 3: Capital Provider Stable Config Pause

Controlled by: Admin OR capital provider via set_paused_for_lp_stable_config Effects:

Blocks all pairs for this capital provider/stablecoin combination
Other capital providers unaffected
Other stablecoins for same capital provider unaffected

Use Cases:

Capital provider operational issue
Stablecoin-specific concern for one capital provider
Capital provider maintenance period

Level 4: Pair Pause

Controlled by: Capital provider via update_pair Effects:

Blocks only this specific trading pair
All other pairs remain operational

Use Cases:

Liquidity rebalancing
Fee adjustment period
Individual pair maintenance

Swap Validation

Every swap validates all applicable pause levels, including the configured fee asset:

// Pause checks in swap instruction
require!(!global_config.paused, ErrorCode::ProgramPaused);
require!(!pair.paused, ErrorCode::PairPaused);
require!(!base_config.paused, ErrorCode::RwaPaused);
require!(!quote_config.paused, ErrorCode::StablePaused);
require!(!fee_config.paused, ErrorCode::FeeAssetPaused);
// Each Stable side requires its capital provider config; RWA sides do not.
for config in [lp_stable_config_quote, lp_stable_config_base].into_iter().flatten() {
    require!(!config.paused, ErrorCode::StablePaused);
}

If ANY level is paused, the swap is rejected. Treasury has independent global and asset pause flags. A Treasury CPI must also pass those checks. Swap remove_liquidity does not check swap asset or capital provider stable pause flags, but still requires an unpaused swap program and, when redeeming, an unpaused Treasury program and asset.

Two-Step Admin Transfer

The program implements a secure two-step admin transfer mechanism to prevent accidental or malicious admin handover:

Step 1: Propose New Admin

Current admin calls set_new_admin:

pub fn set_new_admin(
    ctx: Context<SetNewAdmin>,
    new_admin: Pubkey,
) -> Result<()>

Effects:

Sets pending_new_admin to proposed address
Current admin remains in control
No immediate transfer occurs

Step 2: Confirm New Admin

New admin calls confirm_new_admin:

pub fn confirm_new_admin(
    ctx: Context<ConfirmNewAdmin>,
) -> Result<()>

Requirements:

Caller must match pending_new_admin
Caller must sign the transaction

Effects:

admin updated to new address
pending_new_admin cleared
Transfer complete

Security Benefits

No Accidental Transfer: Typo in address won’t transfer control
Recipient Verification: New admin must actively accept
Revocable: Current admin can propose different address before confirmation

Error Handling

The program defines comprehensive error codes for security validation:

#[error_code]
pub enum ErrorCode {
    #[msg("Unauthorized")]
    Unauthorized,

    #[msg("Program paused")]
    ProgramPaused,

    #[msg("Pair paused")]
    PairPaused,

    #[msg("RWA paused")]
    RwaPaused,

    #[msg("Stable paused")]
    StablePaused,

    #[msg("Invalid NAV")]
    InvalidNav,

    #[msg("Math Overflow")]
    MathOverflow,

    #[msg("Math Underflow")]
    MathUnderflow,

    #[msg("Insufficient liquidity")]
    InsufficientLiquidity,

    #[msg("Amount in too high")]
    AmountInTooHigh,

    #[msg("Amount out too low")]
    AmountOutTooLow,

    #[msg("Fees out of range")]
    FeesOutOfRange,

    #[msg("Price decimals too large")]
    PriceDecimalsTooLarge,

    // ... additional validation and operational error codes
}

Operational Security Best Practices

For institutions integrating with the program:

Key Management

Use Hardware Wallets: For all signing operations
Multi-Signature: Admin should be a multi-sig wallet
Key Rotation: Periodic admin transfer to fresh keys
Backup Procedures: Secure backup of all signing keys

Transaction Security

Simulation: Use Solana’s transaction simulation before signing
Verification: Double-check all account addresses
Priority Fees: Set appropriate priority fees for time-sensitive operations
Recent Blockhash: Use recent blockhashes to prevent replay

Monitoring

Event Tracking: Monitor program events for all state changes
Balance Monitoring: Track capital provider vault ATAs and protocol fee vault balances separately
Pause State: Alert on any pause state changes
Admin Changes: Alert on admin transfer initiation

Known Limitations and Assumptions

Token Compatibility

The program assumes:

Tokens follow SPL Token or Token-2022 standards
Tokens do not have transfer fees that break atomicity
NAV oracles remain available and accurate
Token decimals are correctly configured

Price Oracle Assumptions

NAV sources return valid prices within configured decimals
Price divergence threshold is appropriately set
At least one NAV source is always available
Pyth oracle accounts are correctly configured

Operational Assumptions

Admin wallet is secure and properly managed
Capital providers manage their liquidity appropriately
Fee vault balances are claimed periodically
Pairs are closed properly before decommissioning

Security Contacts

For security vulnerabilities or concerns:

DO NOT disclose security vulnerabilities publicly. Contact the Multiliquid team directly through secure channels.

Website: https://www.multiliquid.xyz/

This security documentation is a living document and will be updated as the program evolves and new security measures are implemented.

Next: Swap Instruction

Explore the main swap instruction managing all trading operations

​Security Overview

Program Security

Access Control

Pause Controls

Admin Transfer

​Program Security

​Anchor Framework

​Core Security Mechanisms

​1. Program-Derived Addresses (PDAs)

​2. Signer Validation

​3. Integer Overflow Protection

​4. Input Validation

​Token Security

​SPL Token Integration

​Token-2022 Support

​Access Control System

​Admin Role

​Capital Provider Role

​User Role (Permissionless)

​Treasury Roles

​Pause Control System

​Pause Hierarchy

​Level 1: Global Pause

​Level 2: Asset Pause

​Level 3: Capital Provider Stable Config Pause

​Level 4: Pair Pause

​Swap Validation

​Two-Step Admin Transfer

​Step 1: Propose New Admin

​Step 2: Confirm New Admin

​Security Benefits

​Error Handling

​Operational Security Best Practices

​Key Management

​Transaction Security

​Monitoring

​Known Limitations and Assumptions

​Token Compatibility

​Price Oracle Assumptions

​Operational Assumptions

​Security Contacts

Next: Swap Instruction

Security Overview

Program Security

Anchor Framework

Core Security Mechanisms

1. Program-Derived Addresses (PDAs)

2. Signer Validation

3. Integer Overflow Protection

4. Input Validation

Token Security

SPL Token Integration

Token-2022 Support

Access Control System

Admin Role

Capital Provider Role

User Role (Permissionless)

Treasury Roles

Pause Control System

Pause Hierarchy

Level 1: Global Pause

Level 2: Asset Pause

Level 3: Capital Provider Stable Config Pause

Level 4: Pair Pause

Swap Validation

Two-Step Admin Transfer

Step 1: Propose New Admin

Step 2: Confirm New Admin

Security Benefits

Error Handling

Operational Security Best Practices

Key Management

Transaction Security

Monitoring

Known Limitations and Assumptions

Token Compatibility

Price Oracle Assumptions

Operational Assumptions

Security Contacts