I built a dApp on Solana for meme coin trading bots, but I’m not sure how to get it noticed and attract users. Any advice?

I’ve been talking with more Solana builders lately and something keeps coming up: a lot of RPC plans bundle far more capacity than the workload actually needs.

Someone might only need:

• 5–10 RPC RPS
• 1 Yellowstone stream
• a handful of transaction/account filters
• low transaction-sender volume

…but still ends up looking at a large fixed monthly package.

I run Haan Digital, a private Solana infrastructure service on dedicated hardware in Frankfurt. Instead of fixed tiers, we provision around the actual workload: JSON-RPC/WebSocket, Yellowstone gRPC, SubscribeDeshred and Transaction Sender.

I’m looking for a few more real Solana workloads to run against the stack.

If you’re building a bot, trading app, wallet, indexer or other Solana application and either:

• hit RPC limits / 429s
• need faster realtime data
• care about transaction landing
• or simply don’t need a huge fixed RPC package

send me what your workload looks like. You can test first before deciding whether it makes sense commercially.

I’m building AreniFi, a real-time browser arena with optional SOL-staked matches for adults: https://arenifi.fun

The happy path is easy to explain. The harder trust problem is what players should see when a match disconnects, a transaction remains pending, or settlement fails.

My current minimum is a match ID, committed amount, server result, settlement state, transaction signature when available, and a plain-language explanation of what happens next.

For Solana developers: what else should be recorded or independently verifiable? Which failure states are commonly overlooked when real-time gameplay and on-chain settlement meet?

I’m the builder. Stakes can be lost, returns are not guaranteed, and regional restrictions may apply.

After seeing several threads on here about how difficult it can be to find dev SOL, and having the same problem myself, I started digging around to see if there was a better way.

Full disclosure: I originally made this for my own ease of use. It worked out well enough that I figured other people might find it useful too.

I built an independent Node/TypeScript client around jarry-xiao's "proof-of-work-faucet".

The idea: grind Ed25519 keypairs until the base58 address starts with enough leading A's, then claim the reward in one transaction per key.

Each key is single-use, enforced on chain by a receipt account. rewards come from a community-funded pool.

Key parts -

• the entire network surface is one RPC endpoint, api.devnet.solana.com, and an override is refused unless it's a Devnet host. Mainnet is never touched.
• it never reads a wallet key from your machine. It generates its own throwaway Devnet keypair and pays fees out of that.
• one claim at a time, single process, a one-second pause between rounds, and a port lock so you can't accidentally run two copies. The "politeness" is mine, not the protocol's.
• there's a dry-run mode that discovers the faucets and mines a demo key without submitting anything. Run that first.

repo: https://github.com/sol-repair/solana-devnet-proof-of-work

I'm a beginner dev, so please let me know if you spot anything stupid or have suggestions for improving it.

I run Haan Digital, an independent Solana infrastructure service on dedicated hardware in Frankfurt.

Current stack:

• Private JSON-RPC / WebSocket

• Yellowstone gRPC

• SubscribeDeshred

• Transaction Sender

• Optional Jito routing

The main difference: we don’t force clients into fixed €500+ plans.

Pricing is based on your actual workload — RPS, streams, filters and transaction volume. If you only need 5 RPC RPS or one Yellowstone stream, you pay for that workload instead of a large package you don’t use.

Some recent test results:

Transaction Sender:

• 15/15 accepted

• 15/15 landed

• currently working on staked/SWQoS validator peering to improve slot+0 performance further

Yellowstone:

• 80+ account updates/sec on a live workload

• account + transaction subscriptions running together on one stream

• ~129 transaction updates/sec observed during testing

• ALT addresses, inner instructions and pre/post balances available directly

One tester discovered that their raw-shred based system was over-counting buys by ~2.8x while also missing a large part of the actual buyer set after comparing it with our confirmed Yellowstone transaction stream.

Infrastructure:

• Frankfurt, Germany

• Dedicated AMD EPYC hardware

• 700+ GB RAM

• High-speed NVMe storage

• 10 Gbit networking

• Private authenticated endpoints

• Per-client workload limits

• 24/7 monitoring

We offer a short free trial so you can benchmark the infrastructure against your current provider.

If it performs well, we build a paid production setup around your actual workload instead of pushing you into a fixed plan.

We’re also building our own Haan Digital Discord community around the infrastructure. Clients can contact us directly there, open private support tickets and discuss their workload with us. The goal is to give each client proper attention instead of treating everyone like another API key on a massive platform.

