Skip to main content
venue: solana. Over HTTP, sol, svm, spl and spltoken also resolve to it.

​
What to send

A base64-serialized transaction, legacy or v0, as {transaction: "<base64>"}, {tx: "<base64>"} or {method: "signAndSendTransaction", params: {transaction: "<base64>"}}. The string must be strict base64. It is detected without venue when the bytes deserialize as a transaction with at least one instruction. For a v0 transaction that uses address lookup tables, accounts loaded from a table cannot be resolved offline. They show as lookup-table accounts, and a note says so.

​
How it is decoded

Each instruction is decoded and listed in order. SPL amounts are the u64 in the instruction. TransferChecked and ApproveChecked also carry decimals and the mint. actionType is the single instruction action present, mixed if there is more than one, and program-call if there is none. actionFamily covers the whole transaction:
  • permission if any instruction is Approve, ApproveChecked, SetAuthority, CloseAccount or Assign.
  • Otherwise unknown if any instruction could not be decoded.
  • Otherwise transfer if any instruction moves funds (CreateAccount counts).
  • Otherwise unknown, with a note that the transaction is only fees and memos.

​
Notes the classifier adds

  • A plain SPL Transfer names token accounts, not wallets, and not the mint. The owner of the destination and the token are unverified from the instruction.
  • Token-2022 mints can carry transfer fees, transfer hooks and other extensions that the instruction does not show.
  • Approve lets a delegate move tokens later without asking again. SetAuthority changes who controls a token account. CloseAccount sends the account’s rent to a destination, which is a known draining pattern.
  • MintTo creates supply, and Burn destroys tokens.
  • Unknown programs and undecodable instructions tell the judge to lean ESCALATE unless your rules cover them.

​
No live lookup

The adapter reads only the bytes. In an escrow wallet, the transaction is also simulated before the verdict, but a Solana simulation reports only whether the transaction succeeds, not what it moves. None of the wallet limits (per-action USD limit, 24-hour cap, token allowlist, recipient allowlist) can be checked against a raw Solana transaction, so a wallet with any of them set blocks it. Transfers made with escrow_transfer state what they move and are checked normally. See Wallet limits.

​
Example

The classifier types this as sol-transfer in the transfer family. Its summary lists the priority-fee instruction as moving no funds and the transfer as 0.25 SOL (250,000,000 lamports) to 4Nd1mBQtrMJVYVfKf2PJy9NZUZdTAsp7D4xWLs4gDB4T.

​
From an MCP client

Instruct the agent to call verify_intent before signing any Solana transaction, with your rules as intent, { "transaction": "<base64>" } as action and venue: "solana", and to act only on ALLOW.