After internal discussions, we’re adjusting the mandate to remove unnecessary timing dependencies while keeping the security posture unchanged:
-
Allocation to the ETH and USD vaults can proceed from day one even if the burn-function isn’t deployed yet. First-loss protection remains mandatory; if a first-loss action is needed before the burn-function is live, it will be executed manually, and once the vaults are patched GC will re-deposit to enable onchain execution.
-
Minor cleanups elsewhere.
Here’s the list of amendments:
1) Amendments — Covering situation that burn-function is not yet deployed
1.1 Under Allocation scope
Original:
• First-loss readiness (mandatory): Allocations under this mandate are permitted only to vaults that are burn-ready…
Amendment (replace bullet with):
• First-loss execution readiness (mandatory): Allocation to the Lido Earn ETH and Lido Earn USD vaults may be executed even if the burn-function is not yet deployed. If a ≥1% loss is confirmed before the burn-function is available, GC executes an economically equivalent manual loss-absorption action per mandate instructions with incident disclosure. If/when the vaults are patched with the burn-function, GC will withdraw and re-deposit to activate technical execution via contractual functions.
1.2 Under Burn-readiness gating
Original:
Allocations under this mandate may be made only into burn-ready vaults.
• Exception (time-bound)… GC must not deposit… until burn-readiness is achieved.
• Missed timeline… funds remain unallocated…
Amendment:
Replace the above gating language with:
Allocation may proceed into the ETH and USD vaults even if the burn-function is not yet deployed. If first-loss is triggered before the burn-function is available, GC executes an economically equivalent manual loss-absorption action per mandate instructions with incident disclosure. If/when the vaults are patched with the burn-function, GC will withdraw and re-deposit to activate technical execution via contractual functions.
Remove the “Missed timeline” unallocated-funds clause.
1.3 Execution & controls - Operator
Original:
• …ensure GC has the required permissions to execute it. GC may not allocate DAO Treasury to them until burn-readiness is achieved.
Amendment:
• …ensure GC has the required permissions to execute it. Allocation may proceed prior to deployment; GC will withdraw and re-deposit after the burn-function is deployed to activate technical execution via contractual functions.
1.4 DAO-only share-burn implementation
Remove the “DAO-only share-burn implementation” section in full. The authoritative execution flow is defined under “Risk control – B) First-loss mechanism”.
1.5 Risk control → B) First-loss mechanism
Original:
• GC burns the DAO’s vault shares onchain using the vault’s DAO-share burn function.
• This control is usable only for vaults that include an onchain DAO-share burn function…
• By mandate design, allocations are made only to burn-ready vaults…
Amendment:
Replace the above with:
• If the onchain burn-function is available and activated, GC burns DAO-held shares onchain. If not yet available, GC executes an economically equivalent manual loss-absorption action per mandate instructions with incident disclosure.
• Allocation may occur before the burn-function is deployed; therefore first-loss must remain operationally executable (manual or onchain). Any inability to execute must be treated as an incident, disclosed, and accompanied by root-cause + remediation steps.
2) Other Amendments
2.1 Net rewards
Original:
• Economics: net rewards remitted to Treasury…
• All net rewards… are remitted at least quarterly.
Amendment:
• Economics: rewards compound inside the vault and are remitted to the Treasury only if needed as part of the annual budgeting process…
• All net rewards… accrue to the DAO Treasury and are retained for compounding; they are remitted only if needed as part of the annual budgeting process (quarterly reporting reflects share price appreciation and mandate actions).
2.2 Implementation details → 2) Allocation scope"
Original:
• Deposit-asset scope… allocations to vaults with new deposit-asset types…
Amendment:
• Deposit-asset scope: limited to the ETH and USD vault deposit assets described in this proposal. Any allocation outside these two vaults requires explicit DAO approval.
Remove the reporting bullet: “any allocations to vaults with new deposit-asset types…”