DEV Community: Amir of Ekiti

# Web3 Dev Is Not Hard — It’s Just Different

Amir of Ekiti — Tue, 08 Jul 2025 19:23:26 +0000

“It’s not that Web3 is hard. It’s just that everything you think you know — changes.”

💭 The Misconception

When I first dipped into Web3, I thought I needed to unlearn everything:

Solidity looked strange
Wallets felt clunky
Testing was painful
And don’t get me started on uint256

But the truth is: Web3 development isn’t hard. It’s just... different.

And once you stop comparing it directly to Web2, it actually becomes exciting.

🧱 What’s Actually Different?

Let’s break it down:

1. No Backend? Wrong — the Backend is the Blockchain

In Web2, the backend is your server or cloud stack.

In Web3, the smart contract is your backend — deployed on Ethereum, Polygon, etc.

You can’t patch code (unless you build for upgrades)
Everything is public
Every state change costs gas

✅ You don’t write to a database — you write to an immutable ledger.

2. Frontend Stays Familiar — But Needs to Be Wallet-Aware

Your React/Vue app still works. You still use JavaScript.

The difference?

You don’t log in — you connect a wallet
You don’t call an API — you call a smart contract
You don’t store state off-chain — you watch the chain for changes

Learning libraries like ethers.js, viem, or wagmi bridges the gap.

3. Testing Is Less "Unit", More "Chain Simulation"

Forget mocking a function call.

In Web3, you want to simulate real transactions:

Will this revert?
How much gas will this use?
Does it behave differently when called from another contract?

Tools like Hardhat, Foundry, and Tenderly help answer these.

4. You Can’t Hide Your Mistakes

There’s no console.log in Solidity (well… kind of).

Every mistake you deploy is public, permanent, and traceable.

But that’s also empowering.

You write contracts that live forever
Others can build on them
Users own their data

It forces you to build like you mean it.

🚀 What Helped Me Transition

Here’s what clicked for me as I went from Web2 to Web3:

Start simple: deploy a HelloWorld.sol to Sepolia
Learn how to read/write contract state from a frontend
Don’t chase DeFi complexity — focus on how the chain works
Use testnets like they’re real. Simulate flows, not just function calls
Get curious: inspect contracts on Etherscan, decode ABI, watch logs

And the biggest mindset shift?

💡 You’re not just writing code — you’re publishing logic into the world.

🎯 So, Is Web3 Dev Hard?

No.

But it’s unforgiving, transparent, and trustless by design.

And once you embrace that…

You realize how fun, fast, and full of potential it is to build for the chain.

💬 Your Turn

If you're a Web2 dev making the jump to Web3:

What confused you at first?

What helped you finally “get it”?

Drop your thoughts in the comments — let’s help each other build better, together.

Thanks for reading 🙌

Follow me for more Web3 dev insights, beginner-friendly smart contract tips, and honest lessons from the chain.

# Why Your First DApp Should Be Boring (and What Mine Taught Me About Blockchain Reality)

Amir of Ekiti — Tue, 08 Jul 2025 14:30:22 +0000

When I built my first decentralized app, I had visions of disrupting DeFi, scaling NFTs, and maybe even minting the next viral meme token.

Instead, I built... a simple "read/write" contract that stored notes on-chain.

And it was the smartest decision I could’ve made.

🚧 Chasing Complexity (Too Early)

Before I understood Solidity properly, I was already sketching ideas for lending protocols and on-chain games. But something kept nagging at me:

How do contracts store data long term?
What happens if a write fails?
How do I debug transactions after they succeed but don’t behave as expected?

The more I experimented, the more I realized I was skipping the basics.

So I did something "boring."

📝 The DApp That Just Stored Notes

I built a minimal dApp that did exactly two things:

addNote(string memory content)
getNotes() returns a list of notes

Each note was tied to msg.sender. Just text — no tokens, no randomness, no cross-chain hype.

But this boring dApp taught me everything I needed to know:

How contract storage works
How to handle mappings and arrays
Why gas costs matter
How to emit logs for frontends
How to test using Sepolia and Hardhat

