docs: add Yield Boost protocol docs and assertions social card#1350
docs: add Yield Boost protocol docs and assertions social card#1350kyzooghost wants to merge 25 commits intomainfrom
Conversation
Document ETH fund flow, architecture, roles, and fund flow scenarios for the Linea Yield Boost staking system. Co-authored-by: Cursor <[email protected]>
Co-authored-by: Cursor <[email protected]>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Co-authored-by: Cursor <[email protected]>
docs/protocol/yield-boost.mdx
Outdated
| Yield Boost is not yet live. This documentation describes the intended design. | ||
| ::: | ||
|
|
||
| # Yield Boost - ETH fund flow |
There was a problem hiding this comment.
Let's move this H1 above the caution callout, so:
H1
Caution
H2 "Overview"
docs/protocol/yield-boost.mdx
Outdated
|
|
||
| ## Overview | ||
|
|
||
| The Linea Yield Boost system stakes LineaRollup funds on Ethereum L1 via Lido V3 stVaults to generate beacon chain rewards, which are reported to L2 for distribution. This document maps **where ETH flows** and **which roles control each movement**. |
There was a problem hiding this comment.
Let's get some more non-technical description here before getting into the technical intricacies.
There was a problem hiding this comment.
Maybe this first sentence in Overview could instead be moved down to "High-level architecture", and replaced with simpler description for overview.
|
General question -- is there an action item here for readers? Any thing they need to do on their end, or is this exclusively informational |
Co-authored-by: allywhiting <[email protected]>
Exclusively informational |
Co-authored-by: Cursor <[email protected]>
- Simplify Overview with user-focused description - Add Bridge deposits intro and Key entities bullet list - Clarify LST withdrawal and ossification descriptions Co-authored-by: Cursor <[email protected]>
Co-authored-by: Cursor <[email protected]>
Co-authored-by: Cursor <[email protected]>
- Add numbered summary of all 6 fund flow scenarios - Move reserve replenishment before yield reporting to follow flow order - Replace 'freezes' with 'locks' in ossification description Co-authored-by: Cursor <[email protected]>
docs/protocol/yield-boost.mdx
Outdated
| LR -->|excess ETH| YM | ||
| YM -->|fund| DB | ||
| DB -->|fund| SV | ||
| NO -.->|discretion over beacon chain deposits| SV |
There was a problem hiding this comment.
"discretion over beacon chain deposits" - the wording is subject to interpretation and can make it sounds like it is custodial.
I would rather suggest saying "decide when to trigger the deposit".
Also I suggest to add a small note below the diagram indicate that while the NO "decides" when to stake it is part of an automated process with logic agreed beforehand with the node operator. We should also mention the recommended approach is for the NO to greedily stake funds newly deposited funds in the vault (except withdrawals).
|
|
||
| class NO admin | ||
| class User permissionless | ||
| ``` |
There was a problem hiding this comment.
Can we include a short description of the roles of each contracts in the diagram?
There was a problem hiding this comment.
have added a Key Entities section near the top
| SV[StakingVault] | ||
| NO([Node Operator]) | ||
| BC{{Beacon Chain}} | ||
|
|
There was a problem hiding this comment.
The diagram implicitly indicates that the staking/unstaking is triggered by users' ETH deposit / withdrawal on the bridge. Can we make it clearer what are the atomic actions and who triggers them?
There was a problem hiding this comment.
Following sequence diagram makes it clearer but it is important in my opinion that we don't give a wrong impression in this first diagram for users who might not read the document completely.
docs/protocol/yield-boost.mdx
Outdated
| DB -->|stETH borrow liability| Lido[Lido] | ||
| DB -->|protocol fees| Lido | ||
| DB -->|node operator fees| FeeRecipient([Node Op Fee Recipient]) | ||
| YM -.->|reportNativeYield| LR[LineaRollup] |
There was a problem hiding this comment.
Can we add one more step here explaining what happens when this is triggered and how the accrued yield is computed?
Without context, it could sound like the Automation service defines how much yield should be distributed, but this is not the case.
|
|
||
| class L2MS,L2YD l2 | ||
| class FeeRecipient admin | ||
| ``` |
There was a problem hiding this comment.
Can we add a description in english of each steps as the diagram might be hard to follow for someone without context on the feature
docs/protocol/yield-boost.mdx
Outdated
|
|
||
| | Role | Held By | ETH Movement Authorized | | ||
| |------|---------|------------------------| | ||
| | `YIELD_PROVIDER_STAKING_ROLE` | Automation Service | LineaRollup → YieldManager → StakingVault | |
There was a problem hiding this comment.
Can we explain in plain english and functional terms what are the ETH Movement Authorized?
| Note over DB: Skip settlement<br/>carry forward obligations | ||
| end | ||
|
|
||
| YM-->>LR: reportNativeYield()<br/>(net surplus after obligations) |
There was a problem hiding this comment.
Can we make it explicit where we fetch the information about how much yield has been generated?
docs/protocol/yield-boost.mdx
Outdated
| L2MS->>L2YD: distribute yield | ||
| ``` | ||
|
|
||
| No L1 ETH moves for the yield report itself - obligation payments (solid arrows) are the only L1 ETH transfers. The `MessageSent` event is synthetic: it relays the net surplus to L2 for distribution without bridging ETH. |
There was a problem hiding this comment.
It would be worth it to explicitly call out why we don't need to bridge funds, while the system remains fully collateralized.
Co-authored-by: allywhiting <[email protected]>
Co-authored-by: Cursor <[email protected]>
Soften "discretion over beacon chain deposits" to "decides when to trigger deposits" and add note explaining the automated nature of the process and the recommended greedy-staking approach.
Rewrite all entries for a non-technical audience: remove jargon (withdrawal credentials, LST minting, obligation settlement), explain each role in plain language, and add a Beacon Chain entry.
Co-authored-by: Cursor <[email protected]>
Co-authored-by: Cursor <[email protected]>
Replace contract-path notation and function names with plain-language descriptions of what each role can do. Correct ossification roles to note Lido-required fee settlement instead of direct ETH withdrawal.
Make explicit that totalValue comes from the Lido Oracle Committee daily updates and that yield is the diff against a stored checkpoint.
Add note clarifying that L1 staking rewards grow collateral beyond the existing L2 supply, so L2 can safely mint the difference without moving ETH across the bridge.
- Promote Key entities to a heading - Fix YieldManager casing, clarify totalValue and Lido Oracle role - Add obligation settlement skip logic to yield reporting steps - Minor wording tweaks throughout Co-authored-by: Cursor <[email protected]>
Co-authored-by: Cursor <[email protected]>
Co-authored-by: Cursor <[email protected]>
Co-authored-by: Cursor <[email protected]>
…able - Replace verbose collateralization paragraph with concise blockquotes - Use "Automation Service" consistently in quick reference table - Clarify LST withdrawal trigger Co-authored-by: Cursor <[email protected]>
Co-authored-by: Cursor <[email protected]>
…ectly Co-authored-by: Cursor <[email protected]>
Summary
Note
Low Risk
Documentation-only change with no impact to runtime code paths or security-critical logic.
Overview
Adds a new
docs/protocol/yield-boost.mdxpage documenting the intended Yield Boost design, including L1/L2 ETH flow diagrams, yield reporting mechanics, and role/permission boundaries for staking, unstaking, reporting, and ossification.The doc also enumerates end-to-end fund-movement scenarios (routine staking/replenishment, permissionless fallback actions, LST withdrawal as last resort, and vault ossification) plus a quick reference table for reviewers/operators.
Written by Cursor Bugbot for commit b39be2b. This will update automatically on new commits. Configure here.