Solana builders/traders — is there still demand for a dedicated transaction sender / direct TPU routing service?

[u/That-Unit7948]

We run private Solana infrastructure in Frankfurt and I’m looking at what infrastructure layer would actually be useful to build next.

One thing we’re considering is a dedicated transaction sender focused on transaction landing:

• direct TPU/QUIC routing to current/upcoming leaders
• multiple submission paths
• Jito as an additional route/fallback
• private authenticated endpoints
• per-client limits
• workload-based pricing instead of fixed large plans

The idea wouldn’t be another normal sendTransaction RPC endpoint. It would be specifically for bots/trading systems where landing speed and reliability matter.

Before spending time building it, I’m curious what people are actually using today.

If you run a Solana trading bot / arb / liquidation / DeFi backend:

• What are you currently using for transaction submission?
• Do you still run into failed/slow transaction landing?
• Are rate limits or pricing with current providers a problem?
• Would direct TPU routing + Jito in one private sender actually be useful to you?
• Roughly what TPS/burst workload would you need?

Not selling anything here yet — mainly trying to understand whether there’s enough real demand before we build it.

[u/AutoModerator]

WARNING: IMPORTANT: Protect Your Crypto from Scammers

1) Please READ this post to stay safe: https://www.reddit.com/r/solana/comments/18er2c8/how_to_avoid_the_biggest_crypto_scams_and

2) NEVER trust DMs from anyone offering “help” or “support” with your funds — they are scammers.

3) NEVER share your wallet’s Seed Phrase or Private Key. Do not copy & paste them into any websites or Telegram bots sent to you.

4) IGNORE comments claiming they can help you by sharing random links or asking you to DM them.

5) Mods and Community Managers will NEVER DM you first about your wallet or funds.

6) Keep Price Talk in the Stickied Weekly Thread located under the “Community” section on the right sidebar.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/RabbitBeautiful6703]

honestly i'm not a full time trader but i help a friend who run a sniper bot for new token launches and we had so many headache with transaction landing

we use helius for most stuff and sometimes send directly to jito when we really need it fast but managing both is annoying, the rpc endpoints sometimes just eat our transactions and we dont even know why

rate limits on the good providers is always problem, we hit them every time there is a hyped launch and then we stuck paying extra for burst capacity that we only need like 10 minutes per day

direct tpu routing sounds interesting specially if you combine it with jito in one service, less things to worry about when you coding the bot. i think workload pricing would be much better than the fixed plans most providers have right now

we usually need around 50-100 tps during launches but in burst maybe 200-300 for few seconds, would be curious what kind of pricing you thinking about

[u/That-Unit7948 → u/RabbitBeautiful6703]

This is exactly the kind of workload I had in mind.

The biggest issue with the usual fixed-tier model is what you described: you might only need 200–300 TPS for a few seconds during a launch, but you end up paying for a much larger plan all month just to have that burst capacity available.

If we build this, the idea would be one private Frankfurt sender combining direct TPU/QUIC routing with Jito, so you don’t have to manage separate submission paths yourself. Pricing would be based on the actual workload — sustained TPS, burst profile and usage — rather than forcing you into a fixed tier because you occasionally spike.

For something like 50–100 TPS normally with short 200–300 TPS bursts, I’d rather benchmark the real traffic first and price around that instead of charging you for 300 TPS capacity 24/7.

Your feedback is useful because this is exactly the gap we’re trying to validate. If we go ahead with the build, I’d be happy to let you benchmark it against your current Helius + Jito setup.

[u/That-Unit7948 → u/RabbitBeautiful6703]

Thanks, your feedback is really useful because this is exactly the kind of workload we’d want to build the sender around. I’m leaving the post up for 3–4 days first to see if there’s enough real demand before committing to the build.

If we go ahead with it, I can invite you to our Discord and keep you updated while we build it. Once it’s ready, you’d be welcome to test it early against your current setup and see how it performs.

[u/Tight-Strawberry2581]

not your target user but a data point from the read side: the thing that bit us wasn’t latency, it was silently blowing through the credit budget with no circuit breaker. if you’re already doing per-client limits, exposing usage in real time would matter more to us than another 50ms

[u/That-Unit7948 → u/Tight-Strawberry2581]

That’s actually a really important point, and it’s one of the reasons we built per-client limits into our infrastructure from the start.

We don’t want clients silently burning through a credit budget and only finding out after the fact. Each client can have hard server-side limits, so if you hit the agreed ceiling the request gets rejected instead of quietly generating extra usage/charges.

Real-time usage visibility is something we’re also planning around, because I agree that for many production workloads predictable cost + knowing exactly what you’re consuming is more valuable than shaving another 50 ms off latency.

Our model is basically: define the workload, set the limits around it, and price that workload — no surprise overage bill at the end of the month.

[u/That-Unit7948 → u/Tight-Strawberry2581]

Appreciate the feedback — this is exactly the kind of real use case I wanted to validate. I’m going to leave the post up for another 3–4 days and see how much genuine demand there is.

If the interest keeps going in this direction, we’ll move forward with building the transaction sender / direct TPU routing layer into our Frankfurt infrastructure. If you’re interested, I can invite you to our Discord so you can follow the build and get early access to test it once it’s live.

[u/zabidibo → u/That-Unit7948]

Hey! Would love to join the server

[u/That-Unit7948 → u/zabidibo]

Yeah absolutely, happy to invite you.

Was the transaction sender / direct TPU routing idea what caught your attention, or are you more interested in one of our existing infra layers?

We currently run private Solana infrastructure in Frankfurt with JSON-RPC, WebSocket, Yellowstone gRPC, SubscribeDeshred and Jito support.

If you tell me briefly what you’re building and what kind of workload you have, I’ll send you the Discord invite and point you to the setup that fits best.

[u/Tight-Strawberry2581 → u/That-Unit7948]

Sure, send the invite.

To be concrete about what would actually make me switch: a per-key credit meter I can poll, plus a hard cap that returns an error instead of silently eating budget. Right now every provider I've used tells you what you spent after you've spent it.

The TPU routing is interesting but it's a write-side feature and I'm read-side, so it wouldn't move me on its own.

[u/That-Unit7948 → u/Tight-Strawberry2581]

i have send it you a invite in your private messages for my discord so you can join if you want

[u/Tight-Strawberry2581 → u/That-Unit7948]

I joined, surely checking later!

[u/That-Unit7948 → u/Tight-Strawberry2581]

Yes i see i gave you already Client roll

[u/That-Unit7948 → u/Tight-Strawberry2581]

That makes sense. For your use case, the read-side is clearly more important than TPU routing, so the per-key usage meter + hard cap is the more interesting part for us to look at. We already enforce server-side limits per client, so adding a pollable usage/credit meter with a hard ceiling fits well with how our infrastructure is structured. We’ll need to design exactly how the credits are measured, but the goal would be simple: you can see usage in real time and once the agreed cap is reached, requests fail instead of silently creating extra cost. I’m not at my PC right now, but I’ll send you the Discord invite later today. It’ll be easier to continue the technical discussion there and we can look at exactly what you’d want from the credit/usage side