Security & Risk Management - Multiliquid Protocol

Security Overview

The Multiliquid Protocol is built with institutional-grade security as a core requirement. Every contract, function, and integration point has been designed with security-first principles, incorporating multiple layers of protection, comprehensive access controls, and battle-tested frameworks.

Smart Contract Security

OpenZeppelin frameworks and secure coding practices

Access Control

Multi-tiered role-based permission model

Risk Management

Asset-specific controls and volume limits

Emergency Response

Pause capabilities and incident response

Smart Contract Security

Industry-Standard Frameworks

The protocol is built exclusively using audited, production-tested libraries: OpenZeppelin Upgradeable Contracts

Usage: Access control, proxy patterns, reentrancy protection, safe external operations
Security: Industry-standard, extensively audited by multiple firms
Key Modules:
- AccessControlUpgradeable: Role-based permissions
- UUPSUpgradeable: Secure upgrade mechanism
- ReentrancyGuardUpgradeable: Reentrancy attack prevention
- PausableUpgradeable: Emergency pause functionality

Solady

Usage: Gas-optimized mathematical operations
Security: Extensively tested, overflow-safe operations
Key Module: FixedPointMathLib for WAD/RAY mathematics

Core Security Mechanisms

1. Reentrancy Protection

All external-facing functions that involve token transfers are protected against reentrancy attacks:

function swapIntoStablecoin(...) external nonReentrant whenNotPaused {
    // Checks
    require(validInputs, "Invalid parameters");

    // Effects
    updateInternalState();

    // Interactions
    executeExternalCalls();
}

The protocol follows the Checks-Effects-Interactions pattern rigorously:

Checks: Validate all inputs and preconditions
Effects: Update all internal state
Interactions: Execute external calls (transfers, delegate calls)

2. SafeERC20 Operations

All ERC20 token interactions use OpenZeppelin’s SafeERC20 library:

Handles non-standard ERC20 implementations
Reverts on failed transfers (even if token returns false)
Protects against tokens with unusual return values

using SafeERC20 for IERC20;

// Safe transfer with automatic revert on failure
IERC20(rwaToken).safeTransferFrom(user, custody, amount);

3. Integer Overflow Protection

Solidity 0.8.30: Built-in overflow/underflow protection
Checked Arithmetic: All operations automatically revert on overflow
WAD Mathematics: Consistent 18-decimal precision prevents rounding errors

4. Input Validation

Every function validates inputs before execution:

Asset IDs must correspond to accepted assets
Amounts must be non-zero
Addresses must be non-zero

Upgrade Safety

UUPS Proxy Pattern

The protocol uses the Universal Upgradeable Proxy Standard (UUPS): Security Advantages:

Upgrade logic lives in implementation (not proxy)
Smaller proxy contract reduces attack surface
Explicit authorization required for upgrades
Event emission for all upgrades

Upgrade Authorization:

function _authorizeUpgrade(address newImplementation)
    internal
    override
    onlyRole(DEFAULT_ADMIN_ROLE)
{
    // Only DEFAULT_ADMIN_ROLE (typically multi-sig) can upgrade
}

Storage Layout Protection

Storage Gaps: All upgradeable contracts include __gap arrays
Layout Verification: Automated tools verify storage compatibility
Initialization Guards: initializer modifier prevents re-initialization

contract MultiliquidSwapV2 is Initializable, UUPSUpgradeable {
    // State variables...

    // Storage gap for future versions (50 slots)
    uint256[50] private __gap;
}

Access Control System

The protocol implements a sophisticated multi-tier permission model using OpenZeppelin’s AccessControl:

Global Roles

DEFAULT_ADMIN_ROLE

Permissions:

Upgrade all UUPS contracts
Grant and revoke all other internal roles (does not include external role IssuerAdmin)
Modify core protocol parameters
Execute emergency recovery operations

Security Considerations:

Should never be held by EOA (Externally Owned Account)
Requires multi-party consensus for all operations

OPERATOR_ROLE

Permissions:

Accept new RWAs and stablecoins
Update price adapters
Configure fee tiers
Manage operational parameters

Security Considerations:

Should never be held by EOA (Externally Owned Account)
Requires multi-party consensus for all operations

Restrictions:

Cannot upgrade contracts
Cannot modify access control
Cannot directly transfer user funds

PAUSE_ROLE

Permissions:

Pause the MultiliquidSwap contract
Unpause the MultiliquidSwap contract

Intended Holder: Security operations team Use Cases:

Smart contract vulnerability discovered
Suspicious trading activity detected
Oracle manipulation detected
Regulatory requirement

Asset-Specific Roles

