Protocol Mechanics

Protocol Architecture

Everst implements a modular architecture based on proven lending protocols, enhanced with features specific to tokenized asset lending. This technical documentation provides detailed information for developers and advanced users.

Core Contract Architecture

Blotroller (Asset Controller)

The protocol's central risk management contract responsible for governing all protocol operations.

Core Structure

struct Market {
    bool isListed;           // Whether market is listed
    uint256 collateralFactor; // Collateral factor (0-90%)
    mapping(address => bool) accountMembership;
}

Key Functions

  • Market administration and asset listing

  • Collateral factor parameter management

  • Interest rate model selection and configuration

  • Liquidation parameter control

  • Account liquidity calculation: Σ(Collateral Value × Collateral Factor) - Total Debt

BToken Contract System

Interest-bearing tokens representing supplied positions, serving as the protocol's core asset representation.

BErc20 Core Data

struct BTokenStorage {
    uint256 totalSupply;     // Total BToken issuance
    uint256 totalBorrows;    // Total borrowed amount
    uint256 totalReserves;   // Protocol reserves
    uint256 accrualBlockNumber; // Last interest accrual block
}

Key Mechanisms

  • Exchange Rate Calculation: exchangeRate = (totalCash + totalBorrows - totalReserves) / totalSupply

  • Interest Accrual Formula: Borrow Balance × (1 + Borrow Rate)^Blocks

  • Reserve Accumulation: Fixed percentage of each borrowing interest

Interest Rate Model

Everst adopts a jump rate model that responds dynamically to market utilization.

Interest Rate Model

Model Parameters

  • Base Rate: Minimum borrowing rate

  • Multiplier: Slope before kink

  • Kink: Target utilization threshold

  • Jump Multiplier: Accelerated slope after kink

  • Blocks Per Year: Network-specific parameter

Rate Calculation Formula

Before kink:

Borrow Rate = Base Rate + (Utilization × Multiplier)

After kink:

Borrow Rate = Base Rate + (Kink × Multiplier) + ((Utilization - Kink) × Jump Multiplier)

Supply Rate:

Supply Rate = Borrow Rate × Utilization × (1 - Reserve Factor)

Stock Token Special Considerations

  • Dynamic base rate adjustment during earnings seasons

  • Jump multiplier adjustment based on volatility

  • Additional liquidity incentives outside market hours

Oracle System

Multi-Oracle Aggregation Architecture

Everst aggregates prices from multiple sources to ensure security and reliability.

Oracle Source Integration

  • Chainlink: Decentralized price network, heartbeat mechanism triggers

  • Pyth Network: High-frequency updates, professional data sources

  • Validation Mechanism: Price deviation checks, historical data comparison

Stock Token Special Handling

  • Market hours: Real-time price synchronization

  • Non-market hours: Maintain closing price

  • Opening smoothing: Prevent price jumps

Price Source Security Mechanisms

Deviation Checks Maximum allowed oracle deviation: 2% Action on deviation: Use most conservative price

Staleness Protection Maximum price age: Configurable per asset type Fallback: Pause markets if all sources stale

Circuit Breakers

  • Single block price change limit: Configurable threshold

  • Daily price change limit: Configurable threshold

  • Action on trigger: Pause affected markets

Liquidation Engine

Hybrid Liquidation System Architecture

Everst's dual-path liquidation system ensures efficient unwinding of underwater positions.

Hybrid Liquidation Architecture

Path 1 - DEX Liquidation:

function liquidateBorrow(
    address borrower,
    uint256 repayAmount,
    address cTokenCollateral
) external {
    require(getAccountLiquidity(borrower) < 0, "Account healthy");
    // Calculate liquidatable amount and incentive
    uint256 seizeTokens = calculateSeizeTokens(repayAmount);
    // Execute liquidation
}

Path 2 - OTC Liquidation:

  • Large orders through professional market makers

  • Offchain quote competition mechanism

  • Onchain final settlement confirmation

