Skip to main content

​
The core rules are fixed

Strip fixes its core economic rules in code. The 50/50 yield split, the emission decay curve, the boost bounds and claim-time enforcement, and the Principal Token redemption mechanics cannot be changed without redeploying the protocol. These are not governance parameters; they are part of the system’s operating structure. Vault deposits and withdrawals are user-controlled contract interactions. Admins do not custody user principal, approve individual deposits, gate withdrawals, or decide who can exit. Once a user holds Principal Tokens, the principal claim is theirs to redeem through the vault mechanics. The protocol does have privileged roles. They exist for operation, safety, and routine execution, not to rewrite the economic rules or control user principal.

​
Owner (multisig)

The owner is a multisig. It can manage operator and signer permissions and configure supported operational settings. These powers exist so the protocol can rotate permissions, maintain infrastructure, and respond to issues. They do not give the owner custody over user principal or control over Principal Token redemption.

​
Owner + timelock

The most sensitive parameter changes pass through a 24-hour timelock:
  • Adding or removing emission pools
  • Adjusting Principal Token rate-protection parameters
  • Resetting the high-water mark
  • Approving allocation signers
The multisig proposes the change; anyone can execute it after the delay. The point of the delay is visibility: sensitive changes sit onchain for a full day before they can take effect. The pool registry is timelocked for a precise reason: it is the only place emissions could be redirected outside the system. A new pool is a new destination for minted STRIP, so no destination can be added without a full day of onchain notice. The split between registered pools is deliberately not timelocked. Steering emissions among registered venues is an operational action, executed immediately and logged onchain the moment it happens. The worst a wrong or malicious split change can do is misallocate rewards among PT staking and sWLP staking venues; it cannot move emissions anywhere else, it is publicly visible in the same block, and it is reversible just as fast. The published policy governs where the split should sit; the event log shows where it does.

​
Keepers

Two automated keepers handle routine execution:
  • The boost keeper computes and publishes per-epoch boost data (see below).
  • The operator keeper handles regular system actions: triggering buybacks, burning STRIP, redeeming yield into the BuybackBurner, forwarding trading fees to stSTRIP, running emissions distribution, and executing emission-split updates under the published policy.
Keepers execute routine flows; they cannot add or remove pools, which is timelock-gated as described above. Both keepers can be revoked or replaced by the multisig.

​
Boost computation

Boost deserves its own honesty. The multiplier you receive is computed offchain by the boost keeper, following the published rules described on Lockless Boost, and attested onchain as an immutable per-epoch Merkle root. The contracts do not recompute your alignment; they verify that your claimed boost is included in the epoch’s root and cap the multiplier at the maximum. What this means in practice:
  • What is fixed in code: the boost bounds, the per-epoch immutability of published roots, and the fact that claims are capped so no pool can ever mint beyond its scheduled allocation.
  • What is operational: the computation of each user’s boost value, per epoch, against the published rules.
  • The failure mode is bounded: if the keeper misses an epoch or boost data is unavailable, claims still work at the 1x baseline. Missing data can reduce a boost benefit; it can never block base rewards or take principal.
Every published root is visible on the transparency dashboard, so the keeper’s output is public the moment it exists.

​
Signer redundancy

Approved offchain signers provide a fallback path for emission-split updates if the operator keeper is unavailable. Adding or removing approved signers requires a timelocked owner action.

​
Verification

Every action across every privileged role emits an onchain event, and the transparency dashboard surfaces these events in real time. Users do not have to trust that the roles behave; they can watch them.