Building an Anchor/Solana program and I’m stuck because every devnet faucet I’ve tried is rate-limited or account-age gated.
I honestly just want to confirm that the wallet can receive devnet SOL at this point — even 0.01 or 0.1 devnet SOL would help.
Devnet address:2HmzjEX5whFCvfe9LxMoy6WKunfSWSc8h3F4LeVCPzoG
Devnet only — not asking for real SOL.
Many say that the market is in the worst condition. Spending money to go there will not be a good choice?
Or shall I think like this?
Going now to avoid an annoying crowd? So that I could get noticed?!
I really want to get into crypto with solana and have been learning about for the past year. I dont have any way to buy it i dont have a credit card or anything, and if someone would send me 0.005 0.01 sol it would help me alot and i would be hella thankful. If someone would dm me or reply🙏 thanks
I made a simple solana token launcher bc many of the existing ones charge $20-$50+ for something this basic
this one is all onchain and super straight forward with
low $10 launch fee
creating an SPL token
mints the amount you want to your wallet
optional authority settings
can test on solana devnet first
your wallet signs the transaction itself
is fully visible before you approve (you can even open up the tx in phantom and see exactly what it does)
the launcher itself never holds your wallet or tokens, it just creates a new token, mints the amount you want to your wallet, and pays the fee
give it a try here
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 ?
I keep seeing "Solana is booming, get in now" takes, so I want to share what the junior job hunt actually looks like on the ground, because it's rougher than the hype suggests.
The stack is there, the doors aren't. I've got Rust, Anchor, Next.js/React, TypeScript — the "should be employable" toolkit. Doesn't matter much when almost every listing on the job boards is for mid/senior engineers. Scroll through any Solana-focused job board and you'll notice the same thing: 2+ years experience, "ship fast," "own a product area." Very few roles are actually scoped for someone one or two years into their career.
Cold outreach mostly goes nowhere. I've DMed people at teams I respect, kept it short, led with skills instead of one flashy project, tried to be useful instead of needy. Most get ignored. A few get a polite no. That's just the base rate — doesn't mean the approach is wrong, it means the funnel is that narrow.
Even when you get a process going, it can still end in "not a fit." Applied to a security research role, went through an actual coding challenge (bytecode/calldata analysis), and still got a no. That one stung more than the ignored DMs because it meant I was close enough to get a real look — just not close enough.
What's actually working (or at least feels less like screaming into the void):
Superteam Earn bounties — visible work, visible name, no gatekeeper
Open-source contributions to stuff people already use (Anchor, SDKs) — commits are a resume that talks back
Twitter/X presence — half of Solana hiring seems to happen in someone's replies, not on a job board
Direct, specific outreach to smaller/newer teams instead of the 5 names everyone already knows
Basically: the ecosystem isn't short on junior talent, it's short on junior roles. If you're trying to break in, the job board is not where it happens. It happens in Discords, in bounty leaderboards, in "hey I fixed this thing you didn't ask for" DMs. Slow, and no guarantee, but it's the only funnel that's actually open.
If anyone else is in the trenches on this — what's actually worked for you?
I'm building QAL, an early-stage blockchain infrastructure project focused on commitment integrity rather than token issuance.
What I'm building: an exact private artifact can be sealed locally; QAL anchors its fingerprint/commitment record to Solana. The original artifact can remain private/off-chain. Later the commitment can be independently verified and its lifecycle can show active, revoked, superseded, or disputed.
Who it's for: initially developers and teams that make claims/disclosures/promises where a mutable webpage, screenshot, or PDF isn't a strong enough historical record. One concrete vertical I'm testing is crypto/memecoin teams making wallet, mint, treasury, LP, or incident commitments.
Stage: pre-alpha / protocol hardening. I have an interactive educational demo and verifier, but I'm not presenting it as audited production infrastructure yet.
Demo: https://bestmemecoins.app/
What I want feedback on: does the commitment-history layer add enough beyond 'publish a hash somewhere,' and which use case has enough pain to justify integrating it?
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.
Hey guys, I built this dApp, which you can find at grindflow .run
Basically, it’s a bot that works with all the coins on Solana. You can set a buy trigger after a drop and a sell trigger after a rise.
I’ve had some interesting results using a buy trigger at -47% and a sell trigger at +10%.
Thanks to Lit Protocol, I don’t have control over users’ private wallet keys.
I’d love to get some feedback from you guys — any thoughts, suggestions, or ideas for improvement are more than welcome!
Thanks!
Anyone else here facing Cargo and blake version clash? And how did you solve it? I've been at this for over 24hrs and it's frustrating.
Full disclosure: this is my project.
I’ve been building PumpFunBot around a pretty specific split:
The desk is self-funded: you create/fund your own boss + worker wallets and run the available micro-trade / wave / random-walk strategies from the dashboard. The current plans are 1 SOL / 2.5 SOL / 5 SOL for different access windows.
Important distinction: I’m not selling a ranking guarantee or pretending paid activity magically creates organic demand. It’s an on-chain operations tool and the site says that plainly.
The part I’m most interested in feedback on is whether the product separation is clear enough. Scanner users should be able to use the free side without being forced into the operator tool.
If you run Solana launches, what would make the operator desk materially more useful?
AgarStake is a no-download multiplayer arena inspired by Agar.io and Slither.io. Enter with SOL, grow, split, survive and try to leave with more than you started with. It is designed for short, competitive browser sessions rather than passive “earn” mechanics.
18+ only. Stakes can be lost, returns are never guaranteed, and access may be restricted in some regions. Developer/self-promotion disclosure: I built it.
Play here: https://agararena.space
Most Token-2022 discussions focus on Transfer Hooks and Confidential Transfers. I spent some time testing four of the smaller extensions on Devnet, and they cover a surprising amount of application-level logic.
The four extensions are:
Permanent Delegate gives one authority transfer and burn rights across every account associated with a mint. That is useful for regulated assets, subscriptions, and recovery workflows, but it also creates an authority that users need to understand before accepting the token.
Non-Transferable makes the restriction part of the mint itself. There is no wrapper program or freeze workaround. Transfers fail at the token program level, while the holder can still burn the asset.
The interesting part is combining it with Permanent Delegate. You can model prepaid API or compute credits as fungible tokens that users can hold but cannot resell. The protocol backend burns credits as the service is consumed.
Default Account State covers a different problem. New token accounts can begin frozen and remain unusable until an authority explicitly thaws them. That gives regulated protocols a native account-level approval flow.
Required Transfer Memos is applied by the receiving token account rather than the mint. It forces incoming transfers to include transaction context, which is useful for exchange deposits and treasury accounting.
The trade-off is clear: Token-2022 removes a lot of custom wrapper code, but it moves more policy and authority into the token configuration itself. Wallets and explorers need to make those permissions very visible.
I documented the Devnet tests, SPL CLI commands, and Solscan transactions here:
https://andreyobruchkov1996.substack.com/p/the-utility-extensions-completing
Which of these extensions would you trust in a production asset, and what warnings should wallets show before a user receives one?
🔊 - Good Morning! Jump_in_Jack here!
💡- In light of some stuff coming up in the not so distant future. I made a new role on our discord to identify who is running bots.
📤 - Once every two weeks I will have a raffle draw for a lucky JiJbot User, on our discord, to recieve a FREE Gominer.
You will need to sign up to Gominer to receive it through the referral link unless you already have a Gominer account.
https://gomining.com/?ref=X71MRYX
Thank you all for being part of JiJ and JiC.
📰 - First Draw will be Tuesday Aug. 25th 2026
So head over to https://www.jumpinjack.ca to download your FREE JiJbot and get rdy to win a gominer.
Visit the announcement section on our discord --> https://discord.gg/VbMS4z9qNM be added to the draw.
~JiJ
I've shipped a few small Solana things a recurring payments program, some Telegram bots and I'm trying to figure out what to build next , and I wanna build for actual users and a valid pain , if you have any kindly share
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.