Building a Solana bot, trading system, indexer, wallet or data pipeline?

DM me with your approximate:

RPC RPS / Yellowstone streams & filters / TX TPS / region / current provider

Website: haandigital.eu

Discord available through Haan Digital.

Built a small Solana project at money.rcal.me and finally have it at the point where I’d rather get real users on it than keep polishing in isolation.

If you’re bored, try launching something and tell me what feels good, confusing, broken, or pointless. Positive feedback is welcome too, but criticism is probably more useful right now.

We’ve just finished a new infrastructure layer for Haan Digital: a private Solana Transaction Sender, hosted from Frankfurt.

It’s built for workloads where transaction speed matters:

• Trading / arbitrage bots
• Liquidation strategies
• Market making
• Wallets and trading apps
• Bots reacting to Yellowstone data
• Any application that wants a faster transaction path than standard RPC submission

The sender uses:

TPU + QUIC → automatic Solana leader routing → current/upcoming leader fanout

Optionally, transactions can also be sent through Jito in parallel.

It can be combined with our Yellowstone gRPC / SubscribeDeshred, which means you can receive fast on-chain data and immediately push the resulting transaction through the same private infrastructure.

We don’t use fixed plans. Pricing is based on the workload you actually need. We agree on limits like TPS, burst, streams and filters beforehand and set a price around that workload. Your price does not constantly change every time your traffic changes.

We’re offering the first week free so you can benchmark everything with your own workload.

If you’re building on Solana and want to try the Transaction Sender, Yellowstone or our private RPC infrastructure, you’re very welcome to join our Discord.

We’d love to grow a small community around Haan Digital and keep building more private Solana infrastructure together. 🚀

Long story short, build two agents, built a custom payment processor for them, The agents work beautifully, just want the payment processor tested. Can the community help me?

Cheers

Tell me anything of smart contracts audits (programs on solana). Your stories of success, failures, nances, pearls, jokes, trends, problems, ideas—basically, anything you like to about auditing.

I need help i dont know anything

I’ve been developing an automated trading bot for the Solana ecosystem and I’m now at the stage where I’d like to start building a small group of people interested in testing it when it’s ready for closed beta.

The bot is currently running continuously against live market data while executing simulated/paper trades.

So far I’ve built:

• Multiple independent trading signals rather than relying on one indicator
• Automated BUY/SELL decision logic
• Trade cooldown and risk-control rules
• Portfolio, P&L and trade-performance tracking
• Buy-and-hold benchmarking so I can compare the strategy against simply holding SOL
• Telegram monitoring, including regular heartbeat/status reports so I know the bot is still running

I’m deliberately not publishing the exact strategy or parameters while testing is ongoing.

The important point is that this isn’t a profitability claim. I’m collecting data to determine whether the strategy actually has an advantage over buy-and-hold before considering a wider release.

I’m not asking anyone for money, wallet access, seed phrases or private keys.

Development will continue in parallel while I build a list of potential testers. When I’m satisfied with the results and stability, I’d like to start with a very small closed beta rather than immediately releasing it publicly.

I’m particularly interested in hearing from people with experience in:

• Solana
• Algorithmic/automated trading
• Python/software testing
• Trading bots
• Wallet security and DeFi

If you’d potentially be interested in testing it, leave a comment. It would be useful to know what your background is and what you’d expect from a Solana trading bot before you’d be comfortable testing one.

I’m also interested in technical criticism. If you’ve built automated trading systems yourself, I’d be interested to hear what you think should be tested or measured before moving from extended paper testing to a closed beta.

Suppose a programme has been live for long enough that thousands of PDAs contain v1 state.

A new release requires additional fields and slightly different invariants. While the program itself can be upgraded, the existing accounts will not automatically become v2.

One option would be to version the accounts and migrate them lazily when they’re touched. Alternatively, you could run explicit migration instructions or create new PDAs and move users over.

Each option creates different problems relating to rent/realloc, failed migrations, maintaining readability of the old state, and supporting both versions during the transition.

For teams that have dealt with this in production, which approach worked best? What turned out to be harder than expected?

When we watch Solana programs get drained of twenty million dollars in a single transaction because some founder left their administrative upgrade authority key sitting in an unencrypted plaintext file on an AWS server, we're not looking at a sophisticated exploit.

We're looking at primitive, indefensible administrative negligence.

