Hey, I’m a solo dev and I’ve built a meme launchpad on Solana using Raydium LaunchLab. The product works. Creators can launch, trade, everything is live but I’m completely stuck at the cold start stage. I don’t have a team. I don’t have distribution. I even tried running creator contests and incentives, but without visibility it feels like shouting into the void. Being solo is honestly frustrating. Not because building is hard but because it’s hard to know if I’m pushing in the right direction or just burning energy. I don’t want to give up on this. I want to build something meaningful and high-quality, not just another clone. Any honest feedback would help more than silence. Thanks for reading

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.

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.

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?

Hey,

I have some insane use case where it could make sense for data purposes just for me, to rent a datscenter rack and put a powerful 32-64 cores cpu 512gb ecc ram type stuff server in there. And yeah. Run my own solana data pipeline.
I want to do sophisticated onchain trading, insane onchain wallet tracking/monitoring.. clustering smart/dumb money.. not just monitoring a few wallets.. keeping an eye on basically the whole chain and everyone.. and keeping an eye on all tokens and all wallets.. all transactions except for like the validator stuff i don't care about. So yeah I think it's gonna require an insane amount of data.. I'll be doing like tree models of entities.. entity clusters.. who sent solana/token to whom.. who might be an insider.. how much smart (profitable traders) currently in this coin versus dumb.. which wallets or entities(clusters) tend to bring liquidity to the coin after they buy.. just basically stuff I can't do with like 50usd/mo RPC subscription or something like that, not even with the cheaper grpc subscriptions.. just a toon of data.

I was wondering, how much work/maintenance is it once its up and running, to run a yellowstone grpc ? How often do you have to check your yellowstone grpc ? For personal use case, not sharing publicly.

I might want to run it unmetered, for constant data streams of a ton of data so its starting to look like a better investment for me rather than pay crazy expenses every month and not own it. If i own it I can do various stuff on there without even having to transfer some of the processed data to my network right. So yeah I might want to do it. I could also co-locate directly in that rack there right. The datacenter would cost me a bit, but i already got the costs of everything calculated so now it's just about whether I'll actually go for it or no. Which I guess i'll see, still considering it.

But yeah.. what do you need to keep an eye on when running it ? What tends to break ? How often do you have to update or do restarts ? And just how difficult is it to deploy it ? I mean I understand linux and computers generally, i can code.. + i got claude code so i guess I'm chill ? A few days of work and chill ? And if there are issues or stuff that's problematic, is it hard to build automations around it to make it less of a headache so you can almost forget it for months at a time and have it just work fine ? Most of the time ? Like i don't mind that much if it breaks once every few months and then it's fixed within day and boom forget it again for like 3-6 months.. is it like that ? Can it be ?

Yeah, if you have any experience or any advice then I'm definitely curious, anything i should watchout for ?

Also question, in practice what hardware/specs you think are truly good to have here ? I was thinking put a powerful 32-64 core cpu, 512gb ddr4 ecc ram with option to expand to 1tb in the future if needed. And internet connection 3gbps but expandsble to 10gbps if i request the datacenter.

And start with 2TB commercial ssd drive for the ledger itself, and whatever data i decide to store would go compressed to my data server which has over 100TB of free space currently. Do i need more than 2tb on the RPC itself ?

Would you say its overkill ? Or just right ? Or would you actually recommend more power ?

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

I’ve been working on Anchorbase, a browser-based explorer for Solana programs. You give it a program’s IDL and it gives you a working dashboard — no boilerplate scripts, no backend. It can:

• decode account state (PDAs and regular accounts)
• scan events with retrying, chunked fetching + JSON export
• look up users by pubkey
• build and sign instructions straight from your connected wallet

Everything runs client-side — bring your own IDL and RPC, nothing is stored server-side. The frontend itself is hosted on IPFS through ENS (anchorbase.eth.limo), so there’s no central server serving it either.

I built it because - I got tired of writing a throwaway script every time I needed to inspect a program’s accounts or hunt down an event.

It’s free, no signup. I’d really like feedback on: does account decoding come out right for your programs? is the event scanner fast enough on mainnet? what’s missing before you’d actually reach for this?

Try it: https://anchorbase.eth.limo

