igh
ETF Indices (SPY, QQQ)
75%
80%
5%
Low-Medium
Safety buffer = difference between max borrow and liquidation
Stock Token Specific Liquidation Risks
Market Hours Factors
US Stock Trading Hours
: Most active liquidation period
After-Hours/Weekends
: Relatively less price movement, but liquidations can still occur
Holidays
: Traditional markets closed but DeFi continues operating
Stock-Specific Risks
Earnings Announcements
: Earnings season increases liquidation risk due to volatility
Major News Events
: Breaking news can cause rapid price movements
Corporate Actions
: Dividends, splits, and other events affect prices
Regulatory Changes
: Stock-related regulatory policies impact
Volatility Patterns
Market Open/Close
: Higher volatility during traditional trading hours
Earnings Season
: Significantly increased liquidation risk during quarterly reports
Market Events
: Major economic events affect all stock tokens
For Borrowers: Avoiding Liquidation
Prevention Strategies
1. Maintain Safe Health Factor
Keep Health Factor > 1.5 for safety
2.0 for volatile stock tokens
Monitor regularly during market volatility
2. Diversify Collateral
Don't rely on single stock token
Mix USDT with stock tokens
Reduces single-point failure risk
3. Set Alerts
Stock token price alerts
Health Factor warnings at 1.5, 1.25, 1.1
Daily position summaries
Earnings date reminders
4. Have Contingency Plans
Keep reserves to add collateral
Plan partial repayments
Know your liquidation price
Prepare rapid response strategies
Calculating Your Liquidation Price
For single collateral positions:
Liquidation Price = Borrowed Amount ÷ (Collateral Amount × Liquidation Threshold)
Example
:
Collateral: 10 AAPL stock tokens (80% threshold)
Borrowed: 8,000 USDT
Liquidation Price = 8,000 USDT ÷ (10 × 0.80) = $1,000 per AAPL
Stock-Specific Prevention Measures
Earnings Season Preparation
2 Weeks Before Earnings
: Reduce leverage to conservative levels
Earnings Day
: Avoid new borrowing
Post-Earnings
: Adjust positions based on results
News Event Management
Pre-Major Announcements
: Increase Health Factor to > 2.5
Regulatory News
: Monitor stock-related policy changes
Industry Events
: Watch for sector-wide impacting news
Technical Analysis Support
Support Level Identification
: Set liquidation prices above technical support
Resistance Monitoring
: Watch for potential price ceilings
Trend Analysis
: Adjust risk exposure based on trends
For Liquidators: Participating in Liquidations
Requirements
Capital
: Funds to repay borrower's debt
Technical Setup
: Bot or monitoring system
Gas for Transactions
: Native tokens for network fees
Risk Management
: Handle received collateral
Liquidation Bot Architecture
The liquidation bot continuously monitors positions, identifies unsafe loans, calculates potential profit, executes liquidations through DEX or OTC routes, and manages the received collateral in a continuous cycle.
Profit Calculation
Gross Profit = (Collateral Received × Market Price) - Debt Repaid
Net Profit = Gross Profit - Gas Costs - Slippage
Example
:
Repay: 10,000 USDT debt
Receive: Collateral including liquidation bonus
Gas: $0.50
Slippage: $50 (0.5%)
Net Profit: $800 - $0.50 - $50 = $749.50
Stock Token Liquidation Specifics
Liquidity Considerations
Large-cap Stocks
: AAPL, MSFT typically have better liquidity
Small-cap Stocks
: May require OTC route for liquidation
Time Sensitivity
: Best liquidity during US trading hours
Risk Management
Price Volatility
: Stock token prices can move rapidly
Liquidity Risk
: Some stock tokens may be difficult to sell immediately
Hedging Strategies
: Consider immediately hedging received stock tokens
Integration Points
Read Functions
:
getAccountLiquidity()
,
getBorrowBalance()
Liquidation Function
:
liquidateBorrow(borrower, amount, collateral)
Events
: Monitor
LiquidateBorrow
events
Oracle Prices
:
getUnderlyingPrice(asset)
Impact on Different Stakeholders
For Borrowers
Loss
: Liquidation penalty on collateral
Partial liquidation
: Up to the configured close factor of debt
Immediate execution
: No grace period
Gas fees
: Paid by liquidator, not borrower
For Suppliers
Protection
: Ensures protocol solvency
No direct impact
: Unless also borrowing
Maintains liquidity
: Repaid funds return to pool
For the Protocol
Risk mitigation
: Prevents bad debt
Automatic process
: No manual intervention
Decentralized
: Anyone can liquidate
Revenue neutral
: Incentive paid from borrower's collateral
Advanced Topics
Cascading Liquidations
In extreme market conditions, liquidations can cascade:
Initial liquidations sell collateral
Selling pressure drops prices further
More positions become unsafe
Cycle continues
Everst mitigates this through:
Configurable close factor (partial liquidations)
Hybrid liquidation engine (reduces onchain selling)
Conservative collateral factors
Oracle price averaging
Stock-Specific Cascading Risks
Industry Chain Effects
Tech Stock Crash
: AAPL, MSFT, NVDA declining simultaneously
Financial Crisis
: Bank stocks liquidating in sync
Regulatory Impact
: Entire sectors facing regulatory pressure
Mitigation Measures
Industry Diversification
: Mix of stock tokens across sectors
Tiered Liquidation
: Different parameters for different industries
Dynamic Adjustment
: Risk parameter adjustment based on market conditions
MEV and Liquidations
Liquidations can be subject to MEV (Maximal Extractable Value):
Front-running liquidation transactions
Back-running oracle updates
Sandwich attacks on liquidation trades
Protection mechanisms:
Flashloan resistance
Minimum liquidation amounts
Oracle delay for price updates
Emergency Procedures
Protocol Pause
In extreme circumstances, governance can:
Pause new borrows
Pause liquidations temporarily
Adjust risk parameters
Enable emergency withdrawal
Insurance Fund
Protocol reserves act as first loss capital
Covers shortfalls from failed liquidations
Funded by protocol reserve factor
Governance controlled
Real-time Monitoring and Alert Systems
For Borrowers
Mobile App Push
: Instant notifications when Health Factor drops below thresholds
Email Alerts
: Daily risk reports and market updates
SMS Warnings
: Emergency liquidation risk notifications
Price Tracking
: Custom stock token price targets
For Liquidators
Arbitrage Opportunities
: Real-time profitable liquidation identification
Competition Analysis
: Monitor other liquidator activity
Gas Optimization
: Optimal transaction timing suggestions
Risk Assessment
: Risk analysis of received collateral
Frequently Asked Questions
Q: Can I be liquidated if I only supply?
A: No, liquidation only affects borrowers.
Q: Is there a grace period before liquidation?
A: No, liquidation is immediate when Health Factor < 1.0.
Q: Can I stop a liquidation in progress?
A: No, but you can prevent it by maintaining safe ratios.
Q: What happens to remaining collateral after liquidation?
A: You keep any collateral not liquidated and can withdraw if not securing other debt.
Q: Can liquidation be reversed?
A: No, blockchain transactions are irreversible.
Q: What's special about stock token liquidations?
A: Stock token liquidations may be affected by market hours, earnings events, and industry news, requiring additional monitoring.
Next Steps
Avoid liquidation
→ Review prevention strategies above
Understand the process
→ See step-by-step breakdown above
For liquidators
→ Review liquidator requirements section
Risk management
→
Risk Overview
Liquidations are automatic and irreversible. Maintain safe collateral ratios to avoid losses.
Risk Overview
Protocol Mechanics
## /docs/everst/protocol-mechanics
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.
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
GitHub Repository
Contract Documentation
Integration Examples
Testnet Faucet
Technical Support
Telegram Community
- Real-time support
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
.
Liquidations
Oracle System
## /docs/everst/oracle-system
Oracle System
Overview
Everst uses a robust multi-oracle system to ensure accurate and manipulation-resistant price feeds for all supported assets. The protocol aggregates data from multiple trusted sources to provide reliable pricing for lending, borrowing, and liquidation calculations.
Oracle Architecture
Primary Oracle: Chainlink
Decentralized price aggregation
from multiple node operators
Update frequency
: Triggered when price deviates >0.5% or after set time intervals
Battle-tested
across DeFi with billions in secured value
Coverage
: All major tokenized stocks and stablecoins
Latency
: 1-3 block confirmation time
Secondary Oracle: Pyth Network
High-frequency updates
with sub-second latency
Professional-grade
price feeds from institutional market makers
Confidence intervals
providing price uncertainty metrics
Pull-based model
allowing on-demand price updates
Specialized
for financial market data
Price Aggregation Strategy
Dual-Oracle Verification
The protocol implements a sophisticated price aggregation mechanism:
Final Price = Aggregate(Chainlink Price, Pyth Price)
Normal Operation
:
Both oracles must report prices within 2% deviation
Final price is the weighted average of both feeds
Chainlink weighted 60%, Pyth weighted 40%
Divergence Handling
:
When oracle prices diverge by more than 2%:
For collateral valuation
: Use the lower price (conservative approach)
For debt calculation
: Use the higher price (protective measure)
Alert triggered
for manual review if divergence exceeds 5%
Fallback Mechanism
if (Chainlink fails) {
if (Pyth available && recent) {
use Pyth price with 10% additional haircut
} else {
pause affected market
}
}
Oracle Update Mechanisms
Push-Based Updates (Chainlink)
Automatic updates from decentralized node network
Triggered by price deviation or heartbeat
Gas-efficient batch updates
Pull-Based Updates (Pyth)
Keeper bots monitor off-chain prices
Update on-chain when deviation exceeds threshold
User-triggered updates for immediate execution
Security Features
Price Manipulation Protection
Multi-source verification
prevents single point of failure
Time-weighted average prices
(TWAP) for volatile periods
Maximum price change limits
per block (circuit breakers)
Staleness checks
rejecting prices older than 120 seconds
Circuit Breakers
Maximum price change per update:
- Stablecoins: ±2%
- Blue-chip stocks: ±10%
- Growth stocks: ±15%
- ETFs: ±8%
Oracle Monitoring
Real-time deviation tracking between sources
Historical price feed analysis
Automated alerts for anomalies
Manual override capabilities for emergencies
Implementation Details
Smart Contract Integration
BloPriceOracle.sol
:
interface
IBloPriceOracle
{
function
getUnderlyingPrice
(
BToken
bToken
)
external
view
returns
(
uint
);
function
updatePrice
(
address
asset
)
external
;
function
isPriceStale
(
address
asset
)
external
view
returns
(
bool
);
}
Price Feed Registry
Maintains mapping of assets to their oracle configurations:
Primary oracle address
Secondary oracle address
Deviation thresholds
Update frequencies
Fallback parameters
Gas Optimization
Batch price updates for multiple assets
Caching mechanisms for recent prices
Optimized storage patterns
Keeper Infrastructure
Automated Price Updates
Keeper bots continuously:
Monitor off-chain price sources
Calculate deviation from on-chain prices
Submit updates when thresholds exceeded
Compete for update rewards
Update Triggers
Deviation trigger
: Price moves >0.5%
Time trigger
: No update for >120 seconds
Liquidation trigger
: Position approaching liquidation
User trigger
: Manual update request
Oracle Governance
Parameter Management
Governed parameters include:
Deviation thresholds
Update frequencies
Oracle weights
Fallback conditions
Circuit breaker limits
Oracle Addition Process
Technical evaluation of feed reliability
Historical data analysis
Integration testing on testnet
Gradual mainnet rollout
Continuous monitoring period
Tokenized Stock Considerations
Market Hours Handling
Continuous 24/7 price feeds despite traditional market hours
Week프로젝트로 돌아가기 