How Yield Generation Works
Timelocks
Which changes to a stock's strategy must wait the curator's delay of at least three days, which take effect at once, who can cancel a scheduled change, and why holders have time to leave.
A timelock is a waiting period between announcing a change and making it. Every change to a strategy's settings that could add risk for holders, such as adding a money market, registering a stablecoin or changing the fee, waits behind one. Day-to-day moves within those settings do not wait. A scheduled change is public while it waits. A holder who disagrees can leave with a forced withdrawal before it lands, since leaving has no wait.
Key points
- Every curator change waits the curator's delay. The delay is set when the contract is deployed, and the deployment refuses anything under three days.
- The admin's changes to the admin role, to delays and to who governs the contract wait the same delay, and a new curator can act only once it has passed.
- Operator actions, lowering the deposit cap, and revoking the curator or operator take effect at once.
- A forced withdrawal has no wait, so a holder who sees a change scheduled can leave first, within the limits of forced withdrawals.
How a delay works
The vault that holds each stock (see Using a vault) is governed by an access manager, a standard OpenZeppelin contract that decides who may call each restricted function. A role with an execution delay cannot act straight away. Instead:
- The role holder schedules the change. The schedule is public onchain, with the exact call it will make.
- The delay passes.
- The role holder carries out the change. If they do not do so within a week of it becoming ready, it expires.
The curator's delay is set when the contract is deployed, and is shown with each role under Maintenance on the stock's page. The deployment refuses a delay under three days.
Which changes wait
| Change | Who | Wait |
|---|---|---|
| Add or remove a stablecoin | Curator | The curator's delay |
| Add a lending venue or a borrow venue | Curator | The curator's delay |
| Abandon a borrow venue that cannot be read | Curator | The curator's delay |
| Set or remove a price feed | Curator | The curator's delay |
| Change the swap or harvest tolerance | Curator | The curator's delay |
| Change the performance fee, up or down, or its recipient | Curator | The curator's delay |
| Set the Merkl distributor for rewards | Curator | The curator's delay |
| Raise the deposit cap | Curator | The curator's delay |
| Appoint a new curator | Admin | The new curator can act only once the curator's delay has passed |
| Shorten a role's delay | Admin | Takes effect no sooner than five days later, and later still when the cut is larger |
| Change the admin role, which role calls a function, or the access manager that governs the contract or its oracle | Admin | The curator's delay |
The admin also holds the curator role, at the same delay. It can do anything the curator can, but no sooner.
Which changes are immediate
| Change | Who |
|---|---|
| Supply, withdraw or move collateral, borrow, repay, lend, swap, harvest and rebuy | Operator |
| Set the release order or the lending order | Operator |
| Remove an empty lending or borrow venue | Operator |
| Claim rewards | Operator |
| Lower the deposit cap | Operator |
| Revoke the curator or the operator | Admin, through its guardian roles |
| Cancel a scheduled change | Whoever scheduled it, the admin, or the role's guardian |
| Appoint a new operator | Admin, through its guardian role |
Operator actions do not wait, because they work only within what the curator has registered and the contract's checks. Lowering the deposit cap only turns new deposits away. A raise names the cap it replaces, so a raise scheduled before a lowering fails when it runs.
Who can cancel a scheduled change?
A scheduled change can be cancelled by the account that scheduled it, by the admin, or by the guardian of the role it belongs to. The admin holds both guardian roles, so it can cancel any curator or operator change while it waits.
The first days after deployment
The access manager applies a longer delay only after its own minimum setback of five days, a constant in the OpenZeppelin contract. The deployment sets the curator role's appointment delay when the contract is created. For the first five days, that delay is not yet in force, so the admin could appoint a curator who acts without waiting. Until then, holders rely on the admin not to make such an appointment. After that, a new curator can act only once the full delay has passed since the appointment, which is public from the start.
Exit before a change lands
A forced withdrawal has no wait of its own: it pays in the transaction that asks for it. A holder who sees a curator change scheduled can leave before it runs, within the limits on forced withdrawals. No change waits for holders to leave first. The delay gives holders time to leave, not a veto.
Watching for changes
The access manager emits an event for every scheduled change, with the target contract and the exact call. Anyone can follow these events to see what is coming.