# Overview {% 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 a research-driven structural alpha platform built from the work of Base58 Labs. Base58 Labs acts as the research engine: it studies market microstructure, execution risk, and the mathematical conditions under which alpha exists in crypto market residuals. BASIS is the execution layer: it turns those research outputs into user-facing strategies that are operationally simple, risk-aware, and continuously monitored. BASIS is operated with an institutional-grade control framework and internationally certified management systems. BASIS DIGITAL INFRASTRUCTURE LTD maintains active ISO/IEC 27001:2022 certification for information security management and active ISO/IEC 20000-1:2018 certification for IT service management. The ISO/IEC 27001:2022 certification remains active with a last updated date of March 27, 2026, and both certifications are publicly verifiable on IAF CertSearch. ## What BASIS is BASIS is designed to pursue market-neutral returns by capturing objective market inefficiencies such as price gaps, funding differentials, liquidity fragmentation, and execution precision opportunities rather than predicting the direction of BTC, ETH, SOL, or PAXG. It prioritizes Execution First: fill quality, latency discipline, and slippage control, alongside Capital Preservation: risk constraints, circuit breakers, and conservative operating rules. These principles are embedded in the platform’s strategy matrix, risk engine, operating policies, and the certified operational management systems maintained by BASIS DIGITAL INFRASTRUCTURE LTD. ## What you will find in this GitBook This GitBook is written as both: 1. A whitepaper-grade operating manual explaining the system architecture, economics, risk controls, and operational model 2. A user guide showing how to onboard, deposit, stake, unstake, and withdraw Navigation is organized by decision path: * New user: start with Getting Started and Risk Disclosure * Investor or allocator: start with Whitepaper and Economics & Rewards * Technical reviewer: start with Technical Architecture and Risk Management * PAXG user: start with PAXG Integration ## Non-negotiable definitions BASIS uses precise definitions to avoid ambiguity: * Market neutral does not mean risk-free. Strategies are designed to minimize directional exposure, but execution, operational, and counterparty risks remain. * Mathematically verified means strategy logic is expressed through constraints and invariants across pre-trade, in-trade, and post-trade states, then tested against defined failure modes. It does not mean returns are guaranteed. * Quantity preservation means 1:1 conversion between supported native assets and staking tokens for principal accounting: * BTC ↔ stBTC * ETH ↔ stETH * SOL ↔ stSOL * PAXG ↔ stPAXG ## Quickstart checklist {% stepper %} {% step %} Read Risk Disclosure, especially valuation conventions, system states, lock-up rules, and operational assumptions. {% endstep %} {% step %} Create an account using email code login. {% endstep %} {% step %} Deposit supported native assets into your Funding Wallet: * BTC via your BASIS-assigned deposit address * ETH, SOL, or PAXG via connected Web3 wallet {% endstep %} {% step %} Swap native assets 1:1 into staking tokens: * BTC → stBTC * ETH → stETH * SOL → stSOL * PAXG → stPAXG {% endstep %} {% step %} Stake from your Staking Wallet and monitor rewards in real time. {% endstep %} {% step %} When the lock-up ends, unstake the full position. Claimable rewards are auto-credited to the Staking Wallet as the same stToken. {% endstep %} {% endstepper %} ## Wallet model | Wallet | Asset type | Purpose | | -------------- | ------------- | --------------------------------------------------- | | Funding Wallet | Native tokens | Deposit, hold, withdraw | | Staking Wallet | stTokens | Stake, earn, receive auto-credited unstake proceeds | {% hint style="success" %} Supported deposit assets: BTC, ETH, SOL, PAXG USDT is used only as an internal accounting and display unit. It cannot be deposited or withdrawn. BASIS operates under active ISO/IEC 27001:2022 and ISO/IEC 20000-1:2018 management system certifications held by BASIS DIGITAL INFRASTRUCTURE LTD. {% endhint %} ## Core mechanics ### Deposits {% tabs %} {% tab title="BTC" %} * Copy your unique BASIS-assigned BTC deposit address * No Web3 wallet connection is required * No minimum deposit {% endtab %} {% tab title="ETH / SOL / PAXG" %} * Connect a supported Web3 wallet such as MetaMask * Deposit the native asset directly into your Funding Wallet * PAXG support is active {% endtab %} {% endtabs %} ### Swap Swaps are same-token only and always 1:1: | Native asset | Staking token | | ------------ | ------------- | | BTC | stBTC | | ETH | stETH | | SOL | stSOL | | PAXG | stPAXG | No cross-asset swap path is supported inside the staking conversion flow. ### Fees | Action | Fee | | ---------- | ----- | | Deposit | 0% | | Withdrawal | 0.05% | | Swap | 0.01% | ### Withdrawal timing | Asset | Typical processing time | | ----- | ----------------------- | | BTC | 10 to 60 minutes | | ETH | 1 to 10 minutes | | SOL | 1 to 10 minutes | | PAXG | 1 to 10 minutes | ## Staking, rewards, and lock logic ### Booster schedule | Lock period | Booster | | ----------- | ---------- | | 14D | +10% | | 30D | +20% | | 90D | +50% | | 180D | +100% (2×) | ### Fixed pool rules * Rewards accumulate in real time as the same stToken * Rewards appear in the Staking Wallet when unstake is executed * Fixed pools can be unstaked only after the lock-up period ends * No early exit option is available * Unstake is full-position only and executes as auto-MAX {% hint style="warning" %} If you stake stBTC, rewards accrue as stBTC. If you stake stETH, rewards accrue as stETH. If you stake stSOL, rewards accrue as stSOL. If you stake stPAXG, rewards accrue as stPAXG. {% endhint %} ## Dashboard structure The dashboard is organized into the following sections: * Stake * Assets * Referral * Support * Account ## Status, change control, and trust This documentation is versioned. When policies change, including fees, thresholds, supported assets, or risk triggers, BASIS publishes: * A changelog entry * The effective date * Backward-compatibility notes where relevant See Changelog for the canonical record. ## Operating and technical trust model BASIS emphasizes deterministic execution, mathematical constraints, state-machine risk controls, and certified operational governance. Key trust anchors include: * Seychelles IBC operating entity * [LEI: 254900IX2F2KCWNSSS64](https://lei.bloomberg.com/leis/view/254900IX2F2KCWNSSS64) * Base58 Labs research foundation * Structural alpha methodology * Deterministic execution controls * Constraint-based risk enforcement * State-machine monitoring for abnormal conditions * Active ISO/IEC 27001:2022 certification for information security management * Active ISO/IEC 20000-1:2018 certification for IT service management * Public certification verification through IAF CertSearch * Public certified entity record for BASIS DIGITAL INFRASTRUCTURE LTD on IAF CertSearch ### BHLE execution environment BASIS infrastructure includes BHLE characteristics designed for execution precision: * Sub-50μs latency * 100K+ OPS * Proprietary routing infrastructure This architecture supports disciplined fill quality, routing efficiency, and low-latency strategy execution under defined risk constraints. *** ## About the Operator | | | | ------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Legal Name | BASIS DIGITAL INFRASTRUCTURE LTD | | Company No | 248559 | | Incorporated | 4th February 2026, Victoria, Seychelles | | Governing Law | International Business Companies Act, 2016 | | Address | Room 306, Victoria House, P.O Box 673, Victoria, Mahe, Seychelles | | LEI | [254900IX2F2KCWNSSS64](https://lei.bloomberg.com/leis/view/254900IX2F2KCWNSSS64) | | Research Partner | Base58 Labs, London, UK | | ISO/IEC 27001:2022 | Active certification held by BASIS DIGITAL INFRASTRUCTURE LTD, public verification: [IAF CertSearch](https://www.iafcertsearch.org/certification/VDrwBpB8mD2nw5ykj5zxSANH) | | ISO/IEC 27001:2022 Last Updated | March 27, 2026 | | ISO/IEC 20000-1:2018 | Active certification held by BASIS DIGITAL INFRASTRUCTURE LTD, public verification: [IAF CertSearch](https://www.iafcertsearch.org/certification/1IbVSdVuBbykRHSgkfAo8mBE) | | Certified Entity Record | [IAF CertSearch Entity Listing](https://www.iafcertsearch.org/certified-entity/WTmKlSOrxvhkPKrCUIdWYEgv) | | Contact | | *** If you are reading this documentation for allocation or operating decisions, do not skip: * Risk Disclosure * Unstaking & Asset Protection * PAXG Risk Addendum For legal documents, see the [Legal & Corporate](/legal-and-corporate/corporate-structure) section. # Legal Entity & Currency {% 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 %} This page clarifies: 1. who operates BASIS 2. how balances and reports are displayed 3. how display currency differs from supported deposit and withdrawal assets ## 1. Operator, jurisdiction, certifications, and operational context BASIS is operated by BASIS DIGITAL INFRASTRUCTURE LTD, a Seychelles IBC. The platform combines deterministic execution, math-constrained routing, and state machine risk controls. Research support is provided by Base58 Labs, referenced in documentation as the Research Partner. This infrastructure is designed for execution precision and structural alpha capture. BASIS is built and operated within an institutional-grade control environment. BASIS DIGITAL INFRASTRUCTURE LTD is the certified entity for active ISO/IEC 27001:2022 and ISO/IEC 20000-1:2018 certifications, both publicly verifiable through IAF CertSearch. The ISO/IEC 27001:2022 public record is active and shows a last updated date of March 27, 2026. | Operator profile | Detail | | ----------------------- | ----------------------------------------------------------------------------------------------------------------------------- | | Operator | BASIS DIGITAL INFRASTRUCTURE LTD | | Jurisdiction | Seychelles IBC | | Address | Room 306, Victoria House, P.O Box 673, Victoria, Mahe, Seychelles | | LEI | [254900IX2F2KCWNSSS64](https://lei.bloomberg.com/leis/view/254900IX2F2KCWNSSS64) | | Certified entity record | [Entity Record on IAF CertSearch](https://www.iafcertsearch.org/certified-entity/WTmKlSOrxvhkPKrCUIdWYEgv) | | ISO/IEC 27001:2022 | Active. Public verification: [Verify on IAF CertSearch](https://www.iafcertsearch.org/certification/VDrwBpB8mD2nw5ykj5zxSANH) | | ISO/IEC 20000-1:2018 | Active. Public verification: [Verify on IAF CertSearch](https://www.iafcertsearch.org/certification/1IbVSdVuBbykRHSgkfAo8mBE) | {% hint style="success" %} BHLE infrastructure targets sub-50μs latency, 100K+ OPS, and proprietary routing across supported venues and networks. {% endhint %} This matters because the operator framework governs: * terms of service * risk disclosures * compliance handling * dispute processes * service availability and restricted jurisdictions * dependencies on exchanges, blockchain networks, custodial workflows, and on-chain protocols ## 2. Currency convention: USDT as the unit of account BASIS displays portfolio values in USDT for internal accounting and reporting consistency. USDT on BASIS is: * a display unit * an accounting reference * a reporting convention for examples, balances, and analytics USDT on BASIS is not: * a supported deposit asset * a supported withdrawal asset * a settlement guarantee in fiat USD ### Why this convention exists A single accounting unit helps standardize: * portfolio valuation * reporting across BTC, ETH, SOL, and PAXG * reward visualization * historical performance comparisons * operational thresholds and policy references The use of a single internal reporting unit also supports consistent service operations, reconciliation, and dashboard interpretation across a controlled operating environment with active ISO/IEC 27001:2022 and ISO/IEC 20000-1:2018 certifications publicly listed for BASIS DIGITAL INFRASTRUCTURE LTD. ## 3. Supported asset flows | Wallet | Asset type | Function | | -------------- | --------------------------- | ------------------------------------ | | Funding Wallet | BTC, ETH, SOL, PAXG | Native asset deposit and withdrawal | | Staking Wallet | stBTC, stETH, stSOL, stPAXG | Staking positions and reward accrual | {% tabs %} {% tab title="Deposits" %} * BTC deposit: copy the BASIS-assigned BTC address for your account * BTC does not require a Web3 wallet connection * ETH, SOL, PAXG deposit: connect a supported Web3 wallet such as MetaMask * No minimum deposit * Deposit fee: 0% * USDT cannot be deposited {% endtab %} {% tab title="Swaps" %} Swaps are same-token only, at 1:1. * BTC → stBTC * ETH → stETH * SOL → stSOL * PAXG → stPAXG Swap fee: 0.01% {% endtab %} {% tab title="Withdrawals" %} * Native assets withdraw from the Funding Wallet * Withdrawal fee: 0.05% * Typical processing time: * BTC: 10 to 60 minutes * ETH, SOL, PAXG: 1 to 10 minutes * USDT cannot be withdrawn {% endtab %} {% endtabs %} ## 4. What “USD-equivalent” means When documentation references USD-equivalent values, it means balances are displayed using USDT as the internal unit of account for practical reporting. This does not mean: * a fiat USD bank balance * guaranteed redemption at 1:1 with USD * elimination of stablecoin valuation risk USDT may trade above or below 1 USD. Users should treat displayed values as accounting references, not cash equivalents. {% hint style="warning" %} ⚠️ Display value and settlement asset are different concepts. Settlement and custody occur in supported native assets and stTokens. Reporting may be shown in USDT-equivalent terms for consistency across the dashboard. {% endhint %} ## 5. How displayed values should be interpreted | Displayed value | Interpretation | | -------------------------- | -------------------------------------------------------------------------- | | 50,000 USDT | Internal display value intended for USD-equivalent reporting | | BTC balance shown in USDT | Native BTC position translated into USDT for reporting | | Reward value shown in USDT | stToken-denominated rewards translated into USDT for reporting convenience | If a balance is shown in USDT, that does not change the underlying asset type. Examples: * BTC remains BTC in the Funding Wallet * stBTC remains stBTC in the Staking Wallet * PAXG remains PAXG in the Funding Wallet * stPAXG remains stPAXG in the Staking Wallet ## 6. Operational interpretation across the dashboard The dashboard is organized into: * Stake * Assets * Referral * Support * Account Across these sections: * Funding Wallet holds native assets used for deposit and withdrawal * Staking Wallet holds stTokens used to stake and earn * rewards accumulate in real time as the same stToken * fixed pools can be unstaked only after the lock-up period ends * unstake is full-position only * claimable amounts are auto-credited to the Staking Wallet as stToken upon unstake ### Booster reference | Lock period | Booster | | ----------- | ------- | | 14D | +10% | | 30D | +20% | | 90D | +50% | | 180D | +100% | ## 7. User checklist {% stepper %} {% step %} Confirm the operator details for BASIS DIGITAL INFRASTRUCTURE LTD and the Seychelles IBC legal framework. {% endstep %} {% step %} Understand that USDT is a display and accounting unit only. It is not a deposit or withdrawal asset. {% endstep %} {% step %} Use the correct wallet flow: * Funding Wallet for BTC, ETH, SOL, PAXG * Staking Wallet for stBTC, stETH, stSOL, stPAXG {% endstep %} {% step %} For BTC deposits, use the BASIS-assigned deposit address. For ETH, SOL, and PAXG deposits, connect a supported Web3 wallet. {% endstep %} {% step %} Read the Risk Disclosure and the PAXG Risk Addendum if you use PAXG. {% endstep %} {% step %} If needed, independently verify the operator's active certifications on IAF CertSearch: * Certified entity record: [Entity Record on IAF CertSearch](https://www.iafcertsearch.org/certified-entity/WTmKlSOrxvhkPKrCUIdWYEgv) * ISO/IEC 27001:2022: [Verify on IAF CertSearch](https://www.iafcertsearch.org/certification/VDrwBpB8mD2nw5ykj5zxSANH) * ISO/IEC 20000-1:2018: [Verify on IAF CertSearch](https://www.iafcertsearch.org/certification/1IbVSdVuBbykRHSgkfAo8mBE) {% endstep %} {% endstepper %} ## 8. Summary | Field | Details | | ------------ | -------------------------------------------------------------------------------- | | Operator | BASIS DIGITAL INFRASTRUCTURE LTD | | Jurisdiction | Seychelles IBC | | Address | Room 306, Victoria House, P.O Box 673, Victoria, Mahe, Seychelles | | LEI | [254900IX2F2KCWNSSS64](https://lei.bloomberg.com/leis/view/254900IX2F2KCWNSSS64) | | Item | Details | | ---------------------------- | --------------------------- | | Display unit | USDT | | Depositable assets | BTC, ETH, SOL, PAXG | | Withdrawable assets | BTC, ETH, SOL, PAXG | | Staking assets | stBTC, stETH, stSOL, stPAXG | | Deposit fee | 0% | | Withdrawal fee | 0.05% | | Swap fee | 0.01% | | ISO/IEC 27001:2022 | Active | | ISO/IEC 27001 last updated | March 27, 2026 | | ISO/IEC 20000-1:2018 | Active | | IAF CertSearch entity record | Available | If documentation examples use USDT values, interpret them as internal reporting references only. Actual asset movement on BASIS is native-token based in the Funding Wallet and stToken based in the Staking Wallet. ## Supporting Entity: Base58 Labs LTD (United Kingdom) BASIS's execution infrastructure is developed by Base58 Labs LTD, a UK-registered private limited company (Company No. 17094713), with its registered office at 399-405 Oxford Street, Mayfair, London, W1C 2BU. Base58 Labs LTD is publicly verifiable through the UK Companies House register at: This supporting entity is distinct from the platform operator and certified entity, which is BASIS DIGITAL INFRASTRUCTURE LTD. BASIS DIGITAL INFRASTRUCTURE LTD's internationally accredited certifications are publicly verifiable on IAF CertSearch: * Certified entity: [Entity Record on IAF CertSearch](https://www.iafcertsearch.org/certified-entity/WTmKlSOrxvhkPKrCUIdWYEgv) * ISO/IEC 27001:2022: Active. Public verification: [Verify on IAF CertSearch](https://www.iafcertsearch.org/certification/VDrwBpB8mD2nw5ykj5zxSANH) * ISO/IEC 20000-1:2018: Active. Public verification: [Verify on IAF CertSearch](https://www.iafcertsearch.org/certification/1IbVSdVuBbykRHSgkfAo8mBE) *** # 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 # Base58 Labs Research Domains {% 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 %} {% hint style="success" %} BASIS research is centered on deterministic execution, structural alpha capture, and machine-enforced risk controls. The BHLE stack targets sub-50μs latency, 100K+ OPS, and proprietary routing infrastructure for execution precision across fragmented venues. {% endhint %} Base58 Labs is an independent research institute providing quantitative analysis to the BASIS ecosystem. BASIS DIGITAL INFRASTRUCTURE LTD solely operates the execution and product infrastructure. Base58 Labs develops the measurement frameworks, execution logic, and risk models that support the platform under both normal and stressed conditions. ## Research map | Domain | Primary question | Product impact | | -------------------------------------------- | ---------------------------------------------------------- | ----------------------------------------------------------------------- | | Market microstructure | What is the true executable price at size? | Venue scoring, slippage control, fill quality | | Transaction ordering and execution precision | How do on-chain ordering conditions change expected value? | Routing, protection against execution leakage, structural alpha capture | | Smart contract security | What must remain true under all state transitions? | Safer staking, wallet accounting, contract integrations | | BHLE execution science | How fast and how accurately can the system react? | Sub-50μs decision paths, 100K+ OPS throughput, lower hedge drift | | Risk systems | When should the system constrain, pause, or stop? | Deterministic safety behavior, state machine controls | | Research-to-product pipeline | How does research become production safely? | Controlled rollout, monitoring, reporting discipline | ## 1. Market Microstructure 🔬 Base58 Labs treats price as an output of market structure, not a static number on a screen. {% tabs %} {% tab title="What is studied" %} * Order book depth and imbalance * Tick size and spread behavior * Queue priority and matching engine rules * Latency asymmetry and information decay * Toxic flow and adverse selection {% endtab %} {% tab title="Why it matters to BASIS" %} Most spread-based models fail when they ignore executable depth. A quoted spread is not realizable return if the book cannot absorb size without slippage. Microstructure research defines execution constraints, position sizing rules, and venue quality scores used by BASIS. {% endtab %} {% endtabs %} ## 2. Transaction Ordering and Execution Precision ⚙️ On-chain markets are shaped by block-space competition, mempool visibility, and routing path quality. Base58 Labs studies: * how transaction ordering changes realized execution quality * how routing choices affect leakage, reordering risk, and fill certainty * which path constructions preserve structural alpha capture under congestion * how gas, confirmation timing, and state changes alter expected value {% hint style="warning" %} Cross-venue structural alpha capture requires on-chain legs to be modeled as full execution problems. If ordering risk and gas are not priced explicitly, expected value can collapse even when the headline spread looks attractive. {% endhint %} ## 3. Smart Contract Security and Formal Reasoning 🛡️ For any yield system, one critical vulnerability can dominate years of performance. Base58 Labs focuses on: * invariant-driven system design * rigorous review and adversarial testing * formal reasoning for critical accounting and custody flows * math constraints that define valid state transitions * failure isolation for wallet, swap, stake, and unstake logic ### Security posture in practice {% hint style="info" %} **Core Trust Assumptions** 1. State transitions must be deterministic 2. Invalid transitions must be rejected by construction 3. Accounting must reconcile at every boundary 4. Risk controls must be enforceable by system state, not operator preference {% endhint %} This approach is especially important wherever BASIS issues or manages staking receipts such as stBTC, stETH, stSOL, and stPAXG. ## 4. BHLE Execution Science Execution quality determines realized return. Base58 Labs studies: * signal-to-order latency budgets * slippage distributions during stress * order slicing and completion logic * hedge timing and partial-fill handling * venue handoff and failover behavior {% hint style="info" %} BHLE infrastructure characteristics: * Sub-50μs latency targets * 100K+ OPS processing capacity * Proprietary routing infrastructure * Deterministic execution paths where possible {% endhint %} Why this matters to BASIS: * theoretical edge must survive live market conditions * routing quality directly affects fill certainty and execution precision * latency discipline reduces drift between signal, order, and hedge completion ## 5. Risk Systems and State Machines Base58 Labs treats risk controls as executable logic. Core areas of study: * state machines for operating modes * eligibility gates and hard constraints * automated stop conditions * incident playbooks translated into system behavior * reconciliation controls across funding and staking layers ### Example control model {% hint style="warning" %} **Operating Mode Transitions** Return to a less restrictive state requires policy checks, reconciliation, and operator approval. {% endhint %} | Mode | Description | | ------ | --------------------------------------------------------- | | NORMAL | Standard operation within defined limits | | BSCB | Constrained mode with tighter bounds and reduced activity | | DMM | Defensive mode with capital-preservation priority | This is how BASIS builds trust through deterministic safety behavior rather than discretionary reaction. ## 6. Research-to-Product Pipeline The pipeline is intentionally disciplined. {% stepper %} {% step %} **Hypothesis and measurement** Research begins with a clearly defined hypothesis, measurable variables, and data quality checks. {% endstep %} {% step %} **Cost model and expected value gates** The idea must survive fee, latency, slippage, gas, and failure-cost modeling before any production consideration. {% endstep %} {% step %} **Failure modes and stop conditions** The team defines what can go wrong, what must remain true, and exactly when the system should constrain or stop. {% endstep %} {% step %} **Limited deployment with monitoring** Changes are introduced at small scale with reconciliation, latency telemetry, and exception monitoring. {% endstep %} {% step %} **Rollout and reporting discipline** Only after performance and safety conditions are met does the research graduate into wider production use. {% endstep %} {% endstepper %} ## Why this framework matters BASIS is built around: * measurable execution precision * structural alpha capture under explicit constraints * deterministic system behavior * machine-enforced risk controls * research-led iteration through Base58 Labs Next: continue to the Research Library for deeper theoretical and implementation-level material. # Trust Framework {% 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 %} {% hint style="success" %} Research context: Base58 Labs acts as a Research Partner supporting execution research, systems validation, and control design. {% endhint %} Trust in an execution platform is an engineering property. On BASIS, trust is built from deterministic execution, mathematical constraints, explicit state transitions, conservative risk controls, verifiable reporting, and internationally certified management systems. This framework is implemented through: * BHLE infrastructure with sub-50μs latency, 100K+ OPS, and proprietary routing infrastructure * structural alpha capture through execution precision and fragmented liquidity access * state machine risk controls that define when the system can run, pause, reconcile, and resume * audit trails that explain what happened, when it happened, and why it happened * internationally accredited ISO certification for information security and IT service management, publicly verifiable on IAF CertSearch ## 1) Trust begins with precise definitions If a term can be misunderstood, it should be defined once and used consistently everywhere. | Term | BASIS meaning | Not implied | | --------------------- | ------------------------------------------------------------------------------------------------ | ------------------------------------ | | Market neutral | Directional exposure is minimized by construction | Directional risk is fully eliminated | | Quantity preservation | Asset quantity is preserved through same-token 1:1 conversion between native assets and stTokens | Fiat value is preserved | | USD-equivalent | Display and reporting reference only, shown in USDT | Fixed redemption to USD | | Execution precision | Routing and matching logic are optimized for deterministic fills and structural alpha capture | Guaranteed profit | {% tabs %} {% tab title="1:1 conversion scope" %} Same-token conversion on BASIS is limited to: * BTC → stBTC * ETH → stETH * SOL → stSOL * PAXG → stPAXG Cross-asset swaps are not part of the staking conversion model. {% endtab %} {% tab title="Wallet model" %} * Funding Wallet holds native assets used for deposit and withdrawal * Staking Wallet holds stTokens used for staking and reward accrual * BTC deposits use a BASIS-assigned address unique to the account * ETH, SOL, and PAXG deposits use a connected Web3 wallet {% endtab %} {% endtabs %} ## 2) Trust requires stop conditions A credible platform must be able to stop. Maximum activity is not the objective. Controlled survivability is the objective. 🛡️ {% stepper %} {% step %} **BSCB** Sentinel Circuit Breaker is the immediate protective trigger when loss risk, venue instability, reconciliation failure, or control-limit breach is detected. {% endstep %} {% step %} **DMM** Defensive Maintenance Mode is the controlled pause state used for investigation, balance verification, venue review, and recovery planning. {% endstep %} {% step %} **Re-enable** Strategy activity resumes only after reconciliation, root-cause review, and explicit operational clearance. {% endstep %} {% endstepper %} {% hint style="warning" %} **Operating State Transitions** * **RUNNING** — Standard operation within defined limits * On BSCB trigger → enters **BSCB** constrained mode * On escalation → enters **DMM** (Defensive Mode) * Return path: reconciliation → venue and control validation → explicit operator re-enable {% endhint %} Trust increases when pause logic is deterministic, documented, and enforced by state machine rules rather than ad hoc judgment. ## 3) Trust is measurable through auditability and traceability Each strategy module should maintain a complete operating record. | Record | Minimum content | Trust objective | | ---------------------- | --------------------------------------------------------------- | ----------------------------------- | | Strategy specification | Objective, venue eligibility, parameter bounds, execution logic | Explain intended behavior | | Risk specification | Limits, stop conditions, exposure caps, recovery rules | Explain protection logic | | Event log | State transitions, triggers, timestamps, operator actions | Explain what changed | | Reconciliation record | Pre-state balances, post-state balances, exceptions, resolution | Explain asset integrity | | Change record | Version, rationale, approval, deployment timestamp | Explain why a modification occurred | | Routing telemetry | Latency, fill quality, venue path, rejection reasons | Explain execution precision | You should be able to answer the following without guesswork: * What happened * When it happened * Which control triggered * Which balances changed * Why the system resumed ## 4) Trust is operational through fragmentation and execution design BASIS interacts with third-party exchanges and protocols. That creates venue and counterparty risk. The response is not blind concentration. The response is controlled fragmentation. {% tabs %} {% tab title="Counterparty control" %} BASIS follows liquidity fragmentation principles: * avoid single-venue dependency where feasible * score venue health continuously * restrict or blacklist degraded venues * diversify liquidity access paths * reconcile balances after material events {% endtab %} {% tab title="Execution control" %} BASIS uses BHLE execution infrastructure designed for: * sub-50μs decision latency * 100K+ OPS throughput * proprietary routing infrastructure * deterministic order handling * mathematical constraints on risk and inventory transitions {% endtab %} {% endtabs %} Execution quality is not just a performance metric. It is part of the trust model. Better routing, tighter control loops, and deterministic failover improve structural alpha capture while reducing avoidable operational loss. ## 5) Trust is earned through honest risk disclosure Risk disclosure is part of the product. It must describe what can fail and how the system responds. {% hint style="warning" %} BASIS does not use guaranteed return language. Market-neutral design reduces directional exposure but does not remove market, venue, latency, custody, or smart-contract risk. {% endhint %} A credible disclosure should make the following clear: * displayed USDT values are accounting references only * native assets, not USDT, are used for deposits and withdrawals * same-token 1:1 conversion preserves unit quantity, not market value * third-party venue outages can impair execution, settlement, or withdrawal timing * fixed pools can be unstaked only after the lock-up period ends * rewards accrue in real time as the same stToken in the Staking Wallet * unstake actions apply to the full staked position, with the claimable amount auto-credited to the Staking Wallet as stToken after a mandatory 7-day unstaking buffer ## 6) Trust is documented, not implied BASIS documentation is intended to provide a complete and accurate operating picture, from architecture and execution controls to reconciliation and risk management. Trust on BASIS is grounded in: * a Seychelles IBC operating entity * LEI-based institutional identity * research support from Base58 Labs as Research Partner * deterministic execution and state machine controls * auditable records and explicit failure handling * ISO/IEC 27001:2022 certification for the Information Security Management System under certificate number SC62455E * ISO/IEC 20000-1:2018 certification for the IT Service Management System * public certification transparency through IAF CertSearch That is the standard for an execution platform designed around precision, survivability, and structural alpha capture. ## Compliance posture and institutional assurance BASIS operates with an institutional-grade trust model that combines engineering controls, operational discipline, and internationally accredited certification. BASIS DIGITAL INFRASTRUCTURE LTD maintains active certification for information security and IT service management, with public verification available through IAF CertSearch. The ISO/IEC 27001:2022 certification below applies directly to the design and development of software and quantitative research systems and to the management of associated IT infrastructure and information security. It is accredited within the IAF (International Accreditation Forum) framework. ### ISO/IEC 27001:2022 certification details | Field | Details | | ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------- | | Certificate Number | SC62455E | | Standard | ISO/IEC 27001:2022 | | Status | Active | | Last Updated | March 27, 2026 | | Certified Entity | BASIS DIGITAL INFRASTRUCTURE LTD | | Address | Room 306, Victoria House, P.O Box 673, Victoria, Mahe, Seychelles | | Scope | The Design and Development of Software and Quantitative Research Systems and the Management of Associated IT Infrastructure and Information Security | | Accreditation | IAF (International Accreditation Forum) | | Verification | [Verify on IAF CertSearch](https://www.iafcertsearch.org/certification/VDrwBpB8mD2nw5ykj5zxSANH) | ### Additional active certification | Standard | Certified Entity | Status | Public Verification | | -------------------- | -------------------------------- | ------ | ------------------------------------------------------------------------------------------------ | | ISO/IEC 20000-1:2018 | BASIS DIGITAL INFRASTRUCTURE LTD | Active | [Verify on IAF CertSearch](https://www.iafcertsearch.org/certification/1IbVSdVuBbykRHSgkfAo8mBE) | Certified entity record: [Entity Record on IAF CertSearch](https://www.iafcertsearch.org/certified-entity/WTmKlSOrxvhkPKrCUIdWYEgv) These certifications reinforce formal governance for information security, service management, control execution, and continuous operational accountability across the BASIS operating model. ## Regulatory Compliance & Certifications BASIS holds third-party compliance certifications for SOC and GDPR standards, issued by SE Registrar. Both certificates are publicly verifiable: * **SOC Certificate**: ID `6489580/COC/SC`, [Verify](https://seregistrar.us/verify-your-certificate/) * **GDPR Certificate**: ID `6489581/COC/SC`, [Verify](https://seregistrar.us/verify-your-certificate/) ## Associated legal entities | Entity | Jurisdiction | Role | | ---------------------------------- | ------------------------------------------------------------------------------------------------------ | ----------------------------------- | | BASIS DIGITAL INFRASTRUCTURE LTD | Seychelles IBC ([LEI: 254900IX2F2KCWNSSS64](https://lei.bloomberg.com/leis/view/254900IX2F2KCWNSSS64)) | Platform operator | | Base58 Labs LTD (Co. No. 17094713) | England & Wales, UK | Execution infrastructure & research | Base58 Labs LTD is registered at 399-405 Oxford Street, Mayfair, London, W1C 2BU and is publicly verifiable on [Companies House](https://find-and-update.company-information.service.gov.uk/company/17094713). # Key Concepts {% 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 %} This page defines the minimum vocabulary required for the rest of the documentation. BASIS is a constrained execution system built for structural alpha capture through deterministic routing, math-based limits, and state-machine risk controls. ## 1) Market neutral A market-neutral strategy seeks to reduce sensitivity to the direction of the underlying asset. Typical example: * spot long + derivative short, which reduces delta exposure Market neutrality removes one major risk, directional exposure, but introduces others: * funding risk * basis risk * execution risk * liquidation risk * venue risk ## 2) Execution first Execution quality determines whether a theoretical spread becomes realized structural alpha. Execution First means: * low latency from signal to order * conservative slippage limits * order slicing to reduce market impact * hedge completion requirements, or stop conditions if completion fails * deterministic routing under predefined constraints In BASIS, execution is not an afterthought. It is the primary control surface for risk and return. ## 3) Capital preservation Capital preservation means optimizing for survival under stressed conditions. Core principles: * conservative leverage use * strict stop conditions * controlled unwind protocols * venue diversification * liquidity buffers for withdrawals * state escalation when market or infrastructure conditions degrade This is enforced through predefined system states, not discretionary decision-making. ## 4) Wallet model, BIVB, and stTokens BASIS separates operational balances into two wallets: | Wallet | Asset type | Primary actions | | -------------- | ---------------------------------------- | ---------------------------------- | | Funding Wallet | Native assets, BTC / ETH / SOL / PAXG | Deposit, withdraw, same-token swap | | Staking Wallet | stTokens, stBTC / stETH / stSOL / stPAXG | Stake, earn rewards, unstake | The BASIS Iso-Value Bridge (BIVB) converts native assets in the Funding Wallet into staking assets in the Staking Wallet. Important rules: * conversion is same-token only * conversion is 1:1 in quantity, not fiat value * no cross-asset swap is supported ### Supported 1:1 swap pairs | Native asset | Staking asset | Conversion rule | | ------------ | ------------- | ----------------- | | BTC | stBTC | 1 BTC → 1 stBTC | | ETH | stETH | 1 ETH → 1 stETH | | SOL | stSOL | 1 SOL → 1 stSOL | | PAXG | stPAXG | 1 PAXG → 1 stPAXG | {% hint style="info" %} **Asset Flow** * **Funding Wallet** holds: BTC, ETH, SOL, PAXG * Swap 1:1 via BIVB (same-token only, no cross-asset swaps) * **Staking Wallet** holds: stBTC, stETH, stSOL, stPAXG * Stake stTokens to begin reward accumulation {% endhint %} {% tabs %} {% tab title="BTC deposit" %} Copy your BASIS-assigned BTC deposit address and send BTC to that address. Key points: * each account receives a unique BTC deposit address * no Web3 wallet is required * no minimum deposit {% endtab %} {% tab title="ETH / SOL / PAXG deposit" %} Connect a supported Web3 wallet, such as MetaMask, and deposit the matching native asset. Key points: * deposit the same native asset you intend to hold or swap * ETH, SOL, and PAXG deposits use wallet connection flow * PAXG support is live and active {% endtab %} {% endtabs %} {% hint style="warning" %} USDT is display-only on BASIS. It may appear in reporting, portfolio views, or accounting summaries, but it cannot be deposited, withdrawn, or swapped. {% endhint %} ## 5) Staking mechanics Rewards accumulate in real time and are denominated in the same stToken as the staked position. Examples: * stBTC staking earns stBTC * stETH staking earns stETH * stSOL staking earns stSOL * stPAXG staking earns stPAXG {% stepper %} {% step %} Fund the Funding Wallet with BTC, ETH, SOL, or PAXG. {% endstep %} {% step %} Use BIVB to convert the native asset into the matching stToken on a 1:1 quantity basis. {% endstep %} {% step %} Stake the stToken in an eligible pool from the Stake section. {% endstep %} {% step %} Rewards accumulate in real time in the Staking Wallet as the same stToken. {% endstep %} {% step %} When the position becomes eligible for exit, unstake the full position. After the mandatory 7-day unstaking buffer, the claimable amount is auto-credited to the Staking Wallet as the same stToken. {% endstep %} {% endstepper %} ### Booster schedule | Booster term | Reward boost | | ------------ | ------------ | | 14D | +10% | | 30D | +20% | | 90D | +50% | | 180D | +100% (2×) | ### Pool and unstake rules | Rule | Description | | ---------------- | -------------------------------------------------------------------------------------------------- | | Fixed pools | Unstake only after the lock-up period ends, subject to a mandatory 7-day unstaking buffer | | Early exit | Not available | | Unstake size | Full position only, auto-MAX | | Reward crediting | Auto-credited to the Staking Wallet as the same stToken after the mandatory 7-day unstaking buffer | ### Operational fees and timing | Action | Standard | | -------------------------------- | ---------------- | | Deposit fee | 0% | | Swap fee | 0.01% | | Withdrawal fee | 0.05% | | BTC withdrawal time | 10 to 60 minutes | | ETH / SOL / PAXG withdrawal time | 1 to 10 minutes | Note: Withdrawal times listed above apply to withdrawals from the Funding Wallet. Unstaking from fixed pools requires an additional mandatory 7-day buffer before these withdrawal times apply. ## 6) BHLE, the execution engine BHLE, the Base58 Hyper-Latency Engine, powers BASIS execution. Core properties: * sub-50μs internal response latency * 100,000+ OPS throughput * proprietary routing infrastructure across venue and chain interfaces * deterministic execution with pre-trade state validation * logical asset isolation and controlled signer boundaries * N+1 bare-metal failover * connectivity across BTC settlement flows, SVM, and EVM environments BHLE is designed to convert model output into executable action under strict constraints. Trust is built through repeatable behavior, bounded state transitions, and verifiable operational rules, not discretionary intervention. ## 7) BQAE and BOVE ### BQAE BQAE, the BASIS Deterministic Arbitrage Engine, captures cross-venue structural alpha through: * signal scanning * opportunity filtering * deterministic execution * settlement validation ### BOVE BOVE, the BASIS Omni-Vector Engine, coordinates multiple strategy pipelines across the broader strategy matrix. Together, these systems focus on execution precision and portfolio-level coordination. ## 8) System states, Normal, BSCB, and DMM BASIS uses explicit state-machine controls. | State | Meaning | Typical action | | ------ | ------------------------------- | ---------------------------------------------------------- | | Normal | Strategies are eligible to run | Standard execution | | BSCB | Protective intervention state | Stop, close, isolate, or restrict | | DMM | Maintenance and diagnostic mode | Pause trading, run RCA, resume only after stability checks | This state architecture is central to risk control. When inputs violate predefined thresholds, the system changes state rather than stretching assumptions. ## 9) Trinity, claim-based referral logic Trinity is a contribution-aligned referral network. It is not a sign-up reward model. Trinity rewards are generated when: * downstream users stake * rewards accrue * a claim event occurs This design aligns rewards with real platform activity and discourages inactive or abusive referral trees. ## 10) Dashboard structure The primary dashboard sections are: | Section | Purpose | | -------- | ----------------------------------------------------------------------------------- | | Stake | View pools, boosters, and active staking positions | | Assets | Manage Funding Wallet and Staking Wallet balances, swaps, deposits, and withdrawals | | Referral | View Trinity referral activity and contribution-based rewards | | Support | Access operational help and issue handling | | Account | Manage account settings and security controls | {% hint style="success" %} Key takeaway: BASIS is a system, not a bot. The edge comes from deterministic execution, math-constrained strategy design, and disciplined operational controls. {% endhint %} # What BASIS Is Not {% 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 %} This page removes common category errors. Trust starts with clear boundaries. If anything here conflicts with your assumptions, review the Risk Disclosure before depositing. ## Quick operational facts 🔎 | Topic | BASIS rule | | ------------------------ | ----------------------------------------------------------------------------------------------------------------------------- | | Deposit model | BTC deposits use a BASIS-assigned address unique to each account. ETH, SOL, and PAXG deposits require a connected Web3 wallet | | Supported deposit assets | BTC, ETH, SOL, PAXG | | Internal unit | USDT is display and accounting only. It cannot be deposited or withdrawn | | Wallet structure | Funding Wallet holds native assets. Staking Wallet holds stTokens | | Swap | Same-token only at 1:1: BTC to stBTC, ETH to stETH, SOL to stSOL, PAXG to stPAXG | | Rewards | Accrue in real time as the same stToken in the Staking Wallet | | Unstake | Full position only. Fixed pools unlock only after the lock-up period ends | | Fees | Deposit 0%, withdrawal 0.05%, swap 0.01% | | Standard withdrawal time | BTC 10 to 60 minutes. ETH, SOL, and PAXG 1 to 10 minutes | | BTC minimum deposit | 0.0001 BTC | ## 1. BASIS Is Not a Fixed-Return Product BASIS targets market-neutral yield through structural alpha capture. Outcomes depend on realized spread availability, funding conditions, execution quality, and risk constraints. No page, simulation, dashboard estimate, or historical range should be read as a guaranteed return. Boosters and fixed pools change lock-up mechanics and reward multipliers. They do not create a guaranteed APY. {% hint style="warning" %} Current booster multipliers are 14D +10%, 30D +20%, 90D +50%, and 180D +100%. Fixed pools can be unstaked only after the lock-up period ends. There is no early exit option. {% endhint %} ## 2. BASIS Is Not Directional Trading BASIS is not built to predict whether BTC, ETH, SOL, or PAXG will rise or fall next. The system is designed to pursue structural alpha from basis spreads, funding differentials, venue dislocations, and temporary mispricings in correlated markets while minimizing net directional exposure. If your objective is leveraged price speculation, BASIS is the wrong product. ## 3. BASIS Is Not Unmanaged Arbitrage Arbitrage without strict execution control is not robust infrastructure. BASIS is built around deterministic execution and bounded risk behavior. Key design principles include: * Execution precision through BHLE, targeting sub-50μs latency and 100K+ OPS on proprietary routing infrastructure * Deterministic routing and settlement paths for supported venues and chains * Hedge integrity checks that monitor spread alignment and execution state in real time * Math-constrained position sizing, exposure limits, and state machine risk controls * Venue and liquidity diversification to reduce concentration and operational dependency This is not casual spread chasing. It is a controlled structural alpha system designed to reduce slippage, drift, and path-dependent execution failure. ## 4. BASIS Is Not a Traditional Investment Fund BASIS is a rule-based digital asset infrastructure platform, not a discretionary pooled fund manager. User interaction follows a defined product flow: 1. Deposit supported native assets into the Funding Wallet 2. Swap the native asset to the matching stToken at 1:1 3. Stake the stToken and accrue rewards in real time in the Staking Wallet 4. Unstake the full position when the product rules permit 5. Receive the claimable amount automatically in the Staking Wallet as the same stToken after a mandatory 7-day unstaking buffer This structure is operational, not discretionary. Capital handling, reward accrual, and unstake behavior are governed by product rules and system controls rather than subjective manager decisions. ## 5. BASIS Is Not a Bank Account BASIS is digital asset infrastructure, not a bank and not a fiat payment rail. It does not provide government deposit insurance, checking account functionality, or guaranteed liquidity on demand. Withdrawals follow asset-specific operational timing and network conditions. Native assets move through the Funding Wallet under platform rules. stTokens accrue and settle within the Staking Wallet workflow. {% hint style="info" %} Current standard withdrawal timing is 10 to 60 minutes for BTC and 1 to 10 minutes for ETH, SOL, and PAXG. The standard withdrawal fee is 0.05%. {% endhint %} The trust model is therefore different from consumer banking. It rests on deterministic execution, transparent product rules, research-driven strategy design, and risk controls enforced by system state rather than marketing promises. # Risk Matrix {% 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 %} This page summarises the principal risk categories for BASIS users. Each category is assessed for inherent severity and likelihood before controls, then for residual risk after BASIS mitigations. Residual risk reflects deterministic execution, mathematical exposure constraints, venue limits, and state machine risk controls. This is a summary disclosure. For full detail, see [Risk Disclosure](https://docs.basis.pro/risk-safety-and-asset-protection/risk-disclosure) and the individual pages under the Risk section. {% tabs %} {% tab title="Asset and wallet model" %} * BTC deposits use a BASIS-assigned address that is unique to each account. No Web3 wallet is required for BTC deposits. * ETH, SOL, and PAXG deposits use a connected Web3 wallet such as MetaMask. * Native assets are held in the Funding Wallet for deposit and withdrawal activity. * stTokens are held in the Staking Wallet for staking and reward accrual. * USDT is an internal accounting and display unit only. It is not a depositable or withdrawable asset. {% endtab %} {% tab title="Swap and unstake model" %} Swaps are same-token only and occur 1:1. | Asset | Staked Token | | ----- | ------------ | | BTC | stBTC | | ETH | stETH | | SOL | stSOL | | PAXG | stPAXG | * Rewards accumulate in real time as the same stToken in the Staking Wallet. * Fixed pools cannot be unstaked early. * Unstake is full-position only. * When the lock-up ends, the claimable amount is auto-credited to the Staking Wallet as the same stToken. {% endtab %} {% endtabs %} *** ## Risk Summary Table | Risk Category | Severity | Likelihood | Primary Mitigation | Residual Risk | | ---------------------------------------- | ------------- | ------------- | ------------------------------------------------------------------------------------ | ------------- | | Smart Contract / On-chain | High | Medium | Independent external audits, conservative governance, CEI pattern, reentrancy guards | Low to Medium | | Counterparty (Exchange) | High | Low to Medium | Multi-venue diversification, venue caps, health scoring, BSCB blacklisting | Medium | | Funding Rate (Negative) | Medium | Medium | Real-time monitoring, staged position reduction, BSCB pause thresholds | Low | | Reference Unit Risk (USDT display basis) | Medium | Low | Reconciliation controls, valuation checks, venue collateral limits | Low to Medium | | PAXG / XAU Tracking Risk | Low to Medium | Low | Regulated issuer oversight, reserve attestations, market-integrity monitoring | Low | | Liquidity and Lock-up Risk | Medium | Medium | Fixed lock-up design, treasury buffers, native-asset withdrawal management | Medium | | Regulatory Risk | High | Low | Seychelles IBC structure, jurisdictional screening, external legal counsel | Medium | | Technology Risk (BHLE) | High | Low | N+1 bare-metal failover, deterministic state machine, cryptographic asset enclave | Low | | Key Person Risk | Medium | Low | Research continuity, documented procedures, access compartmentalization | Low to Medium | | Oracle / Price Feed Risk | Medium | Low | TWAP oracles, multi-source aggregation, circuit breakers | Low | | Bridge Risk (BIVB) | High | Low | Independent validator sets, finality thresholds, per-session exposure limits | Medium | *** ## Risk Detail ### Smart Contract and On-chain Risk On-chain components, including bridge and settlement contracts, may contain vulnerabilities not identified during review. BASIS reduces this risk through independent external audits before release, conservative upgrade governance using multisig plus timelock, contract patterns such as checks-effects-interactions, and reentrancy protections. See [Smart Contract & On-chain Risk](/risk-safety-and-asset-protection/smart-contract-risk). ### Counterparty (Exchange) Risk BASIS executes across multiple third-party venues to capture structural alpha with execution precision. If a venue experiences insolvency, operational failure, API degradation, or withdrawal restrictions, capital access and yield generation may be affected. Mitigations include venue-level exposure caps, continuous venue health monitoring, automated blacklisting through BSCB, and rapid re-routing where available. See [Third-Party Exchange Risk](/risk-safety-and-asset-protection/exchange-risk). ### Funding Rate Risk Funding rates can turn negative during adverse market regimes and convert expected yield into cost. BASIS monitors funding continuously and uses staged exposure reduction and pause thresholds when rates move outside approved bands. See [Funding Rate Dynamics](/strategies/funding-rate-dynamics). ### Reference Unit Risk (USDT Display Basis) Displayed balances use USDT as an internal accounting and display reference for USD-equivalent reporting. USDT cannot be deposited or withdrawn on BASIS. If USDT diverges from USD, displayed valuation and some venue-side settlement references may temporarily differ from spot USD intuition. BASIS mitigates this with reconciliation controls, valuation checks, and limits on venue-specific collateral dependencies. See [Risk Disclosure](https://docs.basis.pro/risk-safety-and-asset-protection/risk-disclosure). ### PAXG / XAU Tracking Risk PAXG is active on BASIS and is deposited and withdrawn as a native asset through a connected Web3 wallet. Risk arises if PAXG trades away from underlying gold value, or if issuer, custody, or market structure events affect convertibility or pricing. BASIS relies on regulated issuer disclosures, reserve attestations, and market-integrity monitoring. ### Liquidity and Lock-up Risk Fixed pool positions cannot be unstaked before the selected lock-up ends. There is no early exit option. This design improves capital planning and reduces run-risk from discretionary early withdrawals, but it creates user-side liquidity timing risk if funds are needed before maturity. After lock-up completion, the claimable balance is auto-credited to the Staking Wallet as the same stToken. Users then perform the same-token 1:1 swap back to the native asset before withdrawal. ### Regulatory Risk The regulatory landscape for digital asset yield products continues to evolve. BASIS operates through a Seychelles IBC structure under BASIS DIGITAL INFRASTRUCTURE LTD, LEI [254900IX2F2KCWNSSS64](https://lei.bloomberg.com/leis/view/254900IX2F2KCWNSSS64). Changes in securities, derivatives, tax, promotion, custody, or consumer protection rules may affect product availability or servicing in specific jurisdictions. BASIS applies jurisdictional screening and retains external legal counsel to monitor obligations. ### Technology Risk (BHLE) BHLE is BASIS's proprietary routing and execution infrastructure, engineered for sub-50μs decision latency and 100K+ operations per second under normal operating conditions. Risks include software defects, hardware failure, network partition events, and venue connectivity loss. Controls include N+1 bare-metal failover, deterministic execution logic, mathematical exposure bounds, and state machine risk controls. The cryptographic asset enclave is designed so that compromise of an execution node does not by itself permit unilateral movement of user assets. ### Key Person Risk BASIS depends on specialized quantitative, infrastructure, and security expertise. This risk is reduced through documented procedures, segmented operational authority, reproducible research workflows, and continuity planning with its research partner, Base58 Labs. ### Oracle / Price Feed Risk Strategies and accounting processes that depend on market data may be affected by stale, manipulated, or anomalous inputs. BASIS mitigates this with TWAP-based feeds where appropriate, multi-source aggregation, sanity bounds, and circuit breakers that halt actions when feed quality degrades. ### Bridge Risk (BIVB) Cross-system transfers and bridge components may fail due to validator faults, finality assumptions, or software defects. BASIS mitigates this through independent validator sets, finality thresholds, per-session exposure caps, and conservative recovery procedures. *** ## How to Read This Matrix * Severity: the potential impact if the risk materialises * Likelihood: the estimated probability over a 12-month horizon * Residual Risk: the remaining risk after BASIS controls are applied {% hint style="warning" %} ⚠️ This matrix is a summary and should be read together with the [Risk Disclosure](https://docs.basis.pro/risk-safety-and-asset-protection/risk-disclosure) before committing capital. {% endhint %} # Quick Reference: Key Terms {% 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 %} {% hint style="success" %} Core wallet model: * Funding Wallet holds native assets for deposit and withdrawal * Staking Wallet holds stTokens for staking and reward accrual * Same-token swaps only, BTC ↔ stBTC, ETH ↔ stETH, SOL ↔ stSOL, PAXG ↔ stPAXG, each at 1:1 quantity {% endhint %} A compact reference for the core technical terms used across this documentation. For the extended version, see [Glossary](/reference/glossary). *** ## Operational quick facts | Topic | Rule | | ---------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | | BTC deposit | Copy your BASIS-assigned BTC address. Each account receives a unique deposit address. No Web3 wallet connection is required. Minimum deposit is 0.0001 BTC. | | ETH, SOL, PAXG deposit | Connect a supported Web3 wallet, such as MetaMask or Phantom, then submit the transfer in the same native asset. | | Depositable assets | BTC, ETH, SOL, PAXG | | USDT | Display and accounting unit only. Not depositable or withdrawable. | | Fees | Deposit 0%, Withdrawal 0.05%, Swap 0.01% | | Withdrawal timing | BTC, 10 to 60 minutes. ETH, SOL, PAXG, 1 to 10 minutes | | Rewards | Accumulate in real time as the same stToken in the Staking Wallet | | Unstake | Full position only. The interface auto-selects the full amount. | | Fixed pools | Unstake is available only after the selected lock-up period ends. No early exit option. | | Booster schedule | 14D +10%, 30D +20%, 90D +50%, 180D +100% | | Dashboard sections | Stake, Assets, Referral, Support, Account | ## Supported swap pairs | Asset | Staked Token | | ----- | ------------ | | BTC | stBTC | | ETH | stETH | | SOL | stSOL | | PAXG | stPAXG | ## Deposit paths 🔄 {% tabs %} {% tab title="BTC" %} 1. Open Assets 2. Copy your BASIS-assigned BTC deposit address 3. Send at least 0.0001 BTC from your external wallet or exchange 4. Funds arrive in the Funding Wallet {% endtab %} {% tab title="ETH / SOL / PAXG" %} 1. Open Assets 2. Connect a supported Web3 wallet 3. Approve and send ETH, SOL, or PAXG in the same native asset 4. Funds arrive in the Funding Wallet {% endtab %} {% endtabs %} ## Position lifecycle {% stepper %} {% step %} **Deposit native asset** Deposit BTC to your unique BASIS BTC address, or connect a Web3 wallet for ETH, SOL, or PAXG. Deposits settle into the Funding Wallet. {% endstep %} {% step %} **Swap 1:1 into stToken** Convert the native asset into its corresponding stToken only. Cross-asset swaps are not supported. {% endstep %} {% step %} **Stake into a fixed pool** Allocate stTokens from the Staking Wallet into a staking pool with an optional lock-up booster. {% endstep %} {% step %} **Accrue rewards in real time** Rewards accumulate continuously as the same stToken in the Staking Wallet. {% endstep %} {% step %} **Unstake the full position** After the lock-up ends, unstake the full position. The released amount is auto-credited to the Staking Wallet as the same stToken, subject to a 7-day unstaking buffer. {% endstep %} {% endstepper %} *** ## Key terms BHLE (Base58 Hyper-Latency Engine)\ The proprietary execution engine developed with Base58 Labs, BASIS's Research Partner. BHLE delivers sub-50μs internal latency, 100,000+ orders per second, and proprietary routing infrastructure designed for deterministic execution, execution precision, and structural alpha capture. The engine is constrained by mathematical risk bounds and state machine risk controls. See [System Overview](/whitepaper/system-overview). BIVB (BASIS Iso-Value Bridge)\ The conversion mechanism that swaps native deposited assets, BTC, ETH, SOL, and PAXG, into their corresponding staking tokens, stBTC, stETH, stSOL, and stPAXG, at a strict 1:1 quantity ratio. BIVB preserves asset quantity. It does not guarantee fiat-equivalent value. stToken\ A tokenized receipt issued by BIVB upon conversion, for example stBTC or stPAXG. stTokens are held in the Staking Wallet and represent the user's active staking balance plus real-time reward accrual in the same asset denomination. Funding Wallet\ The wallet area that holds native assets, BTC, ETH, SOL, and PAXG. Deposits arrive here and withdrawals are initiated from here. Staking Wallet\ The wallet area that holds stTokens, stBTC, stETH, stSOL, and stPAXG. Rewards accrue here in real time as the same stToken. Swap\ A same-token conversion only. Supported paths are BTC to stBTC, ETH to stETH, SOL to stSOL, and PAXG to stPAXG, each at a 1:1 quantity ratio. Cross-asset swaps are not supported. Stake\ The action of allocating stTokens from the Staking Wallet into an active strategy pool. Unstake\ The action of closing a staking position after its lock-up condition is satisfied. BASIS processes unstake as a full-position action only. The interface auto-selects the full amount. Claimable Amount\ The amount released when an unstake completes. It is automatically credited to the Staking Wallet as the same stToken after the 7-day unstaking buffer is fulfilled. BOVE (BASIS Omni-Vector Engine)\ The portfolio coordination engine that allocates capital across multiple strategy pipelines simultaneously. It optimizes the mix of spatial arbitrage, funding rate capture, DeFi lending, and active PAXG yield based on real-time risk-adjusted returns. BQAE (BASIS Deterministic Arbitrage Engine)\ The cross-venue spatial arbitrage execution module inside BHLE. It runs a continuous four-step cycle, scan, filter, execute atomically, and settle. BSCB (BASIS Sentinel Circuit Breaker)\ An automated protection layer that halts new trading activity and initiates controlled unwinding when predefined risk thresholds are breached, such as slippage anomalies above internal limits, margin deterioration, or benchmark pricing instability. See [BSCB](/risk-safety-and-asset-protection/bscb). DMM (Defensive Maintenance Mode)\ The platform state entered after BSCB activation or manual intervention. In DMM, no new positions are opened, existing positions are unwound in an orderly sequence, root cause analysis is performed, and the system returns to Normal mode only after verification. See [DMM](/risk-safety-and-asset-protection/dmm). Trinity\ BASIS's contribution-aligned referral network. Trinity rewards are distributed only when a downstream user performs a Claim event. Rewards are not triggered by sign-up alone or by static hierarchy depth. See [Trinity Overview](/trinity-referral-and-vip/overview). Referral Activation State\ The policy rule set that determines which Trinity reward nodes are active for an account based on eligible contribution and staking activity. See [Trinity Overview](/trinity-referral-and-vip/overview). Node A, Node B, Node C\ Trinity reward nodes that define how eligible reward flow propagates through the referral network. Node A covers direct referrals. Node B covers the next eligible scope. Node C covers the expanded eligible scope. Reward rates can reach Node A 18%, Node B 10%, Node C 7%, plus Leadership 5%, subject to an aggregate cap of 40%. See [Trinity Overview](/trinity-referral-and-vip/overview). Lock-up Booster\ A yield multiplier applied to the user's share of net realized yield in exchange for a fixed-duration commitment. Available boosters are 14 days +10%, 30 days +20%, 90 days +50%, and 180 days +100%. Fixed pools unlock only at the end of the selected period and do not support early exit. See [Booster System](/economics-and-rewards/booster-system). Funding Rate\ A periodic cash flow in perpetual futures markets that aligns the futures price with the spot price. When positive, longs pay shorts. When negative, shorts pay longs. BASIS captures funding through delta-neutral long-spot and short-perpetual structures. See [Funding Rate Mechanics](/research-library-deep-dives/funding-mechanics). Delta-Neutral\ A position where net directional exposure to the underlying asset is approximately zero. Gains and losses from price movement on the long leg offset those on the short leg. Residual P\&L comes primarily from carry, spreads, and execution quality rather than market direction. Market-Neutral\ A broader concept where strategy returns are designed to remain statistically insensitive to the direction of the relevant market. A delta-neutral strategy is market-neutral with respect to price. A fully market-neutral strategy also addresses volatility and correlation risk. Slippage\ The difference between the expected execution price and the actual fill price caused by order book liquidity consumption. BASIS enforces a maximum slippage bound of 0.30% per trade. Orders outside this bound are rejected by the protection stack. See [Anti-Slippage](/technical-architecture/anti-slippage). Execution Precision\ The collection of controls used to reduce adverse ordering effects, latency leakage, settlement drift, and on-chain execution variance. BASIS incorporates execution precision constraints directly into routing logic, expected value models, and structural alpha capture workflows. See [System Overview](/whitepaper/system-overview). PAXG (Paxos Gold)\ An ERC-20 token issued by Paxos Trust Company, where each token represents one troy ounce of LBMA-accredited Good Delivery gold bullion held in professional vaulting infrastructure. PAXG is fully active on BASIS for deposit, staking, and withdrawal. See [Why PAXG](/paxg-integration/why-paxg). ## Dashboard navigation | Section | Purpose | | -------- | --------------------------------------------------------------------- | | Stake | Open and manage staking positions | | Assets | View Funding Wallet, Staking Wallet, deposits, swaps, and withdrawals | | Referral | View Trinity referral network activity and reward history | | Support | Access operational assistance and case handling | | Account | Manage profile, security, and account settings | # Your First Stake: Step-by-Step Walkthrough {% 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)). {% endhint %} Use this checklist to complete your first stake on BASIS. You will log in, fund your account, swap into an stToken, choose a pool, and monitor reward accrual in real time. **Time required:** \~10 to 15 minutes for first-time setup *** ## Overview {% hint style="info" %} **End-to-End Staking Flow** Login (OTP) → Deposit → Swap 1:1 into stToken → Choose Pool → Confirm → Monitor → Unstake at eligibility → Wait 7-Day Buffer → Withdraw native asset {% endhint %} *** {% stepper %} {% step %} **Step 1: Log In with Email OTP** **What to do** 1. Visit 2. Enter your registered email address 3. Check your inbox for a 6-digit OTP code 4. Enter the code within 10 minutes **What to expect** * OTP usually arrives within 1 to 2 minutes * The code is valid for 10 minutes and can be used once * BASIS enforces a Single Active Session policy for each account **Tips** * BASIS will never ask for a password, seed phrase, or private key * If you receive a login notification you did not initiate, secure your email account immediately and contact {% endstep %} {% step %} **Step 2: Deposit Your Asset** {% hint style="warning" %} Deposit rules differ by asset: * BTC: use your BASIS-assigned BTC deposit address unique to your account * ETH, SOL, PAXG: connect a supported Web3 wallet such as MetaMask and deposit through the connected wallet flow {% endhint %} **What to do** {% tabs %} {% tab title="BTC" %} 1. Go to **Assets > Funding Wallet** 2. Select **BTC** 3. Copy your BASIS-assigned BTC deposit address 4. Send BTC from your external wallet or exchange {% endtab %} {% tab title="ETH / SOL / PAXG" %} 1. Go to **Assets > Funding Wallet** 2. Select **ETH**, **SOL**, or **PAXG** 3. Click **Connect Wallet** 4. Approve the connection in your Web3 wallet 5. Confirm the deposit transaction from your wallet {% endtab %} {% endtabs %} **What to expect** | Asset | Deposit Method | Typical Time | | ----- | --------------------------- | ---------------: | | BTC | Copy BASIS-assigned address | 10 to 60 minutes | | ETH | Connected Web3 wallet | 1 to 10 minutes | | SOL | Connected Web3 wallet | 1 to 10 minutes | | PAXG | Connected Web3 wallet | 1 to 10 minutes | **Deposit fees** * Deposit fee: 0% **Important** * Minimum BTC deposit: 0.0001 BTC * Only send the exact supported asset on its correct network * Do not send unsupported assets or cross-network transfers {% endstep %} {% step %} **Step 3: Swap to stToken** {% hint style="info" %} Swaps on BASIS are same-token only and 1:1 by quantity: * BTC → stBTC * ETH → stETH * SOL → stSOL * PAXG → stPAXG {% endhint %} **What to do** 1. In **Assets > Funding Wallet**, click **Swap** 2. Select the supported asset 3. Enter the amount 4. Review the summary * Swap fee: **0.01%** * Conversion: 1:1 by token quantity 5. Confirm the swap **What to expect** * The swap is internal and completes immediately after confirmation * Your stToken balance appears in the **Staking Wallet** * Example: 1 ETH swaps to 1 stETH before fees **Tips** * Funding Wallet holds native tokens for deposit and withdrawal * Staking Wallet holds stTokens for staking and reward accrual * The 1:1 conversion is token-denominated, not fiat-value protected {% endstep %} {% step %} **Step 4: Choose Your Pool** **What to do** 1. Go to **Stake** 2. Select the stToken you want to stake 3. Review the available booster periods 4. Choose your preferred lock-up 5. Confirm the stake **Booster schedule** | Lock-up | Booster | | ------- | ------: | | 14D | +10% | | 30D | +20% | | 90D | +50% | | 180D | +100% | **What to expect** * Rewards begin accumulating in real time after staking * Rewards accrue as the same stToken in your Staking Wallet * Fixed pools can only be unstaked after the lock-up period ends * There is no early exit option for fixed pools {% hint style="warning" %} Unstake is full-position only. When you unstake, BASIS applies auto-MAX to the entire staked position for that pool. {% endhint %} {% endstep %} {% step %} **Step 5: Monitor Your Position** **What to do** 1. Open the dashboard 2. Review the main sections: * **Stake** * **Assets** * **Referral** * **Support** * **Account** 3. In your staking view, monitor: * Staked amount in stToken * Accumulated rewards in stToken * Lock-up status * Wallet balances across Funding Wallet and Staking Wallet **What to expect** * Rewards accumulate in real time * Reward balances remain token-aligned with your staked asset * Native tokens remain in Funding Wallet * stTokens and accrued staking rewards remain in Staking Wallet {% hint style="info" %} BASIS infrastructure is designed around deterministic execution, mathematical constraints, and state-machine risk controls. Routing and execution systems are built for execution precision and structural alpha capture rather than discretionary intervention. {% endhint %} {% endstep %} {% step %} **Step 6: Unstake and Wait for Claimable Balance** **What to do** 1. Go to **Stake** 2. Select the active position 3. Click **Unstake** 4. Review the full-position unstake summary 5. Confirm **What to expect** * Flexible or fixed-position rules are enforced by pool logic * For fixed pools, unstake is only available after maturity * Upon unstake, the claimable amount is automatically credited to your **Staking Wallet** as stToken after a mandatory 7-day unstaking buffer. * No separate manual claim step is required after the 7-day unstaking buffer completes **Important** * BASIS does not support partial unstake for a single position * The full position is processed each time unstake is executed {% endstep %} {% step %} **Step 7: Withdraw Native Asset** **What to do** 1. After the mandatory 7-day unstaking buffer completes, go to **Assets > Staking Wallet** 2. If needed, swap your stToken back to the corresponding native token * stBTC → BTC * stETH → ETH * stSOL → SOL * stPAXG → PAXG 3. Move to **Funding Wallet** 4. Click **Withdraw** 5. Enter the destination address 6. Confirm the withdrawal **What to expect** * Withdrawal fee: **0.05%** * Typical withdrawal times from the **Funding Wallet** after the mandatory 7-day unstaking buffer completes: * BTC: 10 to 60 minutes * ETH / SOL / PAXG: 1 to 10 minutes **Tips** * Confirm the destination network and address carefully * Withdraw only to a wallet or venue that supports the exact asset and network * For larger transfers, a small test withdrawal is prudent {% endstep %} {% endstepper %} ## Troubleshooting | Issue | Likely Cause | What to Do | | --------------------------------------- | ---------------------------------------------- | ------------------------------------------------------------------------------------------------- | | OTP not received | Email delay or spam filtering | Check spam, wait 2 minutes, then request a new code | | BTC deposit not arriving | Deposit below minimum or pending confirmations | Confirm amount is at least 0.0001 BTC and check the transaction on-chain | | ETH / SOL / PAXG deposit not arriving | Wallet transaction not confirmed | Check your wallet activity and the destination network | | Swap unavailable | Insufficient balance or unsupported asset path | Confirm you hold the native token in Funding Wallet and are swapping to the matching stToken only | | Unstake unavailable | Fixed pool has not reached maturity | Wait until the lock-up period ends | | Withdrawal pending longer than expected | Network congestion or processing queue | Check the destination chain explorer and contact support if needed | **Support:** *** ## Platform Notes | Item | Value | | ------------------------ | ------------------------------------------------------------- | | Deposit fee | 0% | | Withdrawal fee | 0.05% | | Swap fee | 0.01% | | Supported deposit assets | BTC, ETH, SOL, PAXG | | USDT | Internal accounting/display unit only | | Wallet model | Funding Wallet for native assets, Staking Wallet for stTokens | {% hint style="info" %} BASIS execution infrastructure incorporates proprietary routing, deterministic controls, and exchange-path optimization informed by Base58 Labs research. The BHLE stack targets sub-50μs latency and 100K+ OPS to support consistent execution precision under defined risk constraints. {% endhint %} See also: [Wallet Model](/getting-started/wallet-model) | [Fees & Price Impact](/getting-started/fees) | [Risk Disclosure](/risk-safety-and-asset-protection/risk-disclosure) # Onboarding (Email + MPC) {% 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)). {% endhint %} BASIS keeps onboarding fast without relaxing account security. Instead of a username/password account, BASIS uses email code login with an MPC (Multi-Party Computation) model via Privy™. {% stepper %} {% step %} **1) Create an account / sign in** 1. Enter your email address. 2. Retrieve the 6-digit verification code from your email inbox. 3. Enter the code to complete sign-in. ✅ The flow is the same for first-time sign-in and later sign-ins.\ ✅ You do not create or store a password. {% endstep %} {% step %} **2) What MPC means in practice** Most accounts and wallets depend on one secret such as a password, private key, or seed phrase. If that secret is exposed, the account may be compromised. MPC reduces that single-secret failure mode by: * splitting sensitive authentication material into multiple encrypted shares * storing those shares across independent security boundaries * requiring multiple shares to reconstruct an authorization operation **What this does not mean** * MPC does not eliminate phishing risk * MPC does not make you immune to malware * MPC does not guarantee asset safety if an external service fails MPC reduces one specific class of risk: single-secret compromise. {% hint style="success" %} This security model aligns with BASIS system design principles: deterministic execution, math-constrained operations, and state-machine risk controls. {% endhint %} {% endstep %} {% step %} **3) User security best practices** Even with MPC: * secure your email account with strong authentication * secure your email account with a hardware security key (such as YubiKey) where your email provider supports it * avoid unknown links and unsolicited messages * avoid public Wi‑Fi for account access * verify the BASIS domain every time {% endstep %} {% step %} **4) Troubleshooting login** If you do not receive the 6-digit code: * check your spam or junk folder * wait a few minutes in case of delivery delay * confirm you entered the email address correctly * request a new code If issues persist, contact . {% endstep %} {% endstepper %} {% hint style="warning" %} Next step: read Wallet Model (Funding vs Staking) so you understand where native token deposits arrive, how stTokens are used, and how rewards accumulate in real time. {% endhint %} # Authentication & Security {% 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)). {% endhint %} BASIS uses passwordless login and enforces strict session controls. Every account follows the policies on this page. These controls operate within an institutional-grade security and service management framework maintained by an internationally certified operator. *** ## 1. Passwordless Login BASIS does not use usernames and passwords. Login uses email-based one-time verification codes (OTP): {% stepper %} {% step %} Enter your email address on the login screen. {% endstep %} {% step %} BASIS sends a 6-digit verification code to your email. {% endstep %} {% step %} Enter the code to access your account. {% endstep %} {% endstepper %} This reduces common password-related attack vectors such as credential stuffing, password reuse, and brute-force attempts. {% hint style="warning" %} BASIS will never ask for your password, seed phrase, or private key. {% endhint %} *** ## 2. Verification Code Validity | Property | Value | | --------------- | ---------------------------------------------------------- | | Code length | 6 digits | | Validity period | 10 minutes from issuance | | Reusable | No, single use only | | Scope | Valid only for the login session in which it was requested | After the validity window closes, the code no longer works. A new login request generates a new code. {% hint style="info" %} If you receive a verification code email that you did not request, you can ignore it. No account access occurs unless the code is entered successfully. {% endhint %} *** ## 3. Single Active Session Policy BASIS enforces a Single Active Session Policy: * When the same account logs in from another device or browser, BASIS terminates the existing session. * Only the most recent session remains active. * If your session is terminated, log in again to continue. This control limits concurrent account access and reduces session-sharing risk. *** ## 4. Login Notifications BASIS sends a one-time verification code to your email for each login. There is no separate login notification email. If you did not request a login code, do not enter it and contact immediately. *** ## 5. Your Security Responsibilities You remain responsible for the security of your login environment. * Protect your email account. OTP delivery depends on inbox security. Enable 2FA with your email provider. * Do not share verification codes. BASIS support will never ask for your OTP. * Log out on shared or public devices after each session. * Report suspicious activity immediately to . {% hint style="success" %} Your email account is the primary access control layer for BASIS. If your email is compromised, your account may be at risk. {% endhint %} *** ## 6. Platform Security Principles BASIS applies the following controls through an institutional-grade operating model supported by BASIS DIGITAL INFRASTRUCTURE LTD's active ISO/IEC 27001:2022 and ISO/IEC 20000-1:2018 management system certifications. | Principle | Implementation | | ------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | | OTP-based authentication | No stored passwords. Each login requires a fresh code | | Single active session | Concurrent sessions are not permitted | | Login environment alerts | Email notifications for login events | | Anomaly detection | Automated systems monitor unusual access patterns | | Deterministic infrastructure | State-machine risk controls, math-constrained execution paths, and deterministic session handling | | Institutional-grade systems | N+1 bare-metal failover and BHLE infrastructure | | Information security governance | Security processes operated within the ISO/IEC 27001:2022 certified Information Security Management System of BASIS DIGITAL INFRASTRUCTURE LTD | | IT service management | Service operations managed within the ISO/IEC 20000-1:2018 certified IT Service Management System of BASIS DIGITAL INFRASTRUCTURE LTD | *** ## 7. BHLE Cryptographic Asset Enclave BHLE is BASIS’s proprietary routing and execution infrastructure, designed for deterministic execution, structural alpha capture, and controlled system isolation. Core properties include: * Sub-50μs latency * 100K+ OPS throughput capacity * Proprietary routing infrastructure * State-machine risk controls * Math-constrained execution paths The Cryptographic Asset Enclave is designed so that: * User assets reside in a mathematically isolated environment. * Asset control remains logically separated from the execution layer. * BHLE generates execution instructions without direct signing authority. * Sensitive authorization boundaries are isolated from central platform orchestration. This design helps ensure that execution infrastructure and asset authorization remain separated by system constraints rather than operator discretion alone. {% hint style="info" %} BASIS security architecture is informed by research collaboration with Base58 Labs and emphasizes deterministic execution, bounded system behavior, and infrastructure-level fault isolation. These principles operate within BASIS DIGITAL INFRASTRUCTURE LTD's active ISO/IEC 27001:2022 certified Information Security Management System and ISO/IEC 20000-1:2018 certified IT Service Management System, with public verification available through IAF CertSearch. {% endhint %} *** ## 8. Security Contact {% hint style="info" %} **Account Security** For account security concerns, suspicious login activity, or access-related issues, contact: {% endhint %} {% hint style="warning" %} **Legal & Compliance** For legal or compliance matters related to account access: · {% endhint %} *** These security policies may be updated as the platform evolves. Material changes will be announced via the Changelog and, where applicable, by email notification. # Wallet Model (Funding vs Staking) {% 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 separates balances into two functional wallets: 1. Funding Wallet (native assets) 2. Staking Wallet (stTokens) This structure keeps asset handling explicit, improves accounting clarity, and supports deterministic execution controls. ## 1) Funding Wallet (Native) The Funding Wallet holds your native assets after deposit: * BTC on Bitcoin * ETH on Ethereum * SOL on Solana * PAXG on Ethereum **Typical actions** * Deposit * Withdraw * Swap native asset to the matching staking token Think of the Funding Wallet as the operational layer for on-chain asset movement. {% hint style="success" %} Deposits and withdrawals use native assets only: * BTC ↔ Funding Wallet * ETH ↔ Funding Wallet * SOL ↔ Funding Wallet * PAXG ↔ Funding Wallet USDT is display-only and cannot be deposited or withdrawn. {% endhint %} ## 2) Staking Wallet (stToken) The Staking Wallet holds your staking tokens: * stBTC * stETH * stSOL * stPAXG When you swap a native asset into its staking token, the conversion is always 1:1 within the same asset: | Native asset | Staking token | | ------------ | ------------- | | BTC | stBTC | | ETH | stETH | | SOL | stSOL | | PAXG | stPAXG | ### Important: stTokens are position units stTokens represent your staked position within BASIS. * 1 BTC → 1 stBTC * 1 ETH → 1 stETH * 1 SOL → 1 stSOL * 1 PAXG → 1 stPAXG stTokens are used to track principal and rewards in asset quantity terms. They are not fiat-denominated balances. ## 3) Why BASIS uses two wallets This separation supports: * clearer operational state between deposited and staked assets * safer withdrawal flows through explicit conversion paths * cleaner ledgering and reporting * stronger state-machine controls for asset transitions It also aligns with BASIS system design principles: * deterministic execution * math-constrained accounting * structured risk controls * infrastructure optimized for execution precision and structural alpha capture {% hint style="info" %} Research and execution design are informed by Base58 Labs, BASIS's research partner, with emphasis on deterministic systems, routing efficiency, and controlled strategy state transitions. {% endhint %} ## 4) Asset flow by wallet | Action | From | To | | --------------------------------- | --------------------- | --------------- | | Deposit BTC | External BTC wallet | Funding Wallet | | Deposit ETH/SOL/PAXG | Connected Web3 wallet | Funding Wallet | | Swap | Funding Wallet | Staking Wallet | | Unstake (subject to 7-day buffer) | Staked position | Staking Wallet | | Withdraw | Funding Wallet | External wallet | ## 5) Complete lifecycle examples {% tabs %} {% tab title="BTC" %} 1. Copy your BASIS-assigned BTC deposit address 2. Send at least `0.0001 BTC` from your external BTC wallet 3. BTC arrives in your Funding Wallet 4. Swap BTC to stBTC at 1:1 5. stBTC appears in your Staking Wallet 6. Stake stBTC 7. Rewards accumulate in real time as stBTC 8. After unstaking, the claimable amount is auto-credited to your Staking Wallet as stBTC, subject to a mandatory 7-day unstaking buffer. 9. Swap stBTC back to BTC at 1:1 10. Withdraw BTC from your Funding Wallet on-chain {% endtab %} {% tab title="ETH / SOL / PAXG" %} 1. Connect your Web3 wallet 2. Deposit ETH, SOL, or PAXG 3. Asset arrives in your Funding Wallet 4. Swap to the matching staking token at 1:1: * ETH → stETH * SOL → stSOL * PAXG → stPAXG 5. Stake the stToken 6. Rewards accumulate in real time as the same stToken 7. After unstaking, the claimable amount is auto-credited to your Staking Wallet as stToken, subject to a mandatory 7-day unstaking buffer. 8. Swap back to the native asset at 1:1 9. Withdraw from your Funding Wallet to your wallet address {% endtab %} {% endtabs %} ## 6) Operational rules | Rule | Details | | ------------------- | ------------------------------------- | | Deposit assets | BTC, ETH, SOL, PAXG only | | USDT | Internal accounting/display unit only | | Swap scope | Same-token only, always 1:1 | | BTC minimum deposit | `0.0001 BTC` | | Deposit fee | 0% | | Withdrawal fee | 0.05% | | Swap fee | 0.01% | ## 7) Related dashboard sections The wallet model is reflected across the dashboard: * Stake * Assets * Referral * Support * Account *** Next step: continue to Deposits to choose the correct asset funding flow. # Deposits {% 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)). {% endhint %} This page explains how to deposit supported assets into BASIS. Deposits are made in native assets only: * BTC * ETH * SOL * PAXG After deposit, assets are held in your Funding Wallet. Staking uses the corresponding stToken format: * BTC → stBTC * ETH → stETH * SOL → stSOL * PAXG → stPAXG {% hint style="warning" %} Swap on BASIS is same-token only at a 1:1 asset mapping: * BTC ↔ stBTC * ETH ↔ stETH * SOL ↔ stSOL * PAXG ↔ stPAXG BASIS does not support cross-asset conversion during deposit. {% endhint %} *** ## Supported assets and networks | Asset | Deposit Method | Network | Minimum Deposit | Confirmation Standard | Typical Credit Time | Status | | ----- | ------------------------------ | ---------------- | ------------------------------------------------------------------------------------------------- | --------------------- | ------------------- | ------- | | BTC | BASIS-assigned deposit address | Bitcoin Mainnet | 0.0001 BTC | Bitcoin confirmations | \10 to 60 minutes | 🟢 Live | | ETH | Web3 wallet connection | Ethereum Mainnet | Network practical minimum (see [Fees & Limits](https://docs.basis.pro/reference/fees-and-limits)) | Network confirmation | 1 to 10 minutes | 🟢 Live | | SOL | Web3 wallet connection | Solana Mainnet | Network practical minimum (see [Fees & Limits](https://docs.basis.pro/reference/fees-and-limits)) | Network finality | 1 to 10 minutes | 🟢 Live | | PAXG | Web3 wallet connection | Ethereum Mainnet | Network practical minimum (see [Fees & Limits](https://docs.basis.pro/reference/fees-and-limits)) | Network confirmation | 1 to 10 minutes | 🟢 Live | Always verify the deposit screen before sending funds. *** ## Wallet structure | Wallet | Holds | Primary Use | | -------------- | ---------------------------------- | ------------------------------- | | Funding Wallet | Native tokens: BTC, ETH, SOL, PAXG | Deposit and withdrawal | | Staking Wallet | stBTC, stETH, stSOL, stPAXG | Staking and reward accumulation | Rewards accumulate in real time as the same stToken in your Staking Wallet. *** ## Deposit methods {% tabs %} {% tab title="BTC" %} BTC deposits do not require a Web3 wallet connection. **How BTC deposit works** 1. Open Dashboard → Assets. 2. Select BTC. 3. Copy your BASIS-assigned Bitcoin deposit address. 4. Send BTC from your external wallet or exchange. 5. Wait for blockchain confirmations. 6. Once credited, BTC appears in your Funding Wallet. {% hint style="success" %} Each account receives a unique BASIS BTC deposit address. Use only the BTC network when sending to this address. {% endhint %} {% endtab %} {% tab title="ETH / SOL / PAXG" %} ETH, SOL, and PAXG deposits use a connected Web3 wallet such as MetaMask or a compatible wallet. **How Web3 deposits work** 1. Open Dashboard → Assets. 2. Select ETH, SOL, or PAXG. 3. Connect your supported Web3 wallet. 4. Confirm the deposit transaction in your wallet. 5. Wait for network confirmation. 6. Once credited, the asset appears in your Funding Wallet. {% hint style="success" %} PAXG deposit support is active and live. {% endhint %} {% endtab %} {% endtabs %} *** ## Step-by-step deposit flow {% stepper %} {% step %} **Open the Assets section** Go to Dashboard → Assets and select the asset you want to deposit. {% endstep %} {% step %} **Choose the correct deposit path** * BTC: copy your BASIS-assigned deposit address * ETH / SOL / PAXG: connect your Web3 wallet {% endstep %} {% step %} **Submit the transfer** Send only the selected native asset on its correct network. {% endstep %} {% step %} **Wait for confirmation** Your deposit is credited after the required blockchain confirmation or network finality. {% endstep %} {% step %} **Verify Funding Wallet balance** After crediting, the deposited native asset appears in your Funding Wallet and is available for same-token swap into the corresponding stToken. {% endstep %} {% endstepper %} *** ## Fees | Fee Type | Amount | | -------------- | ------------------------------------ | | Deposit Fee | 0% | | Withdrawal Fee | 0.05% | | Swap Fee | 0.01% | | Network Fee | Paid by sender, varies by blockchain | *** ## Important safety rules {% hint style="danger" %} Blockchain transactions are irreversible. Always verify asset type, network, and destination details before sending. {% endhint %} ### 1. Use the correct network Send each asset only on its supported network. * BTC → Bitcoin Mainnet * ETH → Ethereum Mainnet * SOL → Solana Mainnet * PAXG → Ethereum Mainnet Sending assets through an incompatible network can result in permanent loss. ### 2. Follow the correct deposit method * BTC uses a BASIS-assigned address * ETH, SOL, and PAXG use Web3 wallet connection Do not use a BTC address flow for ETH, SOL, or PAXG. ### 3. Start with a test transaction if needed If this is your first deposit, a small test transaction is recommended. ### 4. Confirm wallet destination carefully Copy and paste addresses where applicable. Do not enter addresses manually. ### 5. Do not send USDT USDT is used only as an internal accounting and display unit. It is not supported for deposit or withdrawal. *** ## What happens after deposit After your asset reaches the Funding Wallet, you may perform a same-token swap into the staking asset: | Native Asset | Staking Asset | | ------------ | ------------- | | BTC | stBTC | | ETH | stETH | | SOL | stSOL | | PAXG | stPAXG | Swap is 1:1 within the same asset pair, subject to the 0.01% swap fee. Example: {% hint style="info" %} **BTC Deposit Flow** 1. BTC is credited to your Funding Wallet 2. Swap BTC → stBTC at 1:1 (0.01% swap fee applies) 3. stBTC appears in your Staking Wallet 4. Stake stBTC to begin reward accumulation {% endhint %} *** ## Related operational timings | Action | Typical Time | | --------------- | ---------------- | | BTC withdrawal | 10 to 60 minutes | | ETH withdrawal | 1 to 10 minutes | | SOL withdrawal | 1 to 10 minutes | | PAXG withdrawal | 1 to 10 minutes | *** ## Dashboard navigation Relevant sections: * Stake * Assets * Referral * Support * Account *** ## Need help? If a deposit is delayed beyond the normal confirmation window, contact support with: * account identifier * asset type * transaction hash * amount * time submitted Support: # Deposit BTC This guide explains how to deposit Bitcoin (BTC) into BASIS. {% 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)). {% endhint %} *** ## 1. Overview When you deposit BTC into BASIS, the BTC is credited to your Funding Wallet after the required network confirmations. You can then swap BTC to stBTC at a 1:1 token conversion within the platform. * Funding Wallet: holds native tokens for deposit and withdrawal * Staking Wallet: holds stTokens used for staking and reward accrual {% hint style="warning" %} USDT is an internal accounting and display unit only. It is not depositable, withdrawable, or used as the asset you stake after a BTC deposit. {% endhint %} *** ## 2. Step-by-Step Guide ### Step 1: Open the Assets section Log in to BASIS and go to: `Dashboard → Assets → Deposit` Select `BTC` as the asset. ### Step 2: Copy your BTC deposit address BASIS will generate a unique Bitcoin deposit address for your account. {% hint style="warning" %} Send only native BTC on **Bitcoin Mainnet (BTC)**. Do not use other networks or wrapped formats. {% endhint %} Only send native BTC on Bitcoin Mainnet. Do not send: * BTC via wrapped formats * BTC via exchange-internal transfer rails that do not settle on Bitcoin Mainnet * assets from other networks {% hint style="danger" %} Send only native BTC to your assigned BTC address. Deposits sent through unsupported networks may be permanently lost. {% endhint %} ### Step 3: Send BTC from your wallet or exchange From your external wallet or exchange account, send BTC to the address shown in BASIS. Minimum BTC deposit: **No minimum** Before confirming: * verify the address carefully * confirm the network is Bitcoin Mainnet ### Step 4: Wait for network confirmations BTC deposits are credited after the required blockchain confirmations. | Requirement | Typical Time | | --------------------------------------- | ---------------- | | Bitcoin network confirmation processing | 10 to 60 minutes | After confirmation, the BTC will appear in your Funding Wallet. ### Step 5: Swap BTC to stBTC To stake BTC, convert BTC to stBTC inside BASIS. Swap rules: * BTC → stBTC only * 1:1 same-token swap structure * swap fee: 0.01% {% hint style="info" %} BASIS supports only same-token swaps: * BTC → stBTC * ETH → stETH * SOL → stSOL * PAXG → stPAXG {% endhint %} ### Step 6: Stake stBTC After the swap, your stBTC will appear in your Staking Wallet. Go to: `Dashboard → Stake` From there, you can: * choose a fixed staking pool * apply a Booster if desired * begin real-time reward accumulation in stBTC *** ## 3. Fees | Fee Type | Amount | | -------------- | ------------------------------------------------------ | | Deposit Fee | 0% | | Withdrawal Fee | 0.05% | | Swap Fee | 0.01% | | Network Fee | Paid by you to the blockchain network when sending BTC | *** ## 4. Wallet Structure | Wallet | Holds | Purpose | | -------------- | ----- | -------------------------- | | Funding Wallet | BTC | Deposit and withdrawal | | Staking Wallet | stBTC | Staking and reward accrual | *** ## 5. Important Rules ### BTC deposit rules * each account receives a unique BTC deposit address * no Web3 wallet connection is required for BTC deposits * no minimum deposit * only native BTC is supported ### Staking rules * rewards accumulate in real time as stBTC * fixed pools can only be unstaked after the lock-up period ends * early unstake is not available * unstake is full-position only * when you unstake, the claimable amount is automatically credited to your Staking Wallet as stBTC *** ## 6. Troubleshooting ### Deposit not showing Check the following: * the transaction was sent on Bitcoin Mainnet * the destination address exactly matches your BASIS BTC deposit address * the transaction has confirmed on-chain If the transaction is confirmed and still not visible, contact: `support@basis.pro` ### Sent less than the minimum ### Sent via the wrong network Transactions sent through unsupported networks or formats cannot be guaranteed recoverable. ### Sent to the wrong address Blockchain transactions are irreversible. If BTC was sent to an incorrect address, recovery may not be possible. *** ## 7. Operational Notes BASIS infrastructure is designed around deterministic execution, state-machine risk controls, and mathematically bounded system behavior. Core platform characteristics include: * structural alpha capture research supported by Base58 Labs * BHLE routing infrastructure * sub-50μs latency * 100K+ OPS throughput * execution precision with deterministic system controls For additional assistance, use the `Support` section in the dashboard or email `support@basis.pro`. # Deposit ETH {% 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)). {% endhint %} This guide explains how to deposit Ethereum (ETH) into BASIS. ## 1. Overview ETH deposits are made by connecting a Web3 wallet such as MetaMask and sending ETH on Ethereum Mainnet. After your deposit is credited to your Funding Wallet, you may swap ETH to stETH at a 1:1 ratio, less the swap fee. Staking rewards accumulate in real time as stETH in your Staking Wallet. {% hint style="warning" %} ETH deposits do not convert to USDT. USDT is used only as an internal accounting and display unit. It is not depositable or withdrawable. ETH can only be swapped to stETH on a same-token 1:1 basis. {% endhint %} ## 2. Before you start > \[!INFO] Wallet structure on BASIS: > > * Funding Wallet: holds native tokens for deposit and withdrawal > * Staking Wallet: holds stTokens for staking and reward accrual | Asset | Deposit Method | Wallet Required | | ----- | ------------------- | ----------------------------- | | ETH | Connect Web3 wallet | MetaMask or compatible wallet | ## 3. Step-by-step ### Step 1: Go to Assets Log in to BASIS and open the Assets section from the dashboard. ### Step 2: Select ETH Choose ETH as the asset you want to deposit. ### Step 3: Connect your wallet Connect your Web3 wallet, such as MetaMask, and confirm that you are using Ethereum Mainnet. {% hint style="warning" %} Only Ethereum Mainnet is supported for ETH deposits. Do not send ETH using Arbitrum, Optimism, BNB Smart Chain, or other networks. {% endhint %} ### Step 4: Approve and send ETH Enter the amount of ETH you want to deposit and confirm the transaction in your wallet. The ETH will be credited to your Funding Wallet after network confirmation. ### Step 5: Wait for confirmation ETH deposits are typically credited within 1 to 10 minutes, depending on network conditions. | Network | Typical Credit Time | | ---------------- | ------------------- | | Ethereum Mainnet | 1 to 10 minutes | ### Step 6: Swap ETH to stETH Once your ETH appears in the Funding Wallet, you can swap ETH to stETH. Swap rules: * ETH → stETH only * 1:1 same-token swap * Swap fee: 0.01% ### Step 7: Stake stETH After the swap, your stETH appears in the Staking Wallet. Open the Stake section to stake your stETH. Available booster options: | Booster | Reward Multiplier | | ------- | ----------------- | | 14D | +10% | | 30D | +20% | | 90D | +50% | | 180D | +100% | {% hint style="warning" %} Fixed pools can only be unstaked after the selected lock-up period ends. Early exit is not available. {% endhint %} ## 4. Fees | Fee Type | Amount | | -------------- | ------ | | Deposit Fee | 0% | | Withdrawal Fee | 0.05% | | Swap Fee | 0.01% | > \[!INFO] Ethereum gas fees are paid from your external wallet and are separate from BASIS platform fees. ## 5. Reward and unstake behavior * Rewards accumulate in real time as stETH * Rewards appear in the Staking Wallet * Unstake is processed as full-position only * The claimable amount is auto-credited to the Staking Wallet as stETH upon unstake ## 6. Troubleshooting ### Deposit not showing * Confirm you used Ethereum Mainnet * Check the wallet transaction status * Allow up to 6 minutes for crediting under normal conditions ### Wrong network used If ETH was sent through an unsupported network, recovery may not be possible. ### Wrong address or incorrect transaction Blockchain transactions are irreversible. Always verify the transaction details before confirming. ## 7. Platform notes BASIS is designed around deterministic execution, math-constrained state transitions, and state machine risk controls. Its routing stack is informed by Base58 Labs research and optimized for structural alpha capture through precise execution. BHLE infrastructure characteristics include: * Sub-50μs latency * 100K+ OPS * Proprietary routing infrastructure For operational support, contact . # Deposit SOL {% 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)). {% endhint %} This guide explains how to deposit Solana (SOL) into BASIS. ## 1. Overview SOL deposits are made through a connected Web3 wallet on Solana Mainnet. After deposit, your SOL remains tracked within your Funding Wallet. If you want to stake, you must perform a same-token 1:1 swap from SOL to stSOL. BASIS does not convert SOL deposits into USDT. USDT is used only as an internal accounting and display unit. {% hint style="warning" %} Supported deposit flow for SOL: * Deposit asset: native SOL * Deposit method: connect Web3 wallet * Staking asset: stSOL * Swap direction: SOL → stSOL only * Swap ratio: 1:1 * Swap fee: 0.01% {% endhint %} ## 2. Step-by-Step Guide ### Step 1: Go to Assets Log in to BASIS and open the Assets section from the dashboard. Dashboard sections: * Stake * Assets * Referral * Support * Account ### Step 2: Select SOL Choose SOL as your deposit asset. ### Step 3: Connect Your Web3 Wallet For SOL deposits, connect a compatible Solana wallet. Supported wallet flow: * Solana-compatible Web3 wallet * Solana Mainnet only * Native SOL only {% hint style="warning" %} Do not send assets from unsupported networks. Do not send wrapped assets or unsupported SPL tokens unless explicitly supported in the interface. Only native SOL on Solana Mainnet should be used for SOL deposits. {% endhint %} ### Step 4: Confirm the Deposit Enter the amount of SOL you want to deposit and approve the transaction from your wallet. After confirmation: * Deposited SOL appears in your Funding Wallet * Funding Wallet holds native tokens for deposit and withdrawal * Staking Wallet holds stTokens for staking and rewards ### Step 5: Swap SOL to stSOL To stake SOL, use the swap function to convert SOL to stSOL. {% hint style="info" %} **SOL Swap Details** * SOL → stSOL * Rate: 1:1 * Fee: 0.01% {% endhint %} {% hint style="info" %} BASIS supports same-token swaps only: * BTC → stBTC * ETH → stETH * SOL → stSOL * PAXG → stPAXG {% endhint %} ### Step 6: Stake stSOL Go to the Stake section and stake your stSOL. Rewards: * Accumulate in real time * Accrue as stSOL * Are credited to your Staking Wallet ## 3. Deposit and Settlement | Item | Value | | ----------------------- | --------------------- | | Supported network | Solana Mainnet | | Asset type | Native SOL | | Deposit method | Connected Web3 wallet | | Deposit fee | 0% | | Swap fee | 0.01% | | Withdrawal fee | 0.05% | | Typical withdrawal time | 1 to 10 minutes | ## 4. Wallet Structure | Wallet | Purpose | | -------------- | -------------------------------------------------- | | Funding Wallet | Holds native tokens for deposit and withdrawal | | Staking Wallet | Holds stTokens for staking and reward accumulation | ## 5. Staking Rules {% hint style="warning" %} Fixed pools cannot be unstaked early. Unstaking is available only after the lock-up period ends. {% endhint %} Additional rules: * Rewards accumulate in real time as stSOL * Unstake action is auto-MAX only * Full position only * On unstake, the claimable amount is auto-credited to your Staking Wallet as stSOL ### Booster options | Booster | Reward Multiplier | | ------- | ----------------- | | 14D | +10% | | 30D | +20% | | 90D | +50% | | 180D | +100% (2x) | ## 6. Why SOL Is Supported SOL is supported because it is an important settlement asset within digital asset markets and integrates efficiently with BASIS infrastructure. Key reasons: * Fast finality and efficient on-chain settlement * Broad market depth across spot and derivatives venues * Useful for structural alpha capture across fragmented liquidity environments * Compatible with deterministic execution workflows and state-machine-based risk controls BASIS infrastructure is designed around: * Deterministic execution * Mathematical constraint systems * State machine risk controls * BHLE architecture with sub-50μs latency * 100K+ OPS routing capacity * Proprietary routing infrastructure informed by Base58 Labs research ## 7. Troubleshooting ### Deposit not showing Check the following: * Your wallet was connected on Solana Mainnet * You deposited native SOL * The transaction was successfully finalized on-chain * The connected wallet matches the depositing address ### Sent from the wrong network Assets sent through unsupported networks may not be recoverable. ### Balance visible but cannot stake You may still hold SOL in your Funding Wallet. To stake, first swap SOL to stSOL. ### Need help Contact . # Deposit PAXG (Ethereum) {% 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)). {% endhint %} PAXG is live and fully supported on Ethereum. You can deposit PAXG by connecting a compatible Web3 wallet. ## Steps {% stepper %} {% step %} Open the app and go to Account → Assets. {% endstep %} {% step %} Select Deposit. {% endstep %} {% step %} Choose PAXG (Ethereum). {% endstep %} {% step %} Connect your Ethereum wallet, such as MetaMask. {% endstep %} {% step %} Approve and confirm the PAXG transfer. {% endstep %} {% endstepper %} ## Network requirements {% hint style="warning" %} PAXG is an ERC-20 asset on Ethereum. Your wallet must hold enough ETH to pay network gas fees. {% endhint %} ## After deposit Deposited PAXG appears in your Funding Wallet. From there, you may swap PAXG to stPAXG at a 1:1 ratio. | Action | Result | | ------------------ | ----------------------------------------------------------- | | Deposit PAXG | PAXG credited to Funding Wallet | | Swap PAXG → stPAXG | 1:1 conversion | | Stake stPAXG | Rewards accumulate in real time as stPAXG in Staking Wallet | ## Fees | Type | Fee | | ---------- | ----- | | Deposit | 0% | | Swap | 0.01% | | Withdrawal | 0.05% | ## Notes * PAXG deposits require Web3 wallet connection * PAXG cannot be sent from the BTC deposit flow * USDT is used only as an internal display and accounting unit * If you are depositing for the first time, a small test transaction is recommended ## Related risk considerations PAXG includes asset-specific considerations such as issuer exposure, redemption conditions, and Ethereum network congestion. BASIS manages execution through deterministic routing, math-constrained state transitions, and state machine risk controls designed to preserve execution precision. For support, contact . # Wallet Connection Guide How to deposit ETH, PAXG, and SOL using the correct smart-contract wallet flow on BASIS. {% 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)). {% endhint %} This guide explains the correct wallet connection flow for ETH, PAXG, and SOL deposits on BASIS. *** ## Supported Assets and Wallets | Asset | Supported Network | Recommended Wallet | Required Path | | ----- | --------------------- | ------------------ | ---------------------------------- | | ETH | Ethereum Mainnet only | MetaMask | Assets page > Deposit | | PAXG | Ethereum ERC-20 only | MetaMask | Assets page > Deposit | | SOL | Solana Mainnet only | Phantom Wallet | Assets page > Deposit | | BTC | Bitcoin Mainnet only | N/A | BASIS-assigned BTC deposit address | {% hint style="warning" %} ETH and PAXG deposits must be completed on an Ethereum/ERC-20 compatible wallet flow. SOL deposits must be completed on the Solana wallet flow. If an unsupported wallet cannot complete the smart-contract flow, use the recommended wallet for that asset. {% endhint %} *** ## Correct Flow: Deposit from the Assets Page ### Step 1 - Open the Assets Page Navigate to **Assets** and locate the **Deposit**, **Withdraw**, or **Swap** buttons. These buttons open the BASIS asset-specific deposit workflow. {% hint style="success" %} Always start deposits from the **Assets page**. Use the Deposit, Withdraw, or Swap buttons shown below. {% endhint %} ![Use the Deposit / Withdraw / Swap buttons on the Assets page.](https://docs-img.basis.pro/step-01-assets-page.png) *** ### Step 2 - Select the Asset and Connect the Correct Wallet If the selected asset does not have a wallet connected, the deposit modal will display a **Connect Wallet** button. Click it to begin the wallet connection. ![If the asset wallet is not connected, click Connect Wallet from the deposit modal.](https://docs-img.basis.pro/step-02-connect-wallet.png) *** ### Step 3 - Choose the Recommended Wallet Select the wallet that matches the asset network. * For **ETH** and **PAXG**: select **MetaMask** * For **SOL**: select **Phantom Wallet** {% hint style="info" %} WalletConnect and other wallets may appear in the list, but compatibility can vary. Use MetaMask for ETH/PAXG and Phantom for SOL to ensure a reliable flow. {% endhint %} ![Select MetaMask for ETH/PAXG or Phantom Wallet for SOL.](https://docs-img.basis.pro/step-03-wallet-selection.png) *** ### Step 4 - Approve the Wallet Connection Review the wallet connection prompt in your wallet application. Confirm only the account you intend to use for this deposit. ![Review the account details and approve the wallet connection.](https://docs-img.basis.pro/step-04-approve-connection.png) *** ### Step 5 - Confirm the Deposit Transaction Review the amount, asset, and destination in the BASIS deposit modal. Then confirm the transaction in your connected wallet. {% hint style="warning" %} Verify all details - asset type, network, amount, and destination address - before signing. Confirm only after everything matches the BASIS deposit modal. {% endhint %} ![Review the amount and confirm the transaction in your connected wallet.](https://docs-img.basis.pro/step-05-confirm-transaction.png?v=2) *** ## Switching Between MetaMask and Phantom This section explains how to switch from an Ethereum-compatible wallet used for ETH or PAXG to a Solana-compatible wallet when depositing SOL. Use this flow whenever you need to move between Ethereum and Solana wallet connections. ### Overview BASIS uses asset-specific wallet connections. ETH and PAXG are handled on the Ethereum network and are recommended to be used with MetaMask. SOL is handled on the Solana network and is recommended to be used with Phantom Wallet or another Solana-compatible wallet. If an Ethereum wallet is currently connected and you want to deposit SOL, disconnect the Ethereum wallet first, then connect a Solana-compatible wallet from the Deposit modal. | Asset | Network | Recommended Wallet | Action | | ----- | -------- | ------------------ | ----------------------------------------------------------------------------------------- | | ETH | Ethereum | MetaMask | Use Deposit / Withdraw from the Assets page. | | PAXG | Ethereum | MetaMask | Use the same Ethereum wallet flow as ETH. | | SOL | Solana | Phantom Wallet | Disconnect the Ethereum wallet first, then connect Phantom or a Solana-compatible wallet. | {% hint style="info" %} The wallet shown in the top-right corner is the currently connected wallet. Use it to manage, switch, or disconnect the active wallet connection before selecting another network. {% endhint %} *** ### Step 1 - Open the Connected Wallet Panel On the Assets page, click the connected wallet indicator in the top-right corner. This opens the Connected Wallet panel. ![Open the Connected Wallet panel from the top-right wallet indicator.](https://docs-img.basis.pro/step-switch-01.png) *** ### Step 2 - Disconnect the Current Ethereum Wallet If you were previously using ETH or PAXG, an Ethereum wallet may still be connected. Click **Disconnect** to clear the current Ethereum wallet connection. ![Disconnect the currently connected Ethereum wallet before switching to SOL.](https://docs-img.basis.pro/step-switch-02.png) *** ### Step 3 - Select Solana (SOL) in the Deposit Modal Return to **Assets**, open **Deposit**, and select **Solana (SOL)**. When no Solana wallet is connected, click **Connect Wallet**. ![Select Solana (SOL), then click Connect Wallet.](https://docs-img.basis.pro/step-switch-03.png) *** ### Step 4 - Choose a Solana-Compatible Wallet Select **Phantom Wallet** or another Solana-compatible wallet from the wallet list. BASIS recommends Phantom Wallet for SOL operations. ![Select Phantom Wallet or another Solana-compatible wallet.](https://docs-img.basis.pro/step-switch-04.png) *** ### Step 5 - Approve the Wallet Connection Your wallet will display a connection request. Review the account and connect it to basis.pro. Only approve connection requests from the official BASIS website. ![Confirm the connection request inside the selected Solana wallet.](https://docs-img.basis.pro/step-switch-05.png) *** ### Step 6 - Confirm That the SOL Wallet Is Active After the Solana wallet is connected, the SOL Deposit form becomes available. Review the connected wallet, enter the amount, and proceed with the deposit flow. ![The SOL Deposit form is available after a Solana wallet is connected.](https://docs-img.basis.pro/step-switch-06.png) *** ### Switching Back to ETH or PAXG The same process applies in reverse. If a Solana wallet is connected and you want to deposit or withdraw ETH or PAXG, open the Connected Wallet panel, disconnect the Solana wallet, and then connect MetaMask on the Ethereum network. After switching wallets, always confirm that the selected asset, network, and connected wallet match before proceeding with Deposit or Withdraw. *** ## Troubleshooting Checklist * Confirm the selected asset matches the wallet network. * For ETH and PAXG: verify the wallet is using the **Ethereum / ERC-20** network. * For SOL: verify **Phantom Wallet** is connected and set to **Solana Mainnet**. * Refresh the page and reconnect the recommended wallet if the Deposit button does not proceed. * If a third-party wallet fails to complete the flow, retry with **MetaMask** (ETH/PAXG) or **Phantom** (SOL). * Disconnect the previously connected wallet when switching between Ethereum and Solana networks. * After switching wallets, confirm that the selected asset, network, and connected wallet match before proceeding. * If the expected wallet is not shown, verify that the wallet extension is installed, unlocked, and set to the correct network. * If support review is required, provide the asset, network, wallet address, screenshots, and transaction hash (if a transaction was submitted). *** ## Related Resources * [BASIS App](https://basis.pro) * [BASIS Documentation](https://docs.basis.pro) * [Deposit BTC](https://docs.basis.pro/getting-started/deposits/deposit-btc) * [Deposit ETH](https://docs.basis.pro/getting-started/deposits/deposit-eth) * [Deposit SOL](https://docs.basis.pro/getting-started/deposits/deposit-sol) * [Deposit PAXG](https://docs.basis.pro/getting-started/deposits/deposit-paxg) # Deposit Address Pool Architecture {% 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 maintains a large, dynamically allocated pool of deposit addresses that serves its global user base. Because the platform supports tens of thousands of users across multiple networks and assets, the same blockchain deposit address may be assigned to different users at different points in time. This behavior is **normal, expected, and by design.** A deposit address that appears to have activity associated with more than one user does not mean funds are mixed, shared, or at risk. BASIS separates user balances through its internal accounting ledger and enforces custody security at the MPC key management layer, not through exclusive address ownership. *** ## How the address pool model works BASIS uses an address pool model rather than a permanent one-address-per-user model. Deposit addresses are managed as platform infrastructure and allocated to users when needed. {% tabs %} {% tab title="Traditional model" %} Each user is permanently assigned one fixed address per asset. The address never changes. All transaction history on that address belongs to one account forever. This approach is simpler to understand but creates address correlation risks and operational rigidity at scale. {% endtab %} {% tab title="BASIS pool model" %} Addresses are drawn from a large shared pool and assigned dynamically. An address may serve one user today and a different user later. User funds and balances are tracked through an internal ledger, not through address exclusivity. This is the institutional-grade approach used by large custodial platforms and asset managers. {% endtab %} {% endtabs %} ### Pool components | Component | Role | | ---------------------- | --------------------------------------------------------------------------------------- | | Deposit address pool | A large set of blockchain addresses managed by BASIS across all supported networks | | Dynamic assignment | Addresses are drawn from the pool and assigned to users based on operational parameters | | Reassignment over time | After a deposit is settled, an address may later be allocated to another user | | Internal ledger | The authoritative record of every user's balance, credit, and withdrawal history | | MPC custody layer | The cryptographic key management layer that controls signing authority | {% hint style="warning" %} A blockchain address is a delivery endpoint for receiving assets on a public network. It is not the source of truth for account ownership inside BASIS. Your balance is defined by the internal ledger, not by what a blockchain explorer shows on your deposit address. {% endhint %} *** ## Why address overlap happens Public blockchains expose address-level transaction history to anyone. A blockchain explorer shows deposits, withdrawals, and token transfers for a given address, but it has no visibility into BASIS's internal assignment records or ledger state. Address overlap may occur when: * A deposit address was assigned to one user at an earlier point in time. * The same address was later reassigned and used by another user. * Multiple historical deposits appear under the same on-chain address. * A blockchain explorer displays the full address history without knowing which BASIS account was credited for each transaction. This is standard practice in custodial and institutional digital asset infrastructure. Blockchain addresses are observable on-chain. User attribution and balance ownership are controlled through internal platform records. {% hint style="info" %} If you view your BASIS deposit address on a blockchain explorer such as Mempool, Etherscan, or Solscan, you may see transactions that were not made by you. This is expected behavior. It does not indicate any problem with your account or your funds. {% endhint %} *** ## Why this is secure User fund isolation at BASIS is enforced through internal accounting and custody controls, not through address exclusivity. Security operates at three independent layers. {% tabs %} {% tab title="Internal ledger" %} Each user balance is tracked in BASIS's internal ledger independently from raw blockchain address history. When a deposit is detected, BASIS attributes it to the correct user account based on the active deposit instruction, asset, network, transaction hash, confirmation count, and account records. No transaction is applied to a user account simply because it appeared at a deposit address. Attribution requires a confirmed match against the active assignment record. {% endtab %} {% tab title="MPC custody" %} BASIS uses MPC wallet architecture via Privy. In an MPC model, private key material is split into cryptographic shares distributed across independent parties. No single party, including BASIS itself, holds a complete private key. Signing requires controlled participation from multiple independent keyholders through the MPC protocol. Address sharing or reassignment does not weaken the MPC custody model, because custody security depends on key management policy and signing controls, not on whether an address has been used by one account or multiple accounts over time. {% endtab %} {% tab title="Reconciliation" %} BASIS operates continuous post-execution reconciliation between internal ledger records and external balances. Every custody movement, deposit event, and venue balance is verified against the internal ledger on an ongoing basis. If a discrepancy is detected at any layer, the BSCB circuit breaker triggers immediately and halts affected activity until the discrepancy is resolved and verified. {% endtab %} {% endtabs %} {% hint style="success" %} Address overlap does not commingle user funds. Each user's balance is isolated and tracked through BASIS's internal ledger, which is the authoritative accounting system. Address sharing is an operational design choice. It has no effect on fund separation or custody security. {% endhint %} *** ## Reconciliation model BASIS operates continuous post-execution reconciliation across all layers of the system. | Reconciliation layer | What is verified | | --------------------- | ------------------------------------------------------------------------------------- | | Deposit detection | Network, asset, amount, transaction hash, confirmation count, and destination address | | Ledger attribution | Correct user account credit matched against active assignment records | | Custody balance check | Internal balance records compared against controlled MPC wallet state | | Venue balance check | Internal records verified against external venue balances where applicable | | Exception handling | Immediate discrepancy flag and operational halt through BSCB circuit breaker | If reconciliation identifies any mismatch, the BSCB circuit breaker triggers. The affected process is halted immediately and flagged for investigation before any further activity proceeds. This control prevents reconciliation inconsistencies from propagating through the platform. *** ## Privacy benefits Address pooling improves user privacy on public blockchains as an additional structural benefit. A permanent one-to-one address model makes it straightforward for third parties to correlate a specific deposit address with a single user account, track balance history, and link activity across time. Pooling reduces this direct correlation risk. It becomes significantly harder to map a public address to a specific account or to construct a longitudinal view of a single user's on-chain behavior. {% hint style="info" %} Address pooling does not make public blockchain activity private in an absolute sense. On-chain transactions remain visible to anyone. The benefit is a meaningful reduction in simple address correlation attacks and long-term behavioral tracking by third parties. {% endhint %} *** ## What users should know {% hint style="success" %} **Key facts for BASIS users** * Address overlap between users is normal and expected for BASIS deposit infrastructure. * A deposit address may show historical on-chain activity that is not related to your account. * Your BASIS balance is determined by the internal ledger, not by what a block explorer shows. * Security is enforced through MPC custody via Privy, continuous reconciliation, and BSCB circuit breaker controls. * If reconciliation detects any failure, BSCB immediately flags and halts the affected process. * Always use the deposit address currently displayed inside your authenticated BASIS account session. * Unexpected historical activity on a blockchain explorer does not indicate any risk to your funds. {% endhint %} The address pool model is a deliberate institutional design choice. It allows BASIS to serve a large and growing global user base efficiently while maintaining ledger-level fund isolation, MPC custody security, continuous post-execution reconciliation, and improved privacy against public blockchain correlation. # Swap, Stake & Earn {% 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)). {% endhint %} After your deposit arrives in the Funding Wallet, you can swap into the corresponding stToken to allocate capital into BASIS staking flows. ## 1) Swap step: native token to matching stToken BASIS supports same-token 1:1 swaps only. | Native token | stToken | Swap ratio | | ------------ | ------- | ---------- | | BTC | stBTC | 1:1 | | ETH | stETH | 1:1 | | SOL | stSOL | 1:1 | | PAXG | stPAXG | 1:1 | {% hint style="success" %} PAXG is fully live and supported. {% endhint %} ### Supported wallet flow by asset {% tabs %} {% tab title="BTC" %} * Deposit BTC by copying your BASIS-assigned BTC deposit address * No Web3 wallet connection is required for BTC deposits * Minimum deposit: 0.0001 BTC {% endtab %} {% tab title="ETH / SOL / PAXG" %} * Connect a supported Web3 wallet such as MetaMask * Deposit the native asset on the correct network * The deposited asset appears in your Funding Wallet {% endtab %} {% endtabs %} ### Why the swap step exists The swap step creates a clear system boundary between custody and participation: * Funding Wallet holds native tokens for deposit and withdrawal * Staking Wallet holds stTokens for staking and reward accrual * principal and rewards are tracked with deterministic accounting * state transitions are controlled by internal risk checks This structure supports deterministic execution, math-constrained accounting, and state machine risk controls. ## 2) What happens after you stake Once swapped, the stToken appears in your Staking Wallet. Rewards then: * accumulate in real time * accrue in the same stToken denomination * remain visible in the dashboard as your position updates * are governed by system safety conditions and execution controls {% hint style="info" %} Rewards accrue in the Staking Wallet as stBTC, stETH, stSOL, or stPAXG depending on the asset staked. {% endhint %} ## 3) How rewards should be understood Rewards are variable and should not be interpreted as a fixed interest rate. They are driven by: * structural alpha capture * execution precision across BASIS infrastructure * net strategy outcomes after fees and operating conditions * internal safety controls that can limit or pause allocation activity when required BASIS infrastructure is designed around deterministic execution and disciplined routing logic, including: * sub-50μs latency architecture * 100K+ OPS routing capacity * proprietary execution infrastructure * mathematically constrained risk controls ## 4) Fees and operational parameters | Item | Value | | -------------- | ----- | | Deposit fee | 0% | | Withdrawal fee | 0.05% | | Swap fee | 0.01% | | Asset | Typical withdrawal time from Funding Wallet | | ----- | ------------------------------------------- | | BTC | 10 to 60 minutes | | ETH | 1 to 10 minutes | | SOL | 1 to 10 minutes | | PAXG | 1 to 10 minutes | {% hint style="info" %} These processing targets apply after assets are available in the Funding Wallet. Unstaking is subject to a mandatory 7-day buffer before claimable amounts are credited, and fixed-pool unstaking must also satisfy the full lock-up period before the 7-day buffer begins. {% endhint %} ## 5) Booster lock options If you choose a fixed pool booster, the following multipliers apply: | Lock period | Booster | | ----------- | ---------- | | 14D | +10% | | 30D | +20% | | 90D | +50% | | 180D | +100% (2×) | {% hint style="warning" %} Fixed pools can only be unstaked after the full lock-up period ends. Early exit is not available, and a mandatory 7-day unstaking buffer applies before the claimable amount is credited to the Staking Wallet. {% endhint %} ## 6) Before you stake {% stepper %} {% step %} Review the Risk Disclosure documentation. {% endstep %} {% step %} Confirm the token and network are correct. {% endstep %} {% step %} Confirm you are swapping only into the matching stToken: * BTC → stBTC * ETH → stETH * SOL → stSOL * PAXG → stPAXG {% endstep %} {% step %} Understand wallet roles: * Funding Wallet = native token deposits and withdrawals * Staking Wallet = stTokens, staking positions, and reward accrual {% endstep %} {% step %} If using a fixed pool, confirm you accept full lock-up until maturity and the mandatory 7-day unstaking buffer before claimable amounts are credited. {% endstep %} {% endstepper %} ## 7) Unstake and reward crediting When unstaking: * the unstake action applies to the full staked position only * partial unstake is not supported * claimable amounts are automatically credited to the Staking Wallet as stToken after the mandatory 7-day unstaking buffer * you may then swap back 1:1 into the corresponding native token before withdrawal ## 8) Dashboard path Use the following sections to manage the full flow: * Stake * Assets * Referral * Support * Account *** Next step: review how unstake and reward crediting work across the BASIS dashboard. # Claiming Rewards {% 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)). {% endhint %} BASIS treats these as separate concepts: 1. Accrual: rewards accumulate in real time while your position is active 2. Unstake: after the lock-up period ends, you may initiate release of your full staked position, subject to the mandatory 7-day unstaking buffer 3. Credit to wallet: claimable value is automatically credited to your Staking Wallet as the same stToken after the 7-day unstaking buffer is complete ## 1) Why BASIS uses explicit reward realization events Reward realization matters because it: * creates a discrete accounting event * creates auditable timestamps * supports deterministic state transitions in the staking system * enables contribution-based reward system calculations where applicable {% hint style="success" %} Rewards accumulate in real time as the same stToken and are credited to the Staking Wallet after the mandatory 7-day unstaking buffer following unstake. {% endhint %} ## 2) How reward realization works There is no separate partial-claim workflow for standard fixed staking positions. ### Fixed pool behavior * Rewards accrue continuously while the position is locked * Early exit is not available * Unstake is only available after the lock-up period ends * All unstaking actions are subject to a mandatory 7-day unstaking buffer * Unstake is processed as full position only * The entire claimable amount is auto-credited to your Staking Wallet as stToken after the mandatory 7-day unstaking buffer ## 3) User flow {% stepper %} {% step %} Open Dashboard → Stake {% endstep %} {% step %} Review your active position, accrued rewards, and lock-up status {% endstep %} {% step %} When the lock-up period has ended, click Unstake {% endstep %} {% step %} Wait for the mandatory 7-day unstaking buffer to complete {% endstep %} {% step %} Your principal plus rewards are automatically credited to your Staking Wallet as the same stToken after the mandatory 7-day unstaking buffer {% endstep %} {% endstepper %} ## 4) Claim vs withdraw vs swap These actions are different and should not be confused. | Action | What it does | Wallet | | -------- | ----------------------------------------------------------------------------------------------------------------- | ------------------------------------ | | Accrual | Rewards accumulate in real time | Staking position | | Unstake | Releases the full staked position after lock-up ends, subject to a mandatory 7-day unstaking buffer before credit | Staking Wallet | | Swap | Converts stToken to the same native token at 1:1 | Staking Wallet / Funding Wallet flow | | Withdraw | Sends native token out of BASIS | Funding Wallet | ### Important rules * Rewards are earned as stToken, not native token * Swaps are same-token only at 1:1 * Supported swap pairs are: * BTC → stBTC * ETH → stETH * SOL → stSOL * PAXG → stPAXG {% tabs %} {% tab title="BTC" %} * Deposit BTC by copying your BASIS-assigned BTC address * No Web3 wallet connection is required for BTC deposits * Minimum deposit: 0.0001 BTC * After the mandatory 7-day unstaking buffer, stBTC can be swapped 1:1 to BTC * BTC withdrawals from the Funding Wallet typically complete in 10 to 60 minutes {% endtab %} {% tab title="ETH / SOL / PAXG" %} * Deposit by connecting a supported Web3 wallet such as MetaMask * After the mandatory 7-day unstaking buffer, stETH, stSOL, or stPAXG can be swapped 1:1 to the corresponding native asset * ETH, SOL, and PAXG withdrawals from the Funding Wallet typically complete in 1 to 10 minutes {% endtab %} {% endtabs %} *Note: Unstaking from fixed pools requires an additional 7-day buffer before these withdrawal times apply.* ## 5) Funding Wallet and Staking Wallet BASIS uses a two-wallet model: | Wallet | Purpose | Asset Type | | -------------- | -------------------------------------- | ---------------------------------- | | Funding Wallet | Deposit and withdraw | Native tokens: BTC, ETH, SOL, PAXG | | Staking Wallet | Hold staked asset balances and rewards | stBTC, stETH, stSOL, stPAXG | {% hint style="warning" %} You cannot withdraw stTokens directly. To exit the platform, first unstake if applicable and wait for the mandatory 7-day unstaking buffer to complete, then swap the stToken 1:1 into its corresponding native token, then withdraw from the Funding Wallet. {% endhint %} ## 6) Fees | Action | Fee | | ---------- | ----- | | Deposit | 0% | | Withdrawal | 0.05% | | Swap | 0.01% | ## 7) Booster reminder If your position used a Booster, the applicable multiplier remains part of the position economics during the selected lock period. | Booster | Reward Boost | | ------- | ------------ | | 14D | +10% | | 30D | +20% | | 90D | +50% | | 180D | +100% (2×) | ## 8) Contribution-aligned referral network logic Referral network distributions do not activate simply from sign-up. They are evaluated based on qualifying user actions and system state transitions, including realized reward events where applicable. If you participate in the referral network, review the relevant reward flow documentation carefully before estimating downstream distribution outcomes. *** BASIS is designed around deterministic execution, mathematical constraints, and state-machine risk controls. This ensures reward realization, wallet crediting, swap handling, and withdrawal processing remain transparent and auditable. # Withdrawals {% 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)). {% endhint %} This page explains how withdrawals work, supported assets, timing, and fees. *** ## 1. Withdrawal Process Withdrawals follow the asset flow of the platform: * Funding Wallet holds native assets: BTC, ETH, SOL, PAXG * Staking Wallet holds stTokens: stBTC, stETH, stSOL, stPAXG To withdraw, you must first unstake your full position from the relevant pool. Unstaking is full-position only and auto-MAX. {% stepper %} {% step %} **Go to Stake** Open the Stake section in the dashboard. {% endstep %} {% step %} **Select the active position** Choose the pool you want to exit. Supported staking pairs are: * BTC ↔ stBTC * ETH ↔ stETH * SOL ↔ stSOL * PAXG ↔ stPAXG {% endstep %} {% step %} **Unstake the full position** Unstaking is processed on a full-position basis only. When you initiate unstake, the system automatically applies MAX to the entire staked balance for that pool. Once confirmed, the claimable amount is automatically credited to your Staking Wallet as the corresponding stToken upon completion of the lock-up requirement. {% endstep %} {% step %} **Move to withdrawal** After unstake is completed and the balance is available for withdrawal, proceed to Assets and submit a withdrawal request from your Funding Wallet in the native asset. {% endstep %} {% endstepper %} *** ## 2. Supported Withdrawal Assets Withdrawals are available only in the same native asset family used by the account balance. ### BTC * Network: Bitcoin only * Minimum withdrawal: 0.0002 BTC * Estimated arrival: \10 to 60 minutes {% hint style="warning" %} BTC withdrawals are supported on the Bitcoin network only. Non-Bitcoin addresses may cause irreversible loss of funds. {% endhint %} ### ETH * Network: Ethereum * Minimum withdrawal: 0.004 ETH * Estimated arrival: 1 to 10 minutes {% hint style="warning" %} ETH withdrawals are executed via smart contract to your connected wallet on Ethereum. Please ensure your connected wallet supports ETH. Transactions on-chain cannot be reversed. {% endhint %} ### PAXG * Network: Ethereum (ERC-20) * Minimum withdrawal: 0.002 PAXG * Estimated arrival: 1 to 10 minutes {% hint style="warning" %} PAXG withdrawals are executed via smart contract to your connected wallet on Ethereum (ERC-20). Transactions on-chain cannot be reversed. {% endhint %} ### SOL * Network: Solana * Minimum withdrawal: 0.1 SOL * Estimated arrival: 1 to 10 minutes {% hint style="warning" %} SOL withdrawals are executed via smart contract to your connected wallet on Solana. Transactions on-chain cannot be reversed. {% endhint %} {% hint style="warning" %} USDT is not a depositable or withdrawable asset. It is used only as an internal accounting and display unit. {% endhint %} *** ## 3. Asset Conversion Rules Swaps are same-token only and always 1:1 within the BASIS asset model. | Native Asset | Staking Asset | Swap Rule | | ------------ | ------------- | ----------------- | | BTC | stBTC | 1 BTC = 1 stBTC | | ETH | stETH | 1 ETH = 1 stETH | | SOL | stSOL | 1 SOL = 1 stSOL | | PAXG | stPAXG | 1 PAXG = 1 stPAXG | There is no cross-asset withdrawal conversion at withdrawal time. Examples: * BTC withdraws as BTC * ETH withdraws as ETH * SOL withdraws as SOL * PAXG withdraws as PAXG *** ## 4. Fees | Action | Fee | | ---------- | ----- | | Deposit | 0% | | Swap | 0.01% | | Withdrawal | 0.05% | {% hint style="info" %} There is no separate unstaking fee. Network execution is handled within the platform withdrawal fee structure. {% endhint %} *** ## 5. Fixed Pools and Lock-Up Rules Booster schedules are: | Lock Period | Booster | | ----------- | ---------- | | 14D | +10% | | 30D | +20% | | 90D | +50% | | 180D | +100% (2×) | Important rule: * Fixed pools can be unstaked only after the lock-up period ends * There is no early exit option * Unstake is full-position only Rewards accumulate in real time as the same stToken in the Staking Wallet. *** ## 6. Processing Logic and Risk Controls Withdrawals are governed by deterministic execution controls and state-machine risk management. This design supports: * orderly capital movement without forced routing errors * deterministic accounting between Funding Wallet and Staking Wallet * structural alpha capture with constrained execution states * platform stability under changing market conditions BASIS execution infrastructure is built around: * sub-50μs latency * 100K+ OPS routing capacity * proprietary routing infrastructure * mathematically constrained execution paths These controls support execution precision and predictable settlement behavior. *** ## 7. Withdrawal Protection Withdrawal Protection is enabled automatically when you create a BASIS account. No additional setup is required. ### How It Works When you submit a withdrawal request, BASIS adds an email verification step to confirm your identity before processing the transaction. ### Final Submission of a Withdrawal Request {% stepper %} {% step %} **Click Withdraw** Complete the withdrawal form and click the **Withdraw** button. {% endstep %} {% step %} **Enter the verification code** A 6-digit verification code modal appears on screen. BASIS sends the code to the email address registered to your account. {% endstep %} {% step %} **Confirm the withdrawal** Enter the 6-digit code in the modal. The withdrawal is processed normally once the correct code is entered. {% endstep %} {% endstepper %} {% hint style="info" %} The verification code is valid for a single use only. If you do not receive it within a few minutes, check your spam folder or request a new code. {% endhint %} ### Managing Withdrawal Protection If you make frequent withdrawals, you may disable Withdrawal Protection to streamline your workflow. {% hint style="warning" %} If you disable Withdrawal Protection, follow these precautions: * **Always click the logout button** before closing your browser. Do not close the tab without logging out first. * Use a private, secure device. Avoid accessing BASIS on shared or public computers. * Enable 2FA on your registered email account to protect the credentials linked to your BASIS account. Disabling Withdrawal Protection removes the secondary email verification step. You are responsible for the security of your account if you choose to disable it. {% endhint %} *** ## 8. Important Notes * Withdrawal requests are processed according to internal risk and settlement checks * Always verify the destination address before confirming * Blockchain transactions are irreversible * BTC withdrawals use the BASIS account address model * ETH, SOL, and PAXG flows require a connected Web3 wallet * Minimum withdrawal amounts: BTC 0.0002 | ETH 0.004 | PAXG 0.002 | SOL 0.1 * Dashboard navigation: Stake | Assets | Referral | Support | Account {% hint style="success" %} For withdrawal issues, contact . {% endhint %} # Withdrawal Protection {% 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)). {% endhint %} ## Overview Withdrawal Protection adds an email verification step to secure withdrawal-related actions on your BASIS account. When enabled, a 6-digit verification code sent to your registered email address is required to complete the following actions: * Enabling Withdrawal Protection * Disabling Withdrawal Protection * Confirming a withdrawal request The verification code is valid for 10 minutes. Protected actions are only completed after successful email verification. Withdrawal Protection is strongly recommended for every account with withdrawal privileges. {% hint style="warning" %} Withdrawal Protection materially improves resistance to unauthorized withdrawals, but its effectiveness depends on the security of the registered email account. If the mailbox is compromised, the protection boundary is weakened. {% endhint %} ## Feature Definition Withdrawal Protection applies a 6-digit email verification requirement to the following actions: | Protected Action | Control Applied | Outcome | | ---------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- | | Enable Withdrawal Protection | A 6-digit verification code is sent to the registered email address | The feature is enabled only after successful code verification | | Disable Withdrawal Protection | A 6-digit verification code is sent to the registered email address | The feature remains enabled until successful code verification | | Initiation of a withdrawal request | A 6-digit verification code is sent to the registered email address at the very first step of the withdrawal flow, before any withdrawal details are confirmed | The withdrawal process can only proceed after successful code verification at the first step | **Key control behavior** * The protected action is not completed at the moment the user clicks the initial confirmation button * BASIS holds the action in a pending verification state until a valid code is entered * If verification fails, expires, or is abandoned, the protected action is not completed ## Activation Policy To enable Withdrawal Protection, BASIS follows the process below: 1. The user navigates to **Security Settings** within the BASIS account. 2. The user selects the option to enable **Withdrawal Protection**. 3. BASIS generates and sends a 6-digit verification code to the account's registered email address. 4. The current feature state remains unchanged while verification is pending. 5. The user retrieves the code from the registered email account and enters it into the BASIS verification interface. 6. BASIS validates the code for correctness and validity period. 7. If the code is valid, Withdrawal Protection is activated and the status is updated to **Enabled**. 8. If the code is invalid or expired, activation does not complete and the feature remains in its prior state. 9. If needed, the user must request a new code and repeat the verification step. ## Deactivation Policy To disable Withdrawal Protection, BASIS follows the process below: 1. The user navigates to **Security Settings** within the BASIS account. 2. The user selects the option to disable **Withdrawal Protection**. 3. BASIS generates and sends a 6-digit verification code to the account's registered email address. 4. The current feature state remains unchanged while verification is pending. 5. The user retrieves the code from the registered email account and enters it into the BASIS verification interface. 6. BASIS validates the code for correctness and validity period. 7. If the code is valid, Withdrawal Protection is deactivated and the status is updated to **Disabled**. 8. If the code is invalid or expired, deactivation does not complete and the feature remains in its prior state. 9. If needed, the user must request a new code and repeat the verification step. ## Withdrawal Authentication Flow When Withdrawal Protection is enabled, email verification is required before withdrawal details can be submitted. The verification step appears immediately when the user initiates a withdrawal. 1. The user selects **Withdraw** for the relevant asset. 2. BASIS immediately presents a **Verification Required** modal before any withdrawal details are entered. 3. BASIS sends a 6-digit verification code to the registered email address associated with the account. 4. The user retrieves the code from their registered email and enters it into the verification prompt. 5. The user clicks **Verify & Continue**. 6. BASIS validates the code for correctness and validity period. 7. If the code is valid, the user proceeds to the withdrawal detail entry screen. 8. For non-BTC assets (ETH, SOL, PAXG), the user connects a Web3 wallet to provide the destination address and complete the withdrawal. 9. For BTC, no wallet connection is required. The user enters the destination address directly and submits the withdrawal. 10. If the code is invalid or expired, the withdrawal flow does not proceed. 11. If the code expires, the user must request a new code and repeat the verification step. {% hint style="info" %} The email verification modal appears before withdrawal details are entered. For non-BTC assets, wallet connection occurs after successful verification, not before. {% endhint %} ## Verification Code Specifications | Parameter | Specification | Control Note | | --------------------------- | --------------------------------------------------- | ----------------------------------------------------------------------------- | | Code format | 6 digits | Numeric only | | Delivery channel | Registered email address | Sent only after a protected action is initiated | | Validity period | 10 minutes from issuance | Expired codes cannot authorize the action | | Reissue requirement | New code required after expiry | The prior code cannot be reused after expiration | | Maximum attempts | 3 attempts per code | The code is invalidated after 3 failed attempts; a new code must be requested | | Protected actions | Activation, deactivation, and withdrawal initiation | Applies only to supported protected workflows | | Confidentiality requirement | Must not be shared with any third party | Treat the code as a confidential authorization factor | ## How Withdrawal Protection Defends You Withdrawal Protection is designed to reduce the probability that a single point of failure can lead to unauthorized asset movement. It is particularly effective against common account takeover and operational abuse scenarios. ### Session hijacking If an attacker obtains access to an active BASIS session through a stolen browser cookie, compromised workstation, or unattended terminal, the attacker may appear authenticated within the platform. Withdrawal Protection adds a separate verification requirement through the registered email account before withdrawal submission or feature state changes can be completed. This reduces the likelihood that session access alone is sufficient to authorize asset movement. ### Phishing In phishing scenarios, a user may be tricked into disclosing account credentials or interacting with a fraudulent login page. Even if credentials are exposed, Withdrawal Protection creates an additional barrier by requiring access to the registered email account to complete the protected action. This does not eliminate phishing risk, but it narrows the attacker's path to successful withdrawal execution. ### Credential theft Credentials can be compromised through password reuse, malware, endpoint compromise, or exposure in third-party breaches. Withdrawal Protection helps contain the impact of stolen credentials by introducing a second approval step that is separate from the login secret used to access the BASIS account. ### Unauthorized access Unauthorized access can arise from shared devices, weak operational controls, or misuse of delegated account access. Withdrawal Protection requires explicit verification through the registered email account before high-risk actions are completed, which helps reduce the risk of accidental or malicious withdrawal submission by an unauthorized party. {% hint style="warning" %} Withdrawal Protection is a compensating control, not a substitute for secure email operations, endpoint hardening, credential hygiene, and internal approval processes. Institutions should treat the registered email account as part of the custody control perimeter. {% endhint %} ## Security Best Practices ### Secure the registered email account * Use a unique, high-entropy password for the registered email account * Store credentials in an approved password manager rather than in browsers or unsecured notes * Enable multi-factor authentication on the email account, preferably with phishing-resistant methods where available * Review mailbox forwarding rules, recovery addresses, delegated access, and sign-in history on a regular basis * Remove obsolete recovery methods and revoke access for former personnel or unused devices * For institutional deployments, use a controlled corporate mailbox with clear ownership, access logging, and monitored security alerts ### Secure access to BASIS * Enable all available BASIS security controls that are applicable to your account model * Access BASIS only from trusted devices that are patched, encrypted, and protected by endpoint security controls * Avoid shared browsers, unmanaged devices, and public networks for withdrawal-related activity * Verify that you are using the correct BASIS domain before signing in or entering verification codes * Maintain strict internal approval procedures for wallet changes and withdrawal execution ### Verify every withdrawal deliberately * Review the destination address, network, asset, amount, and beneficiary context before entering a verification code * Confirm that the withdrawal matches internal authorization records and treasury instructions * Do not rely on email links alone to access the platform. Prefer direct navigation through a trusted bookmark or approved internal access path ### If you receive an unexpected verification code * Do not share the code * Do not enter the code anywhere unless you personally initiated the protected action * Log in to BASIS through a trusted path and review recent account activity * Review the security of the registered email account immediately * Change account credentials and rotate email credentials if compromise is suspected * Escalate the event through your internal security process and contact BASIS support if unauthorized activity is suspected {% hint style="danger" %} An unexpected withdrawal verification email should be treated as a potential security event. If you did not initiate the action, assume that account credentials, an authenticated session, or the registered email account may have been targeted until proven otherwise. {% endhint %} ## User Responsibilities Users are responsible for the secure operation of Withdrawal Protection and for protecting the channels on which it depends. 1. You must maintain secure and exclusive control over the registered email account. 2. You must not disclose verification codes to any third party under any circumstance. 3. You must verify the legitimacy of each protected action before entering a code. 4. You must investigate unexpected verification emails immediately. 5. You must keep the registered email address current, accessible, and protected by appropriate security controls. 6. You must ensure that personnel with withdrawal authority understand that a verification code is an authorization factor and must be handled as confidential security data. 7. You must follow your internal incident response process if you suspect phishing, credential compromise, mailbox compromise, or unauthorized access. {% hint style="warning" %} Successful entry of a valid verification code is treated as authorization for the pending protected action. Failure to secure the registered email account can materially reduce the effectiveness of this control. {% endhint %} ## UI Reference | Feature Name | Description | Status Values | | --------------------- | -------------------------------------------------------------------------------------------------------------------- | ----------------- | | Withdrawal Protection | Applies email verification to enabling the feature, disabling the feature, and the initiation of withdrawal requests | Enabled, Disabled | **UI behavior note** * During activation or deactivation, the displayed status does not change until the verification code is successfully validated * During withdrawal initiation, the withdrawal flow cannot proceed until the verification step is completed successfully # Fees & Price Impact {% 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)). {% endhint %} In structural alpha systems, fees are part of the core cost model. They directly affect realized performance, execution precision, and strategy eligibility. BASIS presents the fee surface clearly so users can evaluate: * net yield after costs * whether a strategy remains valid under current market conditions * why deterministic risk controls may pause or reject execution ## 1) Platform-level fees | Action | Fee | | ---------- | ----- | | Deposit | 0% | | Swap | 0.01% | | Withdrawal | 0.05% | {% hint style="warning" %} Swaps on BASIS are same-token only and executed 1:1 between native assets and their staking representations: * BTC ↔ stBTC * ETH ↔ stETH * SOL ↔ stSOL * PAXG ↔ stPAXG Cross-asset conversion is not supported. {% endhint %} ## 2) What “price impact” means here Price impact is the difference between: * the expected execution level at the time an instruction is evaluated * the realized average fill level after routing and execution Price impact depends on: * available depth and liquidity quality * market volatility * routing path quality * execution latency BASIS treats price impact as a risk variable within its deterministic execution framework. When projected cost overwhelms expected edge, the system can refuse execution. This is part of how BASIS maintains execution precision and protects structural alpha capture. ## 3) Network fees are separate On-chain transfers still require network fees at the protocol level: * Bitcoin network fees for BTC transfers * Ethereum gas fees for ETH and PAXG transfers * Solana network fees for SOL transfers These fees are paid to the underlying networks, not to BASIS. ## 4) Why fees matter in market-neutral systems Even when exposure is controlled and directional risk is reduced, cost drag still compounds: * frequent rebalancing increases cumulative execution cost * collateral movement can introduce additional transfer overhead * cross-venue settlement can reduce realized spread capture * poor routing quality can erode edge through price impact This is why BASIS emphasizes: * deterministic execution logic * strict eligibility thresholds * state machine risk controls * proprietary routing infrastructure * high-throughput market connectivity via BHLE {% hint style="success" %} BASIS execution infrastructure is designed around deterministic behavior, mathematical constraints, and infrastructure-level precision, including sub-50μs latency targets and 100K+ OPS routing capacity under BHLE architecture. {% endhint %} ## 5) User-facing implications Before initiating activity, users should understand: * deposits are made in native assets only: BTC, ETH, SOL, or PAXG * BTC deposits use a BASIS-assigned address unique to the account * ETH, SOL, and PAXG deposits require a connected Web3 wallet * rewards accumulate in real time as the same stToken inside the Staking Wallet * unstaking returns the full claimable stToken amount to the Staking Wallet * unstake is full-position only and becomes available after any fixed lock-up period ends ## Related references * Fees & Limits * Deposits & Withdrawals * Swaps * Risk Disclosure * Arbitrage Economics: Edge vs Cost # Minimum Staking & Reward Claim Policy Minimum staking amounts and reward claim thresholds for BASIS staking products on BASIS. ## Overview BASIS applies minimum staking and minimum reward claim thresholds to maintain economic efficiency, operational consistency, and execution quality across supported assets. These thresholds are designed to ensure that positions are large enough to generate meaningful rewards, absorb network-related costs, and remain compatible with internal liquidity and risk controls. All thresholds listed on this page are denominated in the native unit of the relevant asset. Minimums may be reviewed and updated periodically to reflect changes in market structure, network fees, settlement conditions, and internal execution requirements. ## Minimum Staking | Asset | Minimum Stake | | ------ | ------------: | | stBTC | 0.0002 BTC | | stETH | 0.004 ETH | | stSOL | 0.1 SOL | | stPAXG | 0.002 PAXG | ## Why the stBTC Minimum Is Higher BTC has a materially higher unit price than ETH, SOL, or PAXG, which means very small BTC positions can accrue rewards that are technically valid but economically immaterial over standard accrual periods. A higher minimum staking threshold helps ensure that expected yield remains meaningful relative to position size, reporting precision, and ordinary user claim behavior. This prevents ultra-small BTC stakes from creating dust-like balances that consume system resources while delivering limited practical value to the account holder. Bitcoin also presents slower settlement characteristics and more variable on-chain fee conditions than the networks commonly associated with the other supported staking assets. Deposits, rebalancing activity, and redemption support for BTC therefore require a larger operational buffer to preserve reliability and maintain net efficiency. By enforcing a higher minimum, BASIS reduces the likelihood that confirmation delays, fee spikes, or reserve adjustments will disproportionately affect small BTC positions. In addition, the BASIS BHLE arbitrage engine relies on a minimum level of executable BTC depth to preserve its internal latency and liquidity profile. BTC allocations below the configured threshold contribute insufficient usable inventory once routing logic, risk filters, and market impact controls are applied. The stBTC minimum is therefore aligned with the depth required for the BHLE arbitrage engine to maintain sub-50 microsecond execution performance without introducing slippage through fragmented or undersized BTC legs. ## Minimum Reward Claim | Asset | Minimum Reward Claim | | ------ | -------------------: | | stBTC | 0.00001 BTC | | stETH | 0.003 ETH | | stSOL | 0.004 SOL | | stPAXG | 0.0001 PAXG | ## Minimum Withdrawal | Asset | Minimum Withdrawal | | ------ | -----------------: | | stBTC | 0.0002 BTC | | stETH | 0.004 ETH | | stSOL | 0.1 SOL | | stPAXG | 0.002 PAXG | ## Claim vs Withdraw It is important to distinguish between a **claim** and a **withdrawal**: * **Claim** means moving accrued staking rewards into your **internal BASIS balance**. * **Withdraw** means transferring assets from BASIS to an **external wallet address**. A reward claim is an internal platform action and is subject to the **minimum reward claim thresholds** listed above. A withdrawal is a separate action and may be subject to additional rules, including withdrawal minimums, network fees, compliance checks, destination address validation, and asset-specific processing windows. > A successful reward claim does **not** automatically trigger a withdrawal to an external wallet. ## Important Notes * Minimum staking thresholds apply at the time a staking position is created or topped up. * Minimum reward claim thresholds apply per claim request. * Rewards below the claim threshold will generally remain accrued until the minimum claim amount is reached. * Claiming rewards does **not** unstake or redeem your principal position. * Withdrawal rules are separate from claim rules and may vary by asset, network, and account type. * BASIS may update thresholds from time to time in response to market, network, or operational conditions. * Additional account-level controls may apply for institutional or restricted accounts. ## Support If you require assistance with staking minimums, reward claims, or withdrawal conditions, please contact **BASIS Support** through the official support channel available in the BASIS platform or through your designated account representative. When contacting support, please include: * Your account identifier * The relevant asset * The staking or claim amount * The transaction or request reference * The approximate submission time Providing complete details will help BASIS Support review and resolve your request more efficiently. # Fee Calculator & Worked Examples {% 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 %} This page breaks down fees and boosters with worked examples so you can sanity-check expected outcomes. *** ## Fee Summary | Fee Type | Rate | When Applied | | ----------------------- | ----------------: | ------------------------------------------------------------------------ | | Deposit Fee | 0% | Never | | Swap Fee | 0.01% | Same-token conversion only: BTC→stBTC, ETH→stETH, SOL→stSOL, PAXG→stPAXG | | Withdrawal Fee | 0.05% | On native-asset withdrawal | | Management Fee | 0% | Never | | Performance Fee | 20% of net profit | Deducted before reward distribution to staking positions | | Early Unstaking Penalty | Not applicable | Fixed pools can only be unstaked after lock-up ends | {% hint style="success" %} Swap functionality is strictly 1:1 on a same-token basis. BASIS does not support cross-asset swaps such as BTC→ETH or ETH→SOL. {% endhint %} {% hint style="info" %} Yield rates used in examples are illustrative only. Actual DRR varies with market conditions. Check the dashboard for current rates. {% endhint %} *** ## Lock-up Booster Multipliers | Pool Type | Lock-up Duration | Booster | | --------- | ---------------: | ---------: | | Fixed | 14 days | +10% | | Fixed | 30 days | +20% | | Fixed | 90 days | +50% | | Fixed | 180 days | +100% (2×) | {% hint style="warning" %} Fixed pools do not support early exit. Unstaking is only available after the lock-up period ends. {% endhint %} *** ## Worked Example 1: Staking 1 BTC (30 Days, No Booster) ### Assumptions * BTC price at deposit: $80,000 equivalent * Illustrative base yield rate: 0.05% per day * Hold period: 30 days * Deposit amount: 1 BTC * Minimum BTC deposit: 0.0001 BTC ### Flow {% stepper %} {% step %} Deposit 1 BTC into your Funding Wallet using your BASIS-assigned BTC deposit address. {% endstep %} {% step %} Swap BTC to stBTC at 1:1 quantity. A 0.01% swap fee applies. {% endstep %} {% step %} Stake stBTC. Rewards accumulate in real time as stBTC in your Staking Wallet. {% endstep %} {% step %} At unstake, the full staked position is auto-selected as MAX. Partial unstake is not supported. {% endstep %} {% endstepper %} | Step | Calculation | Amount | | ---------------- | -------------------------- | ---------: | | Deposit fee | 0% | $0.00 | | Swap fee | $80,000 × 0.01% | $8.00 | | Daily base yield | $80,000 × 0.05% | $40.00/day | | 30-day yield | $40.00 × 30 | $1,200.00 | | Withdrawal fee | ($80,000 + $1,200) × 0.05% | $40.60 | ### Result * Gross value before withdrawal fee: \~$81,200.00 equivalent * Net value after withdrawal fee: \~$81,159.40 equivalent > Quantity note: the swap remains 1:1 at the token level. Fiat-equivalent value at withdrawal depends on the BTC market price at that time. *** ## Worked Example 2: Staking 1 BTC (90-Day Fixed Pool, +50% Booster) ### Assumptions * Same starting BTC value: $80,000 equivalent * Same illustrative base yield rate: 0.05% per day * Lock-up period: 90 days * Booster: +50% | Step | Calculation | Amount | | ------------------- | -------------------------- | ---------: | | Swap fee | $80,000 × 0.01% | $8.00 | | Boosted daily yield | $40.00 × 1.5 | $60.00/day | | 90-day yield | $60.00 × 90 | $5,400.00 | | Withdrawal fee | ($80,000 + $5,400) × 0.05% | $42.70 | ### Result * Gross value before withdrawal fee: \~$85,400.00 equivalent * Net value after withdrawal fee: \~$85,357.30 equivalent ### Comparison | Pool | Duration | Net Yield | | ------------ | -------: | ----------: | | No booster | 90 days | \~$3,600.00 | | 90-day fixed | 90 days | \~$5,400.00 | Yield advantage from the 90-day booster: \~$1,800.00 equivalent *** ## Worked Example 3: ETH Staking with Referral Rewards ### Assumptions * You stake 20 ETH * ETH price at deposit: $3,500 equivalent * Total value: $70,000 equivalent * Base yield rate: 0.04% per day * You have a referred user who generates a reward event equivalent to $200 ### Your own staking yield over 30 days | Calculation | Amount | | ------------ | --------------: | | Daily yield | $70,000 × 0.04% | | 30-day yield | $28.00 × 30 | ### Contribution-aligned referral network example | Calculation | Amount | | ---------------------------- | ------: | | Downstream reward event | $200.00 | | Example referral reward rate | 15% | | Your referral reward | $30.00 | {% hint style="info" %} Referral network rewards are governed by the contribution-based reward system and credited according to the applicable referral structure. See the referral documentation for current calculation logic. {% endhint %} *** ## Worked Example 4: Fixed Pool Unstake After Lock-up For fixed pools, unstaking becomes available only after the lock-up period ends. ### Example: 90-day fixed BTC position * Deposit: 1 BTC * Booster: +50% * Lock-up: 90 days At day 90: * Your full staked position is available for unstake * The unstake action is auto-MAX for the full position * Claimable rewards are automatically credited to your Staking Wallet as stBTC * You may then withdraw native BTC from your Funding Wallet after the required conversion flow {% hint style="warning" %} There is no early exit option for fixed pools. If you need immediate liquidity, use an unstaked balance in your Funding Wallet rather than a locked fixed pool position. {% endhint %} *** ## Network Processing Expectations | Asset | Typical Withdrawal Time | | ----- | ----------------------- | | BTC | 10 to 60 minutes | | ETH | 1 to 10 minutes | | SOL | 1 to 10 minutes | | PAXG | 1 to 10 minutes | Network fees are separate from BASIS fees and are determined by the underlying chain environment and wallet conditions. *** ## Wallet Model Reference | Wallet | Holds | Primary Actions | | -------------- | ------------------------------------- | ------------------------------- | | Funding Wallet | Native assets: BTC, ETH, SOL, PAXG | Deposit, withdraw | | Staking Wallet | stTokens: stBTC, stETH, stSOL, stPAXG | Stake, receive rewards, unstake | {% tabs %} {% tab title="BTC deposits" %} 1. Open Assets or Funding Wallet. 2. Copy your BASIS-assigned BTC deposit address. 3. Send BTC from your external wallet or exchange. 4. Once credited, swap BTC→stBTC if you want to stake. No Web3 wallet connection is required for BTC deposits. {% endtab %} {% tab title="ETH / SOL / PAXG deposits" %} 1. Open Assets or Funding Wallet. 2. Connect a supported Web3 wallet such as MetaMask. 3. Select ETH, SOL, or PAXG. 4. Approve and complete the deposit transaction. 5. Once credited, swap to the matching stToken if you want to stake. Supported swap pairs are ETH→stETH, SOL→stSOL, and PAXG→stPAXG only. {% endtab %} {% endtabs %} *** ## Operational Notes {% hint style="info" %} BASIS infrastructure is designed for deterministic execution under strict state-machine controls, with math-constrained risk handling and proprietary routing optimized for execution precision. Research support is provided by Base58 Labs, a research partner focused on structural alpha capture and systems design. {% endhint %} {% hint style="info" %} BHLE architecture targets sub-50μs latency and 100K+ OPS through proprietary routing infrastructure, supporting predictable transaction handling and high-throughput internal accounting. {% endhint %} *** See also: * [Fees & Limits Reference](/reference/fees-and-limits) * [Lock-up Economics](/economics-and-rewards/lock-up-economics) * [Booster System](/economics-and-rewards/booster-system) # Dashboard Guide {% 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)). {% endhint %} Treat the dashboard as the platform source of truth. ## 1) Main navigation BASIS organizes the UI into five sections: | Section | Path | Purpose | | -------- | ----------- | ---------------------------------------------------------------- | | Stake | `/Stake` | Staking positions, live scanner, reward feed | | Assets | `/Assets` | Funding Wallet, Staking Wallet, deposit, withdraw, swap | | Referral | `/Referral` | Contribution-aligned referral network status and reward tracking | | Support | `/Support` | Help requests, operational assistance, guidance | | Account | `/Account` | Email identity, session management, logout | {% hint style="info" %} Wallet model: * Funding Wallet holds native tokens: BTC, ETH, SOL, PAXG * Staking Wallet holds staking tokens: stBTC, stETH, stSOL, stPAXG {% endhint %} *** ## 2) Reading the Staking Dashboard Each asset card shows: | Field | Meaning | | ------------------ | ----------------------------------------------------------------------------------------- | | Asset name + price | Current spot reference price in USDT | | Wgt. X% | Deployment weight, the share of total capital allocated to that asset’s active strategies | | $ value | USDT-equivalent of your staked position | | ACTIVE / INACTIVE | Whether the strategy module for this asset is currently running | | stXXX balance | Your staking token balance, for example `0.50000000 stBTC` | | 24h % | Price change of the underlying asset over 24 hours | Current live asset status example: | Asset | Status | Wgt. | DRR | | ----- | ------ | ---- | ----- | | BTC | ACTIVE | 24% | 0.40% | | ETH | ACTIVE | 76% | 0.38% | | PAXG | ACTIVE | 0% | 0.42% | | SOL | ACTIVE | 0% | 0.36% | > Asset status and weights change as strategies are enabled, audited, and scaled. Always rely on the live dashboard. *** ## 3) DRR: Daily Reward Rate DRR is the estimated daily yield rate on deployed capital, expressed as a percentage. {% hint style="info" %} $$ \text{Daily Reward} \approx \text{Staked Value} \times \text{DRR} $$ Example: `$34,798` staked at `DRR 0.40%` → `~$139/day` estimated reward DRR reflects recent strategy performance and execution conditions. It is not guaranteed. {% endhint %} DRR is shown on each asset card and inside the staking interface. *** ## 4) Staking Interface The staking interface is embedded directly in the dashboard. You do not need to navigate to a separate page to stake or unstake. Tabs: `stBTC` | `stETH` | `stPAXG` | `stSOL` For each asset you can see: * Total Balance and current stToken quantity * Currently Staked amount * Total Rewards Claimed, cumulative in stToken units * Reward Booster, shown as a percentage increase over base rate * Est. Daily Rate, aligned with the asset DRR * Lock-up selector: `14D / 30D / 90D / 180D` {% hint style="warning" %} Fixed pools can only be unstaked after the selected lock-up period ends and are subject to a mandatory 7-day unstaking buffer before the claimable amount is credited. Early exit is not available. {% endhint %} {% hint style="info" %} Rewards accumulate in real time as the same stToken and are credited to the Staking Wallet after the mandatory 7-day unstaking buffer following unstake. Unstake is processed as full-position only. The interface auto-selects the maximum available staked balance for the chosen asset. {% endhint %} *** ## 5) Reward Booster The UI displays boosters as percentage additions to the base DRR: | Lock-up | UI display | Multiplier equivalent | | -------- | ---------- | --------------------- | | Flexible | +0% | 1.0x base | | 14 days | +10% | 1.1x | | 30 days | +20% | 1.2x | | 90 days | +50% | 1.5x | | 180 days | +100% | 2.0x | *** ## 6) Live Reward Feed A real-time stream below the asset cards shows profit events as they are realized by the strategy engine. When strategies are running normally, entries appear continuously. When the system is in a non-executing or protected state, the feed displays `Waiting for profits...` This feed is informational only and does not represent your individual accruals. *** ## 7) Total Rewards Generated The dashboard shows cumulative rewards across all supported assets: * Total Rewards Generated, shown as a USD-equivalent summary * Per-asset breakdown in stToken units: `stBTC / stETH / stPAXG / stSOL` *** ## 8) DB Sync indicator A DB Sync status label appears next to the reward summary. It confirms that platform records and settlement records are synchronized. {% hint style="warning" %} If DB Sync shows a warning state, wait for synchronization before making staking or withdrawal decisions. {% endhint %} *** ## 9) Live Structural Alpha Scanner The bottom section of the dashboard shows a live view of the BHLE scanner’s opportunity feed. | Column | Meaning | | -------------- | ------------------------------------------------------- | | Market Pair | Asset and reference pair, for example `BTC/USDT` | | Sourcing Venue | Venue where the lower price is detected | | Target Venue | Venue where the higher price is detected | | Spread % | Price difference between venues | | Est. Profit | Estimated USD-equivalent profit per standard trade size | | Action | Current engine state: Scanning / Processing / Executing | {% hint style="warning" %} The scanner is a live view of opportunity detection, not a guarantee of execution. BHLE applies expected-value checks, slippage controls, and state-machine risk controls before any order is routed. {% endhint %} {% hint style="info" %} BHLE infrastructure highlights: * Sub-50μs latency * 100K+ OPS throughput * Proprietary routing infrastructure * Deterministic execution controls * Mathematical constraint enforcement {% endhint %} *** ## 10) What to check daily | Check | Where | | ------------------------------------- | ---------------------- | | System state | Top bar | | DRR and asset ACTIVE status | Asset cards | | Staked balances and booster selection | Staking Interface | | DB Sync status | Reward summary section | | Scanner activity | Bottom of dashboard | *** ## 11) Related operational notes {% tabs %} {% tab title="Deposits" %} **BTC** 1. Go to Assets. 2. Open the BTC deposit panel. 3. Copy your BASIS-assigned BTC deposit address. 4. Send at least `0.0001 BTC`. No Web3 wallet connection is required for BTC deposits. **ETH / SOL / PAXG** 1. Go to Assets. 2. Select ETH, SOL, or PAXG. 3. Connect a supported Web3 wallet, such as MetaMask. 4. Confirm the native token deposit. Supported funding assets are BTC, ETH, SOL, and PAXG only. {% endtab %} {% tab title="Swap" %} Swaps are same-token only and executed at 1:1: * `BTC → stBTC` * `ETH → stETH` * `SOL → stSOL` * `PAXG → stPAXG` Swap fee: `0.01%` {% endtab %} {% tab title="Withdrawals" %} Withdrawals are made from the Funding Wallet in native tokens. | Asset | Typical withdrawal time | | ----- | ----------------------- | | BTC | 10 to 60 minutes | | ETH | 1 to 10 minutes | | SOL | 1 to 10 minutes | | PAXG | 1 to 10 minutes | Note: Unstaking from fixed pools requires an additional 7-day buffer before these withdrawal times apply. Withdrawal fee: `0.05%` Deposit fee: `0%` {% endtab %} {% endtabs %} See also: [Wallet Model](/getting-started/wallet-model) | [Staking Pools](/economics-and-rewards/staking-pools) | [Risk Disclosure](/risk-safety-and-asset-protection/risk-disclosure) # Executive Summary {% 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 %} {% hint style="success" %} Research Partner: Base58 Labs Execution infrastructure: BHLE is designed for sub-50μs latency, 100K+ OPS, and proprietary routing infrastructure. The operating objective is deterministic execution, math-constrained decisioning, and state machine risk control. International certification: BASIS DIGITAL INFRASTRUCTURE LTD holds active ISO/IEC 27001:2022 certification, Certificate Number SC62455E, last updated March 27, 2026, and active ISO/IEC 20000-1:2018 certification. Both certifications are publicly verifiable on IAF CertSearch. {% endhint %} BASIS is not a passive yield wrapper. It is an intelligent yield infrastructure that converts market structure inefficiencies into user-accessible, risk-aware yield through execution precision and structural alpha capture. The platform follows a research principle from Base58 Labs: > "Alpha is found in the residuals." > > Durable edge remains after obvious, crowded, and non-verifiable signals are removed. ## 1. The problem we solve Crypto markets contain real inefficiencies, but individuals rarely capture them safely and consistently because: * execution windows are short and unforgiving * fees and slippage can erase theoretical edge * exchanges can halt withdrawals or fail operationally * on-chain congestion can degrade execution precision * fragmented liquidity makes consistent settlement difficult The result is simple: arbitrage is widely discussed, but rarely operationalized with institutional discipline. ## 2. The BASIS approach BASIS treats yield generation as an engineering and risk-control problem. ### Core operating principles * Market neutral\ Focus on price gaps, basis dislocations, and structural differentials rather than directional bets. * Execution first\ Execution quality is the primary variable. Prediction is secondary. * Capital preservation\ System design prioritizes survivability, explicit stop conditions, and controlled exposure. These principles are encoded into: * the strategy matrix * the routing layer * the risk engine * liquidity buffers * venue fragmentation policy * state machine safeguards BASIS is designed as institutional-grade operating infrastructure. Its control philosophy aligns execution discipline, service reliability, and documented operational governance with active ISO/IEC 27001:2022 and ISO/IEC 20000-1:2018 certifications held by BASIS DIGITAL INFRASTRUCTURE LTD. ## 3. Core components ### BQAE, Spatial Arbitrage Core The BASIS Deterministic Arbitrage Engine captures cross-venue price inefficiencies through a controlled execution cycle. {% stepper %} {% step %} **Step 1. Global market scanning** High-frequency, multi-source pricing is collected across fragmented venues. {% endstep %} {% step %} **Step 2. Institutional filtering** Liquidity, order book depth, venue health, and execution feasibility are screened before action. {% endstep %} {% step %} **Step 3. Atomic execution** Synchronized buy and sell actions reduce open exposure time and improve execution precision. {% endstep %} {% step %} **Step 4. Auto settlement** Positions are closed on convergence. Only realized edge is retained. {% endstep %} {% endstepper %} ### BOVE, Multi-Strategy Coordination The BASIS Omni-Vector Engine coordinates multiple revenue pipelines so the system does not depend on one strategy class. Current strategy families include: * spatial arbitrage * delta-neutral funding streams * early-stage structural alpha capture * blue-chip DeFi and liquid staking optimization strategies are conducted exclusively within the scope of the four officially supported assets: BTC, ETH, SOL, and PAXG This diversification is a structural hedge against regime change. ### BIVB, 1:1 Quantity Peg and Principal Accounting The BASIS Iso-Value Bridge enables same-token 1:1 principal accounting. | Native asset | Staking asset | Swap rule | Deposit method | | ------------ | ------------- | -------------------------------------- | ------------------------------------ | | BTC | stBTC | BTC ↔ stBTC only, 1:1 quantity basis | Copy your BASIS-assigned BTC address | | ETH | stETH | ETH ↔ stETH only, 1:1 quantity basis | Connect a Web3 wallet | | SOL | stSOL | SOL ↔ stSOL only, 1:1 quantity basis | Connect a Web3 wallet | | PAXG | stPAXG | PAXG ↔ stPAXG only, 1:1 quantity basis | Connect a Web3 wallet | {% hint style="warning" %} USDT is used for internal accounting and dashboard display only. It cannot be deposited or withdrawn. {% endhint %} This model preserves principal in quantity terms, while fiat-equivalent value can still fluctuate with market price. ## 4. User operating model ⚙️ {% tabs %} {% tab title="Funding Wallet" %} The Funding Wallet holds native assets for deposit and withdrawal. * Supported assets: BTC, ETH, SOL, PAXG * Deposit fee: 0% * Withdrawal fee: 0.05% * No minimum deposit * Typical withdrawal time for BTC: 10 to 60 minutes * Typical withdrawal time for ETH, SOL, and PAXG: 1 to 10 minutes {% endtab %} {% tab title="Staking Wallet" %} The Staking Wallet holds staking assets. * Supported assets: stBTC, stETH, stSOL, stPAXG * Rewards accumulate in real time as the same stToken * Claimable amounts are auto-credited to the Staking Wallet as stToken after unstake * Unstake is auto-MAX, full position only {% endtab %} {% endtabs %} ### Deposit flow {% tabs %} {% tab title="BTC" %} 1. Open Assets. 2. Select BTC. 3. Copy your BASIS-assigned BTC deposit address. 4. Send BTC from your external wallet or exchange. 5. Funds are credited to your Funding Wallet after confirmation. {% endtab %} {% tab title="ETH / SOL / PAXG" %} 1. Open Assets. 2. Select ETH, SOL, or PAXG. 3. Connect a supported Web3 wallet such as MetaMask. 4. Approve and confirm the native token deposit. 5. Funds are credited to your Funding Wallet after confirmation. {% endtab %} {% endtabs %} ### Staking and swap rules * Swaps are same-token only, 1:1 by quantity * BTC can only swap to stBTC * ETH can only swap to stETH * SOL can only swap to stSOL * PAXG can only swap to stPAXG * Swap fee: 0.01% | Asset | Staked Token | | ----- | ------------ | | BTC | stBTC | | ETH | stETH | | SOL | stSOL | | PAXG | stPAXG | ### Booster schedule | Lock period | Booster | | ----------- | ---------- | | 14D | +10% | | 30D | +20% | | 90D | +50% | | 180D | +100% (2×) | {% hint style="info" %} Fixed pools can be unstaked only after the lock-up period ends. No early exit option is available. {% endhint %} ### Dashboard structure {% hint style="info" %} **Platform Sections** * Stake * Assets * Referral * Support * Account {% endhint %} The Referral section uses a contribution-aligned referral network model. ## 5. Trust by design, the risk model BASIS treats risk as a state machine with explicit operating boundaries. | State | Purpose | System behavior | | ------ | ------------------------- | ---------------------------------------------------------------------------------------------------- | | Normal | Eligible trading state | Trade only when strategy and venue conditions meet system constraints | | BSCB | Protective response state | Trigger defensive actions when loss risk or instability is detected | | DMM | Deep protection state | Pause trading, unwind exposure, perform root cause analysis, resume only after stability is restored | This design accepts a deliberate trade-off: * fewer trades during stress * tighter control of execution quality * higher survivability across market regimes The trust model is grounded in: * deterministic execution * math-constrained decision paths * controlled settlement assumptions * liquidity-aware routing * venue diversification * explicit stop conditions * operational governance aligned with active ISO/IEC 27001:2022 and ISO/IEC 20000-1:2018 certifications * public certification records on IAF CertSearch for both standards and the certified entity This framing is important: trust on BASIS is not presented as marketing language. It is expressed through system behavior, operator controls, and externally verifiable certification status. ## 6. What users and investors should evaluate Users should interpret BASIS as a system that: * provides access to complex market-neutral strategy execution * maintains visible operational constraints * tracks principal on a 1:1 quantity basis for supported assets * separates native-asset custody flow from staking-asset reward flow * operates on infrastructure supported by active ISO/IEC 27001:2022 and ISO/IEC 20000-1:2018 certifications held by BASIS DIGITAL INFRASTRUCTURE LTD Investors should evaluate BASIS like a financial system: * Are system invariants clearly defined? * Are stop conditions explicit? * Is strategy exposure diversified? * Is withdrawal and settlement risk operationalized? * Does platform behavior match the documentation? * Are critical controls supported by publicly verifiable international certifications? BASIS is designed to answer those questions directly through infrastructure, controls, and verifiable operating rules. IAF CertSearch verification records: * ISO/IEC 27001:2022: Active, Certificate Number SC62455E, Last Updated March 27, 2026\ [Verify on IAF CertSearch](https://www.iafcertsearch.org/certification/VDrwBpB8mD2nw5ykj5zxSANH) * ISO/IEC 20000-1:2018: Active\ [Verify on IAF CertSearch](https://www.iafcertsearch.org/certification/1IbVSdVuBbykRHSgkfAo8mBE) * Certified entity record: BASIS DIGITAL INFRASTRUCTURE LTD\ [Entity Record on IAF CertSearch](https://www.iafcertsearch.org/certified-entity/WTmKlSOrxvhkPKrCUIdWYEgv) *** # Core Philosophy {% 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)). {% endhint %} BASIS is built around three non-negotiable constraints. Together they form a design constraint triangle. If one is optimized while the others are ignored, the result is not production-grade infrastructure. ## 1) Market neutral by construction BASIS does not rely on directional market calls. It targets structural alpha capture from: * cross-venue price dislocations * basis and funding differentials * liquidity fragmentation * inventory and routing inefficiencies Market neutrality lowers directional exposure, but it does not remove risk. It transforms directional risk into: * execution risk * funding risk * liquidation risk * venue and counterparty risk * settlement risk The platform treats this explicitly. Reliability comes from acknowledging these risks, measuring them, and constraining them before capital is deployed. This operating model is consistent with an institutional-grade control environment maintained under active ISO/IEC 27001:2022 and ISO/IEC 20000-1:2018 certified management systems. ## 2) Execution first In structural alpha strategies, theoretical edge is usually small and time-sensitive. Therefore: * a 20 bps spread is irrelevant if slippage consumes 30 bps * a positive funding profile is irrelevant if hedging fails during volatility * a DEX-CEX spread is irrelevant if gas costs and execution precision losses dominate Execution first means: * slippage, latency, and routing quality are part of the strategy itself * trades are conditioned on depth, venue health, and expected fill quality * the system is allowed to refuse trades when expected value is negative * deterministic execution rules are enforced before exposure is opened This philosophy is also reflected operationally. Consistent service delivery, controlled change processes, and security governance are essential when execution quality is part of the product itself. BASIS treats these as part of its institutional-grade operating baseline and maintains them under active, publicly verifiable ISO-certified management systems. ### BHLE execution layer BASIS uses BHLE, a proprietary routing and execution infrastructure designed for: * sub-50 μs decision latency * 100K+ OPS throughput * venue-aware path selection * low-variance execution across fragmented liquidity * deterministic routing under mathematical risk constraints The goal is not maximum activity. The goal is execution precision. ### Practical EV gate A simplified eligibility rule can be written as: $$ Edge \ge Fees + Slippage\_Bound + Latency\_Penalty + Safety\_Margin $$ If this condition does not hold under conservative assumptions, the strategy does not run. ``` if expected_edge < total_execution_cost + safety_margin: reject_trade() ``` ## 3) Capital preservation Capital preservation does not mean zero risk. It means the system is designed to remain inside defined risk states and degrade safely under stress. This includes: * conservative capital deployment * explicit stop conditions * controlled unwind procedures * liquidity buffers for withdrawals * state machine risk controls with deterministic transitions Capital preservation also depends on operational discipline outside the strategy layer. Security controls, incident handling, and service management processes matter because a resilient arbitrage platform must protect both capital and continuity under changing conditions. BASIS supports this with active ISO/IEC 27001:2022 and ISO/IEC 20000-1:2018 certifications held by BASIS DIGITAL INFRASTRUCTURE LTD. ### Protective states | Control | Function | | ------- | --------------------------------------------------------------------------------------------------------------------------------------- | | BSCB | Triggers when loss probability or structural instability is detected, including at very low thresholds | | DMM | Enters a protective pause state, reduces or closes exposure, analyzes conditions, and resumes only when stability criteria are restored | This is why rewards may slow or pause during stressed conditions. A platform that never pauses usually has not formalized failure modes. ## 4) How this philosophy appears in the product | Product area | Design expression | | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | | Strategy engine | Diversification across independent structural alpha sources | | Risk engine | Deterministic pre-trade checks, venue health gating, and state machine controls | | Wallet model | Funding Wallet holds native tokens for deposit and withdrawal. Staking Wallet holds stTokens for staking and reward accumulation | | Deposit model | BTC deposits use a BASIS-assigned address unique to each account. ETH, SOL, and PAXG deposits use a connected Web3 wallet such as MetaMask | | Swap model | Same-token 1:1 swaps only: BTC→stBTC, ETH→stETH, SOL→stSOL, PAXG→stPAXG | | Fee model | Deposit 0%, Withdrawal 0.05%, Swap 0.01% | | Reward model | Rewards accumulate in real time as the same stToken in the Staking Wallet | | Fixed pools | Unstake is available only after the lock-up period ends. Early exit is not supported | | Unstake behavior | Full-position unstake only. At maturity, the claimable amount is auto-credited to the Staking Wallet as the same stToken | | Booster design | 14D +10%, 30D +20%, 90D +50%, 180D +100% (2x) | | Referral | Contribution-aligned referral network tied to realized participation | | Operational assurance | Operated by BASIS DIGITAL INFRASTRUCTURE LTD under active, publicly verifiable ISO/IEC 27001:2022 and ISO/IEC 20000-1:2018 certified management systems | {% hint style="warning" %} 🛡️ Operational baseline: * BTC minimum deposit is 0.0001 BTC * BTC withdrawals usually complete in 10 to 60 minutes * ETH, SOL, and PAXG withdrawals usually complete in 1 to 10 minutes * USDT is used for internal display and accounting only * BASIS DIGITAL INFRASTRUCTURE LTD holds active certifications that support the platform's institutional-grade operating model: * ISO/IEC 27001:2022: Active. Last updated: March 27, 2026. [Public verification](https://www.iafcertsearch.org/certification/VDrwBpB8mD2nw5ykj5zxSANH) * ISO/IEC 20000-1:2018: Active. [Public verification](https://www.iafcertsearch.org/certification/1IbVSdVuBbykRHSgkfAo8mBE) * Certified entity record: [BASIS DIGITAL INFRASTRUCTURE LTD](https://www.iafcertsearch.org/certified-entity/WTmKlSOrxvhkPKrCUIdWYEgv) {% endhint %} ## 5) When principles conflict If execution opportunities expand while market stability deteriorates, BASIS prioritizes survivability over activity. {% stepper %} {% step %} **Evaluate expected value** Confirm that projected edge remains positive after fees, slippage bounds, latency penalties, and safety margins. {% endstep %} {% step %} **Validate system state** Confirm venue health, routing quality, liquidity conditions, and state-machine eligibility. {% endstep %} {% step %} **Commit or pause** If any constraint fails, reduce exposure or pause strategy activation. Resume only after deterministic criteria are restored. {% endstep %} {% endstepper %} {% tabs %} {% tab title="Design priority" %} * preserve capital first * capture structural alpha second * increase activity only when risk states allow it {% endtab %} {% tab title="User-visible outcome" %} * rewards can slow during stressed conditions * some strategy paths can be disabled temporarily * withdrawals remain buffered and prioritized within defined operating states * resumption occurs only after deterministic checks are passed * operational trust is reinforced by active, publicly verifiable ISO certifications under BASIS DIGITAL INFRASTRUCTURE LTD on IAF CertSearch {% endtab %} {% endtabs %} The remainder of the documentation translates these principles into architecture, wallet operations, staking mechanics, and control systems across Stake, Assets, Referral, Support, and Account within the same institutional-grade and internationally certified operating model. # System Overview {% 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 %} This section explains the BASIS architecture, wallet model, execution stack, and the capital path through the platform. ## 1) High-level architecture BASIS operates as three coordinated layers: 1. User & Accounting Layer * Funding Wallet for native assets only: BTC, ETH, SOL, PAXG * Staking Wallet for stTokens only: stBTC, stETH, stSOL, stPAXG * Same-token 1:1 swap rules between native assets and stTokens * Real-time reward accrual in the Staking Wallet as the same stToken 2. Execution Layer * BQAE for cross-venue structural alpha capture * Delta-neutral funding modules * On-chain modules with active BTC, ETH, SOL, and PAXG support * Deterministic routing and execution precision through BHLE 3. Risk & Operations Layer * Pre-trade eligibility constraints * State machine controls: Normal → BSCB → DMM * Venue health scoring, throttling, and blacklisting * Liquidity buffers, unwind protocols, and reconciliation checks * Operational governance aligned with BASIS DIGITAL INFRASTRUCTURE LTD's active ISO/IEC 27001:2022 and ISO/IEC 20000-1:2018 management systems {% hint style="success" %} BASIS is designed around deterministic execution, math constraints, and state machine risk controls. Capital preservation is implemented as a system rule, not an operator preference. The platform operates within active, publicly verifiable ISO management systems for information security and IT service management. {% endhint %} ## 1.1) Wallet model | Wallet | Asset type | Primary use | Deposit | Withdraw | Stake rewards | | -------------- | ------------- | -------------------------------------------------------------- | ----------------- | ----------------------------- | ------------- | | Funding Wallet | Native tokens | Hold deposited assets and receive swapped-back native balances | Yes | Yes | No | | Staking Wallet | stTokens | Hold swapped staking balances and accumulated rewards | Via 1:1 swap only | Via swap back to native asset | Yes | ### Supported asset mapping | Asset | Staked Token | | ----- | ------------ | | BTC | stBTC | | ETH | stETH | | SOL | stSOL | | PAXG | stPAXG | Swap rules are same-token only and 1:1 by quantity. BASIS does not support cross-asset swaps inside the staking flow. ## 1.2) Deposit model {% tabs %} {% tab title="BTC" %} BTC deposits use a BASIS-assigned address that is unique to your account. 1. Open Assets 2. Select BTC 3. Copy your assigned BTC deposit address 4. Send at least 0.0001 BTC from an external wallet or exchange 5. After confirmation, BTC appears in your Funding Wallet BTC deposits do not require a connected Web3 wallet. {% endtab %} {% tab title="ETH / SOL / PAXG" %} ETH, SOL, and PAXG deposits use a connected Web3 wallet. 1. Open Assets 2. Select ETH, SOL, or PAXG 3. Connect a supported Web3 wallet such as MetaMask 4. Approve the wallet prompt and submit the native token deposit 5. After confirmation, the asset appears in your Funding Wallet PAXG support is live and active. {% endtab %} {% endtabs %} ## 1.3) Core operational rules | Item | Rule | | -------------------------------- | ------------------------------------------------------------------ | | Deposit assets | BTC, ETH, SOL, PAXG only | | USDT | Internal accounting and display unit only | | Swap fee | 0.01% | | Deposit fee | 0% | | Withdrawal fee | 0.05% | | Minimum BTC deposit | 0.0001 BTC | | BTC withdrawal time | Typically 10 to 60 minutes | | ETH / SOL / PAXG withdrawal time | Typically 1 to 10 minutes | | Reward format | Accumulates in real time as the same stToken in the Staking Wallet | | Unstake behavior | Full position only, auto-MAX | | Claimable amount after unstake | Auto-credited to the Staking Wallet as stToken | | Fixed pools | Unstake only after the lock-up period ends | | Booster options | 14D +10%, 30D +20%, 90D +50%, 180D +100% | {% hint style="warning" %} USDT balances shown on the dashboard are for accounting and reporting. Deposits and withdrawals occur in native assets only. {% endhint %} ## 1.5) The Execution Engine: BHLE All execution in BASIS runs through BHLE, the Base58 Hyper-Latency Engine, proprietary routing infrastructure developed with Base58 Labs, the platform's research partner. | BHLE specification | Value | | ---------------------- | ------------------------------------------------------------------------------- | | Internal response time | Sub-50μs | | Throughput | 100K+ OPS | | Execution model | Deterministic routing with bounded variance and pre-validated state transitions | | Risk controls | Math-constrained eligibility checks before capital is allocated | | Asset isolation | Logical separation between user accounting and execution infrastructure | | Authorization model | Wallet-connected flows require user-side approval where applicable | | Infrastructure | N+1 bare-metal failover across multiple availability zones | | Connectivity | Unified bridge across Ethereum and Solana environments | | Research basis | Market microstructure design informed by Base58 Labs research | BHLE exists to capture short-lived structural alpha opportunities under strict execution constraints. In fragmented digital asset markets, delay converts opportunity into slippage. Deterministic execution precision is therefore a core system requirement. The execution stack operates within a broader operational framework designed for institutional-grade reliability. BASIS DIGITAL INFRASTRUCTURE LTD maintains active ISO/IEC 27001:2022 and ISO/IEC 20000-1:2018 certifications, both publicly verifiable on IAF CertSearch. These certifications support disciplined security governance and service management across the platform environment. {% hint style="info" %} Research context: BASIS combines proprietary infrastructure with market microstructure research from Base58 Labs. The design objective is consistent structural alpha capture under measurable latency, liquidity, and state constraints. BASIS DIGITAL INFRASTRUCTURE LTD's active ISO certifications are publicly verifiable on IAF CertSearch through the certification records and certified entity record listed above. {% endhint %} ## 2) Capital flow 🔄 ```mermaid flowchart LR U[User] -->|Deposit native asset| F[Funding Wallet] F -->|1:1 same-token swap| S[Staking Wallet] S -->|Allocated capital| E[Strategy Matrix] E -->|Real-time rewards in same stToken| S S -->|Unstake full position| S2[stToken credited to Staking Wallet] S2 -->|1:1 same-token swap back| F F -->|Withdraw native asset| U ``` {% stepper %} {% step %} **Step 1: Deposit into the Funding Wallet** Users deposit native assets only. * BTC uses a BASIS-assigned deposit address * ETH, SOL, and PAXG use a connected Web3 wallet {% endstep %} {% step %} **Step 2: Swap 1:1 into the Staking Wallet** Native assets are swapped into the matching stToken. * BTC → stBTC * ETH → stETH * SOL → stSOL * PAXG → stPAXG {% endstep %} {% step %} **Step 3: Capital enters the strategy matrix** The system allocates capital across independent modules for structural alpha capture, funding carry, and other constrained strategies. All allocations must satisfy deterministic eligibility and risk checks before activation. {% endstep %} {% step %} **Step 4: Rewards accrue in real time** Rewards accumulate continuously as the same stToken in the Staking Wallet. No manual claim step is required during active accrual. {% endstep %} {% step %} **Step 5: Unstake and return to native asset** Unstaking is full-position only. After unstake, the credited stToken balance appears in the Staking Wallet and can be swapped 1:1 back to the native asset in the Funding Wallet for withdrawal. {% endstep %} {% endstepper %} ## 3) BOVE: multi-strategy coordination BOVE is the portfolio allocator. It routes capital across independent opportunity sources so performance does not depend on a single module. This coordination layer improves capital efficiency by balancing: * cross-venue structural alpha capture * funding and carry opportunities * on-chain yield paths * liquidity availability * venue quality and settlement constraints The objective is not complexity for its own sake. The objective is stable, rule-based allocation across opportunity sets with different market dependencies. ## 4) BQAE: structural alpha core BQAE is the system component responsible for cross-venue structural alpha capture. Its operating cycle is: 1. Scanning\ High-frequency price discovery across a curated venue registry 2. Filtering\ Removal of low-quality venues and assets based on depth, liquidity, transfer health, and operational reliability 3. Coordinated execution\ Precision buy and sell placement with bounded slippage and exposure windows 4. Settlement and reconciliation\ Position closure, transfer validation, and post-trade accounting checks BQAE acts only when the measured opportunity exceeds the system's execution, liquidity, and risk thresholds. ## 5) Risk and safety states BASIS enforces capital protection through a formal state machine. | State | Function | | ------ | ----------------------------------------------------------------------------------------------- | | Normal | Strategies operate when all eligibility conditions are satisfied | | BSCB | Circuit breaker state that immediately restricts risk and halts affected activity | | DMM | Maintenance state used for unwind, root-cause analysis, venue review, and controlled resumption | These states are triggered by system rules, not discretionary judgment alone. This makes risk handling deterministic, auditable, and consistent across regimes. ### Control principles * pre-trade math constraints * deterministic state transitions * venue health scoring * notional and liquidity limits * controlled unwind procedures * reconciliation before resumption * security and service processes aligned with BASIS DIGITAL INFRASTRUCTURE LTD's active ISO/IEC 27001:2022 and ISO/IEC 20000-1:2018 management systems ## 6) Why this matters for users You do not need to understand every internal module to use BASIS effectively. You should understand the following: * Funding Wallet holds native assets * Staking Wallet holds stTokens and accrued rewards * swaps are same-token only and 1:1 by quantity * rewards accrue in real time as the same stToken * unstake is full-position only * fixed pools unlock only after the lock-up period ends * withdrawals depend on native asset settlement rails and liquidity buffers * dashboard sections are organized as Stake, Assets, Referral, Support, and Account * the platform is operated by BASIS DIGITAL INFRASTRUCTURE LTD, the certified entity for active ISO/IEC 27001:2022 and ISO/IEC 20000-1:2018 certifications that are publicly verifiable on IAF CertSearch {% hint style="success" %} The trust model of BASIS is based on deterministic execution, constrained strategy design, and explicit operational states. BHLE provides the speed. The risk engine provides the boundaries. Active, publicly verifiable ISO certifications strengthen the operational foundation behind that model. {% endhint %} *** Next: read Strategy Matrix to understand how BASIS sources structural alpha and yield across its execution modules. # Strategy Matrix {% 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 %} A single yield source is fragile. BASIS uses a strategy matrix so performance is not dependent on one venue, one protocol, or one market regime. The matrix is coordinated by BOVE and executed through BHLE, BASIS's proprietary routing infrastructure with sub-50μs latency and 100K+ OPS. The objective is structural alpha capture under strict mathematical constraints, not discretionary yield chasing. ## Strategy overview | Pipeline | Primary source | Role in the matrix | Core controls | | ------------------------------------------------------ | ------------------------------------------------ | ----------------------------- | ----------------------------------------------------------------- | | Spatial Arbitrage (BQAE Core) | Cross-venue spread dislocations | Short-horizon execution alpha | Depth checks, slippage bounds, venue health filters | | Delta-Neutral Funding Stream | Perpetual funding imbalances | Market-neutral carry | Hedge ratio controls, margin buffers, liquidation guards | | Structural Alpha Capture | Verified ecosystem incentive programs | Additive upside | Research filters, conservative sizing, lock and bridge limits | | Blue-Chip DeFi Lending and Liquid Staking Optimization | Mature on-chain money markets and liquid staking | Baseline yield layer | Audit filters, collateral limits, execution precision constraints | ## 1) Spatial Arbitrage: cross-venue spread capture Spatial arbitrage targets temporary price differences across venues. Why these differences exist: * heterogeneous latency and market structure * venue-specific inventory and risk limits * settlement and transfer frictions * localized order flow and temporary liquidity gaps BQAE participates only when all of the following are true: * executable depth is sufficient * modeled slippage remains below the target spread * venue status and transfer rails are healthy * expected unwind paths remain open {% hint style="success" %} Execution quality matters more than gross spread. BHLE is designed for deterministic routing so fill quality, latency discipline, and unwind capacity remain within predefined limits. {% endhint %} ## 2) Delta-Neutral Funding Stream: structural cashflow from perpetuals Perpetual futures use funding payments to keep perpetual prices anchored to spot markets. A delta-neutral funding strategy typically combines: * spot long plus perpetual short, or the reverse depending on regime * continuous hedge maintenance * conservative collateral and margin management BASIS routes exposure toward venues with favorable funding after netting out fees, basis drift, borrow costs, and liquidation risk. This turns funding into a constrained cashflow stream rather than an unconstrained directional bet. ## 3) Structural Alpha Capture: systematic incentive harvesting New networks and protocols often distribute incentives to bootstrap adoption and liquidity. BASIS treats these programs as a research-driven source of structural alpha when they satisfy strict inclusion criteria: * verified ecosystems and production-ready infrastructure * transparent emission schedules * acceptable bridge, custody, and smart contract risk * clear exit liquidity and unwind planning This sleeve is intentionally additive. It is not allowed to dominate total system risk. ## 4) Blue-Chip DeFi Lending and Liquid Staking Optimization Established lending and liquid staking markets can provide a baseline yield layer when: * protocols are mature and independently audited * collateral parameters are conservative * smart contract exposure is diversified * on-chain execution remains efficient This module diversifies the matrix beyond centralized venues while maintaining strict risk caps. Execution precision, not raw nominal APY, determines whether a position qualifies. {% tabs %} {% tab title="High-volatility regime" %} Cross-venue dislocations may widen, which can improve arbitrage opportunity density. Risk controls tighten at the same time because slippage, transfer delay, and venue stress can rise quickly. {% endtab %} {% tab title="Calm regime" %} Funding carry and baseline lending can contribute a larger share of total yield when spot dislocations compress and turnover falls. {% endtab %} {% tab title="Venue-stress regime" %} On-chain modules can provide an alternative source of yield and balance sheet flexibility, subject to gas costs, bridge constraints, and execution precision requirements. {% endtab %} {% endtabs %} ## 5) Why a matrix improves survivability The same strategy does not perform equally well in every regime. A matrix improves survivability because each pipeline responds differently to volatility, liquidity, funding conditions, and venue health. ## 6) Allocation workflow {% stepper %} {% step %} #### 🔎 Research admission Only approved venues, protocols, and assets enter the candidate set. This stage is informed by internal research and Base58 Labs review frameworks. {% endstep %} {% step %} #### ⚙️ Execution validation BHLE evaluates route quality, expected costs, and latency sensitivity before capital is assigned. {% endstep %} {% step %} #### 🛡️ Risk budget check BSCB/DMM state-machine controls verify margin buffers, unwind capacity, and strategy caps. {% endstep %} {% step %} #### 📊 Live monitoring Positions remain active only while expected edge, venue health, and system state remain within limits. {% endstep %} {% endstepper %} A position is admitted only if it satisfies deterministic guardrails: ``` allocate(strategy) only if expected_edge > all_costs and unwind_capacity >= required_threshold and state_machine == ACTIVE and risk_budget_after_trade <= strategy_cap ``` This reflects the BASIS operating principle: never exceed your ability to unwind. ## 7) Governing principle: unwind first, allocate second Every strategy is constrained by deterministic risk controls: * positions must be closeable without catastrophic slippage * withdrawals and transfer rails must remain operational * margin buffers must survive modeled stress * emergency states must be able to halt new exposure * portfolio transitions must remain valid under the BSCB/DMM state machine {% hint style="warning" %} Trust in BASIS is grounded in deterministic execution, mathematical constraints, and state-machine risk controls. Yield is a consequence of disciplined routing and capital allocation, not discretionary risk expansion. {% endhint %} *** Next: read BIVB & stTokens to understand principal accounting and the 1:1 quantity peg. # BIVB & stTokens (1:1 Quantity Peg) {% 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 uses a tokenized staking representation layer so users can: * deposit native assets * move capital from the Funding Wallet into the Staking Wallet * track principal and rewards with deterministic accounting * withdraw through controlled on-chain procedures This layer is called BIVB, BASIS Iso-Value Bridge. ## Wallet model | Wallet | Holds | Purpose | | -------------- | --------------------------- | --------------------------------------------------- | | Funding Wallet | BTC, ETH, SOL, PAXG | Deposit and withdraw native assets | | Staking Wallet | stBTC, stETH, stSOL, stPAXG | Stake, track rewards, and manage productive capital | ## 1) What BIVB does BIVB converts native assets in the Funding Wallet into staking representations in the Staking Wallet. | Native asset | Staking representation | Deposit method | Swap rule | | ------------ | ---------------------- | ----------------------------------------------------------------------------------------------------------------- | ----------------- | | BTC | stBTC | Copy your BASIS-assigned BTC address. Each account receives a unique deposit address. No Web3 wallet is required. | 1 BTC ↔ 1 stBTC | | ETH | stETH | Connect a Web3 wallet such as MetaMask or another compatible wallet. | 1 ETH ↔ 1 stETH | | SOL | stSOL | Connect a compatible Solana wallet such as Phantom. | 1 SOL ↔ 1 stSOL | | PAXG | stPAXG | Connect a Web3 wallet such as MetaMask or another compatible wallet. | 1 PAXG ↔ 1 stPAXG | Only same-token swaps are supported. | Asset | Staked Token | | ----- | ------------ | | BTC | stBTC | | ETH | stETH | | SOL | stSOL | | PAXG | stPAXG | Cross-asset conversion is not part of BIVB. ## 2) The 1:1 peg is about quantity, not fiat value BIVB enforces quantity preservation: * 1 BTC ↔ 1 stBTC * 1 ETH ↔ 1 stETH * 1 SOL ↔ 1 stSOL * 1 PAXG ↔ 1 stPAXG This is a quantity peg, not a fiat-value guarantee. If a user increases BTC quantity through rewards, the displayed USDT-equivalent value can still decrease if the BTC market price falls. The same logic applies to ETH, SOL, and PAXG. {% hint style="warning" %} USDT is used for internal valuation and interface display only. It cannot be deposited, swapped in from outside, or withdrawn from BASIS. {% endhint %} ## 3) Why BASIS uses stTokens instead of simple balances stTokens provide: * explicit separation between available capital and allocated capital * deterministic accounting for staking principal and rewards * clean same-token exit semantics, swap back to native asset, then withdraw on-chain * auditable state transitions under math-constrained system rules * compatibility with BASIS execution infrastructure for structural alpha capture This separation is important for system safety. BASIS runs proprietary routing infrastructure designed for execution precision, including BHLE characteristics such as sub-50μs latency and 100K+ OPS. Even with high-throughput execution, asset accounting remains deterministic at the token-quantity level. ## 4) Practical user flow {% tabs %} {% tab title="Deposit" %} 1. Move native assets into your Funding Wallet. 2. For BTC, send funds to your BASIS-assigned BTC deposit address. 3. For ETH, SOL, and PAXG, connect a compatible Web3 wallet and deposit on-chain. 4. Deposit fee is 0%. No minimum deposit {% endtab %} {% tab title="Swap and stake" %} 1. In the Funding Wallet, swap the native asset to its matching stToken. 2. Swap is always 1:1 within the same asset line. 3. Swap fee is 0.01%. 4. The resulting stToken appears in the Staking Wallet. 5. Stake from the Staking Wallet into the selected pool. Rewards accumulate in real time as the same stToken in the Staking Wallet view. {% endtab %} {% tab title="Unstake and withdraw" %} 1. Fixed pools can be unstaked only after the lock-up period ends. 2. Early exit is not available. 3. Unstake is full-position only. The interface applies auto-MAX to the entire staked position. 4. On unstake, the full claimable amount is auto-credited to the Staking Wallet as the same stToken. 5. Swap the stToken back to the matching native asset at 1:1. 6. Withdraw the native asset from the Funding Wallet. Withdrawal fee is 0.05%. {% endtab %} {% endtabs %} ## 5) Fees and processing times | Action | Fee | Notes | | ---------- | ----- | --------------------------------- | | Deposit | 0% | Native assets only | | Swap | 0.01% | Same-token only, native ↔ stToken | | Withdrawal | 0.05% | Native assets only | | Asset | Typical withdrawal time | | ----- | ----------------------- | | BTC | 10 to 60 minutes | | ETH | 1 to 10 minutes | | SOL | 1 to 10 minutes | | PAXG | 1 to 10 minutes | ## 6) Booster and rewards context BIVB defines how principal and rewards are represented. Reward multipliers are applied at the staking layer, not by changing the 1:1 quantity peg. Current Booster schedule: | Lock period | Booster | | ----------- | ------- | | 14D | +10% | | 30D | +20% | | 90D | +50% | | 180D | +100% | The 1:1 swap rule remains unchanged regardless of Booster selection. ## 7) Risk and trust implications Because stTokens represent allocated capital: * the risk profile is tied to the active strategy framework and operational controls * reward generation can slow or pause under protective system states * on-chain withdrawals follow asset-specific processing windows * quantity accounting remains deterministic even during stressed conditions BASIS is designed around: * deterministic execution * math constraints * state machine risk controls * auditable wallet separation * research-backed systems design through Base58 Labs These controls support structural alpha capture while keeping principal representation clear and operationally constrained. {% hint style="success" %} Key rule To exit, the sequence is always: stToken → matching native asset → on-chain withdrawal {% endhint %} BIVB defines how principal is tracked. The Risk Model explains how the system behaves under stress. # Economics: Pools, Lock-up, Boosters {% 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 economics are built around capital efficiency, deterministic execution, and explicit risk constraints. Reward differentials across pool types are justified by deployability of capital, execution precision, and structural alpha capture, not by discretionary marketing policy. This model is paired with BHLE, BASIS’s proprietary routing and execution infrastructure, designed for sub-50μs latency and 100K+ OPS. Economic policy, execution behavior, and state machine risk controls are designed as one system. ## 1) How capital enters a pool {% stepper %} {% step %} Fund the Funding Wallet Supported native assets are BTC, ETH, SOL, and PAXG. * BTC: copy your BASIS-assigned BTC deposit address. Each account has a unique address. No Web3 wallet is required. * ETH, SOL, PAXG: connect a supported Web3 wallet such as MetaMask and deposit directly. Minimum BTC deposit: 0.0001 BTC {% endstep %} {% step %} Convert native asset to staking balance The Funding Wallet holds native tokens. The Staking Wallet holds stTokens used for staking and reward accrual. Conversion is same-token 1:1 only, with a 0.01% swap fee. | Asset | Staked Token | | ------------- | ------------ | | BTC | stBTC | | ETH | stETH | | SOL | stSOL | | PAXG | stPAXG | | {% endstep %} | | {% step %} Stake into a pool Staking is performed with the corresponding stToken. Rewards accumulate in real time as the same stToken and are reflected in the Staking Wallet. {% endstep %} {% endstepper %} ## 2) Pool economics: flexible capital vs fixed-term capital {% tabs %} {% tab title="Flexible capital" %} Flexible capital prioritizes redemption availability. To support that flexibility, the system must retain a larger liquidity reserve. That reserve reduces the proportion of capital that can be continuously deployed, which lowers expected net yield. {% endtab %} {% tab title="Fixed-term capital" %} Fixed-term capital improves predictability. Because maturity is known in advance, BASIS can deploy a higher share of capital with tighter routing, hedging, and inventory planning. This supports higher expected net yield and allows booster allocation to be economically justified. {% endtab %} {% endtabs %} ## 3) Why boosters exist Boosters are a redistribution mechanism applied to higher-quality capital. In practical terms: * gross yield is generated through structural alpha capture and execution precision * costs include routing, hedging, settlement, and operations * net yield is the portion remaining after those costs * boosters increase the share of net yield allocated to fixed-term positions that improve capital efficiency This means boosters are not a free bonus. They reflect the economic value of predictable lock-up capital. ## 4) Booster schedule | Lock-up term | Booster | | ------------ | ---------: | | 14D | +10% | | 30D | +20% | | 90D | +50% | | 180D | +100% (2×) | {% hint style="warning" %} Boosters apply to the reward calculation basis of eligible fixed-term positions. They do not represent guaranteed returns. {% endhint %} ## 5) Adding stake to an existing fixed pool position When additional stake is added to an existing fixed-term position, BASIS treats the position as one aggregated allocation. As a result: * the lock-up timer resets from the timestamp of the additional stake * allocation remains fair across participants * strategy scheduling remains internally consistent * split-timing abuse is prevented by design This rule follows directly from deterministic pool accounting. ## 6) Unstake rules for fixed pools {% hint style="danger" %} Fixed pools can be unstaked only after the lock-up period ends. There is no early exit option. {% endhint %} Fixed-pool unstake behavior is as follows: * unstake is auto-MAX only * partial unstake is not supported * the entire staked position is released in one action * the resulting amount, including accrued rewards, is auto-credited to the Staking Wallet as the same stToken * there is no separate manual claim step After unstake, users may convert the stToken back to the corresponding native asset on a same-token 1:1 basis, then withdraw from the Funding Wallet. ## 7) Fees and settlement timing | Action | Fee | Notes | | ---------- | ----: | ----------------------------- | | Deposit | 0% | Native assets only | | Swap | 0.01% | Same-token 1:1 only | | Withdrawal | 0.05% | Native asset withdrawals only | | Asset | Deposit method | Typical withdrawal time | | ----- | -------------------------- | ----------------------- | | BTC | BASIS-assigned BTC address | 10 to 60 minutes | | ETH | Web3 wallet connection | 1–6min | | SOL | Web3 wallet connection | 1–6min | | PAXG | Web3 wallet connection | 1–6min | ## 8) Why economics and risk controls cannot be separated A platform cannot maximize liquidity, maximize deployment, and maximize yield at the same time without introducing hidden fragility. BASIS addresses this by aligning pool design with: * deterministic execution * mathematical constraints on deployable capital * state machine risk controls * predictable settlement pathways * clear wallet segregation between Funding Wallet and Staking Wallet That is the basis for credible reward distribution. {% hint style="success" %} In short, fixed-term capital supports tighter execution, better deployment ratios, and more consistent structural alpha capture. Booster policy is the economic expression of that improvement. {% endhint %} Next: read Risk Model to see how these policies are enforced under normal and stressed conditions. # Risk Model: States, Triggers, Protections {% 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 %} A platform risk model is its immune system. It defines how the system behaves under stress and is the primary control layer for capital preservation. At BASIS, the risk model is implemented as a deterministic state machine. It is designed to protect structural alpha capture by enforcing strict transitions, measurable triggers, and automated controls. This design works alongside BHLE execution infrastructure, including sub-50μs internal latency targets, 100K+ OPS capacity, and proprietary routing logic built for execution precision. This is not a theoretical framework. It is an engineering specification for a survivable system. *** ## 1) State hierarchy The system operates in one of three states. | State | Name | Description | System action | | ------ | ------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------- | | Normal | Normal Operating Mode | All monitored systems are healthy. Eligible opportunities may be routed and executed within risk limits. | Execute approved activity | | BSCB | Basis Sentinel Circuit Breaker | A defined trigger has been activated for a specific asset, venue, route, or module. The system enters a protective pause for the affected scope. | Stop new entries in affected scope | | DMM | Defensive Maintenance Mode | A severe, systemic, or unknown condition has been detected. Automated activity is halted until operator review and root cause analysis are complete. | Halt all automated activity | {% hint style="success" %} Why a state machine matters 🛡️ A deterministic state model improves auditability, reduces discretionary decision risk, and ensures that capital protection rules are applied consistently across market regimes. {% endhint %} ## 2) Trigger categories Triggers are specific, measurable conditions that cause a state transition. They encode known failure modes and define the system response in advance. {% tabs %} {% tab title="Market triggers" %} * Extreme volatility\ Realized volatility in a core asset, such as BTC, exceeds a predefined threshold over a short interval. * Execution precision inversion\ Estimated execution costs persistently exceed the expected structural alpha available across routes or venues. * Funding rate dislocation\ Funding rates become unstable, invert sharply, or diverge from historical ranges in a way that signals market stress. * Cross-venue basis shock\ The spread between reference venues widens beyond tolerance, increasing routing and hedge risk. {% endtab %} {% tab title="Venue triggers" %} * Deposit or withdrawal halt\ A major venue disables deposits or withdrawals for a relevant asset. * API instability\ Response latency, error rates, or order acknowledgement quality deteriorate beyond operational thresholds. * Abnormal pricing\ A venue price feed diverges materially from the global reference, suggesting internal issues, stale data, or market impairment. * Settlement degradation\ Transfer confirmation patterns, settlement behavior, or custody acknowledgements become inconsistent with baseline expectations. {% endtab %} {% tab title="Asset and accounting triggers" %} * PAXG basis dislocation\ PAXG market pricing diverges materially from reference gold pricing or exhibits sustained abnormal basis behavior. * Native asset chain stress\ BTC, ETH, SOL, or PAXG transfer conditions indicate abnormal confirmation delays, network instability, or elevated settlement risk. * Display-unit divergence\ The USDT/USD display basis moves outside internal tolerance. This affects reporting and accounting alerts only. It does not change the native-asset custody model. * Liquidity compression\ Available executable depth falls below minimum thresholds for safe routing or hedge maintenance. {% endtab %} {% tab title="Internal system triggers" %} * Margin buffer breach\ The safety buffer on a hedged or derivative-linked position falls below a critical threshold. * Reconciliation failure\ Internal ledgers, venue balances, and position records fail to reconcile within tolerance. * State integrity fault\ A control-plane inconsistency, sequencing error, or state transition mismatch is detected. * Risk control timeout\ A required kill-switch, limit update, or exposure reduction action does not complete within the allowed window. {% endtab %} {% endtabs %} *** ## 3) Protection logic When a trigger fires, protections are applied automatically according to severity and scope. {% stepper %} {% step %} **Step 1: Detect and classify** The system validates the trigger, assigns severity, and determines whether the issue is local, scoped, or systemic. {% endstep %} {% step %} **Step 2: Enter BSCB when the issue is scoped** If the condition is isolated to a route, asset, venue, or module, BASIS enters BSCB for that scope. New entries are blocked immediately. Existing exposure may be reduced if the condition persists. {% endstep %} {% step %} **Step 3: Enter DMM when the issue is systemic or unknown** If the condition threatens system-wide integrity, or if the failure mode is not fully classified, BASIS enters DMM. All automated activity stops and operator review begins. {% endstep %} {% step %} **Step 4: Resume only after validation** Normal operation resumes only after post-incident checks, ledger reconciliation, venue health confirmation, and control validation are complete. {% endstep %} {% endstepper %} ### Protection behavior by state | State | New entries | Existing exposure | Automation | Human review | | ------ | -------------------------- | ------------------------------------------------- | -------------------- | ------------ | | Normal | Allowed within limits | Managed normally | Active | Not required | | BSCB | Blocked for affected scope | Reduced if required by policy | Partially restricted | Conditional | | DMM | Fully blocked | Frozen or reduced according to emergency protocol | Halted | Required | {% hint style="warning" %} Customer impact During BSCB or DMM, funding and settlement workflows may be delayed if a relevant chain, venue, or risk-control dependency is affected. Under normal conditions, typical withdrawal processing targets from the Funding Wallet are 10 to 60 minutes for BTC and 1 to 10 minutes for ETH, SOL, and PAXG. (Note: Unstaking from fixed pools requires an additional 7-day buffer before these withdrawal times apply.) {% endhint %} *** ## 4) Control philosophy The BASIS risk model is based on three principles: 1. Deterministic execution over discretionary reaction\ The system should respond to stress through pre-validated rules, not improvised operator judgment. 2. Math constraints over narrative assumptions\ Positioning, routing, and exposure management must stay within quantified tolerances. 3. State machine risk controls over ad hoc overrides\ Every material protection action should be attributable to a clear trigger and an auditable transition. This approach is consistent with high-reliability systems, where the cost of uncontrolled failure is unacceptable. ``` if trigger.severity == "critical" or trigger.classification == "unknown": state = DMM halt_all_automation() alert_operators() elif trigger.scope in ["asset", "venue", "route", "module"]: state = BSCB block_new_entries(trigger.scope) reduce_exposure_if_required(trigger.scope) else: state = Normal ``` *** ## 5) Why this matters BASIS does not rely on a single defense. Capital protection depends on layered controls: * deterministic state transitions * reconciliation and ledger integrity checks * venue and chain health monitoring * routing constraints for execution precision * automated kill-switches and exposure reduction logic * operator review before restart after severe incidents The result is a system designed to preserve capital first and pursue structural alpha only inside clearly defined risk boundaries. *** ### References \[1] Weick, K. E., & Sutcliffe, K. M. (2007). Managing the Unexpected: Resilient Performance in an Age of Uncertainty. Jossey-Bass. # Operational Model: Venues, Fragmentation, Controls {% 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)). {% endhint %} BASIS interacts with third-party venues, including centralized exchanges and on-chain protocols, to execute structural alpha capture strategies. This introduces operational complexity, settlement dependencies, and counterparty risk. This page explains how BASIS manages: * venue selection and whitelisting * risk scoring and blacklisting * liquidity fragmentation * deterministic execution controls * incident response and public disclosure ## 1) Venue registry and whitelisting BASIS maintains a continuously updated venue registry. Only venues that satisfy minimum technical, operational, and risk thresholds are eligible for automated routing. These controls operate within an institutional-grade operating model supported by active ISO/IEC 27001:2022 and ISO/IEC 20000-1:2018 management systems. | Registry field | Description | | ------------------- | ------------------------------------------------------------------------- | | Connectivity status | Endpoint health, latency, timeout rate, failover readiness | | Market coverage | Supported spot and derivatives markets | | Withdrawal status | Enabled, delayed, limited, or halted | | Settlement paths | On-chain and exchange transfer routes available to BASIS | | Reliability metrics | Historical uptime, rejection rate, cancellation behavior | | Risk score | Composite score derived from operational and market conditions | | Capacity limits | Internal exposure caps, venue-specific throughput, and balance thresholds | Whitelisting is not static. A venue may be active for one market and blocked for another if local conditions differ. {% hint style="warning" %} Whitelisting is independent from strategy logic. A market signal does not authorize execution unless the venue also passes current operational and risk checks. {% endhint %} ## 2) Institutional-grade filtering For each candidate trade, BASIS evaluates whether the opportunity is executable under live constraints. This evaluation is performed through defined control layers that align with BASIS operational discipline and its certified information security and service management processes. {% tabs %} {% tab title="Market filters" %} * Order book depth and replenishment quality * Spread stability over short intervals * Realized slippage expectation * Fee impact after routing * Cross-venue price consistency {% endtab %} {% tab title="Operational filters" %} * Withdrawal availability * Deposit crediting reliability * Rate-limit pressure * Maintenance windows * API degradation or abnormal error rates {% endtab %} {% tab title="Risk filters" %} * Venue risk score threshold * Concentration limits * Asset-specific exposure limits * Transfer-path restrictions * Strategy-level capital allocation bounds {% endtab %} {% endtabs %} This filtering is what separates theoretical spread from executable structural alpha capture. ## 3) Blacklisting and dynamic exclusion A venue can be dynamically excluded when one or more of the following conditions appear: * withdrawals are delayed, limited, or halted * abnormal pricing or persistent dislocation is detected * API instability or sequencing errors appear * order acknowledgements become unreliable * counterparty risk score deteriorates beyond threshold * settlement paths become congested or unavailable Exclusion can occur automatically through system rules or manually through operator intervention. Re-entry requires fresh validation, not simple timeout expiry. ## 4) Liquidity fragmentation policy Because counterparty risk is real, BASIS follows a liquidity fragmentation policy. Capital is intentionally distributed across multiple venues and settlement paths rather than concentrated in a single location. | Policy rule | Objective | | ------------------------ | ----------------------------------------------------- | | Multi-venue distribution | Reduce single-point counterparty exposure | | Concentration caps | Prevent excessive dependence on one venue | | Pre-positioned balances | Reduce transfer delay during active execution windows | | Transfer-path diversity | Preserve optionality if a route degrades | | Protocol exposure limits | Bound smart contract and bridge-related risk | Where feasible, BASIS distributes capital across multiple venues and routes. This increases operational complexity, but materially improves survivability during venue-specific incidents. ## 5) Execution infrastructure and control framework BASIS uses BHLE, a proprietary routing and execution infrastructure designed for deterministic behavior under fragmented market conditions. | Capability | Standard | | ---------------- | ---------------------------------------------------------------------- | | Decision latency | Sub-50μs | | Throughput | 100K+ OPS | | Routing model | Proprietary multi-venue routing infrastructure | | Control model | Deterministic execution, math constraints, state machine risk controls | Execution flow is constrained by explicit system gates: ``` Signal → venue eligibility → risk gate → route selection → execution → post-trade reconciliation → exposure update ``` Key properties of the control framework: * deterministic order handling under predefined constraints * bounded exposure transitions through state-machine logic * hard rejection of routes that violate capital or reliability thresholds * continuous reconciliation between venue balances, internal ledgers, and strategy state These controls are designed to prioritize execution precision and capital preservation over nominal opportunity count. ## 6) Incident response and user communication 🔒 When a venue or protocol incident occurs, BASIS applies a formal response process. This process is supported by an operating framework aligned with the company’s active ISO/IEC 27001:2022 and ISO/IEC 20000-1:2018 certifications. 1. Detect and classify the event\ Identify whether the issue is related to market quality, API behavior, withdrawals, settlement, or counterparty risk. 2. Isolate affected routes\ Disable impacted venues, markets, or transfer paths. 3. Trigger protective state transitions\ Apply the appropriate system mode, including BSCB → DMM where required by internal risk logic. 4. Communicate externally\ Publish a timestamped notice describing scope, user impact, and current system status. 5. Resume only after verification\ Restart routing only after stability checks, reconciliation, and root-cause review are complete. {% hint style="info" %} Public documentation, dashboards, and status notices must match actual system behavior. Consistency between disclosed state and live state is a core trust requirement. BASIS treats this as part of an institutional-grade control environment with internationally verifiable management systems. {% endhint %} ## 7) Practical implication for users Venue fragmentation and dynamic exclusion may reduce short-term opportunity count, but they improve execution reliability and loss containment under stress. This is consistent with the BASIS operating model: * deterministic execution instead of discretionary intervention * constrained state transitions instead of ad hoc overrides * survivability first, then optimization In practice, this means BASIS is designed to operate as an institutional-grade, internationally certified, and trustworthy platform where execution discipline, operational resilience, and externally verifiable control standards matter as much as raw opportunity capture. *** Next: read `Metrics & Reporting` to understand how BASIS defines yield, APY, and performance figures. # Deposit Limits and Account Tier Capacity Operator and jurisdiction: BASIS is operated by BASIS DIGITAL INFRASTRUCTURE LTD, a Seychelles IBC (LEI: 254900IX2F2KCWNSSS64). Deposit limits on BASIS are deployment capacity controls. They are not wallet acceptance limits. BASIS accepts supported assets into the Funding Wallet. The account tier ceiling determines how much capital the BHLE execution engine can route into live arbitrage positions. Capital above the applicable ceiling remains idle in the Funding Wallet as native tokens. It is not swapped, not staked, and not represented as stTokens. > Deployment capacity protects execution quality. It prevents account capital from consuming the order book depth required to capture the spread, preserves venue concentration limits, and keeps Anti-Slippage Slicing inside its optimal execution window. ## Scope This page applies to supported BASIS assets. | Asset | Funding Wallet form | Staking Wallet form | | ----- | ------------------- | ------------------- | | BTC | BTC | stBTC | | ETH | ETH | stETH | | SOL | SOL | stSOL | | PAXG | PAXG | stPAXG | BASIS operates cross-exchange structural arbitrage across spatial price gaps, delta-neutral funding, early-stage alpha, and blue-chip DeFi lending strategies. ## Key definitions | Term | Definition | | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------ | | Deposit balance | Total supported assets credited to the Funding Wallet. | | Deployment ceiling | Maximum USD-equivalent capital that the execution engine can actively route under the account tier rules. | | Deployable capital | Capital that is eligible for routing into live strategies after tier capacity, asset support, and execution constraints are applied. | | Active deployment | Capital currently allocated to live arbitrage positions or strategy exposure. | | Excess capital | Capital above the tier ceiling. It remains idle in the Funding Wallet as native tokens. | | stToken balance | Strategy accounting representation in the Staking Wallet, such as stBTC, stETH, stSOL, or stPAXG. | ## Account tier deployment ceilings | Account tier | Capacity type | Deployment ceiling | What the ceiling governs | | ------------ | ------------------------------------ | ------------------------- | --------------------------------------------------------------------------------------------------------------- | | VIP2 | Rolling daily deployment ceiling | USD 2,000,000 equivalent | Maximum capital the execution engine can route into live deployment during the rolling daily deployment window. | | VIP3 | Cumulative active deployment ceiling | USD 20,000,000 equivalent | Maximum capital that can remain actively deployed at one time. | These ceilings do not cap total deposits. A Funding Wallet balance can exceed the tier ceiling. The ceiling controls routing into live arbitrage, not custody of supported assets. ## How tier capacity is applied When a deposit is credited, BASIS separates wallet acceptance from deployment eligibility. | Step | System action | | ------------------------------------ | -------------------------------------------------------------------------------------------------------- | | 1. Deposit received | Supported assets are credited to the Funding Wallet as native tokens. | | 2. USD-equivalent balance evaluated | The account system evaluates the deposit against the applicable tier ceiling. | | 3. Deployment eligibility calculated | Capital within the ceiling becomes eligible for routing by BHLE, subject to live market conditions. | | 4. Excess retained | Capital above the ceiling remains idle in the Funding Wallet. | | 5. Withdrawal remains available | Excess capital can be withdrawn immediately, subject to the standard withdrawal fee and processing time. | The execution engine does not swap or stake excess capital. Excess BTC remains BTC. Excess ETH remains ETH. Excess SOL remains SOL. Excess PAXG remains PAXG. ## Minimum deposit and fee reference | Item | Value | | ------------------------------- | ---------------------------------------------------- | | BTC minimum deposit | 0.0001 BTC | | ETH minimum deposit | Network practical minimum, see Fees and Price Impact | | SOL minimum deposit | Network practical minimum, see Fees and Price Impact | | PAXG minimum deposit | Network practical minimum, see Fees and Price Impact | | Deposit fee | 0% | | Withdrawal fee | 0.05% | | Swap fee | 0.01% | | BTC withdrawal processing time | 10 to 60 minutes | | ETH withdrawal processing time | 1 to 10 minutes | | SOL withdrawal processing time | 1 to 10 minutes | | PAXG withdrawal processing time | 1 to 10 minutes | ## Why deployment ceilings exist Deployment ceilings are execution risk controls. In arbitrage, capital only produces value while the executable edge remains positive after slippage, fees, latency, and venue constraints. Once capital size exceeds the depth that can be executed efficiently, additional capital does not increase return. It consumes the spread that the strategy is designed to capture. ### 1) Self-impact and order book depth Cross-exchange arbitrage captures the difference between two executable prices. The spread is not a static balance sheet asset. It exists at specific price levels, across specific venues, for limited size. Let: ``` Q = capital selected for deployment D(p) = executable cumulative order book depth at price level p spread(p) = observable cross-venue spread before execution slippage(Q, D(p)) = execution cost caused by consuming available depth fees = venue fees, network costs, and swap costs where applicable e(Q) = executable edge after slippage and fees ``` The executable edge is: ``` e(Q) = spread(p) - slippage(Q, D(p)) - fees ``` Deployment is valid only while: ``` e(Q) > 0 ``` As Q approaches the available depth D(p), the engine begins consuming the same spread it is trying to monetize: ``` Q -> D(p) slippage(Q, D(p)) increases e(Q) -> 0 ``` Beyond the profitable execution size, edge turns negative: ``` Q > Q* e(Q) < 0 ``` Where Q\* is the maximum deployment size where e(Q) remains positive. Order book depth is discrete and nonlinear. The first units of capital may execute against top-of-book liquidity. Larger parent orders climb the ask on the buy venue, hit lower bids on the sell venue, or both. The resulting volume-weighted average price moves against the account. The effect is self-impact. The account becomes large enough relative to available depth that its own execution destroys the arbitrage spread. Deployment ceilings keep account-level capital below the range where self-impact becomes the dominant cost. ### 2) Anti-Slippage Slicing constraints BASIS uses the BHLE execution engine with sub-50 microsecond decision latency and 100K+ OPS throughput. BHLE fragments large parent orders through the Anti-Slippage Slicing algorithm. The objective is to reduce market impact by distributing execution across child orders, time intervals, venues, and price levels. For a parent deployment: ``` Q = sum(q_i for i = 1 to n) q_i = child order size n = number of child orders t_parent = t_n - t_0 ``` Each child order has its own executable edge: ``` e_i = spread_i - slippage(q_i, D_i) - fees_i ``` The parent deployment remains valid when the size-weighted edge is positive after execution risk: ``` E_parent(Q) = sum(q_i * e_i for i = 1 to n) / Q Deploy only if E_parent(Q) > drift_risk(t_parent) ``` Slicing reduces instantaneous market impact, but it does not eliminate time risk. As Q increases, the algorithm requires more child orders. More child orders expand the parent execution window. A longer execution window increases: | Risk source | Impact on deployment | | ----------------------- | ------------------------------------------------------------------------ | | Price drift | The observed spread can compress before all child orders complete. | | Queue reshuffling | Top-of-book liquidity can disappear or reprice. | | Cross-exchange latency | One leg can fill while the opposite leg becomes less attractive. | | Correlation compression | High cross-exchange correlation can close the gap before full execution. | | Funding interval change | Funding-linked trades can lose edge as the funding window advances. | The slicing model has an optimal capital envelope. Inside that envelope, fragmentation lowers slippage without extending execution beyond the edge horizon. Beyond that envelope, the cost of time exceeds the residual spread. The tier ceiling prevents the engine from expanding the parent execution window into an unprofitable regime. ### 3) Liquidity fragmentation policy BASIS distributes capital across multiple venues. Venue allocation is controlled through liquidity fragmentation and per-venue concentration caps. No single venue is allowed to receive an allocation approaching its concentration cap for the purpose of absorbing oversized account capital. Let: ``` A_j(Q) = allocation to venue j generated by account deployment Q C_j = concentration cap for venue j ``` The venue allocation constraint is: ``` For every venue j: A_j(Q) < C_j ``` If an account deposit exceeds the tier ceiling, increasing deployment would require one of two outcomes: | Outcome | BASIS policy | | ---------------------------------------- | ---------------------------------------------------------------------- | | Allocate more capital to the same venues | Not permitted when it pushes venue exposure toward concentration caps. | | Relax venue concentration limits | Not permitted by the risk engine. | | Leave excess capital idle | Required control behavior. | The per-account ceiling is calibrated so that, after capital is fragmented across active venues, no single venue receives an allocation that compromises concentration controls. See Operational Model: Venues, Fragmentation, Controls for the full fragmentation policy. ### 4) Staged opportunistic deployment Capital is not deployed all at once. BASIS uses a staged deployment model. The Data Pipeline continuously scans venues for qualifying spreads. A tranche is allocated only when the executable edge is positive after fees and estimated slippage: ``` Deploy tranche k only if: spread_k - slippage(q_k, D_k) - fees_k > executable_edge_threshold_k ``` This applies across spatial price-gap trades, delta-neutral funding trades, early-stage alpha routes, and blue-chip DeFi lending opportunities. The engine deploys when the market offers an executable spread. It remains idle when the market does not. The deployment sequence: ``` Funding Wallet (idle native asset) -> spread detected by Data Pipeline -> venue eligibility check -> risk gate validation -> tranche allocation (anti-slippage sliced) -> execution and post-trade reconciliation -> exposure state update ``` During low-spread environments or high cross-exchange correlation regimes, gaps compress. In those conditions, eligible capital can remain in the Funding Wallet. Idle capital is a risk control state, not an execution failure. ## What happens when a deposit exceeds the ceiling If a deposit exceeds the account tier ceiling, BASIS accepts the full supported asset balance into the Funding Wallet. The excess remains idle. | Condition | Result | | --------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | | Deposit exceeds VIP2 rolling daily deployment ceiling | The account can receive the full deposit. BHLE routes only up to the eligible rolling daily amount. Excess remains in the Funding Wallet. | | Deposit exceeds VIP3 cumulative active deployment ceiling | The account can receive the full deposit. BHLE routes only up to the active deployment ceiling. Excess remains in the Funding Wallet. | | Excess capital is present | It is not swapped, not staked, and not converted into stTokens. | | User wants to withdraw excess | Withdrawal can be initiated immediately. Standard withdrawal fee and processing time apply. | | Withdrawal fee | 0.05% | | BTC withdrawal time | 10 to 60 minutes | | ETH, SOL, PAXG withdrawal time | 1 to 10 minutes | There is no penalty for depositing above the tier ceiling. There is no lock-up on excess capital in the Funding Wallet. ## Capacity examples ### VIP2 example A VIP2 account deposits USD 2,500,000 equivalent in BTC. | Component | Treatment | | ------------------------------------- | ------------------------------------------------------------------------- | | Total Funding Wallet credit | USD 2,500,000 equivalent in BTC | | VIP2 rolling daily deployment ceiling | USD 2,000,000 equivalent | | Eligible for routing | Up to USD 2,000,000 equivalent during the rolling daily deployment window | | Excess | USD 500,000 equivalent remains idle in BTC | | Withdrawal status of excess | Available immediately, subject to the 0.05% withdrawal fee | ### VIP3 example A VIP3 account deposits USD 25,000,000 equivalent across BTC and ETH. | Component | Treatment | | ----------------------------------------- | ----------------------------------------------------------------------------------------------------------- | | Total Funding Wallet credit | USD 25,000,000 equivalent across native assets | | VIP3 cumulative active deployment ceiling | USD 20,000,000 equivalent | | Eligible active deployment | Up to USD 20,000,000 equivalent | | Excess | USD 5,000,000 equivalent remains idle in the Funding Wallet | | Additional deployment | Only available when active deployment capacity is below the tier ceiling and qualifying opportunities exist | ## Controls and operating environment Deployment capacity is part of the BASIS control framework. | Control area | BASIS implementation | | -------------------------------- | -------------------------------------------------------------------------------- | | Operator | BASIS DIGITAL INFRASTRUCTURE LTD, Seychelles IBC, LEI: 254900IX2F2KCWNSSS64 | | Research partner | Base58 Labs Limited, Company No. 17094713, England and Wales | | Execution engine | BHLE, sub-50 microsecond decision latency, 100K+ OPS throughput | | Order execution | Anti-Slippage Slicing fragments large orders to reduce market impact | | Venue allocation | Liquidity fragmentation across multiple venues with per-venue concentration caps | | Principal risk halt | BSCB circuit breaker triggers automatic halt if principal risk reaches 0.001% | | Security certification | ISO/IEC 27001:2022, SC62455E, active and verifiable on IAF CertSearch | | Service management certification | ISO/IEC 20000-1:2018, active and verifiable on IAF CertSearch | ## FAQ **Is there a maximum deposit amount?** No tier-based maximum deposit amount is imposed by the deployment ceiling. Supported assets are accepted into the Funding Wallet. The tier ceiling governs how much capital the execution engine can route into live arbitrage positions. **What if my deposit exceeds my tier ceiling?** The full supported asset balance is credited to the Funding Wallet. The amount above the tier ceiling remains idle as native tokens. It is not swapped, not staked, and not converted into stTokens. You can withdraw the excess immediately, subject to the 0.05% withdrawal fee and normal processing time. **Will all my deployable capital be working simultaneously?** No. Deployable capital is capital eligible for routing, not a guarantee of simultaneous deployment. BHLE deploys tranches only when the Data Pipeline identifies qualifying opportunities where executable edge remains positive after fees, slippage, and execution risk. During compressed-spread regimes, some or all eligible capital can remain idle. **What is the difference between VIP2 and VIP3?** | Tier | Main difference | | ---- | ---------------------------------------------------------------------------------------------------------------------------------- | | VIP2 | USD 2,000,000 equivalent rolling daily deployment ceiling. The control applies to routed deployment over the rolling daily window. | | VIP3 | USD 20,000,000 equivalent cumulative active deployment ceiling. The control applies to capital actively deployed at one time. | VIP3 provides materially larger active capacity. Both tiers use the same execution discipline. Neither tier converts the deployment ceiling into a hard deposit limit. **How do I inquire about institutional capacity arrangements?** Contact . Institutional capacity reviews are handled through official company support channels only. Include the legal entity name, expected asset mix, requested USD-equivalent capacity, onboarding timeline, and any venue or custody constraints. # Metrics & Reporting {% 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 %} {% hint style="warning" %} Reporting unit: Dashboard values may be displayed in a USDT-equivalent internal accounting unit for consistency. USDT is not a deposit or withdrawal asset on BASIS. Funding Wallet supports native assets only: BTC, ETH, SOL, PAXG.\ Staking Wallet holds stTokens only: stBTC, stETH, stSOL, stPAXG. {% endhint %} A platform’s credibility depends on whether it reports metrics in a way that: * is internally consistent * cannot be gamed by selective framing * aligns with user outcomes * can be reconciled under stress conditions This section defines how BASIS reports and interprets performance metrics. ## 1) Core reporting principle: net realized yield BASIS focuses on net realized yield. This means: * realized profits from structural alpha capture, funding mechanisms, and onchain yield sources * net of execution costs, venue fees, network fees, and operational overhead * measured first in native asset terms * translated into a USDT-equivalent display unit for reporting consistency Any secondary metric must reconcile to net realized yield. ``` net_realized_yield = realized_gross_profit - execution_costs - venue_fees - network_fees - operational_costs ``` {% hint style="info" %} stTokens are accounting wrappers for staking participation and rewards. Swaps are same-token only at 1:1: * BTC → stBTC * ETH → stETH * SOL → stSOL * PAXG → stPAXG Swap fee: 0.01% {% endhint %} ## 2) APR vs APY {% tabs %} {% tab title="APR" %} APR is a simple annualized rate with no compounding assumption. {% endtab %} {% tab title="APY" %} APY is an annualized rate that assumes compounding. {% endtab %} {% endtabs %} If BASIS reports APY, it must also specify: * compounding frequency * whether compounding is automatic or user-initiated * whether the figure is based on historical windows or live rolling data * whether booster effects are included ### Reporting rule Booster effects must never be blended into a base rate without clear labeling. Booster schedule: | Booster term | Multiplier | | ------------ | ---------: | | 14D | +10% | | 30D | +20% | | 90D | +50% | | 180D | +100% (2×) | For fixed pools, unstaking is only available after the lock-up period ends. There is no early exit option. ## 3) Historical reference vs illustrative example Any numeric example must be labeled as one of the following: | Label | Meaning | | -------------------- | --------------------------------------------- | | Historical reference | Past realized figures from completed periods | | Live rolling metric | Current metric derived from an ongoing window | | Illustrative example | Hypothetical example for explanation only | BASIS should avoid forward-looking promises. Where appropriate, publish ranges or scenario bands instead of single-point expectations. ## 4) Strategy contribution breakdown For sophisticated users, BASIS should report contribution by strategy module. Examples include: * cross-venue structural alpha capture * funding and basis capture * onchain lending or liquidity deployment * PAXG-linked yield modules Costs should also be broken down explicitly: * venue fees * routing slippage * network fees * withdrawal charges * hedging or carry costs This allows users to evaluate where returns came from and how much was consumed by execution. ## 5) Key risk metrics to surface A professional dashboard should track: * system state (Normal / BSCB / DMM) * slippage distribution versus configured bounds * venue incident count and current exposure * funding rate distribution, when perp hedges are used * latency and fill-quality telemetry * intervention count from state machine risk controls * reference price deviation for the USDT-equivalent display unit * spot/reference divergence for PAXG modules {% hint style="info" %} Trust is not created by marketing claims. It is created by deterministic execution, bounded behavior, and transparent exception handling. {% endhint %} ## 6) Reconciliation and auditability For each reporting period, BASIS should be able to reconcile: * starting balances by asset * realized PnL by module * fees and costs by category * ending balances by asset * total rewards credited to users * any pending operational adjustments {% stepper %} {% step %} Record opening balances Capture Funding Wallet and Staking Wallet balances by asset: * BTC, ETH, SOL, PAXG in Funding Wallet * stBTC, stETH, stSOL, stPAXG in Staking Wallet {% endstep %} {% step %} Attribute realized performance Break out realized gains and losses by strategy module, including structural alpha capture, funding, and onchain sources. {% endstep %} {% step %} Deduct costs Deduct execution costs, venue fees, network fees, swap fees, and withdrawal fees. {% endstep %} {% step %} Credit user rewards Rewards accumulate in real time as the same stToken in the Staking Wallet. Upon unstake: * the unstake amount is auto-MAX, full position only * the claimable amount is auto-credited to the Staking Wallet as stToken {% endstep %} {% step %} Verify closing balances Closing balances must reconcile with all credited rewards, fees, and realized strategy outcomes. {% endstep %} {% endstepper %} ## 7) User-facing reporting rules The following conventions must be consistent across the dashboard, statements, and support responses. | Item | Reporting rule | | -------------------------------- | -------------------------------------------------------------------------------- | | Deposit assets | BTC, ETH, SOL, PAXG only | | USDT | Internal accounting and display unit only, not depositable or withdrawable | | BTC deposit flow | Copy the BASIS-assigned BTC address, unique per account, no Web3 wallet required | | ETH / SOL / PAXG deposit flow | Connect a Web3 wallet such as MetaMask | | Minimum BTC deposit | 0.0001 BTC | | Wallet model | Funding Wallet for native assets, Staking Wallet for stTokens | | Reward unit | Rewards accrue as the same stToken in real time | | Swap model | Same-token 1:1 only | | Deposit fee | 0% | | Withdrawal fee | 0.05% | | Swap fee | 0.01% | | BTC withdrawal time | 10 to 60 minutes | | ETH / SOL / PAXG withdrawal time | 1 to 10 minutes | | Unstake behavior | Full position only, auto-MAX | | Fixed pools | Unlock only after the lock-up period ends | ## 8) What credible reporting looks like A credible yield platform does not rely on isolated high-return snapshots. It shows that: * performance reconciles over time * costs are visible * rewards match realized outcomes * risk states are observable * execution quality is measurable * user balances can be audited from start to finish If you want to evaluate whether a yield platform is real, ask whether its numbers still reconcile during volatile markets, degraded venue conditions, and constrained liquidity. That is where reporting standards matter most. # Execution Model: Technical Detail {% 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 %} The BASIS execution model follows one rule: deterministic, low-latency, atomic execution. BHLE is the execution layer behind structural alpha capture and funding-rate strategies. It combines sub-50μs internal execution latency, 100K+ OPS throughput, proprietary routing infrastructure, and fail-closed state-machine controls to keep execution variance bounded. ## Core execution properties | Property | Implementation | | ----------------------- | ----------------------------------------------------------------------------------------- | | Deterministic routing | Pre-calculated venue state removes last-second discovery calls | | Math-constrained sizing | Position sizing, slippage bounds, and margin checks are computed against fixed invariants | | Atomic coordination | Dual-leg orders are linked by correlation ID and timeout logic | | Risk control model | State-machine transitions block invalid or partially reconciled states | | Reliability scoring | Venue quality is updated from observed acknowledgements, fills, and slippage | ## Pre-calculated network state Many execution stacks react in-line. A signal arrives, the system queries books, sizes the trade, then submits. Each query adds latency and jitter. BHLE avoids that by continuously maintaining a pre-calculated network state, a live model of: * current order book depth across active venues * normalized liquidity at each price level within the slippage bound of 0.30% * current margin ratios across open positions * funding-rate state per asset and venue * network and gas estimates for on-chain settlement legs * venue health, acknowledgement quality, and route reliability scores When a signal fires, BHLE decides against this state instead of issuing last-second queries. This removes a major latency source and improves execution precision. ## Order submission pipeline ``` [Signal] -> [Decision] -> [Order Construction] -> [Atomic Submission] -> [Fill Confirmation] <1μs <5μs <10μs <14μs <20μs Total internal pipeline target: <50μs ``` {% stepper %} {% step %} #### 1. Signal Signals enter from three sources: * funding-rate monitor, scheduled * structural alpha scanner, continuous * risk monitor, event-driven Each signal carries the asset, direction, target notional, maximum slippage, timeout window, and route class. {% endstep %} {% step %} #### 2. Decision BHLE checks the signal against the pre-calculated state and hard risk constraints: * is the spread still inside the 0.30% slippage bound * is depth sufficient for the target notional * are margin ratios above minimum on both legs * are venue health and route reliability above threshold * are circuit breakers and state-machine guards clear If any check fails, BHLE rejects the signal and submits no order. {% endstep %} {% step %} #### 3. Order construction BHLE builds both legs at the same time with synchronized order IDs. Each order contains: * venue * asset * side * quantity * limit price derived from spot and tolerance * correlation ID linking the two legs Sizing is math-constrained. Orders cannot exceed the validated depth, margin envelope, or route timeout budget. {% endstep %} {% step %} #### 4. Atomic submission BHLE submits both orders simultaneously over co-located venue links and proprietary routing infrastructure. Atomic means the trade is treated as one coordinated state transition. If Leg 2 does not receive a fill acknowledgement inside the timeout window, BHLE cancels or offsets Leg 1 immediately. The engine does not leave a partially hedged position open past the configured threshold. {% endstep %} {% step %} #### 5. Fill confirmation BHLE receives acknowledgements and fills, reconciles them, and updates the state model. If realized slippage exceeds the configured threshold, the trade is flagged for post-trade review and the venue reliability score is adjusted. {% endstep %} {% endstepper %} ## Latency breakdown | Stage | Target latency | Primary bottleneck | | ------------------------------------ | -------------- | ------------------------------ | | Signal to Decision | < 1μs | pre-calculated state lookup | | Decision to Order Construction | < 5μs | dual-leg size calculation | | Order Construction to Submission | < 10μs | network serialization | | Submission to Exchange ACK | < 14μs | co-location and venue response | | Exchange ACK to Fill Confirmation | < 20μs | exchange matching engine | | End-to-end, signal to confirmed fill | < 50μs | BHLE internal path | {% hint style="info" %} These figures represent BHLE internal processing targets. Venue network RTT and blockchain finality are external to the internal latency budget. {% endhint %} ## Atomic execution and partial fill prevention {% tabs %} {% tab title="Preventive controls" %} * correlated order IDs for both legs * pre-trade depth validation on both routes * slippage ceiling fixed at 0.30% * margin and exposure invariants checked before submission * venue health and reliability gating {% endtab %} {% tab title="Fail-closed behavior" %} * if Leg 2 misses the timeout, Leg 1 is cancelled or neutralized immediately * if state reconciliation fails, new orders are blocked until the state machine returns to a valid state * if a venue degrades, the route is disabled and traffic is rebalanced * if market movement exceeds tolerance, the order is rejected rather than chased {% endtab %} {% endtabs %} Partial fills are the primary execution risk in cross-venue structural alpha capture. BHLE reduces that risk by combining pre-trade validation, correlated execution, and immediate rollback logic. ## SVM vs EVM execution differences BHLE bridges SVM and EVM environments for BIVB operations and active PAXG settlement paths. | Dimension | SVM (Solana) | EVM (Ethereum and L2) | | -------------------- | --------------------------------------- | ---------------------------------------------------- | | Block time | \~400ms | 12s on L1, \~250ms on fast L2s | | Transaction finality | \~1s, optimistic | multi-block on L1, faster on L2 depending on network | | Gas model | fixed compute units | variable gas pricing | | Parallelism | native parallel execution | sequential virtual machine execution | | BHLE use | preferred for time-sensitive settlement | used for DeFi integrations and active PAXG routes | {% hint style="warning" %} For time-sensitive BIVB settlement, BHLE prefers the route with the best combined latency, liquidity quality, and deterministic settlement profile. In practice, that often favors SVM paths for high-speed settlement and EVM paths for integrations where liquidity access or asset support is superior. {% endhint %} ## Why this matters Execution quality is not only a speed problem. It is a control problem. BASIS uses deterministic routing, math-bounded sizing, and state-machine risk controls so that structural alpha capture remains inside a known execution envelope instead of depending on discretionary intervention. ## See also * [System Overview](/whitepaper/system-overview) * [BHLE Architecture](/technical-architecture/overview) * [Cross-Venue Execution](/research-library-deep-dives/cross-exchange-execution) # Architecture Overview {% 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 a distributed execution platform, not a monolithic application. The system is engineered for structural alpha capture with deterministic execution, high-throughput event processing, and tightly bounded operational risk. Its architecture is designed to support an institutional-grade operating model with traceable controls, disciplined service delivery, and publicly verifiable international certifications. Core infrastructure targets include: * Sub-50μs internal routing latency in the BHLE layer * 100K+ OPS across ingest, signal, execution, and ledger services * Proprietary routing infrastructure across centralized and onchain venues * Deterministic replay from immutable event logs * State-machine risk controls with hard veto and isolation paths This page summarizes the major building blocks. {% tabs %} {% tab title="Data plane" %} Market data ingestion → normalization → signal generation → execution orchestration → reconciliation {% endtab %} {% tab title="Control plane" %} Risk engine → venue health checks → state transitions → audit trail → monitoring and recovery {% endtab %} {% endtabs %} ## 1) Core design philosophy BASIS uses an event-driven, event-sourced architecture. Services publish and consume immutable events instead of relying on direct point-to-point calls. Typical events include: ``` OrderBookUpdate TradeExecuted HedgeCompleted WithdrawalRequest LedgerPosting RiskStateChanged ``` This model provides: * Resilience: Loose coupling reduces fault propagation * Scalability: Event streams can be partitioned and processed in parallel * Auditability: The log is a time-ordered record suitable for replay, verification, and compliance review * Determinism: Historical behavior can be reconstructed from the event sequence These properties also support the operational control objectives expected of institutional-grade platforms, including traceability, repeatability, and controlled service delivery under the active ISO/IEC 27001:2022 and ISO/IEC 20000-1:2018 certifications held by BASIS DIGITAL INFRASTRUCTURE LTD. ## 2) Component pipeline ⚙️ The production path is organized as a deterministic pipeline. {% stepper %} {% step %} #### Data ingestion Collect, normalize, timestamp, and sequence venue data. {% endstep %} {% step %} #### Signal generation Convert normalized market state into structural alpha signals with explicit cost and confidence estimates. {% endstep %} {% step %} #### Execution orchestration Route and coordinate orders with execution precision and hedge-completion controls. {% endstep %} {% step %} #### Risk gating Apply state-machine checks, exposure limits, and venue health controls before any action is allowed. {% endstep %} {% step %} #### Accounting and reconciliation Post every state transition to the ledger and verify balances continuously. {% endstep %} {% endstepper %} | Layer | Primary role | Key properties | | ---------------- | --------------------------------- | -------------------------------------------------------- | | Data pipeline | Ingest and normalize venue data | Low jitter, venue adapters, schema normalization | | Signal layer | Generate structural alpha signals | Cost-aware scoring, confidence weighting, regime filters | | Execution layer | Route and coordinate orders | Execution precision, hedge completion, failover | | Risk engine | Enforce hard constraints | State-machine controls, venue halts, exposure caps | | Accounting layer | Maintain balances and P\&L | Deterministic ledger, continuous reconciliation | ### 2.1) Data pipeline Function: * Ingest real-time market data from centralized and onchain venues, including order books, trades, quotes, and venue health signals * Normalize heterogeneous venue formats into a consistent internal schema * Timestamp and sequence messages for replay and latency analysis Implementation characteristics: * Low-latency WebSocket and API connectivity * Data-oriented implementation in performance-focused languages such as C++ and Rust * Kernel-bypass and packet-path optimization where appropriate * Backpressure controls to preserve system stability under burst load ### 2.2) Signal and alpha generation Function: * Convert normalized data into executable structural alpha signals * Evaluate spread quality, expected edge, impact costs, and completion probability before any order is formed Signals are not simple price-gap alerts. A valid signal carries: * Expected edge after fees and slippage * Estimated completion cost * Confidence score * Venue and inventory constraints * Time-sensitivity and decay characteristics This layer reflects ongoing research conducted with Base58 Labs as a Research Partner. ### 2.3) Execution orchestration Function: * Transform approved signals into concrete order instructions * Manage placement logic, slicing, hedge sequencing, and venue-specific routing behavior Execution priorities: * Precision: Minimize timing drift between related legs * Completion: Reduce partial-fill and hedge-failure risk * Determinism: Ensure each decision path is observable and replayable * Throughput: Sustain 100K+ OPS across active routing paths BHLE sits in this layer as the high-performance routing fabric. It is optimized for sub-50μs internal decision latency and uses proprietary routing infrastructure to maintain execution precision across fragmented markets. ### 2.4) Risk engine Function: * Act as the hard gatekeeper for system actions * Evaluate market state, venue state, internal balances, and strategy constraints before execution is allowed Control mechanisms include: * BSCB/DMM state transitions * Venue health and liveness checks * Exposure and inventory limits * Kill-switch and circuit-breaker logic * Strategy-level veto rules {% hint style="warning" %} The risk engine can reject, pause, or isolate a subsystem automatically. This is a hard control plane, not a best-effort alerting layer. {% endhint %} Risk is managed as a deterministic state machine. That design makes failure handling explicit, testable, and auditable. It also aligns with the control, service governance, and continuous improvement disciplines reflected in BASIS DIGITAL INFRASTRUCTURE LTD's active ISO/IEC 27001:2022 and ISO/IEC 20000-1:2018 certifications. The ISO/IEC 27001:2022 certification covers The Design and Development of Software and Quantitative Research Systems and the Management of Associated IT Infrastructure and Information Security. ### 2.5) Accounting and reconciliation Function: * Maintain the authoritative ledger for balances, positions, rewards, fees, and realized results * Reconcile internal state continuously against venue state and blockchain state where applicable Accounting principles: * Every state transition is event-backed * All postings must satisfy mathematical balance constraints * Drift detection runs continuously * Exceptions are surfaced through explicit reconciliation events Platform wallet domains are enforced at the ledger level: * Funding Wallet: native assets only, including BTC, ETH, SOL, and PAXG for deposit and withdrawal * Staking Wallet: stTokens only, including stBTC, stETH, stSOL, and stPAXG for staking and reward accrual Swap operations are same-token 1:1 conversions only: * BTC ↔ stBTC * ETH ↔ stETH * SOL ↔ stSOL * PAXG ↔ stPAXG This separation reduces accounting ambiguity and supports deterministic balance verification. ## 3) Why this architecture supports trust 🔒 The architecture follows the same principles used in professional execution systems: * Separation of concerns: Each service owns a narrow, testable responsibility * Deterministic execution: Decisions can be replayed from the event log * Mathematical constraints: Ledger and exposure rules are enforced mechanically * State-machine risk control: Unsafe transitions are blocked by design * Operational transparency: Audit trails exist at transaction and system-state level In practical terms, BASIS turns research into measurable production behavior. Structural alpha capture depends not only on signal quality, but also on deterministic execution, rigorous risk gating, and verifiable accounting. This architecture is operated by BASIS DIGITAL INFRASTRUCTURE LTD under active and publicly verifiable ISO/IEC 27001:2022 and ISO/IEC 20000-1:2018 certifications, reinforcing BASIS's institutional-grade security, service management, and operational trust profile. ### Reference \[1] Martin Kleppmann, Designing Data-Intensive Applications, O'Reilly Media, 2017. # Data Pipeline & Market Scanning {% 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 %} In structural alpha capture, the first failure mode is accepting a price that is not truly executable. The data pipeline converts raw venue signals into a validated signal stream for the execution precision layer. That stream feeds BHLE, the BASIS execution engine built for sub-50μs routing, 100K+ OPS throughput, and proprietary routing infrastructure. {% hint style="warning" %} A visible spread is not automatically tradable. A signal is only eligible if it passes price validation, venue health checks, cost modeling, and deterministic execution constraints. {% endhint %} ## 1. Signal sources {% tabs %} {% tab title="Market data" %} BASIS ingests market-state inputs such as: * top-of-book quotes * order book snapshots and deltas * trade prints * mark prices and index prices * funding rates and open interest where relevant {% endtab %} {% tab title="Operational data" %} Operational signals are treated as first-class inputs: * withdrawal status * deposit status * API latency and error rates * throttling and rate-limit conditions * maintenance notices * settlement or transfer interruptions {% endtab %} {% tab title="On-chain data" %} Where strategy modules require it, BASIS also evaluates: * gas conditions * block congestion * confirmation latency * bridge or settlement state * wallet and contract interaction health {% endtab %} {% endtabs %} A venue registry defines which feeds are eligible and how much confidence each source receives. ## 2. Normalization Each venue exposes data differently. To make signals comparable, BASIS transforms all inputs into a canonical internal format. | Input difference | Normalization action | | -------------------------- | ------------------------------------ | | Symbol naming | Canonical symbol mapping | | Quote currency conventions | Unified quote handling | | Precision and tick size | Scaled numeric normalization | | Timestamp format | Clock alignment and drift monitoring | | Depth representation | Standardized depth ladder format | | API semantics | Common event schema | Example canonical event: ```json { "venue": "exchange_a", "symbol": "BTC-USD", "timestamp_ns": 1731045600000000000, "best_bid": 68250.10, "best_ask": 68250.45, "bid_size": 1.42, "ask_size": 0.98, "sequence": 184220991, "health_score": 0.97 } ``` Normalization reduces semantic mismatch before any opportunity model is applied. ## 3. Cross-validation and outlier rejection A single venue can publish stale, lagged, or erroneous prices. BASIS therefore applies multi-source validation before any signal reaches execution. {% stepper %} {% step %} Collect comparable observations across eligible venues. {% endstep %} {% step %} Estimate fair reference levels using robust statistics such as medians and trimmed means. {% endstep %} {% step %} Reject observations outside dynamic deviation thresholds. {% endstep %} {% step %} Require temporal consistency across successive updates. {% endstep %} {% step %} Promote only validated signals to the execution queue. {% endstep %} {% endstepper %} This process reduces the probability of trading on a ghost gap or stale book. ## 4. Venue health scoring A large spread can indicate opportunity, but it can also indicate operational stress. BASIS scores venues continuously and uses those scores as part of the eligibility gate. | Health input | Why it matters | | ----------------------- | ------------------------------------ | | Withdrawal availability | Determines settlement realism | | Deposit availability | Affects inventory mobility | | API latency | Impacts execution precision | | Error rate | Indicates feed stability | | Throttling conditions | Limits order placement reliability | | Maintenance windows | Can invalidate live pricing | | Sequence integrity | Detects missing or corrupted updates | Low health scores can down-rank or fully exclude a venue from signal generation. ## 5. Market scanning and opportunity detection After normalization and validation, the signal engine scans for executable structural alpha, including: * cross-venue price dislocations * funding and basis differentials * spot and derivative mispricings * on-chain versus off-chain valuation gaps where relevant Detection alone is not sufficient. Every candidate must also pass: * depth sufficiency checks * transfer and settlement feasibility checks * fee and slippage modeling * route construction checks * state-machine risk controls {% hint style="info" %} Trust in the signal engine comes from deterministic execution rules, mathematical constraints, and explicit state transitions. A candidate either satisfies the full rule set or it does not enter execution. {% endhint %} ## 6. Execution handoff The validated signal stream is handed to the orchestration layer only when all required constraints are satisfied: * data freshness is within tolerance * venue health is above threshold * executable depth is sufficient * modeled edge remains positive after costs * routing path is stable * risk state permits action This architecture is designed to prioritize determinism over headline spread size. ## 7. Why this matters The data pipeline is the first control surface for execution quality. If inputs are inconsistent, stale, or operationally compromised, even fast infrastructure will route bad decisions quickly. BASIS therefore treats market scanning as a constrained systems problem, not a simple spread detector. Next: read Execution Orchestration. # Execution Orchestration {% 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 %} Execution orchestration converts modeled structural alpha into realized results. At BASIS, execution quality depends on deterministic routing, math-constrained order generation, and state machine risk controls running on BHLE infrastructure. {% hint style="success" %} ⚙️ BHLE highlights * Sub-50μs internal decision latency * 100K+ OPS event throughput * Proprietary routing infrastructure * Deterministic execution controls with bounded risk transitions {% endhint %} ## What the orchestrator is responsible for A production-grade orchestrator answers four questions: | Function | Requirement | | ------------------ | ---------------------------------------------------------------- | | Signal handling | Validate that a signal remains actionable at dispatch time | | Order construction | Generate bounded orders with explicit size and slippage limits | | Routing | Send orders to the correct venue with venue-specific safeguards | | Recovery | Isolate faults, complete required hedges, and reconcile balances | ## 1. Execution lifecycle {% stepper %} {% step %} Signal detected A structural alpha opportunity is identified and checked for freshness, venue availability, and inventory constraints. {% endstep %} {% step %} Eligibility gate passed The engine validates capital allocation, venue health, transfer state, and current risk state. {% endstep %} {% step %} Orders generated The system computes order size, price bounds, hedge dependency, and maximum acceptable slippage. {% endstep %} {% step %} Orders routed Orders are routed through BHLE with venue-aware throttling, retry rules, and deterministic sequencing. {% endstep %} {% step %} Fills monitored Fill ratios, hedge completion windows, and residual exposure are tracked in real time. {% endstep %} {% step %} Positions reconciled Venue balances, partial fills, fees, and transfer dependencies are reconciled before exposure is considered closed. {% endstep %} {% step %} Results recorded Outcome data is written to reporting systems and displayed using the platform's internal USDT accounting convention. {% endstep %} {% endstepper %} ## 2. Atomic and coordinated execution {% tabs %} {% tab title="Centralized venues" %} On centralized venues, atomic execution is operational rather than literal. The objective is coordinated completion with minimal time gap between legs. Controls include: * bounded dispatch timing * hedge completion windows * fill ratio thresholds * automatic escalation when symmetry degrades {% endtab %} {% tab title="On-chain venues" %} On-chain, atomic execution can be literal when both legs execute in a single transaction with revert behavior. Controls include: * transaction-level slippage limits * deterministic calldata generation * pre-trade simulation * failure reversion when execution conditions are not met {% endtab %} {% endtabs %} The orchestrator treats these as separate execution domains with different guarantees. ## 3. Order management and fill symmetry The main source of execution loss is asymmetric completion, where one leg fills and the other does not. BASIS mitigates this with: * explicit price bounds * venue-specific slippage caps * real-time fill symmetry monitoring * hedge completion deadlines * state machine escalation when thresholds are breached {% hint style="warning" %} 🛡️ If fill symmetry falls outside policy, the engine does not continue normal routing. It transitions to a protective state, isolates the position, and executes the required unwind path. {% endhint %} ## 4. Settlement and reconciliation Reconciliation is a core control, not a back-office task. | Reconciliation layer | What is checked | | -------------------- | ------------------------------------------------------------ | | Order layer | Submitted, acknowledged, filled, canceled, expired | | Position layer | Net exposure, hedge completion, residual inventory | | Balance layer | Venue balances, pending transfers, fee deductions | | Reporting layer | Internal accounting values, realized outcome, exception logs | This loop matters because: * venue balance updates can lag * partial fills create residual exposure * settlement timing can temporarily constrain deployable capital ## 5. Failure modes and fallback behavior The orchestrator handles adverse conditions conservatively. | Failure mode | Default response | | ----------------- | --------------------------------------------------------------- | | API timeout | Stop new dispatch for the affected venue and verify order state | | Rate limiting | Degrade routing frequency and preserve hedge priority | | Venue maintenance | Quarantine the venue and reroute only if policy allows | | Volatility spike | Tighten bounds, reduce size, or halt execution | | Transfer delay | Recompute available inventory and block dependent strategies | Fallback policy is simple: ``` detect fault → freeze unsafe path → complete or unwind exposure → reconcile balances → return to normal only after policy checks pass ``` ## 6. Why this matters Execution quality is not defined only by signal quality. It depends on whether the platform can convert opportunity into realized results under real market conditions. At BASIS, that conversion is supported by: * BHLE low-latency routing * deterministic execution rules * math-constrained order sizing * state machine risk controls * continuous reconciliation across venues Next: Anti-Slippage & Order Slicing # Anti-Slippage & Order Slicing {% 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 %} Slippage is one of the primary failure modes in structural alpha capture. A platform can claim execution precision and still lose money if it cannot bound slippage under real market conditions. BASIS treats slippage control as a layered systems problem, combining deterministic execution, math constraints, and state machine risk controls. ## 1) Slippage components | Component | Meaning | Primary control | | ----------------- | ------------------------------------------------------------- | ------------------------------------------------------------------ | | Market impact | Your order consumes visible liquidity and moves the book | Size gating, depth-aware sizing, slicing rules | | Adverse selection | You interact with better-informed or faster flow | Venue scoring, toxic flow filters, strategy eligibility rules | | Latency | The market changes before the order is acknowledged or filled | BHLE routing, sub-50μs internal handling, strict cancel discipline | BASIS designs an explicit control layer for each source of execution drift. ## 2) Pre-trade slippage bounds Before sending an order, BASIS computes a conservative slippage bound using: * live order book depth * recent volatility * venue-specific execution quality * expected queue position * routing and network latency If expected slippage exceeds the available edge, the trade is rejected. ``` if expected_edge <= expected_slippage + fees: reject_trade() ``` {% hint style="warning" %} ⚠️ Core rule: when expected cost is greater than expected edge, no order should be sent. {% endhint %} This is the practical form of slippage inversion. When cost dominates opportunity, the correct action is inaction. ## 3) Order slicing For larger sizes, BASIS may split a parent order into controlled child orders and re-evaluate conditions between fills. {% tabs %} {% tab title="When slicing is used" %} * the opportunity window is sufficiently wide * hedge quality remains controlled * venue depth supports incremental execution * estimated exposure time stays within strategy limits {% endtab %} {% tab title="When slicing is not used" %} * signal half-life is too short * hedge quality deteriorates rapidly * realized slippage is already near rejection threshold * venue conditions enter a stressed regime {% endtab %} {% endtabs %} ### Iceberg concept An iceberg strategy exposes only part of the total size to the book at any given time. Benefits: * reduced signaling * lower instantaneous market impact Costs: * longer exposure time * higher risk of regime change during execution BASIS only permits slicing when these trade-offs remain favorable under risk constraints. ## 4) Price protection Orders are wrapped with explicit protection logic. {% stepper %} {% step %} Apply protective limit bounds {% endstep %} {% step %} Set time-in-force rules appropriate to the venue and strategy {% endstep %} {% step %} Cancel or replace when the market moves outside the allowed execution band {% endstep %} {% step %} Abort when fill quality degrades below threshold {% endstep %} {% endstepper %} BASIS treats no fill as preferable to a bad fill when capital preservation is the correct decision. ## 5) Post-trade analysis A reliable execution system tracks: * realized slippage distribution * fill quality by venue and asset * regime sensitivity during spikes and normal conditions * reject rates versus accepted trade outcomes * child-order behavior during slicing This data feeds directly into venue scoring, risk calibration, and future eligibility decisions. {% hint style="success" %} BHLE is the proprietary routing and execution layer behind BASIS. It is engineered for sub-50μs internal latency and 100K+ OPS. The objective is not speed alone. It is deterministic execution quality under strict risk constraints. {% endhint %} *** Next: read Risk Engine. # Risk Engine {% 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)). {% endhint %} The Risk Engine is the deterministic control layer that protects execution precision and structural alpha capture across the BASIS platform. It evaluates every proposed order before routing, monitors active positions after submission, and reconciles outcomes after completion. It operates alongside BHLE, BASIS High-Load Execution, which provides sub-50μs internal decision latency, 100K+ OPS capacity, and proprietary routing infrastructure. No order reaches a venue unless it passes the engine's eligibility gate. *** ## 1. Design model: fail closed by default The Risk Engine follows a default-deny model. Every trade begins in a rejected state and is promoted to approved only after all required checks succeed. This fail-closed design matters for three reasons: * Missing data results in rejection, not silent acceptance * New or unclassified risk conditions do not bypass controls * State transitions remain deterministic and auditable {% hint style="warning" %} If any required input is stale, unavailable, or internally inconsistent, the engine rejects the order and records the reason. {% endhint %} ``` NORMAL -> pre-trade checks pass -> route order -> monitor fills and exposure -> reconcile balances and PnL -> NORMAL NORMAL -> critical threshold breach -> BSCB -> DMM if automated recovery is insufficient ``` ## 2. Eligibility gate Before an order is submitted to any venue, the engine evaluates the following controls in sequence. | Check | What is tested | Failure action | | -------------------------- | -------------------------------------------------------------------------------------- | -------------------------------------------- | | System state | Is the platform in `NORMAL` state, with no active BSCB or DMM restriction? | Reject: system not in executable state | | Market data integrity | Are reference prices, books, and internal signals fresh and internally consistent? | Reject: invalid or stale market data | | Venue health | Is the target venue reachable, responsive, and within latency bounds? | Reject: venue health check failed | | Venue allocation | Would the order push venue concentration beyond the configured cap? | Reject: venue allocation limit reached | | Asset exposure | Would net exposure to a single asset exceed policy limits? | Reject: asset concentration limit reached | | Margin sufficiency | For leveraged legs, is there enough margin buffer above maintenance thresholds? | Reject: insufficient margin buffer | | Impact estimate | Is expected slippage and book impact within execution precision limits? | Reject: estimated impact too high | | Structural alpha viability | After fees, expected slippage, and network costs, is the expected edge still positive? | Reject: expected edge not viable after costs | | Reconciliation status | Has the most recent reconciliation completed with no unresolved discrepancy? | Reject: reconciliation lock active | ## 3. In-flight monitoring Once an order is live, the engine continues to supervise it in real time. {% tabs %} {% tab title="Positions" %} * Margin health monitoring tracks open leveraged positions against warning and critical thresholds * Hedge integrity checks verify that paired legs remain within allowed deviation bands * Exposure drift checks detect inventory changes caused by partial fills, funding, or venue-side adjustments {% endtab %} {% tab title="Orders" %} * Fill monitoring cancels or replaces stale orders that remain open beyond expected timing windows * Price protection prevents fills outside allowed impact bands during rapid market movement * Venue response monitoring detects degraded acknowledgements, rejects, or out-of-order events {% endtab %} {% tab title="Escalation" %} * Warning thresholds trigger controlled reduction logic * Critical thresholds trigger BSCB * Repeated BSCB events, unresolved reconciliation errors, or non-automatable venue anomalies escalate to DMM {% endtab %} {% endtabs %} ## 4. Post-trade reconciliation Every execution cycle ends with a mandatory reconciliation pass. {% stepper %} {% step %} #### Balance verification Venue balances are checked against the internal ledger. Any discrepancy is flagged immediately. {% endstep %} {% step %} #### PnL attribution Realized profit and loss is attributed to the originating strategy, venue, and execution path. {% endstep %} {% step %} #### Cost accounting Exchange fees, network fees, funding, borrow costs, and other direct execution costs are deducted from gross results. {% endstep %} {% step %} #### State confirmation The system confirms that all expected state transitions completed correctly before new exposure is permitted. {% endstep %} {% endstepper %} {% hint style="info" %} Reconciliation is not a reporting convenience. It is a hard risk control. If reconciliation does not complete cleanly, the engine can block new orders until the discrepancy is resolved. {% endhint %} ## 5. Relationship to BSCB and DMM The Risk Engine is the detection and decision layer. BSCB is the automated containment layer. DMM is the operator-supervised escalation layer for conditions that require discretionary review. A practical hierarchy is: * Risk Engine, detect and evaluate * BSCB, contain automatically * DMM, supervise recovery or exceptional handling ## 6. Why this matters The BASIS risk model is built around deterministic execution, explicit mathematical constraints, and state machine risk controls. This architecture supports structural alpha capture without relying on permissive routing or manual intervention during normal operation. In operational terms, the objective is simple: * approve only what is safe to execute * reject anything ambiguous * reconcile every completed action * escalate only through defined state transitions # Observability & Audit Logs {% 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 %} {% hint style="warning" %} Accounting and asset model The interface may display balances and performance in USDT as an internal accounting and USD-equivalent reference unit. USDT is not a deposit or withdrawal asset. Deposits and withdrawals use native assets only: * BTC via a unique BASIS-assigned deposit address for each account * ETH, SOL, and PAXG via a connected Web3 wallet such as MetaMask Swaps are same-token 1:1 only: * BTC → stBTC * ETH → stETH * SOL → stSOL * PAXG → stPAXG {% endhint %} A system that cannot explain its behavior under stress is not trustworthy. Observability is the discipline of instrumenting the platform so operators and users can understand why the system behaved as it did, when it changed state, and how outcomes were reconciled. For BASIS, observability must cover: * execution precision inside BHLE * structural alpha capture workflows * wallet and staking state transitions * deterministic risk controls * post-trade and user-balance reconciliation *** ## 1. The three pillars of observability {% tabs %} {% tab title="Logs" %} Logs are granular, timestamped records of discrete events. Typical examples: * `ORDER_SENT` * `ORDER_ACKNOWLEDGED` * `FILL_PARTIAL` * `STATE_TRANSITION_NORMAL_TO_BSCB` * `RECONCILIATION_PASSED` * `BTC_DEPOSIT_CONFIRMED` * `SWAP_BTC_TO_STBTC_COMPLETED` * `UNSTAKE_SETTLED_TO_STAKING_WALLET` Logs support forensic review, root-cause analysis, and audit trails. {% endtab %} {% tab title="Metrics" %} Metrics are aggregated numerical views of system health over time. Typical examples: * p50, p95, p99 routing latency * venue API latency * quote acceptance rate * fill ratio * reconciliation error count * withdrawal processing time by asset * state machine transition frequency * open exposure by asset and venue Metrics power dashboards, thresholds, and automated alerts. {% endtab %} {% tab title="Traces" %} Traces show the full lifecycle of a single workflow across components. A BASIS trace may follow: 1. market data intake 2. signal evaluation 3. eligibility gate decision 4. order submission 5. venue acknowledgement 6. fill and reconciliation 7. wallet or staking ledger update For user operations, a trace may follow deposit detection, confirmation, wallet credit, swap, stake, reward accrual, unstake, and withdrawal. {% endtab %} {% endtabs %} BASIS uses all three pillars to maintain professional operational awareness across execution, accounting, and user funds movement. *** ## 2. What must be observable The platform should capture enough detail to reconstruct both technical and economic outcomes. | Domain | Required telemetry | | --------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | | Market data and quoting | raw ticks received, normalization results, quote construction, eligibility gate outcomes, reason codes for pass or reject | | Order lifecycle | venue, asset, order size, limit or market instruction, acknowledgement, partial fill, full fill, cancel, reject, retry | | Execution quality | route selection, latency by hop, slippage distribution, fill quality, deterministic fallback activation | | Risk and state machine | all transitions between Normal, BSCB, DMM, trigger source, threshold value, exposure snapshot, margin status, liquidation guard alerts | | Reconciliation | balance deltas, fee application, PnL attribution, ledger finalization, discrepancy detection, operator resolution notes | | Infrastructure | queue depth, service saturation, packet loss, time synchronization health, dependency failures, recovery events | | User wallet activity | deposit detection, confirmation count, Funding Wallet credit, withdrawal request, approval trail, broadcast, completion | | Staking activity | same-token 1:1 swap event, stToken credit, booster selection, lock start, lock end, reward accrual, unstake settlement | | Support and account actions | authentication events, security setting changes, support case creation, account-level risk flags | *** ## 3. User-facing actions that must be auditable Observability is not limited to internal trading systems. User actions must also be reconstructable from source event to final ledger state. | Action | What must be recorded | User-visible result | | ------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------- | | BTC deposit | BASIS-assigned deposit address, transaction hash, confirmation state, minimum deposit rule check of 0.0001 BTC, Funding Wallet credit | Assets | | ETH deposit | connected wallet address, signature or authorization context, onchain tx hash, confirmation state, Funding Wallet credit | Assets | | SOL deposit | connected wallet address, tx hash, confirmation state, Funding Wallet credit | Assets | | PAXG deposit | connected wallet address, tx hash, confirmation state, Funding Wallet credit | Assets | | Same-token swap | source asset, destination stToken, 1:1 conversion, swap fee of 0.01%, timestamp, wallet movement from Funding Wallet to Staking Wallet | Assets, Stake | | Stake | pool type, asset, amount, booster term, lock schedule, final accepted position size | Stake | | Reward accrual | real-time accrual rate, reward balance in same stToken, ledger snapshots, accrual interruptions if any | Stake | | Unstake | full-position only validation, fixed-pool lock expiry validation, unstake request, settlement amount, auto-credit to Staking Wallet as stToken after the mandatory 7-day unstaking buffer | Stake, Assets | | Withdrawal | asset, destination, withdrawal fee of 0.05%, security checks, broadcast status, completion timestamp | Assets, Support | | Referral network rewards | attribution event, eligibility logic, ledger posting, settlement state | Referral | {% hint style="success" %} Wallet model * Funding Wallet holds native assets for deposit and withdrawal * Staking Wallet holds stTokens for staking and rewards * Rewards accumulate in real time as the same stToken * On unstake, the claimable amount is auto-credited to the Staking Wallet as stToken after the mandatory 7-day unstaking buffer * Fixed pools can be unstaked only after the lock-up period ends * Unstake is full-position only and auto-MAX by design {% endhint %} *** ## 4. Asset-specific monitoring expectations | Asset flow | Deposit method | Withdrawal expectation | Monitoring requirement | | ---------- | -------------------------------------- | -------------------------- | -------------------------------------------------------------------------------------- | | BTC | copy the unique BASIS-assigned address | typically 10 to 60 minutes | confirmation count, mempool visibility, final wallet credit, delayed-transfer alerting | | ETH | connect a Web3 wallet | typically 1 to 10 minutes | chain confirmation, gas status, wallet signature context, final settlement | | SOL | connect a Web3 wallet | typically 1 to 10 minutes | slot confirmation, tx finality, final wallet settlement | | PAXG | connect a Web3 wallet | typically 1 to 10 minutes | token transfer confirmation, contract event parsing, final wallet settlement | Any deviation from expected processing windows should trigger internal alerts and user-visible status updates. *** ## 5. Audit logs and integrity requirements Audit logs are a higher-assurance subset of platform logs. They must be tamper-evident, time-accurate, and reviewable. ### Core properties 1. Append-only storage\ Historical entries must not be mutable in place. 2. Cryptographic integrity\ Each record should be chained to the previous record, making unauthorized edits detectable. 3. Time synchronization\ Clock accuracy is mandatory. With BHLE operating at sub-50μs latency, timestamp drift can invalidate reconstruction. 4. Access control\ Role-based access controls must govern who can view, export, or annotate audit data. 5. Dual-scope retention\ Operational telemetry and formal audit records may have different retention classes, but both must follow documented policy. 6. Provenance\ Every material state change should identify source service, responsible actor or system identity, and before/after values. ### Minimum immutable fields ```json { "event_id": "a8a3d5f1-8f67-4c27-9f68-0f24f8f5f2b1", "trace_id": "trc_01HVQ0R6N2Y9", "recorded_at_utc": "2026-03-12T10:22:48.184291Z", "service": "wallet-ledger", "event_type": "SWAP_ETH_TO_STETH_COMPLETED", "account_id": "acc_7f24", "asset_in": "ETH", "asset_out": "stETH", "amount_in": "2.50000000", "amount_out": "2.50000000", "fee_rate": "0.0001", "wallet_from": "Funding Wallet", "wallet_to": "Staking Wallet", "state_before": "pending", "state_after": "settled", "decision_reason": "same-token-1-to-1-swap", "hash_prev": "0x8f1d...", "hash_self": "0x12ac..." } ``` *** ## 6. Why this matters for BASIS execution Observability is not only about uptime. It is also about proving execution quality under load. For BASIS, that includes: * measuring route selection quality across proprietary routing infrastructure * proving state machine transitions happened at the correct thresholds * verifying risk controls blocked invalid actions deterministically * showing reconciliation matched execution outcomes to ledger outcomes * confirming structural alpha capture logic behaved within mathematical constraints If a system claims execution precision, its logs, metrics, and traces must support that claim. *** ## 7. Incident response workflow {% stepper %} {% step %} **Detect 🔎** Automated alerts fire when latency, exposure, settlement timing, reconciliation drift, or dependency health moves outside expected bounds. {% endstep %} {% step %} **Diagnose** Operators inspect metrics, traces, and immutable logs to isolate the root cause, scope affected accounts, and determine whether a state-machine transition is required. {% endstep %} {% step %} **Contain 🛡️** If needed, the system can shift into a protective state such as BSCB or DMM, reduce exposure, restrict certain flows, or halt non-essential actions. {% endstep %} {% step %} **Communicate** Users receive clear status updates through platform status surfaces and support channels. Silence during incidents is unacceptable. {% endstep %} {% step %} **Reconcile** After recovery, all affected execution, wallet, and staking records are rechecked for ledger completeness and accounting consistency. {% endstep %} {% step %} **Review** A formal post-incident review should preserve timeline, root cause, impact, remediation, and control improvements. {% endstep %} {% endstepper %} *** ## 8. User verification surface Users should be able to inspect key events directly in the dashboard: * Stake * Assets * Referral * Support * Account At a minimum, the interface should expose: * transaction hashes where applicable * timestamps and final states * wallet movement between Funding Wallet and Staking Wallet * applied fees * lock schedules and booster terms * unstake settlement status * withdrawal progress {% hint style="info" %} Booster reference * 14D: +10% * 30D: +20% * 90D: +50% * 180D: +100% (2×) These selections and their resulting lock windows should be fully auditable. {% endhint %} *** ## 9. Standard of trust A trustworthy platform is not one that claims perfection. It is one that can show, with deterministic evidence, what happened, when it happened, why it happened, and how final balances were derived. For BASIS, observability and auditability are part of the control plane itself: * deterministic execution * math-constrained decisioning * state machine risk controls * tamper-evident logs * reconciled user balances * measurable BHLE performance That is the minimum standard for a platform handling execution, staking, and native-asset fund flows. # Security Architecture {% 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)). {% endhint %} {% hint style="info" %} Accounting convention Dashboard balances may be displayed in USDT as an internal accounting and reporting unit for USD-equivalent reference. USDT is not a depositable or withdrawable asset on BASIS. Deposits and withdrawals are supported in native assets only: * BTC * ETH * SOL * PAXG Staking balances are represented as: * stBTC * stETH * stSOL * stPAXG {% endhint %} Security on BASIS is a system property. It includes identity controls, asset segregation, deterministic execution, operational access control, third-party dependency management, and internationally certified management controls. BASIS operates with institutional-grade security and service governance aligned to internationally accredited standards. BASIS DIGITAL INFRASTRUCTURE LTD maintains active certification to ISO/IEC 27001:2022 and ISO/IEC 20000-1:2018, with public verification available through IAF CertSearch. The platform security model is designed around execution precision, structural alpha capture, and bounded state transitions. This means the system limits what can happen by design, rather than relying only on operator judgment after the fact. ## Certification and governance The BASIS control environment is supported by an active ISO/IEC 27001:2022 certification covering software design, quantitative research systems, associated IT infrastructure, and information security management. | Field | Details | | ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------- | | Certificate Number | SC62455E | | Standard | ISO/IEC 27001:2022 | | Status | Active | | Last Updated | March 27, 2026 | | Certified Entity | BASIS DIGITAL INFRASTRUCTURE LTD | | Address | Room 306, Victoria House, P.O Box 673, Victoria, Mahe, Seychelles | | Scope | The Design and Development of Software and Quantitative Research Systems and the Management of Associated IT Infrastructure and Information Security | | Accreditation | IAF (International Accreditation Forum) | | Verification | [Verify on IAF CertSearch](https://www.iafcertsearch.org/certification/VDrwBpB8mD2nw5ykj5zxSANH) | BASIS DIGITAL INFRASTRUCTURE LTD also maintains an active ISO/IEC 20000-1:2018 certification. | Standard | Certified Entity | Status | Public Verification | | -------------------- | -------------------------------- | ------ | ------------------------------------------------------------------------------------------------ | | ISO/IEC 20000-1:2018 | BASIS DIGITAL INFRASTRUCTURE LTD | Active | [Verify on IAF CertSearch](https://www.iafcertsearch.org/certification/1IbVSdVuBbykRHSgkfAo8mBE) | Certified entity record: [Entity Record on IAF CertSearch](https://www.iafcertsearch.org/certified-entity/WTmKlSOrxvhkPKrCUIdWYEgv) These certifications reinforce the BASIS operating model by placing security and service management under documented controls, formal review, and externally verifiable governance. ## 1) User authentication: passwordless OTP BASIS uses passwordless email OTP authentication. BASIS does not store user passwords. | Security property | Implementation | | ---------------------- | ----------------------------------------------------------------------------------- | | Authentication factor | 6-digit OTP sent to the registered email | | OTP validity | 10 minutes, single-use | | Concurrent sessions | Single Active Session Policy, each new login terminates the previous session | | Login notifications | Every login event generates an automated email alert with IP, device, and timestamp | | Brute force protection | Temporary lockout after 5 consecutive failed attempts | {% hint style="warning" %} User hygiene still matters * Protect your email account with a strong password and 2FA * BASIS will never ask for private keys, seed phrases, or wallet recovery phrases * Verify the domain is `basis.pro` before entering an OTP * Official email communications use `@basis.pro` addresses only {% endhint %} ``` Official web domain: basis.pro Official email domain: @basis.pro ``` ## 1.5) Execution security: BHLE and deterministic state control The Base58 Hyper-Latency Engine, or BHLE, is the execution infrastructure behind BASIS. It is engineered for deterministic routing, execution precision, and structural alpha capture under tightly bounded risk controls. Core execution characteristics: * Sub-50μs decision latency * 100K+ OPS processing capacity * Proprietary routing infrastructure * Deterministic execution paths * Math-constrained state transitions * Explicit stop conditions and circuit logic * State machine risk controls that restrict invalid or out-of-policy actions This architecture reduces discretionary behavior at the infrastructure layer. The objective is not only speed, but correctness under stress. Key security properties: * execution logic is separated from user-facing asset states * allowable actions are constrained by product rules * invalid transitions are rejected at the state-machine level * risk controls can halt routing or settlement progression when constraints are breached * structural alpha capture is pursued through deterministic routing logic, not through unrestricted operator intervention {% hint style="success" %} Why this matters A secure system should not depend on perfect human intervention. BASIS constrains the action space through deterministic rules so that wallet states, staking states, and withdrawal states remain machine-verifiable. {% endhint %} {% stepper %} {% step %} **1. Deposit to Funding Wallet** Users deposit native assets only. * BTC deposits use a unique BASIS-assigned address for each account * ETH, SOL, and PAXG deposits require a connected Web3 wallet such as MetaMask or another supported wallet * Minimum BTC deposit: 0.0001 BTC {% endstep %} {% step %} **2. Convert on a same-token basis** Swaps are same-token only and 1:1 between a native asset and its corresponding staking asset. Examples: * BTC ↔ stBTC * ETH ↔ stETH * SOL ↔ stSOL * PAXG ↔ stPAXG No cross-asset swaps are used in this flow. {% endstep %} {% step %} **3. Stake from the Staking Wallet** Staking positions are funded with stTokens only. Rewards accumulate in real time as the same stToken in the Staking Wallet. {% endstep %} {% step %} **4. Unstake under explicit rules** Unstake is full-position only. The system uses an auto-MAX model. For fixed pools, unstake is available only after the lock-up period ends. There is no early exit option. {% endstep %} {% step %} **5. Credit and withdraw** When unstake is completed, the claimable amount is auto-credited to the Staking Wallet as the same stToken. Users can then convert on a same-token 1:1 basis and withdraw the native asset from the Funding Wallet. {% endstep %} {% endstepper %} ## 2) Asset security: wallets and permissions BASIS separates wallet functions at the product level: | Wallet | Holds | Primary actions | Security role | | -------------- | ---------------------------------- | --------------------------------------------- | -------------------------------------------- | | Funding Wallet | Native assets: BTC, ETH, SOL, PAXG | Deposit, withdraw, same-token conversion | Isolates settlement and transfer activity | | Staking Wallet | stBTC, stETH, stSOL, stPAXG | Stake, earn, unstake, receive accrued rewards | Isolates earning states from transfer states | This separation is intentional. It reduces ambiguity in asset state, improves auditability, and limits the impact of invalid transitions. ### Deposit model by asset type {% tabs %} {% tab title="BTC" %} BTC deposits are made by copying the unique BASIS-assigned deposit address shown for the account. Security characteristics: * no Web3 wallet connection is required for BTC deposits * the deposit address is specific to the account * minimum deposit is 0.0001 BTC * inbound settlement is monitored before balances are credited {% endtab %} {% tab title="ETH / SOL / PAXG" %} ETH, SOL, and PAXG deposits are made by connecting a supported Web3 wallet. Security characteristics: * wallet authorization is initiated by the user * deposits move native assets into the Funding Wallet model * PAXG is live and fully supported * chain-specific settlement checks apply before balances are credited {% endtab %} {% endtabs %} ### Product state constraints | Action | Allowed behavior | | --------------- | ---------------------------------------------- | | Deposit | Native asset only | | Swap | Same-token 1:1 only | | Stake | stToken only | | Rewards | Accumulate in real time as the same stToken | | Unstake | Full position only | | Fixed pool exit | Only after lock-up ends | | Claim crediting | Auto-credited to Staking Wallet as stToken | | Withdraw | Native asset only from the Funding Wallet flow | These rules are part of the security model. By narrowing valid state transitions, BASIS reduces operational ambiguity and unauthorized path expansion. ## 3) Operational security Operational security includes: * role-based access control * environment segregation across development, staging, and production * controlled deployment pipelines * peer review and change management * monitored infrastructure and alerting * key and credential rotation policies * incident response playbooks * reconciliation and exception handling procedures These controls are supported by BASIS's certified management systems for information security and IT service management. In practice, this means security and service operations are governed through documented controls, repeatable processes, and auditable oversight aligned with ISO/IEC 27001:2022 and ISO/IEC 20000-1:2018. The ISO/IEC 27001:2022 certification for BASIS DIGITAL INFRASTRUCTURE LTD is publicly verifiable under certificate number SC62455E. BASIS also uses deterministic operational parameters so user-facing asset behavior is predictable and not manually repriced on a case-by-case basis. | Operational parameter | Rule | | -------------------------------- | -------------------------- | | Deposit fee | 0% | | Withdrawal fee | 0.05% | | Swap fee | 0.01% | | BTC withdrawal time | Typically 10 to 60 minutes | | ETH / SOL / PAXG withdrawal time | Typically 1 to 10 minutes | Fixed pools add another safety boundary. Positions cannot be exited before maturity, which prevents unsupported state changes during the lock period. ## 4) Third-party security BASIS depends on external infrastructure for parts of settlement and execution, including: * liquidity venues and exchanges * public blockchain networks * wallet providers for supported chains * token issuers and settlement rails, including PAXG infrastructure * market data and routing dependencies Third-party risk controls include: * venue risk scoring * exposure limits * fragmented liquidity sourcing * monitored routing quality * network health checks * explicit stop conditions when settlement or market quality falls below policy thresholds Security on BASIS does not assume that third parties are always healthy. It assumes that dependencies can degrade and that system behavior must remain bounded when they do. ## 5) What security cannot guarantee Security architecture lowers the probability of certain failures. It does not eliminate: * exchange insolvency or counterparty failure * blockchain congestion, halts, or reorgs * market dislocations and liquidity gaps * external issuer or settlement risk, including PAXG-related dependencies * reference pricing deviations in external markets, including USDT as a display benchmark The practical objective is resilience, not invulnerability. BASIS combines deterministic execution, math constraints, explicit stop logic, state machine risk controls, and internationally certified security and service management practices to keep failure modes bounded and observable. *** Next: read Audits & Responsible Disclosure. # Audits & Responsible Disclosure {% 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)). {% endhint %} BASIS documents how its systems are reviewed, how vulnerabilities are reported, and how material changes are disclosed. This includes on-chain components where applicable, custody workflows, platform infrastructure, and the BHLE execution environment used for structural alpha capture. As part of its control framework, BASIS operates within internationally accredited management systems for information security and IT service management, supporting an institutional-grade approach to governance, change control, and operational resilience. ## Current audit status BASIS maintains a continuous security review program across smart contract surfaces, custody controls, platform infrastructure, and the execution stack. Independent external review is combined with internal control testing, remediation tracking, and release gating. This review program operates alongside BASIS's active ISO/IEC 27001:2022 and ISO/IEC 20000-1:2018 certifications, reinforcing a structured approach to security governance, service operations, and controlled change management. {% tabs %} {% tab title="Execution systems" %} Review scope includes the BHLE execution layer, sub-50μs latency targets, 100K+ OPS throughput assumptions, proprietary routing infrastructure, API authentication, deterministic execution guarantees, and state machine risk controls. {% endtab %} {% tab title="On-chain components" %} Where BASIS deploys on-chain logic, review scope includes staking token accounting, mint and burn permissions, reward distribution, same-token swap logic, access controls, upgrade paths, and pause conditions. {% endtab %} {% tab title="Custody and key management" %} Review scope includes key generation, storage boundaries, approval workflows, withdrawal controls, segregation of duties, and incident response procedures. {% endtab %} {% tab title="Infrastructure and operations" %} Review scope includes deployment pipelines, secrets handling, monitoring, logging integrity, network controls, penetration testing, backup recovery, and operational resilience. {% endtab %} {% endtabs %} Audit reports, executive summaries, and remediation notes are published when release does not create unnecessary attack surface. Where redaction is required for operational safety, BASIS will still disclose scope, findings class, and remediation status. ## 1. Smart contract audits When BASIS deploys externally accessible contracts, the minimum disclosure standard includes: * independent third-party review * contract scope and version disclosure * severity classification of findings * remediation status and change log * explicit statement when a feature is off-chain and outside contract scope If a product flow has no user-facing on-chain contract exposure, BASIS states that directly. ## 2. Infrastructure and operational audits Security review is not limited to contracts. BASIS also reviews the systems that support deterministic execution and fund safety. These reviews are supported by formal management processes consistent with BASIS's internationally accredited ISO/IEC 27001:2022 and ISO/IEC 20000-1:2018 certifications. | Area | Control focus | | ------------------- | ---------------------------------------------------------------------- | | Access control | Least privilege, role separation, approval boundaries | | Key management | Generation, storage, rotation, withdrawal authorization | | Execution integrity | Deterministic routing behavior, math constraints, state machine checks | | API security | Authentication, rate limiting, replay protection, permission scoping | | Release management | Staged deployment, rollback paths, change approval, audit trail | | Resilience | Monitoring, alerting, incident drills, backup recovery | {% hint style="warning" %} Certain operational details remain confidential, including venue-level routing specifics and environment-specific security configurations. Policy-level controls, review scope, certification status, and material user-impacting changes remain public. {% endhint %} ## 3. Responsible disclosure Security contact: If the issue involves legal process, privacy, or sanctions exposure, copy . {% stepper %} {% step %} Send an email to with the subject line shown below. {% endstep %} {% step %} Describe the affected component, impact, and reproduction steps. Include logs, transaction hashes, screenshots, or proof-of-concept material where relevant. {% endstep %} {% step %} Avoid actions that could harm users, degrade service, access private data, or move funds without written authorization. {% endstep %} {% step %} Wait for triage guidance before expanding testing against production systems. {% endstep %} {% endstepper %} {% hint style="warning" %} **Security Disclosure Submission** To report a vulnerability, email with the following: * **Subject:** \[SECURITY DISCLOSURE] Brief issue title * Affected component or endpoint * Description of the issue * Steps to reproduce * Potential impact * Your contact details (optional) {% endhint %} ### Timeline commitments | Stage | Target | | ------------------------------------------ | ----------------------- | | Acknowledgment | Within 2 business days | | Initial triage | Within 5 business days | | Remediation timeline or next-action update | Within 10 business days | Good-faith researchers who act within this policy, avoid user harm, and report issues privately will be handled through a coordinated disclosure process. BASIS is evaluating a formal bug bounty program as part of its ongoing security roadmap. ## 4. Transparency and confidentiality BASIS aims for policy transparency without exposing live attack surfaces. Publicly disclosable items include: * audit scope * findings categories and remediation status * security policies * material operational changes * incident postmortem summaries where appropriate * publicly verifiable certification status for internationally accredited management systems Operationally sensitive items that may remain confidential include: * venue allocation details * low-level routing heuristics for structural alpha capture * specific infrastructure topologies * environment-specific hardening details ## 5. Change control For any critical change to user-impacting rules or risk controls, BASIS documents: * effective date * rationale * affected systems or products * backward compatibility notes * user action required, if any At minimum, this applies to changes involving: * fees, including the current baseline of deposit 0%, withdrawal 0.05%, and swap 0.01% * withdrawal processing rules and security holds * staking eligibility or reward accounting * fixed-pool lock-up behavior * same-token 1:1 swap mechanics * execution constraints and risk-trigger logic {% hint style="success" %} Security at BASIS is an ongoing control function. Trust comes from deterministic execution, constrained system design, reviewable changes, evidence-backed operations, and internationally accredited management systems that are publicly verifiable. {% endhint %} ## 6. Certification disclosure BASIS integrates certification status directly into its security and operational governance model. The active ISO/IEC 27001:2022 certification below provides public evidence that BASIS DIGITAL INFRASTRUCTURE LTD operates an internationally accredited Information Security Management System covering software development, quantitative research systems, associated IT infrastructure, and information security management. ### ISO/IEC 27001:2022 certification details | Field | Details | | ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------- | | Certificate Number | SC62455E | | Standard | ISO/IEC 27001:2022 | | Status | Active | | Last Updated | March 27, 2026 | | Certified Entity | BASIS DIGITAL INFRASTRUCTURE LTD | | Address | Room 306, Victoria House, P.O Box 673, Victoria, Mahe, Seychelles | | Scope | The Design and Development of Software and Quantitative Research Systems and the Management of Associated IT Infrastructure and Information Security | | Accreditation | IAF (International Accreditation Forum) | | Verification | [Verify on IAF CertSearch](https://www.iafcertsearch.org/certification/VDrwBpB8mD2nw5ykj5zxSANH) | BASIS DIGITAL INFRASTRUCTURE LTD also maintains an active ISO/IEC 20000-1:2018 certification for IT Service Management. Together, these internationally accredited certifications support BASIS's institutional-grade operating model and provide independent confirmation that key information security and service management processes are governed under internationally recognized standards. | Record | Details | Verification | | ----------------------- | ---------------------------------------- | ---------------------------------------------------------------------------------------------------------- | | ISO/IEC 20000-1:2018 | BASIS DIGITAL INFRASTRUCTURE LTD, Active | [Verify on IAF CertSearch](https://www.iafcertsearch.org/certification/1IbVSdVuBbykRHSgkfAo8mBE) | | Certified entity record | BASIS DIGITAL INFRASTRUCTURE LTD | [Entity Record on IAF CertSearch](https://www.iafcertsearch.org/certified-entity/WTmKlSOrxvhkPKrCUIdWYEgv) | Public certification records can be reviewed directly on IAF CertSearch. *** ## Compliance Certifications BASIS has obtained third-party compliance certifications verifiable through the SE Registrar certificate verification portal. ### SOC Compliance Certificate | Field | Detail | | ----------------- | --------------------------------------------------------- | | Certificate ID | `6489580/COC/SC` | | Certificate Type | Certificate of Compliance | | Issuing Authority | SE Registrar | | Verification | [Verify](https://seregistrar.us/verify-your-certificate/) | ### GDPR Compliance Certificate | Field | Detail | | ----------------- | --------------------------------------------------------- | | Certificate ID | `6489581/COC/SC` | | Certificate Type | Certificate of Compliance | | Issuing Authority | SE Registrar | | Verification | [Verify](https://seregistrar.us/verify-your-certificate/) | These certifications reflect BASIS's commitment to data protection, operational security, and regulatory compliance standards applicable to institutional-grade financial infrastructure. # Incident Response & Business Continuity {% 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)). {% endhint %} {% hint style="warning" %} Accounting convention: Portfolio values may be displayed in USDT as an internal accounting and display unit only. USDT is not depositable or withdrawable on BASIS. Supported native asset flows are BTC, ETH, SOL, and PAXG. BTC deposits use a unique BASIS-assigned address for each account. ETH, SOL, and PAXG deposits use a connected Web3 wallet. See [Risk Disclosure](https://docs.basis.pro/risk-safety-and-asset-protection/risk-disclosure). {% endhint %} This page explains how BASIS detects incidents, constrains risk, preserves asset integrity, and restores normal operation. It also describes what users see across Stake, Assets, Support, and Account during an event. ## Incident classification | Severity | Definition | Example | Response initiation | | ------------ | ----------------------------------------------------------------------- | -------------------------------------- | --------------------------------------------------- | | P1, Critical | Asset integrity at immediate risk or core platform inoperable | Venue insolvency, BHLE cluster failure | < 5 minutes automated, < 15 minutes operator review | | P2, High | Material degradation, structural alpha capture paused on affected flows | API failure cascade, BSCB trigger | < 15 minutes automated | | P3, Medium | Partial degradation with isolated impact | Single venue maintenance window | < 1 hour automated | | P4, Low | Non-critical alert with no direct asset risk | Elevated latency, minor fee anomaly | < 4 hours | ## Response state model {% hint style="warning" %} **Operating State Cycle** NORMAL → BSCB\_ACTIVE → DMM\_ACTIVE → RECOVERY → NORMAL {% endhint %} * NORMAL: All supported operations run within standard constraints. * BSCB\_ACTIVE: Risk-increasing actions are restricted while the system validates market and ledger conditions. * DMM\_ACTIVE: Defensive reduction logic can be applied to limit risk and control market impact. * RECOVERY: Reconciliation completes, queued actions drain, and normal routing resumes. ## Venue failure response {% stepper %} {% step %} **1. Detection** BHLE continuously measures venue health. If 3 consecutive calls fail, the venue is marked degraded. Detection target is under 1 second. {% endstep %} {% step %} **2. BSCB activation** The BASIS Safety Circuit Breaker blocks new risk-increasing actions on the affected venue. Existing positions are not force-closed automatically unless a higher-priority risk rule requires reduction. {% endstep %} {% step %} **3. Constrained reallocation** Capital can be reallocated to healthy venues only if execution precision remains within model limits for depth, slippage, and state transition safety. {% endstep %} {% step %} **4. Revalidation** BHLE continues polling the degraded venue. After 3 consecutive successful responses and clean ledger checks, the venue can return to the active pool. {% endstep %} {% step %} **5. Reconciliation and audit** Fill records, balances, funding entries, and internal state transitions are reconciled against BHLE logs. Any mismatch is escalated. {% endstep %} {% endstepper %} ## BSCB trigger conditions The BSCB activates automatically when any threshold below is breached. | Trigger | Threshold | | ------------------------- | --------------------------------------------------- | | API failure | More than 3 consecutive failed calls to any venue | | Execution anomaly | More than 3x predicted slippage at execution | | Margin ratio | Below 150% on any open position | | Settlement unit deviation | More than 1.5% deviation from reference | | Reconciliation failure | Any mismatch between BHLE records and venue balance | | Volatility spike | More than 4x the 1-hour average volatility | When BSCB activates: * New position openings are paused on affected routes * Same-token 1:1 swaps into affected pools can be temporarily restricted * Reward accumulation can pause for affected pools * Existing positions are held or reduced only by rule set * The system enters continuous monitoring mode * Operator review begins for P1 and P2 paths If conditions persist or worsen, the system escalates to DMM. ## DMM, Defensive Market Mode DMM is a controlled risk state, not a panic shutdown. In DMM: * Positions may be reduced gradually to limit risk * Execution remains constrained by deterministic sizing and market impact limits * User withdrawals may queue until asset and ledger checks clear * Matured unstake requests may be delayed while reconciliation completes * Fixed pools remain locked until the lock-up period ends, with no early exit option ## What users experience during an incident {% tabs %} {% tab title="Normal" %} * Funding Wallet supports native asset deposits and withdrawals for BTC, ETH, SOL, and PAXG * BTC deposits use the BASIS-assigned address for the account * ETH, SOL, and PAXG deposits use a connected Web3 wallet * Same-token swaps are 1:1 only, BTC→stBTC, ETH→stETH, SOL→stSOL, PAXG→stPAXG * Rewards accumulate in real time as the same stToken in the Staking Wallet * Unstake is always full-position only, with auto-MAX behavior * Upon unstake, the matured position and accumulated rewards are auto-credited to the Staking Wallet as stToken * Fixed pools can be unstaked only after the lock-up period ends * Standard withdrawal timing is 10 to 60 minutes for BTC and 1 to 10 minutes for ETH, SOL, and PAXG {% endtab %} {% tab title="BSCB Active" %} * Existing positions remain protected by circuit breaker logic * New staking or same-token swaps into affected pools may be paused * Reward accumulation may pause for affected pools * Funding Wallet withdrawals can move into a review queue * Dashboard status banners appear in Stake, Assets, Support, and Account * Native asset balances remain visible, with USDT shown only as a display unit {% endtab %} {% tab title="DMM Active" %} * Controlled position reduction may be in progress * Matured unstake requests may remain queued until risk checks complete * Fixed pools remain locked until maturity, with no early exit * Withdrawal times may exceed normal targets * Support updates continue through the dashboard incident banner and official notices {% endtab %} {% tab title="Recovery" %} * Normal routing resumes after venue, ledger, and state checks pass * Reward accumulation restarts for recovered pools * Queued withdrawals and matured unstake requests are processed * Dashboard status changes to recovered, with an incident reference where applicable {% endtab %} {% endtabs %} {% hint style="info" %} Operational constants during normal service remain unchanged by incident policy: deposit fee 0%, withdrawal fee 0.05%, swap fee 0.01%. USDT remains a display unit only. {% endhint %} ## BHLE hardware failure and N+1 failover BHLE runs on N+1 bare-metal capacity. For every N active nodes, at least one standby node is reserved for failover. Failover flow: 1. Heartbeat monitoring detects a non-responsive node in under 1 second 2. A standby node assumes the active role using the last committed deterministic state snapshot 3. In-flight orders reconcile against venue fill records 4. Any ledger mismatch escalates immediately to P1 review 5. Target end-to-end failover time is under 30 seconds Asset movement authority does not expand during failover. Transfer permissions remain constrained by the same authorization state machine, withdrawal policy, and ledger consistency checks. ## Recovery targets | Metric | Target | | ----------------------------------- | --------------- | | BSCB trigger to automated response | < 15 minutes | | P1 incident to user notification | < 15 minutes | | P1 incident to full recovery | < 4 hours | | Post-incident reconciliation report | Within 48 hours | | Public incident disclosure | Within 72 hours | ## Post-incident reporting After any P1 or P2 incident, BASIS publishes: 1. Timeline, including detection, containment, and recovery checkpoints 2. Root cause, including system, venue, or market failure source 3. Impact, including affected users, asset exposure, and realized loss if any 4. Remediation, including rule changes, infrastructure changes, or control hardening 5. Audit trail excerpts, redacted where required for security, showing position and balance reconciliation Reports are published in the platform dashboard and linked from [Audits & Responsible Disclosure](/technical-architecture/audits-and-disclosure). ## See also * [BSCB Circuit Breaker](https://docs.basis.pro/technical-architecture/bscb-circuit-breaker) * [Security Architecture](/technical-architecture/security-architecture) * [Audits & Responsible Disclosure](/technical-architecture/audits-and-disclosure) # Institutional API Guide {% 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)). {% endhint %} ## 1. Overview The BASIS Institutional API provides programmatic access to account state, asset balances, staking workflows, reward accrual, withdrawals, order routing, reporting, and configurable risk controls. It is designed for institutions that require deterministic integration patterns, high-throughput messaging, and auditable operational workflows. This API is intended for: * Hedge funds * Trading desks * Custodians * Market-makers * Treasury teams operating managed digital asset balances Key capabilities include: * Account and balance retrieval * Staking lifecycle management for BTC, ETH, SOL, and PAXG * Reward reporting and historical accrual access * Programmatic withdrawals to approved destinations * Order submission and status retrieval for execution workflows * Risk policy configuration through authenticated control endpoints * Webhooks for low-latency downstream automation * Immutable reporting and audit root retrieval BHLE, the BASIS high-liquidity execution layer, is the infrastructure core behind the institutional stack. It delivers sub-50μs internal processing latency and sustains 100,000+ OPS for account events, risk checks, routing optimization, and ledger writes. Supported staking booster tenors: | Booster | Bonus | | ------- | ---------- | | 14D | +10% | | 30D | +20% | | 90D | +50% | | 180D | +100% (2x) | Asset support is limited to BTC, ETH, SOL, and PAXG. PAXG is live and active. USDT is internal accounting only and cannot be deposited or withdrawn. ## 2. API Availability and Authentication ### 2.1 Base URL `https://api.basis.pro/v1/` Production conventions: * Transport: HTTPS over TLS 1.3 * Payload format: `application/json` * Response timestamps: ISO 8601 UTC * Authentication timestamp header: Unix milliseconds UTC * Decimal amounts: serialized as strings to preserve precision * State-changing requests: should include `Idempotency-Key` ### 2.2 Versioning policy BASIS uses path-based major versioning. * Current major version: `v1` * Non-breaking additions, such as new response fields or new optional request fields, may be introduced within `v1` * Breaking changes are released under a new major path such as `v2` * Deprecated fields remain supported for a minimum of 90 days after formal notice * Institutional clients with dedicated environments receive change notices before breaking upgrades * Clients should ignore unknown response fields to remain forward compatible ### 2.3 Authentication Flow Each request must be signed with HMAC-SHA256 and include the exact headers below: * `X-BASIS-KEY` * `X-BASIS-TIMESTAMP` * `X-BASIS-SIGNATURE` Recommended additional headers: * `Content-Type: application/json` * `Idempotency-Key: ` for `POST` and `PUT` operations Authentication flow: 1. Provision an institutional API key with the required scopes. 2. Bind source IP addresses and enable mTLS if required by your onboarding profile. 3. Generate a Unix millisecond timestamp. 4. Create the request body exactly as transmitted. 5. Compute the SHA-256 hash of the raw body bytes. For empty bodies, hash the empty string. 6. Build the canonical string as: * `timestamp + "\n" + method + "\n" + path_with_query + "\n" + body_sha256_hex` 7. Sign the canonical string with HMAC-SHA256 using your API secret. 8. Send the lowercase hex digest in `X-BASIS-SIGNATURE`. Exact header example: ``` X-BASIS-KEY: bas_live_inst_01HZW6YF9C8P X-BASIS-TIMESTAMP: 1774274521123 X-BASIS-SIGNATURE: 3b7be6d8b0f8f1e4d6d2c9988f41cc9a90cf1f376727233c45f7f0db2a53d9b9 Content-Type: application/json Idempotency-Key: 2df7d6f5-c4f0-4627-bf86-4d01c4f0f4be ``` Validation rules on the server side: * Timestamp skew tolerance: ±30 seconds * Signature must match the raw request body and exact path with query string * API key must have the required scope * Source IP must match whitelist if enabled * mTLS certificate must be valid if enforced for the key HMAC-SHA256 pseudocode: ``` timestamp = unix_ms() method = "POST" path_with_query = "/v1/stake" body = json_encode(request_body) body_sha256_hex = sha256_hex(body) canonical = timestamp + "\n" + method + "\n" + path_with_query + "\n" + body_sha256_hex signature = hmac_sha256_hex(api_secret, canonical) headers = { "X-BASIS-KEY": api_key_id, "X-BASIS-TIMESTAMP": timestamp, "X-BASIS-SIGNATURE": signature, "Content-Type": "application/json", "Idempotency-Key": uuid_v4() } ``` ### 2.4 Rate Limits Rate limits apply per API key and are enforced over rolling one-second windows. | Tier | Sustained Limit | Recommended Use | | ------- | --------------- | ------------------------------------------------------------ | | Default | 100 rps | Reporting, treasury ops, standard automation | | Premium | 500 rps | Active routing, market-making, high-frequency reconciliation | Rate limit headers: * `X-RateLimit-Limit` * `X-RateLimit-Remaining` * `X-RateLimit-Reset` When a client exceeds the limit, the API returns `429 Too Many Requests`. ### 2.5 Security Features BASIS supports institutional-grade controls at the transport, credential, and policy layers. * IP whitelisting: restrict access to approved source ranges * mTLS: optional or mandatory based on your integration profile * Role-scoped keys: issue least-privilege keys such as `balance:read`, `stake:write`, or `reports:read` * Key rotation: rotate credentials through `POST /auth/rotate` * Idempotency support: protects state-changing requests from replay on network retries * Immutable request tracing: all authenticated actions are mapped to request IDs and retained in the audit trail * Destination controls: withdrawals can be restricted to approved addresses only ## 3. Endpoint Reference | Path | Method | Description | Auth Scope | | --------------------- | ------ | --------------------------------------------------------------------------------------------- | ------------------ | | `/account` | GET | Return institution profile, account identifiers, enabled products, and custody policy summary | `account:read` | | `/balance` | GET | Return available, locked, staked, and pending balances by asset | `balance:read` | | `/stake` | POST | Create a staking instruction with optional booster tenor | `stake:write` | | `/unstake` | POST | Request full position release from an active stake (full position only) | `stake:write` | | `/rewards` | GET | List accrued and settled rewards by asset and date range | `rewards:read` | | `/withdrawal` | POST | Create a withdrawal request to an approved destination | `withdrawal:write` | | `/withdrawal/{id}` | GET | Return withdrawal status, fee, approval state, and network transaction details | `withdrawal:read` | | `/orders` | POST | Submit an execution instruction with routing optimization parameters | `orders:write` | | `/orders` | GET | List or filter orders by asset, status, and time range | `orders:read` | | `/reports/statement` | POST | Generate account statements in JSON, CSV, or FIXML | `reports:read` | | `/reports/audit-root` | GET | Return Merkle root and timestamp evidence for a reporting interval | `reports:read` | | `/auth/rotate` | POST | Rotate an API key and return successor key metadata | `auth:admin` | | `/risk/config` | GET | Read active risk controls and thresholds | `risk:read` | | `/risk/config` | PUT | Update BSCB, DMM, and position monitor thresholds | `risk:write` | | `/webhooks` | POST | Register or update webhook destinations and event subscriptions | `webhooks:write` | | `/webhooks` | GET | List active webhook endpoints and subscribed event types | `webhooks:read` | Common success envelope: | Field | Type | Description | | ------------- | ------ | ---------------------------------------------------- | | `request_id` | string | Server-generated trace identifier | | `server_time` | string | ISO 8601 UTC timestamp | | `status` | string | `ok`, `accepted`, or endpoint-specific success state | | `data` | object | Endpoint payload | Common error envelope: | Field | Type | Description | | --------------- | ------ | -------------------------------------- | | `request_id` | string | Trace identifier for support and audit | | `server_time` | string | ISO 8601 UTC timestamp | | `status` | string | `error` | | `error.code` | string | Machine-readable error code | | `error.message` | string | Human-readable summary | | `error.details` | object | Optional field-level detail | Common HTTP statuses: | Status | Meaning | | ------ | -------------------------------------------- | | `200` | Request completed successfully | | `201` | Resource created | | `202` | Request accepted for asynchronous processing | | `400` | Validation error | | `401` | Authentication failed | | `403` | Scope or policy denied | | `404` | Resource not found | | `409` | State conflict or idempotency collision | | `429` | Rate limit exceeded | | `500` | Internal service error | | `503` | Temporary service degradation | ## 4. Request and Response Examples All numeric amounts are represented as strings. For `GET` endpoints, the request JSON below represents query parameters. ### 4.1 GET /balance Request JSON: ```json { "include_locked": true, "include_valuation": true, "valuation_currency": "USD" } ``` Response JSON: ```json { "request_id": "req_01JV7CPEA7CVY2H2QF4M1P9Q8V", "server_time": "2026-03-23T14:00:01.104Z", "status": "ok", "data": { "account_id": "acc_inst_00127", "valuation_currency": "USD", "balances": [ { "asset": "BTC", "available": "12.54000000", "locked": "0.75000000", "staked": "8.00000000", "pending_withdrawal": "0.00000000", "usd_value": "1073760.54" }, { "asset": "ETH", "available": "185.25000000", "locked": "10.00000000", "staked": "60.00000000", "pending_withdrawal": "0.00000000", "usd_value": "654922.75" }, { "asset": "SOL", "available": "4200.00000000", "locked": "0.00000000", "staked": "1500.00000000", "pending_withdrawal": "25.00000000", "usd_value": "769500.00" }, { "asset": "PAXG", "available": "95.50000000", "locked": "0.00000000", "staked": "20.00000000", "pending_withdrawal": "0.00000000", "usd_value": "440267.50" } ], "totals": { "usd_value": "2938450.79" } } } ``` ### 4.2 POST /stake Example: staking BTC with a 90D booster Request JSON: ```json { "asset": "BTC", "amount": "2.50000000", "booster": "90D", "auto_renew": true, "source_account": "main", "client_reference": "fund-alpha-btc-20260323-01" } ``` Response JSON: ```json { "request_id": "req_01JV7CQ3W3TYZXAH6M0M5CGY0B", "server_time": "2026-03-23T14:02:11.284Z", "status": "accepted", "data": { "stake_id": "stk_01JV7CQ3X8A4JH4G4CNQ8PX4MZ", "asset": "BTC", "amount": "2.50000000", "booster": "90D", "term_days": 90, "booster_bonus_pct": "50", "base_reward_rate_apr": "0.0600", "effective_reward_rate_apr": "0.0900", "auto_renew": true, "source_account": "main", "status": "pending_settlement", "submitted_at": "2026-03-23T14:02:11.284Z", "expected_settlement_at": "2026-03-23T14:02:12.000Z", "maturity_at": "2026-06-21T14:02:12.000Z", "client_reference": "fund-alpha-btc-20260323-01" } } ``` ### 4.3 POST /unstake Request JSON: ```json { "stake_id": "stk_01JV7CQ3X8A4JH4G4CNQ8PX4MZ", "amount": "2.50000000", "destination_account": "main", "client_reference": "fund-alpha-unstake-20260323-01" } ``` Response JSON: ```json { "request_id": "req_01JV7CRSH3E0HDKRE98VP4EF0N", "server_time": "2026-03-23T14:05:08.440Z", "status": "accepted", "data": { "unstake_id": "ustk_01JV7CRSJ3QBV3R9N9R4N2ZZ6K", "stake_id": "stk_01JV7CQ3X8A4JH4G4CNQ8PX4MZ", "asset": "BTC", "amount": "2.50000000", "destination_account": "main", "status": "queued", "submitted_at": "2026-03-23T14:05:08.440Z", "request_accepted_at": "2026-03-23T14:05:12.000Z", "estimated_settlement_at": "2026-03-30T14:05:12.000Z", "client_reference": "fund-alpha-unstake-20260323-01" } } ``` ### 4.4 GET /rewards Request JSON: ```json { "asset": "BTC", "from": "2026-03-01", "to": "2026-03-23", "granularity": "daily" } ``` Response JSON: ```json { "request_id": "req_01JV7CT2N9M43ZV3VJYJTRTH0T", "server_time": "2026-03-23T14:08:33.015Z", "status": "ok", "data": { "account_id": "acc_inst_00127", "asset": "BTC", "from": "2026-03-01", "to": "2026-03-23", "granularity": "daily", "rewards": [ { "date": "2026-03-21", "accrued": "0.00041000", "settled": "0.00000000", "status": "accrued" }, { "date": "2026-03-22", "accrued": "0.00041200", "settled": "0.00000000", "status": "accrued" }, { "date": "2026-03-23", "accrued": "0.00041500", "settled": "0.00000000", "status": "accrued" } ], "totals": { "accrued": "0.00984200", "settled": "0.00000000", "usd_value": "842.11" } } } ``` ### 4.5 POST /withdrawal Request JSON: ```json { "asset": "BTC", "amount": "0.75000000", "network": "BTC", "address": "bc1qxy2kgdygjrsqtzq2n0yrf2493p83kkfjhx0wlh", "memo": null, "source_account": "main", "client_reference": "fund-alpha-wd-20260323-01" } ``` Response JSON: ```json { "request_id": "req_01JV7CVTRKW7ZW7A6N3PZQ50JD", "server_time": "2026-03-23T14:11:27.889Z", "status": "accepted", "data": { "withdrawal_id": "wd_01JV7CVTTFM7F8XMNZY6T2RD7F", "asset": "BTC", "amount": "0.75000000", "network": "BTC", "address": "bc1qxy2kgdygjrsqtzq2n0yrf2493p83kkfjhx0wlh", "fee_estimate": "0.00012000", "net_amount_estimate": "0.74988000", "status": "pending_authorization", "source_account": "main", "created_at": "2026-03-23T14:11:27.889Z", "estimated_completion_seconds": 45, "client_reference": "fund-alpha-wd-20260323-01" } } ``` ## 5. Webhooks and Callbacks BASIS webhooks provide low-latency event delivery to client systems for reconciliation, treasury movement, reward accounting, and downstream execution workflows. Event payload shape: ```json { "event_id": "evt_01JV7CXR1XKJ59EBB2SY6P1P0W", "type": "stake.settled", "created_at": "2026-03-23T14:13:05.121Z", "account_id": "acc_inst_00127", "data": { "stake_id": "stk_01JV7CQ3X8A4JH4G4CNQ8PX4MZ", "asset": "BTC", "amount": "2.50000000", "status": "settled" } } ``` Event types: | Event Type | Trigger | Core Data | | ----------------- | ------------------------------------------------------------------------------------ | -------------------------------------------------------------- | | `balance.update` | Any confirmed balance state change | `asset`, `available`, `locked`, `staked`, `pending_withdrawal` | | `stake.settled` | Stake instruction reaches settled state | `stake_id`, `asset`, `amount`, `status`, `maturity_at` | | `reward.accrued` | Reward accrual is posted to the account ledger | `asset`, `accrued`, `period_start`, `period_end` | | `unstake.settled` | Unstake instruction completes the 7-day buffer and is credited to the Staking Wallet | `unstake_id`, `asset`, `amount`, `status` | | `withdrawal` | Withdrawal state changes through its lifecycle | `withdrawal_id`, `asset`, `amount`, `status`, `tx_hash` | Signature verification: * Each webhook includes `X-BASIS-WH-SIG` * Compute HMAC-SHA256 over the raw request body using the webhook secret configured at registration * Compare the resulting lowercase hex digest to `X-BASIS-WH-SIG` using a constant-time comparison * Deduplicate using `event_id` Verification pseudocode: ``` raw_body = request_body_bytes expected_sig = hmac_sha256_hex(webhook_secret, raw_body) provided_sig = header("X-BASIS-WH-SIG") if !constant_time_equals(expected_sig, provided_sig): reject_request() ``` Delivery guarantees: * Delivery model: at-least-once * Acknowledgement rule: any `2xx` response marks the event delivered * Retry strategy: exponential back-off on non-`2xx` responses or connection failure * Retry window: up to 24 hours * Ordering: best effort per destination, not guaranteed across event types * Consumer requirement: webhook handlers should be idempotent Webhook registration endpoint: `POST /webhooks` Registration payload fields: * `url`: your HTTPS endpoint * `events`: array of event types * `secret`: shared signing secret * `active`: boolean flag ## 6. Execution Infrastructure BHLE is the execution and settlement fabric that sits behind institutional API traffic. It is optimized for deterministic routing, pre-trade control enforcement, ledger consistency, and fast acknowledgement paths. BHLE architecture overview: * Gateway layer for authenticated HTTP and FIX ingress * Deterministic pre-trade and pre-withdrawal policy checks * In-memory state engine for balances, locks, and exposure views * Routing optimization layer for order and conversion instructions * Append-only ledger writer for settlement state * Replicated audit stream for reporting and reconciliation * Sub-50μs internal processing latency * Sustained throughput above 100,000+ OPS Co-location and institutional connectivity: * Dual-site co-location topology is available for approved institutional clients * Equinix cross-connect connectivity is supported for private low-latency access * FIX 4.4 sessions are available for clients that prefer standardized order flow and drop copy patterns * Site-level provisioning details are shared during onboarding Connectivity modes: | Mode | Transport | Typical Gateway Latency | Best Use Case | | --------------- | --------------------------- | ------------------------------ | --------------------------------------------------- | | Public Internet | HTTPS over TLS 1.3 | 2 ms to 30 ms path-dependent | Treasury operations, reporting, standard automation | | Cross-connect | Private circuit via Equinix | 250μs to 900μs typical | Active execution, low-latency reconciliation | | FIX-over-TLS | FIX 4.4 over TLS | Acknowledgement under 1 ms p99 | Trading desks, market-makers, drop copy | Latency figures represent BASIS edge behavior under normal operating conditions and exclude client-side network variance. Atomic clock synchronization: * Gateway, engine, and ledger events are stamped against atomic-clock synchronized UTC sources * Timestamp ordering is preserved across API events, webhooks, reports, and FIX sessions * Time synchronization supports deterministic reconciliation and precise audit sequencing ## 7. Supported Assets | Asset | Native Deposit | Staking Token | Min Stake | Withdrawal Network | | ----- | -------------- | ------------- | ---------- | ------------------ | | BTC | Yes | stBTC | 0.01000000 | Bitcoin | | ETH | Yes | stETH | 0.25000000 | Ethereum | | SOL | Yes | stSOL | 5.00000000 | Solana | | PAXG | Yes | stPAXG | 0.10000000 | Ethereum (ERC-20) | Notes: * Supported assets are limited to BTC, ETH, SOL, and PAXG only * PAXG is live and fully active for deposit, staking, rewards, and withdrawal * USDT is internal accounting only and cannot be deposited or withdrawn ## 8. Risk Controls BASIS applies account-level and workflow-level risk controls before balance mutation, execution submission, or withdrawal release. Institutional clients can review and update control settings through `/risk/config`, subject to scope and approval policy. Risk controls: | Control | Description | Default | | ---------------- | ----------------------------------------------------------------------------------------------------------------- | ------- | | BSCB | BASIS Sentinel Circuit Breaker. Halts or reduces execution activity when predefined risk thresholds are breached. | Enabled | | DMM | Defensive Maintenance Mode. Halts automated activity until operator review and root cause analysis are complete. | Enabled | | Position Monitor | Enforces concentration and exposure thresholds by asset, tenor, and workflow type | Enabled | `GET /risk/config` returns the active account policy. `PUT /risk/config` updates policy thresholds, subject to `risk:write` scope and internal approval policy. Example risk configuration payload: ```json { "bscb": { "enabled": true, "min_operational_buffer_pct": "2.00" }, "dmm": { "enabled": true, "daily_drawdown_limit_pct": "5.00" }, "position_monitor": { "enabled": true, "single_asset_concentration_limit_pct": "40.00" } } ``` Operational notes: * Risk policy changes are fully audited * Policy updates can be staged for activation at a future timestamp * Rejected requests return detailed policy failure reasons in `error.details` ## 9. Reporting and Audit Trail BASIS maintains a 7-year immutable operational and ledger log for institutional accounts. Every authenticated API action, balance mutation, stake lifecycle event, reward accrual, withdrawal event, and risk policy change is preserved for audit and reconciliation. Reporting capabilities include: * Statement generation through `/reports/statement` * Export formats: JSON, CSV, FIXML * Interval-level audit anchoring through `/reports/audit-root` * RFC 3161 TSA timestamps for report evidence * Merkle-root proofs for statement integrity verification Typical reporting workflow: 1. Submit a statement generation request to `POST /reports/statement` 2. Specify account, date range, and desired format 3. Retrieve the generated statement and associated integrity metadata 4. Verify the returned Merkle root against `/reports/audit-root` 5. Store the accompanying RFC 3161 timestamp token for external audit evidence Recommended statement fields: * Account identifier * Asset balances by day or interval * Stake opens and closes * Reward accrual and settlement * Withdrawal requests and completion state * Order submissions and acknowledgements * Risk policy changes * Request IDs and server timestamps ## 10. Service Level Agreement | Service Metric | Target | | --------------------- | --------- | | API uptime | 99.98% | | Order acknowledgement | <1 ms p99 | | Webhook delivery | <500 ms | | Withdrawal completion | <60 s | SLA notes: * Targets apply to normal operating conditions * Client-side network path variance is excluded * Planned maintenance windows are notified in advance * Policy-based holds, destination approval workflows, or external network congestion may affect individual settlement outcomes ## 11. Research References Selected Base58 Labs research papers from 2026: 1. Base58 Labs, "Deterministic Routing Optimization Under Stochastic Latency", 2026 2. Base58 Labs, "Atomic Time Ordering for Digital Asset Audit Trails", 2026 3. Base58 Labs, "Adaptive Liquidity Recycling for Yield and Arbitrage Portfolios", 2026 4. Base58 Labs, "Secure Multi-Signature Orchestration for Institutional Settlement", 2026 5. Base58 Labs, "Low-Latency Risk Gating with Balance Sufficiency Circuit Breakers", 2026 ## 12. Contact * To apply for institutional API access, please provide the following information by email to : 1. Legal entity name and jurisdiction 2. Intended use case (hedge fund / trading desk / custodian / treasury) 3. Estimated monthly volume (USD equivalent) 4. Preferred connectivity mode (Public HTTPS / Equinix cross-connect / FIX) 5. Technical contact and compliance officer details Our institutional team will respond within 2 business days. Following eligibility review, approved applicants receive API credentials, onboarding documentation, and a dedicated technical contact. {% hint style="info" %} Client assets are segregated at wallet, ledger, and reporting layers. Withdrawal release policies support approved destination lists, role-based authorization chains, and multi-sig custody controls. Hot wallet exposure is policy-limited, with excess balances swept to segregated cold custody. Audit evidence is available through immutable statements, Merkle-root verification, and RFC 3161 timestamp records. {% endhint %} # Market Microstructure Primer {% 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)). {% endhint %} Market microstructure studies how exchange rules, queue dynamics, participant behavior, and latency shape price formation, liquidity, and transaction cost. For BASIS, microstructure is operational rather than academic. It is the source of structural alpha capture, execution precision, and realized slippage. The BHLE execution stack is designed around sub-50μs internal latency, 100K+ OPS capacity, proprietary routing infrastructure, deterministic execution paths, math-based constraints, and state machine risk controls. This page introduces the core microstructure concepts that underpin BASIS strategy design and execution logic. *** ## At a glance {% tabs %} {% tab title="Key concepts" %} | Concept | What it measures | Why it matters | | ----------------- | -------------------------------------------- | ----------------------------------------- | | Spread | Best ask minus best bid | Immediate explicit trading cost | | Depth | Resting size across price levels | Capacity before slippage increases | | Price impact | How trades move price | Determines scalable order size | | OFI | Net order flow pressure | Short-horizon directional information | | Adverse selection | Risk of trading against better-informed flow | Converts apparent edge into realized loss | | Latency risk | Cost of stale or delayed information | Critical for venue selection and routing | | {% endtab %} | | | {% tab title="BASIS execution view" %} BASIS treats microstructure as an input to routing and state control. * Order book state informs expected fill quality * Impact models bound executable size * OFI helps refine timing * Latency models filter stale opportunities * State machine controls enforce deterministic risk limits {% endtab %} {% endtabs %} *** ## 1) The limit order book as the foundational data structure Every exchange-based market is organized around the limit order book, or LOB. The LOB is a live record of outstanding buy and sell interest for a given asset, arranged by price level. ### Core terms | Term | Definition | | -------------- | ------------------------------------------------ | | Bid | An order to buy at a stated price or lower | | Ask | An order to sell at a stated price or higher | | Best bid | Highest active buy price | | Best ask | Lowest active sell price | | Spread | Difference between best ask and best bid | | Depth | Available quantity at each price level | | Queue position | Relative priority among orders at the same price | Shallow depth means even modest trades can move price materially. Deep books allow larger trades with lower slippage, but only up to the true available capacity at each level. BASIS consumes Level 2 and, where available, Level 3 order book data in real time. That data is the raw material for identifying structural alpha capture opportunities and estimating execution cost before an order is routed. {% hint style="warning" %} A visible price gap is not sufficient. If displayed depth is thin, stale, or likely to cancel under stress, the apparent edge may not survive execution. {% endhint %} *** ## 2) Price impact and Kyle's Lambda Any trade that consumes liquidity can move price. A standard way to model this effect is Kyle's Lambda, introduced in Albert S. Kyle's 1985 paper, "Continuous Auctions and Insider Trading" \[1]. In simplified form: $$ \Delta P = \lambda \cdot Q $$ Where: * ΔP is the price change * Q is signed order size * λ is the price impact coefficient A higher λ implies a more sensitive or less liquid market. A lower λ implies deeper liquidity and lower marginal impact. For BASIS, λ is not a static number. It varies by: * venue * asset * time of day * volatility regime * current book shape * order flow pressure An execution path that looks profitable before impact adjustment may become unattractive once λ is estimated correctly. ``` net_edge = observed_edge - spread_cost - fee_cost - impact_cost(lambda, size) - latency_risk - inventory_penalty Execute only if: net_edge > threshold and state_machine_allows(order) ``` This is where deterministic execution matters. BASIS does not rely on discretionary overrides during live routing. Math constraints and state machine checks define whether a route is admissible. *** ## 3) Order flow imbalance Order Flow Imbalance, or OFI, measures the net pressure exerted by buying and selling activity on the book. It incorporates both aggressive liquidity-taking flow and meaningful changes in resting liquidity. As described by Cont, Kukanov, and Stoikov (2014) \[2], OFI can be informative for short-horizon price movement: * Positive OFI often indicates upward pressure * Negative OFI often indicates downward pressure BASIS research uses OFI to improve execution precision in several ways: | Application | Practical use | | ------------------- | ----------------------------------------------------- | | Entry timing | Avoid entering when near-term pressure is unfavorable | | Exit timing | Reduce slippage during unwind events | | Volatility sensing | Treat OFI spikes as a microstructure stress signal | | Routing calibration | Reweight venue preference under changing pressure | OFI is most useful when combined with spread, depth, queue dynamics, and latency measurements. On its own, it is informative. In combination, it becomes operational. *** ## 4) Adverse selection and information asymmetry Adverse selection is the risk of trading with a counterparty who effectively knows more than you at that moment. In fast markets, this often appears as stale-price risk. A venue may still show an attractive quote even though a faster participant has already reacted to a price change elsewhere. If you trade against that stale quote without proper controls, your apparent edge disappears. For BASIS, this risk is modeled explicitly through a latency risk component that depends on: * internal processing latency * feed delay and synchronization quality * venue-specific quote stability * stale-quote frequency * cancellation intensity near touch levels The objective is simple. Distinguish genuine structural alpha capture from illusions created by information asymmetry. {% hint style="success" %} Deterministic execution quality depends on both speed and control. BASIS combines sub-50μs internal latency, proprietary routing, and state machine risk gates so that opportunities are evaluated under the same decision logic every time. {% endhint %} *** ## 5) From signal to execution {% stepper %} {% step %} **Observe** Ingest live book state, trade prints, venue latency, and queue changes. {% endstep %} {% step %} **Estimate** Compute spread cost, impact, OFI, fill probability, and latency-adjusted net edge. {% endstep %} {% step %} **Constrain** Apply deterministic risk rules, inventory bounds, venue health checks, and state machine permissions. {% endstep %} {% step %} **Route** Send orders through proprietary routing infrastructure designed for high throughput and execution precision. {% endstep %} {% endstepper %} This pipeline is what turns microstructure research into a production execution system. *** ## 6) The role of Base58 Labs 🔬 Base58 Labs, the Research Institute supporting BASIS, studies digital asset market structure at the empirical level. Its research areas map directly to the concepts above: * High-frequency data analysis Modeling impact, queue behavior, and short-horizon response functions * Execution microstructure Designing slicing, placement, and routing logic to reduce realized cost * On-chain execution precision Quantifying adverse selection, timing risk, and structural alpha capture in decentralized environments * Risk systems design Translating market observations into math constraints and state machine controls This research-led framework helps ensure that BASIS strategy logic is grounded in measurable market behavior rather than static assumptions. *** ## References \[1] Kyle, A. S. (1985). "Continuous Auctions and Insider Trading." Econometrica, 53(6), 1315-1335. \[2] Cont, R., Kukanov, A., & Stoikov, S. (2014). "The Price Impact of Order Book Events." Journal of Financial Econometrics, 12(1), 47-88.\ *** ## Base58 Labs Research The following publications from Base58 Labs are directly relevant to the microstructure concepts discussed in this primer. **Asymmetric Observation: Why Markets Never See the Same World** (February 2026)\ Examines how market participants operate under structurally asymmetric information environments. Relevant to routing logic design and execution timing under observable state conditions.\ \[Base58 Labs.com/research]\( Labs.com/research) **The Physics of Intent: Bridging the Semantic Gap Between Security and UX** (February 2026)\ Explores the tradeoffs between transaction intent visibility and execution security in decentralized environments. Relevant to pre-trade information leakage and order routing design. **Ethereum 2026: The Triad of Scale, UX, and Resilience** (February 2026)\ Reviews the structural developments in Ethereum's execution layer as of 2026. Relevant to cross-venue execution dynamics and settlement finality assumptions. **The Physics of Propagation: PeerDAS and the Tail Risk of Decentralized Routing** (March 2026)\ Analyzes propagation latency and tail-risk scenarios in decentralized data availability systems. Relevant to timing risk modeling in execution environments with non-deterministic finality. These publications inform the research framework underlying BASIS strategy design and the BHLE execution infrastructure maintained by Base58 Labs. # Cross-Exchange Execution: Microstructure Challenges {% 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 %} {% hint style="warning" %} Display convention: dashboard values may be shown in USDT as an internal accounting unit. USDT is not a depositable or withdrawable asset on BASIS. Funding is available in native assets only: BTC, ETH, SOL, and PAXG. {% endhint %} Spotting a cross-venue price gap is easy. Capturing it in the live order book is the challenge. This page describes the microstructure failure modes behind structural alpha capture and how BHLE manages them through deterministic execution, math constraints, and state machine risk controls. *** ## ⚠️ The leg risk problem Cross-venue execution requires two fills close in time: * Leg 1: buy on the lower-priced venue * Leg 2: sell on the higher-priced venue Leg risk appears when one leg fills and the other leg fails or fills materially worse. If only Leg 1 fills, the system temporarily holds directional exposure. That breaks the intended market-neutral profile. ``` Ideal fill: BUY Venue A ($30,000) + SELL Venue B ($30,050) -> profit $50 Degraded fill: BUY Venue A ($30,000) + SELL Venue B ($30,005) -> profit $5 Failed hedge: BUY Venue A ($30,000) + SELL Venue B FAILS -> unhedged long exposure ``` {% hint style="danger" %} The visible spread is not the realizable spread. Realized outcome depends on queue position, depth quality, cancellation intensity, and round-trip latency. {% endhint %} *** ## 📉 Why visible spread disappears | Factor | What happens in live books | Execution consequence | | ------------------------ | --------------------------------------------------------- | ------------------------------------------------------------- | | Market impact (Kyle's λ) | Larger orders move the book against the executor | Per-unit edge decays as order size approaches available depth | | Quote flickering | Market makers cancel and repost quotes in milliseconds | Visible liquidity can disappear before both legs complete | | Latency asymmetry | Slower participants lose queue priority to faster routers | Spread capture can compress from profitable to flat | | Partial fills | Only a fraction of the intended size executes | Residual exposure remains unhedged | | Venue instability | API delay, stale acknowledgements, or timeout bursts | Fill certainty falls even when quoted spread looks attractive | Kyle (1985) models price impact as proportional to order flow imbalance. Cont, Kukanov, and Stoikov (2014) show that limit order book impact is nonlinear and path-dependent. In practice, this means structural alpha capture is constrained by order book state, not by the displayed mid-price alone. *** ## ⚙️ BHLE execution model BHLE reduces leg risk through synchronized cross-venue submission with deterministic state transitions. {% stepper %} {% step %} Signal validation The opportunity must exceed a pre-trade threshold after estimated impact, venue fees, and a slippage guard are applied. {% endstep %} {% step %} Constraint check BHLE checks whether both venues can support the required quantity inside the configured slippage bound of 0.30%. {% endstep %} {% step %} Simultaneous submission Both legs are submitted at the same time through proprietary routing infrastructure with synchronized order identifiers. {% endstep %} {% step %} Fill reconciliation The engine reconciles acknowledgements and fills within a tightly bounded latency window. {% endstep %} {% step %} Abort or offset If the hedge leg fails, BHLE cancels or offsets the filled leg immediately. The system accepts a small bounded loss rather than hold open directional exposure. {% endstep %} {% endstepper %} ``` Signal detected (gap = $50, T = 0) ├── T+0μs Pre-calculate both legs and validate against 0.30% slippage bound ├── T+10μs Submit orders to Venue A and Venue B simultaneously ├── T+40μs Receive fill confirmation from both venues │ -> Trade complete └── Fallback -> If one venue does not confirm inside tolerance, cancel or offset -> Preserve neutrality and keep loss bounded ``` ### Control principles | Control | Purpose | | --------------------------- | --------------------------------------------------------------------- | | Sub-50μs latency budget | Keeps routing inside the effective lifetime of short-lived price gaps | | 100K+ OPS throughput | Maintains stable handling of burst traffic during volatility | | Deterministic state machine | Prevents discretionary drift during live execution | | Slippage bound of 0.30% | Rejects trades when the fill cannot remain inside defined tolerance | | Pre-trade depth validation | Avoids routing size into insufficient liquidity | | Circuit-breaker logic | Temporarily disables unstable venues after repeated failures | {% hint style="info" %} BHLE is designed to preserve execution precision first. If the hedge cannot be completed within constraints, the trade is rejected or neutralized. {% endhint %} *** ## 🧪 Worked example Scenario: BTC spread of $45 between Venue A and Venue B. {% tabs %} {% tab title="Slow executor" %} | Time | Event | | ------- | --------------------------------------------------------------------------------------------------- | | T=0ms | Gap detected: Venue A $30,000, Venue B $30,045 | | T=500ms | Orders submitted after internal processing delay | | T=501ms | Venue A fills at $30,002 | | T=502ms | Venue B has moved to $30,018 as other fast participants close the gap | | Result | Gross spread captured: $16. Assumed execution and network costs: $15. Net result: approximately $1. | This outcome is operationally flat even though the original quote looked attractive. {% endtab %} {% tab title="BHLE path" %} | Time | Event | | ------ | ---------------------------------------------------------------------------------------------------- | | T=0μs | Gap detected: Venue A $30,000, Venue B $30,045 | | T=12μs | Both orders submitted simultaneously | | T=47μs | Both legs confirmed | | Result | Gross spread captured: $45. Assumed execution and network costs: $15. Net result: approximately $30. | The difference is execution precision, not signal quality. {% endtab %} {% endtabs %} *** ## 🌪️ Routing under stress When volatility rises, BHLE shifts from opportunity maximization to constraint enforcement. | Stress condition | BHLE response | | ----------------------- | -------------------------------------------------------------------------------- | | Thin order books | Reduce size to remain inside validated depth | | Quote flickering burst | Require stronger pre-trade fill probability before routing | | Venue API degradation | Trigger circuit breaker after repeated failures and temporarily remove the venue | | Correlated venue stress | Pause new structural alpha capture and preserve capital | | Partial fill sequence | Offset residual exposure immediately through the state machine | ### What this means operationally * Do not chase spread that sits outside validated depth * Do not rely on top-of-book alone * Do not hold a one-sided fill if the hedge leg is impaired * Do not continue routing to a venue that has entered a degraded state *** ## 🔒 Why this matters for BASIS BASIS execution infrastructure is built around deterministic routing, bounded loss logic, and strict neutrality enforcement. The objective is not just to detect price differences. It is to realize structural alpha under real exchange constraints. This design philosophy supports: * deterministic execution over discretionary handling * math-constrained order admission * state machine risk controls * bounded response to venue instability * consistent execution precision across market regimes *** ## 📚 References * Kyle, A. S. (1985). "Continuous Auctions and Insider Trading." Econometrica, 53(6), 1315-1335. * Cont, R., Kukanov, A., and Stoikov, S. (2014). "The Price Impact of Order Book Events." Journal of Financial Econometrics, 12(1), 47-88. * Alexander, A. (2025). "Latency Arbitrage in Cryptocurrency Markets." SSRN 5143158. # Arbitrage Economics: Edge vs Cost {% 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 %} Most spread-trading summaries stop at "buy low, sell high." Real execution begins after that. The relevant question is whether an observed gap has positive expected value after fees, slippage, latency drag, settlement cost, and residual tail risk. This page defines the economics model BASIS uses to approve or reject a structural alpha capture slice. {% hint style="success" %} ⚙️ Execution environment BASIS runs BHLE with sub-50μs decision latency, 100K+ OPS throughput, and proprietary routing infrastructure. Faster routing reduces execution decay, but no trade bypasses the expected value gate. {% endhint %} ## 1) Formal expected value model For any opportunity, BASIS gates execution on expected value: $$ EV = E\[\text{Edge}] - \sum C\_{\text{trade}} - R\_{\text{premium}} $$ | Variable | Meaning | | ------------------------ | ---------------------------------------------------------------------------- | | $E\[\text{Edge}]$ | Expected gross profit from an observed spread, basis, or funding dislocation | | $\sum C\_{\text{trade}}$ | Total direct and indirect execution costs | | $R\_{\text{premium}}$ | Additional premium for unhedgeable or tail risk | {% hint style="info" %} Rule: BASIS initiates a trade only when $EV > 0$ under conservative parameters. {% endhint %} ``` Decision rule if expected_edge - total_trade_costs - risk_premium > 0 and venue_limits_pass and inventory_limits_pass and state_machine_checks_pass: route_order() else: reject_slice() ``` ## 2) Cost and risk decomposition {% tabs %} {% tab title="Cost stack" %} | Component | Description | BASIS treatment | | -------------------- | --------------------------------------------------------------------------------- | ----------------------------------------------------------------------------- | | $C\_{\text{fees}}$ | Explicit venue charges such as maker, taker, funding transfer, or withdrawal cost | Direct deduction from expected edge | | $C\_{\text{slip}}$ | Price impact from consuming liquidity | Function of trade size, venue depth, queue position, and volatility | | $R\_{\text{lat}}$ | Risk that the edge compresses before hedge completion | Penalty that rises with observed latency and market velocity | | $R\_{\text{settle}}$ | Cost and risk of moving inventory across venues or chains | Includes gas, delay, operational friction, and settlement failure probability | | $R\_{\text{cpty}}$ | Venue or protocol failure risk | Managed through venue scoring, exposure caps, and concentration limits | | {% endtab %} | | | {% tab title="Execution controls" %} BASIS applies math-constrained routing before any order is released: * deterministic execution paths * state machine risk controls * venue exposure ceilings * inventory bounds * route quality scoring * minimum executable size checks * throttle and pause logic during volatility spikes These controls prevent displayed edge from being mistaken for executable edge. {% endtab %} {% endtabs %} ## 3) Slippage inversion: when not trading is correct A common execution failure is slippage inversion: $$ \sum C\_{\text{trade}} \geq E\[\text{Edge}] $$ At that point, the trade is loss-making by construction, even if the displayed spread still looks attractive. BASIS refuses these slices. The risk engine can pause, throttle, or reduce order size when liquidity deteriorates or volatility rises and the slippage estimate expands. {% hint style="warning" %} Skipping a trade is often the correct outcome. Deterministic rejection is a feature of execution precision, not a missed opportunity. {% endhint %} ## 4) Inventory and capital cost The model also prices inventory risk. * In derivatives strategies, inventory cost often appears through funding. * In spot strategies, inventory cost appears as opportunity cost and temporary directional exposure. * More volatile inventory requires a larger premium, which reduces the set of acceptable slices. This follows the same intuition developed in optimal market-making literature: inventory is not neutral, and holding it even briefly should be priced into the decision. ## 5) How BASIS evaluates a slice {% stepper %} {% step %} Observe the raw spread, basis, or funding dislocation. {% endstep %} {% step %} Estimate executable size using live depth, queue state, and route quality. {% endstep %} {% step %} Subtract direct costs, including fees and expected slippage. {% endstep %} {% step %} Apply latency, settlement, counterparty, and inventory premiums. {% endstep %} {% step %} Run deterministic state machine checks for exposure, concentration, and route safety. {% endstep %} {% step %} Route only if the resulting $EV$ remains positive. {% endstep %} {% endstepper %} ## 6) Why this framework improves trust A formal EV gate converts spread capture into something that can be reasoned about and audited. It makes three points explicit: * Not every displayed spread is a real opportunity * Risk has a quantifiable price * Forced execution is usually worse than selective execution Within BASIS, this framework sits inside the execution and risk stack that supports structural alpha capture. The combination of BHLE routing, deterministic execution, and state machine risk controls is designed to preserve edge quality under real market conditions. *** ## References \[1] Kyle, A. S. (1985). "Continuous Auctions and Insider Trading." Econometrica, 53(6), 1315-1335. \[2] Avellaneda, M., and Stoikov, S. (2008). "High-frequency trading in a limit order book." Quantitative Finance, 8(3), 217-224. \[3] Alexander, A. (2025). "Latency Arbitrage in Cryptocurrency Markets: Analyzing Execution Speeds & Liquidity Dynamics." SSRN Working Paper 5143158. Available at: \[4] Grossman, S. J., and Stiglitz, J. E. (1980). "On the Impossibility of Informationally Efficient Markets." American Economic Review, 70(3), 393-408. # Funding Rate Mechanics {% 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 %} Funding rates are frequently misunderstood as passive yield. They are not. Funding is a transfer mechanism inside perpetual futures markets. A delta-neutral strategy can convert that mechanism into structural alpha capture, but only if execution quality, hedge discipline, and risk controls remain intact. This page explains: * why funding exists * how funding differs from basis * how a delta-neutral structure works conceptually * where the real risks sit * what BASIS should disclose for credible reporting *** ## 1. Why funding exists in perpetual futures Perpetual futures do not expire. Without an expiry anchor, perpetual prices can drift away from spot prices. Funding is the mechanism used to push perpetual pricing back toward spot. {% tabs %} {% tab title="Positive funding" %} When perpetual price is above spot price: * longs pay shorts * short exposure becomes more attractive * additional short interest helps compress the premium {% endtab %} {% tab title="Negative funding" %} When perpetual price is below spot price: * shorts pay longs * long exposure becomes more attractive * additional long interest helps close the discount {% endtab %} {% endtabs %} The key point is simple: funding is not created from nowhere. It is transferred between market participants. *** ## 2. Funding vs basis Funding and basis are related, but they are not the same thing. | Concept | What it is | Time profile | Why it matters | | ------- | -------------------------------------------------- | ----------------------- | --------------------------------- | | Basis | Difference between derivative price and spot price | Point-in-time price gap | Can widen or converge | | Funding | Periodic payment between longs and shorts | Interval-based transfer | Incentivizes perp price alignment | A delta-neutral structure may monetize: * funding payments * basis convergence * or both together {% hint style="info" %} Practical interpretation: basis is a price condition, funding is a payment rule. {% endhint %} *** ## 3. Conceptual delta-neutral structure A canonical funding capture structure is: 1. long spot 2. short perpetual futures 3. rebalance when the hedge drifts {% stepper %} {% step %} #### Step 1 Acquire or hold the spot asset. {% endstep %} {% step %} #### Step 2 Open an offsetting short position in the corresponding perpetual market. {% endstep %} {% step %} #### Step 3 Monitor hedge ratio, margin state, and funding regime. {% endstep %} {% step %} #### Step 4 Rebalance only when expected net value remains positive after execution costs and risk constraints. {% endstep %} {% endstepper %} This reduces directional exposure, but it does not eliminate risk. Why not? * hedge ratios drift * funding can reverse * rebalancing is not free * liquidation remains possible if margin deteriorates * basis can widen before it converges A useful conceptual decomposition is: ``` Net capture ≈ funding received + basis convergence - trading fees - slippage - borrow or margin cost - losses from hedge drift - liquidation losses ``` If the result is not positive after realistic costs, there is no structural alpha. *** ## 4. Funding is a regime variable Funding is not stable. It changes with market structure. Common drivers include: * volatility spikes * crowded one-sided positioning * rapid shifts in open interest * exchange-specific imbalances * major macro or crypto news events A strategy that assumes funding will remain positive is not neutral. It is taking a regime bet. {% hint style="warning" %} ⚠️ Funding can compress, flip negative, or become too unstable to justify exposure. Historical funding is not a guarantee of future capture. {% endhint %} For this reason, BASIS treats funding capture as conditional, not automatic. Eligibility should be gated by: * positive expected value under conservative assumptions * deterministic execution thresholds * strict margin and liquidation guardrails * state machine risk controls that can pause or reduce exposure during stress *** ## 5. Why execution quality matters In funding capture, the edge is often small relative to execution error. Poor execution can destroy theoretical carry through: * slow hedge updates * spread crossing * slippage during rebalancing * fragmented routing quality * delayed de-risking during volatility BASIS addresses this through BHLE, a proprietary execution environment designed for: * sub-50μs latency * 100K+ OPS throughput * deterministic routing infrastructure * math-constrained state transitions * automated risk bounds at the engine level This matters because structural alpha capture is only credible when the realized path stays close to the modeled path. *** ## 6. Hidden costs that are easy to miss Even when gross funding looks attractive, net realized outcome may be weaker. | Hidden cost | How it appears | Why it matters | | ------------------------ | -------------------------------------- | ---------------------------------- | | Rebalancing fees | Frequent hedge updates | Eats into carry | | Slippage | Thin books or stressed markets | Realized entry and exit worsen | | Margin opportunity cost | Capital tied to the hedge | Lowers capital efficiency | | Liquidation risk premium | Adverse move before rebalance | Can convert carry into loss | | Venue fragmentation | Different prices and funding schedules | Makes true net capture harder | | Latency drag | Delayed reaction to market change | Increases drift and execution loss | Funding APR, by itself, is not yield. Only net realized outcome matters. *** ## 7. BASIS operating standard for funding exposure A credible funding capture program should not run on narrative. It should run on measurable constraints. BASIS applies the following principles: * only engage when expected value is positive after conservative cost assumptions * cap exposure by market depth, volatility, and hedge quality * treat liquidation as a failure state, not a routine operating assumption * reduce or pause deployment when regime quality deteriorates * rely on deterministic execution and state machine controls rather than discretionary reactions This is consistent with BASIS's broader design philosophy: * execution precision over headline optics * structural alpha capture over directional speculation * verifiable process over opaque discretion *** ## 8. What should be disclosed for credible reporting If BASIS reports funding-linked performance, the disclosure standard should be clear and auditable. Minimum reporting should include: * realized funding income * realized trading fees * realized slippage * net carry after all costs * hedge rebalancing frequency * liquidation events, if any * pause or stop intervals during stress * regime filters used to qualify deployment {% hint style="success" %} ✅ Good reporting separates gross funding from net realized outcome. {% endhint %} *** ## 9. Bottom line Funding is a useful market mechanism, not free yield. A delta-neutral structure can harvest funding and basis dislocations, but only under disciplined execution, conservative risk limits, and transparent reporting. At BASIS, funding capture is treated as one component of a broader structural alpha framework, supported by deterministic execution, quantitative constraints, and research-driven market microstructure models. *** Next: read Slippage & Market Impact Models. # Slippage & Market Impact Models {% 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 %} Slippage is not random noise. It is a measurable function of market depth, volatility, time, and routing quality. BASIS models slippage to improve execution precision and structural alpha capture across fragmented liquidity. The BHLE stack is designed for sub-50μs decision latency, 100K+ OPS, and proprietary routing under deterministic, math-constrained state machine risk controls. *** ## 1) Slippage components {% tabs %} {% tab title="Instant impact" %} Immediate price movement caused by consuming visible liquidity at the top of the book. {% endtab %} {% tab title="Transient impact" %} Price drift during the execution window while the order is still being completed. {% endtab %} {% tab title="Adverse selection" %} Loss from interacting with liquidity just before new information is reflected in the market. {% endtab %} {% tab title="Routing friction" %} Execution loss introduced by venue choice, queue position, latency, and hedge completion quality. {% endtab %} {% endtabs %} A reliable model estimates conservative bounds for each component, then applies routing and stop conditions before execution. *** ## 2) Depth-based slippage estimation A first-order depth model starts with two quantities: * Order size: Q * Available cumulative depth to a target price level: D As Q / D increases, expected slippage generally increases. ### Intuition | Condition | Expected effect | | ---------------------- | --------------------------------------------------- | | Small Q relative to D | Lower immediate impact | | Large Q relative to D | Higher immediate impact | | Fast depth refill | Lower realized slippage than static depth suggests | | Thin or unstable books | Higher realized slippage than static depth suggests | {% hint style="warning" %} Depth alone is not sufficient. Order books are dynamic, and visible liquidity can disappear under stress. BASIS therefore combines book depth, refill behavior, volatility, venue quality, and latency-sensitive routing signals. {% endhint %} *** ## 3) Nonlinear impact intuition Many markets exhibit sublinear impact growth with size. A common empirical heuristic is: $$ \text{Impact} \propto \sigma \cdot \sqrt{\frac{Q}{V}} $$ | Variable | Meaning | | -------- | ----------------- | | $\sigma$ | Market volatility | | $Q$ | Order size | | $V$ | Traded volume | This captures a practical idea: * higher volatility tends to increase impact * larger orders tend to increase impact * deeper volume tends to reduce impact {% hint style="info" %} This square-root form is a useful empirical guide, not a universal law. Production execution systems should calibrate it by asset, venue, and volatility regime. {% endhint %} *** ## 4) Conservative execution bound BASIS does not rely on a single impact number. It composes a conservative bound from multiple microstructure terms. ``` conservative_slippage_bound = instant_impact(depth, spread, queue) + transient_impact(volatility, execution_time) + adverse_selection(toxicity, information_speed) + routing_friction(latency, venue_quality, hedge_path) ``` ### Practical interpretation | Term | What it protects against | | ----------------- | --------------------------------------------------- | | Instant impact | Sweeping shallow displayed liquidity | | Transient impact | Price movement during completion | | Adverse selection | Being late to new information | | Routing friction | Suboptimal pathing, venue mismatch, or latency loss | This structure supports deterministic pre-trade checks and post-trade attribution. *** ## 5) Why order slicing helps, and when it hurts Order slicing can reduce instantaneous impact by trading in smaller pieces. It also increases exposure time, which can raise adverse selection risk. {% stepper %} {% step %} #### When slicing helps Use smaller clips when the opportunity window is wide, liquidity is stable, and hedge completion remains safe. {% endstep %} {% step %} #### When slicing hurts Avoid over-slicing when the price gap is fleeting, volatility is elevated, or book toxicity is rising. {% endstep %} {% step %} #### What BASIS does Routing logic evaluates whether to execute in one shot, split across venues, or pause entirely if state machine constraints indicate poor execution precision. {% endstep %} {% endstepper %} ### Decision guide | Market state | Preferred behavior | | ------------------------------ | --------------------------------------- | | Stable liquidity, low toxicity | Controlled slicing may improve outcomes | | Fast market, short-lived edge | Faster completion may dominate | | Weak hedge path | Reduce size or do not execute | | Venue instability detected | Re-route or stop | *** ## 6) Post-trade slippage analytics 📊 A production-grade system maintains realized slippage distributions across multiple dimensions. | Dimension | Examples | | ------------ | ---------------------------------- | | Percentiles | p50, p90, p99 | | Venue | CEX, DEX, internal route class | | Asset | BTC, ETH, SOL, PAXG | | Regime | low vol, mid vol, stress | | Order shape | single-shot, sliced, multi-venue | | Latency band | local, cross-venue, degraded state | These analytics inform: * venue scoring * order sizing constraints * route eligibility * stop conditions * model recalibration {% hint style="success" %} The goal is not to eliminate slippage entirely. The goal is to keep realized execution inside deterministic bounds often enough to preserve structural alpha after costs. {% endhint %} *** ## 7) BASIS execution design principles | Principle | BASIS approach | | ----------------------- | ------------------------------------------------ | | Deterministic execution | Pre-trade checks and bounded routing logic | | Latency discipline | BHLE architecture with sub-50μs decision latency | | Throughput | 100K+ OPS routing and state handling | | Risk controls | Math constraints and state machine enforcement | | Research loop | Continuous calibration with the Research Partner | This is why slippage modeling is treated as core infrastructure, not a cosmetic metric. *** ## 8) Key takeaways 🎯 * Slippage is a structured microstructure problem * Static depth is necessary, but not sufficient * Nonlinear impact matters at larger size * Slicing can improve or worsen outcomes depending on regime * Deterministic routing and post-trade attribution are essential for execution precision *** Next: read Execution Precision & On-chain Routing. # Execution Precision & On-chain Routing {% 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 %} Public-chain execution is not a substitute for centralized execution.\ It is a distinct market structure with visible state, observable intent, and transaction ordering risk. This page explains why execution precision matters for BASIS modules, especially structural alpha capture strategies that interact with public-chain liquidity. ## 1) The core execution problem When a transaction is broadcast publicly, other market participants can observe intent before finalization. This creates risks such as: * order anticipation * adverse reordering * slippage amplification * fee bidding pressure For strategies that depend on small spreads, these effects can eliminate expected edge before settlement. ## 2) Why public-chain routing affects structural alpha capture Opportunities on decentralized venues are visible through: * pending transaction flow * public state transitions * quoted liquidity and reserve movement If a profitable route is exposed too early, competing participants can: * replicate the trade path * move execution priority * consume available spread * force execution outside acceptable price bounds This is why BASIS treats public-chain execution as a constrained routing problem, not as a guaranteed alpha source. ## 3) BASIS execution framework 🛡️ {% tabs %} {% tab title="Market reality" %} Public-chain venues expose timing, state, and route intent. Profitability depends on execution quality, not only signal quality. {% endtab %} {% tab title="BASIS control model" %} BASIS applies deterministic execution rules, mathematical constraints, and state machine risk controls before capital is deployed. BHLE infrastructure supports sub-50μs internal decision latency, 100K+ OPS, and proprietary routing infrastructure for cross-venue coordination. {% endtab %} {% endtabs %} Key controls include: * private and selective routing where supported * bounded slippage with revert conditions * route sizing based on real-time liquidity depth * latency-aware venue selection * failure-rate and fee-regime monitoring * hard disable conditions when execution precision deteriorates {% hint style="warning" %} No routing method is perfect. BASIS does not force execution when deterministic bounds fail. If the required execution precision cannot be maintained, the module is paused. {% endhint %} ## 4) Decision policy {% stepper %} {% step %} Measure spread, depth, and fee burden. {% endstep %} {% step %} Estimate execution quality under current ordering conditions. {% endstep %} {% step %} Apply state-machine limits and route constraints. {% endstep %} {% step %} Execute only if expected structural alpha remains positive after all costs. {% endstep %} {% step %} Disable or defer if the route fails deterministic checks. {% endstep %} {% endstepper %} ## 5) When BASIS disables public-chain modules BASIS will disable or restrict a module when one or more of the following conditions is present: | Condition | Why it matters | BASIS response | | ----------------------------- | ----------------------------------------- | -------------------------- | | Fee regime spike | Net edge compresses below threshold | Pause or reduce route size | | Unstable block conditions | Settlement predictability declines | Restrict execution | | Elevated ordering competition | Public intent becomes easier to exploit | Shift routing or disable | | Slippage bound breach | Execution no longer matches modeled price | Revert or pause | | Abnormal failure rate | Signals degradation in route quality | Enter protective mode | ## 6) Why this belongs in a trust document 🔍 A credible platform should define: * the adversarial market structure * the exact stop conditions * the control logic that prevents forced execution BASIS trust is grounded in deterministic execution, mathematical constraints, and auditable risk transitions. Research support is provided by Base58 Labs as Research Partner, with ongoing work in market microstructure, structural alpha capture, and routing design. ``` Execution principle Run only when: expected edge > fees + slippage + ordering risk Otherwise: do not execute ``` Next: Risk Quantification & Stress Testing. # Risk Quantification & Stress Testing {% 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 %} A serious execution system must be evaluated under stress, not only in calm conditions. This page describes the research-driven stress testing framework used by BASIS to validate structural alpha capture under adverse market conditions. The framework is built around deterministic execution, mathematical constraints, and state-machine risk controls. {% hint style="success" %} BHLE execution profile ⚙️ * Sub-50μs latency * 100K+ OPS * Proprietary routing infrastructure Stress tests verify whether execution precision remains within tolerance when venues degrade, liquidity fragments, or hedge paths fail. {% endhint %} *** ## 1) What stress testing means in a cross-venue system Stress testing evaluates whether: * strategies remain executable * risk controls trigger in the intended order * capital can be unwound safely * hedge ratios remain inside tolerance * routing logic preserves deterministic behavior under failure conditions The objective is not to predict every crisis. The objective is to prove that the system enters controlled states when assumptions break. *** ## 2) Core stress scenarios {% tabs %} {% tab title="Scenario A · Major exchange withdrawal halt" %} Conditions * Deposits or withdrawals are halted at a major venue * Price gaps widen * Settlement certainty deteriorates Expected system behavior * BSCB triggers for affected assets and venues * New entries stop * Exposure is reduced and capital is rebalanced * Impaired routes are excluded from the active venue set {% endtab %} {% tab title="Scenario B · Extreme volatility spike" %} Conditions * BTC moves more than 10% within minutes * Order books thin out * Slippage and funding stress rise sharply Expected system behavior * Slippage inversion gates reject new trades * Liquidation guards reduce derivative exposure * The system pauses if hedging cannot be guaranteed within configured tolerance {% endtab %} {% tab title="Scenario C · USDT-linked quote market dislocation" %} Conditions * USDT deviates beyond threshold in external markets * Liquidity becomes fragmented across quote venues * Cross-venue pricing loses consistency Expected system behavior * Depeg response logic pauses affected modules * Exposure is consolidated and reduced * DMM is entered if quote uncertainty persists {% endtab %} {% tab title="Scenario D · Ethereum congestion and execution precision degradation" %} Conditions * Gas spikes drastically * On-chain execution loses precision * Realized edge falls below the structural alpha threshold Expected system behavior * On-chain modules are disabled * No forced execution occurs when routing quality is inadequate * Structural alpha capture resumes only after execution precision recovers {% endtab %} {% endtabs %} *** ## 3) What to measure A professional stress framework measures both loss outcomes and control quality. | Metric | Why it matters | | ------------------------------------ | -------------------------------------------------------------------- | | Time-to-unwind distribution | Shows whether risk can be reduced before venue impairment propagates | | Stress max drawdown | Quantifies loss under adverse path dependence | | Slippage, normal vs stress | Measures deterioration in execution precision | | Hedge completion rate | Confirms whether offsetting trades can still be completed | | Incident frequency and recovery time | Validates operational resilience | | Exposure concentration by venue | Prevents hidden dependency on a single venue or route | | Invariant violation count | Detects breaks in quantity, state, or settlement logic | | Failover latency | Measures routing and control reaction speed under degradation | {% hint style="warning" %} A metric is only useful if it is tied to a control action. Every threshold should map to a deterministic response such as block, reduce, rebalance, or pause. 🔒 {% endhint %} *** ## 4) Deterministic control mapping Stress testing is only credible when it produces clear state transitions. ``` if unwind_time > threshold or hedge_completion_rate < minimum: block_new_entries() reduce_exposure() rebalance_capital() enter_pause_state() ``` This is the core trust model for BASIS: * execution paths are measurable * failure modes are pre-defined * state transitions are machine-enforced * principal preservation is checked through invariant reconciliation *** ## 5) Stress test cycle {% stepper %} {% step %} #### Inject the shock Model a venue halt, liquidity collapse, quote dislocation, latency spike, or on-chain congestion event. {% endstep %} {% step %} #### Observe control responses Verify that routing filters, exposure limits, hedge guards, and pause logic trigger in the correct order. {% endstep %} {% step %} #### Measure outcome quality Record unwind time, slippage, drawdown, hedge completion, invariant status, and recovery latency. {% endstep %} {% step %} #### Reconcile system state Confirm that balances, positions, and state transitions remain internally consistent after the scenario completes. {% endstep %} {% endstepper %} *** ## 6) Why stress testing increases trust Stress testing converts operational claims into falsifiable statements: * If the system claims it can pause safely, test the pause sequence * If the system claims it can unwind, measure time-to-unwind under venue failure * If the system claims it preserves principal in quantity terms, reconcile balances and invariant states * If the system claims execution precision, compare realized routing outcomes against stressed benchmarks Trust does not come from optimistic assumptions. It comes from repeatable evidence that the system remains inside mathematical and operational bounds when the market stops behaving normally. *** ## 7) Design principles behind the framework BASIS stress testing is anchored to four principles: 1. Deterministic execution\ The same trigger must produce the same state transition under the same inputs. 2. Mathematical constraints\ Quantity preservation, hedge tolerances, and settlement checks must remain machine-verifiable. 3. State-machine risk controls\ The platform must move cleanly between normal, restricted, and paused states without undefined behavior. 4. Infrastructure realism\ BHLE routing, venue outages, quote fragmentation, and latency spikes are treated as first-class failure modes. *** Next: read Mathematical Verification: Invariants. # Mathematical Verification: Invariants {% 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 %} “Mathematically verified” is a design method at BASIS. The platform is built around deterministic execution, explicit math constraints, and state machine risk controls that must hold before capital can move, orders can route, or rewards can update. Structural alpha capture depends on precision first. BASIS treats correctness constraints as production requirements, not research notes. *** ## What is an invariant? An invariant is a statement that must remain true across all valid system states. Common classes include: | Class | Meaning | Example | | ------------ | --------------------------------------- | -------------------------------------------------------------- | | Accounting | Balances reconcile exactly | Minted stToken supply matches underlying native token quantity | | Eligibility | Actions require validated preconditions | No order routes unless the eligibility gate passes | | Exposure | Venue and asset limits stay bounded | Per-venue BTC exposure cannot exceed configured caps | | State safety | Certain states prohibit new risk | In defensive states, new entries remain disabled | If an invariant is threatened, the affected workflow should halt, reject, or move to a constrained state. *** ## Core invariants used by BASIS 🔒 ### 1. Quantity preservation for native-token staking BASIS only supports same-token 1:1 conversion: * BTC → stBTC * ETH → stETH * SOL → stSOL * PAXG → stPAXG Invariant: ``` minted stToken quantity = accepted native token quantity burned stToken quantity = released native token quantity ``` This quantity rule applies per asset and per account. {% tabs %} {% tab title="BTC" %} * Deposit by copying your BASIS-assigned BTC address * Minimum deposit: 0.0001 BTC * No Web3 wallet connection is required for BTC deposits * Accepted BTC quantity must match minted stBTC quantity 1:1 {% endtab %} {% tab title="ETH / SOL / PAXG" %} * Deposit by connecting a supported Web3 wallet such as MetaMask * Accepted native token quantity must match minted stToken quantity 1:1 * PAXG support is live and active {% endtab %} {% endtabs %} ### 2. Swap integrity invariant BASIS does not support cross-asset swaps inside the staking system. Invariant: | Allowed mapping | Rule | | --------------- | -------- | | BTC ↔ stBTC | 1:1 only | | ETH ↔ stETH | 1:1 only | | SOL ↔ stSOL | 1:1 only | | PAXG ↔ stPAXG | 1:1 only | Any request outside the same-token mapping must be rejected. ### 3. Eligibility gate invariant Invariant: ``` No order is submitted unless the eligibility gate has passed. ``` This protects deterministic execution during degraded venue conditions, stale market states, or invalid portfolio transitions. It is one of the key controls behind execution precision and structural alpha capture. ### 4. Exposure bound invariant Invariant: ``` Per-venue exposure <= configured cap Per-asset exposure <= configured cap Aggregate portfolio state <= global risk budget ``` This limits concentration risk and constrains failure domains at the venue, asset, and portfolio levels. ### 5. Risk-state invariant BASIS uses state machine controls for strategy activation. Invariant: * In defensive or constrained states, new entries remain disabled * Recovery requires explicit state transition criteria * Reward accounting may continue, but risk expansion cannot occur without permission from the state machine This prevents the system from increasing exposure while conditions are outside acceptable bounds. ### 6. Wallet separation invariant BASIS maintains two wallet domains: | Wallet | Asset type | Allowed actions | | -------------- | ------------------ | ------------------------------ | | Funding Wallet | Native tokens only | Deposit, hold, withdraw | | Staking Wallet | stTokens only | Stake, accrue rewards, unstake | Invariant: ``` Native tokens do not appear as spendable staking balances stTokens do not function as direct withdrawal assets until the required conversion flow completes ``` This separation reduces accounting ambiguity and supports auditability. ### 7. Reward accounting invariant Rewards accumulate in real time as the same stToken in the Staking Wallet. Examples: * stBTC positions accrue rewards in stBTC * stETH positions accrue rewards in stETH * stSOL positions accrue rewards in stSOL * stPAXG positions accrue rewards in stPAXG Invariant: ``` Reward asset = stake asset = credited stToken ``` No alternate reward token is introduced by the staking engine. ### 8. Unstake completion invariant For staking positions on BASIS: * Unstake operates on the full position only * The unstake amount is auto-MAX * For fixed pools, unstake is available only after the lock-up period ends * All unstaking actions are subject to a mandatory 7-day unstaking buffer before the claimable amount is credited * There is no early exit option for fixed pools Invariant: ``` unstake_request_quantity = full_staked_position_quantity ``` Claimable value is auto-credited to the Staking Wallet as stToken only after the mandatory 7-day unstaking buffer completes. ### 9. Fee schedule invariant The platform fee schedule is fixed at the product level: | Action | Fee | | ---------- | ----- | | Deposit | 0% | | Withdrawal | 0.05% | | Swap | 0.01% | Invariant: ``` Applied fee must match the configured schedule for the action type ``` ### 10. Settlement path invariant Operational timing targets are asset-specific: | Asset | Typical withdrawal time from Funding Wallet | | ----- | ------------------------------------------- | | BTC | 10 to 60 minutes | | ETH | 1 to 10 minutes | | SOL | 1 to 10 minutes | | PAXG | 1 to 10 minutes | For unstaked positions, the mandatory 7-day unstaking buffer must complete before these withdrawal timing targets apply. Invariant: * Completed approvals must enter the correct asset settlement path * Settlement timing controls must remain consistent with the asset type requested *** ## Booster and fixed-pool constraints Booster multipliers are deterministic parameters, not discretionary adjustments. | Lock-up | Booster | | ------- | ---------- | | 14D | +10% | | 30D | +20% | | 90D | +50% | | 180D | +100% (2×) | For fixed pools, the lock-up constraint itself is part of the invariant set. {% stepper %} {% step %} Stake a supported stToken from the Staking Wallet. {% endstep %} {% step %} If a fixed pool is selected, the position remains locked until the chosen period ends. {% endstep %} {% step %} Rewards accumulate in real time as the same stToken. {% endstep %} {% step %} At maturity, unstake the full position, then wait for the mandatory 7-day unstaking buffer to complete. The claimable amount is auto-credited to the Staking Wallet as stToken. {% endstep %} {% endstepper %} *** ## How BASIS enforces invariants ⚙️ BASIS applies invariants through multiple control layers: * code-level assertions * property-based testing * simulation and replay across historical event streams * deterministic state transition checks * continuous monitoring and alerting * production risk controls tied to routing infrastructure The BHLE execution stack is designed for high-throughput precision. BASIS infrastructure targets sub-50μs internal decision latency and 100K+ OPS through proprietary routing systems while still enforcing hard risk constraints before order submission. {% hint style="success" %} A fast system is only trustworthy if its speed is bounded by math, deterministic rejection rules, and explicit state controls. {% endhint %} *** ## Why this matters Experts look for invariant-driven systems because they expose what the platform actually guarantees: * what must reconcile * what cannot happen * what states disable risk * what accounting paths are permitted * what assumptions are enforced in production At BASIS, mathematical verification is the practical link between research, infrastructure, and live capital operations. The research framework is informed by Base58 Labs and implemented as deterministic controls for execution precision and structural alpha capture. *** ## Related product assumptions For users reviewing system correctness, the following product rules are part of the operational model: | Topic | Rule | | ----------------------- | ----------------------------------------- | | Dashboard sections | Stake, Assets, Referral, Support, Account | | BTC deposits | Use your BASIS-assigned BTC address | | ETH, SOL, PAXG deposits | Connect a supported Web3 wallet | | Depositable assets | BTC, ETH, SOL, PAXG | | USDT | Internal accounting and display unit only | | Referral system | Contribution-aligned referral network | {% hint style="warning" %} If an interface state or transaction flow appears to violate any rule on this page, contact before proceeding. {% endhint %} # Spatial Arbitrage (BQAE) {% 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 %} ## 1) Objective Spatial Arbitrage, also known as cross-venue arbitrage, is the act of simultaneously buying an asset on one venue where the price is lower and selling it on another where the price is higher. The BASIS Quantitative Arbitrage Engine (BQAE) is designed to execute this strategy systematically with deterministic execution, execution precision, and state-machine risk controls. ## 2) Plain-English Overview: Global Price Gaps Imagine a product selling for $100 in one market and $105 in another. A spatial arbitrage system buys in the lower-priced market and sells in the higher-priced market, capturing the spread after transaction costs. In digital asset markets, the "markets" are exchanges and liquidity venues, and the assets are instruments such as BTC, ETH, SOL, or PAXG. The BQAE continuously scans cross-venue pricing to detect temporary dislocations and route orders with high execution precision. {% hint style="success" %} BQAE is designed to capture structural alpha from short-lived cross-venue inefficiencies, not directional market exposure. {% endhint %} ## 3) Professional View: Frictions That Define Profitability Although the idea is straightforward, profitable implementation depends on infrastructure, quantitative modeling, and risk constraints. The BQAE must solve several core frictions. ### Latency and routing Price dislocations can collapse within milliseconds. The system must coordinate both sides of the trade before the spread disappears. BASIS infrastructure emphasizes: * Sub-50μs internal latency design * 100K+ OPS processing capacity * Proprietary routing infrastructure * Deterministic execution paths * Venue-aware order placement logic This architecture supports execution precision under fragmented market conditions. ### Execution quality and slippage control Both legs must complete at acceptable prices. If one side fills and the other does not, the trade may become unintended directional exposure. To reduce this risk, BQAE uses: * Pre-trade slippage modeling * Liquidity-depth checks * Conservative fill thresholds * Atomic execution logic where possible * Immediate unwind procedures when completion constraints are violated ### Settlement and inventory management Cross-venue arbitrage requires inventory to already exist where it is needed. For example, one venue may require quote inventory while another requires base inventory. Rebalancing this inventory across venues introduces cost, delay, and operational complexity. The BQAE maintains venue-level inventory models and treasury constraints to support continuous execution without relying on slow reactive transfers. ## 4) Mathematical Framing: Graph Search for Structural Alpha Finding profitable multi-venue and multi-asset paths can be modeled as a graph problem. Research Partner frameworks apply concepts related to Bellman-Ford and Floyd-Warshall to represent the trading environment as a directed graph. ### Graph representation | Component | Interpretation | | ------------ | ------------------------------------------------------------------------ | | Nodes | Assets on specific venues, such as BTC on one exchange or ETH on another | | Edges | Tradable conversions or transfer relationships | | Edge weights | Exchange rates adjusted for fees, spread, and execution assumptions | A common transformation uses the negative logarithm of effective exchange rates. Under that formulation, profitable cycles correspond to negative-weight cycles in the graph. ``` Node A -> Node B -> Node C -> Node A ``` If the product of effective rates across a closed loop exceeds 1 after all costs, the cycle may contain structural alpha. $$ \log(r\_1) + \log(r\_2) + \log(r\_3) + \dots + \log(r\_n) > 0 $$ Where each ( r\_i ) is the effective exchange rate after fees and modeled execution cost. This approach allows BQAE to evaluate not only simple two-venue spreads but also more complex path-dependent opportunities across fragmented liquidity. {% hint style="warning" %} A theoretical cycle is not sufficient for execution. BQAE applies real-time feasibility filters for liquidity, latency, venue health, and inventory availability before any route is eligible. {% endhint %} ## 5) Risk Model and Control Framework The strategy is governed by deterministic constraints rather than discretionary intervention. Risk controls are implemented as state-machine checks before, during, and after execution. | Risk | Description | BASIS control mechanism | | ------------------- | ----------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | | Execution risk | One leg fills while the offsetting leg does not, creating unwanted exposure | Hedge completion window with automatic unwind logic if paired execution constraints fail | | Settlement risk | Capital becomes unavailable on a venue due to transfer restrictions or operational issues | Liquidity fragmentation, venue scoring, balance caps, and automatic venue isolation | | Slippage inversion | Spread is smaller than total cost after fees and market impact | Expected value gate using conservative slippage and fill assumptions | | Latency decay | Opportunity disappears before both legs can complete | Time-validity thresholds and routing only through venues meeting latency standards | | Inventory imbalance | Required assets are not positioned on the correct venues | Pre-positioned inventory framework with treasury rebalancing constraints | ## 6) Why Infrastructure Matters BQAE performance depends on engineering quality as much as on pricing logic. The system is built around: * Deterministic execution * Math-constrained opportunity selection * State-machine risk controls * Venue health monitoring * Proprietary routing infrastructure * Research-driven path optimization frameworks from Base58 Labs This is essential because the edge in spatial arbitrage is often small, temporary, and highly sensitive to operational precision. ## References \[1] Cormen, T. H., Leiserson, C. E., Rivest, R. L., & Stein, C. (2009). Introduction to Algorithms, 3rd Edition. MIT Press. Chapter 24.1: The Bellman-Ford algorithm. # Delta-Neutral Funding Stream {% 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 %} Perpetual futures introduce recurring funding transfers between long and short positions. These transfers create a structural opportunity for delta-neutral strategies designed to capture funding spreads while controlling execution precision, margin stability, and liquidation risk. ## 1) Funding rate basics Perpetual futures do not expire. Funding payments help keep perpetual prices aligned with spot prices. * When funding is positive, longs typically pay shorts. * When funding is negative, shorts typically pay longs. Funding is not constant. It changes with market positioning, volatility, and market stress. ## 2) A delta-neutral structure A common structure is: * Spot long the asset * Perpetual short the same asset This aims to reduce directional exposure: * spot gains may offset perpetual losses, and vice versa The objective is to capture: * funding transfers * basis convergence * structural alpha from market dislocations, subject to strict risk controls ## 3) Why this is not risk-free Delta-neutral funding strategies still face material risks: * funding regime changes * liquidation risk on the perpetual leg * execution precision risk during entry, exit, or rebalancing * venue risk and settlement constraints * temporary basis divergence between spot and perpetual markets Therefore, BASIS treats this module as: * conditionally deployable under predefined eligibility rules * bounded by strict margin safety constraints * governed by emergency protection triggers and state-machine risk controls {% hint style="warning" %} Delta-neutral does not mean risk-free. The core risk is not directional exposure alone. It is whether the system can maintain hedge integrity under changing funding conditions, venue fragmentation, and stressed execution environments. {% endhint %} ## 4) Auto-rebalancing logic Because funding rates vary across venues, BASIS can: * monitor funding across approved venues * evaluate net funding after fees, slippage, and risk adjustments * re-route exposure when expected value justifies movement Rebalancing frequency is a constrained optimization problem: * too frequent creates fee drag and unnecessary execution exposure * too slow may miss favorable funding conditions or degrade hedge quality BASIS addresses this using deterministic decision rules, mathematical constraints, and execution thresholds designed to preserve expected edge after cost. ## 5) Liquidation guard If the perpetual leg approaches liquidation risk, the system can: * reduce exposure * add margin where policy permits * partially or fully unwind positions * halt redeployment until safety conditions are restored Liquidation avoidance is part of capital preservation, not a secondary objective. ## 6) Infrastructure requirements This strategy depends on high-speed routing and reliable execution quality. BASIS BHLE infrastructure is designed for this environment: * sub-50μs latency * 100K+ OPS * proprietary routing infrastructure * deterministic execution controls * state-machine risk management These controls matter because funding capture can be eroded quickly by poor timing, fragmented liquidity, or delayed hedge updates. ## 7) What users should monitor Users should monitor: * funding rate regime and volatility * margin health and liquidation distance * basis spread behavior * system state and risk alerts * execution quality under changing market conditions ## 8) Research basis This strategy is developed within a research-driven framework informed by Base58 Labs, acting as Research Partner to BASIS. The focus is not speculative leverage. It is controlled structural alpha capture through deterministic execution, math-bounded decision logic, and constrained state transitions. *** Funding streams can produce persistent yield in specific market regimes, but only when hedge discipline, execution precision, and liquidation control remain intact. On BASIS, this module is treated as a constrained risk system built for deterministic operation rather than discretionary trading. # Delta-Neutral Strategy Explained {% 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 %} A delta-neutral portfolio targets a total delta near zero. Spot price moves still occur, but the spot leg and derivatives hedge move in opposite directions. This reduces directional P\&L and shifts the strategy focus toward carry, funding, and structural alpha capture through deterministic execution. *** ## What Delta Means In a spot-only position, delta is +1 per unit held. If BTC moves +$1, the position gains about +$1. A short perpetual has delta -1. If BTC moves +$1, the short loses about -$1. Held at equal size: $$ \Delta\_{\text{portfolio}} = (+1) + (-1) = 0 $$ Directional price movement is largely offset. The remaining return profile comes from funding, carry, basis behavior, and execution precision. *** ## How BASIS Maintains Delta Neutrality BASIS builds delta-neutral exposure by coordinating both legs through BHLE, the firm's proprietary routing and execution infrastructure. ### Execution sequence {% stepper %} {% step %} Establish the spot leg BASIS acquires or maintains the underlying asset exposure, including supported stToken-linked strategy inventory where applicable. {% endstep %} {% step %} Establish the hedge leg BASIS opens an equal-notional short perpetual position on a liquid derivatives venue. {% endstep %} {% step %} Coordinate both legs BHLE executes both legs within sub-50μs timing to minimize leg mismatch risk and reduce slippage exposure. {% endstep %} {% step %} Monitor and rebalance As prices move, the portfolio delta can drift. BHLE continuously measures drift and rebalances when thresholds are breached. {% endstep %} {% endstepper %} {% hint style="success" %} BHLE characteristics: * Sub-50μs latency * 100K+ OPS processing capacity * Proprietary routing infrastructure * Deterministic execution controls * State machine risk constraints {% endhint %} This structure is designed to preserve hedge integrity while improving execution precision under changing market conditions. *** ## Funding Rate Capture Perpetual swaps use funding payments to keep perpetual prices anchored to spot. In bullish conditions, long positions often pay short positions. When BASIS is short the perpetual, it may receive funding on each funding interval. {% hint style="success" %} $$ \text{Annualised yield} \approx \text{Funding Rate}\_{8h} \times 3 \times 365 $$ Example: 0.01% per 8h → 0.03% per day → about 10.95% annualised {% endhint %} This component of return does not require the asset price to rise. It depends on funding conditions and hedge continuity. *** ## Numerical Example ### Setup | Item | Value | | ----------------------- | --------------------: | | Capital reference value | 30,000 USDT | | BTC spot leg | Buy 1 BTC at 30,000 | | BTC perpetual leg | Short 1 BTC at 30,050 | | Net delta | \~0 | ### Scenario A: BTC rises to 32,000 | Position | P\&L | | ----------------------------------------- | -----: | | Long 1 BTC spot | +2,000 | | Short 1 BTC perpetual | -1,950 | | Funding received (30 days × 0.01% per 8h) | +270 | | Net | +320 | ### Scenario B: BTC falls to 28,000 | Position | P\&L | | --------------------- | -----: | | Long 1 BTC spot | -2,000 | | Short 1 BTC perpetual | +1,980 | | Funding received | +270 | | Net | +250 | In both cases, the hedge offsets most directional movement and the return is primarily shaped by carry and execution quality. *** ## Key Risks When Delta Neutrality Deviates ### 1. Basis Risk Spot and perpetual prices can diverge. When basis widens against the position, hedge effectiveness declines. BASIS monitors basis continuously and adjusts exposure when divergence exceeds tolerance. This is one of the core reasons deterministic execution and real-time controls matter. ### 2. Funding Rate Sign Reversal Funding can turn negative during stressed or sharply bearish conditions. In that case, short positions may pay long positions rather than receive funding. BASIS detects sustained negative funding and can reduce, pause, or reroute the affected strategy path until conditions normalize. The BSCB circuit breaker serves as the hard control layer. ### 3. Liquidation Risk on the Short Hedge If margin on the perpetual short becomes insufficient during a rapid move, the venue may liquidate the hedge. That would leave unhedged spot exposure. BASIS maintains margin buffers above venue minimums and tracks margin utilization continuously through rule-based risk controls. ### 4. Execution Mismatch Risk Even in a well-designed system, timing mismatch between spot and hedge can create temporary exposure. BHLE is designed to reduce this through coordinated routing, low-latency execution, and mathematical sizing constraints. *** ## Why This Matters in BASIS Architecture The delta-neutral framework is not only a trading concept. It is an infrastructure problem involving: * Deterministic execution * Routing quality * Hedge synchronization * Basis monitoring * Risk state enforcement BASIS approaches this through BHLE and a control framework built around mathematical constraints rather than discretionary intervention. The objective is stable structural alpha capture, not directional speculation. {% hint style="info" %} Research context: BASIS strategy design is supported by Base58 Labs, acting as a Research Partner focused on execution systems, market microstructure, and risk-constrained portfolio logic. {% endhint %} *** ## See Also * [Funding Rate Dynamics](/strategies/funding-rate-dynamics) * [BSCB Circuit Breaker](https://docs.basis.pro/risk-safety-and-asset-protection/bscb) * [Yield Sources](/economics-and-rewards/yield-sources) # Funding Rate Dynamics {% 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 %} Funding rates on perpetual swaps are a primary component of carry generation in BASIS delta-neutral strategies. Understanding funding behavior, including negative regimes, is necessary for evaluating expected returns, drawdown periods, and deployment pacing. *** ## What Funding Rates Are Perpetual swaps do not expire. Without a convergence mechanism, perpetual prices can diverge from spot prices. Funding is the mechanism used by exchanges to align perpetual pricing with the underlying spot index. At each funding interval, value is transferred between longs and shorts based on the relationship between perpetual mark price and spot index price. ``` Funding Rate > 0 → Longs pay Shorts Funding Rate < 0 → Shorts pay Longs ``` A common exchange-side formulation is: ``` Funding Rate = Clamp(TWAP Premium Index + Interest Rate, -0.75%, +0.75%) ``` Most major venues apply funding every 8 hours. ``` Annualized equivalent ≈ Funding Rate × 3 × 365 ``` {% hint style="success" %} For BASIS, positive funding generally supports structural alpha capture when spot holdings are paired against short perpetual hedges. {% endhint %} *** ## Why Funding Rates Often Trend Positive Digital asset markets are frequently long-biased. Many market participants seek spot exposure and then extend that exposure using leveraged perpetual contracts. Persistent long demand can push perpetual prices above spot prices, causing longs to pay shorts. For a delta-neutral structure holding spot while shorting perpetuals, this environment can create recurring carry. The durability of this effect varies by asset, market regime, leverage conditions, and venue composition. *** ## Historical Funding Rate Ranges The ranges below reflect commonly observed 8-hour funding behavior across major venues. These figures are illustrative and should not be treated as guaranteed forward expectations. | Asset | Typical Positive Range | Extreme Positive | Typical Negative Range | Extreme Negative | | ----- | ---------------------: | ---------------: | ---------------------: | ---------------: | | BTC | 0.005% to 0.030% | >0.100% | -0.005% to -0.020% | -0.075% | | ETH | 0.005% to 0.035% | >0.150% | -0.005% to -0.025% | -0.090% | | SOL | 0.010% to 0.050% | >0.200% | -0.010% to -0.030% | -0.100% | At a midpoint funding rate of 0.015% per 8 hours: ``` 0.015% × 3 × 365 ≈ 16.4% annualized ``` This is a gross funding figure before execution costs, hedge maintenance, inventory management, and strategy controls. *** ## Negative Funding Rate Regimes Funding turns negative when short positioning becomes dominant. Common drivers include: * Rapid spot sell-offs that trigger aggressive short-perpetual demand * Macro or regulatory shocks leading to broad risk reduction * Venue-specific dislocations during liquidation cascades * Temporary basis distortions during stressed order book conditions When funding is negative, a short perpetual hedge pays funding rather than receiving it. This reduces carry and may temporarily reverse expected yield. *** ## BASIS Response to Negative Funding BASIS monitors funding conditions continuously across supported venues and applies deterministic allocation controls designed to preserve capital and maintain execution precision. | Funding Rate (8h) | BASIS Response | | -------------------------- | --------------------------------------------------------------- | | > 0% | Normal operation | | 0% to -0.005% | Elevated monitoring, no immediate reallocation | | -0.005% to -0.020% | Exposure reduction on the affected asset, potentially up to 50% | | < -0.020% | Strategy pause on the affected asset until conditions normalize | | Repeated venue/API failure | New deployment paused under state-machine risk controls | {% hint style="warning" %} The objective is not continuous deployment at any cost. BASIS prioritizes deterministic execution, math-constrained risk management, and capital preservation when expected carry becomes structurally unfavorable. {% endhint %} *** ## Interaction with Lock-Up Boosters Funding-derived yield and booster multipliers interact at the distribution layer. Current booster schedule: | Lock-Up Period | Booster | | -------------- | ------: | | 14D | +10% | | 30D | +20% | | 90D | +50% | | 180D | +100% | A longer lock-up increases reward weighting, but it also increases the time horizon over which capital remains committed. During negative funding or paused deployment windows, that means users may experience a longer period of reduced productive exposure relative to short-duration positions. {% hint style="info" %} Fixed pools can only be unstaked after the selected lock-up period ends. Early exit is not available. {% endhint %} *** ## Operational Context BASIS strategy infrastructure is designed around deterministic execution and risk-bounded state transitions. Key properties include: * Structural alpha capture through spot-perpetual basis alignment * Sub-50μs latency routing through BHLE infrastructure * 100K+ OPS throughput capacity * Proprietary routing stack for venue-aware hedge execution * State machine risk controls for deployment pauses and reactivation logic * Research support from Base58 Labs as Research Partner These controls are intended to reduce slippage, limit operational drift, and improve execution precision during both normal and stressed market conditions. *** ## See Also * [Delta-Neutral Strategy Explained](/strategies/delta-neutral-explained) * [Yield Sources](/economics-and-rewards/yield-sources) * [BSCB Circuit Breaker](https://docs.basis.pro/risk-safety-and-asset-protection/bscb) # Early-Stage Alpha Capturing {% 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 %} This strategy targets incentives distributed by emerging networks and protocols, as well as structural pricing inefficiencies that arise during a new asset's initial listing period. Ecosystems frequently bootstrap liquidity through reward programs, and disciplined execution can convert these short-duration opportunities into repeatable yield. *** ## 1. The BASIS research framework: new listing effects In traditional finance, the phenomenon of Initial Public Offering (IPO) underpricing has been extensively studied. Ritter (1991) documented that IPOs in the United States were, on average, underpriced by 14.8% on their first day of trading. A related pattern can emerge in digital asset markets when a new token is listed on a major venue. During the first hours and days of a new listing, several structural factors can create abnormal pricing inefficiencies: * Information asymmetry: not all market participants have the same level of information about the new asset. Early participants who have conducted due diligence may retain an informational edge. * Fragmented liquidity: the new asset may be listed on only one or two venues initially, creating significant price discrepancies as liquidity remains thin and unevenly distributed. * Elevated volatility: the lack of established price history and the influx of speculative interest can create extreme volatility, widening bid-ask spreads and increasing dislocation frequency. * Funding rate dislocation: if a perpetual futures contract launches alongside the spot listing, funding can become materially imbalanced as the market searches for equilibrium. ## 2. What this module does Depending on the ecosystem and opportunity type, early-stage structural alpha capture may involve: * Cross-venue spatial arbitrage: exploiting price discrepancies for newly listed assets across different venues where liquidity is fragmented. * Funding rate harvesting: capturing elevated funding rates on newly launched perpetual futures contracts via delta-neutral positions. * Bridge usage and liquidity provisioning: providing liquidity to new cross-chain bridges or DEX pools that offer bootstrapping incentives. * Verified task execution: participating in on-chain incentive programs that reward specific actions such as governance participation or protocol interactions. * Reward harvesting and consolidation: systematically collecting and converting distributed rewards into portfolio base exposure. {% hint style="success" %} BASIS evaluates these opportunities through deterministic execution pipelines, proprietary routing infrastructure, and state machine risk controls designed to preserve execution precision under stressed market conditions. {% endhint %} ## 3. Research-driven filtering Not every new listing or incentive program is worth pursuing. A Research Partner-driven filter evaluates each opportunity against the following criteria before capital is deployed: | Filter Criterion | Description | Minimum Threshold | | ----------------------- | -------------------------------------------------------------------------------------- | --------------------------------------------------- | | Protocol maturity | Has the protocol been live on mainnet for a meaningful period? | > 3 months preferred | | Audit quality | Has the smart contract been audited by a reputable firm? | At least one top-tier audit | | TVL and liquidity depth | Is there sufficient Total Value Locked and order book depth? | Sufficient to absorb planned position size | | Exploit history | Has the protocol suffered any exploits or security incidents? | No unresolved incidents | | Incentive design | Is the reward structure sustainable, or is it a short-term distortion? | Sustainable tokenomics preferred | | Operational complexity | Is the effort required to capture structural alpha proportional to the expected value? | Expected value must exceed operational cost by > 2x | Opportunities that fail any critical filter are rejected regardless of their apparent yield profile. ## 4. Risk controls Emerging market opportunities require additional scrutiny. BASIS applies the following controls before any capital allocation: * Smart contract validation: newly deployed contracts undergo additional review. Only protocols meeting audit and maturity criteria are eligible. * Governance monitoring: protocol parameter changes are tracked in real time. Positions are reduced or closed if economics shift materially. * Liquidity management: position sizes are calibrated to available order book depth to minimize market impact on exit. * Incentive tracking: reward program changes are monitored continuously. Any material modification triggers an immediate position review. {% hint style="warning" %} BASIS treats this pipeline conservatively. Only verified ecosystems are eligible, position sizing is capped as a small percentage of total AUM, and stop conditions are strict. {% endhint %} ## 5. Role within the strategy matrix This module is designed to be additive and opportunistic. The core of BASIS is built on spatial arbitrage, funding streams, and established DeFi strategies that seek stable, repeatable yield sources. Emerging market capture supplements overall portfolio returns during favorable conditions and is sized accordingly. Research and execution are informed by Base58 Labs methodology, BHLE infrastructure, and deterministic market interaction principles: * Sub-50μs latency design * 100K+ OPS routing throughput * Proprietary routing infrastructure * Mathematical constraint systems for position validation * State machine risk controls for deterministic execution Users may choose their level of participation in this pipeline based on their individual preferences. # Blue-Chip DeFi Lending & LSD {% 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)). {% endhint %} DeFi lending and liquid staking markets can provide baseline yield when accessed with conservative risk controls. This pipeline is designed to diversify away from centralized exchange dependency and provide yield sources with different regime behavior. By combining on-chain yield generation with the platform's existing off-chain structural alpha and execution precision framework, BASIS maintains a more resilient and diversified revenue base. *** ## 1. Blue-Chip Lending: The Mechanics In a conservative lending strategy, the system supplies major assets such as ETH, BTC, or tokenized gold exposure through established lending and collateral protocols such as Aave, Compound, or Maker. Yield is generated from borrower demand and protocol-level interest dynamics. ### How it works 1. Capital deployment: A portion of platform-managed capital is allocated to a whitelisted protocol. 2. Supply yield: Deposited assets earn a variable rate determined by utilization and market demand. 3. Continuous monitoring: The system monitors utilization, liquidity depth, oracle quality, and protocol solvency indicators. 4. Withdrawal: When capital is required elsewhere or risk conditions change, assets are withdrawn and reallocated. {% hint style="success" %} BASIS emphasizes deterministic execution, mathematical constraints, and state-machine risk controls when interacting with on-chain venues. {% endhint %} ### Yield dynamics Lending yields are typically strongest during periods of elevated market activity and collateral demand. During expansion phases, borrowing demand often increases and pushes supply APYs higher. During quieter periods, yields generally compress. This behavior can complement other BASIS strategies and improve diversification across market regimes. ### Risk assessment | Risk Factor | Description | Mitigation | | ------------------- | ------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------- | | Smart contract risk | A vulnerability in protocol code could lead to fund loss. | Deploy only to protocols with multiple reputable audits, long operating history on mainnet, and deep liquidity. | | Oracle risk | Incorrect, manipulated, or stale pricing can distort collateral valuation and liquidation logic. | Prefer robust oracle designs with diversified data sources and monitored update quality. | | Liquidity risk | During very high utilization, withdrawals may be delayed or temporarily constrained. | Track utilization continuously and reduce exposure before critical thresholds are reached. | | Governance risk | Protocol parameters can change through governance actions. | Monitor proposals and maintain whitelist review procedures. | *** ## 2. Liquid Staking Derivative Optimization Liquid staking protocols allow users to stake assets such as ETH or SOL and receive a liquid derivative token in return. On BASIS, supported same-token swaps are: * ETH → stETH * SOL → stSOL * PAXG → stPAXG * BTC → stBTC These swaps are 1:1 within the BASIS system and are used to separate funding balances from staking balances. {% tabs %} {% tab title="Wallet model" %} * Funding Wallet: holds native tokens for deposit and withdrawal * Staking Wallet: holds stTokens for staking and reward accrual {% endtab %} {% tab title="Supported deposits" %} * BTC: deposit by copying the unique BASIS-assigned BTC address for your account * ETH / SOL / PAXG: deposit by connecting a Web3 wallet such as MetaMask or a compatible wallet {% endtab %} {% tab title="Not supported" %} * USDT deposits * Cross-token swaps * Partial unstake requests {% endtab %} {% endtabs %} ### Optimization approaches * Staking yield capture: Holding the relevant stToken captures the underlying staking reward profile. * Reinvestment and compounding: Rewards accumulate in real time as the same stToken in the Staking Wallet. * Conservative collateral usage: Where collateral strategies are used, exposure is constrained by hard risk limits and unwind logic. ### LSD-specific risks | Risk Factor | Description | Mitigation | | ----------------------- | ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------ | | Peg risk | An LSD may trade at a discount to its underlying reference asset during stress. | Monitor basis deviation and reduce exposure if discount thresholds are exceeded. | | Validator slashing risk | Validator penalties can reduce backing value. | Prefer diversified validator sets and robust staking infrastructure. | | Smart contract risk | Liquid staking protocols carry protocol and integration risk. | Apply the same maturity, audit, and monitoring requirements used for lending venues. | *** ## 3. Why "Optimization" Is a Risk Term Any recursive or leveraged structure increases tail risk materially. BASIS treats optimization as a constrained program, not unconstrained yield maximization. The constraint set includes: * Conservative collateral factors: Internal limits remain below protocol maximums. * Explicit unwind plans: Every position has a defined reduction and exit path. * Emergency stop conditions: If a monitored threshold deteriorates, the system begins controlled unwinding in accordance with platform risk policy. {% hint style="warning" %} Optimization does not mean maximum exposure. It means bounded exposure under predefined mathematical and operational constraints. {% endhint %} *** ## 4. When On-Chain Modules Are Disabled If on-chain conditions become unsafe due to gas spikes, congestion, or degraded execution quality, the platform may pause selected modules and prioritize capital preservation. In such conditions, capital may be rotated to lower-risk holdings or held in reserve pending normalized conditions. This approach is consistent with the BASIS emphasis on: * deterministic execution * execution precision * state-machine risk controls * structural alpha capture under bounded risk *** ## 5. Operational Notes for BASIS Users ### Deposits {% stepper %} {% step %} For BTC, copy your unique BASIS-assigned BTC deposit address from the Dashboard. No Web3 wallet connection is required for BTC deposits. {% endstep %} {% step %} For ETH, SOL, and PAXG, connect a supported Web3 wallet and complete the native-token deposit flow. {% endstep %} {% step %} Deposits are made in native tokens only. USDT is not supported as a deposit asset. {% endstep %} {% endstepper %} ### Swap behavior | Pair | Direction | Rate | | ------------- | ---------------------------------- | ---- | | BTC ↔ stBTC | Same-token conversion within BASIS | 1:1 | | ETH ↔ stETH | Same-token conversion within BASIS | 1:1 | | SOL ↔ stSOL | Same-token conversion within BASIS | 1:1 | | PAXG ↔ stPAXG | Same-token conversion within BASIS | 1:1 | ### Fees | Action | Fee | | ---------- | ----- | | Deposit | 0% | | Withdrawal | 0.05% | | Swap | 0.01% | ### Minimums and timing | Item | Value | | -------------------------------- | ---------------- | | Minimum deposit | No minimum | | BTC withdrawal time | 10 to 60 minutes | | ETH / SOL / PAXG withdrawal time | 1 to 10 minutes | ### Staking and unstaking * Rewards accumulate in real time as the same stToken in the Staking Wallet. * Unstake applies to the entire staked position only. * Upon unstake, the claimable amount is automatically credited to the Staking Wallet as stToken. * Fixed pools can be unstaked only after the lock-up period ends. ### Booster schedule | Lock Period | Booster | | ----------- | ---------- | | 14D | +10% | | 30D | +20% | | 90D | +50% | | 180D | +100% (2×) | *** ## 6. Infrastructure and Risk Framework BASIS combines on-chain modules with proprietary execution infrastructure and research support from Base58 Labs. Key operating characteristics: * BHLE architecture * Sub-50μs latency * 100K+ OPS routing capacity * Proprietary routing infrastructure * Deterministic execution under mathematical constraints These controls are intended to reduce operational variance and preserve strategy integrity during changing market states. If you are reviewing this pipeline, focus on: * audited protocol whitelist quality * conservative collateral parameters * explicit unwind procedures * deterministic execution controls * research-backed risk governance For support, contact . # Strategy Eligibility & Safety Rules {% 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)). {% endhint %} Eligibility rules define the mathematical boundary between executable strategy logic and unacceptable risk. BASIS applies deterministic eligibility gates so strategies run only when: * expected value remains positive under conservative assumptions * risk constraints are satisfied * execution precision remains within defined tolerances * state machine safety conditions remain valid ## 1) Universal eligibility gate A generic gate for a structural alpha capture action: $$ EV \ge 0 \quad \text{under conservative bounds} $$ Conservative bounds include: * worst-case slippage within defined percentile * maximum fee schedule * latency penalty * safety margin for volatility * settlement reliability constraints If the gate fails, the system does not execute. {% hint style="success" %} BASIS prioritizes deterministic execution over activity volume. If mathematical constraints are not met, no action is taken. {% endhint %} ## 2) Venue eligibility A venue must satisfy all of the following: * operational health, including functioning withdrawals and stable API behavior * minimum depth thresholds * fee constraints * risk score above minimum threshold * consistent settlement behavior * routing compatibility with BASIS infrastructure If a venue fails health checks, it is excluded even if quoted spreads appear attractive. Large spreads often indicate hidden execution risk, settlement impairment, or unstable market conditions. ## 3) Asset eligibility Assets are eligible only when: * liquidity is sufficient * manipulation risk is low * reliable pricing exists across venues * settlement constraints are manageable * inventory transfer paths remain operational Low-liquidity assets are excluded even if they show frequent pricing gaps. ## 4) Safety rules (stop conditions) ### Slippage inversion If slippage cost exceeds target edge, the system: * cancels the action * may enter protective mode if inversion signals market stress * tightens execution thresholds if needed ### Withdrawal halt or settlement disruption If a major venue halts withdrawals for a relevant asset, the system: * reduces new exposure * may unwind positions dependent on settlement * may suspend affected strategy paths until normal conditions return ### Abnormal price feed If oracle or feed input is inconsistent, the system: * rejects trades * isolates affected signals * may escalate to BSCB if the condition is systemic ### Infrastructure degradation If routing, latency, or execution acknowledgment falls outside accepted bounds, the system: * stops affected actions * reroutes where possible * preserves capital over throughput ## 5) Why this matters for users These safety rules explain why: * strategies may pause * reward accrual may slow temporarily * withdrawals may follow operational waiting periods depending on network and asset type These are protective behaviors of a survivable system, not failures of system design. {% hint style="warning" %} Withdrawal timing depends on the asset rail: * BTC: typically 10 to 60 minutes * ETH / SOL / PAXG: typically 1 to 10 minutes (Note: Unstaking from fixed pools requires an additional 7-day buffer before these withdrawal times apply.) {% endhint %} ## 6) System design principle BASIS is built around deterministic execution, mathematical constraints, and state machine risk controls. This includes: * conservative eligibility gating * infrastructure-aware execution precision * bounded exposure logic * fail-safe halts under abnormal conditions BHLE infrastructure supports this with: * sub-50μs latency * 100K+ OPS capacity * proprietary routing infrastructure These controls are designed to support structural alpha capture while limiting non-deterministic risk. *** For the formal state model, read: Risk to BSCB and Risk to DMM. # Parameters & Glossary {% 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 %} This page collects the core parameters that govern the behavior of BASIS strategy modules. These parameters are used to interpret execution behavior, risk controls, and pool economics. Actual values may vary by environment and may change through governed policy updates. *** ## 1. Execution Parameters These parameters control how orders are constructed and submitted to venues to maintain deterministic execution and execution precision. | Parameter | Description | Typical Range | Rationale | | -------------------------- | --------------------------------------------------------------------------- | -------------------- | --------------------------------------------------------------------------------------------------------------------------------- | | Max Slippage Bound | Maximum allowed slippage as a percentage of notional. | 3–10 bps | Prevents execution in thin order books where trading cost would impair structural alpha capture. | | Min Depth Threshold | Minimum order book depth required at target price levels. | Varies by asset | Ensures sufficient liquidity exists to absorb the order without excessive market impact. | | Hedge Completion Window | Maximum time allowed for both legs of a hedged trade to complete. | 5–60 seconds | If the second leg is not filled within this window, the first leg is reduced or unwound to avoid unintended directional exposure. | | Order Slicing Size | Child order size for iceberg or TWAP-style execution. | 5–15% of top-5 depth | Breaks large orders into smaller pieces to minimize market impact under established optimal execution models. | | Time-in-Force | Order validity policy per venue (IOC/FOK/GTC). | IOC or FOK preferred | IOC and FOK reduce stale order risk during rapid market moves. | | Max Order Size (% of Book) | Maximum size of a single order as a percentage of visible order book depth. | 5–15% | Larger orders relative to visible depth can create disproportionate price impact. | {% hint style="success" %} BHLE execution environment: sub-50μs latency, 100K+ OPS, and proprietary routing infrastructure are used to improve execution precision under real market conditions. {% endhint %} ## 2. Risk Parameters These parameters are enforced by the risk engine's pre-trade eligibility gate. No strategy module can override them. | Parameter | Description | Typical Range | Rationale | | ------------------------------ | ---------------------------------------------------------------------------------------------- | ---------------------------- | --------------------------------------------------------------------------------------------------------------- | | Exposure Cap | Maximum exposure per asset, per venue, or per strategy. | 15–30% of AUM per venue | Limits concentration and counterparty risk through capital distribution. | | Concentration Limit | Maximum percentage of total capital deployed to a single venue. | 30% max | Ensures the failure of any single venue does not create catastrophic loss. | | Stablecoin Deviation Threshold | Trigger level for stablecoin stress response in reporting and treasury controls. | > 1.5% deviation | Activates protective controls if a reference stablecoin materially deviates from expected USD-equivalent value. | | PAXG Peg Deviation Threshold | Module-specific trigger for PAXG peg stress. | > 2.0% from LBMA spot | Activates the PAXG Peg Deviation Monitor module. | | Liquidation Buffer | Safety margin maintained above the venue's maintenance margin requirement for derivative legs. | 150–300% of maintenance | Provides a cushion against sudden price movements. | | Margin Buffer Ratio | Minimum margin ratio before the system begins reducing position size. | 200% warning / 150% critical | Warning level triggers gradual reduction. Critical level triggers state-machine protective controls. | | Reconciliation Interval | Frequency of post-trade balance checks. | After every trade cycle | Ensures the internal ledger and venue balances remain aligned. | {% hint style="warning" %} Risk controls are constrained by deterministic state transitions, mathematical bounds, and pre-defined failure handling. Administrative discretion cannot bypass hard-coded safety ranges. {% endhint %} ## 3. Strategy-Specific Parameters ### 3.1 Cash-and-Carry / Delta-Neutral Funding | Parameter | Description | Typical Range | | ------------------------------ | ---------------------------------------------------------------- | -------------- | | `min_annualized_funding_rate` | Minimum annualized funding rate required to open a new position. | > 5% APR | | `max_leverage` | Maximum leverage used on the perpetual futures leg. | 1–3x | | `funding_rate_lookback` | Historical window used to calculate average funding rate. | 7–30 days | | `position_rebalance_threshold` | Delta deviation at which the hedge is rebalanced. | > 1% net delta | ### 3.2 Spatial Arbitrage | Parameter | Description | Typical Range | | ---------------------------- | ------------------------------------------------------------------------ | ------------- | | `min_cross_venue_spread` | Minimum price difference between two venues required to trigger a trade. | > 10 bps | | `max_transfer_time` | Maximum acceptable time for an asset transfer between venues. | < 30 minutes | | `inventory_rebalance_target` | Target inventory balance across venues. | 50/50 split | ### 3.3 Statistical Arbitrage | Parameter | Description | Typical Range | | ----------------------- | ----------------------------------------------------------------- | ------------- | | `cointegration_p_value` | Maximum p-value from the Engle-Granger cointegration test. | < 0.05 | | `z_score_entry` | Z-score of the spread at which a mean-reversion trade is entered. | > 2.0 sigma | | `z_score_exit` | Z-score at which the position is closed. | < 0.5 sigma | | `lookback_window` | Historical data window for estimating cointegration parameters. | 30–90 days | ## 4. Pool & Economics Parameters | Parameter | Description | Policy | | ------------------------- | -------------------------------------------------------------------- | ---------------------------------------------------------------- | | Lock-up Duration | Duration for which staked capital is committed. | 14 / 30 / 90 / 180 days | | Booster Multiplier | Bonus factor applied to yield calculation based on lock-up duration. | 14D +10%, 30D +20%, 90D +50%, 180D +100% | | Booster Reset Rule | Lock-up timer behavior when adding stake. | Full reset on new aggregated stake | | Unstaking Rule | Withdrawal behavior for fixed pools. | Unstake only after lock-up period ends | | Reward Accrual | How rewards appear during staking. | Real-time accumulation as the same stToken in the Staking Wallet | | Unstake Amount Logic | Amount selection during unstake. | Full position only, auto-MAX | | Claimable Amount Delivery | Where unstaked value is credited. | Auto-credited to the Staking Wallet as stToken | {% tabs %} {% tab title="Wallet Model" %} | Wallet | Asset Type | Primary Use | | -------------- | ------------------------------------- | ------------------------------------- | | Funding Wallet | Native tokens: BTC / ETH / SOL / PAXG | Deposit and withdrawal | | Staking Wallet | stBTC / stETH / stSOL / stPAXG | Stake, reward accrual, unstake credit | | {% endtab %} | | | {% tab title="Swap Rules" %} Swaps are same-token only at 1:1: | Asset | Staked Token | | ----- | ------------ | | BTC | stBTC | | ETH | stETH | | SOL | stSOL | | PAXG | stPAXG | Swap fee: 0.01% {% endtab %} {% tab title="Funding & Withdrawal" %} * Deposit fee: 0% * Withdrawal fee: 0.05% * Minimum deposit: No minimum * BTC withdrawal time: 10 to 60 minutes * ETH / SOL / PAXG withdrawal time: 1 to 10 minutes {% endtab %} {% endtabs %} ## 5. Referral Network Parameters | Parameter | Description | Policy Example | | ------------------ | ---------------------------------------------------------------------------------- | ------------------------- | | Contribution Scope | Reward scope based on verified referral network contribution. | Defined by program policy | | Reward Cap | Maximum total referral reward percentage under a contribution-based reward system. | Policy-bound | | Grace Period | Maintenance window for referral eligibility continuity. | Program-defined | {% hint style="info" %} BASIS does not use product tiers. Referral network logic, where applicable, is governed by contribution alignment, eligibility rules, and program caps rather than account plans. {% endhint %} ## 6. Parameter Governance Strategy parameters are not static. They are reviewed and adjusted by the Research Partner based on ongoing market analysis, execution quality review, and risk telemetry. All parameter changes are subject to strict governance: * Change Logging: Every parameter change is recorded in the audit log with a timestamp, the old value, the new value, and the reason for the change. * Bounded Ranges: Each parameter has a hard-coded minimum and maximum range. No parameter can be set outside this range, including by an administrator. * Gradual Rollout: Significant parameter changes are rolled out gradually, starting with a small allocation, to observe real-world impact before full deployment. * Control Integrity: State machine risk controls enforce parameter application at runtime. * Research Oversight: Base58 Labs supports model research, validation, and parameter review for structural alpha capture systems. ## 7. Operational Glossary | Term | Definition | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Execution Precision | The ability to achieve intended trade outcomes within bounded slippage, latency, and inventory constraints. | | Structural Alpha Capture | Return generation derived from persistent market structure, pricing inefficiencies, and disciplined routing rather than discretionary directional prediction. | | Deterministic Execution | Execution behavior constrained by explicit rules, bounded state transitions, and verifiable policy logic. | | Staking Wallet | Wallet that holds stTokens, receives real-time reward accrual, and receives unstaked value as stToken. | | Funding Wallet | Wallet that holds native tokens used for deposit and withdrawal flows. | | Same-Token Swap | A 1:1 conversion between a native token and its corresponding stToken only. | | PAXG Support | PAXG is an active supported asset across deposit, swap, staking, and withdrawal flows. | For definitions of additional technical terms, see the Glossary in the Reference section. # DEX-CEX Arbitrage Module {% 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 %} The PAXG DEX-CEX structural alpha module captures price dislocations between decentralized exchanges such as Uniswap or Curve and centralized exchanges such as Binance or Kraken. Because PAXG typically trades with thinner liquidity than major crypto pairs, spread windows can persist longer and offer measurable execution opportunities when evaluated under strict cost and inventory constraints. ## 1. Why DEX-CEX Spreads Exist for PAXG Price dislocations between DEXs and CEXs arise from differences in venue design: * AMM vs. order book: DEXs use automated market makers that price assets through pool formulas such as x \* y = k. CEXs use order books where prices are formed by matched bids and asks. These mechanisms can diverge when order flow hits one venue faster than the other. * Fragmented liquidity: PAXG liquidity is distributed across multiple venues and pool configurations. A large order on one DEX pool can move the on-chain price away from the best centralized quote. * Gas cost barrier: On Ethereum, DEX execution includes network fees. This creates a minimum profitable spread threshold below which structural alpha capture is not economical. * Latency asymmetry: CEX prices can update in milliseconds through streaming market data, while DEX prices update when state changes are confirmed on-chain. This timing difference creates short-lived execution windows. ## 2. Execution Flow {% stepper %} {% step %} #### Price monitoring The system continuously monitors PAXG reference pricing across approved DEX and CEX venues. {% endstep %} {% step %} #### Net spread calculation Gross spread is adjusted for DEX swap fees, CEX trading fees, estimated gas, expected slippage, and inventory rebalance costs. {% endstep %} {% step %} #### Eligibility check The opportunity must exceed the minimum threshold defined by the risk engine and execution policy. {% endstep %} {% step %} #### Paired execution If viable, both legs are executed with high timing precision. For example, if PAXG is cheaper on a DEX, the system buys on the DEX and sells on the CEX. {% endstep %} {% step %} #### Inventory rebalance Post-trade inventory is normalized across venues to preserve readiness for the next cycle. {% endstep %} {% endstepper %} ## 3. Cost Structure | Cost Component | Typical Range | Notes | | --------------------- | -------------- | --------------------------------------------------- | | DEX swap fee | 0.05% to 0.30% | Depends on pool design and liquidity concentration. | | CEX trading fee | 0.02% to 0.10% | Venue-specific and strategy-dependent. | | Ethereum network cost | Variable | Continuously monitored before execution. | | Slippage (DEX) | 0.10% to 0.50% | Can widen in thinner pools. | | Slippage (CEX) | 0.01% to 0.10% | Usually lower when order book depth is sufficient. | {% hint style="warning" %} Minimum viable spread: after all explicit and implicit costs are applied, only opportunities above the configured profitability threshold are eligible for execution. {% endhint %} ## 4. Risk Factors | Risk | Description | Mitigation | | ----------------------------- | ------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------ | | Execution precision risk | On-chain transactions may be displaced by competing flow before confirmation. | Use protected transaction routing, deterministic execution checks, and venue-specific timing controls. | | Smart contract risk | Interaction with DEX smart contracts introduces protocol and integration risk. | Restrict activity to reviewed, production-grade protocols and controlled routing paths. | | Network fee spike risk | Sudden Ethereum fee expansion can invalidate expected profitability. | Real-time fee monitoring with dynamic thresholds and abort logic. | | Settlement and inventory risk | Venue transfers and asynchronous settlement can create temporary imbalances. | Maintain pre-positioned inventory and enforce state-machine based inventory controls. | ## 5. Infrastructure Context BASIS execution systems are designed around deterministic execution, mathematical constraints, and state machine risk controls. Key infrastructure characteristics: * BHLE routing architecture * Sub-50μs internal latency targets * 100K+ OPS processing capacity * Proprietary routing infrastructure * Inventory-aware execution logic * Structural alpha capture under bounded risk policies {% hint style="success" %} PAXG support is live and active on BASIS. Deposits and withdrawals for PAXG use a connected Web3 wallet. In the BASIS wallet model, native assets such as PAXG are held in the Funding Wallet, while staking assets such as stPAXG are held in the Staking Wallet. Supported same-token swap path: `PAXG → stPAXG` at 1:1 {% endhint %} ## 6. Research Basis This module is informed by execution research and market structure analysis developed with the Research Partner. The operating objective is not directional speculation, but disciplined structural alpha capture through constrained execution, inventory symmetry, and repeatable venue selection logic. # Peg Deviation Monitor {% 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 %} The Peg Deviation Monitor is a live risk management module that continuously tracks the relationship between the PAXG market price on supported trading venues and the global gold reference price. Because PAXG is designed to be backed 1:1 by physical gold, any meaningful deviation between token price and underlying gold value may indicate either structural alpha capture conditions or a risk event requiring immediate control actions. *** ## 1. What is peg deviation? PAXG is designed to track the price of one fine troy ounce of gold. The primary reference is the LBMA Gold Price, which is set twice daily and serves as a global benchmark for gold pricing. In practice, the PAXG price on digital asset venues can deviate from the gold reference price for several reasons: * Supply and demand imbalance: a sudden increase in demand for PAXG on a specific venue can temporarily push the token to a premium. Heavy selling can push it to a discount. * Market hours mismatch: gold reference markets and digital asset markets do not operate under identical liquidity conditions. Because PAXG trades continuously, its market price may move when traditional gold reference markets are less active. * Redemption friction: even where redemption exists, practical redemption thresholds and operational constraints can limit immediate arbitrage alignment. * Systemic stress: during broad market stress, correlations can tighten and liquidations can affect PAXG pricing independently of gold fundamentals. ## 2. Monitoring architecture The Peg Deviation Monitor operates as a continuous control loop built for deterministic execution and state-aware risk handling. ### Process flow 1. Data ingestion\ The system ingests PAXG market prices from supported venues and compares them against the gold reference price or a real-time proxy such as XAU/USD from approved data providers. 2. Deviation calculation\ The percentage deviation is calculated as: ``` Deviation = (PAXG_Market_Price - Gold_Reference_Price) / Gold_Reference_Price × 100% ``` 3. Threshold evaluation\ The calculated deviation is compared against predefined state thresholds. 4. Risk action routing\ If thresholds are exceeded, connected modules receive updated execution constraints or position management instructions. {% hint style="success" %} This module is integrated into the broader BASIS risk state machine and supports deterministic execution, math-constrained decisioning, and controlled escalation paths. {% endhint %} ## 3. Response levels | Level | Deviation | Action | | -------- | ----------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Normal | < 0.5% | No action. Normal market fluctuation. | | Watch | 0.5% - 1.0% | Alert generated. Monitoring frequency increases. No direct trading restriction. | | Caution | 1.0% - 2.0% | New PAXG-related entries may be paused. Existing positions are monitored under tighter execution precision and risk parameters. | | Critical | > 2.0% | Protective controls are triggered across PAXG-related modules. Positions are evaluated for orderly reduction. If deviation persists or worsens, deeper defensive controls are activated. | ## 4. Interaction with other modules The Peg Deviation Monitor does not operate in isolation. Its output directly affects PAXG-related strategy behavior across the BASIS system. ### Golden BASIS If peg deviation enters the Caution zone, the Golden BASIS module may stop opening new positions. Existing positions can remain active, but under tighter monitoring and stricter execution controls. ### DEX-CEX structural alpha capture A peg deviation can itself create a structural alpha capture condition, such as local venue mispricing relative to the gold reference. However, if the deviation appears to be driven by systemic stress rather than localized liquidity imbalance, the module defers to Peg Deviation Monitor risk state outputs. ### Collateral and balance management If peg deviation enters the Caution zone, collateral-sensitive processes may reduce balance sheet exposure, increase buffers, or tighten operational thresholds to absorb adverse PAXG repricing. ## 5. Why this module matters Without a dedicated peg deviation monitor, the platform could take exposure using a PAXG market price that does not accurately reflect underlying gold value. This can lead to mispriced execution, distorted risk assessment, and avoidable losses. The Peg Deviation Monitor helps ensure that BASIS maintains an accurate understanding of the relationship between token price and underlying asset value before allowing further execution, inventory shifts, or risk expansion. {% hint style="warning" %} This module is especially important during periods of fragmented liquidity, market stress, or cross-venue dislocation, where nominal token price may temporarily diverge from underlying value. {% endhint %} ## 6. Operational status The Peg Deviation Monitor is live and active as part of the PAXG support framework on BASIS. Its purpose is to support: * deterministic risk supervision * state-based escalation logic * execution precision during PAXG dislocations * structural alpha capture only when deviation conditions remain within approved safety bounds ## 7. Infrastructure context This module operates within the broader BASIS execution and risk environment: * Seychelles IBC operator framework * LEI: [254900IX2F2KCWNSSS64](https://lei.bloomberg.com/leis/view/254900IX2F2KCWNSSS64) * research support from Base58 Labs as Research Partner * proprietary routing infrastructure designed for deterministic execution * BHLE stack targeting sub-50μs latency and 100K+ OPS capacity * state machine risk controls enforced through math-based constraints rather than discretionary overrides These controls are designed to improve reliability, reduce model drift in live conditions, and maintain disciplined handling of cross-market pricing dislocations. # Strategic Listing Proposal (Base58 Labs Note) {% 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)). {% endhint %} ## Base58 Labs Research Note, “Bridging the Gap: On‑Chain Gold & Real‑World Arbitrage” > **Operator and jurisdiction**: **BASIS** is operated by **BASIS DIGITAL INFRASTRUCTURE LTD**, a **Seychelles‑incorporated** entity. > > **Currency convention**: All amounts are denominated in **USDT** and should be interpreted as **USD‑equivalent** values. USDT may deviate from USD. see **Risk Disclosure**. > **Document purpose** This page is written as a **research‑driven listing proposal**. It is designed to be used in GitBook and/or as an announcement memo to investors and users. *** ## 0) Executive Thesis **BASIS** is expanding beyond purely crypto‑native inefficiencies into **RWA‑linked** inefficiencies. The first strategic asset in this expansion is **PAX Gold (PAXG)**, a tokenized representation of gold designed to trade 24/7 on crypto rails while referencing one of the most liquid real‑world assets: **gold**. The proposal is not “add gold because it sounds safe.” The proposal is: 1. Gold introduces a **different microstructure regime** than BTC/ETH/SOL, which improves portfolio‑level robustness for market‑neutral systems. 2. Tokenized gold introduces a **structural bridge** between TradFi reference pricing and on‑chain execution. That bridge creates measurable residuals (basis, liquidity lag, settlement frictions). 3. PAXG, among tokenized gold options, offers a **trust + transparency profile** that aligns with **BASIS**’ identity: * Research‑Driven * Mathematically Verified (constraint‑based) * Trust‑first (auditable, observable) *** ## 1) Why Gold? (Why add a “safe‑haven” reference asset) Crypto markets are dominated by high‑beta, risk‑on assets. A market‑neutral system is strongest when it can: * reduce concentration of risk factors, * diversify opportunity sources across regimes, * and maintain “capital preservation” under stress. Gold matters because it often behaves as a **risk‑off reference asset** relative to crypto risk regimes. Even when gold does not “rise,” its volatility profile and market structure differ from crypto, which creates two system‑level advantages: ### 1.1 Diversification of residuals (where alpha lives) Base58 Labs’ core principle is that alpha exists in residuals, what remains after you remove common factors. Adding PAXG adds a new factor structure: * different liquidity providers, * different investor motive, * different response to macro news, * and different “settlement narrative” (gold is not a protocol token). This diversifies the residual opportunity set, which reduces reliance on any single market regime. ### 1.2 RWA “bridge opportunities” are microstructure opportunities Tokenized gold is not only an asset. it is a **bridge**: * a TradFi reference (gold price discovery) * expressed through crypto rails (exchanges, DEX pools, perps) Bridges create friction. Friction creates spreads. Spreads create arbitrage surfaces. *** ## 2) Why PAXG (and not “any gold token”) There are multiple tokenized gold products. **BASIS** selects PAXG because our selection framework prioritizes **trust‑weighted expected value**. In arbitrage, expected value is not just spread minus fees, it is: $$ EV \approx Edge - Costs - (Tail\Risk\Premium) $$ The tail risk premium depends heavily on: * issuer transparency and reporting, * operational clarity of redemption rules, * and market adoption / integration quality. ### 2.1 Trust and transparency are not “nice to have” A tokenized RWA introduces issuer‑linked risk surfaces: * custody attestations * operational redemption constraints * potential regulatory actions * token control features (e.g., freeze/upgrade functions) Therefore, we select the product whose trust surfaces are most auditable. ### 2.2 What we like about PAXG (high level) PAXG aligns with a trust‑first framework because it provides: * public transparency reporting (e.g., monthly attestations / reserve reports) * allocation lookup mechanisms (gold bar allocation reference) * broad exchange availability and DeFi integration discussion in major protocols > This is not a claim of “risk‑free issuer.” It is a claim of **higher observability**, which is essential for mathematically verified risk controls. *** ## 3) PAXG vs XAU₮ (Tether Gold): a risk‑premium comparison The goal is not to “attack” alternatives. The goal is to quantify tail‑risk premium. **BASIS**’ comparison lens: * **Regulatory posture** (what oversight exists?) * **Transparency cadence** (how often do attestations/reports occur?) * **Redemption clarity** (what are the operational constraints?) * **DeFi composability** (is the asset used as collateral in credible contexts?) If PAXG provides higher observability on these dimensions, its tail‑risk premium is lower, which improves trust‑weighted EV. See: **PAXG vs XAU₮: A Risk‑Premium Comparison**. *** ## 4) **BASIS** Arbitrage Mechanics: how PAXG is used **BASIS** does not add PAXG as a passive “hold.” PAXG becomes a strategic input for multiple market‑neutral modules. ### Module A, “Golden **BASIS**”: spot–perp delta‑neutral funding capture **Structure (conceptual):** * Spot long PAXG * Perp short PAXG (or gold‑linked perp exposure where available) Objective: * reduce directional exposure * capture funding payments and/or basis convergence when synthetic gold demand creates funding distortions ### Module B, RWA Liquidity Arbitrage: DEX–CEX Tokenized gold can exhibit short‑term peg deviations due to: * DEX liquidity depth limitations * on‑chain execution costs (gas/MEV) * rapid order flow bursts **BASIS** can capture deviations only when: * net EV remains positive after costs and conservative slippage bounds * and the system can unwind safely ### Module C, Collateral Yield Optimization (Pristine Collateral Hypothesis) In many DeFi contexts, collateral quality matters more than yield. PAXG can serve as a high‑quality collateral candidate in conservative lending frameworks, allowing: * baseline collateral yield (supply APY) * optional borrowing to redeploy into other market‑neutral modules (only under strict risk caps) This is a capital efficiency tool, not a use invitation. ### Module D, Peg Deviation Monitor (Research Surface) Even if **BASIS** does not trade peg deviations aggressively, measuring them is research value: * deviations reflect liquidity stress * and can serve as early warning signals for risk regime shifts *** ## 5) The ecosystem vision: Tokenized Gold Standard inside **BASIS** PAXG enables three user‑facing narratives that are actually grounded in system mechanics: ### 5.1 Inflation hedge zone (portfolio construction) Users who do not want pure crypto exposure can allocate to a gold‑linked token while still participating in market‑neutral yield infrastructure. ### 5.2 Hybrid liquidity layer (TradFi ↔ DeFi) PAXG is a gateway asset that brings TradFi reference value into DeFi rails. **BASIS** becomes an execution layer that can arbitrage and optimize that bridge. ### 5.3 24/7 gold trading TradFi gold venues have session boundaries. Crypto venues are continuous. This mismatch can create residual opportunities during off‑hours and weekends. *** ## 6) Risk controls: the proposal is only valid with controls PAXG adds new risk categories. Therefore the listing requires: * PAXG‑specific eligibility rules * PAXG risk addendum disclosure * BSCB triggers for issuer/peg/chain stress * DMM procedures for on‑chain congestion and venue incidents See: **PAXG Risk Addendum** and **Integration Plan & Rollout**. *** ## 7) Verdict PAXG listing is not a “token add.” It is an expansion of **BASIS**’ strategy surface into a new residual domain: * the intersection of gold (RWA reference), crypto rails (24/7 markets), and execution science. It strengthens the platform’s identity: * **Research‑Driven**: new measurable residuals * **Mathematically Verified**: constraint‑driven eligibility and controls * **Trust**: auditable transparency and explicit failure modes *** If you want the operational next step: read **Integration Plan & Rollout**. ## References (issuer / public sources) * Paxos, PAXG product overview: * Paxos, PAXG transparency / reserve reports: * Tether, XAU₮ attestation announcement (example): * Aave governance, PAXG collateral discussion (historical): # PAXG Listing Rationale {% 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 %} The decision to integrate PAX Gold (PAXG) into the BASIS platform reflects a strategic expansion into tokenized hard-asset exposure with distinct market structure, execution behavior, and structural alpha capture potential. This page explains the rationale. *** ## 1. Why Gold? The Macro Case Gold has served as a store of value for centuries. Within a digital asset execution platform, gold introduces a differentiated asset class with market behavior that is not fully synchronized with BTC, ETH, or SOL. ### Key reasons * Low correlation to major crypto assets: Gold pricing is influenced by inflation expectations, interest-rate policy, reserve demand, and geopolitical repricing. This creates diversification in opportunity flow. * Structural inefficiency: The tokenized gold market remains less mature than core crypto derivatives markets, which can result in more persistent pricing dislocations. * Expanding market depth: As tokenized gold adoption grows, liquidity improves across spot venues, settlement rails, and derivatives infrastructure, increasing the addressable set of execution opportunities. {% hint style="success" %} PAXG is live and active on BASIS. Users can deposit native PAXG via a connected Web3 wallet and swap 1:1 into stPAXG for staking. {% endhint %} *** ## 2. Why PAXG and Not XAUT? Both PAXG and XAUT are gold-backed tokens, but they differ meaningfully in issuer structure, transparency, and operational confidence. For BASIS, PAXG provides the stronger fit. | Criterion | PAXG (Paxos) | XAUT (Tether Gold) | | ------------------------ | -------------------------------------------------------------------------------- | ----------------------------------------------------------- | | Regulatory profile | Issued under a more established regulated trust structure | Less institutionally transparent by comparison | | Reserve verification | Regular third-party attestations | Reserve reporting framework differs | | Gold custody disclosures | Clear bar allocation and custody framework | Less granular public bar-level disclosure | | Redemption structure | Established redemption framework through issuer channels | Different minimums and procedures | | Operational transparency | Stronger market perception for transparency and controls | More questions historically around broader issuer structure | | Platform suitability | Better aligned with deterministic risk controls and institutional infrastructure | Less aligned with BASIS listing criteria | For a platform centered on deterministic execution, risk-bounded state transitions, and institutional-grade operating standards, PAXG is the more suitable asset. *** ## 3. Structural Alpha Capture Opportunities Specific to PAXG PAXG introduces several venue and product-specific opportunities that differ from crypto-native assets. ### Core opportunity types * Spot-perpetual basis trading: Cash-and-carry style positioning applied to PAXG-linked derivatives where supported by market structure and funding conditions. * DEX-CEX dislocation capture: Price differences between decentralized liquidity pools and centralized venues. * Cross-exchange spatial arbitrage: Temporary price divergence for PAXG across centralized venues. * Cross-asset relative value: Statistical deviations involving gold-crypto ratios, including BTC/PAXG and ETH/PAXG relationships. * Collateral efficiency strategies: PAXG can participate in broader capital routing frameworks where risk controls and settlement conditions permit. {% hint style="warning" %} BASIS does not expose strategy internals in full detail. Execution logic, routing, and venue selection are governed by proprietary infrastructure designed for execution precision and structural alpha capture. {% endhint %} *** ## 4. Why PAXG Fits the BASIS Architecture PAXG is not listed simply as an additional asset. It is included because it is compatible with the platform's execution and control framework. ### Platform alignment * Deterministic execution paths under constrained state transitions * Math-based allocation logic and bounded risk parameters * State machine risk controls for position lifecycle management * Proprietary routing infrastructure designed for execution precision * BHLE performance characteristics: sub-50μs latency, 100K+ OPS throughput * Research support informed by Base58 Labs, referenced as a Research Partner This makes PAXG suitable not just as a passive store-of-value representation, but as an asset that can be integrated into a controlled, measurable execution environment. *** ## 5. User Handling on BASIS PAXG support on BASIS follows the standard wallet architecture. {% tabs %} {% tab title="Deposit" %} * Go to Dashboard → Assets * Select PAXG * Connect a supported Web3 wallet such as MetaMask * Approve and submit the native PAXG deposit PAXG deposits use connected wallet flow. Unlike BTC, there is no copy-only assigned address flow for PAXG. {% endtab %} {% tab title="Swap" %} * Native PAXG can be swapped only 1:1 into stPAXG * Swap fee: 0.01% * Supported mapping: PAXG → stPAXG only Cross-token swaps are not supported. {% endtab %} {% tab title="Staking" %} * stPAXG is held in the Staking Wallet * Rewards accumulate in real time as stPAXG * Booster options: * 14D: +10% * 30D: +20% * 90D: +50% * 180D: +100% (2×) * Fixed pools can be unstaked only after the lock-up period ends * Unstake is full-position only * Upon unstake, the claimable amount is automatically credited to the Staking Wallet as stPAXG {% endtab %} {% endtabs %} *** ## 6. Operational Parameters | Item | PAXG | | ----------------------- | --------------------------------------------------------- | | Deposit method | Web3 wallet connection | | Depositable asset | Native PAXG only | | Internal staking asset | stPAXG | | Swap ratio | 1:1 only | | Deposit fee | 0% | | Withdrawal fee | 0.05% | | Swap fee | 0.01% | | Typical withdrawal time | 1–6 minutes | | Wallet model | Funding Wallet for native PAXG, Staking Wallet for stPAXG | *** ## 7. Risk Considerations PAXG introduces asset-specific considerations that are managed through the BASIS control framework. ### Primary risks monitored * Peg deviation risk: PAXG can trade at a premium or discount relative to reference gold pricing * Market-hours liquidity variation: Gold-linked liquidity conditions can differ depending on global trading sessions * Venue fragmentation: Tokenized gold markets may show uneven depth across venues * Issuer and regulatory event risk: Changes affecting the issuer can alter trading conditions or availability * Settlement path variability: On-chain and venue-specific transfer conditions can affect timing and execution quality These risks are managed through deterministic controls, exposure thresholds, and state-aware execution logic rather than discretionary intervention. {% hint style="info" %} Trust on BASIS is based on observable process discipline: deterministic execution, mathematical constraints, bounded transitions, and infrastructure designed to reduce operational ambiguity. {% endhint %} *** ## 8. Conclusion PAXG is live on BASIS because it expands the platform into a differentiated, institutionally legible asset class with favorable characteristics for structural alpha capture. Its transparency profile, hard-asset linkage, and compatibility with deterministic risk controls make it a strong fit for the BASIS execution environment. # Why PAXG (and not only BTC/ETH/SOL) {% 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)). {% endhint %} This page explains why adding PAXG is strategically consistent with BASIS as a market-neutral execution platform focused on deterministic execution, structural alpha capture, and system robustness. ## 1) BASIS is a system, not a single-asset strategy BASIS does not depend on directional exposure to crypto markets. It is designed to capture structural inefficiencies through execution precision across fragmented venues and settlement environments. Core sources of structural alpha include: * spatial spreads * funding differentials * liquidity fragmentation * cross-venue settlement asymmetries An asset is added only when it introduces distinct inefficiency surfaces or improves portfolio-level resilience. PAXG does both. ## 2) Gold changes the factor model BTC, ETH, and SOL share several overlapping market characteristics: * crypto risk-on and risk-off sentiment * correlated volatility regimes * overlapping venue concentration * shared market maker and liquidity routing networks Gold-linked exposure behaves differently across many macro environments. That matters because BASIS is built for regime robustness, not asset concentration. Adding PAXG broadens the opportunity set without relying on the same factor cluster that dominates core crypto assets. ## 3) PAXG expands the structural alpha surface PAXG introduces execution environments that differ meaningfully from BTC, ETH, and SOL. Examples include: * CEX order book versus DEX pool pricing gaps * on-chain gold demand versus reference market pricing * derivative funding distortions * settlement timing differences between on-chain transfer and exchange ledger movement * liquidity fragmentation across tokenized commodity venues These are precisely the types of residual pricing environments targeted by the research framework supporting BASIS. {% hint style="success" %} Research foundation: BASIS integrates a research-driven approach informed by Base58 Labs, with emphasis on math-constrained execution, state machine risk controls, and deterministic strategy deployment. {% endhint %} ## 4) Why not just use stablecoins? Stablecoins are useful for internal accounting and quote normalization, but they do not create the same kind of distinct execution surface. PAXG contributes something different: * exposure linked to a non-crypto reference asset * continuous tradability in digital market infrastructure * composability across on-chain environments * a distinct trust and settlement profile This makes PAXG operationally valuable in ways that go beyond simple accounting stability. ## 5) PAXG market context PAXG is now fully active on BASIS and is supported as a native asset for wallet connectivity, swapping, staking, and withdrawal. Within BASIS, PAXG follows the same core asset logic as ETH and SOL: {% tabs %} {% tab title="Deposit" %} Connect a supported Web3 wallet to deposit PAXG. {% endtab %} {% tab title="Swap" %} Swap is same-token only at a 1:1 ratio: `PAXG → stPAXG` {% endtab %} {% tab title="Staking" %} Rewards accumulate in real time as stPAXG in the Staking Wallet. {% endtab %} {% tab title="Withdrawal" %} PAXG withdrawals are typically completed in 1 to 10 minutes. {% endtab %} {% endtabs %} ## 6) PAXG is a useful control-discipline asset Because PAXG is linked to real-world gold exposure, it requires tighter operational discipline across multiple control layers. That includes: * issuer risk handling * redemption-path awareness * liquidity condition monitoring * chain congestion handling * peg deviation surveillance * venue-specific execution constraints A platform that can support PAXG cleanly is a platform that has matured beyond simple crypto-native routing. This aligns with the design principles of BASIS: * deterministic execution * formal risk constraints * state-machine-based control logic * infrastructure-led reliability ## 7) Why this fits BASIS infrastructure BASIS is not structured around narrative-driven asset expansion. Asset support must align with execution architecture. PAXG fits because BASIS is built on infrastructure intended for high-integrity routing and market-neutral deployment: * sub-50μs latency design * 100K+ OPS throughput architecture * proprietary routing infrastructure * deterministic execution controls * structural alpha capture across fragmented liquidity PAXG therefore strengthens the system not by adding hype exposure, but by adding a differentiated market surface that can be processed under the same risk and execution framework. *** If you want the full research framing, read the Strategic Listing Proposal. # PAXG vs XAU₮: A Risk-Premium Comparison {% 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 %} This is a risk-premium comparison, not a marketing attack. In arbitrage, an asset with lower tail-risk premium can be superior even if its headline liquidity appears smaller. ## 1) The selection framework Research Partner evaluates tokenized real-world assets using four criteria: 1. Regulatory posture and governance clarity 2. Transparency cadence and reporting quality 3. Redemption and operational clarity 4. Composability and ecosystem integration We prefer assets that maximize observability. ## 2) Summary comparison table | Dimension | PAXG (Paxos) | XAU₮ (Tether Gold) | Why it matters for BASIS | | --------------------------------- | --------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- | | Issuer regulatory status | Paxos Trust Company, regulated by NYDFS | Tether Limited, registered in the British Virgin Islands, not under an equivalent banking-grade regulator | A regulated custodian reduces counterparty tail-risk and improves suitability for institutional participation | | Physical gold backing | 1 PAXG = 1 troy oz of LBMA-accredited Good Delivery gold bullion, stored in Brink's vaults (London) | 1 XAU₮ = 1 troy oz of physical gold. Redemption requires a high minimum threshold | Redemption accessibility affects liquidation floor value under stress | | Minimum redemption unit | 0.01 PAXG | 430 XAU₮ | Lower minimum improves practical peg defense for small to medium strategies | | Reporting and attestation cadence | Monthly reserve attestation reports by an independent accountant | Quarterly attestation, with less consistent historical cadence | Higher reporting frequency improves anomaly detection and monitoring confidence | | On-chain composability (Ethereum) | Broad Ethereum integration across major DeFi venues | More limited DeFi integration | Structural alpha capture modules rely on on-chain liquidity depth and reliable collateral pathways | | Market footprint | Material adoption across tokenized gold markets | Material adoption across tokenized gold markets | Relative depth matters for execution precision and liquidity resilience | | Tokenized gold market context | Active participant in a growing tokenized gold segment | Active participant in a growing tokenized gold segment | Expanding market structure can improve strategy breadth over time | | Key DeFi yield surface | Broader Ethereum-native liquidity and collateral utility | Narrower yield surface | External liquidity venues can reduce carry friction for gold exposure | | Chain presence | Ethereum (ERC-20) | Ethereum (ERC-20) and Tron (TRC-20) | Multi-chain presence adds operational complexity. BASIS supports PAXG as an active asset | > Source notes: Market footprint, composability, and reporting posture should be validated against current issuer disclosures, venue integrations, and public governance records before operational use. Summary: PAXG's regulated issuer structure, lower minimum redemption, more frequent attestations, and deeper Ethereum composability make it the lower tail-risk premium choice for BASIS' market-neutral execution model. XAU₮ is a legitimate gold-backed token but introduces higher counterparty opacity and greater DeFi liquidity friction in relevant strategy contexts. ## 3) The key idea: tail-risk premium must be priced Even if two assets are both gold-backed, their risk surfaces differ. Examples of tail-risk surfaces: * opacity of custody proofs * unclear redemption constraints * issuer administrative controls such as freezes or upgrades * regulatory actions affecting issuer operations BASIS should prefer the asset whose risk surfaces are: * measurable * monitorable * documentable ## 4) Why this matters to users Users do not just want yield. They want confidence that: * risk is understood * failure modes are explicit * the system pauses safely under uncertainty {% hint style="success" %} PAXG is live and active on BASIS. Supported asset flow: * Deposit PAXG by connecting a Web3 wallet * Swap only 1:1 from PAXG to stPAXG * Stake stPAXG to receive real-time rewards in the Staking Wallet * Unstake returns the full position only, with claimable stPAXG auto-credited to the Staking Wallet after the mandatory 7-day unstaking buffer. {% endhint %} ## 5) Operational relevance on BASIS PAXG is supported within BASIS infrastructure under deterministic execution and state-machine risk controls. Key platform constraints: | Item | BASIS handling | | --------------------- | ------------------------------------------------ | | Deposits | Native PAXG only via connected Web3 wallet | | Withdrawals | Native PAXG only | | Internal display unit | USDT for accounting and dashboard reporting only | | Swap path | PAXG → stPAXG only, 1:1 | | Funding Wallet | Holds native PAXG for deposit and withdrawal | | Staking Wallet | Holds stPAXG for staking and reward accrual | | Reward format | Real-time accumulation as stPAXG | | Unstake behavior | Full position only | | Withdrawal timing | 1 to 10 minutes under normal conditions | | Fees | Deposit 0%, Withdrawal 0.05%, Swap 0.01% | This architecture aligns with BASIS design priorities: * deterministic execution * math-constrained accounting * explicit asset-state separation * structural alpha capture through controlled routing infrastructure BHLE infrastructure characteristics include sub-50μs latency, 100K+ OPS throughput, and proprietary routing systems designed for execution precision under constrained state transitions. *** If you want the full operational treatment, read PAXG Risk Addendum. ## References * Paxos, PAXG product overview: * Paxos, PAXG transparency and reserve reports: * Tether, XAU₮ attestation and issuer materials: * Aave governance, historical PAXG collateral discussion: # Arbitrage Modules {% 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)). {% endhint %} This section documents how PAXG is used inside BASIS. The purpose is to define active modules, eligibility conditions, risk sources, and required control layers. It does not constitute a promise of returns. *** ### Module Overview | # | Module | Strategy | Status | Risk Level | | - | ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------ | ---------------- | | 1 | Golden BASIS (Spot-Perp) | Capture funding and basis differentials while minimizing directional exposure through deterministic hedging logic. | Active | Low-Medium | | 2 | RWA Liquidity Arb (DEX-CEX) | Capture short-term pricing dislocations between on-chain pools and centralized venues using structural alpha capture. | Active | Medium | | 3 | Collateral Yield Optimization | Use PAXG as conservative collateral in vetted lending environments to improve capital efficiency. | Active | Medium | | 4 | Peg Deviation Monitor | Measure peg stress, liquidity fragmentation, and venue dispersion. Execute only when strict expected-value gates and execution precision conditions are satisfied. | Active | Low (Monitoring) | ### How the Modules Work Together The four modules operate as an integrated system. Module 4, Peg Deviation Monitor, functions as a safety layer for the other modules. It continuously monitors the PAXG price relative to reference gold pricing and triggers protective actions when deviation, spread instability, or liquidity deterioration exceed permitted thresholds. Modules 1 and 2 are the primary structural alpha engines. * Module 1 captures funding-rate and basis differentials when PAXG perpetual markets trade away from spot reference levels while maintaining constrained directional exposure. * Module 2 captures cross-venue price discrepancies caused by fragmented liquidity between decentralized venues and centralized exchanges. Module 3 is a capital-efficiency layer. Capital not actively allocated to Modules 1 and 2 may be routed into vetted lending environments where risk constraints, collateral parameters, and withdrawal conditions remain within BASIS control tolerances. {% hint style="success" %} PAXG support is live on BASIS. * Deposit asset: PAXG * Deposit method: connect a Web3 wallet such as MetaMask * Swap path: PAXG ↔ stPAXG only, 1:1 * Rewards accrue in real time as stPAXG in the Staking Wallet * Unstake is full-position only after the selected lock-up period ends {% endhint %} ### Gold-Specific Risk Considerations PAXG introduces risk factors that differ from crypto-native asset strategies. | Risk Factor | Description | Mitigation | | ----------------------------- | -------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------- | | Gold Market Hours | Reference gold markets operate on specific schedules. PAXG pricing behavior may differ during active market hours and off-hours. | Modules adjust quoting thresholds, hedge tolerances, and participation rules by market session. | | Redemption Constraints | PAXG redemption into physical gold depends on issuer processes, minimum thresholds, and settlement timing. | Modules do not depend on physical redemption as an exit path. | | Correlation Regime | Gold and digital asset markets can shift between low, moderate, and inverse correlation regimes during macro stress. | Modules monitor rolling correlation, spread persistence, and hedge efficiency before capital activation. | | Venue Liquidity Fragmentation | On-chain and centralized market depth can diverge materially during volatility. | Routing logic uses deterministic execution rules, venue scoring, and state-based participation controls. | | Oracle and Reference Drift | Reference pricing inputs may momentarily diverge across data sources. | Execution requires cross-check validation, tolerance bands, and fail-closed state machine controls. | ### Control Framework Each module inherits the global BASIS risk state machine and module-specific eligibility filters. The control architecture emphasizes: * deterministic execution * mathematical constraint checks * state machine risk controls * structural alpha capture rather than directional speculation * execution precision through proprietary routing infrastructure BASIS trading and routing infrastructure is informed by Base58 Labs research and BHLE design principles, including sub-50μs latency targets, 100K+ OPS processing capability, and deterministic venue selection under constrained risk states. ### Wallet and Asset Handling for PAXG | Function | Rule | | --------------- | --------------------------------------------------- | | Deposit | Connect a Web3 wallet and deposit native PAXG | | Funding Wallet | Holds native PAXG for deposit and withdrawal | | Staking Wallet | Holds stPAXG for staking and reward accumulation | | Swap | PAXG → stPAXG and stPAXG → PAXG only, 1:1 | | Display Unit | USDT is used internally for accounting display only | | Withdrawal Fee | 0.05% | | Swap Fee | 0.01% | | Deposit Fee | 0% | | Withdrawal Time | Typically 1–6 minutes for PAXG | ### Next Step Choose a module page below to review detailed mechanics, eligibility rules, execution constraints, and risk controls for each PAXG module. # Module 1: Golden BASIS (Spot-Perp) {% 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 %} ## 1) Objective The Golden BASIS module is designed to capture structural alpha from a market-neutral PAXG basis position. This is a classical cash-and-carry framework applied to tokenized gold, with deterministic execution and strict state-machine risk controls. ## 2) The Layman's Guide: Earning Yield on Gold Exposure Imagine you hold tokenized gold (PAXG). Instead of leaving it idle, the strategy pairs that long spot exposure with an offsetting short perpetual position of the same size. This reduces directional gold price exposure while allowing the strategy to collect the spread generated by the derivatives market structure. In simple terms: * Hold PAXG exposure * Short the corresponding perpetual market * Keep the position balanced * Earn when market structure remains favorable after costs The goal is not to predict where gold goes next. The goal is to extract value from the pricing relationship between spot and perpetual markets with high execution precision. ## 3) The Professional's View: Capturing the Basis Premium This strategy performs when the perpetual market trades in contango, meaning the perpetual contract is priced above spot on a sustained basis. In that state, a hedged long-spot / short-perp structure can earn recurring carry, subject to venue costs, borrow terms, execution quality, and market microstructure. The position is constructed as follows: * Long leg: Acquire spot PAXG * Short leg: Simultaneously short an equivalent notional of the PAXG perpetual contract This creates a delta-neutral structure. Spot and perpetual P\&L largely offset each other, leaving the strategy's net result primarily driven by basis capture, execution quality, and cost control. ### Mathematical Formulation A simplified representation of expected carry is: $$ Expected\_Carry \approx Position\_Value \times Net\_Basis\_Yield $$ Where: * `Position_Value` is the deployed PAXG notional * `Net_Basis_Yield` reflects the observed basis premium after transaction costs, slippage, venue fees, and hedge maintenance costs BASIS activates this module only when expected annualized carry exceeds predefined operational and risk thresholds. ## 4) Why This Is a Core BASIS Strategy * Structural alpha: The spread between spot and perpetual markets is a persistent market structure feature rather than a discretionary directional view. * Low directional sensitivity: The hedge is designed to minimize gold price exposure and isolate carry. * Institutional execution profile: The strategy benefits from deterministic execution, mathematical constraints, and routing discipline. * Production scalability: With sufficient market depth, the structure can be deployed systematically across favorable windows. {% hint style="success" %} Execution standard: BASIS uses proprietary routing infrastructure built for sub-50μs latency, 100K+ OPS handling, and deterministic hedge maintenance. This is central to preserving execution precision in spread-dependent strategies. {% endhint %} ## 5) Primary Risks and Controls | Risk | Description | BASIS Control Mechanism | | ------------------------------ | ------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------- | | Basis compression or inversion | The spread narrows materially or turns unfavorable, reducing or reversing expected carry. | Eligibility gate: the module activates only above minimum projected return thresholds and de-risks when spread persistence fails. | | Liquidation risk | A sharp move in PAXG can stress the short perpetual leg if margin buffers are insufficient. | Liquidation guard: conservative leverage, margin buffer requirements, and automatic exposure reduction under pressure states. | | Hedge mismatch | Spot and perpetual legs may not remain perfectly aligned because of slippage, market fragmentation, or venue conditions. | Hedge integrity monitor: continuous notional reconciliation, tolerance bands, and auto-rebalance logic. | | Execution slippage | Poor fills can erode spread capture, especially during volatility or thin books. | BHLE routing: proprietary infrastructure optimizes fill quality, queue placement, and timing to protect execution precision. | | Venue and operational risk | Exchange outages, API degradation, or settlement constraints can disrupt hedge maintenance. | State-machine failovers: strategy pauses, exposure caps, and controlled unwind procedures under degraded conditions. | ## 6) Operational Notes for BASIS Users {% tabs %} {% tab title="Deposits" %} For PAXG, deposits are live and active through a connected Web3 wallet. Steps: 1. Go to Assets 2. Connect your Web3 wallet 3. Select PAXG 4. Confirm the deposit transaction 5. Funds arrive in your Funding Wallet Notes: * PAXG is supported as a native deposit asset * USDT is display-only and cannot be deposited * Funding Wallet holds native assets such as PAXG * Staking Wallet holds stTokens used for earning {% endtab %} {% tab title="Swap" %} PAXG can be swapped only 1:1 into stPAXG. * PAXG → stPAXG only * Same-token conversion only * Swap fee: 0.01% This module uses the same asset identity throughout the flow, with stPAXG representing the staking-side receipt asset. {% endtab %} {% tab title="Rewards" %} Rewards accumulate in real time as stPAXG in the Staking Wallet. Key rules: * Rewards accrue continuously * Unstake is full-position only * Claimable amount is auto-credited to the Staking Wallet as stPAXG upon unstake * Fixed pools can be unstaked only after the lock-up period ends {% endtab %} {% endtabs %} ## 7) Research and Infrastructure Context BASIS combines: * Seychelles IBC operating structure * LEI [254900IX2F2KCWNSSS64](https://lei.bloomberg.com/leis/view/254900IX2F2KCWNSSS64) * Research support from Base58 Labs as Research Partner * Deterministic execution architecture for structural alpha capture * Math-constrained risk engines and state-machine controls These elements are intended to reduce operational ambiguity and improve consistency in spread-based strategies where execution quality matters as much as signal quality. *** ### References \[1] Binance. (2024). "What Are Funding Fees in Crypto Futures Trading?" Binance Academy. # Module 2: RWA Liquidity Arb (DEX-CEX) {% 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)). {% endhint %} ## 1) Objective Capture short-term price discrepancies between: * DEX pools (on-chain pricing) * CEX orderbooks (off-chain pricing) for PAXG. This module exists because DEX pricing is influenced by: * pool liquidity depth * swap flow bursts * on-chain execution costs * execution precision conditions CEX pricing is influenced by: * centralized orderbook liquidity * faster matching engines * market maker inventory constraints These two environments do not update identically. ## 2) The basic trade A typical pattern: * Buy PAXG where it is undervalued, for example on a DEX * Sell PAXG where it is overvalued, for example on a CEX Or reverse the direction when the deviation moves the other way. ## 3) Why this is hard, and why BASIS can do it DEX–CEX arbitrage typically fails for individuals because: * network fee spikes can erase expected profit * execution can be displaced by competing order flow * confirmation timing can introduce delay * slippage can expand quickly in shallow pools BASIS treats this as a research-driven module with strict eligibility controls supported by Base58 Labs research and deterministic execution infrastructure: * trades run only when net expected value remains positive after worst-case cost and slippage bounds * on-chain execution uses atomic or revertable patterns where available * the module pauses under chain congestion or execution precision stress conditions through state-machine risk controls * routing decisions are constrained by mathematical thresholds rather than discretionary judgment {% hint style="success" %} Infrastructure basis: * BHLE routing stack * Sub-50μs latency * 100K+ OPS processing capability * Proprietary routing infrastructure * Deterministic execution and bounded-risk state transitions {% endhint %} ## 4) Eligibility constraints Examples of eligibility filters include: | Constraint | Purpose | | ------------------------------------------------- | --------------------------------------------------- | | Minimum pool liquidity and depth | Avoid thin venues and unstable execution | | Maximum allowed network fee bound | Preserve positive expected value | | Minimum spread above total cost and safety margin | Filter false opportunities | | Execution precision indicators below threshold | Reduce adverse routing conditions | | Stable venue transfer and settlement status | Prevent trapped capital during cross-venue activity | ## 5) Primary risks * on-chain congestion and fee spikes * structural alpha capture degradation from adverse order flow * partial execution risk * CEX transfer or settlement constraints * sudden liquidity withdrawal in PAXG pools ## 6) Risk controls * on-chain execution via revertable transactions where possible * fee bounds and timeout controls * automatic protection triggers during chain stress or abnormal slippage * deterministic monitoring and pause logic when repeated failures occur * state machine risk controls that prevent invalid execution paths ## 7) Operational posture This is a selective module, not a constant-activation strategy. BASIS activates it only when market structure, execution precision, and settlement conditions align within strict bounds. The goal is not aggressive turnover. The goal is controlled structural alpha capture with deterministic execution quality. {% hint style="warning" %} PAXG support is active on BASIS. Deposits and withdrawals for PAXG use a connected Web3 wallet. PAXG can be swapped only 1:1 into stPAXG within the platform. Rewards accumulate in real time as stPAXG in the Staking Wallet. {% endhint %} # Module 3: Collateral Yield Optimization {% 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)). {% endhint %} The PAXG Collateral Yield module converts tokenized gold from a passive holding into an active source of return by using PAXG as collateral in decentralized lending venues. This allows BASIS to preserve gold exposure while allocating borrowed capital into controlled structural alpha capture strategies. The objective is not directional trading on gold. The objective is capital efficiency under strict risk constraints, deterministic execution rules, and continuous collateral monitoring. *** ## 1. Core Mechanism In traditional markets, physical gold does not generate native cash flow. Tokenized gold changes this because PAXG can be posted as onchain collateral. The strategy follows a constrained sequence: 1. Supply PAXG as collateral to an approved lending venue. 2. Borrow against that collateral at conservative loan-to-value levels. 3. Route borrowed capital into BASIS execution systems designed for structural alpha capture. 4. Retain the spread between realized strategy return and borrowing cost, subject to risk limits and market conditions. {% hint style="success" %} PAXG is fully supported on BASIS. * Deposit asset: PAXG * Receipt asset: stPAXG * Swap path: PAXG ↔ stPAXG only, at 1:1 * Deposit method: Web3 wallet connection required {% endhint %} ### Example workflow | Step | Action | Illustrative Amount | | ---- | ------------------------- | ---------------------------------------- | | 1 | Post collateral | 10 PAXG | | 2 | Borrow against collateral | USD-equivalent value at conservative LTV | | 3 | Deploy borrowed capital | BASIS market-neutral execution stack | | 4 | Realize spread | Strategy return minus financing cost | The user retains exposure to the underlying gold price through PAXG while the collateral is used in a controlled capital efficiency framework. *** ## 2. Conservative LTV Policy Loan-to-value management is the primary control variable in this module. Higher LTV increases deployable capital, but it also reduces liquidation distance. | LTV Level | Risk Profile | BASIS Policy | | --------- | ------------ | -------------------------------------------------- | | 30–40% | Conservative | Preferred safety-first range | | 40–50% | Moderate | Maximum operating range under monitored conditions | | 50–60% | Aggressive | Not used in standard operation | | >60% | Prohibited | Never used | BASIS maintains conservative collateral discipline and continuously evaluates: * collateral ratio * liquidation distance * oracle integrity * borrowing cost drift * venue-specific stress conditions If thresholds are approached, the system can reduce exposure by partial repayment, capital rebalancing, or full strategy exit. {% hint style="warning" %} Collateralized strategies are governed by state machine risk controls. If risk conditions move outside acceptable bounds, capital preservation takes priority over return generation. {% endhint %} *** ## 3. Venue Selection Standards Only venues that meet BASIS operational and risk requirements are eligible. | Criterion | Requirement | | ---------------------- | --------------------------------------------------------------------- | | PAXG support | Native collateral support for PAXG | | Security review | Strong independent audit history with no unresolved critical findings | | Production history | Established mainnet operating record | | Liquidity depth | Sufficient onchain liquidity and borrow capacity | | Oracle design | Robust multi-source pricing architecture | | Liquidation model | Transparent and predictable liquidation mechanics | | Operational resilience | Reliable uptime and incident response history | Venue approval is based on both protocol-level review and execution-layer compatibility with BASIS routing systems. *** ## 4. Risk Controls | Risk | Description | Mitigation | | ---------------------- | ----------------------------------------------------------- | ------------------------------------------------------------- | | Gold price decline | A drop in gold price can compress collateral coverage | Conservative LTV, continuous monitoring, automated de-risking | | Borrow rate expansion | Financing cost can rise and compress strategy spread | Dynamic threshold checks and rapid exit logic | | Smart contract failure | Vulnerability or protocol malfunction in a lending venue | Strict venue filtering and exposure caps | | Oracle failure | Distorted pricing can affect collateral health calculations | Oracle quality requirements and venue selection standards | | Liquidity stress | Reduced market depth can impair adjustments | Capacity limits and staged execution logic | *** ## 5. BASIS Infrastructure Context This module is supported by the same operating philosophy used across BASIS systems: * deterministic execution * math-constrained capital allocation * state machine risk controls * proprietary routing infrastructure * structural alpha capture over discretionary prediction BHLE infrastructure characteristics include: * sub-50μs latency * 100K+ OPS throughput * proprietary routing architecture built for execution precision These controls are designed to reduce slippage, improve response time under stress, and preserve predictable system behavior. *** ## 6. User Asset Flow on BASIS For PAXG users, the asset path is standardized. {% tabs %} {% tab title="Deposit" %} 1. Open Dashboard → Assets 2. Select PAXG 3. Connect a supported Web3 wallet 4. Confirm the PAXG deposit transaction 5. Receive balance credit in the Funding Wallet {% endtab %} {% tab title="Swap" %} 1. Open Dashboard → Assets 2. Select swap from PAXG to stPAXG 3. Confirm 1:1 conversion 4. Pay swap fee of 0.01% 5. stPAXG appears in the Staking Wallet {% endtab %} {% tab title="Stake" %} 1. Open Dashboard → Stake 2. Select stPAXG 3. Choose booster duration if applicable 4. Confirm full-position staking action 5. Rewards accumulate in real time as stPAXG {% endtab %} {% tab title="Unstake" %} 1. Open Dashboard → Stake 2. Select the staked stPAXG position 3. Unstake when the lock-up period has ended 4. The claimable amount is auto-credited to the Staking Wallet as stPAXG 5. Convert stPAXG back to PAXG if desired {% endtab %} {% endtabs %} {% hint style="info" %} Wallet model on BASIS: * Funding Wallet: native tokens only for deposit and withdrawal * Staking Wallet: stTokens only for staking and reward accrual For PAXG: * Deposit/withdraw asset: PAXG * Stake/earn asset: stPAXG {% endhint %} *** ## 7. Fees and Operational Parameters | Item | Value | | --------------- | -------------------- | | Deposit fee | 0% | | Withdrawal fee | 0.05% | | Swap fee | 0.01% | | Deposit asset | PAXG | | Withdraw asset | PAXG | | Swap ratio | PAXG ↔ stPAXG at 1:1 | | Withdrawal time | 1–6 minutes | ### Booster schedule | Lock Period | Booster | | ----------- | ---------- | | 14D | +10% | | 30D | +20% | | 90D | +50% | | 180D | +100% (2×) | {% hint style="warning" %} Fixed pools can only be unstaked after the lock-up period ends. Early exit is not available. Unstaking is processed as a full-position action only. Partial unstake is not supported. {% endhint %} *** ## 8. Status The PAXG Collateral Yield module is live and active within the BASIS asset framework, subject to venue eligibility, risk limits, and collateral conditions. Availability may vary based on: * venue capacity * collateral health thresholds * borrowing cost environment * execution suitability under current market structure For operational questions, contact . For research or methodology inquiries, contact . # Module 4: Peg Deviation Monitor {% 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)). {% endhint %} ### 1) Objective Monitor deviations between: * PAXG market price across supported venues, and * the implied reference value of 1 oz of gold under the platform’s accounting convention. The goal is not necessarily to trade every deviation. The primary goal is to: * detect liquidity stress * quantify arbitrage surface quality * support risk state decisions ### 2) Why peg deviations exist Peg deviations can occur due to: * shallow liquidity in certain pools * withdrawal frictions across venues * sudden demand shocks * on-chain costs and execution precision constraints * issuer or redemption constraints ### 3) Monitoring metrics A professional monitor tracks: * deviation magnitude (bps / %) * deviation persistence (duration) * liquidity depth at deviation points * execution precision indicators for on-chain venues * cross-venue coherence (whether the deviation is local or systemic) {% hint style="warning" %} PAXG support is live and active on BASIS. PAXG deposits and withdrawals use a connected Web3 wallet. PAXG can only be swapped 1:1 into stPAXG, and stPAXG can be staked to earn rewards in real time within the Staking Wallet. {% endhint %} ### 4) How monitors feed the risk engine If deviations exceed defined thresholds and cannot be explained by normal liquidity dynamics, the system should: * reduce exposure * trigger BSCB for protective pause * enter DMM if repeated anomalies occur ### 5) Trading rule (if enabled) A mathematically verified trading rule requires: * conservative EV gates * strict slippage bounds * defined exit plans Without these controls, peg arbitrage can become tail-risk exposure. *** Peg deviations are information. A research-driven platform extracts information first and acts only when eligibility conditions are satisfied. {% hint style="success" %} BASIS emphasizes deterministic execution, mathematical constraints, and state-machine risk controls. This framework is supported by Base58 Labs research, proprietary routing infrastructure, and BHLE performance characteristics including sub-50μs latency and 100K+ OPS. {% endhint %} # PAXG Risk Addendum {% 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 %} PAXG introduces additional risk surfaces beyond BTC, ETH, and SOL. This addendum is intended for users who want explicit failure-mode coverage. {% hint style="warning" %} Non-negotiable reminder Tokenized real-world assets are not risk-free gold. They are financial instruments with issuer, custody, legal, and operational dependencies. {% endhint %} ## 1) Issuer and custody risk PAXG is a token issued by an external issuer, not by BASIS. Risks include: * issuer operational failure * custody failure * audit or attestation failure * legal or regulatory action affecting issuer operations * redemption policy changes BASIS does not control these risks. BASIS can only: * monitor issuer disclosures and market signals * incorporate those signals into eligibility, sizing, and exposure limits * pause PAXG-related activity when uncertainty rises ## 2) Administrative control risk Some token contracts may include administrative controls such as freeze, blacklist, pause, or upgrade functions. If such controls exist, they introduce tail risk, including: * inability to transfer * inability to redeem * sudden changes in token behavior * unexpected restrictions on specific addresses or flows BASIS assumes conservative posture around this category of risk and may maintain tighter exposure and monitoring thresholds for PAXG than for other supported assets. ## 3) Redemption and operational constraints Tokenized gold redemption can involve constraints such as: * minimum redemption size * identity verification requirements * fees * processing delays * jurisdictional or counterparty restrictions These constraints matter during stressed conditions because the reference value may not be enforceable immediately through normal arbitrage activity. ## 4) Market liquidity risk PAXG liquidity can vary materially by venue and by time. Liquidity risk affects: * slippage tolerance * unwind capacity * execution feasibility * cross-venue routing quality * structural alpha capture under stressed market conditions BASIS applies deterministic execution controls and may enforce: * minimum depth thresholds * venue concentration limits * stricter routing filters * temporary suspension of selected strategies ## 5) On-chain risk Because PAXG operates on Ethereum, on-chain activity introduces additional risks, including: * gas spikes * network congestion * execution precision deterioration under volatile block conditions * smart contract integration risk through external pools or protocols During congestion or elevated operational uncertainty, the system prioritizes safety by reducing exposure, narrowing execution conditions, or disabling selected on-chain modules. {% hint style="info" %} PAXG deposits and withdrawals require a connected Web3 wallet such as MetaMask. BASIS supports same-token 1:1 swap functionality only, including PAXG → stPAXG. {% endhint %} ## 6) Peg deviation and valuation risk Even if PAXG references gold, market prices can deviate from expected valuation ranges. Deviation can be caused by: * liquidity constraints * redemption frictions * sudden demand shocks * issuer-related uncertainty * venue fragmentation BASIS may apply peg deviation thresholds that: * reduce module activity * halt selected activity * trigger internal control responses and de-risking logic ## 7) Infrastructure and execution risk PAXG strategy performance depends not only on market conditions but also on routing, timing, and infrastructure state. BASIS manages this through: * deterministic execution policies * math-constrained position logic * state machine risk controls * proprietary routing infrastructure * BHLE architecture with sub-50μs latency and 100K+ OPS handling capacity These controls are designed to improve execution precision and reduce avoidable operational variance. They do not eliminate issuer, custody, or market structure risk. ## 8) What users should do Before using PAXG-related functionality: * read the full Risk Disclosure * understand issuer and redemption dependencies * understand Ethereum transaction costs and operational constraints * test with small allocations first * verify wallet connectivity and address handling before transfer * understand that rewards, when applicable, accrue in real time as stPAXG within the Staking Wallet ## Operational notes | Item | PAXG | | --------------- | ----------------------- | | Deposit method | Connect Web3 wallet | | Withdraw method | Web3 wallet withdrawal | | Swap support | PAXG ↔ stPAXG only, 1:1 | | Funding Wallet | Holds native PAXG | | Staking Wallet | Holds stPAXG | | Deposit fee | 0% | | Withdrawal fee | 0.05% | | Swap fee | 0.01% | | Withdrawal time | 1–6 min | *** Trust is earned by defining how the platform behaves when tokenized gold markets become stressed, not by presenting gold exposure as inherently safe. {% hint style="success" %} BASIS risk architecture is grounded in deterministic execution, mathematical constraints, and explicit control-state transitions. Research support is provided through Base58 Labs, serving as a Research Partner for infrastructure and strategy research. {% endhint %} # Integration Plan & Rollout {% 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)). {% endhint %} PAXG integration is deployed through a phased rollout with explicit operational gates. A research-led platform does not activate complex modules in a single step. Each phase is validated through deterministic execution checks, state machine controls, venue health monitoring, and reconciliation requirements. ## Phase 0: Research and feasibility ### Deliverables * Venue coverage analysis across spot and derivatives markets * Liquidity depth study by venue and time window * On-chain cost study including gas behavior and execution precision conditions * Issuer risk surface mapping, including disclosures, controls, and redemption constraints ### Output * Eligibility rules draft * Risk addendum draft * Monitoring dashboard requirements {% hint style="warning" %} PAXG support is active on BASIS. This phase defines research, control logic, and parameterization before broader strategy activation. {% endhint %} ## Phase 1: Spot support and monitoring ### Enable * PAXG deposits and withdrawals in the Funding Wallet * PAXG to stPAXG same-token 1:1 swap * Monitoring surfaces for price, depth, deviation, and venue health ### Do not enable yet * DEX to CEX structural alpha capture modules * Collateral optimization modules ### Goal * Verify operational stability * Validate reporting and accounting * Confirm wallet, swap, and custody state transitions {% tabs %} {% tab title="User flow" %} 1. Connect a supported Web3 wallet 2. Deposit PAXG into the Funding Wallet 3. Swap PAXG to stPAXG at 1:1 4. Stake stPAXG in the Staking Wallet 5. Monitor rewards accumulating in real time as stPAXG {% endtab %} {% tab title="Operational checks" %} * Deposit confirmation integrity * Funding Wallet and Staking Wallet balance reconciliation * Swap parity validation at 1:1 * Withdrawal processing latency validation * Venue and oracle deviation monitoring {% endtab %} {% endtabs %} ## Phase 2: Golden BASIS module ### Enable * Spot-perpetual delta-neutral structural alpha capture * Access only on whitelisted venues with strong liquidity * Strict liquidation guards and exposure caps ### Goal * Validate hedge mechanics * Validate funding stability under stress * Confirm deterministic execution quality across routing paths {% hint style="info" %} Execution standards are enforced through math-based constraints, deterministic routing logic, and risk controls designed to preserve capital under adverse conditions. {% endhint %} ## Phase 3: DEX-CEX and collateral optimization ### Enable * DEX-CEX module only when on-chain conditions satisfy execution precision thresholds * Collateral optimization only on a strict protocol whitelist with conservative parameters ### Goal * Expand the opportunity surface without compromising capital preservation * Maintain reconciliation quality and operational predictability ### Control requirements | Control area | Requirement | | ------------------ | -------------------------------------------------------------- | | On-chain execution | Gas and execution precision must remain within approved bounds | | Protocol access | Whitelist only | | Position sizing | Conservative caps | | Failure handling | Automatic pause and state transition controls | | Monitoring | Real-time venue, chain, and collateral health checks | ## Phase 4: Full integration and public reporting ### Publish * Module performance breakdowns by realized yield contribution * Incident and pause statistics * Parameter change logs * Reconciliation summaries where applicable A trust-first platform proves performance through evidence, reconciliations, and repeatable control behavior. *** ## Live PAXG support on BASIS PAXG is fully active on BASIS. ### Supported wallet and asset behavior | Item | PAXG | | ------------------------- | ---------------------- | | Deposit method | Web3 wallet connection | | Wallet type | Funding Wallet | | Swap supported | PAXG → stPAXG only | | Swap ratio | 1:1 | | Withdrawable asset | PAXG | | Reward asset | stPAXG | | Estimated withdrawal time | 1–6 minutes | {% hint style="success" %} PAXG follows the standard BASIS asset model: * Funding Wallet: native token custody, deposit, withdrawal * Staking Wallet: stToken balance, staking, reward accrual * Rewards: accumulate in real time as stPAXG * Unstake: full position only * Claimable amount: automatically credited to the Staking Wallet as stPAXG after the 7-day unstaking buffer is complete. {% endhint %} ## Platform controls relevant to rollout BASIS infrastructure applies the same control philosophy across active assets, including PAXG: * Deterministic execution * Math-constrained position logic * State machine risk controls * Proprietary routing infrastructure * BHLE architecture with sub-50μs latency and 100K+ OPS capability * Research support from Base58 Labs A phased rollout is not delay for its own sake. It is how production systems preserve capital, maintain accounting integrity, and scale safely. # Announcement Template {% 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 Announces PAX Gold (PAXG) Support Is Live Asset: PAXG (PAX Gold), Ethereum (ERC-20) #### Why PAXG is supported BASIS has expanded its supported asset set beyond BTC, ETH, and SOL to include PAXG as an active supported asset. PAXG is included because it: * introduces a differentiated market regime linked to gold exposure * broadens structural alpha capture opportunities across spot, derivatives, and cross-venue routing * aligns with the BASIS trust framework through explicit risk controls, deterministic execution, and auditable operational constraints #### How PAXG is supported on BASIS PAXG is fully active across the BASIS asset flow. Users can: * deposit native PAXG by connecting a Web3 wallet * swap PAXG to stPAXG at a 1:1 ratio * stake stPAXG and accumulate rewards in real time * unstake the full staked position after the applicable lock-up period, subject to a mandatory 7-day unstaking buffer before claimable stPAXG is credited * withdraw native PAXG from the Funding Wallet {% tabs %} {% tab title="PAXG Asset Flow" %} {% hint style="info" %} **PAXG Staking Flow** 1. Web3 Wallet (PAXG) 2. Deposit to Funding Wallet (PAXG) 3. 1:1 swap to Staking Wallet (stPAXG) 4. Stake to active position {% endhint %} {% endtab %} {% endtabs %} #### Deposit and wallet handling {% stepper %} {% step %} Connect a supported Web3 wallet such as MetaMask. {% endstep %} {% step %} Select PAXG from the Assets section. {% endstep %} {% step %} Deposit native PAXG into your Funding Wallet. {% endstep %} {% step %} Swap PAXG to stPAXG at 1:1 before staking. {% endstep %} {% endstepper %} {% hint style="warning" %} PAXG deposits require a connected Web3 wallet. BASIS supports native token deposits for ETH, SOL, and PAXG through wallet connection. BTC deposits use a unique BASIS-assigned deposit address instead. {% endhint %} #### Fees and operational rules | Item | Value | | -------------- | ------------------------------: | | Deposit fee | 0% | | Withdrawal fee | 0.05% | | Swap fee | 0.01% | | Swap ratio | 1:1 only | | Supported swap | PAXG → stPAXG and stPAXG → PAXG | #### Staking and reward mechanics PAXG staking follows the same wallet and settlement model used across BASIS. * Native PAXG is held in the Funding Wallet * stPAXG is held in the Staking Wallet * rewards accumulate in real time as stPAXG * unstake is full-position only * the claimable amount is auto-credited to the Staking Wallet as stPAXG, subject to a 7-day unstaking buffer following the unstake action * fixed pools can only be unstaked after the lock-up period ends, with claimable amounts credited after the mandatory 7-day unstaking buffer #### Booster options | Lock-up Period | Booster | | -------------- | ---------: | | 14D | +10% | | 30D | +20% | | 90D | +50% | | 180D | +100% (2×) | #### Risk note PAXG includes asset-specific considerations, including issuer, custody, smart contract, and market structure risks. BASIS may apply protective state controls when required by market conditions or system constraints. This reflects the BASIS operating model: * deterministic execution * math-constrained allocation logic * state machine risk controls * precision-first routing through proprietary infrastructure #### Infrastructure and research basis PAXG support is integrated into the BASIS execution environment backed by: * BHLE architecture with sub-50μs latency * 100K+ OPS routing capacity * proprietary routing infrastructure for execution precision * research collaboration with Base58 Labs as Research Partner * structural alpha capture under strict operational constraints #### What users should do * confirm your wallet supports ERC-20 PAXG * deposit native PAXG through a connected Web3 wallet * begin with a small transfer to validate workflow * review the updated Assets, Stake, and Support sections in the dashboard *** BASIS remains committed to: * research-driven execution * deterministic and transparent system behavior * mathematically enforced risk controls * trust-first digital asset infrastructure # Performance Fee Mechanics {% 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)). {% endhint %} *** ## Fee Structure Summary | Fee Type | Rate | When Applied | | --------------- | ----------------: | -------------------------------------------------------- | | Performance Fee | 20% of net profit | Deducted before reward distribution to staking positions | | Management Fee | 0% | Never charged | | Deposit Fee | 0% | Never charged | | Swap Fee | 0.01% | On same-token 1:1 conversion | | Withdrawal Fee | 0.05% | On withdrawal | {% hint style="success" %} Supported same-token swaps only: * BTC → stBTC * ETH → stETH * SOL → stSOL * PAXG → stPAXG There is no cross-asset swap function. {% endhint %} *** ## How the Performance Fee Is Calculated {% hint style="info" %} $$ \text{Net Yield} = \text{Gross Yield} - \text{Execution Costs} $$ $$ \text{Performance Fee} = \text{Net Yield} \times 20% $$ $$ \text{User Distribution} = \text{Net Yield} \times 80% $$ {% endhint %} | Component | Description | | --------------- | -------------------------------------------------------------------------------------------- | | Gross Yield | Funding payments, basis spreads, structural alpha capture, and protocol-native yield sources | | Execution Costs | Exchange fees, slippage, gas, hedging overhead, and routing costs | | Net Yield | Yield available for distribution after costs | Rewards accumulate in real time as the same stToken in the Staking Wallet. We apply the performance fee before rewards are credited to staking positions. *** ## Worked Example {% tabs %} {% tab title="ETH example" %} Assumptions: * User deposits 10 ETH through a connected Web3 wallet * ETH is swapped 1:1 to stETH * Position is staked for a 30-day period * Entry reference value: 30,000 USDT-equivalent * Gross yield for the period: 600 USDT-equivalent * Execution costs: 120 USDT-equivalent | Step | Calculation | Amount | | --------------------- | ------------ | -----------------: | | Gross yield | 600 | 600 | | Execution costs | -120 | -120 | | Net yield | 600 - 120 | 480 | | Performance fee (20%) | 480 × 20% | -96 | | User receives | 480 × 80% | 384 | | Net return to user | 384 / 30,000 | 1.28% over 30 days | | {% endtab %} | | | {% tab title="90D booster example" %} Assumptions: * Same base conditions as above * 90-day booster applied * Booster multiplier: +50% | Step | Calculation | Amount | | ----------------------------- | ----------- | -----: | | Base gross yield over 90 days | 600 × 3 | 1,800 | | Booster-adjusted gross yield | 1,800 × 1.5 | 2,700 | | Execution costs | \~540 | -540 | | Net yield | 2,700 - 540 | 2,160 | | Performance fee (20%) | 2,160 × 20% | -432 | | User receives | 2,160 × 80% | 1,728 | {% hint style="warning" %} Current booster schedule: * 14D: +10% * 30D: +20% * 90D: +50% * 180D: +100% (2×) For fixed pools, unstaking is available only after the lock-up period ends. There is no early exit option. {% endhint %} {% endtab %} {% endtabs %} *** ## Why Performance Fees Align Incentives A performance fee aligns operator economics with realized user outcomes more closely than an asset-based management fee. | Fee Type | Operator Earns When | User Outcome | | --------------- | -------------------------------------------------- | ------------------------------------------------- | | Management fee | Assets remain deposited, regardless of performance | Operator may earn during flat or negative periods | | Performance fee | Platform generates positive net yield | Operator earns only when users earn | BASIS charges 0% management fee and 20% performance fee only. This means: * If net yield is zero, no performance fee is charged * If net yield is negative, no performance fee is charged * Operator compensation depends on positive realized performance, not simply asset growth {% hint style="info" %} This model is supported by deterministic execution, mathematical portfolio constraints, and state-machine-based risk controls across the BASIS execution stack. {% endhint %} *** ## High-Water Mark A high-water mark means performance fees apply only to new net profits above the previous peak. If a pool declines below its prior high-water level and later recovers, performance fees are charged only on gains above that previous peak. Recovery back to the earlier level is not charged again. BASIS applies high-water mark logic on a pool-cycle basis. If positions are rolled across cycles, refer to the relevant pool documentation for cycle reset handling. *** ## Operational Context {% hint style="info" %} BASIS combines research from Base58 Labs with proprietary routing and execution infrastructure designed for: * Sub-50μs latency * 100K+ OPS throughput * Deterministic execution quality * Structural alpha capture under strict risk constraints {% endhint %} These controls are intended to reduce avoidable execution loss and preserve execution precision across staking-related yield strategies. *** ## Related References * [Fee Calculator](/getting-started/fee-calculator) * [Fees & Limits](https://docs.basis.pro/reference/fees-and-limits) * [Booster System](/economics-and-rewards/booster-system) # Fee Structure Overview {% 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)). {% endhint %} Fees should be explicit and predictable. This page lists every fee that may apply on BASIS and when it applies. *** ## 1. Core Principle: Transparent Fees BASIS uses a simple fee model with no hidden line items. * No management fee * No deposit fee * Fixed withdrawal fee * Fixed swap fee for same-token conversion * 20% performance fee on net yield, deducted before reward distribution This structure supports deterministic execution, transparent accounting, and clear user expectations. ## 2. Fee Schedule | Fee Type | Rate | Description | | --------------- | ----------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Management Fee | 0% | No annual or recurring management fee is charged on deposited or staked assets. | | Deposit Fee | 0% | No fee is charged when depositing supported native assets into the Funding Wallet. | | Withdrawal Fee | 0.05% | A fixed withdrawal fee applies when native assets are withdrawn from the Funding Wallet. | | Swap Fee | 0.01% | A fixed fee applies when converting native tokens to their corresponding staking tokens on a 1:1 same-token basis. | | Performance Fee | 20% of net profit | Deducted before reward distribution to staking positions. Users receive 80% of net yield. See [Performance Fee Mechanics](/economics-and-rewards/performance-fee-mechanics). | ## 3. Supported Asset Flow BASIS supports native asset deposits only. | Asset | Deposit Method | Swap Path | Withdrawal Method | | ----- | -------------------------------------------- | ------------- | --------------------------------- | | BTC | Copy your BASIS-assigned BTC deposit address | BTC → stBTC | Withdraw BTC from Funding Wallet | | ETH | Connect Web3 wallet | ETH → stETH | Withdraw ETH from Funding Wallet | | SOL | Connect Web3 wallet | SOL → stSOL | Withdraw SOL from Funding Wallet | | PAXG | Connect Web3 wallet | PAXG → stPAXG | Withdraw PAXG from Funding Wallet | {% hint style="warning" %} USDT is used only as an internal accounting and display unit. It cannot be deposited, swapped in from outside, or withdrawn. {% endhint %} ## 4. How Fees Apply in Practice ### Deposits * Deposit fee: 0% * No minimum deposit * BTC deposits use a unique BASIS-assigned address for each account * ETH, SOL, and PAXG deposits require a connected Web3 wallet such as MetaMask or a compatible wallet ### Swaps Swaps on BASIS are limited to same-token 1:1 conversions only: * BTC → stBTC * ETH → stETH * SOL → stSOL * PAXG → stPAXG A 0.01% swap fee applies to each conversion. {% hint style="info" %} BASIS does not support cross-asset swaps such as BTC → stETH or ETH → stSOL. {% endhint %} ### Withdrawals A 0.05% withdrawal fee applies when withdrawing native assets from the Funding Wallet. Typical processing times: * BTC: 10 to 60 minutes * ETH / SOL / PAXG: 1 to 10 minutes ## 5. Wallet Separation BASIS separates operational balances into two wallet views: | Wallet | Holds | Primary Use | | -------------- | ------------------------------------- | -------------------------------------------------- | | Funding Wallet | Native tokens: BTC, ETH, SOL, PAXG | Deposit, withdraw, and prepare assets for swap | | Staking Wallet | stTokens: stBTC, stETH, stSOL, stPAXG | Stake, monitor rewards, and hold unstaked balances | Rewards accumulate in real time as the same stToken in the Staking Wallet. ## 6. Staking and Unstaking Notes ### Booster schedule | Lock Period | Booster | | ----------- | ---------- | | 14D | +10% | | 30D | +20% | | 90D | +50% | | 180D | +100% (2×) | ### Unstaking rules * Fixed pools can only be unstaked after the lock-up period ends * No early exit option is available for fixed pools * Unstake is processed as auto-MAX, meaning the full staked position is unstaked * Upon unstake, the claimable amount is automatically credited to the Staking Wallet as the corresponding stToken after the mandatory 7-day unstaking buffer ## 7. Operational Design BASIS is designed around deterministic execution, mathematical constraints, and state-machine risk controls. Core infrastructure characteristics include: * Seychelles IBC operating structure * Research support from Base58 Labs * Structural alpha capture through execution precision * BHLE architecture with sub-50μs latency * 100K+ OPS routing capacity * Proprietary routing infrastructure for deterministic execution quality These controls support transparent fee treatment and reduce ambiguity in user accounting. ## 8. Dashboard Reference Relevant dashboard sections: * Stake * Assets * Referral * Support * Account ## 9. Support For fee-related questions or operational clarification: * * * # Staking Pools: Technical Overview {% 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 %} Staking pools are how users allocate supported native assets on BASIS. Users deposit BTC, ETH, SOL, or PAXG, convert them 1:1 into the corresponding stToken, and stake that stToken into a selected pool. Rewards accumulate in real time as the same stToken in the Staking Wallet. BASIS staking infrastructure is designed around deterministic execution, state-machine risk controls, and structural alpha capture supported by proprietary research and execution systems. *** ## 1. How Staking Works {% stepper %} {% step %} **Deposit native assets** Users deposit a supported native asset into their Funding Wallet: * BTC: copy the BASIS-assigned deposit address unique to the account * ETH, SOL, PAXG: connect a Web3 wallet such as MetaMask and deposit directly Supported deposit assets: * BTC * ETH * SOL * PAXG Minimum BTC deposit: `0.0001 BTC` {% endstep %} {% step %} **Swap 1:1 into the corresponding stToken** Deposited assets are converted only into the matching staking asset: | Native Asset | stToken | | ------------ | ------- | | BTC | stBTC | | ETH | stETH | | SOL | stSOL | | PAXG | stPAXG | Swap is same-token only at 1:1. Cross-asset swaps are not supported. Examples: * BTC → stBTC * ETH → stETH * SOL → stSOL * PAXG → stPAXG {% endstep %} {% step %} **Stake from the Staking Wallet** The user selects a staking pool and stakes the available stToken balance from the Staking Wallet. {% endstep %} {% step %} **Earn rewards in real time** Rewards accumulate continuously as the same stToken and are reflected in the Staking Wallet according to the selected pool booster and platform performance. {% endstep %} {% step %} **Unstake the full position** Unstaking is processed on a full-position basis only. The unstake amount is auto-MAX for the selected stake. Once the lock-up period ends, a mandatory 7-day unstaking buffer applies. After the buffer is complete, the claimable amount is automatically credited to the Staking Wallet as stToken. {% endstep %} {% endstepper %} *** ## 2. Wallet Structure | Wallet | Purpose | Asset Type | | -------------- | -------------------------------- | ------------- | | Funding Wallet | Deposit and withdrawal | Native tokens | | Staking Wallet | Staking and rewards accumulation | stTokens | {% hint style="info" %} Funding Wallet holds native assets for deposit and withdrawal. Staking Wallet holds stTokens used for staking and reward accounting. {% endhint %} *** ## 3. Pool Types BASIS offers fixed-duration staking pools with defined booster levels. | Pool Type | Lock-Up | Booster | UI Display | | --------- | -------- | ------- | ---------- | | 14-Day | 14 days | 1.1x | +10% | | 30-Day | 30 days | 1.2x | +20% | | 90-Day | 90 days | 1.5x | +50% | | 180-Day | 180 days | 2.0x | +100% | {% hint style="warning" %} Fixed pools can only be unstaked after the lock-up period ends, and a mandatory 7-day unstaking buffer applies before the claimable amount is credited to the Staking Wallet. Early exit is not available. {% endhint %} {% hint style="info" %} Booster definitions: * 14D: +10% * 30D: +20% * 90D: +50% * 180D: +100% The booster modifies reward participation. It does not guarantee a fixed return. {% endhint %} *** ## 4. Reward Mechanics When a user stakes stTokens, rewards accrue in real time as the same stToken. ### Example * A user deposits `1 BTC` * The user swaps `BTC → stBTC` at `1:1` * The user stakes `1 stBTC` into a 30-day pool * Rewards accumulate during the lock-up period * At maturity, the user may unstake the full position; after the mandatory 7-day unstaking buffer, the full claimable amount is credited back to the Staking Wallet as `stBTC` If the final claimable balance is `1.012 stBTC`, that full amount appears in the Staking Wallet after the 7-day unstaking buffer is complete. {% hint style="info" %} BASIS uses same-token staking accounting rather than cross-asset conversion into a separate deposit currency. {% endhint %} *** ## 5. Unstaking Rules ### Fixed lock-up enforcement Users may only unstake after the selected lock-up period has ended. A mandatory 7-day unstaking buffer then applies before the claimable amount is credited to the Staking Wallet. ### Full-position unstake only Partial unstaking is not supported. The system automatically unstake-selects the entire active position. ### Auto-credit after the 7-day buffer After the mandatory 7-day unstaking buffer, the full claimable balance is automatically credited to the Staking Wallet as stToken. ### Withdraw native assets To withdraw, users convert the stToken back into the corresponding native asset and send it from the Funding Wallet. Under normal conditions, typical withdrawal processing targets from the Funding Wallet are: | Asset | Typical Processing Time | | ----- | ----------------------- | | BTC | 10 to 60 minutes | | ETH | 1 to 10 minutes | | SOL | 1 to 10 minutes | | PAXG | 1 to 10 minutes | Note: Unstaking from fixed pools requires an additional mandatory 7-day buffer before these withdrawal times apply. *** ## 6. Fees | Action | Fee | | ---------- | ----- | | Deposit | 0% | | Swap | 0.01% | | Withdrawal | 0.05% | {% hint style="info" %} USDT may appear in reporting or dashboard valuation views as an internal accounting unit only. It cannot be deposited or withdrawn. {% endhint %} *** ## 7. Capital Deployment BASIS does not deploy 100% of staked capital at all times. A reserve is maintained for withdrawal handling, execution continuity, and risk-buffer requirements. Typical deployment ranges are dynamically managed according to: * market conditions * pending withdrawal volume * strategy capacity * internal risk constraints This approach supports deterministic execution and reduces forced rebalancing risk. *** ## 8. Execution and Risk Framework BASIS staking returns are supported by infrastructure engineered for execution precision and structural alpha capture. Key operating characteristics include: * Seychelles IBC operating structure * LEI: `254900IX2F2KCWNSSS64` * Research support from Base58 Labs as Research Partner * BHLE execution environment with sub-50μs latency * 100K+ OPS routing capacity * proprietary routing infrastructure * math-constrained state-machine risk controls These controls are designed to improve consistency, settlement integrity, and operational resilience across supported strategies. *** ## 9. Dashboard Navigation Relevant dashboard sections: * Stake * Assets * Referral * Support * Account Use the Stake section to select a pool and manage active positions. Use the Assets section to review Funding Wallet and Staking Wallet balances. # Staking Activation Window {% 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)). {% endhint %} This page defines the BASIS staking activation window, explains the controls inside it, and documents the 2026 reduction from a typical Pending to Active interval of approximately 2 hours to a typical interval of 10 to 60 minutes under normal conditions. ## 1. Definition: the staking activation window The staking activation window is the short-lived Pending state shown on the user dashboard between the user's stake confirmation and the position becoming Active. It begins after the stake has been confirmed by the user into the staking flow and the dashboard position is Pending. It ends when the position state changes to Active. This window is distinct from the same-token swap step. The swap documentation states that "The swap step creates a clear system boundary between custody and participation: Funding Wallet holds native tokens for deposit and withdrawal. Staking Wallet holds stTokens for staking and reward accrual. principal and rewards are tracked with deterministic accounting. state transitions are controlled by internal risk checks." ([Swap, Stake & Earn](/getting-started/stake-and-earn)) The window is also distinct from on-chain deposit or withdrawal confirmation. The glossary states: "Deposits and withdrawals of supported assets interact with on-chain addresses, while some internal dashboard balances are maintained as platform records until a settlement event occurs." ([Glossary](/reference/glossary)) The activation window is therefore a platform state transition layer, not simply a blockchain confirmation layer. Most importantly, the activation window is distinct from reward accrual. Reward accrual begins when the position enters the Active state and then accrues in real time in the same stToken. This behavior is unchanged. The glossary defines the reward model as follows: "Real-time accumulation is the reward accounting model in which staking rewards accrue continuously and are reflected over time in the Staking Wallet. It is not a manual batch-claim model for standard BASIS staking flows." ([Glossary](/reference/glossary)) The economic parameters of a position, including the lock schedule and booster selection, take effect from the activation event. This is consistent with the documented observability sequence, where staking telemetry covers "same-token 1:1 swap event, stToken credit, booster selection, lock start, lock end, reward accrual, unstake settlement." ([Observability & Audit Logs](/technical-architecture/observability)) In add-stake flows, the booster reset policy remains unchanged: "When additional stake is added to an existing boosted position, the lock-up timer resets based on the new add-stake timestamp for the full aggregated position." ([Booster Reset Policy](/economics-and-rewards/booster-reset-policy)) {% hint style="info" %} A Pending position is waiting for activation controls to complete. It is not an Active position, and this document does not attribute reward accrual to Pending. {% endhint %} ## 2. Mechanics inside the window ### 2.1 Settlement event finalization Inside the activation window, BASIS finalizes the settlement event that connects the user's stake confirmation, the same-token 1:1 swap event, the stToken credit, and the resulting position state. The glossary distinction is important: on-chain deposits and withdrawals interact with addresses, while internal dashboard balances can remain platform records until a settlement event occurs. This step cannot be skipped because activation requires a final ledger state, not merely an instruction record. The observability documentation requires user actions to be "reconstructable from source event to final ledger state." ([Observability & Audit Logs](/technical-architecture/observability)) If the settlement event is not finalized, the platform has not completed the full path from source event to final ledger state. ### 2.2 Invariant reconciliation BASIS then reconciles the relevant invariant. The documented invariant is exact: "Balances reconcile exactly: Minted stToken supply matches underlying native token quantity." ([Mathematical Verification: Invariants](/research-library-deep-dives/invariants)) This is the BIVB invariant referenced in the unchanged safety controls. This step cannot be skipped because reconciliation is a hard risk control. The risk engine documentation states: "The system confirms that all expected state transitions completed correctly before new exposure is permitted." It also states: "Reconciliation is not a reporting convenience. It is a hard risk control. If reconciliation does not complete cleanly, the engine can block new orders until the discrepancy is resolved." ([Risk Engine](/technical-architecture/risk-engine)) ### 2.3 State machine gating: Normal, BSCB, DMM Activation is an exposure-permission event. The platform must confirm that the system state allows the position to become Active. Under Normal system state, activation can proceed when the required checks complete. Under abnormal conditions, BSCB circuit breaker behavior or DMM supervised escalation can pause or supervise new exposure. This step cannot be skipped because state transitions are controlled by internal risk checks, and the risk engine confirms expected state transitions before new exposure is permitted. Expected value gating, BSCB circuit breaker behavior, and DMM supervised escalation are part of the unchanged control surface. ### 2.4 Capital assignment under the reserve policy Activation also requires capital assignment under the documented reserve-based deployment model. The staking pools documentation states: "BASIS does not deploy 100% of staked capital at all times. A reserve is maintained for withdrawal handling, execution continuity, and risk-buffer requirements." ([Staking Pools: Technical Overview](/economics-and-rewards/staking-pools)) This step cannot be skipped because activation must be consistent with the reserve policy. A position cannot be treated as fully Active in the system if its capital assignment would conflict with withdrawal handling, execution continuity, or risk-buffer requirements. ### 2.5 Audit trail finalization The activation window also finalizes the audit trail for the state transition. The observability documentation states that staking activity telemetry covers "same-token 1:1 swap event, stToken credit, booster selection, lock start, lock end, reward accrual, unstake settlement." It also requires actions to be "reconstructable from source event to final ledger state" and states that "Any deviation from expected processing windows should trigger internal alerts and user-visible status updates." ([Observability & Audit Logs](/technical-architecture/observability)) This step cannot be skipped because the platform must retain a complete event trail from user action to ledger state. Without that trail, the position state would not satisfy the documented observability standard. ## 3. Why a bounded activation window is a safety feature, not a defect A bounded activation window is a designed operational constraint. It is structured to make settlement, reconciliation, gating, reserve assignment, and audit finalization explicit before the platform permits new exposure. This follows the same design philosophy as the documented unstaking buffer. The technical risk documentation states that "the mandatory 7-day unstaking buffer is a designed operational constraint, not a technical delay or system failure." ([Technical & System Risk](/risk-safety-and-asset-protection/technical-risk)) The activation window is shorter and occurs before Active status, but the logic is comparable. A visible state boundary is used to separate user instruction from finalized platform participation. A standard industry analogy is exchange settlement cycles. In professional market infrastructure, execution, settlement, risk permissioning, and final balance availability can be separate events. The analogy is not that BASIS copies exchange settlement mechanics. The point is that separating an instruction from final exposure is standard engineering practice in financial systems that require deterministic accounting and controlled state transitions. The Pending state gives users visibility into this control interval. It is more mechanically honest than hiding the process behind an immediate dashboard state change before the platform has completed reconciliation and gating. ## 4. Why the window was approximately 2 hours, and why it is now 10 to 60 minutes Until July 2026, the Pending to Active activation interval typically completed within approximately 2 hours under normal conditions. That earlier timing reflected a conservative settlement cadence around the same settlement, reconciliation, gating, reserve, and audit controls. Following a scheduled platform infrastructure update completed in early August 2026, the same activation interval now typically completes within 10 to 60 minutes under normal conditions. The update changed settlement pipeline throughput and sequencing only. The improved design uses parallelized reconciliation, telemetry driven processing, and higher orchestration headroom. The control surface is identical. No control was removed, weakened, or relaxed. The unchanged controls include the same token 1:1 swap, BIVB invariant reconciliation, expected value gating, BSCB circuit breaker behavior, DMM supervised escalation, the mandatory 7 day unstaking buffer, reserve-based capital deployment, full position auto-MAX unstake, and the booster reset on add-stake policy. This distinction matters because infrastructure speed and risk-control bypass are different things. The BHLE infrastructure documentation references "sub-50 microseconds latency architecture", "100K+ OPS routing capacity", "proprietary execution infrastructure", and "mathematically constrained risk controls." ([Swap, Stake & Earn](/getting-started/stake-and-earn), [System Overview](/whitepaper/system-overview)) Those infrastructure statements provide context for high throughput execution capacity, while the activation window remains governed by settlement finalization, reconciliation, state machine gating, reserve policy, and audit trace completion. The scheduled update also fits the documented production change discipline. BASIS maintains active ISO/IEC 20000-1:2018 certification for IT Service Management, which disciplines how production changes are tested, released, and reviewed. ([Audits & Responsible Disclosure](/technical-architecture/audits-and-disclosure)) The activation window reduction should therefore be understood as a production infrastructure change released under that change-management discipline, not as a change to economic treatment or risk policy. ## 5. Why the parameter is a range and not a constant The current activation interval is documented as 10 to 60 minutes under normal conditions because activation depends on multiple variable inputs. First, asset-specific chain finality matters. BTC linked flows inherit Bitcoin network confirmation timing, documented at 10 to 60 minutes. ETH, SOL, and PAXG flows confirm faster on chain, documented at 1 to 10 minutes. The fees and limits documentation states that BTC deposit credit occurs after required network confirmations, that the same token swap is typically near-instant after confirmation, that BTC withdrawal timing is 10 to 60 minutes, and that ETH, SOL, and PAXG withdrawal timing is 1 to 10 minutes. ([Fees & Limits](/reference/fees-and-limits)) The minimum staking documentation also states that Bitcoin presents "slower settlement characteristics and more variable on-chain fee conditions" than the other supported networks. ([Minimum Staking & Reward Claim Policy](/getting-started/minimum-staking)) Second, reconciliation completion can vary with system state and load. Telemetry driven processing reduces unnecessary waiting, but reconciliation still has to complete cleanly. The risk engine can block new orders if reconciliation does not complete cleanly. Third, state machine gating can pause new exposure during abnormal states. Under Normal conditions, the position can proceed through the activation path after required controls complete. If BSCB circuit breaker behavior or DMM supervised escalation applies, the platform can pause or supervise allocation activity. The lower bound equals the floor of the control sequence. It represents the minimum practical time for settlement finalization, invariant reconciliation, state machine gating, reserve assignment, and audit trail finalization under normal conditions. The upper bound equals the conservative envelope under normal conditions. It is not a fixed countdown and it does not override network confirmation, reconciliation, BSCB, DMM, reserve, or telemetry controls. {% hint style="info" %} The 10 to 60 minute figure is the current typical activation envelope under normal conditions. It is not a fixed countdown and it does not override documented safety controls. {% endhint %} ## 6. Technical questions and answers
Why does an activation window exist if the same-token swap is near-instant after confirmation? Swap finality and position activation are different settlement layers. The swap creates the system boundary between Funding Wallet custody and Staking Wallet participation. As the glossary notes, some internal dashboard balances are maintained as platform records until a settlement event occurs. Activation is the final Pending to Active state transition, completed only after settlement finalization, invariant reconciliation, state machine gating, reserve assignment, and audit trail finalization.
Does faster activation mean weaker risk controls? No. The scheduled update changed settlement pipeline throughput and sequencing only. It added parallelized reconciliation, telemetry driven processing, and higher orchestration headroom. The same reconciliation, invariant, expected value, BSCB, DMM, reserve, and audit controls remain in place. Reconciliation can still block new exposure if it does not complete cleanly.
Why is the activation window a range instead of a fixed number? The parameter is a range because asset-specific chain finality, reconciliation load, and state machine gating vary. BTC linked flows inherit slower Bitcoin timing. ETH, SOL, and PAXG flows confirm faster on chain, but still pass through the same platform activation controls. The lower bound is the control-sequence floor. The upper bound is the conservative envelope under normal conditions.
Does the activation window conflict with the real-time reward accrual model? No. Real-time accumulation describes how rewards accrue after the position is Active. The Pending state is before Active. The documented behavior is unchanged: reward accrual begins when the position enters Active and then accrues in real time in the same stToken.
## 7. Illustrative timing table All timing values below are typical under normal conditions. The asset confirmation column is context for settlement behavior and does not replace the dashboard Pending to Active state. | Flow context | Activation window until July 2026 | Activation window after early August 2026 update | Documented asset confirmation context | | ------------------------ | --------------------------------- | ------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | BTC linked staking flow | Typically approximately 2 hours | Typically 10 to 60 minutes | BTC deposit credit after required network confirmations. BTC withdrawal timing documented at 10 to 60 minutes. Bitcoin is documented as having slower settlement characteristics and more variable on-chain fee conditions. | | ETH linked staking flow | Typically approximately 2 hours | Typically 10 to 60 minutes | ETH flows confirm faster on chain, documented at 1 to 10 minutes. | | SOL linked staking flow | Typically approximately 2 hours | Typically 10 to 60 minutes | SOL flows confirm faster on chain, documented at 1 to 10 minutes. | | PAXG linked staking flow | Typically approximately 2 hours | Typically 10 to 60 minutes | PAXG flows confirm faster on chain, documented at 1 to 10 minutes. | ## 8. Risk disclosure Rewards are variable. Activation windows in this document are typical under normal conditions and are not processing time commitments under abnormal network conditions, abnormal system state, reconciliation discrepancies, BSCB circuit breaker behavior, DMM supervised escalation, reserve constraints, or telemetry deviations. BASIS controls can pause allocation activity or block new orders when documented risk checks do not complete cleanly. A Pending position should be read as not yet Active. Reward accrual begins only when the position enters Active and then accrues in real time in the same stToken. *** Next: read [Unstaking & Liquidity Buffer](/economics-and-rewards/unstaking-and-7-day-rule) for the exit-side design that follows the same operational constraint philosophy. # Yield Sources: Where Returns Come From {% 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 generates yield from four distinct mechanisms. These strategies are designed to avoid directional dependence on asset prices where possible. This page explains how each source works, why it can produce returns, and where the principal risks sit. *** ## Core Principle: Market-Neutral Return Generation A strategy is market-neutral when P\&L remains statistically independent, or close to independent, from the underlying asset’s price direction. BASIS targets that outcome by pairing each long exposure with an economically equivalent short exposure where appropriate. Price moves are intended to offset. The remaining P\&L comes from carry, structural alpha capture, execution precision, and other market frictions. This framing aligns with established research on hedge fund risk factors and statistical arbitrage, adapted to digital-asset market structure and deterministic execution systems. {% hint style="success" %} BASIS emphasizes deterministic execution, mathematical constraints, and state-machine risk controls rather than discretionary trading views. {% endhint %} *** ## Yield Source 1: Spatial Arbitrage Spreads (BQAE) ### Mechanism Spatial arbitrage captures short-lived price differences for the same asset across trading venues. BASIS operates BHLE, a proprietary routing and execution infrastructure with sub-50μs latency and 100K+ OPS, to detect these windows and execute both legs with execution precision: buy where the asset is cheaper and sell where it is richer. ### Why It Is Market-Neutral The combined position, long on Venue A and short on Venue B, is constructed to maintain net delta near zero. P\&L comes from spread capture after fees, slippage, and transfer or settlement timing. The strategy does not require a bullish or bearish view on BTC, ETH, SOL, or PAXG. ### Structural Source of Spreads | Factor | Explanation | | ------------------- | -------------------------------------------------------------------------------------------- | | Liquidity asymmetry | Order book depth differs across venues, creating temporary mispricings | | Latency asymmetry | Slower participants cannot close windows as quickly as BHLE | | Settlement friction | Capital cannot always move instantly between venues, allowing spreads to persist | | Market segmentation | Distinct participant bases and capital constraints create recurring supply-demand imbalances | ### Why BASIS Can Compete * Proprietary routing infrastructure * Deterministic execution paths * Inventory-aware position balancing * State-machine risk controls for constrained order placement * Research support from Base58 Labs as a Research Partner *** ## Yield Source 2: Funding Rate Capture (Delta-Neutral Basis Trade) ### Mechanism Perpetual futures use a funding rate to keep perpetual prices anchored to spot markets. When perpetuals trade above spot, longs pay shorts periodically. BASIS runs long spot plus short perpetual exposure to collect that funding differential. ### Why It Is Market-Neutral The spot leg and perpetual leg are designed to offset one another, leaving net delta close to zero. Yield is the funding received minus hedge maintenance costs, execution costs, and venue-specific financing friction. ### Historical Context Positive funding has historically appeared most often during periods of strong speculative demand. Across major digital assets such as BTC and ETH, annualized funding has at times ranged from negligible levels to materially elevated carry opportunities. BASIS monitors funding across approved venues continuously and reallocates exposure when conditions change. ### Risk Controls * Real-time detection of funding inversion * Automated unwind when carry turns sufficiently negative * Margin-health monitoring via Liquidation Guard * Position contraction when risk thresholds approach danger zones See: [Liquidation Guard](/risk-safety-and-asset-protection/liquidation-guard) *** ## Yield Source 3: Blue-Chip DeFi Lending and Liquid Staking Yield ### Mechanism When capital is not allocated to arbitrage or carry strategies, BASIS may deploy assets into high-quality on-chain yield sources. #### 1. DeFi Lending Assets are supplied into overcollateralized lending protocols such as Aave, Compound, and selected Solana-native equivalents. Interest rates vary with utilization. The lender receives the same asset back plus accrued interest. #### 2. Liquid Staking Exposure ETH and SOL can be deployed through liquid staking structures to earn protocol-native staking rewards while maintaining liquidity through liquid receipt assets. ### Why It Is Market-Neutral Lending income and staking rewards accrue in the underlying asset rather than depending on fiat price appreciation. While mark-to-market portfolio values may move with the asset price, the reward-generation mechanism itself is based on utilization, validator participation, and network-level issuance or fee distribution. {% hint style="warning" %} On-chain strategies introduce smart-contract, validator, and protocol-governance risk. BASIS restricts deployments through internal risk filters and allocation limits. {% endhint %} *** ## Yield Source 4: PAXG Real-World Asset Yield ### Mechanism PAXG is an active and fully supported asset on BASIS. It is a gold-backed token issued by Paxos Trust Company and supported across Funding Wallet and Staking workflows where applicable. BASIS may deploy PAXG into: * Gold-denominated lending or repo-style markets where available * PAXG spot-perpetual basis structures on venues supporting relevant derivatives * High-quality on-chain liquidity venues where risk-adjusted return is acceptable ### Strategic Role Gold often exhibits different macro behavior from digital assets, which can diversify the platform’s overall return stream. Tokenized gold market depth has expanded meaningfully, supporting larger and more stable allocation capacity than in earlier market phases. ### Risk Profile PAXG-related strategies may involve: * Issuer and custody risk * Liquidity concentration risk * Market-depth limitations in derivatives venues * Smart-contract risk for on-chain deployment *** ## Yield Source Summary | Yield Source | Strategy Module | Typical Conditions | Net Delta | Primary Risk | | ------------------------------- | ----------------------------------------- | -------------------------------------------------- | --------------- | ------------------------------------- | | Spatial arbitrage spreads | BQAE with BHLE | Fragmented or fast-moving markets | ≈ 0 | Execution and settlement | | Funding rate capture | Delta-neutral basis trade | Positive funding environments | ≈ 0 | Funding inversion, liquidation | | DeFi lending and liquid staking | On-chain yield allocator | Healthy lending demand and validator participation | ≈ 0 | Smart-contract, validator, governance | | PAXG yield | Gold lending, basis, liquidity deployment | Gold demand and sufficient market depth | Low to moderate | Custody, issuer, liquidity | *** ## Operational Notes {% tabs %} {% tab title="Supported assets" %} * BTC * ETH * SOL * PAXG {% endtab %} {% tab title="Wallet model" %} * Funding Wallet: native-token deposits and withdrawals * Staking Wallet: stTokens used for staking and reward accrual {% endtab %} {% tab title="Important constraints" %} * Swaps are same-token only, 1:1 * BTC → stBTC * ETH → stETH * SOL → stSOL * PAXG → stPAXG * Rewards accrue in real time as the same stToken * Unstake is full-position only * Claimable amount is auto-credited to the Staking Wallet as stToken upon unstake {% endtab %} {% endtabs %} *** ## References * Fung, W. & Hsieh, D.A. (2001). The Risk in Hedge Fund Strategies. Review of Financial Studies, 14(2). * Avellaneda, M. & Lee, J.H. (2010). Statistical Arbitrage in the U.S. Equities Market. Quantitative Finance, 10(7). * Baur, D.G. & Lucey, B.M. (2010). Is Gold a Hedge or Safe Haven? Financial Review, 45(2). * Alexander, A. (2025). Latency Arbitrage in Cryptocurrency Markets. SSRN 5143158. * Paxos Trust Company. Monthly PAXG Attestation Reports: *** See also: [Strategy Matrix](/whitepaper/strategy-matrix) | [Risk Disclosure](/risk-safety-and-asset-protection/risk-disclosure) | [Delta-Neutral Funding](/strategies/delta-neutral-funding) # Pools Overview {% 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)). {% endhint %} BASIS pools are designed around how execution systems actually operate: > Liquidity and yield are a trade-off.\ > The more predictable capital availability is, the more efficiently the system can deploy it for structural alpha capture. BASIS offers two pool categories: * Flexible pools: prioritize withdrawal flexibility * Fixed pools: trade liquidity for higher capital efficiency and enhanced reward potential ## 1) Flexible pools: liquidity first Characteristics: * withdrawals can be requested at any time, subject to operational processing windows * the system must maintain a liquidity buffer * reward potential is structurally lower due to reserve requirements and lower deployment efficiency Flexible pools fit users who value optionality over higher lock-up rewards. ## 2) Fixed pools: efficiency first Characteristics: * capital is committed for a defined period: 14, 30, 90, or 180 days * the system can deploy a higher fraction of capital continuously * the system can maintain longer-duration positioning with lower forced unwind risk * reward sharing is increased through Booster multipliers Fixed pools fit users who want higher reward efficiency and can commit to a defined horizon. {% hint style="warning" %} Fixed pools can only be unstaked after the full lock-up period ends. Early exit is not available. {% endhint %} ## 3) Booster schedule Fixed pools use the following Booster structure: | Lock-up Period | Booster | | -------------- | ---------: | | 14 Days | +10% | | 30 Days | +20% | | 90 Days | +50% | | 180 Days | +100% (2×) | Rewards accumulate in real time and are credited as the same stToken in the Staking Wallet. ## 4) Shared foundation: capital preservation and state controls Both pool categories share the same operating foundation: * deterministic execution controls * global risk state machine protections * position unwind protocols * math-constrained risk limits * proprietary routing infrastructure designed for execution precision This framework is built to support system resilience under changing market conditions. {% hint style="info" %} BHLE infrastructure characteristics include sub-50μs latency, 100K+ OPS throughput, and proprietary routing architecture designed for deterministic execution and structural alpha capture. {% endhint %} If the system enters a protective state, reward generation may pause temporarily. These controls exist to preserve capital continuity and operational integrity. ## 5) Wallet structure BASIS separates assets into two wallets: | Wallet | Purpose | Asset Type | | -------------- | ----------------------------- | ------------- | | Funding Wallet | Deposit and withdrawal | Native tokens | | Staking Wallet | Stake and reward accumulation | stTokens | Supported asset flows: * BTC → stBTC * ETH → stETH * SOL → stSOL * PAXG → stPAXG Swaps are same-token only and always 1:1. ## 6) Deposit and unstake mechanics {% tabs %} {% tab title="BTC" %} * Deposit by copying your BASIS-assigned BTC address * No Web3 wallet connection is required * Minimum deposit: 0.0001 BTC * After deposit, BTC can be swapped 1:1 into stBTC for staking {% endtab %} {% tab title="ETH / SOL / PAXG" %} * Deposit by connecting a supported Web3 wallet such as MetaMask * Deposits are made in the native asset * After deposit, the asset can be swapped 1:1 into the corresponding stToken for staking {% endtab %} {% endtabs %} Unstaking rules: * unstake is full-position only * the system applies auto-MAX to the selected stake * upon unstake, the claimable amount is automatically credited to the Staking Wallet as stToken after the 7-day buffer is complete ## 7) Fees and timing | Action | Fee | | ---------- | ----: | | Deposit | 0% | | Withdrawal | 0.05% | | Swap | 0.01% | Typical withdrawal times: | Asset | Processing Time | | ----- | ---------------- | | BTC | 10 to 60 minutes | | ETH | 1 to 10 minutes | | SOL | 1 to 10 minutes | | PAXG | 1 to 10 minutes | ## 8) Choosing a pool Ask yourself: 1. Do I need immediate access to my principal? 2. Can I commit funds for 14, 30, 90, or 180 days? 3. Do I understand that adding stake may affect reward configuration and timing? 4. Have I reviewed the risk disclosure and understand that USDT is used only as an internal display unit? ## 9) Navigation Relevant dashboard sections: * Stake * Assets * Referral * Support * Account *** Next: read Lock-up Economics to understand why fixed pools can offer higher reward efficiency without changing the system’s core risk controls. # Lock-up Economics (Capital Efficiency) {% 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)). {% endhint %} Many products describe lock-ups as "bonus yield." Serious allocators should evaluate them through a measurable lens: capital efficiency. BASIS explains lock-ups as a structural mechanism that improves deployable capital ratio under deterministic constraints. ## 1) Why lock-up can support higher efficiency In a flexible pool, capital cannot be deployed at full utilization because: * withdrawals may occur at any time * the system must maintain a liquidity buffer * part of the pool remains idle as operational reserve If a flexible pool must keep 20-30% idle, even a strong strategy stack cannot continuously allocate the full capital base. In a fixed lock-up pool, withdrawal timing is known in advance. This allows BASIS to: * deploy capital more continuously * allocate into strategies requiring a stable time horizon * improve realized yield through lower idle balance and better execution precision Lock-up yield should be understood as a redistribution of efficiency surplus, not as arbitrary bonus issuance. ## 2) A simplified model {% hint style="info" %} Model variables {% endhint %} | Variable | Meaning | Constraint | | -------- | ------------------------------------------------ | ----------------- | | $C$ | Total capital | - | | $b$ | Required buffer fraction | $0 \leq b \leq 1$ | | $r$ | Realized strategy yield rate on deployed capital | - | {% hint style="info" %} Expected realized yield: $$ \text{Yield} \approx (1-b) \cdot C \cdot r $$ A lock-up reduces $b$, which increases deployed capital share and realized yield potential. {% endhint %} ## 3) Why this is not automatically "more risky" A lock-up does not inherently increase platform risk. In some cases, it can reduce specific failure modes: * forced liquidation pressure during clustered withdrawals * execution degradation caused by emergency unwinds * opportunity loss caused by excessive liquidity buffers What lock-up does add is user liquidity constraint: principal remains unavailable until the lock period ends. {% hint style="warning" %} For fixed pools on BASIS, unstaking is only available after the selected lock-up period has ended. Early exit is not supported. Unstake is processed as full-position only. Partial unstake is not available. {% endhint %} ## 4) What BASIS discloses for credibility A credible lock-up system should clearly publish: * available lock durations and booster rules * whether adding stake resets the lock period * how unstake and capital unwind are processed * how the system behaves under internal risk-control states * how rewards accrue and where they are credited On BASIS, rewards accumulate in real time as the same stToken in the Staking Wallet. ## 5) Current fixed lock-up booster schedule | Lock-up period | Booster | | -------------- | ---------- | | 14D | +10% | | 30D | +20% | | 90D | +50% | | 180D | +100% (2x) | {% hint style="success" %} Wallet model * Funding Wallet: native tokens only (BTC, ETH, SOL, PAXG) for deposit and withdrawal * Staking Wallet: stTokens only (stBTC, stETH, stSOL, stPAXG) for staking and reward accrual Swap is same-token only at 1:1: * BTC → stBTC * ETH → stETH * SOL → stSOL * PAXG → stPAXG Fees: * Deposit: 0% * Withdrawal: 0.05% * Swap: 0.01% {% endhint %} ## 6) Operational context BASIS is designed around deterministic execution, mathematical constraints, and state-machine risk controls. Research and systems design are supported by Base58 Labs, with emphasis on structural alpha capture, execution precision, and controlled liquidity behavior. BHLE infrastructure targets sub-50μs latency, 100K+ OPS, and proprietary routing for stable execution quality under load. *** Next: read Booster System. # Booster System {% 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)). {% endhint %} Boosters on BASIS are not presented as a marketing device. They are part of the platform’s staking economics policy and are tied to lock-up commitments. ## 1) Definition: booster as yield-share adjustment A booster is a multiplier applied to the yield accrued by a staked position. BASIS links that multiplier to the capital quality contributed by the user, primarily through lock-up duration. A simplified decomposition: * Gross Yield = realized strategy returns * Costs = fees + slippage + hedging cost + operational overhead * Net Yield = Gross Yield − Costs A boosted distribution changes how net yield is allocated between: * users * the operator Boosters are intended to reflect actual capital-efficiency gains. They are not designed to depend on hidden fees or undisclosed risk transfers. ## 2) Active booster schedule BASIS applies fixed time-based boosters. The interface displays the booster as a percentage addition to the base staking rate. | Lock-up | UI display | Multiplier | Meaning | | -------- | ---------- | ---------- | ------------------------------ | | Flexible | +0% | 1.0x | Base rate, no adjustment | | 14 days | +10% | 1.1x | Yield increased by 10% of base | | 30 days | +20% | 1.2x | Yield increased by 20% of base | | 90 days | +50% | 1.5x | Yield increased by 50% of base | | 180 days | +100% | 2.0x | Yield doubled | {% hint style="success" %} Active booster schedule: * 14D: +10% * 30D: +20% * 90D: +50% * 180D: +100% (2×) {% endhint %} Interpretation: * boosters are multipliers applied to calculated yield * boosters do not guarantee returns * realized yield depends on strategy performance, market conditions, and execution precision ## 3) Why longer lock-ups can receive higher multipliers Longer lock-ups can support better capital deployment because they: * allow higher continuity of allocation * reduce forced repositioning from withdrawal activity * enable longer-horizon strategy participation * improve planning around deterministic execution and state-machine-based risk controls This is why longer lock-ups may receive larger efficiency-based yield adjustments. ## 4) How boosters work operationally {% stepper %} {% step %} Stake stToken from the Staking Wallet Users stake stBTC, stETH, stSOL, or stPAXG from the Staking Wallet. Rewards accumulate in real time in the same stToken. {% endstep %} {% step %} Select the lock-up period Available options include Flexible, 14D, 30D, 90D, and 180D. {% endstep %} {% step %} Booster is applied to the position The selected booster modifies the yield calculation for that staked position. {% endstep %} {% step %} Unstake at maturity for fixed pools Fixed pools can only be unstaked after the lock-up period ends. Early exit is not available. {% endstep %} {% step %} Receive the unstaked amount Upon unstake, the full position is processed on an auto-MAX basis. The claimable amount is automatically credited to the Staking Wallet as the same stToken. {% endstep %} {% endstepper %} ## 5) Important constraints {% tabs %} {% tab title="Position scope" %} Boosters apply to the staked position associated with the selected lock-up configuration. {% endtab %} {% tab title="Rewards format" %} Rewards accumulate in real time as the same stToken in the Staking Wallet. {% endtab %} {% tab title="Unstake behavior" %} Unstaking is full-position only. Partial unstake is not supported. {% endtab %} {% tab title="Fixed pools" %} For fixed pools, unstake is available only after the lock-up period ends. {% endtab %} {% endtabs %} ## 6) Booster disclosures required A credible booster framework should clearly disclose: * whether the booster applies only to yield accrual or also affects other calculations * whether the booster applies prospectively from the moment of staking * how boosted yield is displayed in the interface * how lock-up constraints affect unstake timing * how the system behaves under risk-control states and execution safeguards ## 7) Related platform context BASIS is built around deterministic execution, mathematical constraints, and state machine risk controls. The underlying BHLE infrastructure is designed for sub-50μs latency, 100K+ OPS throughput, and proprietary routing to support structural alpha capture with controlled execution behavior. {% hint style="warning" %} Wallet model reminder: * Funding Wallet: native tokens only for deposit and withdrawal * Staking Wallet: stTokens only for staking and reward accrual Supported swap pairs are same-token only at 1:1: * BTC → stBTC * ETH → stETH * SOL → stSOL * PAXG → stPAXG {% endhint %} *** Next: read Booster Reset Policy to understand what happens when additional stake is added to an existing position. # Booster Reset Policy {% 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)). {% endhint %} The booster reset policy is designed to preserve: 1. Fairness across participants 2. Anti-abuse integrity within the staking system ## 1) The problem: position aggregation When additional stake is added to an existing boosted position, the system treats the result as one aggregated allocation. This means: * the combined position is managed as a single unit * lock-up assumptions must remain consistent across the full allocation * reward treatment must follow one unified booster schedule If separate timelines were maintained for old and newly added portions, the system would introduce: * accounting complexity * avoidable edge cases * incentive loopholes * booster gaming behavior ## 2) The policy: reset on add-stake BASIS applies the following rule: | Rule | Description | | ------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Booster Reset Rule | When additional stake is added to an existing boosted position, the lock-up timer resets based on the new add-stake timestamp for the full aggregated position. | This ensures: * one lock horizon for the full staked allocation * one consistent booster assumption across the position * cleaner state handling and deterministic reward logic {% hint style="warning" %} Fixed pools are locked for their full selected period. There is no early exit option. Unstaking becomes available only after the lock-up period ends. {% endhint %} ## 3) Practical guidance Before adding stake to an existing boosted position, review the following: 1. Check the remaining lock duration 2. Confirm that adding stake will reset the timer for the full position 3. Assess whether waiting for expiry is more suitable than aggregating immediately 4. Remember that unstake is processed as full-position only using auto-MAX behavior ## 4) Why this policy improves trust A reset-based model reduces structural ambiguity and prevents users from stacking new capital onto near-expiry boosted positions to obtain disproportionate reward outcomes. This policy supports: * deterministic execution rules * transparent accounting * state machine risk controls * fair treatment across all participants These constraints are part of the broader BASIS design approach: math-constrained reward logic, deterministic system behavior, and execution precision aligned with institutional-grade infrastructure. {% hint style="success" %} Rewards accumulate in real time as the same stToken and are reflected in the Staking Wallet. When a fixed pool reaches maturity and unstake is executed, the claimable amount is auto-credited to the Staking Wallet as stToken. {% endhint %} *** Next: Unstaking & 7-Day Liquidity Buffer # Unstaking & Liquidity Buffer {% 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)). {% endhint %} If a yield product claims immediate liquidity under all conditions, the underlying unwind process should be examined carefully. BASIS applies a controlled liquidity buffer and deterministic unstaking process, including a mandatory 7-day unstaking buffer, to preserve execution precision, reduce market impact, and protect pool participants from disorderly exits. ## 1) How unstaking works on BASIS When a user unstakes, the system processes the position according to pool rules: * Flexible pools may use a controlled liquidity window to complete orderly settlement * Fixed pools can only be unstaked after the lock-up period ends * Unstaking is processed on a full-position basis only * The entire staked position is auto-MAX at unstake * Upon completion of the mandatory 7-day unstaking buffer, the claimable amount is auto-credited to the Staking Wallet as the corresponding stToken {% hint style="warning" %} There is no early exit option for fixed pools. {% endhint %} ## 2) Why a liquidity buffer exists If many users exit simultaneously, immediate forced unwinds can: * degrade execution quality * increase slippage and market impact * transfer losses to remaining participants * weaken pool stability during stressed conditions A controlled liquidity buffer, including the mandatory 7-day unstaking buffer, reduces these externalities by allowing the system to unwind positions in an ordered sequence under defined risk constraints. ## 3) How the system uses the liquidity window During the unstaking process, BASIS may: * unwind strategy positions in a predefined order * consolidate balances into withdrawable native assets where applicable * apply state-machine risk controls during stressed conditions * complete settlement only after the mandatory 7-day unstaking buffer has elapsed and the unwind path satisfies internal execution and liquidity constraints This framework supports deterministic execution and structural alpha capture while limiting disorderly market interaction. ## 4) What users should expect * Unstaking timing depends on pool mechanics, the mandatory 7-day unstaking buffer, and current market conditions * Flexible pool exits may require additional processing time during volatility or venue disruption * Fixed pool unstaking is available only after the lock-up period has ended * Rewards accumulate in real time as the same stToken in the Staking Wallet until unstake is completed * After the mandatory 7-day unstaking buffer following unstake, the resulting stToken balance appears in the Staking Wallet and can then be swapped 1:1 into the same native asset {% tabs %} {% tab title="Examples" %} * stBTC → BTC at 1:1 * stETH → ETH at 1:1 * stSOL → SOL at 1:1 * stPAXG → PAXG at 1:1 {% endtab %} {% endtabs %} ## 5) Wallet flow after unstake | Wallet | Holds | Purpose | | -------------- | --------------------------- | --------------------------------------- | | Funding Wallet | BTC, ETH, SOL, PAXG | Deposit and withdrawal of native assets | | Staking Wallet | stBTC, stETH, stSOL, stPAXG | Staking balances and reward accrual | Typical flow: 1. Unstake the full stToken position 2. Wait for the mandatory 7-day unstaking buffer to complete 3. Receive the resulting amount in the Staking Wallet as stToken 4. Swap the stToken 1:1 into the same native asset 5. Move or withdraw the native asset from the Funding Wallet {% hint style="success" %} Swap is same-token only and does not support cross-asset conversion. {% endhint %} *** Next: read Position Unwinding Protocol for the step-by-step unwind logic. # Position Unwinding Protocol {% 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)). {% endhint %} This protocol defines how BASIS reduces or closes market exposure when: * users request unstaking followed by withdrawal * the system enters protective states such as BSCB or DMM The objective is to minimize: * slippage * liquidation risk * settlement failure * hedge breakage during execution ## 1) Why unwinding is non-trivial BASIS strategies may include: * cross-venue arbitrage positions * derivative hedges such as perpetuals * on-chain lending positions * structural alpha capture workflows coordinated across venues These positions cannot be closed safely with a simple "sell everything immediately" approach. Unwinds must be sequenced so hedge relationships remain intact while capital is recovered. {% hint style="warning" %} Improper unwind ordering can temporarily expose the book to directional risk, margin stress, or forced closure. BASIS uses deterministic execution rules and state machine risk controls to reduce this risk. {% endhint %} ## 2) Canonical unwind sequence A standard unwind sequence is shown below. | Step | Action | Purpose | | ---- | -------------------------- | --------------------------------------------------------------------------------------------------- | | 1 | Close arbitrage legs | Exit offsetting venue positions and neutralize residual exposure | | 2 | Close derivative hedges | Unwind perpetual or futures hedges and restore margin safety | | 3 | Recover on-chain positions | Repay loans, withdraw collateral, and exit liquidity positions | | 4 | Reconcile balances | Confirm asset settlement and internal accounting consistency | | 5 | Finalize user crediting | After the mandatory 7-day unstaking buffer, credit claimable stToken proceeds to the Staking Wallet | This order reduces the probability that a hedged portfolio becomes unhedged during the unwind process. ## 3) Protective-state unwinding: BSCB and DMM When BSCB is triggered: * new strategy entries stop * exposure reduction takes priority over return generation * routing logic shifts toward capital preservation and execution precision When DMM is triggered: * positions are closed methodically * root-cause analysis is performed * system resumption requires stability confirmation * only validated recovery paths are re-enabled {% hint style="info" %} BASIS infrastructure is designed around deterministic execution, mathematical constraints, and state-machine-based risk controls. This includes BHLE routing characteristics such as sub-50μs latency, 100K+ OPS handling, and proprietary routing infrastructure to support precise exposure reduction under stress. {% endhint %} ## 4) User-facing implications Users may observe the following during unwind events: * withdrawals may take additional time * reward accrual may pause temporarily * safety is prioritized over speed * unstake processing may depend on completion of strategy-side closure steps * even after an eligible unstake request is accepted, claimable balances are credited only after the mandatory 7-day unstaking buffer ## 5) Relationship to staking and withdrawal flow On BASIS, rewards accrue in real time in the same stToken denomination. Unstaking behavior: * unstake is full-position only * the unstake amount is auto-MAX * there is no partial unstake flow * fixed pools can only be unstaked after the lock-up period ends * after an eligible unstake request and completion of the mandatory 7-day unstaking buffer, the claimable amount is auto-credited to the Staking Wallet as stToken After the mandatory 7-day unstaking buffer is complete and the claimable amount has been credited, users may swap 1:1 into the corresponding native asset: * stBTC → BTC * stETH → ETH * stSOL → SOL * stPAXG → PAXG Swap rules: * same-token only * 1:1 conversion only * swap fee: 0.01% Withdrawal rules: * Funding Wallet holds native assets for deposit and withdrawal * Staking Wallet holds stTokens for staking and reward accumulation * withdrawal fee: 0.05% * typical withdrawal processing targets from the Funding Wallet are: * BTC: 10 to 60 minutes * ETH, SOL, and PAXG: 1 to 10 minutes * these withdrawal times apply only after the mandatory 7-day unstaking buffer has elapsed and the user has swapped back 1:1 into the native asset; for fixed pools, the lock-up period must also have ended ## 6) Asset flow reference {% hint style="info" %} **Full Asset Flow** 1. **Funding Wallet** (BTC / ETH / SOL / PAXG) 2. Same-token 1:1 swap via BIVB 3. **Staking Wallet** (stBTC / stETH / stSOL / stPAXG) 4. Stake into eligible pool 5. Real-time reward accrual in same stToken denomination 6. Unstake (full position only) 7. Mandatory 7-day unstaking buffer 8. stToken auto-credited to Staking Wallet 9. Same-token 1:1 swap back to native asset 10. **Funding Wallet** 11. Withdraw {% endhint %} ## 7) Deposit context for unwind readiness Deposit methods differ by asset: {% tabs %} {% tab title="BTC" %} * Copy the BASIS-assigned BTC deposit address * Each account receives a unique BTC address * No Web3 wallet connection is required * Minimum deposit: 0.0001 BTC {% endtab %} {% tab title="ETH / SOL / PAXG" %} * Connect a supported Web3 wallet such as MetaMask * Deposit the native asset directly * PAXG support is live and active {% endtab %} {% endtabs %} ## 8) Operational principle A survivable system does not optimize only for nominal speed. It prioritizes: * deterministic execution * hedge integrity * settlement certainty * capital preservation under stress BASIS combines these controls with research support from Base58 Labs, emphasizing structural alpha capture through disciplined sequencing rather than uncontrolled liquidation behavior. *** Next: see Worked Examples for scenario-based unwind paths. # Worked Examples {% 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)). {% endhint %} ## Example 1, Quantity preservation vs displayed portfolio value You deposit 1 BTC when BTC trades at 100,000 in USDT-equivalent terms. * You deposit BTC by sending it to your BASIS-assigned BTC address. * You swap to 1 stBTC at a 1:1 quantity ratio. * Over time, rewards accumulate in real time and your position becomes 1.10 BTC in quantity terms. If BTC price later drops to 50,000 in USDT-equivalent terms: * Quantity increased: 1.00 BTC → 1.10 BTC * Displayed portfolio value decreased: 100,000 → 55,000 This shows: * BASIS is designed around preservation and growth of asset quantity * BASIS does not guarantee the displayed market value of the underlying asset in USDT-equivalent terms {% hint style="success" %} For BTC, deposits are made by copying your unique BASIS-assigned deposit address. No Web3 wallet connection is required for BTC deposits. {% endhint %} ## Example 2, Lock-up booster effect Assume an illustrative base net yield rate for a period is 0.40%. Under the Booster schedule, a 180D lock-up applies a +100% booster, equivalent to 2× the base rate. | Lock-up | Booster | Illustrative result on 0.40% base | | ------- | ------- | --------------------------------- | | 14D | +10% | 0.44% | | 30D | +20% | 0.48% | | 90D | +50% | 0.60% | | 180D | +100% | 0.80% | Actual realized yield depends on: * market conditions * execution precision * structural alpha capture conditions * safety state behavior * deterministic risk controls ## Example 3, Booster reset on add-stake You stake BTC with a displayed portfolio value of 10,000 in USDT-equivalent terms under a 90D lock-up. After 30 days, you add more BTC with a displayed portfolio value of 5,000. Under the reset policy: * the lock timer resets at the new add-stake timestamp * the aggregated staked position follows the new schedule * rewards continue to accumulate as stBTC in the Staking Wallet This prevents booster gaming and preserves fairness across participants. {% hint style="warning" %} Unstaking is processed as full-position only. BASIS automatically applies MAX on unstake, and the claimable amount is auto-credited to your Staking Wallet as stToken. {% endhint %} ## Example 4, Fixed pool unstaking rationale If many users request unstaking around the same time: * immediate liquidation can create slippage and adverse execution * those effects may reduce net outcomes for remaining participants * a defined lock-up structure supports orderly strategy unwinds under state machine controls For fixed pools: * unstaking is available only after the selected lock-up period ends * there is no early exit option This framework supports deterministic execution, mathematical constraints, and consistent risk handling. *** If you want to explore these mechanics further, read Risk Disclosure and Risk Model next. # Why DRR Rises and Falls: A Structural Explanation {% 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 %} The [Glossary](/reference/glossary) defines DRR as follows: > "DRR stands for Daily Reward Rate. It is an estimated daily yield rate on deployed capital, expressed as a percentage. DRR reflects recent strategy performance and is not guaranteed." DRR is cyclical because it is market-derived. It is not a fixed coupon. In the [Lock-up Economics](/economics-and-rewards/lock-up-economics) model, yield is expressed as: `Yield ~= (1 - b) x C x r` where `b` is the required liquidity buffer fraction, `C` is total capital, and `r` is the realized strategy yield rate on deployed capital. The variable `r` is externally determined by market conditions, not by BASIS's operational efficiency alone. When market structure offers stronger carry, wider spreads, higher utilization, or more positive funding, DRR can rise. When those conditions compress, DRR can fall. This is a repeating market cycle, not a one-way decline. *** ## Up cycle: why DRR can expand DRR tends to rise during strong demand regimes. These are periods when speculative leverage increases, cross-venue price dispersion widens, DeFi utilization rises, and funding rates turn more positive. The [Funding Rate Dynamics](/strategies/funding-rate-dynamics) page defines the funding mechanism directly: > "Funding Rate > 0 -> Longs pay Shorts. Funding Rate < 0 -> Shorts pay Longs." For delta-neutral funding capture, positive funding is structurally favorable because the short perpetual leg receives funding while the spot or staked asset leg preserves directional neutrality. BASIS documents the following historical 8-hour funding ranges as illustrative historical observations, not forward expectations: | Asset | Typical positive range | Extreme positive range | Typical negative range | Extreme negative range | | ----- | ---------------------: | ---------------------: | ---------------------: | ---------------------: | | BTC | 0.005% to 0.030% | >0.100% | -0.005% to -0.020% | -0.075% | | ETH | 0.005% to 0.035% | >0.150% | -0.005% to -0.025% | -0.090% | | SOL | 0.010% to 0.050% | >0.200% | -0.010% to -0.030% | -0.100% | ### Why PAXG is not in this table This table is quoted directly from BASIS's Funding Rate Dynamics page, which covers BTC, ETH, and SOL only. PAXG uses a different yield structure and is intentionally excluded here. | Factor | BTC / ETH / SOL perpetuals | PAXG perpetual | | --------------------- | ------------------------------------ | ------------------------------------------------------------------------------------ | | Funding history depth | Multi-year track record | Approximately since March 2025, a shorter sample | | 24h perpetual volume | Multi-billion dollars per asset | Roughly $90 to $100 million, about two orders of magnitude smaller | | Observed funding band | Wide, matches the ranges shown above | Narrower, has stayed inside a tighter band than BTC's typical range | | Yield documentation | Single funding-rate mechanism | Multiple channels, see Golden BASIS spot-perp module and PAXG Real-World Asset Yield | {% hint style="info" %} Because of these differences, BASIS documents PAXG yield separately rather than folding it into the BTC, ETH, SOL funding table above. {% endhint %} The same page notes that a midpoint funding rate of 0.015% per 8 hours annualizes to approximately 16.4% simple gross before costs. It also notes that BTC funding above 0.100% per 8 hours annualizes to more than 109.5% simple gross before costs. These figures illustrate the scale that funding-based carry can reach when speculative demand is strong. They are historical reference points, not projections. In up cycles, more than one BASIS yield source can expand at the same time: * Spatial Arbitrage (BQAE) * Funding Rate Capture (Delta-Neutral Basis Trade) * Blue-Chip DeFi Lending + Liquid Staking * PAXG Real-World Asset Yield These sources are diversified and not perfectly correlated, but strong risk appetite in the broader market can lift more than one of them at the same time. *** ## Down cycle: why DRR compresses DRR compresses when expected edge compresses across the platform's yield sources. Recent market conditions illustrate this side of the cycle. BTC perpetual funding on major venues has recently traded near flat, occasionally printing negative, well below the typical positive BTC range of 0.005% to 0.030% per 8 hours documented above. Sentiment indicators such as the Crypto Fear & Greed Index have been concentrated in Extreme Fear territory, consistent with reduced speculative leverage. When leveraged long demand declines, positive funding falls toward zero or turns negative. Realized volatility does not need to collapse for this to happen. Price can continue moving while leverage-driven demand for perpetual longs stays weak, which compresses funding-based carry specifically, separate from general price volatility. This is a demand-side and leverage-side compression, not simply "the market went quiet." This is the same cycle described in the funding mechanics: when funding becomes less positive, the expected carry available to a delta-neutral, short-perpetual structure declines. *** ## The floor mechanism: why the reward rate does not go negative for users This is the central mechanical point of this page and it should be read independently of the disclosures that follow it. BASIS's documented control stack is specifically designed so that adverse funding conditions are absorbed by the system through monitoring, exposure reduction, and pausing, rather than being passed through as a negative rate against a user's reward balance. The design objective, and the documented outcome of that design, is that DRR compresses toward a protective floor near 0% under adverse conditions. It does not settle into negative territory and it does not debit previously credited stToken units. This follows directly from four layers of documented control. ### 1. EV gating The [Arbitrage Economics: Edge vs Cost](/research-library-deep-dives/arb-economics) page defines: `EV = E[Edge] - sum(C_trade) - R_premium` The documentation states: > "BASIS initiates a trade only when EV > 0 under conservative parameters." A candidate slice that is not EV positive is rejected rather than executed. This rule applies across all four yield sources. It stops new deployment before an unfavorable trade is entered, rather than entering it and hoping conditions improve. ### 2. The funding response table The [Funding Rate Dynamics](/strategies/funding-rate-dynamics) page documents BASIS's automatic response to negative funding: | Funding Rate (8h) | BASIS Response | | ------------------ | --------------------------------------------------------------- | | > 0% | Normal operation | | 0% to -0.005% | Elevated monitoring, no immediate reallocation | | -0.005% to -0.020% | Exposure reduction on the affected asset, potentially up to 50% | | < -0.020% | Strategy pause on the affected asset until conditions normalize | This table exists precisely to prevent adverse funding from persisting at scale. Mildly negative funding triggers monitoring. More adverse funding triggers exposure reduction on the affected asset. Deeply adverse funding triggers a pause on that asset until conditions normalize. The documentation states the intent directly: > "The objective is not continuous deployment at any cost. BASIS prioritizes deterministic execution, math-constrained risk management, and capital preservation when expected carry becomes structurally unfavorable." The response table works progressively, not instantly. Its purpose is to compress the size and duration of any negative-funding exposure toward zero as quickly as the documented thresholds allow, rather than to let a module remain fully deployed against a persistently negative rate. Combined with EV gating on new slices, this is the mechanism that keeps the platform's realized reward rate from settling into sustained negative territory. ### 3. BSCB and DMM The [BSCB Sentinel Circuit Breaker](/risk-safety-and-asset-protection/bscb) is: > "An automated, rule-based safety mechanism that halts or reduces execution activity when predefined risk thresholds are breached." Triggers include slippage anomalies, venue API failures, margin health deterioration, and pricing reference instability. [DMM, Defensive Maintenance Mode](/risk-safety-and-asset-protection/dmm), is the most severe operational state. On activation, it applies a full halt to automated trading, staking actions, swaps, and withdrawal processing until human review and a formal Root Cause Analysis are complete. It is documented as a safety mechanism, not a discretionary performance tool. Together, EV gating, the funding response table, BSCB, and DMM enforce one principle: do not continue deploying capital at any cost when expected carry or operating conditions become structurally unfavorable. ### 4. BIVB and stToken quantity preservation The [BIVB & stTokens](/whitepaper/bivb-and-sttokens) design converts native assets into staking tokens at a strict 1:1 quantity ratio. Rewards accrue in real time in the same stToken. The documented worked example shows a deposit of 1 BTC growing to 1.10 BTC in quantity terms over time. This reward-accrual mechanism is quantity-additive. It is not designed to subtract previously credited stToken units because a module becomes temporarily ineligible. When a module pauses, the documented outcome is that new rewards from that module stop accruing for that window. It is not a mechanism that reaches back and reduces stToken already credited to a user's Staking Wallet. The [FAQ](/faq/faq) confirms this pause behavior directly: > "Can rewards pause? Yes. Rewards may pause when protective controls are triggered, when diagnostic monitoring is active for root cause analysis, or when strategy modules become temporarily ineligible due to slippage, venue incidents, or stress conditions. These pauses are a safety feature." *** ## This is a different claim from yield-level or principal-value guarantees The floor statement above is a mechanism-level statement about the reward-transmission path. It states that the documented control stack is designed to compress adverse funding toward a near-0% floor rather than a negative rate, and that already-credited stToken balances are not reduced because a module becomes temporarily ineligible. That is a separate claim from saying how large a positive DRR will be, or that it will stay above any specific percentage. BASIS does not guarantee the size or level of positive yield. Actual DRR depends on realized strategy performance, prevailing market conditions, execution costs, available liquidity, and the number of eligible opportunities at any given time. BASIS also does not guarantee the USD-equivalent market value of a user's principal. BTC, ETH, SOL, and PAXG can decline in fiat terms even while their staked quantity is preserved or growing. The BIVB and stToken design preserves native-asset quantity mechanics. It does not fix or protect the fiat-denominated value of that quantity, which is a separate, market-driven variable. These two statements are not in tension. A reward rate that is mechanically floored near zero is a distinct fact from a promise about how large future rewards will be, or about the fiat value of a user's holdings. *** ## Diversification across yield sources BASIS uses four yield sources that are diversified and not perfectly correlated: | Yield source | Primary driver | | --------------------------------------- | --------------------------------------------------------- | | Spatial Arbitrage (BQAE) | Cross-venue dispersion and executable price differences | | Funding Rate Capture | Perpetual funding and basis conditions | | Blue-Chip DeFi Lending + Liquid Staking | Utilization, staking rates, protocol-level opportunity | | PAXG Real-World Asset Yield | Gold-linked asset deployment and related market structure | This diversification supports floor-like behavior in the blended DRR. If one module pauses because it is not EV positive, other modules may remain eligible. If conditions compress broadly across all four sources at once, the blended DRR moves toward the protective near-0% state described above rather than toward a negative number, because each individual module is subject to the same EV gating and response controls. *** ## Illustrative range, not guaranteed, not a forecast The table below is illustrative. It describes documented mechanism and historical range inputs. It is not a forecast, a promised rate, or a cap. | Reference state | Documented basis | Mechanical meaning | | ----------------------------------- | -------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- | | Lower bound: protective pause state | Affected source fails EV gating or funding falls below -0.020% per 8 hours | Affected source contributes near 0% for that window. No debit is applied to already-credited stToken. | | Mid-cycle positive reference | Funding at approximately 0.015% per 8 hours | Approximately 16.4% simple gross annualized before costs | | High-cycle positive reference | BTC funding above the documented extreme of 0.100% per 8 hours | More than 109.5% simple gross annualized before costs | The lower bound in this table is the pause mechanism itself, not a guaranteed positive percentage above zero. The upper reference is drawn from BASIS's own documented historical extreme funding data. It is not a cap and not a forward projection. *** ## Industry-wide funding compression Yield compression has also appeared recently in other public delta-neutral funding-capture products in the broader market. This is directional evidence that funding-driven yield compression is a market-cycle effect across the category, not specific to BASIS. Historically, funding-driven yield has re-expanded when speculative leverage returns, positive funding normalizes, and executable spreads widen again. BASIS's control stack is designed to participate when EV is positive and to reduce or pause when it is not, in either direction of the cycle. *** ## Closing disclosure Historical performance figures on this page are illustrative and reflect past conditions only. BASIS targets yield through market-neutral execution and deterministic risk controls. Actual results depend on realized strategy performance. BASIS does not guarantee any specific yield level or the USD-equivalent value of a user's principal. Third-party exchange risk, counterparty risk, smart contract risk, regulatory risk, and other catastrophic tail risks are addressed in the Risk Disclosure (Master) page and DMM documentation, and are not restated here. None of the disclosures above change the mechanism-level statement made on this page: under BASIS's documented controls for ordinary adverse-funding conditions, EV gating rejects unfavorable new trades, the funding response table compresses and pauses adverse exposure, BSCB and DMM provide additional automated and manual safeguards, and the BIVB/stToken design does not subtract previously credited reward units. Together, these are the reasons the platform's reward-transmission path is designed to compress toward a near-0% floor rather than to transmit a negative rate to users. *** ## See Also * [Yield Sources: Where Returns Come From](/economics-and-rewards/yield-sources) * [Lock-up Economics (Capital Efficiency)](/economics-and-rewards/lock-up-economics) * [Funding Rate Dynamics](/strategies/funding-rate-dynamics) * [BSCB: Sentinel Circuit Breaker](/risk-safety-and-asset-protection/bscb) * [DMM: Defensive Maintenance Mode](/risk-safety-and-asset-protection/dmm) * [Risk Disclosure (Master)](/risk-safety-and-asset-protection/risk-disclosure) # Trinity Overview {% 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)). {% endhint %} Trinity is BASIS’s contribution-aligned referral network. It ties rewards to measurable platform activity rather than static network structure: * Sign-ups do not create rewards. * Network depth alone does not create rewards. * Rewards are generated when downstream participants produce eligible activity and a distribution event is recorded by the system. ## 1) The central design choice: activity-based distribution Trinity calculates and allocates upstream rewards based on realized downstream activity recorded within the platform. This creates two important properties: * Alignment: reward flow follows actual platform usage and participation * Auditability: each distribution is associated with a discrete accounting event and timestamp {% hint style="success" %} Trinity is designed as a contribution-based reward system, not a passive sign-up structure. Reward eligibility depends on real activity inside BASIS. {% endhint %} ## 2) Nodes describe reach, not hierarchy Trinity uses Node to describe reward reach scope, not a fixed hierarchy of people. * Node A: activity from users you directly referred * Node B: activity from the next connected scope * Node C: activity from the expanded connected scope Your assigned policy parameters determine which nodes are active for reward calculation. ## 3) Policy parameters define reach and limits Trinity parameters control: * how far rewards can flow through the referral network * applicable percentage rates where defined * the maximum reward scope or cap available under the active policy This is not a status badge. It is a ruleset governing distribution logic. ## 4) Why Trinity exists inside BASIS A structural alpha platform requires aligned incentives, durable participation, and strict control logic. Trinity is designed to: * reward contributors in proportion to the activity their referral network generates * avoid pure sign-up driven mechanics * preserve auditability through deterministic accounting events * remain compatible with BASIS risk controls and system constraints ## 5) Platform context Trinity operates within the broader BASIS infrastructure: | Platform Property | Description | | ----------------- | ------------------------------------------------------------------------- | | Operator | BASIS DIGITAL INFRASTRUCTURE LTD | | Jurisdiction | Seychelles IBC | | LEI | 254900IX2F2KCWNSSS64 | | Research | Base58 Labs research support | | Execution Model | Deterministic execution with math-constrained state transitions | | Alpha Source | Structural alpha capture and execution precision | | Infrastructure | BHLE with sub-50μs latency, 100K+ OPS, proprietary routing infrastructure | {% hint style="info" %} BASIS emphasizes deterministic execution, mathematical constraints, and state machine risk controls to support transparent reward accounting and platform-wide consistency. {% endhint %} *** Next: read Key Definitions. # Key Definitions (Node, Reach, Claim, Up-to Cap) The Trinity System is the three-pillar reward and risk control framework that governs how rewards are calculated, distributed, and constrained on the BASIS platform. It defines the relationship between internal accounting, staking receipt tokens, and time-based reward boosters. {% 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)). {% endhint %} *** ## 1. The Three Pillars The Trinity System consists of three interconnected components: ### Pillar 1: BASIS Intrinsic Value Balance (BIVB) The BIVB is the platform’s internal accounting layer that tracks the real-time value of pooled capital and the net results generated by the execution engine. It functions as a transparent ledger recording deposits, withdrawals, fees, swaps, staking state changes, and reward accrual. Key properties: * Updated in real time as execution outcomes are recognized * Denominated in USDT for internal accounting consistency * Reconciled against wallet balances, settlement records, and internal state transitions * Used as the base reference for stToken valuation across supported assets * Governed by deterministic execution logic and state-machine risk controls ### Pillar 2: stTokens stTokens are the internal staking receipt tokens users hold after swapping native tokens on a 1:1 same-token basis and staking them into a pool. Examples: * BTC → stBTC * ETH → stETH * SOL → stSOL * PAXG → stPAXG An stToken represents a user’s proportional claim on the relevant staking pool and its accrued rewards. Key properties: * Created through same-token 1:1 swaps only * Non-transferable within the current platform design * Held in the Staking Wallet * Rewards accumulate in real time as the same stToken * Upon unstake, the claimable amount is auto-credited to the Staking Wallet as stToken {% hint style="success" %} Funding Wallet = native tokens for deposit and withdrawal Staking Wallet = stTokens for staking and reward accrual {% endhint %} ### Pillar 3: Booster Multiplier The Booster Multiplier is the time-lock reward weighting mechanism for fixed staking pools. Users who commit to longer lock-up periods receive higher reward amplification. #### Booster Schedule | Pool Type | Lock-Up | Booster | | ------------- | -------- | ------- | | Flexible | None | +0% | | Fixed 14-Day | 14 days | +10% | | Fixed 30-Day | 30 days | +20% | | Fixed 90-Day | 90 days | +50% | | Fixed 180-Day | 180 days | +100% | {% hint style="warning" %} Fixed pools can be unstaked only after the lock-up period ends. Early exit is not available. Unstake is full-position only. The unstake action is auto-MAX for the entire staked balance in that pool. {% endhint %} *** ## 2. How the Three Pillars Interact The reward flow follows this sequence: 1. Users deposit a supported native asset into the Funding Wallet 2. The asset is swapped 1:1 into the corresponding stToken 3. The user stakes that stToken into a flexible or fixed pool 4. The execution infrastructure generates net reward contribution through structural alpha capture and execution precision 5. The BIVB updates in real time to reflect realized pool results 6. Rewards are allocated to staked positions according to pool rules and booster weighting 7. Rewards accumulate continuously as the same stToken in the Staking Wallet view 8. When the user unstakes, the full claimable amount is auto-credited to the Staking Wallet as stToken ### Reward Logic At a high level, a user’s reward outcome is determined by: * Their staked balance * The pool’s realized net performance * Their selected booster, if any * The timing and duration of active stake participation This can be represented conceptually as: {% hint style="info" %} **Reward Formula** User Reward = Staked Position x Pool Net Result Share x Booster Weight {% endhint %} {% hint style="info" %} BASIS uses deterministic execution, mathematical constraints, and state-machine risk controls to govern reward attribution and capital protection. {% endhint %} *** ## 3. Glossary of Trinity Terms | Term | Definition | | ------------------------ | --------------------------------------------------------------------------------------------------------------------------- | | BIVB | BASIS Intrinsic Value Balance. The master internal accounting layer for pooled capital, realized results, and reward state. | | stToken | An internal staking receipt token representing a user’s position in a corresponding staking pool. | | Booster | A time-based reward multiplier applied to fixed staking pools. | | Flexible Pool | A pool without lock-up, using the base reward rate with no booster. | | Fixed Pool | A staking pool with a defined lock-up period and an associated booster. | | Funding Wallet | The wallet section that holds native tokens such as BTC, ETH, SOL, and PAXG for deposit and withdrawal. | | Staking Wallet | The wallet section that holds stTokens used for staking and reward accumulation. | | Claimable Amount | The total unstaked stToken amount, including accrued rewards, auto-credited to the Staking Wallet upon unstake. | | Full-Position Unstake | The unstake model used by BASIS. A user exits the entire position in a pool rather than a partial amount. | | Net Result | Realized outcome after execution costs, routing costs, and operational deductions. | | Structural Alpha Capture | BASIS’s execution model for harvesting inefficiencies through routing, timing, and market-structure optimization. | *** ## 4. Related Operational Context ### Asset Flow Summary {% tabs %} {% tab title="BTC" %} * Deposit by copying your unique BASIS-assigned BTC address * No Web3 wallet connection required * Minimum deposit: 0.0001 BTC * Swap: BTC → stBTC only * Withdrawal processing time: 10 to 60 minutes {% endtab %} {% tab title="ETH / SOL / PAXG" %} * Deposit by connecting a supported Web3 wallet such as MetaMask * Swap only into the corresponding stToken: * ETH → stETH * SOL → stSOL * PAXG → stPAXG * Withdrawal processing time: 1 to 10 minutes {% endtab %} {% endtabs %} ### Platform Fee Reference | Action | Fee | | ---------- | ----- | | Deposit | 0% | | Withdrawal | 0.05% | | Swap | 0.01% | *** ## 5. System Design Principles The Trinity System is designed around the following principles: * Deterministic execution over discretionary handling * Internal accounting consistency across all supported assets * Reward attribution constrained by explicit pool state * Transparent staking mechanics with full-position unstake behavior * Infrastructure-first performance supported by BHLE routing architecture * Trust through math-based controls rather than narrative claims BASIS execution infrastructure includes: * Sub-50μs latency * 100K+ OPS throughput * Proprietary routing infrastructure * State-machine risk controls * Research support from Base58 Labs For account navigation, the primary dashboard sections are: * Stake * Assets * Referral * Support * Account # Eligibility & Access {% 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)). {% endhint %} ## Eligibility Table | Level | Eligibility | Referral Reach | Reward Scope | Total Cap | | --------------- | ----------------------------------------------------------- | ----------------------------------------- | ------------------------------------------------------- | --------: | | VIP1 Standard | Open to all participants, no minimum capital requirement | Node A | Node A: 15% | Up to 15% | | VIP2 Advanced | Personal + network staking volume ≥ 50,000 USDT equivalent | Node A, Node B | Node A: 15% / Node B: 8% | Up to 23% | | VIP3 Leadership | Personal + network staking volume ≥ 300,000 USDT equivalent | Node A, Node B, Node C + Leadership Bonus | Node A: 18% / Node B: 10% / Node C: 7% / Leadership: 5% | Up to 40% | ## What "network staking volume" means Network volume includes: * Your own staking volume * The combined staking volume of eligible participants within your contribution-aligned referral network reach The dashboard is the source of truth for all referral accounting. {% hint style="warning" %} Displayed values may use USDT as an internal accounting and reporting unit only. Funding Wallet deposits and withdrawals are available only in BTC, ETH, SOL, and PAXG. Staking rewards accumulate in real time as the same stToken in the Staking Wallet. {% endhint %} ## How eligibility is applied 1. All users begin at the VIP1 Standard level. 2. No application is required. 3. The system updates eligibility automatically when cumulative volume crosses the relevant threshold. 4. After each reconciliation cycle, eligibility may be adjusted if volume falls below the required threshold. VIP tier eligibility is calculated automatically based on combined personal and network staking volume. No application is required for VIP1, VIP2, or VIP3. For VIP3 Leadership Bonus eligibility review, contact with subject line: `VIP3 Leadership Review Request`. ## Notes * Funding Wallet: holds native assets for deposit and withdrawal * Staking Wallet: holds stBTC, stETH, stSOL, and stPAXG for staking and reward accrual * Swaps are same-token only at 1:1: * BTC → stBTC * ETH → stETH * SOL → stSOL * PAXG → stPAXG *** Next: read [Reward Flow & Calculation](/trinity-referral-and-vip/reward-flow). # Reward Flow & Calculation {% 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)). {% endhint %} The referral network operates on discrete settlement events. Reward distribution is triggered when an eligible downstream claim event is processed. ## 1) Event sequence ```mermaid flowchart TD A[Downstream user unstakes or triggers claim settlement] --> B[Rewards are finalized] B --> C[Referral engine evaluates eligible upstream participants] C --> D[System checks active nodes, eligibility, and policy constraints] D --> E[Rewards distributed to eligible upstream accounts] ``` ## 2) Calculation base {% hint style="info" %} Reward variables {% endhint %} | Variable | Meaning | | ---------------- | ----------------------------------------------------------- | | C | Downstream claim amount, displayed in USDT-equivalent terms | | r\_A, r\_B, r\_C | Reward rates for eligible referral nodes | | Cap | Maximum reward ceiling defined by policy | {% hint style="info" %} Node reward formula for Node A: $$ \text{Reward}\_A = C \cdot r\_A $$ Total upstream reward remains bounded by Cap. {% endhint %} Production logic may include additional eligibility checks, state validation, anti-abuse filters, and contribution-based reward controls. ## 3) Worked example Assume: * You qualify for a referral structure where Node A and Node B are active * Your direct referral settles a claim valued at 100 in USDT-equivalent display terms Then: * Node A reward = 100 × 15% = 15 If a downstream participant one level further settles another claim valued at 100: * Node B reward = 100 × 8% = 8 Combined rewards remain subject to the applicable reward cap. {% hint style="warning" %} Displayed examples use USDT-equivalent accounting for calculation clarity only. Settlement, balances, staking, and withdrawals on BASIS are managed through native assets and corresponding stTokens. {% endhint %} ## 4) VIP3 Leadership bonus A VIP3 Leadership bonus may apply to qualified participants with broader ecosystem contribution. This bonus: * Rewards sustained network contribution * May extend beyond standard Node C scope where policy permits * Always remains within the applicable maximum reward ceiling ## 5) Important constraints * No qualifying claim event means no reward distribution * No active eligible node means no reward distribution * The configured cap cannot be exceeded * Eligibility is determined by current system state and policy rules at the time of settlement These controls support auditability, deterministic reward processing, and bounded reward issuance. ## 6) Operational notes {% tabs %} {% tab title="Settlement Logic" %} * Rewards are evaluated on discrete claim settlement events * Distribution is policy-bound and state-dependent * Invalid or ineligible paths are excluded automatically {% endtab %} {% tab title="Risk Controls" %} * Deterministic execution paths * State machine-based validation * Math-constrained reward ceilings * Anti-abuse monitoring and structural integrity checks {% endtab %} {% tab title="Infrastructure Context" %} * Research support from Base58 Labs * Structural alpha framework with deterministic execution controls * BHLE infrastructure targeting sub-50μs latency and 100K+ OPS {% endtab %} {% endtabs %} *** Next: read Grace Period & Tier Maintenance. # Grace Period & Maintenance {% 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)). {% endhint %} The Grace Period is a 48-hour buffer after a fixed pool lock-up ends. During this window, users may unstake their full position while preserving the booster applied during the completed lock-up period. {% hint style="warning" %} Fixed pools do not support early exit. Unstaking becomes available only after the selected lock-up period has fully ended. {% endhint %} *** ## 1. How it works When a fixed pool lock-up period ends, the position does not automatically unstake. Instead, it enters a 48-hour Grace Period: * During the 48-hour Grace Period: * You may initiate unstake for the full staked position only * The completed fixed-term booster remains applicable to rewards earned through the lock-up period * Once unstake is confirmed, the claimable amount is auto-credited to your Staking Wallet as stToken * After the Grace Period: * If no action is taken within 48 hours, the position automatically rolls into the flexible staking state * Previously earned rewards remain preserved * Ongoing rewards continue at the base rate going forward {% hint style="info" %} BASIS uses full-position unstake only. Partial unstake is not supported. The unstake amount is automatically set to MAX. {% endhint %} *** ## 2. Why the Grace Period exists The Grace Period reduces operational friction at lock-up expiry. Without a buffer window, users would need to act at the exact expiration time to preserve the intended fixed-term outcome. The Grace Period provides a practical response window while preserving the integrity of the fixed-pool reward model. This design supports: * predictable user experience * clear state transitions * deterministic reward handling * reduced timing sensitivity around maturity events These controls align with the broader BASIS approach to deterministic execution, math-constrained reward logic, and state machine risk controls. *** ## 3. Notification schedule The platform sends notifications at the following intervals: | Timing | Notification | | --------------------------------- | -------------------------------------------------------------------------------------------------------------------- | | 7 days before expiry | "Your 90-day lock-up expires in 7 days. Plan your next action." | | 24 hours before expiry | "Your lock-up expires tomorrow. You will have 48 hours to unstake with your completed booster." | | At expiry | "Your lock-up has expired. Grace Period has begun. You have 48 hours to unstake." | | 12 hours before Grace Period ends | "Your Grace Period ends in 12 hours. After that, your position will roll into the base-rate flexible staking state." | *** ## 4. Example scenario {% hint style="success" %} Rewards accumulate in real time as the same stToken in the Staking Wallet. {% endhint %} ### Example: ETH fixed pool 1. A user deposits ETH through a connected Web3 wallet such as MetaMask. 2. The user swaps ETH to stETH at a 1:1 ratio. 3. The user stakes the full stETH balance in the 90-day fixed pool with a +50% booster. 4. The 90-day lock-up ends. 5. The position enters the 48-hour Grace Period. 6. The user initiates unstake within the Grace Period. 7. The unstaked amount and accumulated reward are auto-credited to the Staking Wallet as stETH. 8. The user may then swap stETH to ETH at 1:1 and withdraw to the connected wallet. If no action is taken during the 48-hour Grace Period, the position moves to the base-rate flexible staking state after the window ends. *** ## 5. Booster reference | Fixed pool duration | Booster | | ------------------- | ------- | | 14D | +10% | | 30D | +20% | | 90D | +50% | | 180D | +100% | *** ## 6. Related wallet behavior | Wallet | Purpose | | -------------- | ------------------------------------------------------------------------------------ | | Funding Wallet | Holds native assets for deposit and withdrawal: BTC, ETH, SOL, PAXG | | Staking Wallet | Holds stTokens used for staking and reward accumulation: stBTC, stETH, stSOL, stPAXG | {% hint style="info" %} Supported swaps are same-token only at 1:1: * BTC ↔ stBTC * ETH ↔ stETH * SOL ↔ stSOL * PAXG ↔ stPAXG {% endhint %} {% hint style="info" %} USDT is used as an internal accounting and display unit only. It is not a depositable or withdrawable asset. {% endhint %} # Simulator Embed Guide {% 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)). {% endhint %} BASIS can publish a simulator to help users understand staking outcomes, booster effects, and reward flow under different assumptions. ## 1) Why a simulator matters A simulator improves: * user understanding * support efficiency * decision clarity * trust through transparent modeling It should reflect the live product structure accurately, including: * same-token 1:1 swaps only * real-time reward accumulation in the Staking Wallet * full-position unstake behavior * fixed pool lock-up constraints * booster effects by duration {% hint style="success" %} A reliable simulator strengthens trust when it mirrors deterministic platform rules and state transitions exactly. {% endhint %} ## 2) Recommended simulator inputs Recommended inputs include: * deposit asset: BTC / ETH / SOL / PAXG * deposit amount * selected staking token: stBTC / stETH / stSOL / stPAXG * staking duration assumption * booster selection: * 14D: +10% * 30D: +20% * 90D: +50% * 180D: +100% (2×) * reward accumulation period * unstake timing assumption after lock-up completion * referral network contribution assumptions, if applicable ## 3) Recommended simulator outputs Recommended outputs include: * estimated stToken rewards * projected Staking Wallet balance over time * booster-adjusted reward comparison * lock-up completion timeline * full-position unstake outcome * auto-credited claimable amount to the Staking Wallet as stToken * fee impact summary: * Deposit: 0% * Swap: 0.01% * Withdrawal: 0.05% ## 4) Product rules to reflect in the simulator | Rule | Requirement | | ------------------------- | ------------------------------------------------------------- | | Deposit assets | BTC, ETH, SOL, PAXG only | | BTC deposit flow | Copy your BASIS-assigned deposit address | | ETH/SOL/PAXG deposit flow | Connect a Web3 wallet such as MetaMask | | Swap behavior | Same-token 1:1 only | | Supported pairs | BTC→stBTC, ETH→stETH, SOL→stSOL, PAXG→stPAXG | | USDT usage | Internal accounting/display unit only | | Minimum BTC deposit | 0.0001 BTC | | Rewards | Accumulate in real time as the same stToken | | Wallet separation | Funding Wallet for native assets, Staking Wallet for stTokens | | Unstake behavior | Entire staked position only | | Fixed pools | Unstake only after lock-up period ends | | Withdrawal timing | BTC: 10 to 60 minutes, ETH/SOL/PAXG: 1-6min | {% hint style="warning" %} The simulator should not model unsupported actions such as USDT deposits, cross-token swaps, or partial unstake from fixed pools. {% endhint %} ## 5) GitBook embed example If the simulator is hosted at a public URL, GitBook can embed it: ```html ``` ## 6) Implementation guidance Use the simulator to present deterministic product logic rather than speculative outcomes. Recommended principles: * keep calculations aligned with live platform rules * update simulator logic in the same release as policy changes * display assumptions clearly * separate estimated reward projection from operational timing * reflect state machine constraints and execution precision assumptions consistently ## 7) Trust note BASIS emphasizes deterministic execution, mathematical constraint systems, and state machine risk controls. Platform confidence should come from: * transparent rule modeling * precise balance transitions * structural alpha capture logic * research alignment with Base58 Labs * infrastructure characteristics such as sub-50μs latency, 100K+ OPS, and proprietary routing systems in BHLE environments *** Next: read Trinity FAQ. # Trinity FAQ {% 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)). {% endhint %}
Is Trinity a “reward on sign-up” program? No. Trinity rewards are generated when referred participants perform Claim events on accrued rewards. If no claim occurs, no Trinity distribution is generated.
Are nodes “levels” like a typical referral tree? No. Nodes represent contribution reach within the contribution-aligned referral network, not fixed people-based levels.
Can Trinity rewards exceed the applicable cap? No. Where a cap applies, total Trinity rewards cannot exceed that limit.
What happens if my qualification status changes? Qualification status is evaluated according to the active Trinity policy. If a grace period applies, it is handled under that policy. If required thresholds are not maintained after the applicable period, qualification status may be adjusted accordingly.
Do I need to apply manually for qualification upgrades? No. Where upgrades are supported by policy, they are applied automatically once the relevant conditions are met.
Is Trinity guaranteed income? No. Trinity depends on referred participants staking and claiming rewards. It is not guaranteed. Before relying on Trinity in any decision, review the Risk Disclosure and note that USDT values shown on the platform are internal accounting references only.
# Risk Disclosure (Master) {% 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 seeks to generate market-neutral yield through proprietary execution systems, structured staking design, and structural alpha capture. However, like all digital asset systems and financial infrastructures, BASIS is exposed to risk. This document is written in a control-manual style. The objective is to make risks explicit, testable, and understandable. ### 1) General disclaimer * Digital asset markets are dynamic and subject to rapid change. * Historical performance figures are illustrative and reflect past conditions only. * BASIS targets yield through market-neutral execution and deterministic risk controls. Actual results depend on realized strategy performance. * Dashboard valuations can be shown in USDT as a reference unit, interpreted as a USD-equivalent estimate. * USDT is used for internal accounting and display only. It is not supported for deposit or withdrawal. * Supported asset flows are native-token based: * BTC deposit via a BASIS-assigned address unique to each account * ETH, SOL, and PAXG deposit via connected Web3 wallets * Swaps on BASIS are same-token only and 1:1: * BTC → stBTC * ETH → stETH * SOL → stSOL * PAXG → stPAXG * BASIS operates with institutional-grade control objectives supported by active, internationally accredited ISO/IEC 27001:2022 and ISO/IEC 20000-1:2018 certifications held by BASIS DIGITAL INFRASTRUCTURE LTD and publicly verifiable on IAF CertSearch. Certification supports governance and operational discipline, but does not eliminate market, technical, or counterparty risk. ### 2) Core principle: quantity preservation vs valuation risk BASIS is designed to preserve and grow asset quantity through: * 1:1 conversion between native assets and staking tokens * distribution of realized rewards in the same stToken * automatic crediting of unstaked claimable amounts into the Staking Wallet after the mandatory 7-day unstaking buffer However, BASIS does not guarantee the USDT valuation, USD valuation, or market price of the underlying asset. Users should distinguish between: * "I hold more BTC, ETH, SOL, or PAXG" * and * "the displayed USD-equivalent value of that asset is stable" These are not the same. {% hint style="warning" %} Quantity growth does not eliminate market price risk. If the underlying asset declines in market value, the USD-equivalent value of holdings will also decline even when asset quantity increases. {% endhint %} ### 3) Risk categories (summary) 1. Market volatility risk\ The market value of BTC, ETH, SOL, or PAXG can decline materially. 2. Reference unit risk\ USDT can deviate from USD, and dashboard valuations shown in USDT might not match executable market value. 3. Operational strategy risk\ Execution failures, slippage spikes, partial fills, routing errors, timing mismatches, or venue-side interruptions can reduce expected performance. 4. Third-party venue risk\ Exchanges, custodial venues, counterparties, infrastructure providers, or liquidity venues could impose withdrawal halts, experience insolvency, suffer hacks, or face regulatory restrictions. 5. Technical risk\ Wallet errors, account security failures, chain instability, software defects, network failures, oracle dependency issues, or smart contract risk where applicable can impair operations. 6. On-chain execution risk\ Gas spikes, congestion, failed transactions, adverse ordering effects, and reduced execution precision impact DEX-related or wallet-based activity. 7. Liquidation and margin risk\ Derivative hedges or related positions become subject to liquidation if margin is insufficient or if market movements exceed modeled tolerances. 8. Liquidity and unwind risk\ Position exits can require time, especially during stressed market conditions. Fixed pools are only eligible to be unstaked after the lock-up period ends, and claimable amounts are credited only after the mandatory 7-day unstaking buffer, with no early exit option. 9. Settlement and transfer risk\ Deposits sent to incorrect addresses, unsupported networks, or incorrect wallet configurations risk being delayed, rejected, or unrecoverable. 10. User workflow risk\ Errors in wallet connection, asset selection, staking actions, withdrawal destination selection, or misunderstanding of the two-wallet model can lead to loss or delay. ### 4) BASIS protective mechanisms (summary) BASIS mitigates risk through a layered control framework supported by deterministic execution, mathematical constraints, and state-machine-based risk controls. #### Control systems * BSCB (Sentinel Circuit Breaker)\ A protective trigger that halts strategy activity and initiates controlled position reduction when loss thresholds or abnormal conditions are detected. * DMM (Defensive Maintenance Mode)\ A controlled pause state for unwind procedures, root-cause analysis, reconciliation, and stable resumption. * Liquidity fragmentation\ Distribution of capital and execution across multiple venues to reduce single-venue dependency. * Controlled unstaking structure\ Fixed pools are subject to lock-up periods and can only be unstaked after the lock-up ends. Claimable amounts are credited to the Staking Wallet only after the mandatory 7-day unstaking buffer. This supports orderly liquidity management and reduces forced unwind pressure. * Two-wallet segregation\ Funding Wallet holds native assets for deposit and withdrawal. Staking Wallet holds stTokens for staking and reward accrual. This separation improves accounting clarity and operational control. #### Infrastructure controls BASIS execution infrastructure is designed around: * BHLE architecture * sub-50μs latency * 100K+ OPS throughput * proprietary routing infrastructure * deterministic execution paths * state-machine-enforced guardrails * security and service management processes aligned with the active ISO/IEC 27001:2022 and ISO/IEC 20000-1:2018 certifications held by BASIS DIGITAL INFRASTRUCTURE LTD These measures are intended to improve execution precision and structural alpha capture under normal and stressed market conditions. They reduce risk but do not eliminate it. {% hint style="info" %} Research and systems design are informed by Base58 Labs, acting as Research Partner. Technical sophistication and internationally certified management systems improve control quality, but do not guarantee profit or eliminate loss. {% endhint %} ### 5) Product mechanics relevant to risk Understanding core product behavior is part of risk management. | Topic | BASIS rule | | --------------------------- | ------------------------------------------------------------------------- | | Deposit assets | BTC, ETH, SOL, PAXG only | | USDT | Internal accounting/display unit only | | BTC deposit method | Copy your BASIS-assigned unique BTC address | | ETH/SOL/PAXG deposit method | Connect a supported Web3 wallet | | Swap model | Same-token only, 1:1 native asset to stToken | | Rewards | Accumulate in real time as the same stToken in the Staking Wallet | | Unstake | Full position only, auto-MAX | | Claim after unstake | Auto-credited to Staking Wallet as stToken after a mandatory 7-day buffer | | Fixed pools | No early exit, unstake only after lock-up ends | | Withdrawal fee | 0.05% | | Swap fee | 0.01% | | Deposit fee | 0% | #### Wallet model | Wallet | Purpose | | -------------- | -------------------------------------------------- | | Funding Wallet | Holds native tokens for deposit and withdrawal | | Staking Wallet | Holds stTokens for staking and reward accumulation | Misunderstanding this structure can result in confusion regarding balances, claimability, or transferability. ### 6) User responsibilities Before using BASIS, users should: * understand the two-wallet model * understand that native assets and staking tokens are linked through same-token 1:1 swap mechanics * understand that dashboard values shown in USDT are reference estimates only * understand that USDT cannot be deposited or withdrawn * review risk disclosures relevant to the asset being used, including PAXG if applicable * verify deposit methods before transferring assets: * BTC via the BASIS-assigned account address * ETH, SOL, and PAXG via supported Web3 wallet connection * understand that active, internationally accredited ISO certifications support information security and service management governance, and that the public certification records are available on IAF CertSearch, but these certifications do not constitute a guarantee against loss * begin with conservative allocation and test workflows carefully * verify all wallet addresses, networks, and transaction details before confirming {% stepper %} {% step %} Review the asset flow for your chosen token {% endstep %} {% step %} Confirm whether you are depositing via BTC address copy or Web3 wallet connection {% endstep %} {% step %} Verify that you understand staking, unstaking, and withdrawal constraints {% endstep %} {% step %} Proceed only after confirming operational and market risks are acceptable to you {% endstep %} {% endstepper %} ### 7) No guarantee BASIS does not guarantee: * principal preservation * uninterrupted platform availability * continuous liquidity under all market conditions * stable USD-equivalent valuation * specific yield outcomes * protection from third-party failures * error-free blockchain settlement * immediate exits from fixed-term positions Use of the platform involves real financial and technical risk. *** Proceed to the next pages in this section for detailed disclosures. --- [Next Page](/llms-full.txt/1)