> For the complete documentation index, see [llms.txt](https://docs.kpk.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.kpk.io/vaults/infrastructure/signer-architecture.md). # Signer architecture Every KPK-curated vault is operated through a dedicated set of Safes and onchain permissions. The architecture isolates each vault, scopes automation to a single role, and keeps human signers behind multi-signature thresholds and timelocks. No individual signer, automated or human, can unilaterally move funds or change a vault's risk parameters. A [Safe](https://safe.global/) is a smart-contract multi-signature wallet on Ethereum and EVM chains: transactions require approval from a configurable number of signers (e.g. 2-of-5) before execution, with the signing rules enforced onchain rather than at a custodian. ### Per-vault Curator Safe Each KPK-curated vault, whether on Morpho, Euler, Gearbox, or Symbiotic, has its **own Curator Safe**. The Safe governs day-to-day curation actions for that vault and nothing else. Curator Safes share the same signer set across vaults, which always includes the **KPK Risk Council Safe** (5-of-8). The Risk Council Safe also owns the vault contract itself, giving it authority over higher-impact actions such as adding or removing markets. Each Curator Safe carries a **distinct** [**Zodiac Roles Modifier**](https://docs.roles.gnosisguild.org/) **configuration**, the onchain instance of KPK's [Permissions Layer](https://kpk.io/blog/permissions-layer). No role configuration is shared across vaults. ### Onchain permission enforcement The Roles Modifier is a contract in the transaction path, not an offchain policy file. Every call an agent makes is routed through it and checked against that role's allow-list before the Safe will act on it. A call that is not permitted reverts onchain. The allow-list is scoped at three levels: * **Target.** Which contracts the role may call, for example the vault and its adapter, and nothing else. * **Function.** Which functions on those contracts, for example `reallocate` but not `setCurator`. * **Parameter.** Which argument values are acceptable, for example only the markets already approved for that vault, and only that vault's own adapter as the destination. Parameter-level scoping is what makes the permission narrow rather than merely role-based. A protocol-level Allocator role permits reallocation across every market a vault has enabled. The Roles Modifier restricts a given agent to a defined subset of those markets, within defined bounds. Two properties follow from this: * **The security boundary is the permission set, not the agent code.** A bug in an agent can at worst perform a permitted action at the wrong moment. It cannot perform an action the role does not allow, regardless of what the code attempts. * **Giving an agent a new capability is an onchain change.** Extending what an agent may do requires updating the role, which is a governance-class transaction under timelock (see [Defence in depth](#defence-in-depth)). Deploying new agent code changes nothing about what is permitted. If code and role disagree, the transaction reverts. No agent holds funds. Depositor assets sit in the vault contract, and the Curator Safe holds the roles over it. An agent EOA holds only a key that can propose a call through the Roles Modifier, and that key lives in a dedicated signer service that signs and nothing else: it does not choose what to send, and it does not broadcast. ### Automation addresses are vault-specific KPK agents (rebalancing, exit, and replenishment, see [Automation](/vaults/infrastructure/automation.md)) operate through externally owned accounts (EOAs) that are **unique per vault**. Each EOA is whitelisted in the Curator Safe's Roles Modifier for a narrow set of functions, typically reallocation between approved markets or reducing a market's cap to zero. Key properties of these automation EOAs: * **One EOA per vault per agent type.** A rebalancing EOA for the USDC Yield vault cannot act on the ETH Prime vault, and vice versa. * **No human key access.** Private keys are generated and held in a dedicated ETH signer vault. No team member can sign manually from these addresses. * **Single-purpose.** The addresses are used exclusively for their assigned agent function. They do not hold other assets and do not interact with other contracts. * **Role-scoped permissions.** At most, an automation EOA holds an Allocator-equivalent role. It cannot add markets, change caps upward, or change vault ownership. To date, KPK automation has executed over 8,800 rebalances and moved more than $6bn across [KPK-curated Morpho vaults](https://dune.com/kpk/kpk-morpho-vaults). ### Manual signers Beyond automation, the remaining signers on Curator Safes are **KPK team members**. The same individuals sign across all KPK-curated vaults from labelled, curation-only addresses, for example [`kpk Deployer 1`](https://etherscan.io/address/0xF0Cf1e3Ec6264b03241826f5b2aBda17B4352A75) and [`kpk Deployer 2`](https://etherscan.io/address/0x331D9C769185AE25233314859d53c2b9203a1204) on Etherscan. These addresses are used strictly for activities required to operate KPK-curated products. This includes signing Curator Safe transactions and the onchain steps that support curation, such as token transfers, approvals, and DEX swaps performed in the course of market creation or vault setup. No activity outside the scope of curating KPK products takes place from these addresses. Standard operational practices apply to every Safe transaction: * Calldata is decoded and inspected before signing. * Transaction hashes are independently verified on hardware wallets. * Transactions are simulated before signing. ### Defence in depth The architecture is designed so that no single point of failure, automated or human, can produce a material change to a vault. * **Threshold signing.** Every Curator Safe transaction requires at least two signatures. A single compromised signer cannot execute a transaction alone. * **Timelocks on governance-class changes.** Changes that can expand permissions or increase risk, for example role updates, enabling a new market, raising allocation ceilings, or adding an adapter, execute under protocol-specific timelocks (e.g. Morpho v2's 3/7/14-day schedule, Euler Earn's 3-day delay, Gearbox's 24-hour delay on pool changes). Symbiotic V2 ships no built-in timelock on its economic parameters, so there the separation is by authority rather than by delay: parameters that can widen exposure sit with the Security Council, operational parameters with the Curator Safe. Operational actions within pre-approved bounds, such as reallocation between enabled markets or setting a market cap to zero, are not timelocked so that agents can respond within seconds. The **Guardian** role can intervene during the timelock window if needed. Coverage varies by protocol and is documented on each vault page. * **Bounded automation.** The worst-case outcome of an automation key compromise is reallocation between pre-approved markets, within existing caps. Funds cannot be withdrawn to an external address or moved to a non-approved market. This bound is enforced by the Roles Modifier at execution time, not by the agent's own logic, so it holds even against a fully compromised signer. * **Monitoring.** Hypernative and internal monitors flag abnormal transactions in real time, including queued timelocked actions. For the broader monitoring and response framework, see [Risk framework](/vaults/infrastructure/risk-framework.md). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.kpk.io/vaults/infrastructure/signer-architecture.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.