Protocol, Treasury, and Signer Protection

Cryptographic policy enforcement for protocols, DAOs, bridges, custodians, and institutional treasuries. Uses natural-language rules, proofs for every action, and receipts any counterparty can verify.

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)

• 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)

• 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)

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:

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:

{
  "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