Cross-chain DEX for AI agents. Swap tokens across 7+ chains.
|
suwappu.bot — products, research, and developer entry points. |
terminal.suwappu.bot — markets, charts, swaps, orders, and portfolio. |
| Goal | Start here |
|---|---|
| Add trading to an app | @suwappu/sdk · Agent REST |
| Give an AI agent market tools | Hosted MCP · A2A |
| Let a browser agent trade with a human in the loop | WebMCP Agent Desk · /agent-terminal |
| Build a self-custody flow | Execution ladder · custody semantics |
| Build managed execution | Agent REST · security baseline |
| Trade directly | Terminal · Telegram |
| Understand the system | Architecture · ADRs |
| Operate production | Production inventory · monitoring |
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.
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.
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.
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 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.
Start with the least-privileged capability your product needs and move downward only when your policy requires it.
| Level | Capability | Moves funds? | Typical surfaces |
|---|---|---|---|
| 0 — Discover | Chains, tokens, prices, portfolio, market metadata | No | REST · MCP · SDK · A2A |
| 1 — Quote | Price an intent and compare eligible routes | No | REST · MCP · SDK · A2A |
| 2 — Simulate | Evaluate a proposed swap before signing/execution | No | REST · MCP |
| 3 — Prepare | Build an unsigned self-custody transaction | No | REST · MCP · SDK |
| 4 — Execute | Managed server-side execution | Yes | Explicit Agent REST / managed SDK path |
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.
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.
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.
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.
{
"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.
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.
Feature availability varies by client and chain. Use Feature Guides and Product Status instead of assuming monorepo presence means universal availability.
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 policy"]
Router["Eligibility · quote race · execution"]
Evidence["Status · receipts · execution evidence"]
end
subgraph Settlement["External execution + settlement"]
Providers["Chain-gated routers / venues"]
Chains["EVM · Solana · TRON · Starknet · others"]
end
Human --> API
Apps --> API
Agents --> API
API --> Policy --> Router --> Providers --> Chains
Router --> Evidence
The production runtime includes request-serving services, dedicated workers, bridge/relayer services, signal/on-chain ingestion, Postgres, and Redis. Do not infer deployment topology from source directories; use the production inventory.
For system boundaries, data flows, key handling, and background services, read the Architecture Overview.
Suwappu intentionally keeps experimental work visible without presenting it as live money-path behavior.
| Area | Status | Meaning |
|---|---|---|
| Terminal / web / Telegram / core APIs | Production | User- or application-facing runtime surfaces |
| Hosted MCP / Agent REST / A2A | Hosted | Live programmatic interfaces; capabilities differ by surface |
| TypeScript SDK | Published + source | npm package plus monorepo source; source may be ahead |
| Python SDK | Source-only | Use a pinned repository revision for production integration |
execution_sync* | Shadow | Read-only calibration/replay evidence; not routing authority |
contracts/primitives/ | Experimental / readiness-gated | Presence in repo does not imply deployment or production dependency |
The canonical definitions and version caveats are in Product Status.
Suwappu moves money, so the security boundary belongs next to the integration flow—not at the bottom of the docs.
Read SECURITY.md and the agent security baseline. The checked-in CycloneDX SBOM, CodeQL, and OpenSSF tooling are security evidence—not an audit or compliance certification.
Fast-moving infrastructure becomes unreliable when docs, config, and deployment state each invent their own truth. Suwappu keeps important facts in versioned contracts:
| Contract | Source of truth for |
|---|---|
stats.generated.json | Public chain/router counts |
.env.schema | Environment-variable contract |
capabilities.yaml | Optional capability/provider manifest |
ARCHITECTURE.md | Normative system boundaries |
docs/adr/ | Architecture decisions |
docs/deployment/production-inventory.md | Current production service catalog snapshot |
docs/product-status.md | Maturity and publication semantics |
Docs-only changes can be checked with:
./scripts/verify.sh docs
For local setup and component-specific test lanes, use ONBOARDING.md.
suwappubot/
├── api-ts/ # Agent REST, MCP, A2A, webapp and execution routes
├── api/ # Python FastAPI entry points
├── bot/ # Bot, execution engine, services, workers, models
├── webapp/ # React/Vite application
├── terminal/ # Trading terminal / Mini App
├── mobile/ # Expo iOS client
├── extension/ # Browser wallet extension
├── showcase/ # Public website, products, research, generated stats
├── contracts/ # Solidity contracts and protocol primitives
├── packages/ # SDKs, MCP bridge, OpenClaw, design tokens
├── docs/ # Product, architecture, security, operations, research
├── database/ # Schema/bootstrap and runtime migrations
├── scripts/ # Verification, replay, maintenance, ops tooling
├── monitoring/ # Health/monitoring manifests
├── sbom/ # CycloneDX software bill of materials
└── .github/workflows/ # CI, security and deployment workflows
| Resource | Use it for |
|---|---|
| Quickstart | First successful user/agent/app integration |
| Agent clients | MCP, SDK, REST, A2A, auth and custody semantics |
| Product status | Production vs hosted vs source-only vs shadow vs experimental |
| Feature guides | User-facing capability workflows |
| Architecture | Runtime boundaries and request/data flows |
| Production inventory | Railway service-catalog snapshot |
| ADRs · Decisions | Why important choices exist |
| Onboarding · Contributing | Work on the monorepo |
| Security · Support | Vulnerabilities and help |
Apache-2.0. See LICENSE.
Source-derived launch command. Check the maintainer’s required arguments and credentials before running:
npx -y @suwappu/mcp-serverMerge this template into ~/Library/Application Support/Claude/claude_desktop_config.json. Keep existing servers. Add any arguments, credentials, and permissions required by the maintainer; this template has not been install-tested.
{
"mcpServers": {
"io-github-0xsoftboi-suwappu": {
"command": "npx",
"args": [
"-y",
"@suwappu/mcp-server"
]
}
}
}Restart Claude Desktop completely for changes to take effect. Confirm the server appears connected in the client’s tool list, then try a read-only example from its documentation.
Claude Desktop setup reference@suwappu/mcp-servernpmio.github.0xSoftBoi/suwappu works with any MCP-compatible client. Copy the config snippet from the Configuration section above and add it to the file shown for your client, then restart the application.
~/Library/Application Support/Claude/claude_desktop_config.jsonRestart Claude Desktop completely for changes to take effect.~/.cursor/mcp.jsonRestart Cursor for changes to take effect..vscode/mcp.jsonReload VS Code window for changes to take effect.~/.codeium/windsurf/mcp_config.jsonRestart Windsurf for changes to take effect..mcp.jsonSave at the project root, then start Claude Code in that project and review the MCP server approval prompt. Keep real credentials out of shared files.