Governance, registries, pauses, and timelocks
YieldSeeker’s governance controls determine which wallet implementations, adapters, and protocol targets can be used by agents.
Registry administration
Section titled “Registry administration”The deployment assigns DEFAULT_ADMIN_ROLE on the Adapter Registry and Wallet Factory to the AdminTimelock. The registry admin registers adapters and maps targets; the Factory admin updates wallet implementation, registry, and fee-tracker settings. A separate registry EMERGENCY_ROLE can remove a target mapping, unregister an adapter (disabling its mappings until re-registered), or pause the getTargetAdapter lookup. The default admin can unpause.
Registry approval allows an interaction to be attempted. It does not guarantee protocol solvency, liquidity, or performance.
Wallet Factory
Section titled “Wallet Factory”The Factory creates deterministic Agent Wallet proxies and stores the approved implementation, Adapter Registry, and fee tracker. The AGENT_OPERATOR_ROLE authorizes wallet creation. Wallets cache registry and operator settings at initialization or when synchronized. Factory implementation changes do not automatically upgrade existing wallets; the owner must call upgradeToLatest to install the currently approved implementation.
Timelocked changes
Section titled “Timelocked changes”The production deployment script sets the AdminTimelock’s initial minimum delay to four days (testing mode uses zero). Its configuration batch schedules adapter registration and Factory updates through the timelock. The vault-registration script reads the current getMinDelay() and schedules the target-to-adapter mapping there; under the production four-day setting, registration waits four days before execution.
Governance can change the live delay, so read AdminTimelock.getMinDelay() on the deployed contract before relying on a duration. A scheduled operation is visible onchain during the delay, giving users time to inspect it and decide whether to continue participating or exit, subject to the liquidity and withdrawal rules of their positions.
Deployed contracts
Section titled “Deployed contracts”Current addresses for the Adapter Registry, Wallet Factory, AdminTimelock, and each adapter are published in deployments.json in the contracts repository. This file is the source of truth; addresses are not reproduced here because they change across deployments and networks.
Emergency response
Section titled “Emergency response”The emergency role can stop new adapter-backed operations by pausing registry lookups, removing a target mapping, or unregistering an adapter. These emergency actions bypass the timelock; unpausing requires DEFAULT_ADMIN_ROLE.
Pausing or disabling a registry route does not create liquidity or reverse a settled transaction. It does not block direct owner-only withdrawals of ETH or withdrawable base asset, but a pause can block adapter-backed withdrawals of non-base positions. Underlying-protocol withdrawal conditions remain separate.
Adding a new agent type
Section titled “Adding a new agent type”A new agent type should reuse the shared governance and execution boundary unless the platform changes. Its own adapters, targets, metrics, and risks must be reviewed before being enabled.
See Security and the AgentWalletKit integration guide for the broader threat model.