Bỏ qua để đến nội dung

Governance

Nội dung này hiện chưa có sẵn bằng ngôn ngữ của bạn.

Role Can
governor set fees, lending and keeper parameters, content and roles, upgrade the treasury and vault code; hand-over is two-step
halter pause deposits and loans, immediately; nothing else

In production the governor of the treasury, the main prize vault and every group vault is the timelock.

Role Can
owner, a multisig schedule any message to any contract
anyone execute a scheduled message after the delay and within 14 days
guardian cancel a scheduled message, except one addressed to the timelock itself
the timelock itself change its delay (2 to 30 days), owner or guardian
  • Every schedule, execution and cancellation is logged with the full message, so anyone can read an upgrade and leave before it runs. The explorer lists proposals.
  • The delay is at least two days: one validation round plus unfreeze, so holders with queued claims can leave before an upgrade.
  • The timelock’s own settings change only through its own queue, so lowering the delay also waits out the current delay.
  • The guardian cannot cancel changes of the owner, guardian or delay, so the owner can always remove a hostile guardian.
  • Only the treasury and the prize vault can be upgraded, and only by the governor, so in production every upgrade passes the timelock.
  • Storage starts with a version. New code reads the old storage and migrates it in place on the first message; getters migrate in memory, so they read correctly before that.
  • Migration runs inside the new code. Data prepared off-chain would be stale after the delay.
  • Share wallets, claims and loans are immutable. The treasury recognises them by addresses derived from their code, so changing their logic needs new treasury code that recognises both generations.

The tests upgrade a live treasury to a new version through the timelock and check that every Gram is accounted for after the migration.