> For the complete documentation index, see [llms.txt](https://docs.basis.pro/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.basis.pro/whitepaper/deployment-capacity.md). # 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.