Earning the Solana retweet: a guide for builders
Getting amplified by @solana isn't luck. The account has clear patterns: technical depth, builder substance, ecosystem contribution, concrete numbers. Here's what works, what doesn't, and how to get your project seen.
The @solana Twitter account has roughly 2.5 million followers and consistently amplifies content across its feed. For a builder who just shipped something, a retweet from it is the difference between a quiet launch and thousands of developers seeing your work.
The account doesn't RT randomly. It has patterns — clear ones, if you've watched it long enough. This is an attempt to articulate them.
What @solana actually amplifies
The single thread running through almost every RT: substance over promotion. The account is run by the Solana Foundation marketing team, but it doesn't behave like a typical marketing channel. It amplifies content that makes the ecosystem look capable and innovative, not content that tells people the token is going up.
Categories that consistently earn RTs:
- Developer tools and SDK launches. New clients, libraries, testing tools, RPC improvements — anything that makes building on Solana easier. Especially if there are numbers: "10× faster" or "30% fewer lines of code" is retweetable. "Check out my new SDK" is not.
- Ecosystem infrastructure. New validators, RPC operators, indexers, explorer tools. The Foundation wants to show the ecosystem is deepening, not just growing in price. If you shipped something that other builders will depend on, lead with that.
- Hackathon and grant announcements. Colosseum hackathon winners get amplified reliably. Builders who share a genuine "I built this in 48 hours" demo — especially with a working link — also do well.
- DePIN milestones. Helium, Hivemapper, Render and their successors regularly get amplified when they hit real-world milestones — devices, coverage, usage. Physical networks with verifiable metrics are exactly the kind of content the Foundation wants the world to see.
- AI and agent use cases. Anything with a working demo of an AI agent doing something real on Solana — paying for an API call, executing a swap, making an on-chain decision. The category is hot; the demonstrations that show actual execution get amplified.
- Technical deep-dives. A thread explaining how Solana's priority fee market works, how CPI works, what Address Lookup Tables do — content that genuinely teaches something. These get wider reach because they're useful to developers who aren't yet in the ecosystem.
- Open-source releases. If you push something to GitHub that the ecosystem can use, use or fork, the signal to lead with is the repo and the problem it solves — not the token launch.
What doesn't work
Equally important: what the account ignores.
- Price content. "SOL is going to $1000" or "why Solana wins the cycle" — @solana does not amplify price speculation, ever. The Foundation is constrained by legal and reputational reasons, and the account reflects that.
- Generic ecosystem cheerleading. "Solana is the fastest chain" or "ETH is dead, Solana won." Comparative takes and maximalism don't get amplified. They're preaching to the converted and embarrassing to outsiders.
- Memecoin launches. Regardless of the project quality, if the first thing you're announcing is a token, the @solana account won't touch it. Wait until you have usage, then talk about what you built.
- Promotional without substance. "We're live!" with no explanation of what you built, what problem you solve, or why it's different. Every project is "live" — the question is: live doing what?
- Asking to be retweeted. Directly tagging @solana or replying to their threads asking for amplification signals that you don't have traction. Accounts with traction don't ask.
Format: what gets read and shared
Assuming your content qualifies, format matters. The posts that get the most traction on Solana X share a few properties:
- One-tweet punchy hook, then substance. The first tweet in a thread has to earn the click. Lead with the most surprising or specific thing you can honestly say: a number, a before/after, a counterintuitive fact. Then thread out the detail.
- Show, don't tell. A working demo video outperforms a feature list. A screenshot of your dashboard outperforms a description of your dashboard. If you can show the thing running, do that.
- Concrete numbers. "10× faster," "costs $0.001 per call," "500,000 accounts indexed." Vague superlatives ("blazing fast," "insanely cheap") are invisible; specific numbers are shareable.
- Tag the right people, not everyone. If you used a specific protocol or tool, tag the project. If someone directly helped you, tag them. Don't tag @solana, @helius_dev, @JupiterExchange, and twenty others in a spray of desperation — it reads like spam.
- Link to something real. A GitHub repo, a live app, a documentation page. Not a Linktree.
When to post
Timing inside the Solana ecosystem:
- During hackathons. The Colosseum cycles put builders in the spotlight — posting during or just after a hackathon, especially if you're a finalist or winner, is the highest-signal moment you get.
- Around major ecosystem events. Breakpoint, Solana Hacker Houses, major conference seasons. The Foundation is actively monitoring and amplifying ecosystem content during these windows.
- When a relevant upgrade ships. If your project directly benefits from or contributes to a major protocol change (Alpenglow, RPC 2.0, Firedancer), posting in that window ties your work to a story the whole ecosystem is following.
- US afternoon / EU evening. Peak Solana X engagement sits in the US afternoon / European evening overlap — roughly 2–8pm ET. Not a hard rule, but the data consistently points there.
Build in public, actually
The most consistent route to the @solana retweet isn't a single viral post — it's a track record. Accounts that regularly ship useful content, demo their work, explain their decisions, and contribute back to the ecosystem accumulate social trust.
"Build in public" has become a cliché, but it describes something real: the Foundation and the wider ecosystem have limited time to evaluate projects they've never heard of. A 6-month history of substantive posts is a faster credibility signal than any single announcement.
Concretely: when you make an architectural decision, post why you made it. When you hit a bug, share what you learned. When you release a feature, share a number. When you read an article that changed how you think, cite it. This isn't self-promotion — it's creating a searchable record that other builders find valuable and that the @solana account recognises as genuine.
The underlying principle
@solana amplifies things that make other people want to build on Solana. That's the filter. A working demo of something surprising, a technical post that teaches a developer something they didn't know, a milestone that proves the ecosystem is maturing — these all pass the filter. Content that makes only you look good doesn't.
Build something worth amplifying. The distribution follows.
Further reading
Keep reading
Benchmarked: Solana Foundation public RPC, Extrnode, and PublicNode across getSlot, getLatestBlockhash, getBalance, getEpochInfo, getSignaturesForAddress, and getTokenAccountsByOwner. The basic methods are similar. The indexing-heavy methods diverge by 4.5×. Published RPC 2.0 numbers push that to 24×.
v1.4.0 is the Jito-aware update: simulateBundle lets you test bundle execution locally before touching mainnet. Also new: slotUpdatesSubscribe WebSocket subscription, sysvar/feature-gate filters on snapshot export, and four bug fixes including correct memo and block_time in getSignaturesForAddress.
Every API you use today requires an account, a key, a billing portal, and a rotation policy. x402 collapses that to one HTTP header. pay.sh implements it as a single binary that wraps curl — 76 providers across AI, data, compute, messaging, finance, and more. No keys to manage. No subscriptions.