Stablecoin Issuer Admin

Each stablecoin delegate has an independent issuer admin role: Permissions:

Set RWA discount rates for their stablecoin
Set RWA redemption fees for their stablecoin
Add/remove RWAs from their whitelist
Pause their specific delegate
Configure custody addresses
Update stablecoin minting/burning parameters

Security Boundary:

Cannot affect other stablecoins
Cannot modify core protocol logic
Cannot access other issuers’ funds

Example:

stablecoinDelegate.setRWADiscountRate(rwaID, 1e16); // 1% discount

RWA Issuer Admin

Each RWA delegate (when deployed) has an independent issuer admin role: Permissions:

Configure volume limits
Adjust risk parameters
Pause their specific delegate

Security Boundary:

Cannot affect other RWAs
Cannot modify core protocol logic
Cannot override stablecoin issuer controls

Permission Hierarchy

Risk Management Controls

Volume Limits

RWA delegates can implement daily volume limits to prevent:

Market manipulation through large swaps
Sudden liquidity drains
Compliance violations

Implementation Example (ULTRA):

Daily Limit: Configurable per wallet
Reset Time: 2pm Singapore Time (UTC+8)
Tracking: Cumulative swap volume over rolling 24-hour window
Enforcement: Automatic rejection when limit exceeded

// Example: User attempts swap
function checkRWAOut(address user, uint256 amount, bytes calldata metadata)
    external
    returns (bool)
{
    uint256 currentVolume = dailyVolume[user];
    uint256 limit = dailyVolumeLimit[user];

    require(currentVolume + amount <= limit, "Daily limit exceeded");

    dailyVolume[user] += amount;
    return true;
}

Whitelist Management

Per-Stablecoin RWA Whitelisting:

Each stablecoin issuer controls which RWAs they accept
Granular risk management per issuer
Prevents unwanted asset exposure

Whitelist Modification:

Only issuer admin can modify their whitelist
Events emitted for transparency
Takes effect immediately

Benefits:

Issuers maintain control over their risk profile
Flexible onboarding without protocol-wide impact
Compliance alignment with issuer policies

Slippage Protection

All swap functions require users to specify minimum output amounts: ExactIn Swaps (user specifies input amount):

// User sends exactly 1000 USDC, expects at least 995 RWA tokens
swapIntoRWA(SwapIntoRWAInputs({
    stablecoinID: usdcID,
    stablecoinAmount: 1000e6,     // Exact input
    rwaID: ultraID,
    rwaAmount: 995e6,             // Minimum output (slippage tolerance)
    ...
}));

ExactOut Swaps (user specifies output amount):

// User wants exactly 1000 RWA tokens, willing to pay up to 1005 USDC
swapIntoRWAExactOut(SwapIntoRWAInputs({
    rwaID: ultraID,
    rwaAmount: 1000e6,            // Exact output
    stablecoinID: usdcID,
    stablecoinAmount: 1005e6,     // Maximum input (slippage tolerance)
    ...
}));

If the calculated amount violates the slippage bounds, the transaction reverts atomically.

Discount Rate and Fee Caps

Discount Rates:

Stored as WAD (1e18 = 100%)
Maximum discount: Configurable, typically 20% (2e17)
Prevents excessive value extraction

Redemption Fees:

Stored as WAD
Maximum fee: Configurable, typically 5% (5e16)
Prevents prohibitive redemption costs

Acceptance Fees (Stablecoin-to-Stablecoin):

Charged when accepting a new stablecoin in a swap
Configurable per stablecoin pair
Transparent on-chain calculation

Emergency Mechanisms

Pause Functionality

The protocol implements multi-level pause capabilities:

Global Pause (MultiliquidSwap)

Trigger: PAUSE_ROLE calls pause() Effects:

All swap functions revert
Price queries still available
Administrative functions still accessible

Use Cases:

Critical vulnerability discovered
Oracle manipulation detected
Regulatory requirement
Smart contract upgrade preparation

Delegate-Level Pause

Stablecoin Delegate Pause:

Triggered by issuer admin or PAUSE_ROLE
Affects only swaps involving that stablecoin delegate
Other stablecoin delegates remain operational

RWA Delegate Pause:

Triggered by issuer admin or PAUSE_ROLE
Affects only swaps involving that RWA
Other RWAs remain operational

// ULTRA continues to work with other stablecoins
multiliquidSwap.swapIntoStablecoin(ultraID, uniformLabsStablecoinID, ...);

Unpause Requirements

Unpausing requires:

Root cause analysis completed
Fix implemented and tested (if applicable)
Security review of changes
Explicit unpause transaction by authorized role

