bitpro가 원문에서 글자만 모은 내용이에요. 표·그림·수식은 빠지거나 깨질 수 있어요. 전체 21쪽 중 5쪽
entry point for all trade execution
The Manager Contract orchestrates the entire on-chain execution flow:
Quote Verification
: Validates EIP-712 signatures from the off-chain backend
Routing Logic
: Determines which executor contract to use for each trade
Trade Coordination
: Manages the complete trade execution process
Security Enforcement
: Implements access controls and safety checks
Core Functions
:
function
executeQuote
(
SignedQuote
quote
)
external
function
verifyQuoteSignature
(
SignedQuote
quote
)
internal
function
routeToExecutor
(
address
issuer
,
TradeParams
params
)
internal
Token Registry
Type
: Upgradeable on-chain registry contract
Purpose
: Central repository of all supported tokenized assets
The Token Registry maintains a comprehensive mapping of available assets:
Asset Mapping
: Links stock symbols to token contract addresses
Issuer Association
: Associates each token with its respective issuer
Multi-Issuer Support
: Enables multiple issuers to list the same asset
Access Control
: Role-based permissions for token registration
Registry Structure
:
struct
TokenInfo
{
address
tokenContract;
address
issuer;
string
symbol;
bool
isActive;
}
mapping
(
string
=>
TokenInfo[])
public
tokensBySymbol;
mapping
(
address
=>
TokenInfo)
public
tokensByContract;
Access Controls
:
Issuers can register their own tokens
System admin can manage registry settings
Users have read-only access for price discovery
Executor Registry
Type
: Upgradeable registry contract
Purpose
: Maps issuers to their specific executor contracts
The Executor Registry enables modular integration of different issuer protocols:
Issuer-Executor Mapping
: Links each issuer to their custom executor contract
Protocol Adaptation
: Enables support for different token standards and trading interfaces
Administrative Control
: Only system owner can register or update executors
Upgrade Safety
: Supports safe upgrades of executor implementations
Registry Functions
:
function
registerExecutor
(
address
issuer
,
address
executor
)
external
onlyOwner
function
getExecutor
(
address
issuer
)
external
view
returns
(
address
)
function
updateExecutor
(
address
issuer
,
address
newExecutor
)
external
onlyOwner
Executor Contracts
Type
: Issuer-specific adaptor contracts
Purpose
: Handle actual token transfers and payments
Executor contracts serve as protocol adaptors for each issuer:
Protocol Abstraction
: Standardizes interaction with diverse issuer protocols
Trade Execution
: Performs actual token transfers and payment processing
Custom Logic
: Implements issuer-specific trading rules and requirements
Safety Mechanisms
: Includes validation and error handling for each issuer's protocol
Standard Interface
:
interface
IExecutor
{
function
executeBuy
(
address
user
,
string
symbol
,
uint256
amount
,
uint256
price
)
external
;
function
executeSell
(
address
user
,
string
symbol
,
uint256
amount
,
uint256
price
)
external
;
function
validateTrade
(
TradeParams
params
)
external
view
returns
(
bool
);
}
Executor Types
:
Mint/Burn Executors
: For issuers using mint/burn mechanisms
Transfer Executors
: For issuers using token transfer models
Marketplace Executors
: For issuers with marketplace-based trading
Issuer Token Contracts
Type
: External contracts owned by individual issuers
Purpose
: Actual tokenized asset implementation
These are the external contracts that Aqua integrates with:
Token Implementation
: The actual tokenized stock contracts
Payment Handling
: Processes payments for token purchases/sales
Compliance Logic
: Implements issuer-specific compliance requirements
Asset Backing
: Manages the underlying asset representation
Integration Patterns
:
Direct Token Contracts
: Simple ERC-20 style tokenized stocks
Marketplace Contracts
: Full trading platforms with order books
Custodial Contracts
: Contracts managing underlying asset custody
Component Interactions
Trade Execution Flow
User Request
: User requests quote through frontend or API
Quote Aggregation
: Off-chain backend queries all registered issuers
Best Quote Selection
: Backend selects optimal quote and signs it
On-Chain Execution
: User submits signed quote to Manager Contract
Verification
: Manager Contract verifies quote signature and validity
Routing
: Manager queries Executor Registry to find appropriate executor
Execution
: Executor contract interacts with issuer's token contract
Settlement
: Tokens and payments are transferred according to trade terms
Registry Management
Token Registration
: Issuers register their tokens in Token Registry
Executor Deployment
: System admin deploys and registers executor contracts
Updates
: Registries support upgrades for new features and improvements
Security Model
Access Controls
Registry Permissions
: Role-based access for different registry operations
Executor Authorization
: Only authorized executors can perform trades
Signature Verification
: All quotes must be cryptographically signed
Safety Mechanisms
Quote Expiration
: Time-limited quotes prevent stale price execution
Trade Validation
: Multiple validation layers before execution
Circuit Breakers
: Emergency stops for unusual market conditions
Scalability Considerations
Off-Chain Optimization
Parallel Quote Processing
: Simultaneous requests to multiple issuers
Caching Mechanisms
: Efficient price data caching and updates
Load Balancing
: Distributed backend infrastructure
On-Chain Efficiency
Gas Optimization
: Minimal on-chain computation and storage
Batch Processing
: Support for multiple trade executions in a single transaction
Upgradeable Contracts
: Future improvements without migration costs
Introduction
Security Model
## /docs/aqua/security-model
Security Model
Security Architecture Overview
Aqua's security model is designed around the hybrid architecture principle, where security responsibilities are distributed between off-chain and on-chain components. The model ensures that while off-chain components provide performance and flexibility, on-chain components maintain trustlessness and security guarantees.
Trust Boundaries
Off-Chain Trust Requirements
Limited Trust Scope
Users must trust the off-chain backend for quote aggregation and price discovery, but this trust is bounded by cryptographic verification mechanisms.
Trust Limitations
:
Backend cannot execute trades without valid signatures
Backend cannot modify quote data after signing
Backend cannot access user funds or tokens
Backend downtime does not affect existing on-chain assets
Trust Verification
:
All quotes are cryptographically signed using EIP-712
Signature verification prevents quote manipulation
Time-bounded quotes limit exposure to stale data
Multiple backend implementations possible for redundancy
On-Chain Trustless Guarantees
Cryptographic Security
All critical operations are verified on-chain using mathematical proofs rather than trust assumptions.
Trustless Properties
:
Quote authenticity verified through EIP-712 signatures
Registry operations governed by role-based access controls
Trade execution enforced by smart contract logic
Asset custody remains with users throughout the process
EIP-712 Signature Security
Quote Integrity Protection
Signature Generation Process
The off-chain backend generates structured signatures that bind specific quote parameters to prevent tampering.
Protected Quote Elements
:
Token symbol and amount
Price and expiration timestamp
Issuer identity and nonce
User address and trade direction
Signature Verification
On-chain verification ensures that quotes haven't been modified between generation and execution.
Security Properties
:
Non-repudiation: Backend cannot deny signing valid quotes
Integrity: Any modification of quote data invalidates the signature
Authenticity: Only authorized backend can generate valid signatures
Replay protection: Nonce system prevents quote reuse
Key Management Security
Backend Key Security
The off-chain backend's signing keys are the critical security component for quote generation.
Key Protection Measures
:
Hardware Security Module (HSM) integration for key storage
Multi-signature schemes for key backup and recovery
Regular key rotation procedures
Segregated key access controls
Operational Security
:
Keys never exposed in application memory
Signing operations performed in secure enclaves
Comprehensive audit logging of all signing operations
Emergency key revocation procedures
Registry Security Model
Token Registry Protection
Registration Authority
Only authorized issuers can register tokens, preventing unauthorized or malicious token listings.
Access Control Mechanisms
:
Role-based permissions for token registration
Multi-signature requirements for critical operations
Time-locked administrative changes
Emergency pause mechanisms
Registry Integrity
:
Immutable token-to-issuer mappings once established
Transparent on-chain record of all registrations
Community-verifiable registry state
Protection against registry poisoning attacks
Executor Registry Security
System-Level Controls
Executor registration is restricted to system administrators to maintain security standards.
Security Validations
:
Code review requirements for new executors
Formal verification of executor logic where possible
Compatibility testing with issuer protocols
Security audit requirements for complex executors
Executor Isolation
:
Each executor handles only its designated issuer
Failure isolation prevents cascading security issues
Upgradeable executor implementations for security patches
Emergency executor disabling capabilities
Smart Contract Security
Manager Contract Protection
Entry Point Security
As the primary entry point, the Manager Contract implements multiple security layers.
Security Mechanisms
:
Signature verification before any trade processing
Quote expiration checks to prevent stale price exploitation
Registry validation to ensure legitimate trading pairs
Reentrancy protection for all external calls
Access Controls
:
Only verified quotes can trigger trade execution
Registry modifications require appropriate permissions
Emergency pause functionality for critical situations
Upgradeable contract design with timelock governance
Executor Contract Security
Isolation Principle
Each executor contract operates independently, limiting the blast radius of potential vulnerabilities.
Security Design
:
Minimal trust assumptions about issuer protocols
Input validation for all trade parameters
Safe external call patterns to prevent reentrancy
Comprehensive error handling and failure recovery
Integration Security
:
Standardized interface reduces integration risks
Whitelisting of authorized token contracts
Protection against malicious issuer behavior
Circuit breakers for unusual trading patterns
Economic Security
Quote Manipulation Protection
Time-Bounded Quotes
Short quote expiration times limit the window for potential manipulation attacks.
Economic Incentives
:
Backend reputation tied to quote quality and reliability
Economic penalties for providing poor quotes
Market-driven selection of optimal pricing
Transparency in quote generation process
MEV (Maximal Extractable Value) Considerations
Front-Running Protection
The quote-based model provides some protection against traditional MEV attacks.
MEV Mitigation
:
Pre-signed quotes reduce on-chain price discovery
Time-bounded execution windows limit sandwich attacks
Batch execution capabilities for multiple trades
Integration with MEV protection services where appropriate
Operational Security
Infrastructure Security
Backend Infrastructure
Comprehensive security measures protect the off-chain infrastructure.
Security Measures
:
Multi-region deployment for availability
DDoS protection and rate limiting
Encrypted communication with all external services
Regular security audits and penetration testing
Monitoring and Alerting
:
Real-time monitoring of all system components
Automated alerting for suspicious activities
Comprehensive logging for security analysis
Incident response procedures and escalation paths
Upgrade Security
Safe Upgrade Procedures
Both off-chain and on-chain components support secure upgrade mechanisms.
Upgrade Controls
:
Timelock governance for contract upgrades
Multi-signature requirements for critical changes
Gradual rollout procedures for backend updates
Rollback capabilities for emergency situations
Risk Management
Systemic Risk Mitigation
Component Isolation
Failure in one component should not compromise the entire system.
Risk Controls
:
Independent operation of each issuer integration
Circuit breakers for unusual market conditions
Position limits and exposure controls
Emergency shutdown procedures
Compliance and Regulatory Considerations
Regulatory Alignment
Security model designed to support compliance with evolving regulatory requirements.
Compliance Features
:
Comprehensive audit trails for all transactions
Identity verification integration capabilities
Transaction monitoring and reporting tools
Jurisdiction-specific compliance modules
Security Monitoring
Real-Time Threat Detection
Automated Monitoring
Continuous monitoring of system behavior to detect potential security threats.
Detection Capabilities
:
Unusual trading pattern identification
Quote manipulation detection
System performance anomaly alerts
Integration with threat intelligence feeds
Incident Response
Response Procedures
Comprehensive incident response plan for various security scenarios.
Response Capabilities
:
Rapid threat containment procedures
Emergency system shutdown mechanisms
Coordinated response with affected issuers
Post-incident analysis and improvement processes
Security Assumptions
Explicit Trust Requirements
Off-Chain Dependencies
Clear definition of what users must trust in the system.
Trust Assumptions
:
Backend operators act in good faith for quote generation
Infrastructure providers maintain system availability
Key management systems remain secure
Regulatory environment remains stable
Security Guarantees
Cryptographic Guarantees
Mathematical certainties provided by the security model.
Guaranteed Properties
:
Quote authenticity through signature verification
Trade atomicity through smart contract execution
Registry integrity through on-chain storage
User asset custody through non-custodial design
This security model provides a robust foundation for tokenized asset trading while maintaining the flexibility and performance benefits of the hybrid architecture approach.
Architecture
Get started
## /docs/aqua/get-started
Get started
Get Started
Welcome to
Aqua Liquidity Aggregator for Tokenized Equities
.
We’re excited to onboard both
end users
(integrators/traders) and
liquidity providers
(issuers/market makers) into our ecosystem.
🚀 Who Can Join?
End Users / Integrators
Brokers, apps, and fintech teams who want best-price execution across multiple tokenized equity issuers via a single API.
Liquidity Providers (LPs)
Issuers and market makers who want exposure to unified order flow while retaining full control over their contracts and pricing.
📝 Onboarding Process
1. KYB (Know Your Business)
All participants must complete a KYB process.
Status:
Currently under development.
What will be required:
Legal entity and ownership details
Business activity and jurisdictions
Compliance and technical points of contact
👉
Once KYB is approved, you'll receive your credentials.
📧
For KYB and partnership inquiries
:
partnerships@blockstreet.money
2. Credentials & Documentation
For End Users / Integrators
You will receive an
API key
to access Aqua's RFQ and trade execution endpoints.
API Reference
: Complete API documentation including:
Authentication and key management
RFQ request/response schema (EIP-712 based)
Execution flow and error handling
Rate limits and best practices
For Liquidity Providers
You will receive our
backend integration reference
to connect your quoting systems.
LP documentation
(in progress) will include:
Quote schema and SLA requirements
Signing rules and latency expectations
Executor contract onboarding (if applicable)
Monitoring and reconciliation tools
⏳ Current Status
KYB portal:
Coming soon
API references:
Available now
- Full API documentation is ready
We're actively working on the KYB portal and will announce updates as they become available.
📢 Stay Updated
Follow our
official channels
for the latest announcements, documentation drops, and early-access programs.
Security Model
API reference
All available pages
## /docs/api
API reference
All available pages
List supported tokens
Get token details
Execute trade
Get order status
Health check
Platform metrics
Request for Quote (RFQ)
Get quote details
Get all cached prices
Get specific stock price
Submit withdrawal request
Get withdrawal details
Get started
Health check
GET
Next Page
## /docs/everst
Introduction to Everst
Welcome to Everst, the Leverage and Liquidity Protocol! This guide will walk you through everything you need to know to start earning yields and leveraging assets on our protocol, embarking on your tokenized stocks DeFi journey.
What is Everst?
Everst is the
Leverage and Liquidity Protocol
— the world's first decentralized protocol designed specifically for tokenized stocks that combines off-chain broker-dealer networks with on-chain liquidity pools through a
Hybrid Liquidity Engine
. With Everst, you can:
Access leverage
- Use your tokenized stocks as collateral for leveraged positions with dynamic LTV
Earn yields
- Generate continuous returns by supplying tokenized stocks and USDT stablecoin
Maximize capital efficiency
- Positions are reusable across DeFi for maximum capital utilization
Hedge positions
- Hedge your portfolio risk through leverage mechanics
Trade 24/7
- Break traditional market hour limitations and participate around the clock
"Aqua handles the flow, Everst drives the leverage."
Think of Everst as the leverage layer built on top of Aqua's unified liquidity. Unlike traditional financial institutions, there are no intermediaries holding your funds - everything is automatically managed by smart contracts on the blockchain, transparent, secure, and efficient.
Testnet Traction
Everst has demonstrated exceptional market validation:
700,000 testnet wallets
35% retention rate
41% daily login rate
Before You Begin
What You'll Need
A Web3 Wallet
MetaMask (recommended)
Trust Wallet
Coinbase Wallet
Any WalletConnect-compatible wallet
First-time users should choose MetaMask for its rich tutorial resources
Native Tokens for Gas Fees
You'll need native tokens (ETH, BNB, MATIC, etc.) for transaction fees
Gas fees vary by network but are typically low ($0.1-1 per transaction)
Assets to Supply or Use as Collateral
Stablecoin: USDT (primary trading pair)
Tokenized stocks: AAPL, TSLA, NVDA, MSFT and other popular stocks
More tokenized stocks continuously being listed
Your First Steps
Step 1: Connect Your Wallet
Visit the Everst application
Click "Connect Wallet" in the top right
Select your wallet provider
Approve the connection request in your wallet
Select your preferred network from supported chains
Tip: First connection may require adding the network, just follow the prompts
Step 2: Explore the Markets
Once connected, you'll see the Markets page showing:
Supply APY
: The annual percentage yield you'll earn for supplying
Borrow APY
: The annual percentage rate you'll pay for borrowing
Total Supplied
: Total deposits of each asset in the protocol
Total Borrowed
: Current borrowed amount of assets
Utilization
: Percentage of borrowed amount to supplied amount
Focus on tokenized stocks with high supply프로젝트로 돌아가기