What your model can and can’t do

Your model operates inside its budgets. The shape of every call, the token approval and the expiry are enforced on-chain; when several budgets share one token, the on-chain approval is their shared total and Waypoint enforces each budget’s own cap on top of it. We cannot break your rules, and neither can your model — only you can change them.

• It can call the waypoints you granted, spend within the cap, and receive only the tokens you allowed.
• It is tied to one venue. A budget carries the venues you chose and nothing else: a Morpho budget can reach the Morpho vault and not the Uniswap router, so a model holding it cannot trade. On a swap budget, Session can trade what it receives is on by default (and switched off when the receive set is Any), so the model may sell back what it bought. A Morpho budget has no such toggle — its exit is the “Receives, up to” share ceiling described below. A budget with no venue is refused rather than created.
• It can’t move funds to another wallet, exceed the budget, touch tokens you haven’t approved, or grant itself new permissions. The approval that funds its budget can only be signed by you.
• It can ask. A model that wants more budget or a new capability files a request. The request shows up in your dashboard; nothing changes unless you approve and sign it. Your model can propose; only you can permit.

When an attempt to execute is blocked, the refusal is typed and specific, so the model knows exactly what happened and what would fix it:

{
  "code":   "EXCEEDS_GRANT_CAP",
  "error":  "this call would spend 50 USDG but only 8 USDG of this budget's cap remains",
  "remedy": "reduce the amount, or ask the owner to raise the cap with waypoint_request_budget"
}

The remedy comes back on the model-facing endpoints (/session/act and /session/brief); everywhere else a refusal is the code and error plus the facts that caused it.

Positions: getting in, and getting out

Some waypoints hold a position rather than trading one token for another. A Morpho budget deposits USDG into a vault and the vault mints you shares — steakUSDG — which land in your own wallet, never in the executor.

Getting out is a separate permission. Redeeming spends the shares, so it needs its own approval over them: the “Receives, up to” figure on the budget ticket is exactly that ceiling. Set it and your model can unwind the position up to that many shares. Skip it and the budget can deposit and never withdraw — your money is not stuck, because the shares are yours and you can redeem at the vault directly, but your model cannot do it for you.

You can also grant the exit on its own. A redeem budget has no spending cap at all: it moves no USDG, it only unwinds shares you already hold, bounded by the ceiling you approve and never by more than your actual balance.

Refusals your model might see

The table shows the codes a model meets most often; the full set is larger, and every refusal names its fix in the error text.

A refused call never reaches the chain and costs nothing. A call that passes these checks but reverts on-chain does spend gas from your deposit. Every quote is free, for you and for it — reading never costs anything.