Policy Lifecycle Guide

Policies define which wallets, chains, and contracts a deployment can use, who must approve those actions, and how automation enforces the decision; whenever a new requirement appears (a fresh chain, a payout change, an audit finding), the team updates the policy in Projects → Deployments → Policy & Wallets or in the multichain.walletPolicy block so both the dashboard and OpenTool stay aligned, automation validates the change, and every wallet action instantly inherits the new guardrail without extra steps.

OpenTool Policy Example

jsonc

"multichain": {
  "walletPolicy": {
    "name": "chain-z-royalties",
    "chains": ["chain-z"],
    "allowedContracts": [
      "0x1234...cafe", // royalty distributor
      "0xabcd...00ff"  // treasury bridge
    ],
    "spendLimit": "1.0", // ETH per transaction
    "approvals": {
      "requireOtp": true,
      "delegate": "operating-wallet"
    }
  }
}

Drop this block into the deployment metadata so local OpenTool runs and CI match the dashboard guardrail. The sync job imports it as a draft policy, so the dashboard only needs a quick review before activation.

Blocklist Enforcement

Every wallet transaction passes through the shared blocklist service before it reaches the chain. The service checks the target chain, contract address, and destination wallet announced by the policy and aborts anything that is marked as blocked. Because the blocklist is evaluated on every transaction, you can update it once and immediately shield all policies—new or old—without editing individual deployments.

Frontend Flow

Add or edit policies from Projects → Deployments → Policy & Wallets
Every change there syncs with the OpenTool metadata block and immediately feeds the policy → blocklist → Turnkey pipeline shown above.