Mathematical Verification: Invariants

Operator: BASIS DIGITAL INFRASTRUCTURE LTD, a Seychelles IBC LEI: 254900IX2F2KCWNSSS64 Research Partner: Base58 Labs

Display convention: Some dashboards may show portfolio values in USDT as an internal accounting and display unit. USDT is not a depositable or withdrawable asset on BASIS.

“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.

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

ETH / SOL / PAXG

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

• 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 when unstake 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
BTC	30 minutes to 1 hour
ETH	1 to 6 minutes
SOL	1 to 6 minutes
PAXG	1 to 6 minutes

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.

1

Stake a supported stToken from the Staking Wallet.

2

If a fixed pool is selected, the position remains locked until the chosen period ends.

3

Rewards accumulate in real time as the same stToken.

4

At maturity, unstake the full position. The claimable amount is auto-credited to the Staking Wallet as stToken.

---

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.

A fast system is only trustworthy if its speed is bounded by math, deterministic rejection rules, and explicit state controls.

---

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

If an interface state or transaction flow appears to violate any rule on this page, contact [email protected] before proceeding.