# Research-Driven, Mathematically Verified {% hint style="info" %} Operator and jurisdiction: BASIS is operated by BASIS DIGITAL INFRASTRUCTURE LTD, a Seychelles IBC (LEI: [254900IX2F2KCWNSSS64](https://lei.bloomberg.com/leis/view/254900IX2F2KCWNSSS64)). Research Partner: Base58 Labs contributes execution research, systems modeling, and risk design. {% endhint %} BASIS is built on a simple premise: > Alpha is found in the residuals, the gap between where markets should price and where they temporarily price because of microstructure, latency, and fragmented liquidity. The platform is designed to convert those residuals into structural alpha capture through deterministic execution precision, strict mathematical constraints, and state machine risk controls inside an institutional-grade operating environment supported by active ISO/IEC 27001:2022 and ISO/IEC 20000-1:2018 management systems. This page explains what research-driven and mathematically verified mean in practice. ## 1) Research-driven means hypothesis → measurement → deployment {% stepper %} {% step %} #### 1. Falsifiable hypothesis Every strategy begins with a claim that can be tested and rejected. Example: cross-venue price gaps persist when latency, inventory limits, or venue-specific constraints prevent immediate convergence. {% endstep %} {% step %} #### 2. Measurement design A valid hypothesis requires a defined observation plan: * required datasets * sampling frequency * venue conditions * liquidity regimes * latency windows * failure cases {% endstep %} {% step %} #### 3. Cost model Observed edge is not enough. BASIS models whether the edge survives: * execution fees * slippage * routing delay * inventory cost * funding cost * settlement cost {% endstep %} {% step %} #### 4. Deployment constraints A strategy is not enabled unless it satisfies minimum evidence thresholds and defined operating boundaries. That includes: * venue health thresholds * minimum order book depth * hedge completion windows * exposure caps * reconciliation rules * shutdown conditions {% endstep %} {% endstepper %} A research-driven system does not begin with a promise of return. It begins with measurable claims, conservative assumptions, controlled deployment conditions, and operating standards designed for repeatability, auditability, resilience, and internationally certified service discipline. {% hint style="success" %} Research Partner: Base58 Labs Base58 Labs contributes microstructure research, execution heuristics, risk models, and validation methodology. BASIS productizes that research into a controlled operating environment. {% endhint %} ## 2) Mathematically verified means explicit invariants, not opaque logic In BASIS, mathematically verified refers to the structure of decision-making. It does not imply a guarantee of profit. It means strategy behavior is constrained by formal rules that must hold before, during, and after execution. This approach aligns with the broader operating discipline of the platform: explicit controls, verifiable processes, and active ISO/IEC 27001:2022 and ISO/IEC 20000-1:2018 management systems that support secure and reliable service delivery. {% tabs %} {% tab title="Pre-trade invariants" %} Before execution, BASIS checks whether the trade is eligible at all. Typical conditions include: * expected value remains positive under conservative assumptions * minimum depth is available at the intended size * venue health is acceptable * projected slippage stays within limits * exposure after execution remains below risk caps {% endtab %} {% tab title="In-trade invariants" %} During execution, BASIS validates that the trade path remains consistent with its modeled assumptions. Typical conditions include: * hedge completion occurs within the allowed time window * fill symmetry stays within tolerance * routing remains within latency constraints * inventory drift stays bounded * abnormal venue behavior triggers cancellation or fallback {% endtab %} {% tab title="Post-trade invariants" %} After execution, BASIS verifies that the result can be reconciled and safely carried. Typical conditions include: * fills reconcile with expected positions * accounting entries match execution records * net exposure remains inside limits * settlement state is internally consistent * PnL attribution is explainable by recorded events {% endtab %} {% endtabs %} ### Expected value discipline A minimal decision model for a single execution slice is: $$ EV \approx Edge - Fees - Slippage - Latency\_{Penalty} - InventoryCost - SettlementCost $$ A trade is eligible only if EV remains positive after conservative buffers are applied. | Component | Meaning | | ------------------ | ----------------------------------------------------------------- | | Edge | Quoted price gap, funding differential, or structural dislocation | | Fees | Venue fees plus deterministic platform fees where applicable | | Slippage | Expected impact from depth, queue position, and size | | Latency\_{Penalty} | Risk that the opportunity decays before hedge completion | | InventoryCost | Cost of carrying temporary directional exposure | | SettlementCost | Transfer, gas, or asset movement cost when relevant | Known platform fee inputs are deterministic: | Action | Fee | | ---------- | ----- | | Deposit | 0% | | Withdrawal | 0.05% | | Swap | 0.01% | ### State machine enforcement BASIS uses state-machine style controls to reduce discretionary behavior and tighten risk boundaries. ``` if venue_health != "healthy": reject if expected_value <= safety_buffer: reject if orderbook_depth < min_required_depth: reject if projected_exposure > exposure_cap: reject if hedge_window > max_allowed_window: reject execute() reconcile() archive_audit_state() ``` {% hint style="info" %} Execution layer: BHLE The Base58 Hyper-Latency Engine (BHLE) operates with sub-50μs internal latency targets, 100K+ OPS throughput, and proprietary routing infrastructure designed for deterministic execution precision. {% endhint %} ## 3) What BASIS verifies, and what it does not verify | Category | BASIS verifies | BASIS does not verify | | --------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------- | | Strategy process | Hypothesis testing, evidence thresholds, deployment constraints | That every market condition will remain favorable | | Risk controls | Exposure caps, slippage bounds, venue health checks, shutdown rules | That third-party venues will never fail or halt | | Execution | Routing constraints, hedge windows, reconciliation logic | That all external fills will always be available at the modeled price | | Accounting | Deterministic wallet logic, conversion rules, balance reconciliation | That external assets will never depeg or change market behavior | | Operating environment | Documented security and service management processes operating under active ISO/IEC 27001:2022 and ISO/IEC 20000-1:2018 certifications | That no operational incident can ever occur | Therefore, verified should be read as verified process, verified constraints, and verified accounting behavior. It should not be read as guaranteed profit. ## 4) Verified accounting primitives The accounting model on BASIS is intentionally narrow and testable. | Native asset | Deposit method | Staking representation | Conversion rule | | ------------ | -------------------------------------------------------------- | ---------------------- | -------------------- | | BTC | Copy the BASIS-assigned deposit address unique to your account | stBTC | BTC → stBTC at 1:1 | | ETH | Connect a Web3 wallet such as MetaMask | stETH | ETH → stETH at 1:1 | | SOL | Connect a supported Web3 wallet | stSOL | SOL → stSOL at 1:1 | | PAXG | Connect a Web3 wallet | stPAXG | PAXG → stPAXG at 1:1 | Core wallet roles: * Funding Wallet holds native assets for deposit and withdrawal * Staking Wallet holds stTokens for staking and reward accumulation These rules are intentionally restrictive: * swaps are same-token only * conversions are 1:1 only * USDT is display-only for accounting * rewards accumulate in real time as the same stToken * unstake is full-position only * claimable balances are auto-credited to the Staking Wallet as stToken This narrow accounting surface makes reconciliation and auditability materially stronger, and it supports the controlled service model expected of an institutional-grade platform. ## 5) From research to product {% tabs %} {% tab title="Research" %} Base58 Labs studies: * market microstructure * fragmented liquidity behavior * routing heuristics * execution precision models * state-transition risk models {% endtab %} {% tab title="Infrastructure" %} BASIS implements: * deterministic execution pathways * BHLE routing and matching logic * observability and replay tooling * math-constrained eligibility checks * automated fail-safe states {% endtab %} {% tab title="Product controls" %} The user-facing product exposes only controlled workflows: * native asset funding * same-token 1:1 staking conversion * monitored staking positions * referral network reporting * support and account operations {% endtab %} {% endtabs %} This documentation preserves that separation: * research sections explain the theoretical core * platform sections explain controlled user operations * risk sections explain the limits of the system * operating controls are designed to support secure, reliable, and publicly verifiable service delivery within an internationally certified operating framework ## 6) Practical reading 📘 Recommended reading order: 1. Core Philosophy 2. Spatial Arbitrage (BQAE) 3. Risk Model 4. Economics --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.basis.pro/welcome/research-and-verification.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.