vurto.cc

Vurto Swap — token swaps at the best net price on 9 EVM chains (Ethereum, Optimism, BNB Chain, Gnosis, Polygon, Base, Arbitrum One, Avalanche, Unichain) across Velora, KyberSwap, 1inch, CoW Protocol and the direct pools Uniswap, SushiSwap, PancakeSwap, Aerodrome and QuickSwap, plus `composto`, a two-hop route that crosses two of those pools inside one transaction, and on Solana across Jupiter (router), Raydium, Orca and Meteora. ONE set of tools, two networks: pick the engine with chainId — an integer for EVM, the string "solana-mainnet" for Solana. Everything else is the same vocabulary. Solana addresses are base58 and CASE-SENSITIVE: lowercasing a mint gives a different, non-existent address, and it is the single most common way to break a Solana call. Solana differs in exactly four places, and nowhere else. chainId is the string "solana-mainnet". There is no approve, so a build has one transaction and never a steps[] array. Signing uses a Solana key, so prepare_signing returns a different signer. And status is asked of the network by signature, not of a stored execution by id. ALWAYS USE THE LATEST: re-read these tool descriptions each session and fetch the live guide at https://swap.vurto.cc/agent-api.md — never a cached/older copy; if a cached doc disagrees, the live surface wins. A quote lives 10-12 seconds. Quoting, thinking for a minute, then building does not work — call swap_build directly when you intend to execute; it quotes and builds in one round trip. Only call swap_quote first if you need to compare routes without committing to one. Sign steps[] in the order given, with one prepare_signing call for each step. approve is exact, never infinite, by product decision; send it, do not report it as the swap execution, then rebuild before signing the transaction step. A CoW ERC-20 order (steps[].type === "signature") has no transaction hash — only a uid, from report_execution. A CoW ETH-flow order (selling the chain native asset) DOES send a transaction, but a successful receipt only means the order was registered — the solver fills it later, or never. Call swap_status before telling the user the swap succeeded; do not treat a receipt as proof for either case. If swap_status comes back order_expired_refundable, the funds are stuck in a contract, not lost — call the refund flow pointed to in that response (POST /v1/ethflow/refund) instead of telling the user to give up on them. Building a liquidity pool or matching a ratio between exactly two legs? Use double_quote/double_build instead of two separate swap_quote/swap_build calls: "out" prices one source token split into two destinations, "in" prices two source tokens converging on one destination, both legs against the same instant of the market. The two legs are NOT atomic — execute leg A fully (sign, send, report_execution, confirm) before touching leg B, and do not start leg B if leg A failed or was rejected. More than two legs on either side, or a basket where inputs and outputs are matched by value share rather than a fixed amount you already know? Use nn_quote/nn_build ("N:N"): N input tokens fund M output tokens in ONE atomic on-chain transaction, backend-allocated by value (waterfall) — unlike double_quote/double_build, the resulting nn_build transaction IS atomic across every leg. report_execution/swap_status do not work for an nn_build transaction (no single quoteId to key off) — confirm it via the transaction receipt directly. On Solana a signature is not proof: the wallet returns it at send time, and until the network confirms it the transaction can still be dropped, or expire past lastValidBlockHeight without ever having existed. Call swap_status with the signature before telling the user it worked. RPC per chain: https://rpc.vurto.cc/<slug> — see the slugs in GET /v1/chains, they are the same for every chain here. Never ask for, accept, or repeat a private key in chat, under any circumstance.