Skip to main content

Turn your checklist into a thread that travels

Adapt your Solana security checklist into a clear, practical thread for other developers.
Turn your checklist into a thread that travels background
View Your Submissions
Challenge

Turn your checklist into a thread that travels

Yesterday your security checklist went live on DEV with your name on it. Today it earns its second life. A checklist sitting at a single URL helps the people who happen to find it; the same checklist broken into a sharp, scannable thread can reach a developer who did not know they needed it until your hook stopped their scroll. Amplifying is not bragging. It is closing the loop on a month of attacker-minded work so the lessons land where other builders actually hang out.

There is a real audience for this. Solana security writeups get bookmarked, quoted, and passed around precisely because the stakes are concrete: a missing owner check cost Wormhole $326 million, and a single absent constraint minted billions of fake CASH out of Cashio. You spent the last week reproducing exactly those failure classes. That gives you something most “10 lessons I learned” threads never have: receipts. Today you package those receipts so they travel.

The scenario

Your checklist post has a handful of views, mostly from people who already follow the hashtag. Meanwhile, on X, a developer two weeks into their first Anchor program is about to ship a vault instruction with no has_one constraint and no owner check. They are not going to read a 2,000-word audit guide tonight. But they might read eight tight posts that say, in plain terms, “here are the five checks that would have stopped the biggest Solana hacks, and here is the one-line Anchor constraint for each.” Your job today is to be the thread that reaches that person before the exploit does.

The challenge

Adapt your published security checklist into a developer thread for X (or a LinkedIn post, if that is where your audience lives), publish it, and link back to the full dev.to writeup so readers can go deeper.

What you’ll need

  • Your published security checklist from Day 83 (the dev.to URL)
  • An X account (or LinkedIn, whichever fits your network)
  • A text editor or notes app to draft the thread before you post it
  • Optional: a screenshot of one failing test from your Wormhole/Cashio reproduction (Day 82) to use as the thread’s visual

Steps

  1. Pick the spine of your thread. Open your checklist and choose the 5 to 7 items that carry the most weight: owner checks, signer checks, account validation (has_one / constraint), arithmetic safety (checked math, no silent wrapping in release builds), and account-type confusion. These are the categories Neodyme reports finding over and over in real audits, so leading with them is honest, not arbitrary.
  2. Write the hook first, and make it stand alone. The opening post has to earn the read by itself. Skip the worn-out “I spent 10 years…” template. Anchor it to something concrete you actually did: for example, “A missing owner check drained $326M from Wormhole. Last week I rebuilt that exact bug in a tiny Anchor program to watch it happen. Here are the 5 checks that stop it 🧵”. Keep it specific and true to your own work.
  3. Give each post one idea. Devote one post per checklist item. State the risk in one line, then show the fix in one line. A pattern that reads well: “❌ The bug: program trusts an account without verifying its owner. ✅ The fix: in Anchor, add owner = expected_program or use a typed Account<'info, T> so the framework checks it for you.” Short beats clever here.
  4. Use one visual. Threads with an image in the first or second post stop more scrolls. A screenshot of your own failing-then-passing test from the exploit reproduction is perfect: it proves you ran the attack, you did not just read about it.
  5. Close with a clear next step. The final post should send people somewhere. Link the full dev.to checklist for the readers who want every item, and invite a simple action: “Full checklist (every item + code): [your dev.to link]. Building on Solana? Bookmark it before your next deploy.”
  6. Tag it so it gets found. Add #100DaysOfSolana and one or two relevant tags like #Solana or #Anchor. Two or three tags is plenty; a wall of hashtags reads as spam and dilutes reach.
  7. Post when your people are awake, then stick around. A post does most of its work in the first 60 to 90 minutes, so publish when your audience is active and reply to the first few comments. Engaging early signals the post is worth surfacing to more people.

Run it

There is no terminal command today; your “run it” is hitting publish. Before you do, read your thread top to bottom once, out loud if you can. Check that the hook works with zero context, that every fix line is technically correct (an Anchor constraint that does not exist helps no one), and that the dev.to link actually resolves. Then post the thread.

What just happened

You took private, hard-won knowledge and made it public and findable. That is the same move the best security researchers make: the value of an exploit lesson is not in knowing it, it is in how many builders ship safer code because you said it out loud. By translating your checklist into the format and rhythm of the platform, you met developers where they already are instead of waiting for them to find your blog.

You also did something for your own credibility. A thread that explains the Wormhole owner-check bug, shows a real test reproducing it, and hands over the exact Anchor constraint that prevents it is a portfolio piece. It signals that you can think like an attacker and write like a teacher, which is precisely the profile teams look for when they need someone to harden a program before mainnet. Your reproduction work from earlier this week was the proof; today you turned it into reach.

Resources

Submission

Share your DEV post far and wide on social media and include the #100DaysOfSolana hashtag so the community can read, bookmark, and reshare it. Then submit a link below.

Submit your project