# Section D — Parameter Registry **Version:** v1.3.2 This section enumerates all parameters, limits, and deterministic mechanisms defined for the LSteak protocol and its LSaaS extension framework. If a value, parameter, mechanism, or adjustable control is not explicitly defined in this section, it does not exist in v1. All contents of this section are subordinate to: * [Section B — Immutable Protocol Invariants](/lsteak-protocol-docs/technical-appendix/section-b-immutable-protocol-invariants.md) * [Section C — Deterministic System Flows](/lsteak-protocol-docs/technical-appendix/section-c-deterministic-system-flows.md) Previous: [Section C — Deterministic System Flows](/lsteak-protocol-docs/technical-appendix/section-c-deterministic-system-flows.md) ### Section D — scope & activation This registry covers two system layers: * LSteak Core Protocol (v1 — initial launch) * LSaaS Extension Framework (v1 — post-core deployment) Unless explicitly stated otherwise: * All LSteak Core parameters are active at initial launch. * All LSaaS-related parameters are defined but dormant until LSaaS activation. * Dormant parameters: * cannot be exercised * cannot be partially enabled * cannot be modified outside their defined bounds * LSaaS parameters activate only upon: * deployment of LSaaS contracts, and * explicit governance activation Dormancy does not imply mutability. ### Parameter classes #### Class 0 — immutable constants Cannot change under any circumstances. #### Class 1 — governance-bounded parameters May change only within strict bounds, with timelock and invariant compliance. #### Class 2 — operational parameters Execution-safety parameters adjustable via elevated multisig within bounded ranges. #### Class 3 — contextual parameters (rule-bound variables) Values may vary, but the rules governing how they vary are immutable. ### D.1 Class 0 — immutable constants (locked) #### Treasury & supply (LSteak Core + LSaaS) * Treasury skim (all treasury cuts): `5%` fixed * No emissions: enforced * No rebasing: enforced * Mint ordering: mint at current BPT → update backing → recompute BPT * Backing non-redeemable under normal operation: enforced * Burn irreversibility: enforced #### Internal transaction rules (LSteak Core + LSaaS) * Internal protocol actions never apply a treasury skim. * Internal allocation normalisation basis: `95%`. * Bond and hedge allocations are renormalised to remove the treasury component. #### Value-transfer safety (global guardrail) (LSteak Core + LSaaS) * LSTEAK price floor during any value-transfer loop that mints LSTEAK: `LSTEAK_price >= 0.98 × BPT` (fixed, global) * LSaaS VTL RR drawdown limit per execution: `≤ 0.5%` drawdown versus `RR_pre` (fixed, LSaaS-only) Applies only to loop-based value transfers, including: * LSaaS entry conversion loops * any internal loop capable of impacting BPT **Guardrail condition** All loops are pre-simulated. If either condition would be violated: * `LSTEAK_price < 0.98 × BPT`, or * `RR_post < 0.995 × RR_pre` (LSaaS VTL only), the loop must revert atomically. #### Deterministic routing when VTL cannot execute (LSaaS) If a partner deposit cannot be fully processed through the VTL due to guardrails, the unprocessed portion is moved into the VTL Queue. The deposit is not rejected due to guardrails. Minting uses the pre-deposit RR and counts both: * tokens deposited into xl backing, and * tokens placed into the Queue. #### Queue drip cadence (LSaaS) The system attempts a VTL from the Queue every `10 minutes` (fixed). Queue drip: * does not mint `xl-*` * moves tokens from `Q → B` * keeps `Q + B` constant * leaves RR unchanged #### LSaaS yield routing weights (fixed) LSaaS yield routing depends on whether the Queue has tokens. In both cases, `5%` of gross yield is routed to the treasury first. **Queue > 0** From the remaining yield: * `25%` direct Queue reduction (non-trade transfer from Queue → xl backing, after PYE capital increase) * `10%` LSTEAK/ETH POL increase * `10%` compound into PYE * `5%` buy and burn LSTEAK * `50%` buy partner token and deposit into xl backing **Queue = 0** From the remaining yield: * `5%` LSTEAK/ETH POL increase * `15%` compound into PYE * `5%` buy and burn LSTEAK * `75%` buy partner token and deposit into xl backing #### Emergency & liquidation (LSteak Core + LSaaS) * Emergency pause duration: maximum 72 hours * Extensions: * only in increments of ≤ 72 hours * require top-level multisignature approval * Emergency pause cannot be indefinite * Emergency pause scope: all transactions * Emergency pause purpose: catastrophic failure assessment and liquidation only * Liquidation: fully mechanical and pro-rata #### Structural constraints * LSaaS isolation boundary: enforced * Governance override of invariants: prohibited ### D.2 Class 1 — governance-bounded parameters #### Market banding (relative to BPT) (LSteak Core + LSaaS) * Deadband: default `±1%` * Allowed range: `±0.5%` to `±2.0%` * Premium and discount zones derive directly from deadband. #### External entry allocation (LSteak Core only) Treasury is taken first, then the remainder is allocated. * Treasury: `5%` fixed * `Net_Input = 95% × X` * Bond allocation (`B_net`): `B_net ∈ [80%, 90%]` of `Net_Input` * Hedge allocation (`H_net`): `H_net ∈ [5%, 15%]` of `Net_Input` * Residual (`R_net`): `R_net = 100% − B_net − H_net` (of `Net_Input`) Constraint: * `B_net + H_net + R_net = 100%` (of `Net_Input`) #### Internal entry / internal transactions (LSteak Core + LSaaS) * Treasury skim is not applied. * Bond and hedge allocations are renormalised over `95%`. ### D.3 Class 2 — operational parameters #### D.3.1 LSteak Core — execution safety only (active at launch) LSteak Core does not implement volatility or imbalance resolution mechanisms. Operational parameters exist solely to constrain execution: * routing limits: bounded (non-economic) * slippage limits: bounded (non-economic) * maximum routing iterations: bounded * gas usage caps: bounded These parameters: * do not trigger corrective actions * do not imply imbalance detection * do not introduce value transfers * do not affect BPT, backing, or supply #### D.3.2 LSaaS — execution safety only (LSaaS-only — inactive at core launch) LSaaS does not implement a separate volatility / imbalance resolution module. The only LSaaS-specific internal action is Queue drip (see Class 0 constants). All other operational safety limits are execution-only (routing bounds, slippage caps, gas caps). ### D.4 Class 3 — contextual parameters No Class-3 contextual parameters are defined for LSaaS v1. ### D.5 Hedge allocation guidance (non-binding) (LSteak Core only) LSaaS Partner Yield Engines (PYE) are allocated at the same bond/hedge ratio as the LSteak core. * Absolute minimum hedge allocation: `5%` * Maximum hedge allocation: `15%` * No discrete hedge modes exist Hedge allocation may be adjusted in response to prevailing market conditions, provided all Class-1 bounds and BPT invariants are respected. Non-binding guidance examples: * Bear-leaning conditions: higher gold weighting * Sideways conditions: balanced allocation * Bull-leaning conditions: crypto-heavy allocation ### D.6 Parameter change rules * Class 0: immutable * Class 1: governance + timelock + bounds * Class 2: elevated multisig, bounded * Class 3: values may vary, rules may not All changes must be logged and invariant-checked. ### D.7 Registry supremacy clause If a value, parameter, or mechanism is not enumerated in this registry, it does not exist in v1. *** Previous: [Section C — Deterministic System Flows](/lsteak-protocol-docs/technical-appendix/section-c-deterministic-system-flows.md) --- # 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://lsteak-protocol.gitbook.io/lsteak-protocol-docs/technical-appendix/section-d-parameter-registry.md?ask= ``` 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.