Waypoint

Waypoint is an AI agent for on-chain goals: state what you want, it plans the full multi-chain, multi-protocol path to get there, validates it, and runs it end to end.

Comment

Inspiration

Existing natural-language on-chain agents — Bankr being the clearest example, a live production product with real trade volume — already handle pre-built combo intents: swap, bridge, swap+send, cross-chain swap. We wanted to know exactly where that stops, so instead of guessing we tested it ourselves on Bankr Terminal (2026-08-12): "swap ETH to USDC on Base, bridge it to Arbitrum, then supply it into Aave to earn yield." Bankr completed the swap+bridge automatically — real on-chain transaction — then stopped cold at the third step. Its own reply: "no one-click tool yet for direct Aave deposit — you can supply it yourself on Aave's frontend." Separately, Bankr's own official account has publicly acknowledged a single-turn step limit, telling a user to split a multi-step request into separate messages. The underlying settlement infrastructure for cross-chain movement is already mature (NEAR Intents: $20B+ cumulative volume; ERC-7683 adopted by Across, LI.FI, UniswapX). What's missing isn't execution primitives — it's who plans the full dependency chain across them.

What it does

Waypoint is goal-driven, not command-driven. Instead of issuing instructions one step at a time — swap this, now bridge that, now deposit this — the user states a single target end state in plain language: "consolidate my assets into ETH and put it into the best-yielding lending protocol on Arbitrum." Waypoint reads the user's real balances across every chain they hold assets on, plans the full dependency graph needed to get from where they are to that target state, shows the plan for confirmation before anything moves, then executes it end to end. That includes exactly the kind of step — a specific protocol deposit following a cross-chain move — that stops today's chat-first agents cold and hands the task back to the user.

How we built it

The core is a five-layer TypeScript pipeline, and every layer runs against real infrastructure, not mocks:

  • State reader — real on-chain multicall reads across every chain the wallet holds assets on (native balance plus that chain's dollar stablecoin), so planning always starts from the wallet's actual current state, not a stale snapshot.
  • Goal parser — OpenAI structured output turns free-text plus the user's current wallet state into a structured goal, deliberately kept separate from execution details so an LLM hallucination can't directly touch how funds move.
  • Planner — an LLM proposes a step-by-step dependency graph, informed by a live on-chain yield lookup (read directly from a lending protocol's core contract, not a cached rate) when the goal needs one; deterministic code then validates the proposal (supported chains/protocols, no-op step detection, chain/token continuity between dependent steps, action-type consistency, malformed amount fields) before anything is treated as executable. A failed validation feeds back into a retry loop with the specific failure reason attached, rather than silently returning a broken plan.
  • Orchestrator — the execution-time state machine, and the layer we were most careful with: every step is simulated before it's ever signed, every step's dollar value is checked against a hard cap before simulation even runs, steps run strictly in order and a failure stops the whole run rather than continuing on uncertain state, and the amount fed into a dependent step is that step's actual measured output — read from its own transaction receipt, or for a cross-chain step, confirmed via the bridge's own delivery-status endpoint — never the plan's estimate. Two bridge vendors and one same-chain execution vendor are wired up underneath; none of them is a permanent dependency the planner is locked to — the planning and validation layers above are what's actually novel here.
  • Plan confirmation — showing the plan isn't a binary yes/no gate. A user's reply is classified along two independent axes — what kind of action they're taking (confirm / modify / add a constraint / flag a risk concern / state looks wrong) and what part of the plan they mean (the goal, a balance, a specific step, a protocol choice) — and routed accordingly (re-plan just one step, fold in a new constraint, refresh stale balance data, etc.) instead of hard-coding a response for every possible phrasing.

Challenges we ran into

  • LLM planning bugs weren't the obvious kind. Repeated end-to-end runs surfaced a no-op same-token "swap," broken chain/token continuity between dependent steps, and cross-chain actions mislabeled as same-chain — none catchable by a plan that just "looks reasonable." Fixed with a deterministic validator plus a retry-with-feedback loop.
  • Real execution exposed a second wave of bugs planning tests couldn't reach. RPC-lag caused a false "0 received" on a successful swap (fixed by reading the transaction's own receipt logs); a cross-chain delivery turned out to be invisible in our own receipt (fixed by polling the bridge's status endpoint). The first real LLM-generated plan even broke the orchestrator with a malformed amount field — no funds moved, but it proved schema-valid and executable are different bars.

Accomplishments that we're proud of

We tested the competitor gap ourselves, live, rather than assuming it. The pipeline runs fully end to end with no hand-written plan in between: real goal parsing, real planning with a live on-chain yield lookup, and real execution — verified with real transactions on Arbitrum and Base mainnet for the exact scenario the competitor fails at. Every step is simulated before signing, capped at a small dollar amount, and driven by real measured output, not an estimate.

What we learned

Real testing beats assumption at every layer — what a competitor can't do, what an LLM planner gets wrong, and what an LLM-generated plan breaks on at execution time are only knowable by actually running it, not by reasoning on paper.

What's next

More protocols beyond the current scope, retry/failure recovery, and conditional triggers (e.g. auto-deleveraging before a liquidation). Alongside that, a memory layer that remembers a user's operating habits across sessions and uses them to correctly parse longer, more compound goals.

Built With

Share this project:

Updates

Submission history