Audit and Review Process

Pre-Deployment Security

Before mainnet deployment, all contracts undergo:

Extensive Internal Code Review and Testing
- 835 Unit Tests (including fuzzing)
- Security-focused checklist validation
- Gas optimization review
- Slither static analysis
Testnet Deployment
- Full system deployment on testnet
- Integration testing with real user flows
- Stress testing with edge cases
- Multi-day operational validation
Third-Party Security Audit
- Engagement with reputable security firm
- Comprehensive audit report
- Remediation of all findings
Final Verification and Deployment
- Mainnet deployment scripts used
- Multi-sig setup verified
- Role assignments documented

Post-Deployment Monitoring

Continuous monitoring includes:

Event Indexing: All contract events logged and analyzed
Transaction Monitoring: Unusual patterns detected
Price Oracle Monitoring: Deviation alerts for price feeds

Incident Response

In the event of a security incident:

Detection: Monitoring systems alert security team
Assessment: Rapid evaluation of severity and impact
Pause (if necessary): Immediate pause of affected components
Communication: Transparent disclosure to stakeholders
Remediation: Fix development and testing
Deployment: Upgrade execution via multi-sig
Post-Mortem: Detailed report and process improvement

Operational Security Best Practices

For institutions integrating with the protocol:

Key Management

Use Hardware Wallets: For all signing operations
Multi-Sig Wallets: Minimum 2-of-3 for operational roles
Geographic Distribution: Key holders in different locations
Regular Rotation: Periodic key refresh schedule

Transaction Security

Simulation: Use transaction simulation before signing
Verification: Double-check recipient addresses and amounts
Gas Limits: Set reasonable limits to prevent griefing
Nonce Management: Track nonces to prevent replay attacks

Known Limitations and Assumptions

Token Compatibility

The protocol assumes:

Tokens do not implement transfer fees or rebasing
Tokens do not have transfer requirements that break atomicity
Tokens follow standard ERC20 behavior
Price oracles remain available and accurate

If integrating a token with non-standard behavior, additional analysis and potentially custom delegate development is required.

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/
Public Repository: https://github.com/uniformlabs/Multiliquid

This security documentation is a living document and will be updated as the protocol evolves, new security measures are implemented, and audit results become available.

Next: MultiliquidSwap Contract

Explore the central orchestrator contract managing all swap operations

Overview

Core Components

Integration

​Security Overview

Smart Contract Security

Access Control

Risk Management

Emergency Response

​Smart Contract Security

​Industry-Standard Frameworks

​Core Security Mechanisms

​1. Reentrancy Protection

​2. SafeERC20 Operations

​3. Integer Overflow Protection

​4. Input Validation

​Upgrade Safety

​UUPS Proxy Pattern

​Storage Layout Protection

​Access Control System

​Global Roles

​DEFAULT_ADMIN_ROLE

​OPERATOR_ROLE

​PAUSE_ROLE

​Asset-Specific Roles

​Stablecoin Issuer Admin

​RWA Issuer Admin

​Permission Hierarchy

​Risk Management Controls

​Volume Limits

​Whitelist Management

​Slippage Protection

​Discount Rate and Fee Caps

​Emergency Mechanisms

​Pause Functionality

​Global Pause (MultiliquidSwap)

​Delegate-Level Pause

​Unpause Requirements

​Audit and Review Process

​Pre-Deployment Security

​Post-Deployment Monitoring

​Incident Response

​Operational Security Best Practices

​Key Management

​Transaction Security

​Known Limitations and Assumptions

​Token Compatibility

​Security Contacts

Next: MultiliquidSwap Contract

Security Overview

Smart Contract Security

Industry-Standard Frameworks

Core Security Mechanisms

1. Reentrancy Protection

2. SafeERC20 Operations

3. Integer Overflow Protection

4. Input Validation

Upgrade Safety

UUPS Proxy Pattern

Storage Layout Protection

Access Control System

Global Roles

DEFAULT_ADMIN_ROLE

OPERATOR_ROLE

PAUSE_ROLE

Asset-Specific Roles

Stablecoin Issuer Admin

RWA Issuer Admin

Permission Hierarchy

Risk Management Controls

Volume Limits

Whitelist Management

Slippage Protection

Discount Rate and Fee Caps

Emergency Mechanisms

Pause Functionality

Global Pause (MultiliquidSwap)

Delegate-Level Pause

Unpause Requirements

Audit and Review Process

Pre-Deployment Security

Post-Deployment Monitoring

Incident Response

Operational Security Best Practices

Key Management

Transaction Security

Known Limitations and Assumptions

Token Compatibility

Security Contacts