Vurto Swap

io.github.cryptoconspiracy/vurto-swapVersion 1.0.0

Token swaps at the best net price on 9 EVM chains and Solana. No API key, non-custodial.

Status

Responds303 msNov 14, 2026, 14:48 UTCAnswered our handshake without sign-in.

Registry data may be out of date

We could not refresh it, so this page shows the last copy.

Last checked: Nov 14, 2026, 14:48 UTC
Latency: 303 ms
Remotes responding: 1 of 1
Sign-in: No sign-in
Hosting: Hosted outside the EU (detected)
Registry data as of: Nov 14, 2026, 22:14 UTC

Data from the official MCP Registry, checked by run.zero. How we check

Connect

Streamable HTTP

https://swap.vurto.cc/mcpResponds303 msNov 14, 2026, 14:48 UTC

No sign-in

Claude Code

claude mcp add --transport http vurto-swap https://swap.vurto.cc/mcp

Claude Desktop and claude.ai

1
2
3

Settings > Connectors > Add custom connector
Name: vurto-swap
Remote MCP server URL: https://swap.vurto.cc/mcp

Cursor

{
  "mcpServers": {
    "vurto-swap": {
      "url": "https://swap.vurto.cc/mcp"
    }
  }
}

VS Code

code --add-mcp '{"name":"vurto-swap","type":"http","url":"https://swap.vurto.cc/mcp"}'

Built your own server? run.zero hosts MCP servers on European infrastructure.

Host your own MCP server on run.zero

Tools

32 tools

Tools of Vurto Swap
	Description		Read-only	Idempotent	Open world