🔥 What I Learned (That You Probably Won’t Get From Tutorials)

1. Solidity is deceptively simple

It looks like JavaScript. But one wrong storage pattern can wreck your gas costs or leave your data permanently stuck.

2. Gas fees matter

Even with just notes, writing to storage is expensive. I optimized my code after seeing a 3x gas difference between versions.

3. Logs are your best friend

Return values can’t be tracked after a tx — only events show what actually happened.

4. Simplicity = speed of learning

Because the app was small, I iterated faster, caught bugs early, and deployed to mainnet with confidence.

🧠 My Advice: Keep It Boring

If you're building your first dApp, try something simple:

A to-do list
A URL shortener
A basic registry
A voting system without tokens

Focus on data storage, permissions, events, and deployment flow.

Learn the mechanics — not the hype.

🚀 What’s Next?

Now that I’ve got the basics locked in, I’m building toward:

Upgradeable contracts
Modular smart contracts with Diamond pattern
Cross-chain message passing
Real-time indexing with The Graph

But I wouldn’t have gotten here without starting boring.

💬 Your Turn

What was your first smart contract like?

Did you over-engineer it, or keep it lean?

What’s the best “boring” dApp idea you’d recommend to someone new?

Drop a comment — let’s help newcomers build smarter from day one.

Thanks for reading. Follow me for more Web3 dev stories, code, and honest lessons from building on-chain.

I Lost $200 Deploying My First Smart Contract — Lessons From a Project Fund Tracker

Amir of Ekiti — Tue, 08 Jul 2025 14:23:14 +0000

🚀 My First Web3 Project: A Fund Tracker

Like many developers getting into Web3, I wanted my first project to be more than just a “Hello, Blockchain.” I wanted something useful — something that mimicked real-world use cases.

So I built a Project Fund Tracker.

The idea was simple: contributors could fund a project, and the owner could view and manage the funds. A lightweight version of a crowdfunding contract. It tracked contributions and allowed visibility into total funds collected.

Here’s a basic version of the contribute() function:

function contribute() public payable {
    require(msg.value > 0, "No funds sent");
    contributions[msg.sender] += msg.value;
    totalFunds += msg.value;
}

Everything worked fine:

✅ Contract deployed

✅ Contributions received

✅ State updated

✅ Event logs emitted

Feeling confident — maybe too confident — I decided it was time to go live. I deployed the same contract to Ethereum mainnet and sent 0.1 ETH (~$200) to the contribute() function.

That’s when things broke.

😬 The $200 Mistake

After sending the funds, I checked the contract state.

Nothing had changed.

contributions[msg.sender] was still 0
totalFunds hadn’t increased
No events were emitted

The transaction was marked as successful on Etherscan. Gas was used. ETH was sent.

But it was as if the contract just… ignored it.

🕵️‍♂️ The Debugging Journey

I started retracing my steps.

Here’s what I found:

During a late refactor, I updated the constructor to include default project data like title and owner.
Without realizing it, I also reset totalFunds to zero and unintentionally cleared contribution mappings — right after deployment.
On Sepolia, I had been testing contribute() after the contract had been used a bit. On mainnet, I interacted with it immediately post-deployment, triggering the buggy initialization.

So when I sent ETH, it went in — but the logic to track and emit contribution data was broken. And since I didn’t simulate the full flow on mainnet, I didn’t catch it beforehand.

💡 Lessons Learned

🧪 Sepolia ≠ Mainnet

Testnets are amazing — especially Sepolia. But they don’t simulate everything:

Gas behavior
Timing issues
Real asset risk
Behavioral quirks post-deployment

From now on, I always assume mainnet = production. Period.

🔍 Simulate Everything

Tools like:

Tenderly
Hardhat’s console.log
Foundry’s cast call

…help you simulate transactions and get a dry-run view of what will really happen.

I didn’t simulate the contribute() call after mainnet deployment. If I had, I would’ve caught the problem.

📦 Constructors Can Be Dangerous

The mistake was in the constructor logic.

I hardcoded state initialization in the constructor, assuming it would only run once. It did — but the logic was flawed.

