Suwappu

Suwappu

The execution layer for onchain apps and agents.

Route across chains, simulate before money moves, and choose self-custody or managed execution from the same platform.

Quickstart · Terminal · Telegram · Developer Docs · Product Status · Security

[suwappu.bot](https://www.suwappu.bot) — products, research, and developer entry points.

[terminal.suwappu.bot](https://terminal.suwappu.bot) — markets, charts, swaps, orders, and portfolio.

---

ETHGlobal Tokyo 2026 — Agent Swap Passport

Live demo → [suwappu.bot/passport](https://suwappu.bot/passport)

One wallet, checked live: try to swap unverified and a Uniswap v4 `beforeSwap` hook (0xc72ab4dF…c080) reverts at zero gas. Scan World ID and the server mints the wallet a real ENSv2 subname under suwappu-agents.eth on Sepolia and allowlists it on the same hook. Swap again — it executes through the same pool. One verification, three sponsor integrations, all proven in one recorded per-wallet run. Every claim is backed by a real Sepolia transaction, not a mock — see docs/ethglobal-tokyo2026/SUBMISSION.md for exact file:line pointers, tx hashes, and a 2-minute self-verification path per sponsor track (World ID/IDKit, ENSv2, Uniswap v4). Intercepta was explored but is explicitly out of scope for this submission — not demoed, no live API key provisioned.

---

NEAR HACKATHON 2026 — Suwappu Arbiter (“Proof of Done”)

Trustless milestone escrow for human and agent work. Delivery verified inside an OutLayer Intel TDX enclave; settlement enforced by the contract. One-line problem: every agent marketplace holds money in escrow but can’t prove the work was done. Arbiter closes the loop — a hash-pinned arbiter WASM verifies the evidence (the enclave fetches the PR from the GitHub API itself; no shared secret, no caller-supplied evidence), and every verdict is anchored on-chain as a signed work attestation.

Live demo → [suwappu.bot/arbiter](https://www.suwappu.bot/arbiter) (dry-run by default; no funds needed). Built as a product line — see ARBITER.md for the 12-month plan — with an open attestation spec at docs/arbiter-attestation-v1.md. Hackathon work (baseline commit 99161598, the last commit before the build window): pull requests #1096, #1098, #1099; everything under near/, showcase/src/app/arbiter/ and the Arbiter docs. Judge steps (dry-run, then testnet commands) and honest scope notes are in docs/hackathon/arbiter.md.

---

What can I build?

---

Why Suwappu

One control plane, not one venue

Suwappu normalizes an execution intent, discovers only the routes that can actually serve it, and compares eligible providers instead of hard-coding one exchange or bridge. The generated topology currently reports 45 platform chains, 18 Agent API chains, and 21 chain-gated routing integrations. Those are platform totals—not a claim that every route races every provider.

Human and agent surfaces share the same execution layer

Telegram, web/terminal clients, SDKs, REST, MCP, and A2A are different entry points into the same platform boundaries. Builders do not need a separate “agent DEX” and “human DEX” architecture.

Custody is explicit

Suwappu does not collapse “get a quote,” “prepare a transaction,” and “move funds” into one ambiguous action. Self-custody preparation and managed execution are separate capabilities with separate security consequences.

Execution is observable

The system records route candidates, selected routes, execution/status data, and settlement evidence. New execution-synchronization work adds normalized receipts, provider calibration, and historical/walk-forward replay—but remains shadow-only until evidence supports a controlled promotion.

The platform extends beyond swaps

The same API/control plane also exposes workflows for perps, prediction markets, lending, BTC bridging, orders, portfolio data, and wallet policy where supported by the relevant surface.

See Product Status for what is production, hosted, source-only, shadow, or experimental.

---

The execution ladder

Start with the least-privileged capability your product needs and move downward only when your policy requires it.

Important naming boundary: MCP execute_swap currently belongs to Level 3: it prepares an unsigned self-custody transaction. It does not invoke managed execution. A2A currently stops at discovery/quote semantics and has no fund-moving method.

For an AI system, begin at Levels 0–2 with an application-owned allowlist. Add Level 3 or 4 only with explicit policy, limits, and approval appropriate to the value at risk.

---

First useful integration

1. Register an agent credential

curl -X POST https://api.suwappu.bot/v1/agent/register \

-H 'Content-Type: application/json' \ -d '{"name":"my-agent"}'

Store the returned suwappu_sk_... as SUWAPPU_API_KEY. Do not commit it.

2. Discover supported chains

curl https://api.suwappu.bot/v1/agent/chains \

-H "Authorization: Bearer $SUWAPPU_API_KEY"

Do this at runtime instead of embedding a chain count in application code.

3. Request a quote with the TypeScript SDK

import { Suwappu } from "@suwappu/sdk";

const suwappu = new Suwappu({ apiKey: process.env.SUWAPPU_API_KEY, });

const quote = await suwappu.getQuote({ from: "USDC", to: "ETH", chain: "base", amount: "100", });

console.log(quote.toAmount);

Install the SDK with:

npm install @suwappu/sdk

Repository source can move ahead of the published package. Check the SDK README and Product Status when version boundaries matter.

Or connect an MCP client

{

"mcpServers": { "suwappu": { "url": "https://api.suwappu.bot/mcp", "headers": { "Authorization": "Bearer suwappu_sk_..." } } } }

Discover tools/resources/prompts at runtime rather than copying a static registry from documentation.

Continue with the full quickstart or MCP / SDK / REST / A2A guide.

---

Execution model

Intent

│ ├─ identity / auth / wallet policy ├─ route eligibility ├─ parallel quote discovery ├─ safety + simulation + limits │ ├─ self-custody ──> unsigned transaction ──> caller signs/broadcasts │ └─ managed ───────> explicit execution path ──> status / settlement evidence │ └─> receipts / scoring / replay evidence

Routing is capability- and chain-gated. The canonical generated counts live in showcase/src/data/stats.generated.json; application code should use runtime discovery APIs.

Major capability areas

• Execution: same-chain/cross-chain swaps, limit orders, DCA, MEV-aware routes.
• Markets: HyperLiquid perps, predictions, market discovery.
• Capital: lending/savings and BTC bridge workflows.
• Automation: alerts, copy trading, sniping, transaction/portfolio workflows.
• Policy: simulation, spending limits, 2FA, withdrawal allowlists, token safety checks.
• Agents: REST, hosted MCP, A2A, TypeScript/Python SDKs, framework examples.

Feature availability varies by client and chain. Use Feature Guides and Product Status instead of assuming monorepo presence means universal availability.

---

Architecture

flowchart LR

subgraph Clients["Entry points"] Human["Telegram · Web · Terminal · Mobile"] Apps["TypeScript/Python SDK · REST"] Agents["MCP · A2A"] end

subgraph Platform["Suwappu"] API["API + control plane"] Policy["Auth · simulation · safety · wallet