# Protocol, Treasury, and Signer Protection ### What this protects This pattern protects protocol treasuries and signer workflows by checking every proposed transfer, contract call, signer change, module install, threshold change, and governance action against formal policies before execution. Any failed or unavailable check blocks execution. **Core protection model:** Policies compile into formal logic. Actions are checked by a mathematical solver. Decisions produce cryptographic proof receipts. No appeal, no argument, no override. ### The types of failures In April 2026 alone, $605M was drained across twelve DeFi incidents in eighteen days. The three largest were structurally different, but all three failed at the same layer: * **Drift Protocol: $285M** lost through socially engineered multisig signers who pre-signed durable-nonce transactions carrying hidden admin-transfer authorizations. The protocol's smart contracts were never exploited — the signers were. ([TRM Labs](https://www.trmlabs.com/resources/blog/north-korean-hackers-attack-drift-protocol-in-285-million-heist)) * **Kelp DAO: $292M** lost when Lazarus Group poisoned the RPC infrastructure feeding LayerZero's verifier, forcing the bridge to release 18% of rsETH supply in a single transaction. The bridge did exactly what it was designed to do — release funds on verified messages. The verifier was lied to. ([CoinDesk](https://www.coindesk.com/tech/2026/04/19/2026-s-biggest-crypto-exploit-kelp-dao-hit-for-usd292-million-with-wrapped-ether-stranded-across-20-chains)) * **CoW Swap: $1.2M** lost when attackers social-engineered the .fi domain registry, hijacked cow\.fi, and served a phishing interface to users for several hours. The protocol's smart contracts and infrastructure were never compromised. ([Domain Name Wire](https://domainnamewire.com/2026/04/17/domain-hijack-led-to-crypto-heist/)) These three incidents were executed by humans and compromised infrastructure. The same types of failure apply — and apply with higher velocity — when an AI agent holds signing authority. An agent can be prompt-injected the same way Drift's signers were socially engineered. An agent can trust a compromised data source the same way Kelp's bridge trusted a poisoned RPC. An agent can be served a phishing transaction the same way CoW Swap's users were. The difference is that an agent making these mistakes does so in milliseconds, twenty-four hours a day, without a pause point. As agents gain signing authority across DeFi over the next 18 months, every pattern on this page will apply first to humans and then to the agents operating alongside them. **But whether the signer is human or agent, the core failure is the same.** Every one of those incidents moved funds without a natural-language rule in the path checking whether the action should happen. Audits passed. Contracts behaved exactly as written. The failure was upstream of the code — in the governance actions, the signer behaviors, the release functions, and the user-facing interfaces that no rule ever gated. This is the class of failure Preflight is built to prevent. If your protocol, your DAO treasury, your bridge, your custody product, or your institutional desk has shared signing authority over funds that would be hard to recover — the question you need to answer is not *"are the smart contracts correctly written."* Audits answer that. The question is: > Can you prove, for every material action your protocol or treasury took, that it complied with the policy you said it would comply with — without exposing infrastructure or counterparties? Preflight compiles a natural-language policy to formal logic, checks every proposed action against a mathematical solver in under a second, and returns a zero-knowledge receipt any third party can verify independently. Policy written in plain English. Enforcement by math. Receipt for every decision. ### Why prompt-based guardrails don't solve this Drift's attackers did not bypass any smart contract. They built a six-month social engineering operation that convinced multisig signers to pre-sign transactions that looked routine but carried hidden authorizations. An LLM guardrail on the signing interface would have been susceptible to the same framing that convinced the humans. Kelp's attackers did not break LayerZero's cryptography. They compromised the RPC servers the verifier relied on, then DDoS'd the backup nodes to force failover. The bridge released funds because its verifier believed a valid message had arrived. No reasoning layer, LLM or otherwise, would have caught an 18%-of-supply drain in a single transaction without a numerical rate-limit check. CoW Swap's attackers did not touch the protocol. They hijacked the domain and served a phishing interface. User wallets without transaction-level policy gates signed malicious transactions the protocol never saw. A guardrail that evaluates whether an action *seems reasonable* can be persuaded by the same appeal that persuaded the humans, the verifier, or the agent. A guardrail that asks *"does this action satisfy a boolean constraint"* cannot be persuaded, because the solver does not process arguments. It checks whether `releaseAmount > 0.03 * totalReserves`. The answer is SAT or UNSAT regardless of what the verifier said was valid. ### Who this page is for Preflight sits between a caller with signing authority and the action it is about to take. Who writes the rules, who wires in the API, and who reads the receipt depends on where you sit. **The protocol or DAO engineer** Your team runs a protocol like Drift, Kelp, Uniswap, Aave, Compound, GMX, Jupiter, or a hundred others. Multisig signers, admin actions, governance changes, Security Council migrations. The Security Council or governance body writes the rules in plain English. A protocol engineer wires Preflight into the multisig signing flow and admin surface. Start with Pattern 1 (multisig signing gate). **The bridge or cross-chain operator** Your release function trusts a verifier, a DVN, an oracle, or a validator set. Even when that primary layer does its job, abnormal release patterns should still fail. Preflight runs as defense in depth on top of whatever verification you already have. Start with Pattern 2 (bridge release guard). **The custodian or wallet vendor** You build Safe, Fireblocks, Phantom, Rabby, Turnkey, Privy, Crossmint — products where end users or clients hold signing authority and sign through your interface. Preflight embeds in your signing flow. Users configure rules through your UI. Every signature carries a receipt. Start with Pattern 3 (embedded custody). **The institutional treasury or RWA issuer** You bring real-world assets on-chain, run a digital-asset desk, or operate an agent-powered treasury. Your control framework needs to satisfy a risk committee, an auditor, and a regulator. Every material action needs a policy gate and an auditable receipt. Start with Pattern 4 (autonomous agent operations). ### Threat model and attack surface An AI agent or human signer with wallet signing authority faces multiple attack vectors. Every trust relationship is a potential exploit surface. | Threat | Example | Preflight Check | Residual Control | | ------------------------------- | -------------------------------------- | ----------------------------------------------- | ---------------------------- | | **Compromised agent** | Agent proposes full treasury transfer | Spend limit, recipient registry, daily cap | Safe quorum | | **Malicious signer** | Signer approves dangerous transaction | Timelock, signer independence, threshold policy | Human review / DAO review | | **Signer key theft** | Attacker signs with stolen key | Quorum and signer-source validation | Key rotation runbook | | **Unsafe Safe module** | Module can bypass multisig | Approved module registry | Module audit + recovery path | | **Address poisoning** | Recipient from clipboard/history | Recipient-source policy | Wallet UI warnings | | **Malicious batch transaction** | First call benign, second drains funds | Full calldata / multisend decode | Simulation | | **Governance attack** | Threshold lowered from 4/7 to 1/7 | Threshold-change policy + timelock | Emergency pause | | **Stale treasury state** | Balance/price outdated | State freshness checks | Multi-RPC/oracle validation | ### The four-question rule pattern Every Preflight policy answers four questions about a proposed action, before it executes. 1. **Is the size reasonable?** A percentage cap (3% of reserves per transaction) or a hard cap (under $100,000 equivalent). The single highest-leverage rule, because size limits degrade gracefully even when every other assumption breaks. An 18%-of-supply drain does not pass a 3% gate, regardless of what the verifier said. 2. **Is the counterparty legitimate?** An explicit allowlist (approved settlement addresses, approved routers, approved contract deployers) or a recency check (no asset added as collateral under 30 days old, no contract deployed under 14 days ago). Attackers almost always operate from infrastructure that is new. 3. **Is the rate reasonable?** Rolling windows (no more than X outbound transfers per hour), cooldowns, or burst thresholds that trigger automatic pauses. Catches the case where each action passes individual checks but the attacker drains through volume. Drift was emptied in 31 transactions over 12 minutes. 4. **Does this critical state change need extra confirmation?** For categorically different actions — adding new collateral, changing governance config, transferring admin authority, releasing across a bridge — require a timelock, a second verifier, or a hardware signature. These four questions map directly to the four things an attacker has to control to move funds: how much moves, where it moves to, how fast it moves, and whether anyone else confirms the move. Every documented DeFi incident in 2026 succeeded because at least one of those four was unconstrained. ### Integration patterns The same primitive — natural-language policy, formal logic compilation, solver-verified action check, cryptographic receipt — can be enforced at four different surfaces depending on where signing authority lives. #### Pattern 1: Multisig signing gate Signing authority is split across multiple humans using Gnosis Safe, Squads, Fireblocks, or a similar multisig. Each signer reviews a proposed transaction in their signing UI and signs independently. Preflight runs between the "propose" step and the "sign" step. If any signer's UI calls Preflight before presenting the transaction for hardware signature, a policy-violating transaction never reaches the human. **Safe-specific considerations:** * **Minimum threshold enforcement:** Never allow threshold below 3-of-5 or below 60% of owners * **Signer independence:** No two required signers from the same organization or custody provider * **Batch transaction decoding:** Full MultiSend expansion — a benign-looking batch can hide a dangerous second call * **Module warnings:** Modules can execute arbitrary transactions; malicious modules can take over a Safe * **Owner-change controls:** New signer additions require identity verification, hardware-wallet attestation, and delay **Example governance policy:** ``` Never sign a transaction that transfers admin authority without a 7-day timelock in the instruction data. Never sign a transaction whose instruction data references a token mint created less than 30 days ago. Never sign a transaction that disables or reduces the Security Council timelock below 24 hours. Any transaction affecting more than 5% of total treasury requires the full signer set, not the minimum threshold. Never decrease multisig threshold without 14-day timelock and governance approval. ``` **What it catches.** The Drift attack required three gate points — multisig signers pre-signing hidden durable-nonce authorizations, an admin action whitelisting a fake token (CVT) as collateral, and a zero-timelock governance change eliminating the detection window. All three would have produced UNSAT against the policy above. The attack chain breaks at the first gate. #### Pattern 2: Bridge or release-function guard Signing authority sits in a smart contract that releases funds when a verifier says a valid message has arrived. Preflight runs as a defense-in-depth layer on top of the primary verifier. Even if the verifier is compromised, a rate-limit policy catches abnormal release patterns. **Example bridge policy:** ``` Never release more than 3% of total reserves in a single transaction. Never release more than 20,000 rsETH in any rolling 60-minute window across all transactions. Any release greater than 10,000 rsETH requires confirmation from a second independent verifier. Trigger automatic protocol pause if any 15-minute window shows more than 5 release transactions. Reject all settlements during any 15-minute window where verifier latency exceeds 500ms. ``` **What it catches.** The Kelp bridge released 116,500 rsETH — 18% of total supply — in a single transaction. A 3% cap produces UNSAT regardless of what LayerZero's verifier said. The forged message still runs through the policy check. The policy check does not trust the verifier. #### Pattern 3: Embedded custody and wallet vendor You hold signing authority on behalf of users or clients. Your product is signing-as-a-service, custody, or a wallet application. Preflight embeds in your signing flow. Users configure rules through your UI. Your backend calls Preflight before every signature request is presented. **Example user-configured policy:** ``` Only transfer tokens to addresses on the approved_recipients list. Never transfer more than $2,000,000 equivalent in a single transaction. Never execute more than 3 outbound transfers in any rolling 60-minute window. Any transfer exceeding $500,000 requires a second hardware-wallet confirmation. Never approve a contract interaction with a contract deployed less than 30 days ago. ``` **What it enables.** The CoW Swap domain hijack served phishing transactions to users whose wallets had no transaction-level policy layer. A Preflight-powered wallet running a rule *"only approve swaps to routers on the approved list"* would have rejected the phishing transactions regardless of what the UI asked the user to sign. The UI can lie. The solver does not. #### Pattern 4: Autonomous agent treasury operations Your protocol, treasury, or fund runs autonomous agents against tokenized positions — yield rebalancing, liquidity provision, collateral management, settlement coordination. These agents have signing authority. They are one prompt injection, one compromised data source, or one hallucinated reasoning step away from an event that is hard to explain — whether to a governance forum, an investment committee, or a token-holder vote. **Example typescript integration:** ```typescript async function safeTreasuryAction(wallet, action) { const check = await fetch("https://api.icme.io/v1/checkIt", { method: "POST", headers: { "Content-Type": "application/json", "X-API-Key": process.env.ICME_API_KEY }, body: JSON.stringify({ policy_id: process.env.TREASURY_POLICY_ID, action: action.describe() }) }).then(r => r.json()); if (check.result !== "SAT") { logger.warn(`Action blocked: ${check.ar_detail}`); throw new PolicyViolationError(check.check_id, check.ar_detail); } const tx = await wallet.signAndSend(action.payload); return { tx, check_id: check.check_id }; } ``` **Example treasury agent policy bundle:** ``` Never transfer more than 10% of holdings in a single transaction. Only transfer to addresses in the approved_treasury_recipients list. Never execute more than 5 outbound transfers in any rolling 60-minute window. Any transfer exceeding $100,000 equivalent requires a 24-hour timelock. Never approve a new token as holdable treasury asset without 30 days of price history and $10M traded volume. ``` ### What SAT and UNSAT mean Understanding result semantics is critical for production deployment: | Result | Meaning | Action | | ---------------------------- | ------------------------------------------------------------------ | ------------------------------ | | **SAT** | Declared transaction variables satisfy all hard policy constraints | May proceed to signer workflow | | **UNSAT** | One or more hard constraints failed | Block execution immediately | | **Uncertain / no consensus** | Not enough confidence in the result | Block (fail closed) | | **API unavailable** | Guardrail system not reachable | Block (fail closed) | | **SAT with stale state** | Check used outdated state data | Refresh state and re-check | **Important:** SAT does not mean the transaction is profitable, economically optimal, immune to MEV, or free from smart-contract bugs. It means the transaction matches the formal policy under the supplied state. SAT is permission to proceed, not a recommendation to proceed. ### State sources and freshness requirements Treasury checks are only as good as their inputs. Authoritative state sources and freshness requirements: | Variable | Source | Freshness Requirement | | --------------------------- | ------------------------------------- | --------------------------- | | **Wallet balance** | Chain RPC / indexer | Same block or last N blocks | | **Daily aggregate spend** | Internal ledger + on-chain tx history | Updated before check | | **USD value** | Approved oracle / price API | Max age 60 seconds | | **Approved recipient** | On-chain registry or signed registry | Versioned | | **Safe owners / threshold** | On-chain Safe state | Current nonce/block | | **Contract risk** | Approved contract registry | Versioned | | **Human approval** | Signed approval record | Scope-bound and time-bound | ### Canonical transaction data For high-value transactions, avoid LLM extraction by constructing structured inputs directly. Example canonical payload: ```json { "chainId": 8453, "safeAddress": "0x...", "safeTxHash": "0x...", "nonce": 183, "operation": "CALL", "to": "0xRecipient", "decodedFunction": "transfer(address,uint256)", "token": "USDC", "amountAtomic": "150000000", "tokenDecimals": 6, "amountUsd": 150, "recipientRegistryStatus": "approved", "recipientSource": "approved_registry", "dailyAggregateUsdBefore": 450, "humanApprovalReceived": false, "registryVersion": "2026-04-23", "stateTimestamp": "2026-04-23T15:30:45Z" } ``` This approach provides deterministic policy evaluation without relying on natural language extraction for critical financial data. ### Receipt binding A SAT result should not be reusable for a different transaction. The cryptographic receipt binds to: `policy_id`, `policy_version`, `safe_tx_hash`, `chain_id`, `safe_address`, `nonce`, `to`, `value`, `data_hash`, decoded calldata hash, signer set hash, registry version, state snapshot hash, timestamp, and expiry. Store the receipt beside: the Safe transaction, the on-chain transaction hash, the decoded calldata, and the state snapshot used for the decision. This creates an auditable trail that proves every material action was policy-checked before execution. ### Example policies **Collateral admission policy (lending protocols, liquid-staking, RWA issuers):** ``` A new asset can be admitted as collateral only if it has 30 days of on-chain price history. A new asset can be admitted as collateral only if its 24-hour traded volume across approved DEXs exceeds $1M. A new asset can be admitted as collateral only if it is issued by an entity on the approved_issuer_registry. Admission requires a 48-hour timelock between proposal and execution. ``` **Cross-chain settlement policy (bridges, wrapped asset issuers):** ``` Never settle a cross-chain message representing more than 3% of total bridge reserves. Never settle a message referencing a source chain not in the approved_source_registry. Settlements greater than $10M require confirmation from both the primary verifier and an independent oracle. Reject all settlements during any 15-minute window where verifier latency exceeds 500ms. ``` **Governance action policy (any DAO with onchain governance):** ``` Never execute a governance proposal without a 7-day timelock between passage and execution. Never execute a governance proposal that disables the timelock itself. Never execute a governance proposal affecting Security Council composition without 14-day notice. Emergency pauses require only 3-of-5 signers; emergency unpauses require full set. ``` ### Battle testing matrix Test your policies against real attack scenarios before production deployment: | Test Scenario | Expected Result | | ----------------------------------------------------------- | --------------- | | Transfer $50 to approved vendor, daily total $120 | SAT | | Transfer $150 when limit is $100 and no approval | UNSAT | | Transfer to approved-looking address sourced from clipboard | UNSAT | | Install unapproved Safe Module | UNSAT | | Lower threshold from 4/7 to 1/7 | UNSAT | | Add new signer without timelock | UNSAT | | Execute batch where second call is unknown contract | UNSAT | | Contract upgrade without governance approval ID | UNSAT | | Bridge funds to approved bridge but unapproved destination | UNSAT | | Price data older than max freshness window | UNSAT | ### Production deployment checklist **Policy compilation:** * [ ] Policies compiled and battle-tested against attack scenarios * [ ] Policy IDs stored in environment/config * [ ] All transfer, contract, signer, threshold, module, bridge, and upgrade actions checked **Execution controls:** * [ ] Any UNSAT blocks execution * [ ] API unavailable means fail closed * [ ] Safe transaction hash bound to proof receipt * [ ] State snapshot stored with receipt **Data integrity:** * [ ] Registry versions stored and versioned * [ ] Human approvals are signed, scoped, and time-bound * [ ] Calldata decoded before check * [ ] Batch transactions fully expanded **Operational security:** * [ ] Signer changes require timelock * [ ] Emergency pause tested and documented * [ ] Key-rotation drill completed * [ ] Incident-response contacts documented **What's in the receipt** Every `checkIt` response includes a `check_id` and a cryptographic proof that the named policy was applied to the named action and produced the named result. The proof is verifiable by any third party without contacting ICME, without access to your policy rules, and without revealing anything about the action beyond what the receipt exposes. Use cases by audience: * **DAO governance accountability.** Token holders can verify the Security Council followed the policy the DAO voted on. Verification is independent of the multisig and the Security Council itself. * **Counterparty settlement.** Other protocols can verify your agent's action was gated before accepting it. They verify the receipt before settling. Trust becomes portable. * **Post-mortem evidence.** When incidents happen, receipts provide a minute-by-minute record of which policies held, which didn't, and when each failed — independent of logs attackers may have wiped. * **Insurance underwriting.** Underwriters can verify receipt hash chains against stated policies. Operational discipline becomes mathematically verifiable. * **Audit and regulatory evidence.** Regulators get cryptographic proof of policy compliance without disclosure of infrastructure, counterparties, or actions beyond what receipts expose. ### What's next **Quickstart** Compile your first policy, check an action, read a receipt. Ten minutes end-to-end. Quickstart **API Reference** Every endpoint, every parameter, every response shape. API Reference **Pilot integration** Running a protocol, a DAO treasury, a bridge, a wallet vendor, or an institutional desk? We will walk you through the integration pattern that fits your architecture. Contact --- # 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.icme.io/documentation/agentic-commerce/protocol-treasury-and-signer-protection.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.