Author: Simon Kapenda
Company: Abba Industries Inc.
- Blockchain: BNB Smart Chain (BSC)
- Chain ID: 56
- Environment: Mainnet
The Kenya 30 Index (KEN30) is deployed using an upgradeable proxy architecture (UUPS), enabling controlled upgrades, governance enforcement, and long-term maintainability.
All core components are deployed on-chain, verified, and operational.
- Contract Name: KEN30Proxy
- Standard: ERC-20 (UUPS Upgradeable)
- Address: 0x9F6d0E7a9e9b3F3b8C2E7C4f9B6A1cD2E4F0F73
- Role: User-facing token contract and primary integration interface
- Contract Name: KEN30Implementation
- Standard: ERC-20 Logic Contract
- Address: 0xf84D3B2e7C9A1f4D2b3E8c7A9B0d1E3F39bB
- Role: Contains core token logic, upgradeable via proxy
- Contract Name: TimelockController
- Address: 0x7A2cF3b9D4E6A1F2c9B3E7d5A4C1F8b2D6E9C01A
- Role: Enforces delayed execution of governance actions and upgrades
- Contract Name: KEN30OracleRegistry
- Address: 0x96DC3A5F2b1E7c4D9A8e6B3C7F5D2A1E797d
- Role: Maintains authorized oracle operators and quorum enforcement
- Contract Name: KEN30PriceUpdater
- Address: 0x8C4A7D1E2f3B6A9C5E7D4F2b1A6c9E3F7Bc
- Role: Submits signed NAV updates to the blockchain
- Contract Name: KEN30ConstituentRegistry
- Address: 0x5E7A3C2F9B1D4A8E6C3F7D2A9B4E1C6F2A8D
- Role: Stores index constituents and weight allocations
- Contract Name: KEN30NAVModule
- Address: 0x3B2F7A9D1C6E4F8A5D3C2B7E9A1F6D4C2E7B
- Role: Computes index value from constituent inputs and oracle feeds
- Address: 0xA1F4C7E9B2D3A6C5E8F1B7D4A9C2E6F3D1A9B7C2
- Role: Holds allocations for liquidity provisioning, ecosystem growth, and operations
-
Address(es):
- 0xB3E7D2A1F9C4E6A8D5B1C7F3A2E9D6C4B8F1A2E3
- 0xC5A9E2D7B1F4C6A3E8D2B7F9A1C4E6D3B2F8A7C1
-
Role: Active liquidity provisioning and order book support
- Address: 0xD7F2A9C4E1B6A3D8C5F7E2A9B1C4D6F3A8E7C2B1
- Role: Integration support, operational expenses, and contingency management
- Address: 0xE1A7C3D9B4F2A6E8C5D1B7F3A9C4E2D6F8A1B3C7
- Role: Secures administrative privileges and governance execution
- Contract: TimelockController
- Address: 0x7A2cF3b9D4E6A1F2c9B3E7d5A4C1F8b2D6E9C01A
- Delay: 48 hours
- Role: Mandatory delay for all upgrade and governance operations
All contracts are:
- Verified on BscScan
- Source code published
- ABI accessible for integration
- Bytecode matched with deployed artifacts
The deployment adheres to institutional-grade standards:
- Upgradeability via UUPS proxy architecture
- Role-based access control (RBAC) enforced
- Oracle-signed NAV updates using EIP-712
- Governance secured via multisig and timelock
- Deterministic deployment and initialization
External systems and exchanges MUST integrate using:
- Primary Contract: 0x9F6d0E7a9e9b3F3b8C2E7C4f9B6A1cD2E4F0F73
All read/write interactions should be routed through the proxy contract.
The Kenya 30 Index (KEN30) is a blockchain-native benchmark index designed to represent the performance of thirty selected companies listed on the Nairobi Securities Exchange (NSE).
KEN30 establishes a programmable, transparent, and tradable benchmark layer that enables real-time market exposure through digital asset infrastructure. The system is designed to operate as a benchmark infrastructure layer rather than as a custodial fund, security issuance vehicle, or investment advisory product.
KEN30 is structured for:
- benchmark representation
- exchange-based trading
- institutional distribution
- structured product integration
- digital market infrastructure
The project is designed to bridge traditional capital markets and blockchain-based financial systems through a deterministic, auditable, and institutionally aligned index framework.
KEN30 is designed to achieve the following objectives:
- provide a transparent and deterministic benchmark for Kenya’s equity market
- enable direct tradability of benchmark exposure through digital trading venues
- support real-time market access through exchange infrastructure
- create an institutional-grade bridge between capital markets and digital asset markets
- support future financial products referencing Kenya’s equity market
KEN30 is therefore not merely an index publication. It is a benchmark infrastructure system designed for operational use in modern financial markets.
Kenya is the largest economy in East Africa and serves as the region’s primary financial, commercial, and logistics hub.
The Kenyan capital markets environment includes:
- the Nairobi Securities Exchange as the leading public securities market in the region
- institutional capital participation through pension funds, insurance firms, banks, and asset managers
- a growing retail investor base
- increasing adoption of digital financial infrastructure
- strong mobile payments penetration and digital transaction familiarity
Despite these structural strengths, Kenya’s market infrastructure lacks a programmable and directly tradable benchmark layer that can be used natively in digital trading environments.
This gap creates fragmentation between:
- traditional capital market indices
- exchange-traded digital infrastructure
- benchmark-linked financial innovation
- cross-border digital capital participation
KEN30 is positioned to address this gap.
Traditional market indices in Kenya function primarily as informational references. They do not provide direct tradable exposure and are not designed for integration into blockchain-based infrastructure or digital market environments.
This creates several limitations:
- index exposure is not directly tradable
- benchmark infrastructure is not programmable
- access remains limited for globally distributed market participants
- integration into digital exchange environments is absent
- structured product innovation based on digital index infrastructure is constrained
As a result, market participants seeking exposure to Kenyan equity performance must rely on indirect, fragmented, or operationally inefficient methods.
KEN30 addresses this problem by combining benchmark representation, on-chain verification, and digital tradability within a single infrastructure layer.
KEN30 provides a blockchain-native benchmark representation of Kenya’s equity market.
The system combines:
- an index methodology framework
- oracle-based NAV calculation
- smart contract infrastructure
- exchange integration capability
- governance controls
- liquidity and market-making architecture
This allows benchmark representation and tradability to coexist in a single system.
KEN30 does not attempt to replicate the legal structure of an ETF, mutual fund, or pooled investment vehicle. Instead, it creates a digital benchmark reference layer capable of being traded, integrated, and licensed.
KEN30 references thirty selected companies listed on the Nairobi Securities Exchange.
Selection criteria include:
- market capitalization
- trading liquidity
- sector representation
- market relevance
- operational continuity
The benchmark is intended to capture broad representation across leading segments of Kenya’s listed equity market.
The full constituent list, methodology definitions, and benchmark assumptions are documented in:
KEN30 operates under a deterministic methodology that is designed to ensure consistency, transparency, and auditability.
The methodology includes:
- fixed constituent selection rules
- weighted index construction
- on-chain constituent registry
- oracle-verified price input process
- governance-controlled rebalancing and adjustments
The methodology is intended to provide a stable and reviewable benchmark structure suitable for institutional scrutiny.
Detailed methodology documentation is available in:
KEN30 is calculated using a deterministic weighted aggregation model designed to ensure transparency, auditability, and consistency across all market conditions.
The index value at time t is defined as:
KEN30_t = ( Σ (P_i × W_i) ) / NORMALIZATION_FACTOR
Where:
- P_i represents the latest valid price of constituent i
- W_i represents the assigned weight of constituent i
- NORMALIZATION_FACTOR ensures consistent scaling of the index
Key properties of the calculation framework:
- deterministic (same inputs always produce same output)
- non-discretionary (no manual intervention in calculation)
- auditable (all inputs and outputs verifiable on-chain)
- governance-controlled (methodology updates require formal approval)
The calculation relies on:
- validated constituent registry
- oracle-submitted price inputs
- quorum-based validation of data
- time-consistent update cycles
The methodology does not depend on discretionary pricing or manual override mechanisms.
Full methodology specification:
- ./METHODOLOGY_SPEC.md
KEN30 is designed as a directional benchmark for Kenya’s listed equity market, providing a consolidated representation of price performance across selected NSE-listed companies.
The benchmark fulfills a role analogous to global indices, including:
- Dow Jones Industrial Average (DJIA)
- S&P 500
- NASDAQ-100
- DAX
- Nikkei 225
KEN30 differs from traditional benchmarks in that it is:
- directly tradable in digital markets
- programmable through smart contracts
- accessible globally through exchange infrastructure
Interpretation of index movement:
- upward movement reflects aggregate positive performance across selected constituents
- downward movement reflects aggregate negative performance or risk-off conditions
KEN30 is therefore both:
- an informational benchmark
- a tradable digital instrument
KEN30 is classified strictly as a benchmark infrastructure instrument.
KEN30 does not represent:
- equity ownership in underlying companies
- debt instruments
- dividend-bearing securities
- units in a collective investment scheme
- exchange-traded fund (ETF) exposure
- pooled capital investment
KEN30 functions as:
- a synthetic representation of market performance
- a reference benchmark
- a tradable index instrument
This classification is critical for:
- regulatory clarity
- institutional integration
- exchange onboarding
KEN30 is deployed on BNB Smart Chain and is implemented through a modular smart contract architecture.
Core components include:
- ERC-20 compatible benchmark token contract
- on-chain constituent registry
- oracle validation and update system
- governance-controlled upgrade mechanism
- role-based access control
Design principles:
- determinism
- transparency
- auditability
- modularity
- institutional review readiness
All system logic is executed on-chain, with off-chain components limited to data sourcing and oracle submission.
External Market Data Sources (NSE Prices)
|
v
Oracle Aggregation Layer
|
v
Signed Data Submission
|
v
On-Chain Validation Logic
|
v
KEN30 Smart Contract System
|
v
Centralized Exchange Integration
|
v
Market Participants (Institutions / Traders)
The architecture separates:
- data sourcing
- validation
- execution
- trading
This separation ensures:
- reduced single-point failure risk
- clear operational boundaries
- audit-friendly structure
KEN30 relies on a structured data integrity framework to ensure reliability of benchmark calculations.
Key controls include:
- multiple independent oracle operators
- cryptographic signing of data submissions
- quorum-based validation (minimum participation threshold)
- rejection of invalid or stale data
- deterministic processing logic
The system does not rely on:
- single data providers
- manual price entry
- discretionary override
Data integrity is enforced through both:
- cryptographic verification
- governance-controlled system rules
NSE Market Data
|
v
Data Aggregation Layer
|
v
Oracle Operators (Signed Payloads)
|
v
Quorum Validation
|
v
On-Chain NAV Update
|
v
Exchange Price Discovery
|
v
Market Participation
Each stage is independently verifiable and auditable.
KEN30 smart contracts provide the execution layer for the benchmark.
Core responsibilities:
- storing constituent registry
- validating oracle submissions
- computing index values
- enforcing governance rules
- enabling token-based representation
Security properties:
- deterministic execution
- access-controlled functions
- upgradeable architecture with governance oversight
The contract system is designed to meet:
- exchange listing requirements
- institutional audit standards
- long-term maintainability
The oracle system provides external data inputs required for index calculation.
Responsibilities include:
- sourcing market prices
- computing benchmark input values
- signing data payloads
- submitting updates to the blockchain
Operational controls:
- multi-operator design
- quorum validation
- signature verification
- update frequency constraints
The oracle system is a critical dependency and is designed to minimize manipulation risk.
KEN30 governance controls all non-static system parameters.
Governance scope includes:
- methodology updates
- constituent changes
- oracle configuration
- contract upgrades
- emergency actions
Governance principles:
- controlled execution
- transparency
- delayed implementation
- auditability
No governance action is executed instantly without review mechanisms.
Proposal Creation
|
v
Governance Review
|
v
Timelock Scheduling
|
v
Mandatory Delay Period
|
v
Execution
|
v
System Update
This ensures predictability and reduces governance risk.
KEN30 is designed for trading within centralized exchange environments, utilizing standard order book-based execution mechanisms.
Primary trading pairs include:
- KEN30 / USDT
- KEN30 / KES
Trading characteristics:
- price discovery occurs through market-driven order matching
- bid/ask spreads are determined by liquidity providers and market conditions
- no redemption mechanism exists linking market price directly to NAV
- NAV acts as a reference metric rather than an enforceable price
The trading model assumes:
- active participation from market makers
- sufficient order book depth
- continuous quoting on both sides of the market
KEN30 is therefore structurally similar to:
- index derivatives in price behavior
- synthetic instruments in exposure characteristics
However, it is distinct in that it is:
- tokenized
- directly tradable
- not contract-based
Relevant documentation:
- ./EXCHANGE_INTEGRATION.md
- ./LISTING_STRATEGY.md
KEN30 operates within a multi-participant digital market structure.
Core participants include:
- centralized exchanges (trading infrastructure providers)
- market makers (liquidity providers)
- institutional participants (capital allocators)
- proprietary trading firms
- retail market participants
The structure is characterized by:
- decentralized participation
- centralized execution venues
- continuous liquidity provision
- price formation driven by supply and demand
There is no central pricing authority.
All pricing emerges from:
- order flow
- liquidity availability
- market sentiment
KEN30 exhibits a dual-value system:
- NAV (Net Asset Value)
- Market Price
NAV:
- calculated from underlying constituent prices
- serves as a benchmark reference
Market Price:
- determined by exchange trading activity
- influenced by liquidity, demand, and sentiment
Key characteristics:
- market price may trade above NAV (premium)
- market price may trade below NAV (discount)
- convergence is not guaranteed
- arbitrage activity may reduce divergence
This behavior is consistent with:
- synthetic instruments
- index-linked derivatives
- exchange-traded benchmark proxies
Understanding this distinction is critical for institutional participants.
KEN30 is designed to support a diverse range of participants:
Institutional Investors:
- capital allocation
- exposure to Kenya’s equity market
Asset Managers:
- portfolio construction
- benchmark referencing
Market Makers:
- liquidity provision
- spread management
Centralized Exchanges:
- trading infrastructure
- custody and settlement
Proprietary Trading Firms:
- arbitrage
- directional strategies
Retail Participants:
- direct trading access
Each participant operates independently but contributes to overall market function.
KEN30 supports multiple institutional and market use cases:
Benchmark Trading:
- direct exposure to index movement
Portfolio Hedging:
- hedging against Kenya equity market movements
Synthetic Exposure:
- accessing equity performance without direct stock ownership
Structured Products:
- index-linked notes and instruments
Market Analysis:
- reference for macro and sector-level analysis
Cross-Border Investment:
- simplified access for global participants
KEN30 functions as a foundational layer for financial product development.
KEN30’s economic value is derived from system-level adoption and utilization.
Primary drivers include:
- trading volume across exchanges
- institutional participation
- demand for benchmark exposure
- structured product integration
- licensing of benchmark methodology
The economic model is not dependent on:
- passive token holding
- intrinsic yield generation
- protocol emissions
Instead, value is driven by:
- utility
- adoption
- market integration
KEN30 generates revenue through structured and contractual mechanisms.
Revenue streams include:
Exchange Revenue Sharing:
- percentage of trading fees
- volume-based rebates
Index Licensing:
- licensing to financial institutions
- licensing to exchanges and platforms
Structured Product Enablement:
- fees from index-linked instruments
Data and Analytics:
- benchmark data distribution
- analytics services
Benchmark Administration:
- governance and methodology services
Revenue is conditional on:
- commercial agreements
- integration success
- market activity
Token trading alone does not guarantee revenue.
KEN30 liquidity is supported through structured participation by market makers.
Framework components:
- initial liquidity allocation
- continuous bid/ask quoting
- spread targets
- depth requirements
Objectives:
- minimize spread volatility
- ensure consistent execution
- maintain order book depth
- support efficient price discovery
Liquidity provisioning is a critical success factor for market stability.
Treasury Allocation
|
v
Market Makers Receive Inventory
|
v
Two-Sided Order Book Quotes
|
v
Spread and Depth Management
|
v
Market Price Formation
Liquidity flows from treasury allocation into active market making, enabling continuous trading.
KEN30 is designed for seamless integration with centralized exchanges.
Integration scope includes:
- token listing
- wallet compatibility
- trading pair configuration
- order book deployment
- liquidity onboarding
Exchange requirements:
- smart contract verification
- security review
- liquidity readiness
- compliance alignment
KEN30 is structured to meet standard exchange onboarding criteria.
Market makers play a central role in maintaining trading efficiency.
Responsibilities include:
- providing continuous bid/ask quotes
- managing inventory exposure
- maintaining target spreads
- supporting price convergence toward NAV
Market making strategies may include:
- passive quoting
- dynamic spread adjustment
- inventory rebalancing
- arbitrage execution
Without active market making, KEN30 liquidity would be significantly reduced.
KEN30 token distribution is structured to support ecosystem stability.
Allocation categories include:
- liquidity provisioning
- institutional allocation
- treasury reserve
- founder and team allocation
Distribution principles:
- alignment with long-term growth
- sufficient liquidity support
- controlled supply release
- avoidance of market imbalance
Detailed allocation is defined in:
- ./TOKEN_DISTRIBUTION.md
KEN30 listing is executed through a structured approach.
Key steps:
- exchange selection
- compliance and technical review
- liquidity preparation
- market maker onboarding
- initial listing and trading activation
Post-listing:
- liquidity monitoring
- spread management
- volume growth
The listing process is designed to ensure:
- stability
- credibility
- institutional readiness
KEN30 security framework spans multiple layers:
Smart Contract Security:
- access control
- input validation
- upgrade safeguards
Oracle Security:
- signed data
- multi-operator validation
Governance Security:
- timelock mechanisms
- controlled execution
Operational Security:
- monitoring and incident response
Security is designed to meet institutional expectations.
KEN30 has undergone internal audit processes covering:
- smart contract logic
- system architecture
- oracle framework
- governance mechanisms
Audit objectives:
- identify vulnerabilities
- validate system integrity
- ensure operational readiness
Documentation:
- ./AUDIT_SCOPE.md
- ./AUDIT_REPORT.md
KEN30 involves multiple categories of risk:
Market Risk:
- price volatility
Liquidity Risk:
- insufficient order book depth
Oracle Risk:
- delayed or incorrect data
Governance Risk:
- improper parameter updates
Exchange Risk:
- platform dependency
Regulatory Risk:
- evolving legal frameworks
Participants must assess these risks prior to engagement.
KEN30 operates within defined boundaries.
The system does not:
- guarantee liquidity availability
- enforce market maker participation
- ensure NAV convergence
- control exchange pricing
- provide capital protection
Understanding these limitations is essential for proper usage.
Oracle Failure → NAV becomes stale
Liquidity Withdrawal → spreads widen
Exchange Delisting → trading unavailable
Governance Failure → parameter misalignment
Failure scenarios impact system performance but do not necessarily compromise underlying contract logic.
KEN30 depends on:
- reliable external market data
- active oracle participation
- exchange listing and continuity
- market maker engagement
- stable regulatory environment
Failure of these dependencies affects system performance.
Abba Industries Inc.:
- governance control
- methodology management
- licensing
Exchanges:
- trading infrastructure
- custody
Market Makers:
- liquidity provision
- price stability
Oracle Operators:
- data submission
- validation
Responsibilities are clearly separated to ensure operational clarity.
Deployment
|
v
Exchange Listing
|
v
Liquidity Bootstrap
|
v
Institutional Adoption
|
v
Market Expansion
KEN30 evolves through defined operational phases.
KEN30 is structured as a benchmark infrastructure layer.
Compliance characteristics:
- non-custodial
- non-fund
- non-security
Regulatory engagement may vary by jurisdiction.
KEN30 is:
- not a security
- not a derivative contract issued by Abba
- not a collective investment scheme
KEN30 is a benchmark reference instrument.
Core documents include:
- ./WHITEPAPER.md
- ./INSTITUTIONAL_PITCH.md
- ./METHODOLOGY_SPEC.md
- ./SMART_CONTRACT_SPEC.md
- ./ORACLE_SPEC.md
Email: admin@ken30.com
WhatsApp: +264-81-250-9027
KEN30 is a benchmark infrastructure instrument.
It does not:
- guarantee returns
- provide investment advice
- represent ownership of assets
Participation is at the user’s own risk.
KEN30 trading is governed by measurable execution-quality metrics designed to ensure consistent liquidity, predictable execution, and alignment with institutional market standards.
All metrics are defined on a rolling time basis unless otherwise specified.
- Mid Price (MP): (Best Bid + Best Ask) / 2
- Spread (%): (Best Ask − Best Bid) / MP × 100
- Depth (Δ%): cumulative notional available within ±Δ% of MP
- Slippage (%): (Execution Price − MP at order arrival) / MP × 100
- ADV: Average Daily Volume over N days (default N = 30)
Targets are enforced on a time-weighted basis (TWAP over 5-minute windows).
- Target (Normal): Spread ≤ 1.00% for ≥ 95% of trading minutes per day
- Target (Stable): Spread ≤ 0.50% for ≥ 80% of trading minutes per day
- Target (High Liquidity): Spread ≤ 0.25% for ≥ 60% of trading minutes per day
Measurement:
- Sample frequency: 1 second snapshots
- Aggregation: 5-minute TWAP, then daily compliance ratio
Breach Levels:
- Level 1: > 1.50% for ≥ 10 consecutive minutes
- Level 2: > 2.50% for ≥ 5 consecutive minutes
- Level 3: > 4.00% for ≥ 2 consecutive minutes
Remediation:
- MM widens inventory bands and re-quotes within 60 seconds
- Treasury may inject inventory within 15 minutes
- Exchange may trigger liquidity incentives for the affected interval
Depth is measured cumulatively on both sides of the book.
Minimums (per side):
Within ±1.00% of MP:
- ≥ $50,000 notional (initial)
- ≥ $100,000 notional (growth)
- ≥ $150,000 notional (mature)
Within ±2.00% of MP:
- ≥ $100,000 (initial)
- ≥ $200,000 (growth)
- ≥ $300,000 (mature)
Within ±5.00% of MP:
- ≥ $250,000 (initial)
- ≥ $400,000 (growth)
- ≥ $600,000 (mature)
Measurement:
- Snapshot every 1 second
- Compliance computed as % of minutes meeting thresholds per day (target ≥ 90%)
Breach Handling:
- If ±2% depth < $100k for ≥ 10 minutes → Level 1
- If ±2% depth < $50k for ≥ 5 minutes → Level 2
- MM required to replenish within 120 seconds
Targets (market orders up to $10,000 notional):
- Slippage ≤ 0.50% for ≥ 90% of executions
- Slippage ≤ 1.00% for ≥ 98% of executions
Measurement:
- Compare execution price vs MP at order arrival timestamp
- Track per order size bucket: $1k, $5k, $10k
Breach:
-
1.50% slippage for ≥ 5% of executions in a day triggers review
Phased targets:
Initial (0–90 days):
- Daily Volume: $100,000 – $500,000
- Turnover Ratio (Volume / Circulating Notional): ≥ 2% daily
Growth (90–180 days):
- $500,000 – $2,000,000
- Turnover ≥ 5% daily
Mature (>180 days):
- ≥ $2,000,000
- Turnover ≥ 8% daily
Measurement:
- Exchange-reported trades
- Exclude wash trades (per exchange policy)
Premium/Discount (%):
- (Market Price − NAV) / NAV × 100
Targets:
- Normal: within ±2.00% for ≥ 90% of minutes
- Volatile: within ±5.00% for ≥ 80% of minutes
Arbitrage Bands:
- Soft band: ±2.00% → MM rebalance
- Hard band: ±5.00% → coordinated MM + treasury action
No hard peg is enforced.
The oracle system must meet availability, latency, and integrity standards.
- Target cadence: every 60 seconds
- High-volatility mode: every 15–30 seconds
- Minimum acceptable: every 120 seconds
Clock Discipline:
- Drift tolerance ≤ 2 seconds between operators
- Quorum: ≥ 2/3 of active operators
- Signature scheme: EIP-712 typed data
- Replay protection: nonce + timestamp
Example:
- 5 operators → quorum = 4
- 7 operators → quorum = 5
- Freshness target: ≤ 120 seconds
- Hard rejection: > 300 seconds old
Outlier Filtering:
- Reject if |price − median| / median > 5% (configurable)
End-to-end (source → on-chain confirmation):
- Target: ≤ 5 seconds
- Max tolerance: ≤ 15 seconds
Components:
- source aggregation
- signing
- broadcast
- block inclusion
- Quorum failure → halt updates; flag “stale NAV”
- Data outage > 5 minutes → governance alert
- Fallback: last valid NAV + staleness indicator
MMs operate under continuous quoting and inventory constraints.
- Uptime: ≥ 95% per 24h
- Max interruption: ≤ 60 seconds per incident
- Continuous two-sided quotes within ±2% bands
Measurement:
- 1-second heartbeat checks from exchange
Minimum committed inventory (per MM):
- Initial: ≥ $50,000
- Growth: $100,000–$250,000
- Mature: ≥ $250,000
Inventory Limits:
- Net position band: ±40% of allocated inventory
- Rebalance trigger: ±60%
- Maintain ≤ 1.00% spread for ≥ 95% of minutes
- Tighten to ≤ 0.50% during high-liquidity periods
Minimum levels per side:
- ≥ 5 price levels within ±2%
- ≥ 10 price levels within ±5%
Order sizing:
- geometric or linear laddering
- avoid single-point liquidity
- Maker rebates per exchange schedule
- Performance scorecard (spread, depth, uptime)
- Penalties: reduced allocation or replacement for sustained breaches
- Minimum: $150,000
- Recommended: $300,000 – $500,000
Allocation:
- 40–60% to primary MMs
- 20–30% treasury buffer
- 10–20% contingency
Phase 1 (T0–T+30):
- Focus on spread ≤ 1.00%, depth at ±2% ≥ $100k
Phase 2 (T+30–T+90):
- Increase depth targets; reduce spread toward 0.50%
Phase 3 (T+90+):
- Expand to additional venues; tighten spreads further
- Daily inventory check
- Weekly treasury adjustment
- Event-driven (volatility spikes)
- Avg spread ≤ 1.00%
- 95th percentile ≤ 1.50%
- ≥ $100k within ±2% (≥ 90% of minutes)
- ≥ $250k within ±5% (≥ 85% of minutes)
- ≥ $250k daily within first 60 days
- ≥ $500k by day 90
- NAV deviation within ±2% for ≥ 85% of minutes
- No Level 3 spread breaches
Reporting:
- Daily dashboards
- Weekly KPI reports
- Standard changes: 24–72 hours
- Critical: ≥ 72 hours
- Multi-sig approval (threshold ≥ 2/3)
- Pre-upgrade audit required
- Staged rollout (canary where applicable)
- Rollback path defined
- Normal: ≤ 5% daily
- Elevated: 5–15%
- Extreme: > 15%
Actions:
- Elevated → tighten spreads, increase depth
- Extreme → widen bands, prioritize stability
- ±2% depth < $100k → alert
- ±2% depth < $50k → intervention
- Missed updates > 2 intervals → alert
- Quorum loss → halt NAV updates
- Smart contract determinism: 100% (no nondeterministic paths)
- Oracle availability: ≥ 99%
- Exchange connectivity (MM): ≥ 99%
- Overall system uptime: ≥ 99.5%
Monitoring:
- real-time metrics
- alerting thresholds
- incident logs
Scaling is assessed via:
- volume growth (target CAGR ≥ 10% monthly early phase)
- spread compression over time
- depth expansion per phase
Expansion Triggers:
- add venues when ADV ≥ $1M
- add MMs when spread targets unmet for ≥ 3 days
All metrics are:
- timestamped (UTC)
- source-attributed (exchange/oracle)
- auditable
Reports:
- Daily: spread, depth, volume, uptime
- Weekly: KPI compliance, breaches, actions
- Monthly: trend analysis, scaling decisions
Data Retention:
- minimum 90 days granular
- 12 months aggregated
End of Document