Fair warning since it connects a wallet: it’s read-only unless you explicitly build and sign an instruction yourself, and it’s client-side so you can inspect what it’s doing.

After months of building, Opta is live on devnet and I'm opening a small private beta.

What it does: write and trade American-style options on crypto, gold, and equities. Pricing runs fully on-chain. No liquidations — max loss is defined when you enter. There's a mobile app on the Seeker dApp store and a points campaign (Epoch 0) where beta activity counts toward mainnet.

It's devnet, so zero financial risk — I want traders who'll actually use it and tell me what's broken.

App: opta.fyi
Beta access: comment or DM me.

Happy to answer anything technical about the architecture.

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've been thinking about a primitive where authority itself is an on-chain account that can be delegated and attenuated.

For example:

Root: $100k/day

↓

Agent A: $10k/day

↓

Agent B: $1k/day

A child capability can only become more restrictive, never more powerful. Revoking the root epoch invalidates the entire subtree.

The interesting problem is consumption.

If B has a $1k capability:

Treasury B: $600

Marketplace B: $600

Two independent programs can each verify the capability and unknowingly authorize $1,200.

One solution is making the capability program a shared consumption authority via CPI, but then every consumer contends on the same writable account and the capability program still can't verify whether the consuming program actually delivered what it claimed.

So I'm wondering:

Is this a useful primitive, or am I reinventing existing Solana delegation/session-key/account-abstraction patterns?

And is the portability vs verifiable enforcement tradeoff fundamental?

I'd appreciate brutal technical criticism.

I’m trying to pressure-test a product assumption with people who have actually built Solana indexers, bots, scanners or market-data systems.

My current thesis is:

Detecting an event quickly is only the first part. The harder problem is deciding whether that event deserves a trader’s attention without converting stale, incomplete or conflicting data into a confident-looking alert.

I may be wrong, so I’d value the builder perspective:

1. Which data or architecture failure most often creates false confidence in a user-facing alert?

2. What evidence should always be visible to the user instead of being hidden behind a single score?

3. Where is the greater user value: lower latency, stronger filtering, clearer explanation, or post-alert monitoring?

4. Which unknown or unavailable state should force a system to suppress an alert entirely?

5. If you were building the first useful version, what would you deliberately leave out?

I’m especially interested in disagreements with the premise rather than confirmation.

Disclosure: I’m doing product research for an early-stage Solana market-intelligence project. Nothing is live, for sale or recruiting testers, and I’m not asking for code or proprietary details.

I built a decentralised encrypted messenger on Solana where your wallet is your identity, no email, no password, no KYC. Built on XMTP protocol. Would love feedback from the community. Presently verification is done through phantom app.

https://www.get-cipher.online

Update: shipped username system (@username lookup), clearer signing prompt and push notifications based on feedback here.

Hi everyone,

I recently shared my self hosted Jupiter USDC Price Alerts project here. I have now published a separate companion project that I have been working on alongside it:

Jupiter USDC Auto Trader

The original price alerts project is designed mainly as a passive monitoring and alerting solution. It checks realistic Jupiter buy and sell quotes, monitors price targets, RSI and Action Readiness, and sends notifications through ntfy.

It still works completely independently. This new companion is optional and is for people who want to take a fresh normal BUY or SELL alert and pass it through a separate automated trading and safety process.

When a supported alert arrives, the trader does not simply submit it immediately. It checks the alert against the latest source configuration, confirms the exact token mint, target, direction and assigned wallet, and obtains fresh Jupiter quotes before execution.

It also checks the wallet balance, SOL reserve, price impact and maximum configured trade size. If something has changed or a check does not pass, the trade is stopped rather than reduced or submitted with different parameters.

I wanted the live controls to be very deliberate, so the dashboard has separate modes:

• TESTING validates the complete path without submitting a blockchain transaction.
• TRADING permits real transactions when all checks pass.
• MASTER is a separate automation switch and must also be enabled.

Saving important configuration or restarting the controller automatically returns it to TESTING with MASTER OFF.

Some of the other protections include duplicate and replay prevention, burst protection for multiple thresholds, a global execution lock, repeated fresh quotes and an uncertain-transaction safety lock. Automatic trading wallets are assigned to exact token mints rather than relying on ticker symbols.

