Skip to main content

Publish your Token-2022 trilogy on DEV

Turn a week of Token-2022 experiments into a public DEV post that shows what you built, why it matters, and what each extension is for.
Publish your Token-2022 trilogy on DEV background
View Your Submissions
Challenge

Publish your Token-2022 trilogy on DEV

The Scenario

When you built the feature at work, your job was not finished. The next job now was to make sure the team understood why it existed and how to use it. That write-up almost always outlived the feature, because new hires kept finding it during onboarding and senior engineers kept linking to it in design reviews.

The same pattern lives in the open source world, just on a public surface. Developers who ship interesting things write about them on DEV, and those posts become the artifacts that recruiters, conference organizers, and grant programs actually read. You have spent the last week shipping interesting things. Your Day 50 and 51 mint skims a fee on every transfer. Your Day 52 mint stacks interest on top of that fee. Day 53 audited every extension you had baked in. Day 54 you built a token that refuses to move at all. That is a real Token-2022 portfolio, and right now it lives only in your terminal history.

Today you are going to turn that terminal history into a public artifact. You will write a single dev.to post that walks a curious Web2 developer through the three mints you shipped, what each Token-2022 extension actually does, and when somebody would reach for one. By the end of the day, the work is no longer just yours. It is searchable, linkable, and indexed.

The Challenge

What you’ll need

  • A dev.to account, free to create with GitHub, Google, or email
  • The three Token-2022 mint addresses you shipped during this arc, all on devnet
  • The Solana Explorer open to devnet so you can grab links and screenshots of each mint
  • Your terminal history or notes from Days 50 through 54 so you can quote the exact spl-token commands you ran

Steps

  1. Sign in to DEV and open the new post editor.
  2. Give the post a title that promises something concrete. Something like Three Token-2022 mints in one week: fees, yield, and soul-bound works because it tells a Web2 reader exactly what they will get.
  3. Open with a one paragraph framing for a developer who has never touched Solana. Explain that Token-2022 is the upgraded SPL token program and that extensions let a single mint opt into behaviors like fees, interest, and transfer rules without forking the protocol. Use the middleware analogy you have been building on all week.
  4. Add three sections, one per mint. For each section include the mint address, a link to it on the Solana Explorer, the extension you used, and the exact spl-token command you ran to create it. Wrap commands in fenced code blocks so dev.to renders them with syntax highlighting.
  5. For the transfer fee mint from Days 50 and 51, explain in one or two sentences when a builder would actually want this. Royalties on a creator token, a protocol fee on a stablecoin, a treasury skim on a community currency. Pick the example that resonated with you.
  6. For the interest-bearing mint from Day 52, be honest about what the extension does and does not do. The on-chain rate updates the displayed UI amount; it does not mint new supply. That distinction is the kind of subtle thing your future readers will thank you for spelling out.
  7. For the non-transferable mint from Day 54, share the error you got when you tried to transfer it. Quoting the exact runtime rejection makes the post feel like real engineering, not marketing.
  8. Close with a short reflection. What surprised you? What would you reach for these extensions for in a real product? One paragraph is enough.
  9. Add tags before publishing. Use #100DaysOfSolana, #solana, #web3, and #tutorial. Dev.to allows up to four tags per post.
  10. Hit Publish, then copy the live URL.

What Just Happened

You just translated a week of terminal commands into something a stranger can learn from. That is a meaningful shift. Until today, your Token-2022 work was tacit knowledge that lived in your shell history and your head. Now it is explicit, public, and searchable on a platform that the developer community actually reads. DEV indexes well, gets crawled by Google, and is one of the first places junior developers land when they search for hands-on Solana content.

The post itself is also doing portfolio work for you. When somebody scrolls your dev.to profile six months from now, they will see a developer who can use the Token-2022 program, who understands what extensions are for, and who can explain those choices in plain language. That last skill, the explaining part, is the one that separates engineers who ship from engineers who lead. You practiced it today.

One quiet bonus: by writing the post you almost certainly caught at least one thing you did not actually understand. That moment of “wait, why does the interest extension work that way” is the real payoff of documentation. Writing exposes the seams in your mental model, which is exactly why your tech lead kept nudging you toward it back in your Web2 life.

Resources

Submission

Publish your post on DEV with the #100DaysOfSolana hashtag.

Submit your project