Getting Started

Welcome to Sylphy

Sylphy is private DeFi execution on Base. It protects intent details, matching logic, policy checks, and audit context while keeping final settlement verifiable on-chain.

Private execution, public settlement

Apps and agents submit signed intents instead of exposing raw trade actions early. Sylphy checks allowlists, slippage limits, and policy rules before sending the verified result to Base.

Base proves the transaction settled. Sylphy keeps the sensitive strategy and execution path private.

Core Architecture

Sylphy protects the path before settlement. Intent details and routing context are processed inside a Trusted Execution Environment (TEE), then the final result settles on Base.

Get Started

Quickstart

Connect a wallet, create an intent, and track settlement.

x402 Protocol

Learn how paid API routes work without API keys.

Private Execution

See what stays private during intent execution.

API Reference

Browse endpoints, examples, and payment headers.

How It Works

1

Submit an intent

A wallet, app, or agent sends a trade intent to Sylphy.

2

Process privately

Matching, policy checks, and proof preparation run in a protected flow.

3

Settle on Base

The final settlement is public and verifiable. The execution context stays protected.

What Sylphy is not

Important boundary

Sylphy is not a mixer, privacy coin, or anonymity layer. Wallet activity, transaction hashes, settlement amounts, and x402 payment records can still be visible on Base.

Getting Started

Quickstart

Submit your first Sylphy intent. Use the app for a wallet flow, or use the API when an agent needs to create intents programmatically.

Quickstart scope

This section shows the shortest path to a submitted intent. x402 payment details are covered in the protocol section.

Choose your path

Option A: Sylphy App

Best for wallet users who want to create and review an intent in the interface.

Option B: Agent API

Best for agents, scripts, and apps that submit intents through x402.

Option A: Sylphy App

1

Connect wallet

Open Sylphy and connect a Base-compatible wallet.

2

Create an intent

Enter the token, side, amount, limit price, and any execution constraints.

3

Submit for execution

Sylphy queues the intent for private execution and returns a status reference.

4

Verify result

After settlement, review the final status and Base transaction reference.

Option B: Agent API

Registered agents submit intents through POST /api/intents/trade. External clients pay with x402; this example focuses on the intent payload and accepted response.

submit agent intent

POST /api/intents/trade
Content-Type: application/json
X-PAYMENT: <base64-encoded-payment-proof>

{
  "agentId": "agent_sylphy_01",
  "agentWallet": "0xAgentWallet...",
  "ownerWallet": "0xOwnerWallet...",
  "token": "0xTokenAddress...",
  "side": "buy",
  "amount": "100000",
  "limitPrice": "0.0042",
  "maxSlippageBps": 100,
  "settlementNetwork": "base",
  "privacyMode": "tee"
}

Accepted response

A successful submission returns an accepted private intent. Use the intent ID to track execution and settlement.

intent accepted

{
  "ok": true,
  "intentId": "intent_8f3a...",
  "status": "accepted",
  "privacy": "private_intent",
  "auditAvailableAfterSettlement": true,
  "intentPreviewHash": "0x...",
  "teeAcceptanceHash": "0x...",
  "paymentReceiptId": "rcpt_abc123...",
  "deadline": "2026-05-22T00:00:00.000Z",
  "note": "Intent is queued for TEE matching. Use GET /api/match-status/:id to track status."
}

Getting Started

Core Concepts

Sylphy is built around private intents, x402 access, protected execution, and verifiable settlement.

Execution model

Private intent

A user states the desired trade without exposing the full strategy before matching.

x402 access

External clients pay per request. Sylphy requests payment with HTTP 402 and settles in USDC on Base.

TEE processing

Matching, policy checks, and proof preparation run in a sealed execution environment.

Base settlement

The final transaction settles on Base and can be checked on-chain.

Settlement proof

Proof metadata records payment, policy, matching, and settlement checks.

Permissioned audit

Authorized reviewers can access deeper proof context. Payment alone never grants audit access.

x402 Payment

x402 Protocol

Sylphy uses x402 for paid API access. A client calls a paid route, receives 402 Payment Required, signs a USDC authorization, and retries with X-PAYMENT.

What x402 does

x402 proves that a paid endpoint was funded. It does not grant audit access, reveal private proof data, or hide final settlement on Base.

How it works

The x402 middleware checks whether a route is priced. Free routes continue immediately. Paid routes require a valid X-PAYMENT or X-PAYMENT-SIGNATURE header before the route handler runs.

1

Client calls a paid route

An external client calls a route such as /api/intents/trade, /api/token/:address, or /api/audit/:settlementId/agent.

2

Sylphy returns HTTP 402

The response includes the route description, amount, network, asset, destination, and next step.

3

Client signs payment

The client signs a USDC authorization and retries the request with the signed payload in X-PAYMENT.

