Create your first delegated spend

Walk an agent spend from request through simulation, verification, signature, and confirmed chain proof.

This walkthrough follows one delegated spend end to end, using the same pipeline described in PolicyVault in 5 Minutes: intent → build → sign → finalize → submit → reconcile.

#Prerequisites

• A vault exists and is funded (see Create your first vault).
• An agent has been granted spending authority on that vault (see Give an AI agent spending authority).
• The wallet acting as the agent (or the owner, walking through this as a test) is connected.

#Steps

1. From the vault's page, choose Spend (or the agent-spend action, if using the API/SDK directly — see REST API).
2. Enter the amount and the recipient address. If the vault has a destination allowlist, only allowlisted recipients can be entered successfully — anything else is refused before a transaction is even built.
3. Simulate first. The dashboard (and the SDK's simulate() call) runs the exact same pipeline a real spend would — the same policy checks, the same fee computation, the same successor-state derivation — without persisting anything or consuming any approval. It tells you in advance whether this spend would be refused, and why (over the per-transaction cap, over the remaining periodic budget, needs approvals, needs a governance proposal, held for risk review, and so on) — see Troubleshoot a pending request for what each refusal reason means.
4. If the spend needs approvals above the agent's threshold, it now shows as pending approval; an external approver must approve before it can proceed. See Require approvals and External approver.
5. Once ready, PolicyVault builds the exact unsigned transaction and derives its intent manifest. The signing dialog shows, in full — never truncated — the requested action, every output and its exact destination and amount, the fee, the vault's protected value and fee reserve before and after, and how much of the per-transaction cap and periodic budget this spend consumes.
6. If anything about the built transaction does not match what was actually requested, PolicyVault refuses to present a signing action at all — you see DO NOT SIGN, not a signature prompt. This should never happen in normal operation; it exists specifically to catch a manipulated or buggy server.
7. Sign in KasWare. The wallet signs only the specific transaction inputs PolicyVault named — never a blanket authorization.
8. PolicyVault submits the signed transaction and does not treat "submitted" as done. It waits for the transaction to actually be confirmed and for the exact expected successor vault state to appear on-chain before marking the spend complete and updating the vault's remaining budget.

#If something goes wrong partway through

PolicyVault's pipeline is built to be crash-safe at every stage: a durable record is written before broadcasting, so a crash right before or right after submission is recoverable rather than ambiguous. If a request seems stuck, see Transaction pending and Troubleshoot a pending request — you should never need to guess whether a spend happened.

Next, browse Core Concepts for the underlying vocabulary, or How-To Guides for specific tasks.