Skip to main content

Write about transactions

Share what you've learned about transactions.
Write about transactions background
View Your Submissions
Challenge

Write about transactions

The Scenario

Over the past several days, you’ve gone from knowing nothing about Solana transactions to building and sending them, reading their results on-chain, and even breaking them on purpose to understand how they fail. You’ve seen signatures, instructions, blockhashes, and compute budgets in action. That’s a lot of ground covered. Now it’s time to slow down and do something that will cement all of it: write about it.

If you’ve ever kept notes while learning a new framework or language, you already know how powerful writing is for retention. Explaining a concept to someone else forces you to confront the gaps in your own understanding. Today, you’re going to publish a technical blog post about Solana transactions on DEV, turning what you’ve learned into something that helps the next developer who starts this journey.

The Challenge

What You’ll Need

  • A DEV account (free to create)
  • Your notes, code snippets, and terminal output from the past few days of transaction challenges
  • The Solana Transactions documentation for reference

Steps

  1. Pick your angle. A good technical blog post doesn’t try to cover everything. Choose one aspect of Solana transactions that clicked for you, surprised you, or tripped you up. Some ideas:
    • How Solana transactions differ from API calls you’re used to in Web2
    • The anatomy of a transaction: signatures, instructions, accounts, and the recent blockhash
    • What you learned from exploring failed transactions on devnet
    • How Solana’s 1,232-byte transaction size limit shapes the way developers build
    • The mental model shift from “request/response” to “atomic on-chain state changes”
  2. Outline before you write. Structure your post with a clear beginning, middle, and end. A reliable format for technical posts:
    • Hook: One or two sentences that set up the problem or question
    • Context: What the reader needs to know before diving in
    • Core content: Your explanation, with code snippets or screenshots from your own work
    • Takeaway: What you want the reader to remember
  3. Include real examples. Pull from your own experience this week. Paste in a code snippet you wrote, a terminal output you captured, or a screenshot from Solana Explorer. Readers trust posts that show real work, not just theory. If you explored failed transactions yesterday, that output is great material.
  4. Use Web2 analogies, then let them go. Your readers might be in the same position you were a few weeks ago. Compare a Solana transaction to something familiar, like an HTTP request or a database transaction, but be honest about where the analogy breaks down. For example: both Solana transactions and database transactions are atomic (all-or-nothing), but Solana transactions also require cryptographic signatures and expire after roughly 60 to 90 seconds based on the recent blockhash validity window.
  5. Publish on DEV. Log in to DEV, click “Create Post,” paste your content, and add these tags: solana, blockchain, web3, 100daysofsolana. Give your post a clear, specific title. “What I Learned About Solana Transactions” is fine. “Solana Transactions Explained for Backend Developers” is even better because it tells a reader exactly who the post is for.
  6. Review before you hit publish. Read it once out loud. Check that your code snippets are formatted with proper Markdown code blocks. Make sure any links you include actually work. Then publish it.

What Just Happened

You turned learning into teaching. Writing a technical blog post is one of the most effective ways to solidify what you know, and it’s a skill that compounds over time. Every post you publish builds your public portfolio, helps other developers, and makes you a more thoughtful communicator. In Web2, developers who write well stand out. In Web3, where the ecosystem is younger and documentation is still catching up, a clear explanation of how things work is even more valuable.

You also practiced a core developer skill that has nothing to do with code: organizing technical knowledge for an audience. Whether you end up writing docs, RFCs, or pull request descriptions, the ability to explain complex systems clearly is something you’ll use for the rest of your career.

Resources

Submission

Share the link to your published DEV post in the project submission below.

Submit your project