# 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


---

# 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/trinity-referral-and-vip/definitions.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.
