Block Street 백서

Block Street

원문

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
프로젝트로 돌아가기