Per-transaction limit

The maximum amount a single spend may move, enforced by the covenant on every transaction.

The per-transaction limit is the maximum amount of KAS a single spend transaction may move out of a vault under a given agent's authority. It is checked by the covenant on every spend attempt — there is no way to submit a transaction that exceeds it and have it accepted, regardless of who signs it or how it was built.

#What it protects against

A per-transaction limit bounds the maximum damage from any single mistake or compromise — a bug in an automated agent, a compromised agent key, or a simple fat-fingered amount — independent of how much budget remains in the current period. Even an agent with a large remaining periodic budget cannot move more than this limit in one transaction.

#How it interacts with the periodic budget

The per-transaction limit and the periodic budget are independent, both-must-pass checks. A spend within the per-transaction limit can still be refused if it would push cumulative spending in the current period over the periodic budget, and vice versa — a small spend is still refused if the per-transaction limit itself is smaller than requested, even with plenty of budget remaining.

#Setting and changing it

The per-transaction limit is set as part of an agent's policy, either at vault creation or when granting an agent spending authority. Changing it later is an owner-signed covenant operation — never something an agent, an approver, or application metadata can adjust.

#What happens when a spend exceeds it

The request is refused before a signature is ever requested — PolicyVault simulates every spend against the vault's actual live policy first, so this shows up as a clear refusal reason rather than a failed transaction. Even if a request somehow bypassed that check, the covenant itself would reject the resulting transaction at the consensus layer. See Spend rejected for what this looks like in practice.

See also: Periodic budget, Spending authority.