> 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/economics-and-rewards/lock-up-economics.md).

# Lock-up Economics (Capital Efficiency)

{% 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 %}

Many products describe lock-ups as "bonus yield." Serious allocators should evaluate them through a measurable lens: capital efficiency.

BASIS explains lock-ups as a structural mechanism that improves deployable capital ratio under deterministic constraints.

## 1) Why lock-up can support higher efficiency

In a flexible pool, capital cannot be deployed at full utilization because:

* withdrawals may occur at any time
* the system must maintain a liquidity buffer
* part of the pool remains idle as operational reserve

If a flexible pool must keep 20-30% idle, even a strong strategy stack cannot continuously allocate the full capital base.

In a fixed lock-up pool, withdrawal timing is known in advance. This allows BASIS to:

* deploy capital more continuously
* allocate into strategies requiring a stable time horizon
* improve realized yield through lower idle balance and better execution precision

Lock-up yield should be understood as a redistribution of efficiency surplus, not as arbitrary bonus issuance.

## 2) A simplified model

{% hint style="info" %}
Model variables
{% endhint %}

| Variable | Meaning                                          | Constraint        |
| -------- | ------------------------------------------------ | ----------------- |
| $C$      | Total capital                                    | -                 |
| $b$      | Required buffer fraction                         | $0 \leq b \leq 1$ |
| $r$      | Realized strategy yield rate on deployed capital | -                 |

{% hint style="info" %}
Expected realized yield:

$$
\text{Yield} \approx (1-b) \cdot C \cdot r
$$

A lock-up reduces $b$, which increases deployed capital share and realized yield potential.
{% endhint %}

## 3) Why this is not automatically "more risky"

A lock-up does not inherently increase platform risk. In some cases, it can reduce specific failure modes:

* forced liquidation pressure during clustered withdrawals
* execution degradation caused by emergency unwinds
* opportunity loss caused by excessive liquidity buffers

What lock-up does add is user liquidity constraint: principal remains unavailable until the lock period ends.

{% hint style="warning" %}
For fixed pools on BASIS, unstaking is only available after the selected lock-up period has ended. Early exit is not supported.

Unstake is processed as full-position only. Partial unstake is not available.
{% endhint %}

## 4) What BASIS discloses for credibility

A credible lock-up system should clearly publish:

* available lock durations and booster rules
* whether adding stake resets the lock period
* how unstake and capital unwind are processed
* how the system behaves under internal risk-control states
* how rewards accrue and where they are credited

On BASIS, rewards accumulate in real time as the same stToken in the Staking Wallet.

## 5) Current fixed lock-up booster schedule

| Lock-up period | Booster    |
| -------------- | ---------- |
| 14D            | +10%       |
| 30D            | +20%       |
| 90D            | +50%       |
| 180D           | +100% (2x) |

{% hint style="success" %}
Wallet model

* Funding Wallet: native tokens only (BTC, ETH, SOL, PAXG) for deposit and withdrawal
* Staking Wallet: stTokens only (stBTC, stETH, stSOL, stPAXG) for staking and reward accrual

Swap is same-token only at 1:1:

* BTC → stBTC
* ETH → stETH
* SOL → stSOL
* PAXG → stPAXG

Fees:

* Deposit: 0%
* Withdrawal: 0.05%
* Swap: 0.01%
  {% endhint %}

## 6) Operational context

BASIS is designed around deterministic execution, mathematical constraints, and state-machine risk controls. Research and systems design are supported by Base58 Labs, with emphasis on structural alpha capture, execution precision, and controlled liquidity behavior.

BHLE infrastructure targets sub-50μs latency, 100K+ OPS, and proprietary routing for stable execution quality under load.

***

Next: read Booster System.