Solana Trading

Balchemy Hub agents trade Solana tokens through Jupiter, the leading Solana liquidity aggregator, with automatic pre-trade security screening on every swap.

Warning: This page documents the implemented Solana trading path, not proven live coverage. Treat capability statements here as partial until the current release evidence confirms them, and confirm what is actually exposed to your credential with a runtime tools/list call. Which tools and providers respond depends on current configuration, quotas, and source health.

What is this?

Solana trading in Balchemy routes every swap through the Jupiter aggregator (jup.ag). Jupiter finds the best route across all major Solana DEXes — including Raydium, Orca, and Meteora — and splits orders across multiple pools when it improves the output price. Your Hub agent can search tokens, fetch live quotes, run security checks, and execute swaps through authorized commands, MCP/API calls, or rules that pass policy.

The trading engine is a Rust-based service that handles execution, risk policy enforcement, and on-chain transaction signing. The agent or operator supplies intent; the engine validates policy, quote, and risk signals before any submitted transaction touches the chain.

Prerequisites

• A custodial Solana wallet created and set as primary through the authorized Hub wallet flow (see Agent Wallet Management)
• The custodial wallet funded with SOL (for gas) and your input token (typically SOL or USDC)
• A Hub agent key or runtime with trade scope where trading is intended

Warning: Solana trading is only available with custodial wallets. External delegate wallets cannot sign transactions automatically. If you connect an external wallet, the product can present trade summaries but will not execute them.

---

Two ways to trigger a Solana trade

1. Natural language or MCP/API intent

Use the authorized Hub/agent flow and describe what you want in plain English:

• "Buy 0.5 SOL worth of BONK"
• "Swap 100 USDC for JUP with 1% slippage"
• "Sell 50% of my WIF position"

The agent flow interprets the request, resolves token addresses, fetches a quote, runs the pre-trade report, and presents a trade summary for confirmation before submitting. If the authorized rules/profile allow execution, eligible orders can be submitted through the execution path without an additional chat confirmation.

2. Hub rules and runtime

Hub rules can create Solana trade candidates based on price conditions, technical signals, Signal Sources, or scheduled DCA intervals. When a rule fires, the pipeline still preserves quote, pre-trade status, policy checks, and explicit submitted/blocked/approval-required outcomes.

---

Fee structure

Balchemy charges a platform fee on every Solana swap using Jupiter's feeAccount mechanism:

The fee is deducted from the input token before the swap is submitted to Jupiter. It is passed directly to the Balchemy fee account on-chain and is visible in the transaction explorer. Jupiter also charges its own routing fee (typically 0.04–0.1% depending on the route), which is separate from the Balchemy platform fee.

Tip: The fee is taken from your input token, not from the output. If you sell 1 SOL, 0.01 SOL goes to the Balchemy fee account and 0.99 SOL is routed through Jupiter.

---

Slippage settings

Slippage tolerance is specified in basis points (bps), where 100 bps = 1%. Balchemy recommends:

You can set default slippage through the authorized Hub rules/profile flow or override it per trade where the product flow supports it. The trading engine rejects trades where the actual on-chain price impact exceeds the configured maxSlippage value.

---

Pre-trade security checks

Before a Solana swap is submitted, the trading engine runs the available pre-trade checks and reports each source as available, degraded, or unavailable instead of treating missing data as safe.

RugCheck (trading_solana_rugcheck_report)

RugCheck is a Solana-native token analysis service. It scores a token's mint address and returns signals including:

• Mint authority — Can the creator mint more tokens?
• Freeze authority — Can the creator freeze your tokens?
• LP lock status — Is the liquidity pool locked from rug pulls?
• Holder concentration — What percentage of supply do top wallets hold?
• Individual risk entries — A list of specific findings, each naming a detected issue

The pre-trade check does not read an aggregate score or rating. It counts the risk entries RugCheck returns, and any entry at all — one or twenty — escalates the swap to approval-required rather than blocking it. The trade is not rejected; it waits for an explicit approval before execution. The only path to an outright block is a combined signal: risk entries present and the token's mint authority still active.

If RugCheck cannot be reached at all, the swap is also escalated to approval-required, because a missing signal is not treated as a clean result. A response that arrives but cannot be parsed, or one that carries no risk entries, counts as zero risks and does not escalate on its own.

Token Insights (trading_solana_token_insights)

Token Insights queries the Solana RPC directly and returns:

• Mint authority and freeze authority addresses
• Total supply and decimals
• Top holder distribution (wallet addresses and percentages)

This data supplements RugCheck and lets your bot provide a richer assessment in the pre-trade summary.

---

Token research tools

Your Hub agent has access to these tools for Solana token research before and independent of trading:

You can trigger any of these by asking the agent to research a token before committing to a trade. For example: "Run a pre-trade report on So11111111111111111111111111111111111111112."

---

Pending vs immediate execution

By default, the trading_solana_jupiter_swap tool runs in plan mode (submit: false). In plan mode the agent:

1. Fetches a live quote.
2. Runs the pre-trade report.
3. Presents the quote, fee, slippage, and risk summary to you in chat.
4. Waits for your explicit confirmation before submitting.

When submit: true is set through an authorized confirmation or rule/profile path, the engine signs and broadcasts the transaction immediately. Once broadcast, a Solana transaction cannot be cancelled — and broadcast is not the same as execution. The order is settled only when its on-chain outcome has been observed or reconciled.

