> 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/staking-activation-window.md).
# Staking Activation Window
{% 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 %}
This page defines the BASIS staking activation window, explains the controls inside it, and documents the 2026 reduction from a typical Pending to Active interval of approximately 2 hours to a typical interval of 10 to 60 minutes under normal conditions.
## 1. Definition: the staking activation window
The staking activation window is the short-lived Pending state shown on the user dashboard between the user's stake confirmation and the position becoming Active. It begins after the stake has been confirmed by the user into the staking flow and the dashboard position is Pending. It ends when the position state changes to Active.
This window is distinct from the same-token swap step. The swap documentation states that "The swap step creates a clear system boundary between custody and participation: Funding Wallet holds native tokens for deposit and withdrawal. Staking Wallet holds stTokens for staking and reward accrual. principal and rewards are tracked with deterministic accounting. state transitions are controlled by internal risk checks." ([Swap, Stake & Earn](/getting-started/stake-and-earn.md))
The window is also distinct from on-chain deposit or withdrawal confirmation. The glossary states: "Deposits and withdrawals of supported assets interact with on-chain addresses, while some internal dashboard balances are maintained as platform records until a settlement event occurs." ([Glossary](/reference/glossary.md)) The activation window is therefore a platform state transition layer, not simply a blockchain confirmation layer.
Most importantly, the activation window is distinct from reward accrual. Reward accrual begins when the position enters the Active state and then accrues in real time in the same stToken. This behavior is unchanged. The glossary defines the reward model as follows: "Real-time accumulation is the reward accounting model in which staking rewards accrue continuously and are reflected over time in the Staking Wallet. It is not a manual batch-claim model for standard BASIS staking flows." ([Glossary](/reference/glossary.md))
The economic parameters of a position, including the lock schedule and booster selection, take effect from the activation event. This is consistent with the documented observability sequence, where staking telemetry covers "same-token 1:1 swap event, stToken credit, booster selection, lock start, lock end, reward accrual, unstake settlement." ([Observability & Audit Logs](/technical-architecture/observability.md)) In add-stake flows, the booster reset policy remains unchanged: "When additional stake is added to an existing boosted position, the lock-up timer resets based on the new add-stake timestamp for the full aggregated position." ([Booster Reset Policy](/economics-and-rewards/booster-reset-policy.md))
{% hint style="info" %}
A Pending position is waiting for activation controls to complete. It is not an Active position, and this document does not attribute reward accrual to Pending.
{% endhint %}
## 2. Mechanics inside the window
### 2.1 Settlement event finalization
Inside the activation window, BASIS finalizes the settlement event that connects the user's stake confirmation, the same-token 1:1 swap event, the stToken credit, and the resulting position state. The glossary distinction is important: on-chain deposits and withdrawals interact with addresses, while internal dashboard balances can remain platform records until a settlement event occurs.
This step cannot be skipped because activation requires a final ledger state, not merely an instruction record. The observability documentation requires user actions to be "reconstructable from source event to final ledger state." ([Observability & Audit Logs](/technical-architecture/observability.md)) If the settlement event is not finalized, the platform has not completed the full path from source event to final ledger state.
### 2.2 Invariant reconciliation
BASIS then reconciles the relevant invariant. The documented invariant is exact: "Balances reconcile exactly: Minted stToken supply matches underlying native token quantity." ([Mathematical Verification: Invariants](/research-library-deep-dives/invariants.md)) This is the BIVB invariant referenced in the unchanged safety controls.
This step cannot be skipped because reconciliation is a hard risk control. The risk engine documentation states: "The system confirms that all expected state transitions completed correctly before new exposure is permitted." It also states: "Reconciliation is not a reporting convenience. It is a hard risk control. If reconciliation does not complete cleanly, the engine can block new orders until the discrepancy is resolved." ([Risk Engine](/technical-architecture/risk-engine.md))
### 2.3 State machine gating: Normal, BSCB, DMM
Activation is an exposure-permission event. The platform must confirm that the system state allows the position to become Active. Under Normal system state, activation can proceed when the required checks complete. Under abnormal conditions, BSCB circuit breaker behavior or DMM supervised escalation can pause or supervise new exposure.
This step cannot be skipped because state transitions are controlled by internal risk checks, and the risk engine confirms expected state transitions before new exposure is permitted. Expected value gating, BSCB circuit breaker behavior, and DMM supervised escalation are part of the unchanged control surface.
### 2.4 Capital assignment under the reserve policy
Activation also requires capital assignment under the documented reserve-based deployment model. The staking pools documentation states: "BASIS does not deploy 100% of staked capital at all times. A reserve is maintained for withdrawal handling, execution continuity, and risk-buffer requirements." ([Staking Pools: Technical Overview](/economics-and-rewards/staking-pools.md))
This step cannot be skipped because activation must be consistent with the reserve policy. A position cannot be treated as fully Active in the system if its capital assignment would conflict with withdrawal handling, execution continuity, or risk-buffer requirements.
### 2.5 Audit trail finalization
The activation window also finalizes the audit trail for the state transition. The observability documentation states that staking activity telemetry covers "same-token 1:1 swap event, stToken credit, booster selection, lock start, lock end, reward accrual, unstake settlement." It also requires actions to be "reconstructable from source event to final ledger state" and states that "Any deviation from expected processing windows should trigger internal alerts and user-visible status updates." ([Observability & Audit Logs](/technical-architecture/observability.md))
This step cannot be skipped because the platform must retain a complete event trail from user action to ledger state. Without that trail, the position state would not satisfy the documented observability standard.
## 3. Why a bounded activation window is a safety feature, not a defect
A bounded activation window is a designed operational constraint. It is structured to make settlement, reconciliation, gating, reserve assignment, and audit finalization explicit before the platform permits new exposure.
This follows the same design philosophy as the documented unstaking buffer. The technical risk documentation states that "the mandatory 7-day unstaking buffer is a designed operational constraint, not a technical delay or system failure." ([Technical & System Risk](/risk-safety-and-asset-protection/technical-risk.md)) The activation window is shorter and occurs before Active status, but the logic is comparable. A visible state boundary is used to separate user instruction from finalized platform participation.
A standard industry analogy is exchange settlement cycles. In professional market infrastructure, execution, settlement, risk permissioning, and final balance availability can be separate events. The analogy is not that BASIS copies exchange settlement mechanics. The point is that separating an instruction from final exposure is standard engineering practice in financial systems that require deterministic accounting and controlled state transitions.
The Pending state gives users visibility into this control interval. It is more mechanically honest than hiding the process behind an immediate dashboard state change before the platform has completed reconciliation and gating.
## 4. Why the window was approximately 2 hours, and why it is now 10 to 60 minutes
Until July 2026, the Pending to Active activation interval typically completed within approximately 2 hours under normal conditions. That earlier timing reflected a conservative settlement cadence around the same settlement, reconciliation, gating, reserve, and audit controls.
Following a scheduled platform infrastructure update completed in early August 2026, the same activation interval now typically completes within 10 to 60 minutes under normal conditions. The update changed settlement pipeline throughput and sequencing only. The improved design uses parallelized reconciliation, telemetry driven processing, and higher orchestration headroom.
The control surface is identical. No control was removed, weakened, or relaxed. The unchanged controls include the same token 1:1 swap, BIVB invariant reconciliation, expected value gating, BSCB circuit breaker behavior, DMM supervised escalation, the mandatory 7 day unstaking buffer, reserve-based capital deployment, full position auto-MAX unstake, and the booster reset on add-stake policy.
This distinction matters because infrastructure speed and risk-control bypass are different things. The BHLE infrastructure documentation references "sub-50 microseconds latency architecture", "100K+ OPS routing capacity", "proprietary execution infrastructure", and "mathematically constrained risk controls." ([Swap, Stake & Earn](/getting-started/stake-and-earn.md), [System Overview](/whitepaper/system-overview.md)) Those infrastructure statements provide context for high throughput execution capacity, while the activation window remains governed by settlement finalization, reconciliation, state machine gating, reserve policy, and audit trace completion.
The scheduled update also fits the documented production change discipline. BASIS maintains active ISO/IEC 20000-1:2018 certification for IT Service Management, which disciplines how production changes are tested, released, and reviewed. ([Audits & Responsible Disclosure](/technical-architecture/audits-and-disclosure.md)) The activation window reduction should therefore be understood as a production infrastructure change released under that change-management discipline, not as a change to economic treatment or risk policy.
## 5. Why the parameter is a range and not a constant
The current activation interval is documented as 10 to 60 minutes under normal conditions because activation depends on multiple variable inputs.
First, asset-specific chain finality matters. BTC linked flows inherit Bitcoin network confirmation timing, documented at 10 to 60 minutes. ETH, SOL, and PAXG flows confirm faster on chain, documented at 1 to 10 minutes. The fees and limits documentation states that BTC deposit credit occurs after required network confirmations, that the same token swap is typically near-instant after confirmation, that BTC withdrawal timing is 10 to 60 minutes, and that ETH, SOL, and PAXG withdrawal timing is 1 to 10 minutes. ([Fees & Limits](/reference/fees-and-limits.md)) The minimum staking documentation also states that Bitcoin presents "slower settlement characteristics and more variable on-chain fee conditions" than the other supported networks. ([Minimum Staking & Reward Claim Policy](/getting-started/minimum-staking.md))
Second, reconciliation completion can vary with system state and load. Telemetry driven processing reduces unnecessary waiting, but reconciliation still has to complete cleanly. The risk engine can block new orders if reconciliation does not complete cleanly.
Third, state machine gating can pause new exposure during abnormal states. Under Normal conditions, the position can proceed through the activation path after required controls complete. If BSCB circuit breaker behavior or DMM supervised escalation applies, the platform can pause or supervise allocation activity.
The lower bound equals the floor of the control sequence. It represents the minimum practical time for settlement finalization, invariant reconciliation, state machine gating, reserve assignment, and audit trail finalization under normal conditions. The upper bound equals the conservative envelope under normal conditions. It is not a fixed countdown and it does not override network confirmation, reconciliation, BSCB, DMM, reserve, or telemetry controls.
{% hint style="info" %}
The 10 to 60 minute figure is the current typical activation envelope under normal conditions. It is not a fixed countdown and it does not override documented safety controls.
{% endhint %}
## 6. Technical questions and answers
Why does an activation window exist if the same-token swap is near-instant after confirmation?
Swap finality and position activation are different settlement layers. The swap creates the system boundary between Funding Wallet custody and Staking Wallet participation. As the glossary notes, some internal dashboard balances are maintained as platform records until a settlement event occurs. Activation is the final Pending to Active state transition, completed only after settlement finalization, invariant reconciliation, state machine gating, reserve assignment, and audit trail finalization.
Does faster activation mean weaker risk controls?
No. The scheduled update changed settlement pipeline throughput and sequencing only. It added parallelized reconciliation, telemetry driven processing, and higher orchestration headroom. The same reconciliation, invariant, expected value, BSCB, DMM, reserve, and audit controls remain in place. Reconciliation can still block new exposure if it does not complete cleanly.
Why is the activation window a range instead of a fixed number?
The parameter is a range because asset-specific chain finality, reconciliation load, and state machine gating vary. BTC linked flows inherit slower Bitcoin timing. ETH, SOL, and PAXG flows confirm faster on chain, but still pass through the same platform activation controls. The lower bound is the control-sequence floor. The upper bound is the conservative envelope under normal conditions.
Does the activation window conflict with the real-time reward accrual model?
No. Real-time accumulation describes how rewards accrue after the position is Active. The Pending state is before Active. The documented behavior is unchanged: reward accrual begins when the position enters Active and then accrues in real time in the same stToken.
## 7. Illustrative timing table
All timing values below are typical under normal conditions. The asset confirmation column is context for settlement behavior and does not replace the dashboard Pending to Active state.
| Flow context | Activation window until July 2026 | Activation window after early August 2026 update | Documented asset confirmation context |
| ------------------------ | --------------------------------- | ------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| BTC linked staking flow | Typically approximately 2 hours | Typically 10 to 60 minutes | BTC deposit credit after required network confirmations. BTC withdrawal timing documented at 10 to 60 minutes. Bitcoin is documented as having slower settlement characteristics and more variable on-chain fee conditions. |
| ETH linked staking flow | Typically approximately 2 hours | Typically 10 to 60 minutes | ETH flows confirm faster on chain, documented at 1 to 10 minutes. |
| SOL linked staking flow | Typically approximately 2 hours | Typically 10 to 60 minutes | SOL flows confirm faster on chain, documented at 1 to 10 minutes. |
| PAXG linked staking flow | Typically approximately 2 hours | Typically 10 to 60 minutes | PAXG flows confirm faster on chain, documented at 1 to 10 minutes. |
## 8. Risk disclosure
Rewards are variable. Activation windows in this document are typical under normal conditions and are not processing time commitments under abnormal network conditions, abnormal system state, reconciliation discrepancies, BSCB circuit breaker behavior, DMM supervised escalation, reserve constraints, or telemetry deviations. BASIS controls can pause allocation activity or block new orders when documented risk checks do not complete cleanly. A Pending position should be read as not yet Active. Reward accrual begins only when the position enters Active and then accrues in real time in the same stToken.
***
Next: read [Unstaking & Liquidity Buffer](/economics-and-rewards/unstaking-and-7-day-rule.md) for the exit-side design that follows the same operational constraint philosophy.