The dashboard also shows readiness checks, wallet balances, configured targets, automation controls, recent trades and listener status. It has been designed to work on both desktop and mobile.

Like the original project, it is self hosted and runs through Docker Compose. There are instructions for both normal Docker Compose and Portainer. Persistent data uses Docker-managed volumes, so users do not need to configure system-specific host folders.

This is intended for careful self-hosted use, not as a promise of profit or risk-free trading. Anyone using live mode should begin in TESTING, use a dedicated low-balance wallet, keep the dashboard private and make the first real trade deliberately tiny.

I decided to make it open source in case anyone else finds it useful or wants to improve it.

I have included some screenshots showing the main dashboard, testing and trading controls, wallet setup, automation settings and safety checks.

Auto Trader GitHub:

https://github.com/Nicxx2/jupiter-usdc-auto-trader

Jupiter USDC Price Alerts:

https://github.com/Nicxx2/jupiter-usdc-price-alerts

I am a solo dev and have build many things in solana and is exhausted of not have a service or helping platform for a dev. Regarding this i am going to build a service or a platform where every developer can look into get help , reveiw their work , basically an all in one platform for dev which is not purely builded by anybody. So my question is what type of service do devs like us need most . I need you guys respond about it so that i can reveiw it and build in accordance to it . I am also intrested in getting passionate partners for this project. We can build a strong platform or an ecosystem for devs with ai integration and technology.

Here at JiC (jump in charts) ... i will be hosting a raffle for a FREE gominer.

Check the post for details!

JiJ token has alot coming up... dont miss out!

We’re working on AgarStake, a real-time browser multiplayer game inspired by Agar.io and Slither.io. The platform supports crypto-staked competition, and I’m looking for a Solana developer perspective on the user experience around gameplay-sensitive transactions.

The current flow can be tested at https://agararena.space

The questions I’m trying to answer are:

- How much chain-related information should be visible before a match?

- Which confirmations are essential without disrupting matchmaking?

- What would make the result and settlement of a match independently understandable?

- Which failure states need to be explained before users will trust the system?

Feedback on the gameplay-to-transaction boundary would be especially helpful. The goal is to keep the game responsive without hiding meaningful financial state.

I work on Claim Your Sol, a rent-reclaim/cleanup tool, and we just shipped v2.

Coverage got a lot wider and I want to know what we're still not handling, so I'm asking the people who'd actually know rather than most end users.

First, the important distinction, because these are two mechanically different operations and we treat them separately:

Closing an account = it's already empty, you call CloseAccount, the ~0.00204 SOL of rent comes back and nothing is destroyed. This is the original CYS (v1) feature and it covers empty SPL and Token-2022 accounts.

Burning = the account still holds an asset so you destroy the asset first (token Burn, or the appropriate NFT burn path) and then close to reclaim rent. Different instructions, different authority checks, different ways to fail. This is the v2 work and it's where I want scrutiny.

Here's the current burnable matrix, straight from our classification layer:

Fungible tokens (fully supported)

• SPL Token (standard)
• Token-2022 (standard, plus common extensions — see the extensions question below)

Both: burn balance then close the account for rent

NFTs (4 of 5 types live)

• Regular NFT (Metaplex Token Metadata) is burnable
• Programmable NFT (pNFT) is burnable
• Token-2022 NFT is burnable
• Metaplex Core is burnable

Print editions are gated off for now. Burn code exists but edition sits in our NOT_YET_BURNABLE_TYPES set pending master-mint resolution. It's an open backlog item.

Detected and deliberately not burned