Lesson: treat constructor logic with the same level of scrutiny as any public function. Better yet, use initialize() patterns for safety and transparency.

📉 Emit Logs, Always

Without events, debugging a live contract is like looking for a black cat in a dark room.

I added an event later:

event ContributionReceived(address indexed contributor, uint256 amount);

function contribute() public payable {
    require(msg.value > 0, "No funds sent");

    contributions[msg.sender] += msg.value;
    totalFunds += msg.value;

    emit ContributionReceived(msg.sender, msg.value);
}

Without this, it’s hard to know if a function ran or silently failed. In my case, the lack of logs made it harder to debug what actually happened. The transaction succeeded, gas was consumed, but there was no on-chain evidence of execution — no events, no state changes, nothing obvious to inspect.

⚠️ Sepolia ≠ Mainnet

Sepolia is a great testnet, but it’s not the mainnet. While Sepolia helped me catch most bugs, it didn't replicate all real-world conditions.

Mainnet differs in many ways:

Gas prices fluctuate much more drastically
Miner behavior can affect transaction ordering
Edge cases often appear only in live environments
Stakes are higher — real money is involved

This means passing tests on Sepolia doesn’t guarantee mainnet success. You must simulate mainnet conditions as closely as possible.

✅ The Comeback

After tracking down the issue — mainly an overlooked state reset in the constructor — I:

Refactored the constructor to avoid resetting critical state variables
Added thorough event logging to every public function
Created comprehensive test flows simulating real user interactions on Sepolia
Used simulation tools like Tenderly to analyze transaction behavior
Tested redeployments with a low-balance burner wallet on mainnet

With these safeguards in place, I redeployed to mainnet and finally saw:

Contributions correctly recorded
Event logs emitted as expected
No unexpected state resets or silent failures

This time, the contract worked flawlessly.

🧠 Final Thoughts

Deploying smart contracts to mainnet is like launching a high-stakes product. Mistakes cost real money and trust.

My key takeaways:

Don’t blindly trust testnets — simulate mainnet conditions as much as possible
Use tools to simulate and debug transactions before spending gas
Treat constructor logic with extra caution
Emit detailed events for every state-changing function
Test entire interaction flows, not just isolated functions

💬 Your Turn

Have you ever deployed a contract that worked on testnet but failed on mainnet? Made costly mistakes or discovered helpful tools?

Share your story in the comments — learning from each other helps us all build better, safer Web3 apps.

Thanks for reading! 🙌

If you found this post helpful, please ❤️ or share it with fellow Web3 developers. More stories and lessons coming soon!

## What Really Happens When You Call a Smart Contract?

Amir of Ekiti — Sat, 05 Jul 2025 02:56:45 +0000

It was 2 AM. I had just deployed my first Solidity smart contract—a simple “wave at me” dApp—and was proudly calling wave() from my frontend. But nothing happened.

No wave.

No confirmation.

Just a pending transaction and a big mystery: what is actually happening when I “call” a smart contract?

If you've ever clicked "Submit" in a Web3 app and wondered what goes on behind the scenes, this post is for you.

🧠 TL;DR First (Then We Dive Deep)

When you call a smart contract:

You create a transaction from your wallet (like MetaMask).
That transaction is signed by you, proving it’s legitimate.
It gets sent to the blockchain network (Ethereum, Polygon, etc).
Nodes pick it up, run the contract logic, and validate it.
If all goes well, it’s added to a block, and the change becomes permanent.

But the real magic? It’s what happens between those steps.

Let’s walk through it with a story.

👩‍💻 The Story: Alice Sends a Transaction

Say Alice wants to buy a sword in a blockchain game by calling a smart contract function:

function buySword(uint swordId) public payable {
    require(msg.value >= swordPrice, "Not enough ETH");
    ownerOf[swordId] = msg.sender;
}

She clicks “Buy” in the dApp UI. Here’s what happens:

🧰 Step 1: The Frontend Prepares the Payload

The app uses Ethers.js or Web3.js to encode the function and arguments into something the Ethereum Virtual Machine (EVM) understands:

contract.buySword(2, { value: ethers.utils.parseEther("0.05") });

This turns into a raw transaction object like:

