Here is the short answer: the per-transaction limit blocks 'big one-off spending,' while the cumulative limit blocks 'spending that won't stop.' If you set only one, you are missing a gate, and losses can be much larger when an agent goes wrong.
One user running on-chain arbitrage reported this: his agent had a daily limit of 100 USDT and a per-transaction limit of 20 USDT. The agent sent 80 requests of 0.5 USDT each within one hour. Every request was under the per-transaction limit, but the daily limit was quickly burned through. He got little usable data and still lost money. The core issue is that a per-transaction limit only checks a single amount. It cannot stop many small high-frequency requests from adding up.
Concept Breakdown: What Each Gate Controls
Per-transaction limit: the most the agent can spend in a single payment. It blocks unusual large one-off spending. For example, if an agent is injected with an instruction to transfer a large amount, a proper per-transaction limit will reject that transaction directly.
Cumulative limit (daily/session limit): the total the agent can spend in a fixed period, usually a rolling 24-hour window. It blocks high-frequency small spending that adds up. The arbitrage example above is a classic hole when only a per-transaction limit is set. Each small request looks fine alone, but together they can quickly drain the daily budget.
You need both. With only a per-transaction limit, many small high-frequency payments can slowly empty the account. With only a cumulative limit, one large abnormal instruction can empty the daily budget before you can even react.
Comparison: Suggested Pairings for Different Scenarios
| Scenario | Per-transaction limit | Cumulative limit (daily) | Reason |
|---|---|---|---|
| Calling public APIs (data scraping, weather queries) | 0.5 - 1 USDT | 5 - 10 USDT | Each request has a fixed cost; a daily budget controls total cost |
| On-chain data queries (paid RPC) | 1 - 5 USDT | 20 - 50 USDT | A single query can vary a lot depending on the data size |
| Agent shopping/payments | 10 - 50 USDT | 100 - 500 USDT | Prices fluctuate, so you need some flexible room |
| High-frequency trading/arbitrage agents | Depends on strategy | Depends on position size | Trading needs more complex risk controls; limits alone are not enough |
These are general reference values. If you are a beginner, start with a conservative setting: per-transaction 1 USDT and daily 10 USDT. Run it for a week, then adjust based on actual spending.
Next Steps: How to Set It Up
Step 1: Check which limit dimensions your tool supports
Different platforms put these settings in different places:
Agorio SDK: configure perTransactionLimit and dailyLimit when creating the spendingControls plugin
PaySpawn: set daily limit + max per tx when creating a credential in the Dashboard; once on-chain, it cannot be tampered with
agent-pay-guard: write per_transaction and daily thresholds in guard.yaml; monthly cumulative is also supported
Cronos Agent Wallet: limits: { daily: 10, perTx: 1 }, applied on-chain through AgentAdmin.setPolicy
kova-sdk: Policy.create().spendingLimit({ perTransaction: "1", daily: "5" }), supports multi-layer rule combinations
Step 2: Set warning thresholds
Don't wait until the limit is fully used up. Trigger notifications when cumulative usage reaches 75% and 90%, so you can step in early. If the agent runs unusual high-frequency requests at night, you still have time to stop it manually after the alert.
Definition of done: You can see two separate limit rules in the Dashboard or config file, not just one 'total limit.'
Common Failure Reasons
1. You set a per-transaction limit but no cumulative limit. This is the same trap the arbitrage user fell into. High-frequency small payments pass the per-transaction check easily, making the daily limit useless.
2. The daily limit is so high that it is almost no limit. A daily cap of 1000 USDT is basically unlimited for a beginner agent. By the time you notice something is wrong, the loss is already serious.
3. You mistake 'rolling window' for 'calendar day.' Some tools use a rolling 24-hour window; others reset at 00:00 by calendar day. If the agent runs one payment at 23:59 and another at 00:01, they may cross two calendar days but still be within the same rolling window. Before use, confirm how your tool calculates the limit period.
High-risk reminder: if limit rules only live in code, an injected agent may be able to modify its own config. Consider writing the limits on-chain into a smart contract so that agent permissions cannot tamper with contract rules. If your tool does not support on-chain enforcement, at least place the config file where the agent does not have write access.
How to Verify It Works
Run two tests:
Have the agent make a payment above the per-transaction limit. It should be rejected, and the log should show something like POLICY_REJECTED or Blocked: per-transaction limit exceeded.
Have the agent make multiple small payments whose total exceeds the daily limit. The last one that crosses the limit should be blocked, and the log should show daily limit exceeded or Budget exhausted.
If both are blocked, both gates are working.
