# 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 <support@basis.pro> before proceeding.
{% endhint %}


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.basis.pro/research-library-deep-dives/invariants.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.