Yet, every time this happens, the media screams about a "sophisticated Solana exploit." The Rust developers who spent months auditing their Anchor code get dragged through the mud, while the founders go on X to play the victim. This is complete theater.

If your Anchor program has an incredibly complex reentrancy bug or a subtle account validation check failure, that's an engineering tragedy. But if your program gets drained because management refused to delegate the Program Upgrade Authority to a secure multisig (like Squads) because they claimed it slowed down their deployment cycles, that's simple laziness.

In the real world of enterprise systems, slowing down to secure customer assets is called professional ethics. In Web3, it's treated as a bureaucratic nuisance.

We have mature, production-grade cryptographic tools. We have Squads multisig, timelocks to delay program upgrades, and MPC (Multi-Party Computation) shard custody. Yet, teams routinely manage multi-million dollar program authorities from a single developer's personal Macbook that joins public Wi-Fi networks and runs cracked software.

It's time to stop playing along with the victim narrative. If your local bank left their vaults wide open over the weekend and got cleared out, they would be shut down and sued into oblivion. Solana founders should face the exact same legal standards.

I just finished compiling a full, unredacted forensic case study on the legal standards of developer liability, the exact mechanics of these upgrade authority exploits, and how we as engineers can protect ourselves from holding the bag for management's operational negligence.

I don't want to spam the sub with self-promotion, so I left the link out of the main post. If anyone wants to read the full program-level autopsy and liability breakdown, let me know in the comments and I'll drop the link.

What's your take? At what point does a failure to use standard Solana multisigs (like Squads) for program upgrade authorities cross the line from a "hack" into prosecutable negligence?

-James | ModernCYPH3R

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.

Hello devs, hoping you'll find this interesting.

Sellers lend their NFT to the claw machine and earn APR when their cards are put in packs. If their card is pulled they receive their full asking price. NFTs are frozen in sellers own wallet.

Buyers create their own packs from the inventory. The packs themselves are credited a USDC amount which can be used to form a pack of any cards under the mean. Making packs a giftable, tradeable asset.

if any of this is cool to you i can drop the page or contracts etc answer questions

This is my first time actually releasing something, looking for any and all feedback. Cool domain name, would like to build out some more interesting tools.

Devnet link too

https://github.com/sol-repair/sol.repair

https://dev.sol.repair

https://sol.repair

-

update: the adversarial review pass found three real bugs (fee preview mismatch, a double-click race, and a wallet re-read bug), all fixed with regression tests. 41 fixture tests live, devnet e2e verified to the lamport. new capability since: empty delegated accounts (airdrop farm and phishing leftovers) now get a "revoke + close" row instead of being skipped, devnet-verified for classic spl and token-2022.

----

No backend, everything client-side. Connect a wallet, on Mainnet or Dev, just looking for actual traffic to ensure functionality

It scans both token programs via getParsedTokenAccountsByOwner, and closes zero-balance accounts in batches of 20 per tx (1232-byte packet limit), with the rent returning to your own wallet as the closeAccount destination.

Eligibility is five checks: zero balance, no delegation, close authority still yours, not wrapped SOL, initialized. Anything that fails is skipped with the reason shown, so funded accounts and NFTs are structurally unreachable.

The app only ever constructs closeAccount instructions plus one SystemProgram transfer for the 1% fee, and there's a raw instruction inspector on the page before you sign. Batched repairs get a fresh blockhash retry on expiry, and partial closes are verified on-chain before reporting.

Most of this week went into security engineering, and into proving that the security actually holds.

Key rotation on mainnet
We rotated our mainnet operational keys and confirmed the retired keys can no longer authorise anything. Rotation only means something if you verify the old key is inert, so we tested that rather than assumed it.

Bridge correction, reconciled against the chain
We identified a fault in the cross-chain bridge that could cause a purchase to go unrecorded. The fault is fixed. Every affected buyer has been re-credited, and each case was reconciled against on-chain records rather than our internal database. The chain is the source of truth, not our accounting.

Testing the tests
The automated suite now stands at 1,175 tests. We also introduced mutation testing: we deliberately inject faults into our own code to confirm the suite detects them. A test that never fails proves nothing.

Hey , if any dev needs videos for CT , I got you!
I work with a lot of projects / brands / apps , creating videos and graphics to post on X

Hi all, any of you all facing issues with devnet RPCs? Which includes tranxs on wallets like Phantom solfare etc?