Relay

The AgentSwap relay submits transactions on behalf of users and agents. Its primary onboarding function is sponsoring the deployment of a user’s execution proxy (UserProxyV6) through POST /api/proxy.

Sponsoring a first intent

Before a user can submit an intent, their execution proxy must exist on-chain to handle trade settlement and token routing.

Without a relay, an onboarding user without a deployed proxy must sign and pay for two separate wallet transactions:

1. Direct contract deployment via UserProxyFactoryV6.deploy(owner).
2. An ERC-20 token approval to the predicted proxy address.

With the relay, POST /api/proxy sponsors the proxy deployment. The relay broadcasts the factory deployment transaction and covers the gas fee. The user signs only the token approval from their wallet. A first intent requires one wallet prompt.

Trust and allowance boundary

The proxy is the owner’s own contract:

• UserProxyFactoryV6 deploys a minimal clone whose address derives from the owner; the owner is fixed permanently to the user.
• The relay never holds an allowance. Token approvals are granted exclusively to the owner’s own proxy; there is no Permit2 in this flow.
• The relay possesses no administrative rights, sweep functions, or withdrawal authority over the proxy.
• The relay cannot pull user tokens or alter execution routes.

Base URL

https://app.agentswap.co

Public HTTP contract

POST /api/proxy

Request a sponsored deployment for an owner proxy on a supported chain.

Request body

{
  "chainId": 8453,
  "owner": "0x1111111111111111111111111111111111111111",
  "tokenIn": "0x2222222222222222222222222222222222222222",
  "amountIn": "1000000"
}

Field	Type	Description
chainId	integer	Target EVM chain ID (e.g. 8453, 42161, 4663, 56).
owner	string	The 0x address that will own the deployed proxy.
tokenIn	string	The 0x ERC-20 token address intended for the swap.
amountIn	string | number	The intended trade input amount in atomic integer units.

Successful responses

When a new proxy is deployed:

{
  "txHash": "0x...",
  "proxy": "0x..."
}

When the owner already has a deployed proxy on this chain:

{
  "proxy": "0x...",
  "existing": true
}

When a deployment transaction already exists for this proxy:

{
  "txHash": "0x...",
  "proxy": "0x..."
}

Relay availability

POST /api/proxy evaluates the proxy state, requested token balances, deployment simulation, relay availability, and rate limits before it broadcasts a deployment. The endpoint may reject a request when any required condition fails.

If the owner already has a proxy, or if a deployment transaction already exists for this proxy, the endpoint can return the existing or transaction details instead of broadcasting another deployment. Treat any non-success response or network failure as relay unavailability and use the wallet deployment path.

Fallback and client behavior

Client applications implement clear fallback paths to guarantee that relay failures do not block user execution:

• Fallback to wallet deployment: If POST /api/proxy returns an error status (such as HTTP 400, 429, 502, or 503) or encounters a network failure, the client falls back to requesting a direct factory.deploy(owner) transaction signed by the user’s wallet.
• Unconfirmed deployments: If a sponsored deployment transaction is broadcast but does not confirm within the expected interval, the interface returns to the deploy prompt with the refusal reason. It does not advance to an allowance prompt that would fail against an undeployed address.
• Servability checks: Clients query relay servability (e.g. through GET /api/intents). If a chain is unservable due to RPC degradation or depleted relayer funds, the client bypasses the relay and offers direct wallet deployment immediately.