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 [e-mail]. 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.