{
  "to": "0xContractAddress",
  "data": "0xa9059cbb000000000000000000...",
  "value": "0.05 ETH"
}

🔐 Step 2: Signing the Transaction

Before it can go anywhere, Alice’s wallet (MetaMask, WalletConnect, etc.) pops up and asks her to sign the transaction.

This doesn’t encrypt it.
It simply proves: “Yes, I want to do this.”

The private key never leaves her wallet, but the signature is added to the transaction.

🚀 Step 3: Broadcasting to the Network

Once signed, the transaction is sent to the network—usually to a full node like Infura or Alchemy, or directly to an Ethereum node if you're self-hosting.

This step is like saying:

“Hey miners or validators, here’s a new transaction! Please include it in the next block!”

🔄 Step 4: The EVM Executes the Code

When the transaction is picked up by a node (usually by a validator or miner), the Ethereum Virtual Machine (EVM):

Loads the smart contract's bytecode.
Locates the function via its function selector (first 4 bytes of the data field).
Executes the code line by line.
Updates blockchain state if successful.

If anything fails (like a failed require), the whole transaction is reverted — no changes are made.

⛓️ Step 5: It’s Mined & Stored On-Chain

Once the transaction passes validation:

It's included in the next block.
That block is appended to the blockchain.
The transaction becomes immutable history.

Anyone can verify the transaction later on block explorers like Etherscan.

🧼 Behind the Scenes (Gas, Nonces, and State)

A few more things happening under the hood:

Gas: The fee paid to miners/validators for computation and storage.
Nonce: A unique number to prevent replay attacks and ensure transaction order.
State transitions: Events and changes logged to update the ledger.

Smart contracts are deterministic: if the same inputs are given, every node will compute the same result or revert.

🤖 Read vs Write: Calls That Don’t Cost Gas

If Alice just wants to read data (like checking sword ownership), no transaction is created:

const sword = await contract.getSword(2);

No gas
No miner
No blockchain write
Just a simulated EVM call against the latest state

These are called "view" functions and are free.

🎯 Summary

When you “call” a smart contract, you're not just hitting a function. You’re:

Encoding the function and its arguments
Signing the request
Broadcasting it to the network
Letting thousands of nodes simulate, verify, and agree on the outcome
Getting it permanently recorded on the chain

That’s a lot of trustless magic behind one click.

🛠️ Want to See It in Action?

Try this:

Write a simple contract with a public function
Deploy it to a testnet (like Sepolia)
Call it from your dApp with Ethers.js
Then watch the tx on Etherscan

You’ll see exactly what happens, from pending to confirmed.

💬 Over to You

What’s the smartest (or weirdest) smart contract you’ve interacted with?

Ever had a tx fail mysteriously?

Drop your thoughts in the comments 👇

👋 Let’s Connect

GitHub:https://github.com/amirofekiti/ Thanks for reading! If this helped you, consider hitting ❤️ and saving the post!

## Blockchain Explained Like You’re 5 (With Code)

Amir of Ekiti — Sat, 05 Jul 2025 02:38:45 +0000

Blockchain Explained Like You’re 5 (With Code)

Imagine you and your friends are playing a game of marbles at recess. You all trust each other (kind of), but there's no teacher around to keep score.

So you come up with a plan:

Every time someone wins or loses marbles, you all write it down in your notebooks.

That’s the idea behind a blockchain.

Let me explain.

🧠 What Is a Blockchain (Like You’re 5)

You and your friends:

Agree on the rules: If you lose, you give marbles.
Write down every trade in your own notebook.
Keep all your notebooks in sync.
If someone tries to cheat and says “I didn’t lose 3 marbles,” the others can say, “Look! It’s in all our notebooks!”

That notebook?

That’s a blockchain — a shared list of events that everyone agrees on and no one can secretly change.

🧱 What’s a Block?

You don’t write down every marble trade immediately. Instead, every 10 trades, you:

Wrap them up
Add a date and summary
Put it in your notebook and call it a block

Each block is like a chapter in your notebook, and it has:

What happened
When it happened
A fingerprint of the previous block (so no one can remove or change a chapter)