`check_access`The Check access of a paying wallet, the proof check_credits asks for (access), valid 24 hours. Hand here the signature of check_access_challenge with its nonce and message, unchanged. The challenge is consumed here, once, so the access goes only to whoever holds that signature: keep it secret, it lists this payer's Checks. A challenge of another kind (destination_challenge, the claim of another charge) is refused with check_access_challenge_invalid. Returns { access, payer, expiresAt }.	The Check access of a paying wallet, the proof check_credits asks for (access), valid 24 hours. Hand here the signature of check_access_challenge with its nonce and message, unchanged. The challenge is consumed here, once, so the access goes only to whoever holds that signature: keep it secret, it lists this payer's Checks. A challenge of another kind (destination_challenge, the claim of another charge) is refused with check_access_challenge_invalid. Returns { access, payer, expiresAt }.	No	No	No	No
`check_access_challenge`Only for check_credits (listing a payer's Checks by wallet); paying, analysing and reading one Check need only its id. The challenge of the Check access, of its own: the text says what the signature grants (read and use the paid Checks of this wallet for 24 hours), the site and until when to sign, and that it moves no funds and authorizes no destination. chainId is any network check_info lists: on EVM it is the domain of typedData, on Solana it gives proofTransaction. Returns { nonce, message, expiresAt, buildId (check-access-<nonce>), typedData (EVM) \| proofTransaction (Solana) }. Sign it with prepare_signing (EVM: a signature step with typedData; Solana: the proofTransaction, never sent), then call check_access. Never use destination_challenge or destination_authorize for the Check: they do not give an access.	Only for check_credits (listing a payer's Checks by wallet); paying, analysing and reading one Check need only its id. The challenge of the Check access, of its own: the text says what the signature grants (read and use the paid Checks of this wallet for 24 hours), the site and until when to sign, and that it moves no funds and authorizes no destination. chainId is any network check_info lists: on EVM it is the domain of typedData, on Solana it gives proofTransaction. Returns { nonce, message, expiresAt, buildId (check-access-<nonce>), typedData (EVM) \| proofTransaction (Solana) }. Sign it with prepare_signing (EVM: a signature step with typedData; Solana: the proofTransaction, never sent), then call check_access. Never use destination_challenge or destination_authorize for the Check: they do not give an access.	No	No	No	No
`check_analyze`Spends ONE paid credit on the networks it paid: evmWallet on the EVM networks paid, solanaWallet on Solana if it was paid. Give a wallet for each family the credit paid (check_wallet_missing otherwise) and none for a family it did not (check_family_not_paid). The free screening (OFAC SDN, issuer freeze) and Scorechain read each wallet once, Merkle Science (through Didit) once per network, at most the networks paid plus 2 lookups in all. Returns check with status used, target { wallets { evm, svm }, networks }, seal (the worst network: red, risk found; yellow, medium risk; grey, a paid reading did not come back; green, no risk, Merkle no_data included), result and screening (of the worst network), networks [{ chainId, seal, result { verdict, risk, tools [{ tool, result clear\|flagged\|unavailable, score 0-100, severity, summary, category, factors, sourceOfFunds, destinationOfFunds, analyzedAt, fromHistory }], details }, screening }] and events (the real steps, with ms). The same credit and the same wallets again answers what is stored, with no provider call; other wallets are check_credit_used (409). Two calls at once run ONE analysis (the other gets check_running, 409). check_unreadable (503): a reading did not answer, the credit is still valid, call again with the same arguments (details.missing names tool:network). analysis_tool_unavailable (503): a tool is down and the credit was not touched.	Spends ONE paid credit on the networks it paid: evmWallet on the EVM networks paid, solanaWallet on Solana if it was paid. Give a wallet for each family the credit paid (check_wallet_missing otherwise) and none for a family it did not (check_family_not_paid). The free screening (OFAC SDN, issuer freeze) and Scorechain read each wallet once, Merkle Science (through Didit) once per network, at most the networks paid plus 2 lookups in all. Returns check with status used, target { wallets { evm, svm }, networks }, seal (the worst network: red, risk found; yellow, medium risk; grey, a paid reading did not come back; green, no risk, Merkle no_data included), result and screening (of the worst network), networks [{ chainId, seal, result { verdict, risk, tools [{ tool, result clear\|flagged\|unavailable, score 0-100, severity, summary, category, factors, sourceOfFunds, destinationOfFunds, analyzedAt, fromHistory }], details }, screening }] and events (the real steps, with ms). The same credit and the same wallets again answers what is stored, with no provider call; other wallets are check_credit_used (409). Two calls at once run ONE analysis (the other gets check_running, 409). check_unreadable (503): a reading did not answer, the credit is still valid, call again with the same arguments (details.missing names tool:network). analysis_tool_unavailable (503): a tool is down and the credit was not touched.	No	No	Yes	Yes
`check_buy_challenge`Step one of buying a Check (owner, 12/11/2026: only a wallet that passes the free screening buys, so it signs first). The challenge of its own, scope buy: the text says this wallet pays for a Check and is screened before buying, valid 10 minutes, and that it moves no funds and authorizes no destination. chainId is any network check_info lists. Returns { nonce, message, expiresAt, buildId (check-buy-<nonce>), typedData (EVM) \| proofTransaction (Solana) }. Sign it with prepare_signing, then call check_buy_proof.	Step one of buying a Check (owner, 12/11/2026: only a wallet that passes the free screening buys, so it signs first). The challenge of its own, scope buy: the text says this wallet pays for a Check and is screened before buying, valid 10 minutes, and that it moves no funds and authorizes no destination. chainId is any network check_info lists. Returns { nonce, message, expiresAt, buildId (check-buy-<nonce>), typedData (EVM) \| proofTransaction (Solana) }. Sign it with prepare_signing, then call check_buy_proof.	No	No	No	No
`check_buy_proof`Hand here the signature of check_buy_challenge with its nonce and message, unchanged. The challenge is consumed once, the wallet goes through the free screening (OFAC, issuer freezes), and only if it passes it returns { buyProof (vcb_..., 10 minutes, secret), payer, screening: passed, expiresAt }. A blocked wallet gets payer_blocked (403). A challenge of another kind (check_access_challenge, destination_challenge) is refused with check_buy_challenge_invalid. Pass buyProof to check_charge.	Hand here the signature of check_buy_challenge with its nonce and message, unchanged. The challenge is consumed once, the wallet goes through the free screening (OFAC, issuer freezes), and only if it passes it returns { buyProof (vcb_..., 10 minutes, secret), payer, screening: passed, expiresAt }. A blocked wallet gets payer_blocked (403). A challenge of another kind (check_access_challenge, destination_challenge) is refused with check_buy_challenge_invalid. Pass buyProof to check_charge.	No	No	No	Yes
`check_charge`Builds the USDC transfer of the Check price for the networks chosen (networks, from check_info checkNetworks: perNetwork each, never above maximum) from payer to the analysis fee wallet on chainId (any network of check_info networks), for the payer to sign. The credit is bound to those networks. Needs buyProof, the purchase proof of THIS payer from check_buy_proof (the payer signed and passed the free screening); without it, or with another wallet's, check_buy_proof_required (401). The server also measures the sender on-chain. Returns { check { id, status awaiting_payment, amount, amountRaw, token, feeWallet }, transaction, plan (buildId check-<id>, steps on EVM or transaction on Solana), report }. check.id (CHK-...) is the capability of this Check: whoever holds it reports the payment, analyses and reads the result, so keep it private and keep it to come back to the result. Each call makes a NEW Check, good for 30 minutes (expiresAt): a transaction mined after that is credited by the price of now on the networks it covers (check_report_payment). Pass checkId of one still awaiting payment and in its time to rebuild its transfer (the Solana one expires in about a minute). Sign the transaction exactly as returned: it carries the mark of THIS Check (16 bytes after the transfer arguments on EVM, a memo on Solana). A transfer you build yourself is refused with analysis_payment_rejected reason charge_not_tied after the money left: do not pay again, prove the wallet with destination_challenge (receiver = details.feeWallet, chargeId = the check id, chargeTxHash = that hash) and destination_authorize, then report the same hash again. Refusals: analysis_tool_unavailable (503, a tool is down: nothing is built), check_credit_limit (409), payer_blocked (403), check_network_unsupported (400), check_networks_required (400), check_already_paid (409, checkId of a paid Check), check_charge_expired (409), check_unavailable (503).	Builds the USDC transfer of the Check price for the networks chosen (networks, from check_info checkNetworks: perNetwork each, never above maximum) from payer to the analysis fee wallet on chainId (any network of check_info networks), for the payer to sign. The credit is bound to those networks. Needs buyProof, the purchase proof of THIS payer from check_buy_proof (the payer signed and passed the free screening); without it, or with another wallet's, check_buy_proof_required (401). The server also measures the sender on-chain. Returns { check { id, status awaiting_payment, amount, amountRaw, token, feeWallet }, transaction, plan (buildId check-<id>, steps on EVM or transaction on Solana), report }. check.id (CHK-...) is the capability of this Check: whoever holds it reports the payment, analyses and reads the result, so keep it private and keep it to come back to the result. Each call makes a NEW Check, good for 30 minutes (expiresAt): a transaction mined after that is credited by the price of now on the networks it covers (check_report_payment). Pass checkId of one still awaiting payment and in its time to rebuild its transfer (the Solana one expires in about a minute). Sign the transaction exactly as returned: it carries the mark of THIS Check (16 bytes after the transfer arguments on EVM, a memo on Solana). A transfer you build yourself is refused with analysis_payment_rejected reason charge_not_tied after the money left: do not pay again, prove the wallet with destination_challenge (receiver = details.feeWallet, chargeId = the check id, chargeTxHash = that hash) and destination_authorize, then report the same hash again. Refusals: analysis_tool_unavailable (503, a tool is down: nothing is built), check_credit_limit (409), payer_blocked (403), check_network_unsupported (400), check_networks_required (400), check_already_paid (409, checkId of a paid Check), check_charge_expired (409), check_unavailable (503).	No	No	No	Yes
`check_credits`The paid Checks of a paying wallet, newest first, 50 a page with nextCursor: unused credits (status paid), a reading in flight or interrupted (status running: call check_analyze again with its target to resume) and the analyses already run (status used, with target and seal), to find a Check id you lost. The one check_* tool that reads by wallet, so the one that needs access, the Check access of this payer (check_access_challenge, then check_access).	The paid Checks of a paying wallet, newest first, 50 a page with nextCursor: unused credits (status paid), a reading in flight or interrupted (status running: call check_analyze again with its target to resume) and the analyses already run (status used, with target and seal), to find a Check id you lost. The one check_* tool that reads by wallet, so the one that needs access, the Check access of this payer (check_access_challenge, then check_access).	No	Yes	Yes	No
`check_info`The paid Check of any wallet: price { maximum (dollars, one system variable, 1.99), perNetwork (the maximum divided by 6, down to the cent: 0.33), amount (= maximum, for older clients), currency }; the price of a Check is perNetwork times the networks chosen, never above maximum. checkNetworks [{ chainId, family }] (the seven to choose: 1, 10, 56, 137, 8453, 42161, solana-mainnet), networks [{ chainId, family, token (the USDC that pays), feeWallet }] (where it is paid: the nine EVM networks and solana-mainnet), creditLimit and chargeValidSeconds (1800). Public, no proof needed.	The paid Check of any wallet: price { maximum (dollars, one system variable, 1.99), perNetwork (the maximum divided by 6, down to the cent: 0.33), amount (= maximum, for older clients), currency }; the price of a Check is perNetwork times the networks chosen, never above maximum. checkNetworks [{ chainId, family }] (the seven to choose: 1, 10, 56, 137, 8453, 42161, solana-mainnet), networks [{ chainId, family, token (the USDC that pays), feeWallet }] (where it is paid: the nine EVM networks and solana-mainnet), creditLimit and chargeValidSeconds (1800). Public, no proof needed.	No	Yes	Yes	No
`check_report_payment`Hand the Check payment to the server once it is mined, by the Check id. The server reads it on-chain (the payer the charge names signed it, the network USDC reached the fee wallet, at least the price, after the charge, the mark) and reserves the hash for this Check only. 201 with check.status paid: the credit exists. analysis_payment_pending (409): not mined yet, call again in a few seconds. analysis_payment_rejected (400, details.reason): this transaction does not pay this Check. tx_already_used (409): the hash already paid something else. check_not_found (404): no Check has this id. Mined after the charge's 30 minutes it still credits by the price of now on the networks it covers (lateCharge true, check.paidNetworks may be fewer); check_charge_expired (409) only when it covers none. check_credit_limit (409) and payer_blocked (403) are checked again here; nothing is reserved, so the same hash reported later still counts. Repeating the same hash is safe; never pay again.	Hand the Check payment to the server once it is mined, by the Check id. The server reads it on-chain (the payer the charge names signed it, the network USDC reached the fee wallet, at least the price, after the charge, the mark) and reserves the hash for this Check only. 201 with check.status paid: the credit exists. analysis_payment_pending (409): not mined yet, call again in a few seconds. analysis_payment_rejected (400, details.reason): this transaction does not pay this Check. tx_already_used (409): the hash already paid something else. check_not_found (404): no Check has this id. Mined after the charge's 30 minutes it still credits by the price of now on the networks it covers (lateCharge true, check.paidNetworks may be fewer); check_charge_expired (409) only when it covers none. check_credit_limit (409) and payer_blocked (403) are checked again here; nothing is reserved, so the same hash reported later still counts. Repeating the same hash is safe; never pay again.	No	No	Yes	Yes
`check_result`Reads one Check by its id, as stored (status, target, seal, result, screening, networks, events). Never calls a paid provider. An unknown id gets check_not_found (404).	Reads one Check by its id, as stored (status, target, seal, result, screening, networks, events). Never calls a paid provider. An unknown id gets check_not_found (404).	No	Yes	Yes	No
`destination_authorize`Hand over the signature of destination_challenge. The server checks it is the paying wallet's signature over that exact challenge, for that receiver and chain, unexpired and unused, and then lets builds deliver to that receiver for 30 minutes. Nothing else unlocks it. Errors: signature_invalid, authorization_expired, authorization_replayed, authorization_destination_mismatch, authorization_network_mismatch.	Hand over the signature of destination_challenge. The server checks it is the paying wallet's signature over that exact challenge, for that receiver and chain, unexpired and unused, and then lets builds deliver to that receiver for 30 minutes. Nothing else unlocks it. Errors: signature_invalid, authorization_expired, authorization_replayed, authorization_destination_mismatch, authorization_network_mismatch.	No	No	No	Yes
`destination_challenge`Destination lock. A receiver different from the signing wallet is refused by swap_build, double_build and nn_build (403 destination_not_authorized) until the paying wallet signs an authorization for that exact address on that chain. This returns {nonce, message, expiresAt} plus, on EVM, typedData (EIP-712, the same fields) and, on Solana, proofTransaction (a memo that can never land, for Ledger). Show the user the full receiver and network and get their explicit yes; then sign: on EVM call prepare_signing with step {type: "signature", typedData} and run it; on Solana sign message (or proofTransaction) with the wallet. Then call destination_authorize. Never sign this without the user asking to send to that address. Paying an invoice to its receiver does not unlock through this, but an invoice with payerChecks asks for the same proof of the paying wallet (payer_signature_required).	Destination lock. A receiver different from the signing wallet is refused by swap_build, double_build and nn_build (403 destination_not_authorized) until the paying wallet signs an authorization for that exact address on that chain. This returns {nonce, message, expiresAt} plus, on EVM, typedData (EIP-712, the same fields) and, on Solana, proofTransaction (a memo that can never land, for Ledger). Show the user the full receiver and network and get their explicit yes; then sign: on EVM call prepare_signing with step {type: "signature", typedData} and run it; on Solana sign message (or proofTransaction) with the wallet. Then call destination_authorize. Never sign this without the user asking to send to that address. Paying an invoice to its receiver does not unlock through this, but an invoice with payerChecks asks for the same proof of the paying wallet (payer_signature_required).	No	No	No	Yes
`double_build`Builds signable/sendable plans for BOTH legs of a Double Out or Double In swap — two ordinary swap_build calls under the hood, kept together for convenience. Returns { legA, legB }, each a full SwapPlan exactly like swap_build's. The two legs are NOT atomic — there is no combined contract call, each is a transaction (or CoW signature) the wallet sends separately, same as any other swap. Execute leg A fully first (steps, signing, report_execution) and confirm it landed before starting leg B. If leg A fails or is rejected, do NOT execute leg B — proceeding would leave the wallet with only half the ratio the user asked for, which defeats the purpose of a Double swap.	Builds signable/sendable plans for BOTH legs of a Double Out or Double In swap — two ordinary swap_build calls under the hood, kept together for convenience. Returns { legA, legB }, each a full SwapPlan exactly like swap_build's. The two legs are NOT atomic — there is no combined contract call, each is a transaction (or CoW signature) the wallet sends separately, same as any other swap. Execute leg A fully first (steps, signing, report_execution) and confirm it landed before starting leg B. If leg A fails or is rejected, do NOT execute leg B — proceeding would leave the wallet with only half the ratio the user asked for, which defeats the purpose of a Double swap.	No	No	No	Yes
`double_quote`Compares ranked routes for TWO swap legs at once — "Double Out" (one source token split into two destinations) or "Double In" (two source tokens converging on one destination). This exists because building a liquidity pool or matching a target ratio needs both legs priced against the market at the same instant, not one after another with the price moving in between. Each leg is independently quoted (two ordinary swap_quote calls under the hood) — this tool is a convenience that keeps them together, not a combined/atomic route. For mode "out": legA.tokenIn must equal legB.tokenIn (the shared source); tokenOut differs. For mode "in": legA.tokenOut must equal legB.tokenOut (the shared destination); tokenIn differs. Pass the exact amount each leg should trade — this tool does not compute percentages or splits for you. If the shared token is the chain's native asset, remember gas is paid twice (once per leg's eventual transaction) — do not quote/build a total that leaves nothing for the second leg's gas.	Compares ranked routes for TWO swap legs at once — "Double Out" (one source token split into two destinations) or "Double In" (two source tokens converging on one destination). This exists because building a liquidity pool or matching a target ratio needs both legs priced against the market at the same instant, not one after another with the price moving in between. Each leg is independently quoted (two ordinary swap_quote calls under the hood) — this tool is a convenience that keeps them together, not a combined/atomic route. For mode "out": legA.tokenIn must equal legB.tokenIn (the shared source); tokenOut differs. For mode "in": legA.tokenOut must equal legB.tokenOut (the shared destination); tokenIn differs. Pass the exact amount each leg should trade — this tool does not compute percentages or splits for you. If the shared token is the chain's native asset, remember gas is paid twice (once per leg's eventual transaction) — do not quote/build a total that leaves nothing for the second leg's gas.	No	Yes	No	Yes
`invoice_analysis_pay`Do not use it on an invoice whose split.rule is "brackets" (created since 10/11/2026): its fee is inside the payment and already pays the analysis of both wallets, and the call is refused with analysis_included_in_fee (409). Without checks: the charge of the invoice creator, for an older invoice with payerChecks or paid checks whose analysis.status is awaiting_payment (see invoice_get). Builds ONE USDC transfer of analysis.amount (the price written when that invoice was created: 0.10 Scorechain, 0.40 Merkle Science, 0.50 both) to the Vurto fee wallet (analysis.to), signed by the invoice creator. Sign the charge transaction exactly as returned: it carries the mark that ties the payment to this charge (16 bytes after the transfer arguments on EVM, a memo on Solana). A transfer you build yourself is refused with analysis_payment_rejected, reason charge_not_tied, after the money has left; do not pay again, prove the wallet (destination_challenge with wallet = payer, receiver = details.feeWallet, chargeId = this charge and chargeTxHash = that hash, then destination_authorize) and report the same hash again. Nothing is signed or sent here. The free screening runs first on the receiving wallet and on the creator: a rejected wallet gets screening_blocked (403) and nothing is built; a screening that cannot be read gets screening_unavailable (503). payer must be the creator (the receiving wallet when the invoice was created without a session, which is always the case over MCP); any other wallet gets not_invoice_creator (403) before anything is built. plan has the same shape as invoice_pay (prepare_signing; on Solana POST the signed transaction to /v1/svm/execute), then call invoice_report_analysis_payment with the hash or signature. Paying it from another token is a swap built over the HTTP API (POST /v1/swap on EVM, POST /v1/svm/swap on Solana) from the creator wallet with tokenOut = analysis.token, receiver = analysis.to and invoiceId = this invoice, sized so the guaranteed	Do not use it on an invoice whose split.rule is "brackets" (created since 10/11/2026): its fee is inside the payment and already pays the analysis of both wallets, and the call is refused with analysis_included_in_fee (409). Without checks: the charge of the invoice creator, for an older invoice with payerChecks or paid checks whose analysis.status is awaiting_payment (see invoice_get). Builds ONE USDC transfer of analysis.amount (the price written when that invoice was created: 0.10 Scorechain, 0.40 Merkle Science, 0.50 both) to the Vurto fee wallet (analysis.to), signed by the invoice creator. Sign the charge transaction exactly as returned: it carries the mark that ties the payment to this charge (16 bytes after the transfer arguments on EVM, a memo on Solana). A transfer you build yourself is refused with analysis_payment_rejected, reason charge_not_tied, after the money has left; do not pay again, prove the wallet (destination_challenge with wallet = payer, receiver = details.feeWallet, chargeId = this charge and chargeTxHash = that hash, then destination_authorize) and report the same hash again. Nothing is signed or sent here. The free screening runs first on the receiving wallet and on the creator: a rejected wallet gets screening_blocked (403) and nothing is built; a screening that cannot be read gets screening_unavailable (503). payer must be the creator (the receiving wallet when the invoice was created without a session, which is always the case over MCP); any other wallet gets not_invoice_creator (403) before anything is built. plan has the same shape as invoice_pay (prepare_signing; on Solana POST the signed transaction to /v1/svm/execute), then call invoice_report_analysis_payment with the hash or signature. Paying it from another token is a swap built over the HTTP API (POST /v1/swap on EVM, POST /v1/svm/swap on Solana) from the creator wallet with tokenOut = analysis.token, receiver = analysis.to and invoiceId = this invoice, sized so the guaranteed	No	No	No	Yes
`invoice_create`Create a payment request: who receives, which token, how much, on which network. Returns invoice.id, invoice.label (INV-XXXX-XXXX, what people copy), invoice.url (share this, after paying the analysis charge if the invoice has one; it previews with the QR on WhatsApp and Telegram) and invoice.qr (PNG). No signature or API key needed. New invoices only receive VERIFIED dollar stablecoins on the network allowlist, even without paid analysis. A new invoice without payerChecks carries no fee; with payerChecks, the analysis fee of both wallets is deducted from the amount through the split (see payerChecks). Previously created invoices keep their terms. Tokens resolve by address or symbol — an unverified token is refused because a cloned "USDC" with its own pool would let the creator sell a fake at any price. The payer can pay with ANY token on that network. Paid checks in checks are closed for new invoices (paid_check_moved): use payerChecks. the free screening of the receiving wallet must pass for the invoice to be created (receiver_blocked 403, screening_unavailable 503), and payerChecks adds the paid analysis of both wallets, paid by the fee deducted from the amount.	Create a payment request: who receives, which token, how much, on which network. Returns invoice.id, invoice.label (INV-XXXX-XXXX, what people copy), invoice.url (share this, after paying the analysis charge if the invoice has one; it previews with the QR on WhatsApp and Telegram) and invoice.qr (PNG). No signature or API key needed. New invoices only receive VERIFIED dollar stablecoins on the network allowlist, even without paid analysis. A new invoice without payerChecks carries no fee; with payerChecks, the analysis fee of both wallets is deducted from the amount through the split (see payerChecks). Previously created invoices keep their terms. Tokens resolve by address or symbol — an unverified token is refused because a cloned "USDC" with its own pool would let the creator sell a fake at any price. The payer can pay with ANY token on that network. Paid checks in checks are closed for new invoices (paid_check_moved): use payerChecks. the free screening of the receiving wallet must pass for the invoice to be created (receiver_blocked 403, screening_unavailable 503), and payerChecks adds the paid analysis of both wallets, paid by the fee deducted from the amount.	No	No	No	Yes
`invoice_get`Read an invoice by id (INV-XXXX-XXXX, with or without dashes): requested amount, token, network, receiver, status (open or paid), the paying transaction once paid, and received (the raw amount measured on-chain so far). Pending payments are re-checked on-chain by the read, at most two per read and each at most every 15 seconds. checks lists the older paid screening of an invoice created before 07/11/2026 ([] for new ones), which paying runs on both wallets once analysis.status is paid; payerChecks lists the analysis of the paying wallet the receiver asked and paid for. receiverAnalysisFee, on an open invoice where the payer can buy the receiving wallet analysis (invoice_analysis_pay with checks): {available: true, amount} is the charge in dollars, the bracket fee of the invoice amount, or {available: false, minimum} when the amount is below the minimum and there is nothing to buy. For such an older invoice, analysis.report (Merkle Science only) carries, once the invoice is paid, the detail of both wallets; for payerChecks the result goes to the creator alone, on the site, and does not come here (over the web app, a signed session of the creator also sees the detail of the receiving wallet while it is open): score, severity, summary, main risk category, risk factors and sourceOfFunds (the largest origins of the money, up to 8, with category, entity, percentage, USD amount and direct or indirect exposure). confidential is true only on a private invoice created before 14/10/2026: its receiver reads null here, it can no longer be paid (invoice_pay answers private_invoice_paused), and its paying transaction, once paid, shows the receiver on-chain.	Read an invoice by id (INV-XXXX-XXXX, with or without dashes): requested amount, token, network, receiver, status (open or paid), the paying transaction once paid, and received (the raw amount measured on-chain so far). Pending payments are re-checked on-chain by the read, at most two per read and each at most every 15 seconds. checks lists the older paid screening of an invoice created before 07/11/2026 ([] for new ones), which paying runs on both wallets once analysis.status is paid; payerChecks lists the analysis of the paying wallet the receiver asked and paid for. receiverAnalysisFee, on an open invoice where the payer can buy the receiving wallet analysis (invoice_analysis_pay with checks): {available: true, amount} is the charge in dollars, the bracket fee of the invoice amount, or {available: false, minimum} when the amount is below the minimum and there is nothing to buy. For such an older invoice, analysis.report (Merkle Science only) carries, once the invoice is paid, the detail of both wallets; for payerChecks the result goes to the creator alone, on the site, and does not come here (over the web app, a signed session of the creator also sees the detail of the receiving wallet while it is open): score, severity, summary, main risk category, risk factors and sourceOfFunds (the largest origins of the money, up to 8, with category, entity, percentage, USD amount and direct or indirect exposure). confidential is true only on a private invoice created before 14/10/2026: its receiver reads null here, it can no longer be paid (invoice_pay answers private_invoice_paused), and its paying transaction, once paid, shows the receiver on-chain.	No	Yes	Yes	Yes
`invoice_pay`Build the plan to pay an invoice from payer, with the token payer holds (default: the invoice token). Nothing is signed or sent here. Both wallets are screened first (payer_blocked, receiver_blocked); when the invoice has checks ["scorechain"] (see invoice_get), the creator chose and paid the Scorechain sanctions API, so this call sends the payer wallet and the receiver wallet to Scorechain, a third party (an invoice created before 22/10/2026 with the then-free Scorechain keeps running it without a charge). method "transfer": same token, a direct transfer built from the stored invoice (no fee, no gain; the receiver sees the payer as sender). method "swap": another token; amountIn is computed so the GUARANTEED minimum output covers the requested amount, the route is always the one with GAIN when there is one, and the output goes straight to the receiver (the transaction is public and signed by the payer, so the receiver can see the paying wallet on-chain). Any surplus over the requested amount goes to the receiver. plan has the same shape as a swap_build plan: on EVM sign steps[] in order with prepare_signing (approve steps first, then the transaction); on Solana pass {transaction, executionRef} to prepare_signing and POST the signed transaction to /v1/svm/execute. If simulation.status is approval_required, send the approve and call invoice_pay again. When the invoice has paid checks, the creator must have paid the analysis first (analysis_unpaid, 409). With "merkle-science" this call then sends the payer wallet and the receiver wallet to Didit/Merkle Science, and a HIGH or CRITICAL risk (score 70 or more) refuses with payer_blocked or receiver_blocked; the detail shows in invoice_get analysis.report. At most 3 different payer wallets are analysed per invoice by each paid check; a 4th gets analysis_attempts_exceeded (429). Since 23/10/2026 the payer proves the wallet BEFORE the paid analysis runs on it: over MCP that proof is the destination authorization signed by t	Build the plan to pay an invoice from payer, with the token payer holds (default: the invoice token). Nothing is signed or sent here. Both wallets are screened first (payer_blocked, receiver_blocked); when the invoice has checks ["scorechain"] (see invoice_get), the creator chose and paid the Scorechain sanctions API, so this call sends the payer wallet and the receiver wallet to Scorechain, a third party (an invoice created before 22/10/2026 with the then-free Scorechain keeps running it without a charge). method "transfer": same token, a direct transfer built from the stored invoice (no fee, no gain; the receiver sees the payer as sender). method "swap": another token; amountIn is computed so the GUARANTEED minimum output covers the requested amount, the route is always the one with GAIN when there is one, and the output goes straight to the receiver (the transaction is public and signed by the payer, so the receiver can see the paying wallet on-chain). Any surplus over the requested amount goes to the receiver. plan has the same shape as a swap_build plan: on EVM sign steps[] in order with prepare_signing (approve steps first, then the transaction); on Solana pass {transaction, executionRef} to prepare_signing and POST the signed transaction to /v1/svm/execute. If simulation.status is approval_required, send the approve and call invoice_pay again. When the invoice has paid checks, the creator must have paid the analysis first (analysis_unpaid, 409). With "merkle-science" this call then sends the payer wallet and the receiver wallet to Didit/Merkle Science, and a HIGH or CRITICAL risk (score 70 or more) refuses with payer_blocked or receiver_blocked; the detail shows in invoice_get analysis.report. At most 3 different payer wallets are analysed per invoice by each paid check; a 4th gets analysis_attempts_exceeded (429). Since 23/10/2026 the payer proves the wallet BEFORE the paid analysis runs on it: over MCP that proof is the destination authorization signed by t	No	No	No	Yes
`invoice_report_analysis_payment`Hand the analysis payment transaction to the server once it is mined. The server reads it on-chain: a direct USDC transfer (the USDC of the invoice network) from the invoice creator to the Vurto fee wallet, of at least analysis.amount, newer than the invoice, never used for another analysis or invoice. screening_blocked (403): the free screening rejects the receiving wallet or the creator, and the payment is not registered. analysis_payment_pending (409): not mined yet, call again in a few seconds. analysis_payment_rejected (400) with details.reason (charge_not_tied, wrong_token, wrong_destination, amount_too_low, sender_not_creator, not_a_transfer, tx_reverted, tx_before_invoice): that transaction does not pay this analysis. charge_not_tied means it is not the transaction we built: do not pay again, prove the wallet (destination_challenge with receiver = details.feeWallet, chargeId = this invoice and chargeTxHash = that hash, then destination_authorize) and report the same hash again. Repeating a hash already recorded returns the status, and the stored result only with the receipt the first record returned (receiverAnalysis.receipt, sent back as receipt) or a proven wallet. tx_already_used (409): the hash already paid something else. Once paid, analysis.status is paid and the invoice can be paid. When the payer bought the analysis of the receiving wallet, pass payer too (the charge of the creator needs only txHash): the transaction must be signed by that payer and only the fee wallet may gain USDC in it (the split payment of an invoice never pays it, usdc_to_other_wallet); once paid the receiver analysis runs right away and receiverAnalysis.result comes back (verdict and the paid tools, never the receiving wallet).	Hand the analysis payment transaction to the server once it is mined. The server reads it on-chain: a direct USDC transfer (the USDC of the invoice network) from the invoice creator to the Vurto fee wallet, of at least analysis.amount, newer than the invoice, never used for another analysis or invoice. screening_blocked (403): the free screening rejects the receiving wallet or the creator, and the payment is not registered. analysis_payment_pending (409): not mined yet, call again in a few seconds. analysis_payment_rejected (400) with details.reason (charge_not_tied, wrong_token, wrong_destination, amount_too_low, sender_not_creator, not_a_transfer, tx_reverted, tx_before_invoice): that transaction does not pay this analysis. charge_not_tied means it is not the transaction we built: do not pay again, prove the wallet (destination_challenge with receiver = details.feeWallet, chargeId = this invoice and chargeTxHash = that hash, then destination_authorize) and report the same hash again. Repeating a hash already recorded returns the status, and the stored result only with the receipt the first record returned (receiverAnalysis.receipt, sent back as receipt) or a proven wallet. tx_already_used (409): the hash already paid something else. Once paid, analysis.status is paid and the invoice can be paid. When the payer bought the analysis of the receiving wallet, pass payer too (the charge of the creator needs only txHash): the transaction must be signed by that payer and only the fee wallet may gain USDC in it (the split payment of an invoice never pays it, usdc_to_other_wallet); once paid the receiver analysis runs right away and receiverAnalysis.result comes back (verdict and the paid tools, never the receiving wallet).	No	No	Yes	Yes
`invoice_report_payment`Hand the payment transaction to the server, right after sending it. The server reads the transaction on-chain and measures what reached the receiver in the invoice token; the payer must be the signer and the transaction must be newer than the invoice. The payer is screened again here (payer_blocked: a sanctioned or issuer-frozen payer does not count as paid, and once the network confirms the transaction the refusal is kept in the 10-year analysis record). With a paid analysis on the invoice and no prior proof of the payer wallet, the transaction itself is the proof: until the network confirms it the call returns payment_pending (409) and records nothing, so call again once it is mined. Pending until mined; invoice_get re-checks. An invoice holds at most 5 pending and 30 unconfirmed payments; past that, too_many_pending (429) until the network confirms the transaction, and a confirmed one is always accepted, so call again once it is mined. A hash pays each receiver once (tx_already_used once it confirmed another invoice of the same receiver and token); different receivers in one transaction are a batch payout.	Hand the payment transaction to the server, right after sending it. The server reads the transaction on-chain and measures what reached the receiver in the invoice token; the payer must be the signer and the transaction must be newer than the invoice. The payer is screened again here (payer_blocked: a sanctioned or issuer-frozen payer does not count as paid, and once the network confirms the transaction the refusal is kept in the 10-year analysis record). With a paid analysis on the invoice and no prior proof of the payer wallet, the transaction itself is the proof: until the network confirms it the call returns payment_pending (409) and records nothing, so call again once it is mined. Pending until mined; invoice_get re-checks. An invoice holds at most 5 pending and 30 unconfirmed payments; past that, too_many_pending (429) until the network confirms the transaction, and a confirmed one is always accepted, so call again once it is mined. A hash pays each receiver once (tx_already_used once it confirmed another invoice of the same receiver and token); different receivers in one transaction are a batch payout.	No	No	Yes	Yes
`nn_build`Builds ONE signable/sendable atomic transaction executing every leg of an N:N basket through VurtoSwapRouter. Always re-quotes the whole basket fresh from chainId/inputLegs/outputLegs — there is no quoteId handoff for N:N, pass the same fields used for nn_quote (or skip nn_quote and call this directly). No API key required: pass the wallet that will sign. A machine credential is optional and only raises your limit from the per-IP cap to the credential budget. Returns steps[]: one approve step per DISTINCT input token that still needs allowance, followed by ONE transaction step that executes every leg atomically. The approve target is the VurtoSwapRouter address (steps[].spender / the build's router), NOT each leg's underlying provider — this router pulls every input token itself inside one contract call, so approving providers individually the way swap_build does would approve the wrong address. If simulation.status is approval_required, send the approve step(s) first and call nn_build again for the executable transaction. legs[].routeSwitch, when present on a leg, means the provider the quote picked for THAT leg refused to build (it hit its request limit) and the leg was built with another provider instead: {from, to, reason}. Only that leg changed, the others are untouched, and the replacement is what will be signed: say which provider replaced it before the user signs. IMPORTANT: report_execution and swap_status do NOT support nn_build's transaction step — both key off a single quoteId, and this build has none (it is one transaction covering every leg, not one quote). After sending it, confirm success by checking the transaction receipt directly, not swap_status.	Builds ONE signable/sendable atomic transaction executing every leg of an N:N basket through VurtoSwapRouter. Always re-quotes the whole basket fresh from chainId/inputLegs/outputLegs — there is no quoteId handoff for N:N, pass the same fields used for nn_quote (or skip nn_quote and call this directly). No API key required: pass the wallet that will sign. A machine credential is optional and only raises your limit from the per-IP cap to the credential budget. Returns steps[]: one approve step per DISTINCT input token that still needs allowance, followed by ONE transaction step that executes every leg atomically. The approve target is the VurtoSwapRouter address (steps[].spender / the build's router), NOT each leg's underlying provider — this router pulls every input token itself inside one contract call, so approving providers individually the way swap_build does would approve the wrong address. If simulation.status is approval_required, send the approve step(s) first and call nn_build again for the executable transaction. legs[].routeSwitch, when present on a leg, means the provider the quote picked for THAT leg refused to build (it hit its request limit) and the leg was built with another provider instead: {from, to, reason}. Only that leg changed, the others are untouched, and the replacement is what will be signed: say which provider replaced it before the user signs. IMPORTANT: report_execution and swap_status do NOT support nn_build's transaction step — both key off a single quoteId, and this build has none (it is one transaction covering every leg, not one quote). After sending it, confirm success by checking the transaction receipt directly, not swap_status.	No	No	No	Yes
`nn_quote`N:N — quotes a basket where N input tokens fund M output tokens in ONE atomic on-chain transaction. The backend runs a waterfall allocation deciding which input finances which output, then quotes the real tokenIn->tokenOut route for each resulting slice through the same provider fan-out swap_quote uses. NOT decomposable into independent swap_quote/double_quote calls — the allocation itself is the thing being computed, not just N+M separate prices for legs you already know. inputLegs[]: what you sell (tokenIn + amount or amountRaw, each). outputLegs[]: what you want back, as outputPercent — an integer percent of the TOTAL basket value, not a fixed amount, because the actual split depends on the allocation; every outputLegs[].outputPercent in the request must sum to exactly 100. Up to 10 combined input+output legs; the waterfall never produces more than inputLegs.length + outputLegs.length - 1 real on-chain legs. Returns { legs[], failures[] }. Each entry in legs[] is a real quoted tokenIn->tokenOut leg (a NormalizedQuote under .quote, plus amountIn/tokenIn/tokenOut/receiver for that slice) — this is what nn_build will execute, not a rough preview. failures[] lists any slice that found no route; a partial basket is possible and reported, never silently dropped.	N:N — quotes a basket where N input tokens fund M output tokens in ONE atomic on-chain transaction. The backend runs a waterfall allocation deciding which input finances which output, then quotes the real tokenIn->tokenOut route for each resulting slice through the same provider fan-out swap_quote uses. NOT decomposable into independent swap_quote/double_quote calls — the allocation itself is the thing being computed, not just N+M separate prices for legs you already know. inputLegs[]: what you sell (tokenIn + amount or amountRaw, each). outputLegs[]: what you want back, as outputPercent — an integer percent of the TOTAL basket value, not a fixed amount, because the actual split depends on the allocation; every outputLegs[].outputPercent in the request must sum to exactly 100. Up to 10 combined input+output legs; the waterfall never produces more than inputLegs.length + outputLegs.length - 1 real on-chain legs. Returns { legs[], failures[] }. Each entry in legs[] is a real quoted tokenIn->tokenOut leg (a NormalizedQuote under .quote, plus amountIn/tokenIn/tokenOut/receiver for that slice) — this is what nn_build will execute, not a rough preview. failures[] lists any slice that found no route; a partial basket is possible and reported, never silently dropped.	No	Yes	No	Yes
`payout_batch`Payroll and supplier payouts to many wallets in one batch, on Solana and on the nine EVM chains (those with loteSplit true in GET /v1/chains). EVM: up to 50 wallets, in a verified USD stablecoin (USDC, USDT, PYUSD, USDG, USD1) — the batch is ONE transaction through the Vurto IBBs split contract, and the payer pays the exact amounts PLUS a 0.1% Vurto fee on the total. Solana: up to 20 wallets, in any token the payer holds (no swap, no fee), packed into one or a few transactions. The paying wallet and every receiving wallet are screened first (OFAC SDN list and, on Solana, the issuer freeze of six stablecoins); a blocked payer refuses with payer_blocked (403), and one blocked recipient refuses the whole batch with receiver_blocked (403) and details.index of that row, before anything is created. Each recipient becomes a regular invoice (history, on-chain verification). EVM returns { invoices[], evm: { split, invoiceIds[], base, fee, batchRef, deadline, steps[] } }: sign steps IN ORDER with prepare_signing (the approve step first, then the pay transaction step), send them, and call payout_report_payment with the PAY transaction hash and evm.invoiceIds. Solana returns { invoices[], transactions[] }: sign each transactions[i].transaction (prepare_signing, then POST to /v1/svm/execute) and call payout_report_payment with that signature and its invoiceIds. checks (stablecoin token, both families) adds a PAID analysis of every destination, turning the batch into two steps. Scorechain runs on every EVM chain and Solana; Merkle Science (Didit) does not cover Gnosis, Unichain or Avalanche, so a check the chain lacks refuses with check_not_available_on_chain. With checks the response carries no transactions[]: Solana returns { invoices[], charge: { buildId, transaction, loteId, total, token, tokenDecimals, feeWallet, recipients }, reused[] } (prepare_signing with buildId and step {transaction}, POST to /v1/svm/execute); EVM returns the same charge plus charge.step, a transaction	Payroll and supplier payouts to many wallets in one batch, on Solana and on the nine EVM chains (those with loteSplit true in GET /v1/chains). EVM: up to 50 wallets, in a verified USD stablecoin (USDC, USDT, PYUSD, USDG, USD1) — the batch is ONE transaction through the Vurto IBBs split contract, and the payer pays the exact amounts PLUS a 0.1% Vurto fee on the total. Solana: up to 20 wallets, in any token the payer holds (no swap, no fee), packed into one or a few transactions. The paying wallet and every receiving wallet are screened first (OFAC SDN list and, on Solana, the issuer freeze of six stablecoins); a blocked payer refuses with payer_blocked (403), and one blocked recipient refuses the whole batch with receiver_blocked (403) and details.index of that row, before anything is created. Each recipient becomes a regular invoice (history, on-chain verification). EVM returns { invoices[], evm: { split, invoiceIds[], base, fee, batchRef, deadline, steps[] } }: sign steps IN ORDER with prepare_signing (the approve step first, then the pay transaction step), send them, and call payout_report_payment with the PAY transaction hash and evm.invoiceIds. Solana returns { invoices[], transactions[] }: sign each transactions[i].transaction (prepare_signing, then POST to /v1/svm/execute) and call payout_report_payment with that signature and its invoiceIds. checks (stablecoin token, both families) adds a PAID analysis of every destination, turning the batch into two steps. Scorechain runs on every EVM chain and Solana; Merkle Science (Didit) does not cover Gnosis, Unichain or Avalanche, so a check the chain lacks refuses with check_not_available_on_chain. With checks the response carries no transactions[]: Solana returns { invoices[], charge: { buildId, transaction, loteId, total, token, tokenDecimals, feeWallet, recipients }, reused[] } (prepare_signing with buildId and step {transaction}, POST to /v1/svm/execute); EVM returns the same charge plus charge.step, a transaction	No	No	No	Yes
`payout_charge`Step 2 of a payout_batch with checks, on Solana or EVM. After signing and sending payout_batch's charge.transaction, hand its signature or hash here with the loteId and payer. The server verifies the charge on-chain, runs the paid analysis on EVERY destination, EXCLUDES any wallet that is blocked or over the payer's risk threshold (it receives nothing, its money never moved), and returns { transactions[], evm?, approved[] (each with its scan result), rejected[] (wallet, reason) }. On Solana, sign each transactions[i].transaction (prepare_signing, POST to /v1/svm/execute) and call payout_report_payment with that signature and its invoiceIds. On EVM, sign evm.steps IN ORDER (approve, then pay the IBBs contract) and call payout_report_payment with the pay transaction hash and evm.invoiceIds. Idempotent with the same charge signature (re-returns the built batch, without the wallets already paid, listed in alreadyPaid). The charge hash goes only here, never to payout_report_payment. Errors: batch_charge_not_found, invalid_tx_hash, analysis_payment_pending (409, the network has not confirmed the charge yet, send the signature again shortly), analysis_payment_rejected (the transaction does not pay this charge; details.reason charge_not_tied when it is not the transaction payout_batch built: do not pay again, prove the wallet with destination_challenge (receiver = details.feeWallet, chargeId = the loteId, chargeTxHash = that hash), then destination_authorize, and call this again), tx_already_used.	Step 2 of a payout_batch with checks, on Solana or EVM. After signing and sending payout_batch's charge.transaction, hand its signature or hash here with the loteId and payer. The server verifies the charge on-chain, runs the paid analysis on EVERY destination, EXCLUDES any wallet that is blocked or over the payer's risk threshold (it receives nothing, its money never moved), and returns { transactions[], evm?, approved[] (each with its scan result), rejected[] (wallet, reason) }. On Solana, sign each transactions[i].transaction (prepare_signing, POST to /v1/svm/execute) and call payout_report_payment with that signature and its invoiceIds. On EVM, sign evm.steps IN ORDER (approve, then pay the IBBs contract) and call payout_report_payment with the pay transaction hash and evm.invoiceIds. Idempotent with the same charge signature (re-returns the built batch, without the wallets already paid, listed in alreadyPaid). The charge hash goes only here, never to payout_report_payment. Errors: batch_charge_not_found, invalid_tx_hash, analysis_payment_pending (409, the network has not confirmed the charge yet, send the signature again shortly), analysis_payment_rejected (the transaction does not pay this charge; details.reason charge_not_tied when it is not the transaction payout_batch built: do not pay again, prove the wallet with destination_challenge (receiver = details.feeWallet, chargeId = the loteId, chargeTxHash = that hash), then destination_authorize, and call this again), tx_already_used.	No	No	Yes	Yes
`payout_report_payment`Hand one batch transaction to the server, right after sending it, with the invoiceIds that payout_batch listed for it. Each invoice is verified on-chain like any invoice payment (what reached that receiver); call again a few seconds later if some are still pending.	Hand one batch transaction to the server, right after sending it, with the invoiceIds that payout_batch listed for it. Each invoice is verified on-chain like any invoice payment (what reached that receiver); call again a few seconds later if some are still pending.	No	No	Yes	Yes
`payout_reuse`Preview which wallets in a batch (Solana or EVM) ran this analysis for this payer in the last 30 days: a hint, read with no network call; whether it comes from the history is decided when the charge is paid, by the movement measured then; every one still pays its share of the fee. This reveals a payer's own analysis history, so it needs the paying wallet's signed session; the MCP carries no session, so paid is always [] and the batch charges every destination. With each recipient's amount and a USD stablecoin token it also returns fee { amount (dollars, the analysis charge payout_batch would build), charged (destinations in it), belowMinimum (indexes of the lines below the minimum, which go without the paid analysis), minimum }. Returns { paid: string[], fee? }.	Preview which wallets in a batch (Solana or EVM) ran this analysis for this payer in the last 30 days: a hint, read with no network call; whether it comes from the history is decided when the charge is paid, by the movement measured then; every one still pays its share of the fee. This reveals a payer's own analysis history, so it needs the paying wallet's signed session; the MCP carries no session, so paid is always [] and the batch charges every destination. With each recipient's amount and a USD stablecoin token it also returns fee { amount (dollars, the analysis charge payout_batch would build), charged (destinations in it), belowMinimum (indexes of the lines below the minimum, which go without the paid analysis), minimum }. Returns { paid: string[], fee? }.	No	Yes	Yes	Yes
`prepare_signing`Synthesizes the local CLI signer invocation for one step of a swap_build plan. Does not call the Vurto backend — this only assembles the payload. You (the agent) do not need a private key and must never ask for one in chat: signing happens locally on the user's machine. RUN the command yourself as a background task (it blocks until the user approves/rejects/times out, then prints one JSON line and exits) and react to its exit — never ask the user "did you sign?". EVM supports "approve"/"transaction" steps (send tx.to/tx.data on-chain) and "signature" steps (sign step.typedData off-chain, EIP-712 — a CoW order; no gas, no transaction, no hash). expected_keys in the response tells you which result field to read: txHash for the first two, signature for the third. Solana has no steps[] and no approve: pass chainId "solana-mainnet" and step {transaction: build.transaction, executionRef: build.executionRef}. The response returns a different signer (Solana keys are not EVM keys) with the same shape, and expected_keys is signedTransaction — POST it to /v1/svm/execute, which broadcasts it and returns the signature.	Synthesizes the local CLI signer invocation for one step of a swap_build plan. Does not call the Vurto backend — this only assembles the payload. You (the agent) do not need a private key and must never ask for one in chat: signing happens locally on the user's machine. RUN the command yourself as a background task (it blocks until the user approves/rejects/times out, then prints one JSON line and exits) and react to its exit — never ask the user "did you sign?". EVM supports "approve"/"transaction" steps (send tx.to/tx.data on-chain) and "signature" steps (sign step.typedData off-chain, EIP-712 — a CoW order; no gas, no transaction, no hash). expected_keys in the response tells you which result field to read: txHash for the first two, signature for the third. Solana has no steps[] and no approve: pass chainId "solana-mainnet" and step {transaction: build.transaction, executionRef: build.executionRef}. The response returns a different signer (Solana keys are not EVM keys) with the same shape, and expected_keys is signedTransaction — POST it to /v1/svm/execute, which broadcasts it and returns the signature.	No	Yes	Yes	No
`report_execution`Reports a completed swap, closing the loop. EVM transaction: pass wallet + txHash + quoteId; never report an approve step as an execution. EVM CoW signature: pass wallet + chainId + quoteId + signature; the server reloads the stored build and submits the signed order, returning uid (there is no transaction hash for this path). Solana: pass buildId + signature; the server verifies the fee payer and transaction on the network. No API key required; a machine credential only raises limits.	Reports a completed swap, closing the loop. EVM transaction: pass wallet + txHash + quoteId; never report an approve step as an execution. EVM CoW signature: pass wallet + chainId + quoteId + signature; the server reloads the stored build and submits the signed order, returning uid (there is no transaction hash for this path). Solana: pass buildId + signature; the server verifies the fee payer and transaction on the network. No API key required; a machine credential only raises limits.	No	No	Yes	Yes
`swap_build`Build a signable/sendable plan for a swap. This is the tool that does the work — an agent that only knows this tool can execute a swap end to end. Quotes and builds the best route in one call when quoteId is omitted (recommended): a route with GAIN first, re-quoting up to 3 rounds total before accepting one without gain, the same rule as Invoice; pass quoteId from a prior swap_quote to build exactly that route instead. No API key required: pass the wallet that will sign. A machine credential is optional and only raises your limit from the per-IP cap to the credential budget. Four things to hold onto: 1. steps[] are ORDERED and REQUIRED. Skipping an approve step guarantees a revert. 2. If simulation.status is "approval_required", sign/send only the approve step(s), do not report them as the swap execution, then call swap_build again with quoteId set to the quote.id of that build (the approved route; without it a fresh quote may pick another provider whose spender you never approved). If it is "incomplete", do not sign anything: the transaction was never independently verified. 3. If a step has type "signature", there is no transaction and never will be one for that step — what exists afterward is the uid from report_execution, not a hash. 4. If the provider is cowswap and the token sold is the chain's native asset, the transaction only REGISTERS the order — a successful receipt is not a successful swap. Use swap_status, not the receipt, to know what actually happened. 5. routeSwitch, when present, means the route you asked for refused to build (it hit its request limit) and the plan was built with another provider instead: {from, to, reason}. The quote in the plan is the route that will actually be signed. If the user picked that route themselves, say which provider replaced it before they sign.	Build a signable/sendable plan for a swap. This is the tool that does the work — an agent that only knows this tool can execute a swap end to end. Quotes and builds the best route in one call when quoteId is omitted (recommended): a route with GAIN first, re-quoting up to 3 rounds total before accepting one without gain, the same rule as Invoice; pass quoteId from a prior swap_quote to build exactly that route instead. No API key required: pass the wallet that will sign. A machine credential is optional and only raises your limit from the per-IP cap to the credential budget. Four things to hold onto: 1. steps[] are ORDERED and REQUIRED. Skipping an approve step guarantees a revert. 2. If simulation.status is "approval_required", sign/send only the approve step(s), do not report them as the swap execution, then call swap_build again with quoteId set to the quote.id of that build (the approved route; without it a fresh quote may pick another provider whose spender you never approved). If it is "incomplete", do not sign anything: the transaction was never independently verified. 3. If a step has type "signature", there is no transaction and never will be one for that step — what exists afterward is the uid from report_execution, not a hash. 4. If the provider is cowswap and the token sold is the chain's native asset, the transaction only REGISTERS the order — a successful receipt is not a successful swap. Use swap_status, not the receipt, to know what actually happened. 5. routeSwitch, when present, means the route you asked for refused to build (it hit its request limit) and the plan was built with another provider instead: {from, to, reason}. The quote in the plan is the route that will actually be signed. If the user picked that route themselves, say which provider replaced it before they sign.	No	No	No	Yes
`swap_quote`Compare ranked routes across providers for a swap, without building or spending anything. Ranked by net value after gas and platform fee, not raw output, with ONE unit price for the output token across every route, so a friendlier price feed can never put a route that delivers fewer tokens on top. Each quote also carries estimatedGas, the gas in units behind the same gasUsd, if you would rather rank against a gas price you read yourself. A quote is only usable by swap_build for about 10-12 seconds — do not hold onto a quoteId and build it later, quote again instead.	Compare ranked routes across providers for a swap, without building or spending anything. Ranked by net value after gas and platform fee, not raw output, with ONE unit price for the output token across every route, so a friendlier price feed can never put a route that delivers fewer tokens on top. Each quote also carries estimatedGas, the gas in units behind the same gasUsd, if you would rather rank against a gas price you read yourself. A quote is only usable by swap_build for about 10-12 seconds — do not hold onto a quoteId and build it later, quote again instead.	No	Yes	No	Yes
`swap_status`Re-checks a swap. EVM: pass wallet + executionId (the id from report_execution); for CoW ETH-flow this consults the orderbook and distinguishes order_expired_refundable from order_expired_refunded instead of trusting the registration receipt. Solana: pass signature; answers come directly from the network and may be confirmed, pending, failed or expired.	Re-checks a swap. EVM: pass wallet + executionId (the id from report_execution); for CoW ETH-flow this consults the orderbook and distinguishes order_expired_refundable from order_expired_refunded instead of trusting the registration receipt. Solana: pass signature; answers come directly from the network and may be confirmed, pending, failed or expired.	No	Yes	Yes	Yes
`wallet_check`Check any wallet (EVM 0x address or Solana base58, case-sensitive) before paying it or taking its money: OFAC SDN list on both families; on Solana also the issuer freeze of USDC and EURC (Circle), USDT (Tether), PYUSD and USDG (Paxos) and USD1 (World Liberty), the issuer freeze index, and a fund trail up to three hops back. Returns verdict passed, blocked or unavailable, with each check. Paying an invoice (invoice_pay) runs this check on the receiving wallet and refuses with receiver_blocked, so a payment through Vurto Payments never reaches a sanctioned or frozen wallet. To pay someone directly, create an invoice to their wallet (invoice_create) and pay it with invoice_pay. Plain swaps (swap_build, double_build, nn_build) do not run it. The Scorechain and Merkle Science checks are paid: buy them for any wallet with check_charge and check_analyze (the Check), or inside an invoice with invoice_analysis_pay; asking for them here returns paid_check_requires_invoice (400).	Check any wallet (EVM 0x address or Solana base58, case-sensitive) before paying it or taking its money: OFAC SDN list on both families; on Solana also the issuer freeze of USDC and EURC (Circle), USDT (Tether), PYUSD and USDG (Paxos) and USD1 (World Liberty), the issuer freeze index, and a fund trail up to three hops back. Returns verdict passed, blocked or unavailable, with each check. Paying an invoice (invoice_pay) runs this check on the receiving wallet and refuses with receiver_blocked, so a payment through Vurto Payments never reaches a sanctioned or frozen wallet. To pay someone directly, create an invoice to their wallet (invoice_create) and pay it with invoice_pay. Plain swaps (swap_build, double_build, nn_build) do not run it. The Scorechain and Merkle Science checks are paid: buy them for any wallet with check_charge and check_analyze (the Check), or inside an invoice with invoice_analysis_pay; asking for them here returns paid_check_requires_invoice (400).	No	Yes	Yes	Yes

Details

Registry status: Active
Published: Sep 24, 2026
Updated: Sep 24, 2026
Website: https://swap.vurto.cc/agent-api.md⁠ (opens in a new tab)
Repository: Not given
Categories (suggested): Finance and paymentsSuggested categories are assigned automatically from the registry text and may be wrong. Verified operators can correct them.
GDPR: Not declared

Are you the operator? Claim this listing