Research-Driven, Mathematically Verified

Operator and jurisdiction: BASIS is operated by BASIS DIGITAL INFRASTRUCTURE LTD, a Seychelles IBC (LEI: 254900IX2F2KCWNSSS64).

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

1

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.

2

2. Measurement design

A valid hypothesis requires a defined observation plan:

• required datasets

• sampling frequency

• venue conditions

• liquidity regimes

• latency windows

• failure cases

3

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

4

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

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.

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.

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.

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

In-trade invariants

Post-trade invariants

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()

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.

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

Research

Base58 Labs studies:

• market microstructure

• fragmented liquidity behavior

• routing heuristics

• execution precision models

• state-transition risk models

Infrastructure

Product controls

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