How to use these templates

Twelve spend policy configurations, one for each common production agent shape. Every template is real-world tested. Copy the JSON, adjust the dollar amounts to your traffic baseline, set it on the wallet API, and you have a working policy in under five minutes.

Two things to know before you copy:

1. Always enforce at the wallet API, not in the agent's prompt or planner. Enforcement in the agent fails the first time prompt injection lands. Enforcement at the API is structural. See our security checklist for the full reasoning.
2. The dollar amounts in these templates are starting points, not gospel. Take a week of test traffic, look at the actual distribution of payments, set the per-call ceiling at 2-3x the median and the daily cap at 2x your worst legitimate day. Tighten from there.

All templates assume the Blockchain0x SDK policy shape. If you are using a different wallet provider, the field names will differ but the structure carries over.

Template 1: Research agent (low risk, frequent small calls)

The canonical "agent calls many cheap APIs for data" case. Optimizes for letting the agent work without budget interruptions while bounding the day's exposure.

{
  "perCallMax": "0.05",
  "perDayMax": "10.00",
  "counterpartyAllowlist": [],
  "counterpartyDenylist": ["known-scam-address-1"],
  "timeWindow": { "start": "00:00", "end": "23:59", "tz": "UTC" },
  "categories": ["data_api", "search_api", "scraping_proxy"]
}

When to use: research, data aggregation, RAG-heavy workflows, agents that hit search and lookup APIs throughout their session.

Template 2: MCP customer agent (paying for tool calls)

The agent calls paid MCP tools operated by third parties. Allowlist counterparties as you discover and trust them.

{
  "perCallMax": "0.10",
  "perDayMax": "25.00",
  "counterpartyAllowlist": [
    "mcp.paid-tools.example.com",
    "premium-data.example.io"
  ],
  "categories": ["mcp_tool_call"],
  "requireReceiptValidation": true
}

When to use: agents that consume paid MCP tools regularly. The allowlist plus receipt validation gives you a clear audit trail of which servers your agent has paid.

Template 3: Transactional agent (executes specific paid workflows)

The agent has a defined job that involves a known sequence of paid operations. Tight per-call, generous daily.

{
  "perCallMax": "0.50",
  "perDayMax": "100.00",
  "counterpartyAllowlist": [
    "checkout.partner-a.example",
    "checkout.partner-b.example"
  ],
  "timeWindow": { "start": "06:00", "end": "22:00", "tz": "America/Los_Angeles" },
  "categories": ["checkout", "service_invocation"]
}

When to use: agents that execute defined workflows for users - ticket purchases, recurring service charges, scheduled operations. The narrowed time window catches off-hours anomalies.

Template 4: Agent-to-agent marketplace participant

The agent buys services from other agents. Agent-to-agent payments require slightly different defaults because counterparty discovery is dynamic.

{
  "perCallMax": "0.25",
  "perDayMax": "50.00",
  "perCounterpartyDayMax": "5.00",
  "counterpartyTrustTiers": {
    "verified_kyb": { "perCallMax": "5.00", "perDayMax": "100.00" },
    "domain_verified": { "perCallMax": "0.50", "perDayMax": "25.00" },
    "unverified": { "perCallMax": "0.10", "perDayMax": "2.00" }
  }
}

When to use: agents participating in open agent marketplaces. The trust tiers let new counterparties earn larger payments over time rather than requiring an out-of-band trust grant.

Template 5: Enterprise procurement agent (high stakes, low frequency)

The agent has authority to purchase from approved vendors only, with mandate-style authorization on top.

{
  "perCallMax": "500.00",
  "perDayMax": "5000.00",
  "perMonthMax": "50000.00",
  "counterpartyAllowlist": [
    "vendor-a.example.com",
    "vendor-b.example.com"
  ],
  "requireMandate": true,
  "mandateAuthority": "[email protected]",
  "auditLogRetentionDays": 2555
}

When to use: enterprise procurement, B2B SaaS billing, regulated workflows. The mandate requirement layers AP2-style authorization on top of the spend policy. See AP2 protocol for the mandate model.

Template 6: Consumer shopping agent

The agent shops on behalf of an individual human. Lower per-call, moderate per-day, evening time window to match consumer usage patterns.

{
  "perCallMax": "200.00",
  "perDayMax": "500.00",
  "counterpartyAllowlist": [],
  "counterpartyCategoryAllowlist": ["retail", "grocery", "travel", "subscription"],
  "timeWindow": { "start": "07:00", "end": "23:00", "tz": "America/New_York" },
  "humanApprovalThreshold": "100.00"
}

When to use: consumer-facing agents booking travel, ordering groceries, or managing subscriptions. The human approval threshold sends transactions above $100 through a pre-flight confirmation flow.

Template 7: Development / sandbox agent

For agents in active development. Generous limits inside a controlled sandbox so testing is not blocked by budget. Never use in production.

{
  "perCallMax": "1.00",
  "perDayMax": "20.00",
  "environment": "test_only",
  "counterpartyAllowlist": [],
  "alertThresholds": {
    "perCallDollar": "0.50",
    "perDayDollar": "10.00"
  }
}

When to use: development environments, integration tests, demos. The test_only flag prevents the policy from being applied to a sk_live_ key by accident.

Template 8: Subscription-billing service

