Who decides what.

Who runs WoolFi?

A single multisig wallet. A multisig is a smart contract that needs several separate signers to approve any transaction before it goes through. The specific signers, threshold, and recovery process are published in the launch record. The multisig does not change settings directly: it proposes changes to a timelock, which holds each one in public for 3 days before it can run.

What can the multisig do?

• Authorize a new pool (from the fixed 18-pool catalog) and set its oracle bindings.
• Re-tune parameters of a live pool (fee schedule, tolerance, hard threshold) within audited bounds.
• Pause the whole hook in an emergency, stopping swaps and liquidity adds. This is the one action that takes effect instantly; unpausing waits 3 days like everything else.
• Resolve a structural break directly, or change how long a break waits before it can be confirmed (up to one day).
• Configure per-pool vault drawdown percentage and fee routing.

What can the multisig NOT do?

• Move your LP shares or your vault stake into another account. Balances are held by the position manager and vault contracts, not by governance.
• Change the hook's code. The hook contract is immutable after deployment. Only its documented parameters and pool authorizations are configurable.
• Issue or redeem Robinhood Stock Tokens. The token issuer (RHJ) controls that, entirely off-chain of WoolFi.
• Waive the oracle staleness and sanity checks. Those are hard-coded in the adapters.
• Receive URU taken in a drawdown. Drawn-down URU goes to a separate rebalancer address, never the multisig or the timelock.
• Skip the 3-day delay. The timelock has no admin, so even its own rules can only change through the same public queue.
• Vote "on your behalf" using URU. Underwriting stake is not voting stake.

Is there a delay before settings change?

Yes. Every settings change waits 3 days in public. A timelock (a contract that holds changes in a public queue before they can run) owns the governor, the position manager, the rebate distributor, and the zapper. The multisig can only queue a change, wait at least 3 days, then run it, so anyone watching the queue sees oracle changes, fee changes, vault wiring, break resolution, and unpausing days before they take effect. The multisig can also cancel a queued change before it runs. Unstaking URU takes 2 days, less than the 3-day delay, so a staker who dislikes a queued change can always leave before it runs.

What happens in an emergency?

Emergency pause is instant. The multisig holds a separate guardian role that can pause the hook immediately, stopping swaps and new deposits, and can do nothing else. Unpausing waits 3 days through the timelock, so a pause cannot be used to slip a change through. Withdrawing liquidity stays open while the hook is paused.

Who handles structural breaks?

Nobody needs permission. Detecting a break, confirming it after the waiting period, and unlocking a pool once its price has recovered are all open functions anyone can call; WoolFi runs a keeper bot that calls them automatically. The waiting period itself is public, so stakers and monitors see a break before any URU is drawn down. The multisig can also resolve a break, but it is not required.

Where does URU fit?

URU is the asset deposited into per-pool underwriting vaults. Stakers earn a share of pool fees and bear structural-break drawdown risk. Holding or staking URU does not grant any WoolFi governance rights in v1. URU is underwriting capital, not a voting token.

Why not just launch a token vote?

Token votes work best when there is a large, engaged holder base and a decision surface that changes often. WoolFi v1 has a fixed 18-pool catalog and an audited parameter range; there is very little to vote about that a small multisig cannot handle faster and more safely. If the surface grows, so will governance.

How do I verify all of this myself?

Every parameter change is an on-chain transaction, so every action the multisig takes is public and permanent on Robinhood Chain. The contract addresses, the multisig address, and its signer set are published in the launch record. See /docs for architecture and PROJECT_SPEC.md for the canonical spec.