4

Facilitator verifies

Sylphy sends the payment proof and requirement to the facilitator at /verify.

5

Route executes

If verification succeeds, Sylphy attaches payment data and runs the route.

Payment requirement

This is the response returned when a paid route is called without payment.

402 payment requirement

HTTP/1.1 402 Payment Required
Content-Type: application/json

{
  "status": 402,
  "message": "Payment Required",
  "protocol": "x402",
  "description": "Submit trade intent as an AI agent (requires agent registration)",
  "requirement": {
    "scheme": "exact",
    "network": "eip155:8453",
    "asset": "USDC",
    "price": "$0.01",
    "payTo": "0xPayToAddress...",
    "description": "Submit trade intent as an AI agent (requires agent registration)"
  },
  "instructions": {
    "step1": "Sign a USDC transfer authorization (EIP-3009) for the amount shown",
    "step2": "Retry this request with the signed payment in the X-PAYMENT header",
    "step3": "The facilitator will verify and settle the USDC transfer on Base",
    "network": "Base (Chain ID 8453)",
    "asset": "USDC (0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913)",
    "docs": "https://x402.org/docs"
  }
}

Payment header

After signing, retry the same request with the encoded payment proof. Sylphy checks X-PAYMENT first and falls back to X-PAYMENT-SIGNATURE.

request with payment proof

POST /api/intents/trade
Content-Type: application/json
X-PAYMENT: <base64-encoded-payment-proof>

{
  "agentId": "agent_01",
  "agentWallet": "0xAgentWallet...",
  "token": "0xTokenAddress...",
  "side": "buy",
  "amount": "100000",
  "limitPrice": "0.0042",
  "settlementNetwork": "base",
  "privacyMode": "tee"
}

Verified request data

When verification succeeds, Sylphy attaches this payment context to the request.

req.x402

{
  "paid": true,
  "payer": "0xPayerWallet...",
  "txHash": "0xPaymentTx...",
  "amount": "$0.01",
  "asset": "USDC",
  "network": "eip155:8453"
}

Paid audit response

For GET /api/audit/:settlementId/agent, x402 verifies payment first. Authorization is still required before any audit summary is returned.

authorized audit response

{
  "ok": true,
  "auditSummary": {
    "settlement_id": "settle_123",
    "status": "settled",
    "settlement_tx": "0xabcd...",
    "tee_attestation": "valid",
    "proof_status": "valid",
    "risk_level": "low",
    "matched_result": {
      "token": "SYLPHY",
      "matched_price": "0.0042 USDC",
      "matched_amount": "100000 SYLPHY",
      "price_type": "clearing_price",
      "amount_type": "aggregated_total"
    },
    "private_fields": {
      "submitter_wallet": "hidden",
      "individual_trade_amount": "hidden",
      "individual_limit_price": "hidden",
      "full_audit_blob": "requires_regulator_access"
    },
    "payment_receipt_id": "rcpt_abc123...",
    "summary": "Settlement completed on Base. TEE proof is valid and no policy violation was detected."
  },
  "accessRole": "authorized_agent",
  "paymentReceiptId": "rcpt_abc123..."
}

Network and asset

Parameter	Value
Network	`eip155:8453` — Base mainnet
Payment asset	USDC
USDC contract	`0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913`
Scheme	`exact` payment authorization
Headers	`X-PAYMENT` or `X-PAYMENT-SIGNATURE`
Facilitator	`payai.network` verifies and settles payment proofs

Boundary

x402 unlocks endpoint execution only. Audit routes still require authorization, and final settlement remains visible on Base.

x402 Payment

Pricing

The Sylphy app is free to use. External API clients and AI agents pay per request in USDC on Base.

Paid routes

Endpoint	Method	Price	Purpose
`/api/token/:address`	GET	$0.01	Resolve ERC-20 token info on Base
`/api/intent`	POST	$0.01	Submit a private trade intent
`/api/market-depth/:token`	GET	$0.01	Read aggregated, anonymized depth
`/api/match-status/:id`	GET	$0.01	Check intent status with authorization
`/api/intents/trade`	POST	$0.01	Submit a policy-bound AI agent intent
`/api/swap`	POST	$0.02	Instant DEX swap via Uniswap V2 **
`/api/audit/:settlementId/agent`	GET	$0.25	Read an AI-safe audit summary with authorization

Free routes

/health, /api/fees, and free admin or registration routes do not require x402 payment. The Sylphy app also bypasses API billing.

Using Sylphy

Settlement

Settlement is the final on-chain result. Sylphy does not hide settlement; it protects the execution context around it.

Visibility model

Public on Base

Wallet address involved in settlement

Token transfer and amount where emitted on-chain

Transaction hash and block timestamp

Network confirmation

x402 payment transaction metadata

Protected by Sylphy

