Venum

Appearance

How to Migrate from Raw Solana RPC ​

If your app or bot is built around raw Solana RPC, do not try to replace everything at once.

The best migration path is:

  1. smallest change first
  2. highest operational payoff first
  3. keep raw RPC for the parts that are still fine

For most teams, that means starting with transaction submission, then simulation and build, then moving read-heavy polling and discovery off raw RPC.

The Progressive Path ​

Step 1: Keep your builder, replace submission ​

This is usually the easiest high-impact change.

You keep building and signing transactions the way you already do, but stop sending them through raw sendTransaction.

Use:

Why this is the best first step:

  • minimal code change
  • removes a lot of retry and confirmation glue
  • gives you a cleaner submission surface immediately
  • reduces time spent fighting dropped transactions and confirmation polling

If your current stack is build -> sign -> sendTransaction -> poll, this is the least disruptive migration with immediate benefit.

Step 2: Stop managing simulation and build plumbing yourself ​

Once submission is moved, the next highest-payoff step is to stop managing the swap transaction assembly path yourself.

Use:

Why this matters:

  • fewer moving parts around simulation and route selection
  • less blockhash-management glue in your hot path
  • less transaction assembly code to maintain
  • cleaner separation between build, sign, and submit

This is where teams usually stop fighting transaction-shape issues and start simplifying the execution path itself.

Step 3: Replace price polling ​

After execution is under control, move the repetitive read loops.

Use:

This is low risk and often one of the fastest cost wins.

It removes:

  • repeated getAccountInfo loops
  • stale cached third-party price endpoints
  • unnecessary RPC load just to keep prices fresh

Step 4: Replace pool discovery and pool reads ​

If you are using getProgramAccounts for pool discovery, move that next.

Use:

This is usually the biggest raw RPC cost reduction on the read side.

What to Keep on RPC ​

You should usually keep raw RPC for:

  • wallet-specific reads
  • custom program interactions
  • historical lookups
  • account state unique to your application

Venum is not meant to replace every RPC method. It is meant to replace the repetitive execution and market-data patterns that create the most cost and maintenance.

Migration Order by Goal ​

If your biggest pain is dropped transactions ​

Start here:

  1. POST /v1/send
  2. GET /v1/stream/tx
  3. POST /v1/quote
  4. POST /v1/swap/build
  5. POST /v1/swap

If your biggest pain is RPC cost ​

Start here:

  1. GET /v1/prices
  2. GET /v1/pools
  3. GET /v1/stream/prices
  4. POST /v1/quote
  5. POST /v1/swap/build

If your biggest pain is infra complexity ​

Start here:

  1. POST /v1/send
  2. POST /v1/quote
  3. POST /v1/swap/build
  4. POST /v1/swap
  5. GET /v1/pools

Before and After ​

Before ​

Typical raw RPC stack:

  1. build transactions manually
  2. manage blockhash timing and retries
  3. call sendTransaction
  4. poll confirmations
  5. separately poll prices
  6. separately scan pools

After ​

Typical progressive Venum-assisted stack:

  1. keep signing client-side
  2. replace raw submission first
  3. replace swap build and routing next
  4. replace price polling
  5. replace pool discovery

The goal is not to rip out RPC.

The goal is to remove the parts that are expensive, repetitive, and brittle.

Smallest Safe First Step ​

If you want the safest migration possible, do this first:

  1. keep your existing transaction builder
  2. submit signed transactions through POST /v1/send
  3. track them through GET /v1/stream/tx

That gives you a real migration win without forcing an architectural rewrite.

Next Step After That ​

Once submission is stable, move to the hosted swap flow:

  1. POST /v1/quote
  2. POST /v1/swap/build
  3. sign client-side
  4. POST /v1/swap

That is the point where you stop carrying most of the routing, simulation, and transaction-assembly burden yourself.