Liquidation Parameters

Close Factor: Configurable between 5% and 90% Maximum percentage of debt repayable per liquidation (set by governance)

Liquidation Incentive: Configurable bonus for liquidators Bonus received by liquidators as percentage of repaid value

Protocol Seize Share: Configurable Portion of seized collateral that goes to protocol reserves

Minimum Liquidation: Configurable Smallest profitable liquidation after gas costs

Governance System

Parameter Management

Governance controls critical protocol parameters through timelock:

Governance Parameter Control

struct GovernanceParams {
    uint256 collateralFactor;  // Collateral factor (0-90%)
    uint256 reserveFactor;     // Reserve factor (0-100%)
    address interestRateModel; // Interest rate model contract
    uint256 liquidationIncentive; // Liquidation incentive
}

Timelock Mechanism

  • Key changes require 2-30 day execution delay

  • 14-day grace period prevents governance attacks

Multi-signature Governance Roles

  • Owner: Parameter proposal and execution authority

  • Guardian: Emergency pause, no resume authority

  • Keeper: Daily operation authority

Gas Optimization

Efficient Operations

Everst optimizes gas usage across all supported networks:

Storage Optimization Strategy

struct AccountSnapshot {
    uint128 principal;      // Principal (128 bits)
    uint128 interestIndex;  // Interest index (128 bits)
    // Single storage slot optimization
}

Batch Operation Support

  • Multi-asset atomic operations reduce gas

  • Oracle batch update mechanism

  • Smart contract call optimization

Typical Gas Costs Gas costs vary significantly by network and current conditions. Operations typically require:

  • Supply: Standard token transfer + protocol logic

  • Borrow: Additional collateral checks

  • Repay: Interest calculation + transfer

  • Liquidate: Most complex operation with multiple transfers

Security Features

Reentrancy Protection

Core Security Principles

modifier nonReentrant() {
    require(!entered, "Reentrancy attack");
    entered = true;
    _;
    entered = false;
}

  • Checks-Effects-Interactions: Validate first, update state, then external calls

  • Overflow Protection: Solidity 0.8+ built-in checks

  • Access Control: Role permissions, function modifier validation

Integer Overflow Protection

  • Solidity 0.8+ automatic checks

  • Safe math for older contracts

  • Explicit overflow handling

  • Precision loss prevention

Access Control

  • Role-based permissions

  • Function-level restrictions

  • Modifier-based checks

  • Event logging for actions

Integration Guide

Developer Interface

Core API Interface

// Query interface
function getAccountLiquidity(address account) 
    external view returns (uint256, uint256);
function exchangeRateStored() external view returns (uint256);

// Operation interface
function mint(uint256 mintAmount) external returns (uint256);
function borrow(uint256 borrowAmount) external returns (uint256);
function repayBorrow(uint256 repayAmount) external returns (uint256);

Integration Event Monitoring

  • Mint/Redeem: Supply and withdraw events

  • Borrow/RepayBorrow: Borrowing and repayment events

  • LiquidateBorrow: Liquidation execution events

Smart Contract Addresses

Key Contract Addresses

  • Blotroller: Asset controller main contract

  • BToken Markets: Asset lending markets

  • Oracle: Price oracle aggregator

  • Timelock: Governance timelock contract

Audit History

Security Reviews

Contract Audits

  • Certik: March 2024

  • PeckShield: April 2024

  • Trail of Bits: May 2024

Findings Summary

  • 0 Critical issues

  • 2 High (resolved)

  • 5 Medium (resolved)

  • 12 Low (acknowledged)

Additional Resources

Developer Tools

Technical Support

  • Developer Community Channel

  • GitHub Issues

  • Technical Documentation Wiki

  • Office Hours (Wednesdays 2PM UTC)

This technical documentation is for developers and advanced users. For general usage, see our Getting Started Guide.

PreviousLiquidationsNextOracle System

Last updated