Spend rejected

A spend request was refused — how to find out exactly why, using PolicyVault's own structured refusal reasons.

Start with simulation

If a spend was refused, or you want to check one before attempting it, simulate it first. A well-formed simulate call always returns an explicit verdict — ok: true or ok: false with a structured refusalReason carrying the exact code and message the real call would have produced. This is the fastest way to find out exactly why, without spending anything or consuming an approval.

Common reasons, and where to read more

Likely causeRead
The amount exceeds the agent's per-transaction limitPer-transaction limit
The amount would exceed the remaining periodic budgetBudget exceeded
The recipient isn't on the vault's allowlistDestination not allowed
The spend needs approvals that haven't been collected yetApproval states, Require approvals
The vault is currently pausedPause/revoke
The wrong wallet or network is connectedWrong wallet connected, Wrong network
A held risk-review evaluation hasn't been releasedCheck the refusal code against Error codes (RISK_REVIEW_REQUIRED)
The vault doesn't have sufficient balanceINSUFFICIENT_FUNDS — see Error codes

If the wallet shows "DO NOT SIGN"

This is different from an ordinary refusal — it means PolicyVault's independent pre-sign verification found that the transaction about to be signed did not match what was actually requested. Do not sign. This should never happen against an honest, correctly functioning server — treat it as a bug report; see Local intent verification and Responsible disclosure.

If the transaction was actually rejected by the network

A transaction that got as far as submission but was rejected by Kaspa consensus itself means the covenant found a genuine policy violation at the chain level — this should be extremely rare, since PolicyVault checks policy before ever building a transaction, but it is the final, absolute backstop. See Covenant enforcement.

See also: Error codes, Troubleshoot a pending request.