Intent payload and strategy context

Internal matching route

Policy evaluation details

TEE execution metadata

Encrypted audit proof contents

Using Sylphy

Instant Swap

Agents and API clients can run instant swaps against Uniswap V2 liquidity on Base through SylphySettlement.

Swap execution context

Instant swaps are routed directly to public AMM liquidity. They are faster, but their swap details are public on-chain.

Swap vs OTC intent

Choose the path that fits the trade: instant AMM liquidity or private intent execution with limit-price control.

Feature	`POST /api/swap` (Instant Swap)	`POST /api/intents/trade` (OTC Intent)
Execution	Instant (DEX router)	Async (TEE matching queue)
Counterparty	Uniswap V2 liquidity pool	Private OTC peer
Privacy	On-chain (public tx)	Private inside TEE
Price	Market price (AMM)	Limit price (agent sets)
x402 fee	$0.02 USDC	$0.01 USDC
Best for	Speed, immediate liquidity	Privacy, large trade blocks

Swap lifecycle

1

Submit swap request

The agent sends a swap payload to POST /api/swap with an X-PAYMENT header.

2

Verify and quote

The backend verifies payment and authorization, then requests a pool routing quote.

3

Contract execution

Sylphy routes the trade through SylphySettlement.sol to the Uniswap V2 router.

4

Token transfer and fee

Tokens are exchanged, the swap fee is sent to treasury, and proceeds land in the recipient wallet.

5

Receipt delivery

The API returns the swapId, Base transaction hash, and output amount.

Example Request

submit swap

POST /api/swap
Content-Type: application/json
X-PAYMENT: <base64-encoded-payment-proof>

{
  "agentId": "agent_sylphy_01",
  "tokenIn": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913", // USDC
  "tokenOut": "0x4200000000000000000000000000000000000006", // WETH
  "amountIn": "1000000", // 1.00 USDC (6 decimals)
  "minAmountOut": "300000000000000", // Minimum slippage tolerance
  "recipient": "0xAgentWallet..."
}

Example Response

swap completed

{
  "ok": true,
  "swapId": "swap_9f2b...",
  "status": "executed",
  "txHash": "0xSwapTxHash...",
  "tokenIn": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
  "tokenOut": "0x4200000000000000000000000000000000000006",
  "amountIn": "1000000",
  "amountOut": "312500000000000",
  "feeDeducted": "3000", // 0.3% swap fee
  "recipient": "0xAgentWallet..."
}

Using Sylphy

Private Execution Context

Private execution context is the protected layer around settlement: request details, matching path, policy checks, and proof output.

What is protected

Intent

Token, side, amount, price, expiry, and preview hash.

Matching path

Counterparty discovery, order pairing, and clearing-price logic.

Policy checks

Authorization, allowlists, trade limits, and slippage rules.

Timing context

Queue time, match time, expiry, and ordering metadata used during execution.

TEE attestation

Evidence that the expected enclave code processed the request.

Audit payload

Encrypted proof details available only through authorized review paths.

Using Sylphy

Audit Trail

Sylphy separates payment from permission. Payment funds the request; authorization decides who can read the result.

Access levels

Users can view their own settlement status and public transaction hash.

AI agents can request AI-safe summaries when they are registered and authorized for the relevant resource.

Reviewers can access deeper proof context only through permissioned roles such as auditor or regulator.

AI-safe means scoped

Audit summaries can include status, settlement transaction, proof state, risk level, aggregate match result, and receipt ID. They do not expose individual wallets, order amounts, limit prices, or the full audit blob.

Audit summary response

Authorized agents receive a scoped summary object in auditSummary, plus the access receipt at the top level.

GET /api/audit/:settlementId/agent response

{
  "ok": true,
  "auditSummary": {
    "settlement_id": "settle_123",
    "status": "settled",
    "settlement_tx": "0xabcd...",
    "tee_attestation": "valid",
    "proof_status": "valid",
    "risk_level": "low",
    "matched_result": {
      "token": "SYLPHY",
      "matched_price": "0.0042 USDC",
      "matched_amount": "100000 SYLPHY",
      "matched_notional": "420 USDC",
      "price_type": "clearing_price",
      "amount_type": "aggregated_total"
    },
    "private_fields": {
      "submitter_wallet": "hidden",
      "individual_trade_amount": "hidden",
      "individual_limit_price": "hidden",
      "buyer_wallet": "hidden",
      "seller_wallet": "hidden",
      "full_audit_blob": "requires_regulator_access"
    },
    "payment_receipt_id": "rcpt_abc123...",
    "summary": "Settlement completed on Base. 100000 SYLPHY was matched at 0.0042 USDC. TEE proof is valid and no policy violation was detected."
  },
  "accessRole": "authorized_agent",
  "paymentReceiptId": "rcpt_abc123..."
}