---

Example trade flow: buying BONK with 50 USDC

Here is what happens end-to-end when you ask an agent to buy 50 USDC of BONK:

1. Token resolution — The agent searches for BONK's mint address using trading_solana_jupiter_tokens_search.
2. Quote — trading_solana_jupiter_quote returns the expected BONK output, route details, and price impact at current market conditions.
3. Pre-trade report — trading_solana_pretrade_report runs RugCheck and token insights on the BONK mint address in parallel.
4. Policy check — The trading engine verifies the trade would not breach your configured max drawdown, daily loss limit, or max position size.
5. Summary — The agent flow shows you the quote, platform fee, slippage, and any RugCheck risk entries reported for BONK.
6. Confirmation — You confirm through the authorized flow, or an eligible rule proceeds when policy allows it.
7. Submission — trading_solana_jupiter_swap is called with submit: true. The engine constructs the Jupiter swap transaction and signs it with your custodial wallet's private key.
8. On-chain verification — The engine monitors the submitted transaction. The outcome can be confirmed, failed on-chain, dropped after blockhash expiry, still unknown, or handed to reconciliation. Monitoring ends when one of those outcomes is recorded, not when a signature is returned.
9. Order update — The order status reflects the lifecycle state, such as submitted, confirmed, filled, failed, or reconciliation-required. The Trading Dashboard and Trade History should show that state rather than treating submission as final execution.

---

How the input mint is interpreted

The inputMint you supply is the token being sold, and it decides how the engine labels the swap: when the input mint is native SOL the swap is treated as a buy of the output token, and any other input mint is treated as a sell of that input token.

No allowlist restricts which mint you may pass as inputMint. The engine does not limit the input side to SOL or USDC, so a token-to-token swap between two non-SOL mints (for example BONK → JUP) is accepted and routed through Jupiter like any other swap. The backend checks only that both mint fields are present.

Warning: Because the input side is unrestricted, nothing stops you from selling an unfamiliar or illiquid token. Run trading_solana_pretrade_report on both mints first, and size the trade against real liquidity — a thin route can return far less than the quote suggests even when slippage is set generously.

---

DCA on Solana

Dollar-cost averaging lets an agent buy a fixed USD amount of a token at regular intervals. DCA strategies run the same swap pipeline on a schedule. Use the Hub rules/runtime and agent detail surfaces where DCA profiles are exposed.

See Rules and Runtime for current Hub runtime guidance.

---

Tips and warnings

Tip: Ask your agent to "run a pre-trade report on [mint address]" before any unfamiliar token. The response will include the RugCheck risk entries, mint authority status, holder concentration, and the expected trade output — all in one message.

Tip: For meme tokens with thin liquidity, use a trade size under $500 and set slippage to 3–5% to reduce the chance of partial fills or price impact failures.

Warning: Solana transactions that are broadcast cannot be cancelled. Once the engine submits the transaction with submit: true, the outcome is decided on-chain: it may confirm, fail on-chain, be dropped once its blockhash expires, or stay unknown until reconciliation resolves it. A transaction that has not confirmed yet is not a failed trade, and the engine suppresses automatic retry once a transaction has been broadcast so that a second swap cannot be dispatched alongside the first. Always verify the quote summary before confirming.

Warning: Risk signals gate a trade with an approval step, not a block. If RugCheck returns any risk entry for the token — or if RugCheck cannot be reached — the swap becomes approval-required and waits for your explicit sign-off. Approving it is a decision, not a formality: read the entries before you approve. An outright block happens only when risk entries and an active mint authority appear together.

---

Common issues

"Insufficient balance" when placing a trade. Your custodial Solana wallet does not have enough SOL or USDC. Fund it from an external wallet using the address shown in the Hub wallet flow. Remember to keep at least 0.01 SOL for transaction fees.

"Token not found" when searching by symbol. Jupiter's token list does not include every Solana token by symbol. Search by the full mint address instead. Mint addresses are available on DexScreener, Birdeye, or the project's official website.

"High slippage warning" on the pre-trade report. The current liquidity in the selected pool(s) is insufficient to fill your order without significant price impact. Try reducing the trade size, increasing the slippage tolerance, or waiting for deeper liquidity.

Trade stays in pending for more than 2 minutes. The trading engine may be under load, or the Solana network is congested. A pending order has not been submitted yet; it is not a commitment that the order will execute. It can still be cancelled while it is pending, and once it moves to executing it can confirm, fail, be dropped, or require reconciliation like any other order. Do not place a duplicate order to force it through. If it remains pending for more than 5 minutes, contact support via the in-app help panel.

The amount I received was less than the quote showed. Slippage is the difference between the quoted price and the final execution price. If the market moved between quote time and execution time, you may receive slightly less than quoted. The actual amount received is shown in the Order Details drawer in Trade History.

RugCheck reports "Mint authority not revoked" — is it safe? An active mint authority means the token creator can print new tokens, diluting your position. This is a significant red flag for most projects. Some legitimate tokens (wrapped assets, certain stablecoins) intentionally keep mint authority. Research the project before proceeding and do not rely solely on RugCheck for investment decisions.

---

Related pages

• EVM Trading — Trading on Base via 0x aggregation
• Agent Wallet Management — Set up and review Hub agent wallets
• Rules and Runtime — Configure Hub agent rules and runtime state
• Hub Overview — Monitor active Hub agent operations