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 an allowance, 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
function = exactInputSingle equal — one function, not "anything on Uniswap"
tokenIn = USDC equal — spends only the budgeted token
tokenOut ∈ { WETH, cbBTC } one-of — the set you granted
recipient = your wallet equal — output cannot land anywhere else
Every call is checked against both walls by the chain, during validation, before anything executes. A call that fails a rule isn’t reverted halfway — it’s rejected before it begins.
The turnstile
What our servers actually do
Waypoint’s backend holds the session credential as a hash (only you hold the actual session key), 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, 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.