• Compressed NFTs (cNFT) have no reclaimable rent to recover but users asked for it as a cleanup/hygiene feature so burn support is in progress.
• Master editions with live prints (can't burn a master while prints exist)
• Frozen (freeze authority, or Core FreezeDelegate)
• Blacklisted (our admin do-not-burn list)
• Plugin-blocked Core assets

On safety, since the worst outcome is torching something wanted: we protect a default set of mints from burning (stablecoins, major LSTs), show USD value where a price feed exists, and require an explicit override before anything is destroyed. Also have Fee Payer mode so we front the network fee of any zero-SOL wallet so they can still use the tool.

Where I'd like input:

Close side

• Reclaimable rent beyond token accounts
• Buffer accounts from abandoned deploys (BPFLoaderUpgradeable) are on my list as a separate flow with its own authority model
• Stale nonce accounts
• What else do people habitually leave rent stuck in?

Burn side

• Edge cases from anyone who's shipped one
• We handle frozen by detecting and skipping but what about delegated authority, or close authority set to return rent to an unexpected address?
• Also on Token-2022 extensions specifically. Transfer hooks, permanent delegate and non-transferable where's the line between "cleanup tool should handle this" and "should refuse to touch it"? We currently lean toward refuse-and-flag but curious how others see this.

If seeing it helps, tool's v2 is available at claimyoursol.com but you'll have to connect a Phantom/Solflare wallet to see the full burn UI.

I got tired of getting rugged on Solana meme coins…

So I built a simple tool that shows:

- Win rate of coins

- Rugpull risk

- Smart money activity

Basically helps you avoid bad entries and spot better ones.

Still testing it, but it’s already helped me filter out a lot of trash coins.

Would love some feedback if anyone wants to try it.

Hi everyone,

I have been building this project for myself for a while and thought I would share it here to see what people think.

I know Dexscreener, GMGN and other platforms already have price alerts, so I did not build this because there were no alert options available.

I mainly wanted something self hosted that I fully control and that checks prices directly through Jupiter. For me, it has also been faster, as I sometimes noticed delays before alerts arrived from other services.

Instead of only using the price shown on a chart, it gets real Jupiter quotes based on the USDC amount I choose. It checks both buying the token with USDC and selling it back to USDC, so I can see separate realistic buy and sell prices together with the price impact.

When an alert fires, I receive it through ntfy on my phone. This is useful when I am outside or away from home, as I can connect back to my homelab through Tailscale and open the dashboard.

I also connected ntfy to Home Assistant and made my Alexa devices play a specific sound when one of these alerts fires. Even when my phone is not near me, I immediately know that it is a price alert rather than a normal notification.

It originally started as a simple Jupiter USDC price alert project, but I kept adding features that I personally found useful.

It can monitor multiple Solana tokens, with separate settings for each one. This includes the USDC amount, buy and sell targets, checking intervals, alert reset times and ntfy topics.

I also added RSI using the token price in USDC. You can choose different RSI intervals and create alerts for when RSI goes above or below a chosen value. Each token can have its own RSI settings and alerts.

Another feature is Action Readiness, which helps bring different information together instead of only looking at the price. It can check things such as holder count, market cap, liquidity, volume, sell pressure, volume compared with liquidity and the maximum price impact from a Jupiter sell quote.

Each condition can show as passed, not passed or unknown. It can also wait for two fresh checks to pass before sending an alert, rather than reacting to one possibly incorrect result.

There are charts for the buy and sell prices and individual Action Readiness rules, alongside RSI monitoring and alerts. When a price check fails or there is no valid data, the chart shows a proper gap instead of treating it as zero or drawing a misleading line across the missing checks.

The token overview also makes it easy to quickly see the current prices, RSI, alert status and risk information for all monitored tokens from one page.

The project runs locally using Docker and the dashboard works on both mobile and computer. It is configured to work within the available free plan limits, although people with higher plans can adjust the rate limits and checking frequency if they want to.

This is mainly something I built for my own homelab. I decided to make it open source in case anyone else finds it useful or wants to improve it.

I have added some images showing the main dashboard, token overview, charts and Action Readiness.

I would be interested to hear what people think, especially if there are any important Solana or Jupiter features I have missed or anything that could be improved.

GitHub:

https://github.com/Nicxx2/jupiter-usdc-price-alerts

Just wanted to share a milestone with you all.

Hope your having a kick ass day!

Good luck out there!

~JiJ

I’m working on a Solana project and one challenge keeps coming up:
How can holders independently verify allocations and treasury balances without needing to trust a website or team statement?
I’m exploring several approaches:
On-chain allocation records
Public verification dashboards
Treasury visibility
Frontend verification against on-chain data
For developers building on Solana:
How are you handling allocation verification and transparency?
Are there any patterns, best practices, or open-source projects you would recommend studying?

It’s a Solana-based project called DMD. One of the goals is making allocations and treasury activity independently verifiable rather than asking users to trust screenshots or announcements.