Skip to content

Governance, registries, pauses, and timelocks

YieldSeeker’s governance controls determine which wallet implementations, adapters, and protocol targets can be used by agents.

The Adapter Registry maps approved protocol targets to adapters. Administrative roles can register adapters and targets; emergency roles can remove or disable them and can pause adapter execution.

Registry approval allows an interaction to be attempted. It does not guarantee protocol solvency, liquidity, or performance.

The Factory creates Agent Wallets and supplies shared configuration such as the wallet implementation, Adapter Registry, fee tracker, and authorized operators. Existing wallets do not automatically become safe merely because a new implementation is approved.

Administrative changes that affect users — registering a new adapter or protocol target, changing the Wallet Factory’s shared configuration, or approving a new wallet implementation — are scheduled on the deployed AdminTimelock and can only execute after its delay passes.

The delay is a live contract value (AdminTimelock.getMinDelay()), not a constant in this documentation, because it can change through governance. Read it directly from the deployed timelock contract before relying on a specific duration.

During the delay, the pending change is visible on-chain before it takes effect, giving users time to inspect it and decide whether to continue participating or exit.

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.

An emergency role can pause registry-backed operations or remove a dangerous target. This is intended to stop further automated interactions while the incident is investigated.

Pausing execution does not create liquidity or erase existing protocol risk. User withdrawal rights and underlying-protocol withdrawal conditions remain separate concerns.

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.