Using Sylphy

Wallet-based Users

Sylphy uses wallets as the account boundary. The connected address signs intents, pays when needed, and anchors authorization.

Wallet model

There is no email or password flow in the core protocol. A wallet can submit intents, register agents, pay x402 requirements, and request authorized resources.

Architecture

System Architecture

Sylphy combines protected execution, x402 access, and Base settlement for private DeFi workflows.

End-to-end execution flow

Sylphy separates private execution from public settlement. Each layer protects intent context while keeping the final state change verifiable on Base.

1

Wallet or agent request

A wallet, app, or agent submits an execution intent.

2

x402 payment gate

Paid API routes require a valid USDC payment proof. The Sylphy app bypasses API billing.

3

Authorization and policy

Sylphy checks permissions, slippage bounds, token allowlists, and trade limits.

4

TEE matching

Matching and clearing run inside a protected execution environment.

5

Settlement on Base

The verified result is sent to the settlement contract and executed on-chain.

6

Audit trail

Proof metadata and policy outcomes are stored for authorized review.

TEE execution layer

Orders are processed inside a protected execution environment. This keeps the active matching context away from the public mempool and ordinary application memory.

After an intent is matched or rejected, Sylphy records proof metadata that links the private execution path to the public settlement result.

TEE execution receipt

{
  "enclaveId": "sylphy_sec_enclave_8453",
  "teeAttestationSignature": "0x9b3a...f78e",
  "intentHash": "0xintent_digest...",
  "matchingClearingPrice": "cleared_inside_enclave",
  "policyVerification": "verified_and_passed"
}

Proofs and commitments

Sylphy records proof metadata so settlement can be checked without exposing the full execution context. Public chain data shows the final result; private proof data remains scoped to authorized review.

Scoped auditing

Sylphy is not an anonymity system. It uses permissioned disclosure so approved reviewers can inspect deeper proof context when required.

Audit access is logged and separated from x402 payment. A paid request can still be denied if the caller is not authorized.

Reference

API Reference

Sylphy exposes HTTP endpoints for token data, private intents, market depth, match status, agent access, swaps, and audit summaries.

Endpoint groups

System

GET

/health

Checks API health, chain status, and x402 status. This route is free.

GET

/api/fees

Returns fee configuration and x402 route pricing. This route is free.

Token data

GET

/api/token/:address

Resolves ERC-20 metadata for a Base token contract, including name, symbol, decimals, and support status.

Intent execution

POST

/api/intent

Wallet intent endpoint. Requires tokenAddress, side, amount, price, and walletAddress; returns a pending private intent.

POST

/api/intents/trade

Registered agent trade endpoint. Requires x402 payment, authorization, policy checks, and a valid trade payload.

POST

/api/swap

Instant DEX swap endpoint. Requires x402 payment and agent authorization. Swaps execute against Uniswap V2 pools through SylphySettlement.

Market and status

GET

/api/market-depth/:token

Returns aggregated market depth for a token. Individual orders and wallets remain confidential.

GET

/api/match-status/:id

Returns intent status. Paid external callers must also be authorized.

Agent and audit

POST

/api/agents/register

Registers an agent wallet with owner, permissions, and policy limits.

GET

/api/audit/:settlementId/agent

Returns a scoped audit summary. x402 funds the request; authorization controls access.

Examples

submit intent

const response = await fetch("https://api.sylphy.xyz/api/intent", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    "X-PAYMENT": paymentProof
  },
  body: JSON.stringify({
    tokenAddress: "0xToken...",
    side: "buy",
    amount: "100",
    price: "0.0042",
    walletAddress: "0xWallet..."
  })
});

const data = await response.json();

Reference

Frequently Asked Questions

What problem does Sylphy solve? +

Sylphy lets wallets, apps, and agents submit trade intents without exposing the full execution context. The final Base transaction remains verifiable.

Why does Sylphy use x402? +

x402 lets external clients pay per request with a wallet-signed USDC payment instead of API keys or subscriptions.

Are browser users charged x402 fees? +

No. The Sylphy app bypasses x402 API billing. External API clients and AI agents pay per request.

Is Sylphy anonymous? +

No. Sylphy is wallet-based. It does not hide final settlement, wallet activity, transaction hashes, or x402 payment records on Base.

What stays private? +

Intent payloads, matching path, policy results, timing context, TEE metadata, and audit details stay protected.

Can payment alone unlock audit data? +

No. Audit endpoints require both x402 payment and authorization. Unauthorized requests can be paid but still denied.

Which network does Sylphy use? +

Sylphy targets Base mainnet, chain ID 8453. x402 payments use USDC on Base.

Can AI agents submit trades? +

Yes. Registered agents can submit trade intents through /api/intents/trade after payment, authorization, and policy checks pass.