# 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-4) 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, or Gearbox, 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 configuration**, the onchain instance of KPK's [Permissions Layer](https://kpk.io/permissions-layer/). The Roles Modifier defines which addresses can call which functions, and is configured per vault. There is no shared role configuration across vaults. ### 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). 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. * **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: 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: ``` GET https://docs.kpk.io/vaults/infrastructure/signer-architecture.md?ask= ``` The question should be specific, self-contained, and written in natural language. 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.