So it’s a chain of blocks. Now we’re talking blockchain.

🧪 Let's Code a Baby Blockchain (in JavaScript)

Let’s build a tiny blockchain to understand how it works.

const crypto = require('crypto');

class Block {
  constructor(index, timestamp, data, previousHash = '') {
    this.index = index;
    this.timestamp = timestamp;
    this.data = data;
    this.previousHash = previousHash;
    this.hash = this.calculateHash();
  }

  calculateHash() {
    return crypto
      .createHash('sha256')
      .update(this.index + this.previousHash + this.timestamp + JSON.stringify(this.data))
      .digest('hex');
  }
}

class Blockchain {
  constructor() {
    this.chain = [this.createGenesisBlock()];
  }

  createGenesisBlock() {
    return new Block(0, Date.now(), "Genesis Block", "0");
  }

  getLatestBlock() {
    return this.chain[this.chain.length - 1];
  }

  addBlock(newBlock) {
    newBlock.previousHash = this.getLatestBlock().hash;
    newBlock.hash = newBlock.calculateHash();
    this.chain.push(newBlock);
  }

  isChainValid() {
    for (let i = 1; i < this.chain.length; i++) {
      const current = this.chain[i];
      const previous = this.chain[i - 1];

      if (current.hash !== current.calculateHash()) return false;
      if (current.previousHash !== previous.hash) return false;

✅ Each block is linked to the one before

✅ Every change makes a new hash

✅ Tamper-proof unless someone rewrites the whole chain (and gets everyone else to agree!)

🧊 But What About Crypto?

Blockchains like Bitcoin or Ethereum use this structure to track:

Who sent money to whom
Who owns what
And make sure it’s impossible to cheat (without a lot of power and math)

Instead of marbles, they’re trading coins or tokens.

👩‍🚀 Why Should You Care?

Because this idea:

Makes money programmable
Can create transparent systems (like for voting or public spending)
Helps us build apps where no one can lie about the history

And you just built one (a tiny one, but still 😄).

🧠 TL;DR

A block is a bundle of data + timestamp + a hash.
A blockchain is a secure, connected list of those blocks.
It’s like a shared notebook where everyone writes the truth—and if someone tries to lie, it breaks the chain.

💬 Got Questions?

Let me know in the comments!

Want a follow-up where we deploy this to a real blockchain? Or build a smart contract version?

Hit the ❤️ if this helped you understand blockchain just a bit better.

👋 Let’s Connect

GitHub: https://github.com/amirofekiti/
Say hi in the comments!

How I’m Building Blockchain for Public Fund Transparency

Amir of Ekiti — Sat, 05 Jul 2025 02:24:53 +0000

How I’m Building Blockchain for Public Fund Transparency

It started with frustration.

I was scrolling through a government portal, trying to trace how a particular public fund was allocated, but the trail ended in vague reports and broken links. Billions were accounted for in theory, but not in practice. I thought: “What if there was a way to trace every single transaction, from top-level disbursement to local implementation, in a way no one could tamper with?”

That’s when the idea hit me—why not use blockchain to build a transparent ledger for public fund management?

This post is my journey so far—technical choices, philosophical drivers, and the mistakes I’ve made (and am still making). If you care about civic tech, transparency, or blockchain for good, this one’s for you.

🧠 The Why: Transparency Isn’t Optional—It’s Survival

Public trust is at an all-time low in many parts of the world, and one major reason is opaque financial governance. Most citizens don’t know where their taxes go. And when they ask, they’re given PDF reports instead of raw data.

Blockchain promises immutability, traceability, and public accountability—values governments often claim but rarely deliver on. It’s not about cryptocurrency. It’s about truth.

🧱 The Stack: Building the Transparent Ledger

Here’s what I’m currently working with:

🧬 Blockchain Layer

Choice: Ethereum (using a sidechain for scalability)
Why: Developer-friendly, lots of tooling, good support for smart contracts
Challenges: Gas fees and complexity for non-technical users

🔐 Smart Contracts

I’m using Solidity to write smart contracts that handle:

Fund disbursement logs
Project milestones
Approval workflows

Each transaction creates a record tied to an actual budget item.

🌐 Frontend

Framework: React + Next.js
Web3 Integration: Ethers.js
Design Goals:
- Easy for regular users (citizens) to navigate
- Visual transparency: flow charts, progress bars, and audit trails

🗃️ Backend / Off-chain Storage

IPFS for storing documents like contracts, invoices, and receipts
PostgreSQL for fast querying of mirrored data (used by the frontend)

👥 The People Problem

The hardest part isn’t code—it’s humans.

Government stakeholders are skeptical of decentralization.
NGOs are interested but lack technical staff.
Citizens are curious but wary of “blockchain buzzwords.”

So part of my job became evangelism: running small workshops, creating demo walkthroughs, and building trust.

🔍 Transparency in Action (Demo Use Case)

Let’s say the Ministry of Health allocates $1M to build rural clinics. Here’s how it would work on the platform:

Smart Contract Deployed

Ministry creates a smart contract defining the total budget, deliverables, and timeline.
Fund Disbursed

Every disbursement to contractors or NGOs is logged with a transaction hash.
Milestone Verified

Once a clinic is built, the contract triggers a milestone payment only after verifiable evidence (photos, GPS-tagged receipts) is submitted to IPFS.
Public View

Anyone—citizens, journalists, auditors—can see the full trail from allocation to execution.

🚧 What’s Still in Progress

Onboarding UX: Making wallet connection and blockchain concepts user-friendly
Localization: Adapting for languages and regulatory contexts in multiple countries
Partnerships: Collaborating with civic tech orgs for real-world pilots

🔮 The Road Ahead

I'm under no illusion that tech alone can fix governance. But what it can do is give us the tools to hold power accountable—and to do so in a way that’s verifiable, tamper-proof, and open to all.

This project is open-source, and I’m actively looking for collaborators—developers, designers, civic hackers, and policy nerds alike.

If you’ve ever wanted to use your skills for public good, consider this your invitation.

💬 Let’s Connect

GitHub Repo: https://github.com/amirofekiti
Twitter / X: @amirekiti
Drop a comment or DM me here on Dev.to if you want to get involved!

🙏 Final Thoughts

Building something like this isn’t easy. It’s idealistic, sometimes overwhelming, and constantly evolving. But if even one community can see exactly where their money is going—and demand better because of it—then all this is worth it.

Let’s build transparency, one block at a time.

🌍 Help Build a Transparent Blockchain System for Public Projects | Open-Source Collaboration

Amir of Ekiti — Wed, 28 May 2025 20:21:21 +0000

🛠️ Project: NDDC Blockchain Prototype

Hey devs! 👋

We're building a decentralized web application (DApp) to bring transparency and accountability to public fund management using Ethereum smart contracts. This project simulates a blockchain-powered platform for the Niger Delta Development Commission (NDDC).

💡 Why This Matters

Public institutions in developing regions often suffer from inefficiency and corruption. Our solution uses blockchain to automate fund disbursements, ensure transparency, and build trust among stakeholders.

🚀 Project Highlights

💰 ETH fund deposit & admin disbursement via MetaMask
🔐 Smart contract deployed on Sepolia Testnet
🌐 Real-time frontend interaction with Web3.js
🔎 Transaction history viewable and verifiable on-chain

🔗 Live Demo: nddc-blockchain-prototype.vercel.app

📄 Smart Contract Code: contracts/ProjectFunding.sol

🛠 Tech Stack

Solidity (smart contract logic)
Hardhat (development & testing)
Ethereum Sepolia (testnet deployment)
JavaScript + Web3.js (frontend)
MetaMask (wallet integration)
Vercel (deployment)

🤝 How to Contribute

We’re looking for:

Solidity/Hardhat devs
Web3 frontend engineers
UI/UX designers
Feature brainstormers (e.g., audit trails, role-based access, notifications)

💻 GitHub Repo

To contribute:

Fork & clone the repo
Create a feature branch
Submit a PR with clear documentation

Let’s work together to build a tool that public institutions can actually use. All contributions—big or small—are welcome! 💬 Comment below or connect on GitHub.