Olivia
Online
Triport | Solana RPC & gRPC · ETH Mempool
@triport_io
RPC without credit meters. Solana, Ethereum, Polygon via one endpoint. JSON-RPC, DAS, WebSocket, 100+ concurrent gRPC streams. Flat monthly pricing.
Joined May 2026
46 Following
26 Followers
23 Posts
Triport — multi-chain RPC infrastructure for developers, trading bots, terminals and Web3 teams.
One gateway. One API key. Three networks: Solana, Ethereum and Polygon.
Explore Triport: https://t.co/Wael2zywKw
Query data, stream events, deliver transactions and monitor your infrastructure through:
• Full JSON-RPC and REST product APIs
• Native Yellowstone gRPC with platform-wide capacity for 100+ concurrent streams
• WebSocket subscriptions and Solana First-Shred Stream
• DAS API and ZK Compression
• Priority-fee estimation and bundle delivery via Jito and Flashbots
• Mempool feeds, trace/debug methods, validator and MEV intelligence
Built on health-based routing and automatic failover—so your applications can operate across multiple networks without managing separate infrastructure providers.
Pricing without the usual complexity:
No credits. No compute units. No usage-based overages. Just flat monthly plans with clear RPS limits.
Limited-time launch pricing:
To mark Triport’s market launch, all plans are currently available at introductory rates. Prices will increase after the launch period.
Start with a free 7-day trial—no card required.
Basic: $20/mo
Pro: $249/mo
Business: $499/mo
Enterprise: from $999/mo
Documentation: https://t.co/GdCX8xfoMc
One key. Three chains. No surprises.
At Triport, we separate RPC, WebSocket, Yellowstone gRPC and First-Shred—and use health-based routing across infrastructure.
Because performance is not one impressive number on a pricing page.
It is what survives when production gets messy.
https://t.co/AQJz5hL8td
YOUR RPC PROVIDER’S RPS NUMBER IS ALMOST USELESS.
“1,000 requests per second” sounds fast.
But it tells you nothing about what those requests are, how quickly they return, how fresh the data is—or what happens when traffic suddenly spikes.
Let’s break it down. 🧵
Then test failure—not just normal operation.
Increase traffic. Disconnect a stream. Force retries. Run an expensive method beside ordinary reads.
The useful question is not:
“What RPS does the plan advertise?”
It is:
“What workload survives in production?”
YOU DON’T KNOW WHAT YOUR RPC ACTUALLY COSTS.
Your plan includes “100 million credits.”
Sounds generous.
But how many wallet refreshes is that?
How many indexed blocks?
How many trades?
How many days of production traffic?
If you cannot answer those questions, the credit balance tells you almost nothing.
ONE REQUEST IS NOT ONE BILLABLE UNIT
In a credit-based model, two apps making the same number of requests can pay very different amounts.
A status call may have one weight.
A log-heavy query, trace, parsed transaction, DAS request, or historical lookup may have another.
Streaming may be metered by event, block, byte, or bandwidth.
So this equation is usually wrong:
monthly cost = request count × price per request
The real equation is closer to:
monthly cost =
method mix
× method weights
× polling frequency
× retries
× duplicated traffic
streaming
backfills
That is where “predictable” bills stop being predictable.
YOUR USERS DO NOT CREATE CREDITS
They create product actions.
A user opens a wallet.
A terminal refreshes a market.
A bot evaluates a trade.
An indexer processes a block.
Each action can trigger multiple RPC calls, subscriptions, cache misses, simulations, retries, and background jobs.
The useful metric is not:
“credits consumed per month”
It is:
“infrastructure cost per real product action”
If one wallet refresh calls balances, token accounts, prices, metadata, and history, calculate the cost of the complete refresh.
If one indexed block requires logs, receipts, traces, and enrichment, calculate the cost per processed block.
Only then can you connect RPC spend to users, revenue, and growth.
THE HIDDEN MULTIPLIERS
Production traffic is rarely as clean as a pricing spreadsheet.
Retries consume usage.
Timeouts may consume usage before the retry.
Failover can duplicate a request.
Polling runs even when nothing changes.
Reconnections restart streams.
Backfills replay old data.
Monitoring, development, and staging use the allowance too.
Together, these can push an app into another tier without any meaningful increase in active users.
HOW TO AUDIT YOUR REAL RPC COST
Take 7–14 days of production traffic and measure:
Requests by method, not only total requests.
Billing weight for each method.
Retry and timeout rates.
Traffic duplicated by hedging or failover.
Streaming volume and concurrent connections.
Historical queries and backfills.
Staging, testing, bot, and monitoring traffic.
Cost per wallet refresh, trade, tracked address, or indexed block.
Then model three conditions:
normal traffic
a 3× traffic spike
degraded service with elevated retries
The third is the one many teams miss.
During an incident, reliability can fall while recovery attempts consume more of the allowance. Cost and failure amplify each other.
FLAT PRICING IS NOT MAGIC
A flat plan can still be the wrong fit.
You still need to check sustained RPS, burst behavior, method restrictions, archive access, stream limits, and transaction-send limits.
But these are operational constraints engineers can observe and design around. A credit formula adds another abstraction between traffic and cost.
This is why Triport uses flat monthly plans with explicit RPS and product limits, without converting every method into credits or compute units.
Not because every workload is identical.
Because a team should understand its limits before production discovers them.
Before choosing an RPC plan, ask one question:
Can we calculate the infrastructure cost of one real user action without guessing?
If the answer is no, you do not have predictable pricing.
You have a conversion formula.
At Triport, we treat transaction delivery as a separate infrastructure layer from ordinary RPC reads: simulation, priority-fee data, transaction submission, bundle delivery and status tracking solve different parts of the pipeline.
Because a fast RPC response is not the outcome your application needs.
Your trading bot does not make money when the endpoint returns 200 OK.
It makes money when the transaction lands.
𝗬𝗢𝗨𝗥 𝗕𝗔𝗖𝗞𝗨𝗣 𝗥𝗣𝗖 𝗠𝗔𝗬 𝗕𝗘 𝗠𝗔𝗞𝗜𝗡𝗚 𝗧𝗛𝗘 𝗢𝗨𝗧𝗔𝗚𝗘 𝗪𝗢𝗥𝗦𝗘.
Most teams think RPC failover means adding a second URL:
Primary fails → send the request to backup.
It looks resilient in an architecture diagram.
In production, it can increase latency, return stale state and even cause the same economic action to be signed twice.
A second endpoint is not a failover strategy.
It is just another dependency.
𝗛𝗧𝗧𝗣 𝟮𝟬𝟬 𝗗𝗢𝗘𝗦 𝗡𝗢𝗧 𝗠𝗘𝗔𝗡 “𝗛𝗘𝗔𝗟𝗧𝗛𝗬”
An RPC can respond successfully while being several slots behind the network.
It can return an older blockhash, serve inconsistent state or fail only on expensive methods.
A useful health check should monitor:
• Slot and block-height freshness
• Latency distribution, not only averages
• Timeout and error rates
• Blockhash validity
• Method-specific failures
• WebSocket and stream stability
Failover should begin when an endpoint starts degrading, not only after it becomes completely unavailable.
𝗥𝗘𝗔𝗗𝗦 𝗔𝗡𝗗 𝗪𝗥𝗜𝗧𝗘𝗦 𝗡𝗘𝗘𝗗 𝗗𝗜𝗙𝗙𝗘𝗥𝗘𝗡𝗧 𝗟𝗢𝗚𝗜𝗖
Most read requests can be retried against another healthy endpoint.
But the replacement endpoint must be at an acceptable slot and use the same commitment level.
Otherwise, your application may read one version of state from the primary and another from the backup.
For consistency-sensitive requests, use minContextSlot where supported and reject responses from endpoints that are too far behind.
Transaction submission is different.
A successful sendTransaction response only means that the RPC accepted the signed transaction.
It does not mean the transaction landed or was confirmed.
𝗧𝗛𝗘 𝗗𝗔𝗡𝗚𝗘𝗥𝗢𝗨𝗦 𝗥𝗘𝗧𝗥𝗬
Broadcasting the exact same serialized transaction through several routes does not create a new transaction identity.
The bytes and signature remain the same.
The dangerous moment comes when your system assumes the first attempt failed, fetches another blockhash, rebuilds the transaction and signs it again.
Now you have two different signatures representing the same user intent.
If the original transaction is still valid, both versions may reach the network.
For transfers, swaps or withdrawals, that can become a real financial problem.
A safer submission flow should:
• Sign once
• Preserve the original serialized transaction
• Track its signature centrally
• Monitor lastValidBlockHeight
• Check confirmation independently from submission
• Avoid rebuilding while the original transaction can still land
• Make critical on-chain instructions idempotent where possible
𝗙𝗔𝗜𝗟𝗢𝗩𝗘𝗥 𝗧𝗛𝗔𝗧 𝗪𝗔𝗜𝗧𝗦 𝗙𝗢𝗥 𝗔 𝗟𝗢𝗡𝗚 𝗧𝗜𝗠𝗘𝗢𝗨𝗧 𝗜𝗦 𝗔𝗟𝗥𝗘𝗔𝗗𝗬 𝗟𝗔𝗧𝗘
If your application waits for the entire primary timeout before trying a backup, the backup has not protected latency.
It has added another delay after the first one.
Production routing needs:
• Method-specific deadlines
• Continuous health scoring
• Circuit breakers for degraded endpoints
• Freshness-aware routing
• Controlled retries
• Gradual recovery before returning an endpoint to full traffic
Reads may use hedged requests when the latency justifies it.
Writes need stricter coordination because submission and confirmation are separate processes.
𝗧𝗛𝗘 𝗣𝗥𝗢𝗗𝗨𝗖𝗧𝗜𝗢𝗡 𝗣𝗔𝗧𝗧𝗘𝗥𝗡
A reliable RPC layer should make routing decisions before the application notices an outage.
Healthy routes receive traffic.
Degraded routes leave rotation.
Signed transactions retain one identity across delivery paths.
Confirmation is tracked independently.
Recovered endpoints return gradually, only after proving that they are fresh and stable again.
This is how we approach routing at Triport: active health checks monitor latency and errors, degraded upstreams are removed from rotation, and applications continue using one infrastructure endpoint.
Because real failover is not a list of backup URLs.
It is a decision system.
𝗬𝗢𝗨𝗥 𝗦𝗢𝗟𝗔𝗡𝗔 𝗗𝗔𝗧𝗔 𝗦𝗧𝗔𝗖𝗞 𝗜𝗦 𝗣𝗥𝗢𝗕𝗔𝗕𝗟𝗬 𝗪𝗥𝗢𝗡𝗚.
Most Solana teams don’t have a “slow RPC” problem.
They have an architecture problem:
One data path is being forced to do four completely different jobs.
The same endpoint is expected to:
• Read blockchain state
• Push live updates
• Feed an indexer
• Detect market activity as early as possible
That is where the stack starts to fail.
RPC, WebSocket, Yellowstone gRPC and First-Shred are not faster versions of the same API.
They expose different types and stages of data.
𝗝𝗦𝗢𝗡-𝗥𝗣𝗖: 𝗿𝗲𝗮𝗱 𝗮𝗻𝗱 𝗶𝗻𝘁𝗲𝗿𝗮𝗰𝘁
JSON-RPC is the default choice when your application knows what it needs.
Use it to:
• Read accounts and balances
• Fetch blockhashes
• Simulate transactions
• Query transaction history
• Submit transactions
It is predictable and easy to integrate.
But repeatedly polling RPC for every possible change creates unnecessary requests and introduces delay.
𝗪𝗘𝗕𝗦𝗢𝗖𝗞𝗘𝗧: 𝗿𝗲𝗮𝗰𝘁 𝘁𝗼 𝗰𝗵𝗮𝗻𝗴𝗲𝘀
WebSocket subscriptions push account, program, log, slot and signature updates over a persistent connection.
They work well for:
• Wallet interfaces
• Dashboards
• Transaction-status updates
• Alerts
• Lightweight real-time applications
But WebSocket is not a complete high-throughput data pipeline.
Production systems still need reconnection logic, deduplication and a way to recover events missed during downtime.
𝗬𝗘𝗟𝗟𝗢𝗪𝗦𝗧𝗢𝗡𝗘 𝗴𝗥𝗣𝗖: 𝘀𝘁𝗿𝗲𝗮𝗺 𝘀𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗲𝗱 𝗱𝗮𝘁𝗮
Yellowstone gRPC provides a high-throughput stream built around Solana’s Geyser interface.
It is better suited for:
• Indexers
• Trading terminals
• Blockchain scanners
• Analytics pipelines
• Account and transaction monitoring at scale
The trade-off is operational complexity.
You need filters, backpressure handling, decoding, persistence and recovery logic.
Using gRPC everywhere is not automatically better. It only makes sense when the workload requires it.
𝗙𝗜𝗥𝗦𝗧-𝗦𝗛𝗥𝗘𝗗: 𝗱𝗲𝘁𝗲𝗰𝘁 𝗲𝘃𝗲𝗻𝘁𝘀 𝗮𝘀 𝗲𝗮𝗿𝗹𝘆 𝗮𝘀 𝗽𝗼𝘀𝘀𝗶𝗯𝗹𝗲
First-Shred streams are designed to expose fragments of Solana block data before a complete block is reconstructed downstream.
That makes them useful for:
• Latency-sensitive trading bots
• Searchers
• MEV monitoring
• Early market-event detection
But earlier does not mean confirmed.
Shreds require reconstruction, validation, deduplication and a reliable fallback path.
Using First-Shred for a wallet dashboard is unnecessary.
Using slow polling for a latency-sensitive trading bot is the opposite problem.
𝗧𝗛𝗘 𝗣𝗥𝗔𝗖𝗧𝗜𝗖𝗔𝗟 𝗦𝗧𝗔𝗖𝗞
A production system will often combine several paths:
• RPC for state reads, simulation and submission
• WebSocket for lightweight live updates
• Yellowstone gRPC for structured high-volume streams
• First-Shred for the earliest latency-sensitive signals
A wallet may only need RPC and WebSocket.
An indexer may need gRPC with RPC for backfilling.
A trading system may use First-Shred for detection, gRPC for structured processing and RPC for state and execution context.
The goal is not to use every transport.
The goal is to stop forcing every workload through the same one.
This is also how we approach infrastructure at Triport: RPC, WebSocket, native Yellowstone gRPC and First-Shred are separate surfaces because they solve separate problems.
Before optimizing milliseconds, map every workload to the data path it actually needs.
If one connection is reading state, driving the interface, building history and detecting trades, your Solana data stack is probably wrong.
Documentation: https://t.co/GdCX8xfoMc
𝗛𝗮𝗿𝗱𝗰𝗼𝗱𝗲𝗱 𝗦𝗼𝗹𝗮𝗻𝗮 𝗳𝗲𝗲𝘀 𝗮𝗿𝗲 𝗮 𝗽𝗿𝗼𝗱𝘂𝗰𝘁𝗶𝗼𝗻 𝗯𝘂𝗴.
Use the same priority fee for every transaction, and one of two things happens:
→ During quiet periods, you overpay.
→ During heavy account contention, your transaction still lands late—or does not land at all.
There is no universal “correct” priority fee.
Competition changes across slots, and the relevant fee depends on the writable accounts your transaction touches.
A quiet network does not mean that a popular liquidity pool is also quiet.
𝗔𝗻 𝗮𝗱𝗮𝗽𝘁𝗶𝘃𝗲 𝗳𝗲𝗲 𝘀𝘁𝗿𝗮𝘁𝗲𝗴𝘆 𝘀𝗵𝗼𝘂𝗹𝗱 𝗿𝘂𝗻 𝗮𝘀 𝗮 𝗹𝗼𝗼𝗽:
→ Build the transaction and identify its writable accounts.
→ Simulate it to estimate actual compute consumption.
→ Set the compute-unit limit close to the simulated result, with a reasonable safety margin.
→ Query recent priority fees for the relevant accounts.
→ Select a fee level based on urgency and the cost of missing the opportunity.
→ Choose the appropriate delivery path: standard transaction submission or a Jito bundle when atomic execution and ordering matter.
→ Measure the actual inclusion slot, landed rate and total cost.
→ Feed the result back into the next transaction.
Important details:
• A network-wide fee estimate can misprice a transaction targeting highly contested accounts.
• Increasing the compute-unit limit is not the same as improving priority. The fee is calculated from requested compute, not actual usage.
• A higher fee cannot fix stale blockhashes, slow routing or late delivery to the leader.
• A Jito tip does not automatically replace the native priority fee.
At Triport, we combine priority-fee estimation, Jito sendBundle support and health-based routing within one infrastructure layer.
This allows teams to automate the full decision loop instead of hardcoding one fee and hoping it works.
𝗧𝗵𝗲 𝗯𝗲𝘀𝘁 𝗳𝗲𝗲 𝗶𝘀 𝗻𝗼𝘁 𝘁𝗵𝗲 𝗹𝗼𝘄𝗲𝘀𝘁 𝗼𝗿 𝘁𝗵𝗲 𝗵𝗶𝗴𝗵𝗲𝘀𝘁.
It is the lowest fee that consistently achieves your target landing rate under current conditions.
Next: RPC vs WebSocket vs Yellowstone gRPC vs First-Shred—and which one your product actually needs.
𝗣𝗮𝘆𝗶𝗻𝗴 𝗺𝗼𝗿𝗲 𝘄𝗼𝗻’𝘁 𝗺𝗮𝗸𝗲 𝘆𝗼𝘂𝗿 𝗦𝗼𝗹𝗮𝗻𝗮 𝘁𝗿𝗮𝗻𝘀𝗮𝗰𝘁𝗶𝗼𝗻 𝗹𝗮𝗻𝗱 𝗳𝗶𝗿𝘀𝘁.
You can increase the priority fee, add a Jito tip—and still lose the slot.
Why?
Because priority fees and Jito tips solve different parts of the transaction-delivery problem.
𝗧𝘄𝗼 𝗱𝗶𝗳𝗳𝗲𝗿𝗲𝗻𝘁 𝗺𝗲𝗰𝗵𝗮𝗻𝗶𝘀𝗺𝘀:
→ A priority fee increases the probability that a leader schedules your transaction ahead of competing transactions.
→ A Jito tip places your transaction or bundle into a separate Block Engine auction.
A priority fee is based on the compute-unit price and the compute-unit limit you request.
If the limit is unnecessarily high, you may pay for compute you never use without improving execution.
A Jito auction also considers efficiency and account-locking patterns—not only the raw size of the tip.
Bundles touching the same accounts compete with each other. Bundles without conflicting locks may be evaluated separately.
𝗡𝗲𝗶𝘁𝗵𝗲𝗿 𝗺𝗲𝗰𝗵𝗮𝗻𝗶𝘀𝗺 𝗴𝘂𝗮𝗿𝗮𝗻𝘁𝗲𝗲𝘀 𝗶𝗻𝗰𝗹𝘂𝘀𝗶𝗼𝗻.
Your transaction can still miss because:
• It reached the leader too late
• The delivery route was slow or unstable
• The targeted accounts were highly contested
• The compute budget was configured incorrectly
• The transaction or bundle failed simulation
• The slot had insufficient remaining capacity
• A competing transaction had better timing and fee efficiency
During competitive periods, a Jito submission may require both a priority fee and a tip. One does not automatically replace the other.
At Triport, we combine priority-fee data, Jito sendBundle support and health-based transaction routing within one infrastructure layer.
The goal is not simply to pay more.
The goal is to choose the right fee, compute budget and delivery path for current network conditions.
𝗧𝗵𝗲 𝗺𝗲𝘁𝗿𝗶𝗰 𝘁𝗵𝗮𝘁 𝗺𝗮𝘁𝘁𝗲𝗿𝘀:
Cost per successfully landed transaction—not fee per submission.
Next: how to build an adaptive fee strategy without blindly overpaying.
Triport — multi-chain RPC infrastructure for developers, trading bots, terminals and Web3 teams.
One gateway. One API key. Three networks: Solana, Ethereum and Polygon.
Explore Triport: https://t.co/Wael2zywKw
Query data, stream events, deliver transactions and monitor your infrastructure through:
• Full JSON-RPC and REST product APIs
• Native Yellowstone gRPC with platform-wide capacity for 100+ concurrent streams
• WebSocket subscriptions and Solana First-Shred Stream
• DAS API and ZK Compression
• Priority-fee estimation and bundle delivery via Jito and Flashbots
• Mempool feeds, trace/debug methods, validator and MEV intelligence
Built on health-based routing and automatic failover—so your applications can operate across multiple networks without managing separate infrastructure providers.
Pricing without the usual complexity:
No credits. No compute units. No usage-based overages. Just flat monthly plans with clear RPS limits.
Limited-time launch pricing:
To mark Triport’s market launch, all plans are currently available at introductory rates. Prices will increase after the launch period.
Start with a free 7-day trial—no card required.
Basic: $20/mo
Pro: $249/mo
Business: $499/mo
Enterprise: from $999/mo
Documentation: https://t.co/GdCX8xfoMc
One key. Three chains. No surprises.
@RovercryptoE If you're interested in collaborating with us, send us a DM
𝗬𝗼𝘂𝗿 𝗦𝗼𝗹𝗮𝗻𝗮 𝗥𝗣𝗖 𝗿𝗲𝘁𝘂𝗿𝗻𝗲𝗱 𝗮 𝘀𝗶𝗴𝗻𝗮𝘁𝘂𝗿𝗲.
𝗦𝗼 𝘄𝗵𝘆 𝗱𝗶𝗱 𝘁𝗵𝗲 𝘁𝗿𝗮𝗻𝘀𝗮𝗰𝘁𝗶𝗼𝗻 𝗻𝗲𝘃𝗲𝗿 𝗹𝗮𝗻𝗱?
Because an RPC response is not on-chain execution.
“sendTransaction” only confirms that the endpoint accepted the signed payload. From there, the real delivery race begins:
→ The transaction enters the broadcast path.
→ It is forwarded toward the current and upcoming leaders.
→ A leader’s TPU receives and verifies it.
→ It competes for account access, compute capacity and block space.
→ If it misses the slot, it must be retried before its recent blockhash expires.
At any stage, overloaded queues, network jitter, poor leader routing, account contention, insufficient priority or a slot transition can cost several slots—or prevent the transaction from landing entirely.
𝗧𝗵𝗮𝘁 𝗶𝘀 𝘄𝗵𝘆 𝗲𝗻𝗱𝗽𝗼𝗶𝗻𝘁 𝗽𝗶𝗻𝗴 𝗶𝘀 𝗮 𝘄𝗲𝗮𝗸 𝗯𝗲𝗻𝗰𝗵𝗺𝗮𝗿𝗸.
A 10 ms RPC can produce worse results than a 25 ms RPC if its transaction-delivery path is less reliable.
At Triport, we treat the RPC response as an intermediate event—not the final success metric.
That is why our infrastructure combines health-based routing, automatic failover and Solana transaction-delivery tooling.
The objective is to improve the entire path, not just return a fast HTTP response.
𝗪𝗵𝗮𝘁𝗲𝘃𝗲𝗿 𝗽𝗿𝗼𝘃𝗶𝗱𝗲𝗿 𝘆𝗼𝘂 𝘂𝘀𝗲, 𝗺𝗲𝗮𝘀𝘂𝗿𝗲:
• Landed transaction rate
• Inclusion slot
• p95 and p99 send-to-inclusion latency
• Dropped and expired transactions
Not just RPC RTT.
Next: priority fees, tips and why paying more does not guarantee the first position.
Last Seen Users on Sotwe
Trends for you
Most Popular Users
Elon Musk
@elonmusk
241.5M followers
Barack Obama
@barackobama
119M followers
Cristiano Ronaldo
@cristiano
113.9M followers
Donald J. Trump
@realdonaldtrump
111.8M followers
Narendra Modi
@narendramodi
107.2M followers
Rihanna
@rihanna
98.6M followers
NASA
@nasa
92.4M followers
Justin Bieber
@justinbieber
91.7M followers
KATY PERRY
@katyperry
89.7M followers
Taylor Swift
@taylorswift13
83.6M followers
Lady Gaga
@ladygaga
75.1M followers
Virat Kohli
@imvkohli
72.8M followers
Kim Kardashian
@kimkardashian
70.7M followers
YouTube
@youtube
68.8M followers
Neymar Jr
@neymarjr
65.8M followers
Bill Gates
@billgates
64.9M followers
Selena Gomez
@selenagomez
62.8M followers
The Ellen Show
@theellenshow
62.3M followers
CNN
@cnn
61.8M followers
X
@x
60.7M followers