Under the hood
You don’t need this page to use Waypoint — it’s here so you know why the promises hold.
Who talks to whom — and where the rules live
Two locks, signed by you
When you sign a budget, you create two independent locks. The amount wall is the token approval itself — approve(executor, cap) — living in the token’s own storage. Past the cap, the token contract refuses, and only your signature can raise it. This is the same mechanism every DEX uses; there is nothing novel to audit about it.
The shape wall is a rulebook recorded on-chain against the session’s key: which functions it may call, on which contracts, with which tokens — and, always, that the recipient of any output is pinned to your address. A swap grant compiles to rules like:
target = Uniswap SwapRouter
equal — nothing else callable,
and no other venue
function = exactInputSingle
equal — one function, not "anything on Uniswap"
tokenIn ∈ { USDG, … }
one-of — the budget token, plus what it received
when trading proceeds is on
tokenOut ∈ { WETH, WAY }
one-of — the set you granted (no rule for Any)
recipient = your wallet
equal — output cannot land anywhere else
The shape wall is checked by the chain, during validation, before anything executes: a call that fails a rule is rejected before it begins. The amount wall is the token contract itself: a pull past the approval reverts, and because the whole call is one atomic transaction, everything in it is undone. Each budget’s own cap, when budgets share a token, is checked by Waypoint before the call is ever submitted.
The turnstile
You get one executor per chain, not one per budget, and every budget you hold runs through it. So budgets that spend the same token share a single approval: the token contract enforces the total, and Waypoint enforces each budget’s own cap on top of it. That is worth knowing in both directions — it is why a second budget needs no new setup, and why setting that token’s approval to zero stops all of them at once.
What our servers actually do
Waypoint’s backend authenticates your model against a hash of the credential, and separately keeps an encrypted copy of it so the app can rebuild connector links without forcing a rotation. It also holds the session’s own signing key, encrypted at rest — the one key Waypoint keeps, and it can only sign calls the rules you installed allow. Reading the credential back — or rotating the credential — takes a fresh signature from the wallet that owns the session; an API token on its own will not do it. The backend also turns your model’s intent into properly-formed transactions, keeps the activity ledger, and serves the API and dashboard. What it can’t do is move your money outside the rules — the rules live on-chain, signed by you, and the chain doesn’t ask us.
The API describes itself
A model presenting its credential gets back exactly what it may do — its verbs, its waypoints, its remaining budget — straight from the source of truth (/session/state and its short form /session/brief, shown in Getting started). That’s why the MCP tools appear scoped correctly with zero configuration, and why two AIs holding two different credentials see two different products.