The agent manages recurring payments on behalf of a service. Tight per-call (it knows exactly what each recurring charge should be), generous per-day (many subscribers).

{
  "perCallMax": "100.00",
  "perDayMax": "10000.00",
  "perCounterpartyMonthMax": "1000.00",
  "categories": ["subscription_renewal"],
  "exactAmountMatch": true,
  "expectedAmounts": ["9.99", "19.99", "29.99", "49.99", "99.99"]
}

When to use: agents that process subscription renewals at predefined amounts. The exactAmountMatch setting refuses any payment not matching one of the expected amounts, catching pricing bugs and tampered subscription records.

Template 9: High-frequency / micro-payment agent

Agents making thousands of sub-cent calls per minute, often for API metering or per-token pricing.

{
  "perCallMax": "0.005",
  "perMinuteMax": "0.50",
  "perDayMax": "20.00",
  "burstMode": {
    "windowSeconds": 60,
    "maxCalls": 200
  },
  "counterpartyAllowlist": []
}

When to use: per-token API metering, per-request charges, micro-transactions inside agent workflows. The burst mode catches runaway loops without throttling legitimate high-frequency calls.

Template 10: Multi-agent crew shared wallet (constrained)

A CrewAI or AutoGen crew sharing a wallet. Per-call lower than usual because any agent in the crew can spend.

{
  "perCallMax": "0.05",
  "perDayMax": "30.00",
  "perAgentDayMax": "10.00",
  "agentBudgetIsolation": true,
  "counterpartyAllowlist": ["research-api.example.com"]
}

When to use: when architectural constraints force a shared wallet for a small crew. The perAgentDayMax and agentBudgetIsolation prevent one runaway crew member from spending everyone's budget. Per-agent wallets are still better when feasible.

Template 11: Reputation-gated growth agent

Tight starting limits that auto-expand based on transaction success rate and counterparty diversity. Useful for agents whose owners want to grow autonomy gradually.

{
  "perCallMax": "0.10",
  "perDayMax": "5.00",
  "growthRules": {
    "successRateThreshold": 0.95,
    "minTransactionsForGrowth": 100,
    "growthMultiplier": 1.5,
    "growthCadenceDays": 7,
    "ceilingPerCall": "5.00",
    "ceilingPerDay": "100.00"
  }
}

When to use: new agent deployments where you want autonomous limit-tightening. The agent earns more budget by demonstrating reliable behavior; if its success rate drops, growth stops automatically.

Template 12: Strict compliance / regulated agent

For agents in regulated workflows (healthcare, financial services, government). Maximum auditability, minimum autonomy.

{
  "perCallMax": "50.00",
  "perDayMax": "500.00",
  "requireMandate": true,
  "requireSignedAuthorization": true,
  "auditLogRetentionDays": 2555,
  "auditLogExportFormat": ["json", "csv"],
  "complianceJurisdictions": ["us-gov", "eu-gdpr"],
  "transactionApprovalQuorum": 2
}

When to use: regulated environments where every transaction needs documented authorization and audit trail. The quorum field requires two-of-N approver signature for any transaction above a threshold.

How to pick the right template

Walk down this list:

If your use case spans multiple templates, layer them. The wallet API supports composite policies; you can require both per-call limits and per-counterparty caps simultaneously.

Common mistakes when adopting a template

Mistake 1: setting the per-call ceiling at 10x the median. Starting too generous means you discover the right limit only after an incident. Start at 2-3x the median; tighten from there.

Mistake 2: skipping the daily cap. Per-call limits catch single bad transactions; daily caps catch loops, drift, and slow-rolling adversarial prompts. You need both.

Mistake 3: enforcement in the agent's prompt. This is the single failure mode that has caused the most production losses in the agent payments space. The wallet API is the only safe place to enforce limits. The agent's prompt is not a security boundary. See our security checklist for the full version.

Mistake 4: leaving the counterparty list permissive. For high-stakes agents, every recipient should be on an allowlist. The cost of adding new addresses is tiny; the cost of a payment to a typosquat address is everything you sent.

Mistake 5: never reviewing the policy. A policy set in January and unchanged in June is probably wrong. Review monthly. Tighten where the data supports it. Loosen only when you have a specific reason.

Setting a policy on a Blockchain0x wallet

Once you have picked a template, applying it is one API call:

curl -X PUT https://api.blockchain0x.com/v1/wallets/$WALLET_ID/policy \
  -H "Authorization: Bearer $SK_TEST_KEY" \
  -H "Content-Type: application/json" \
  -d @policy.json

Or in the SDK:

await wallet.setPolicy(JSON.parse(fs.readFileSync("policy.json", "utf-8")));

Verify the policy is in force by attempting a transaction beyond its limits in test mode. The wallet should reject with a structured error before the transaction reaches the chain. If it does not, your policy is not applied; check the wallet id and API key.

What to do next

Pick the template closest to your use case. Apply it in test. Run your agent against it. Look at where the policy is rejecting payments you wanted to make and adjust upward; look at where it is allowing payments you did not expect and adjust downward.

If you do not yet have a wallet to apply a policy to, create one for free. The default policy is conservative; you will want to swap in one of the templates above on day one.

If you want a deeper walk-through of policy design rather than templates to copy, the spend controls guide covers the underlying architecture. The combination of "read the guide once" plus "copy a template" gets most teams to a production-grade policy in an afternoon.