DEV Community: Srashti

I Took My DApp Off My Laptop. The Internet Did Not Care, But I Was Thrilled.

Srashti — Fri, 03 Jul 2026 05:59:23 +0000

Here's an uncomfortable truth about local Hardhat networks.

They feel real. They are not real.

Everything I'd built so far — the contract, the tests, the MetaMask connection — ran on a network that exists only on my laptop, resets every time I restart it, and that literally nobody else on Earth can access.

It was time to put this thing somewhere that actually counts.

Local network vs public testnet — the difference that actually matters

A local Hardhat network is basically a blockchain simulator. Fast, free, and fake. Perfect for testing. Useless for showing anyone else what you built.

A public testnet — I'm using Sepolia, Ethereum's main test network — is a real, persistent, publicly accessible blockchain. The ETH on it has no real value, but everything else behaves exactly like mainnet. Real gas costs (in test ETH), real block times, real network conditions.

If your contract works on Sepolia, you've actually proven something. If it only worked locally, you've proven... that it worked locally.

Getting test ETH

Before deploying anything, you need fake money to pay fake gas fees. Welcome to one of the stranger sentences in software development.

Sepolia faucets give out free test ETH. I used one tied to my Alchemy account, pasted in my wallet address, and waited a couple minutes. Free money, zero value, completely necessary.

Configuring Hardhat for Sepolia

Back to hardhat.config.js — except now it needs to know about a real network, not just the local simulator.

require("@nomicfoundation/hardhat-toolbox");
require("dotenv").config();

module.exports = {
  solidity: "0.8.20",
  networks: {
    sepolia: {
      url: process.env.SEPOLIA_RPC_URL,
      accounts: [process.env.PRIVATE_KEY],
    },
  },
};

Two things I had to get right here, and both involve secrets I should never, ever commit to GitHub.

SEPOLIA_RPC_URL — this is an endpoint that lets Hardhat actually talk to the Sepolia network. I got mine from Alchemy, free tier, no cost.

PRIVATE_KEY — my wallet's private key, used to sign and pay for the deployment transaction. This one terrified me a little the first time. If this leaks, anyone can drain that wallet. I put both of these in a .env file and added .env to .gitignore before I did anything else. Lesson learned before the mistake happened, for once.

Writing the deploy script

const hre = require("hardhat");

async function main() {
  const CrowdFund = await hre.ethers.getContractFactory("CrowdFund");
  const crowdFund = await CrowdFund.deploy();

  await crowdFund.waitForDeployment();

  console.log("CrowdFund deployed to:", await crowdFund.getAddress());
}

main().catch((error) => {
  console.error(error);
  process.exitCode = 1;
});

Then actually run it:

npx hardhat run scripts/deploy.js --network sepolia

This took noticeably longer than deploying locally — because it's a real network with real block times, not an instant simulation. Watching the terminal just sit there for the first time was its own small lesson in patience.

When it finally printed an address, that address was real. Anyone could look it up on Sepolia's block explorer and see my contract sitting there. That moment felt different from every local deploy before it.

Pointing the frontend at it

Small but easy-to-forget step — the React app's CONTRACT_ADDRESS had to change from the local Hardhat address to this new Sepolia one. And MetaMask had to actually be switched to the Sepolia network too, or none of this connects to anything.

That mismatch — frontend pointed one place, wallet connected to another — is its own special category of confusing bug. Everything looks fine. Nothing works. No error tells you why.

The bug that actually got me: events not updating the frontend

Here's the real problem I hit, and it's worth walking through honestly because the fix taught me something about how DApps are actually supposed to work.

My UI showed a campaign's amountRaised correctly right after I contributed — because I was calling the contract directly and re-fetching. But if someone else contributed while I had the page open, my screen had no idea. It just sat there, stale, until I manually refreshed.

The fix was adding events to the contract that I'd skipped back in the original version:

event ContributionMade(uint256 campaignId, address contributor, uint256 amount);

function contribute(uint256 _campaignId) public payable {
    Campaign storage campaign = campaigns[_campaignId];

    require(block.timestamp < campaign.deadline, "Campaign has ended");
    require(msg.value > 0, "Contribution must be greater than zero");

    campaign.amountRaised += msg.value;
    contributions[_campaignId][msg.sender] += msg.value;

    emit ContributionMade(_campaignId, msg.sender, msg.value);
}

emit broadcasts this event onto the blockchain every time someone contributes. Anything listening can pick it up in real time.

Then on the frontend:

contract.on("ContributionMade", (campaignId, contributor, amount) => {
  console.log("New contribution detected:", campaignId, contributor, amount);
  refreshCampaignData(campaignId);
});

This is the piece I genuinely didn't understand until I needed it. Smart contracts don't push updates to a frontend automatically just because something changed. The frontend has to explicitly listen for events — and if you don't emit them in your contract, there's nothing to listen to in the first place.

I had built a contract that worked perfectly and a frontend that had no way of knowing when things changed. Both pieces were "correct." Together, they were broken.

Why this bug actually matters beyond just fixing it

This is the difference between writing a contract that works and building a DApp that feels alive.

Without events, every user is stuck refreshing manually, never sure if what they're looking at is current. With events, the UI reacts the moment something happens on-chain — close to how a normal web app feels, except nothing here is coming from a server.

It's a small addition to the Solidity code. It changes the entire feel of the product.

Where things actually stand right now

Honest status update, because that's the whole point of writing this in public:

Contract is deployed on Sepolia, with a real address anyone can verify
Frontend connects to it, creates campaigns, accepts contributions
Events are now wired up, so the UI updates without manual refreshing
Still rough around the edges — no proper campaign list view yet, styling is minimal, error handling is basic

This isn't "the DApp is live and perfect." It's "the DApp is live, mostly works, and I know exactly what's left."

That gap is smaller than it was at the start of this whole series. That's the actual win.

What's left

A real campaign listing page. Better error messages when a transaction fails instead of a raw MetaMask error. And eventually, a proper look at whether this is even ready to show people outside of me testing it alone.

Getting something onto a public testnet didn't finish this project. It just moved the goalposts to something more honest.

I'm Srashti Gupta, building in the Web3 space. I write about real builds, real bugs, and blockchain development from scratch. Let's connect on LinkedIn.

MetaMask, Wallets, and Why Ownership Actually Matters

Srashti — Wed, 24 Jun 2026 05:10:33 +0000

Up until this post, my entire DApp lived in a terminal.

Tests passed. Contract compiled. Everything technically worked. And none of it looked like anything a real human would ever want to use.

Time to give it a face.

Why MetaMask is the whole game here

In a normal web app, you log in with an email and password. The server checks a database, decides who you are, and trusts that decision.

There's no login here. There's no database deciding who you are.

Instead, there's MetaMask — a wallet that holds your private key and lets you sign transactions. When you "connect" your wallet to a DApp, you're not logging into anything. You're just letting the website see your public address and asking your permission before any transaction goes out.

Nobody can fake being you. Nobody can reset your password and lock you out. Your wallet is your identity here, and only you control it.

That's the part that actually matters. Not the UI. The ownership.

Connecting the wallet

In my React app, I'm using ethers.js (Web3.js's sibling library — similar purpose, cleaner API) to talk to MetaMask.

import { ethers } from "ethers";
import { useState } from "react";

function App() {
  const [account, setAccount] = useState(null);
  const [provider, setProvider] = useState(null);

  async function connectWallet() {
    if (!window.ethereum) {
      alert("MetaMask not found. Please install it.");
      return;
    }

    const browserProvider = new ethers.BrowserProvider(window.ethereum);
    const accounts = await browserProvider.send("eth_requestAccounts", []);

    setProvider(browserProvider);
    setAccount(accounts[0]);
  }

  return (
    <div>
      {account ? (
        <p>Connected: {account.slice(0, 6)}...{account.slice(-4)}</p>
      ) : (
        <button onClick={connectWallet}>Connect Wallet</button>
      )}
    </div>
  );
}

window.ethereum is the object MetaMask injects into every page you visit, automatically, the moment the extension is installed. If it's not there, MetaMask isn't installed — that's the first thing to check.

eth_requestAccounts is what actually triggers that familiar MetaMask popup — "this site wants to connect to your wallet." The user has to approve it. Nothing happens silently.

I'm slicing the address for display (0x71C7...976F instead of the full 42 characters) because nobody wants to read a full wallet address on a button. Small detail, makes the UI feel less like a database dump.

Getting the contract talking to React

Connecting a wallet is step one. Actually calling our contract's functions is step two.

import CrowdFundABI from "./CrowdFund.json";

const CONTRACT_ADDRESS = "0xYourDeployedContractAddress";

async function getContract(provider) {
  const signer = await provider.getSigner();
  return new ethers.Contract(CONTRACT_ADDRESS, CrowdFundABI.abi, signer);
}

Remember that ABI file Hardhat generated back when we first compiled the contract? This is exactly where it gets used. The ABI tells ethers.js what functions exist on our contract and what arguments they expect — without it, JavaScript has no idea our contract can even do anything.

provider.getSigner() gets the actual connected account, the one capable of signing and sending transactions — not just reading data.

CONTRACT_ADDRESS is wherever our CrowdFund contract actually got deployed. For now, that's a testnet address from Hardhat's local network or somewhere like Sepolia.

Creating a campaign from the UI

async function createCampaign(goalInEth, durationInSeconds) {
  const contract = await getContract(provider);

  const tx = await contract.createCampaign(
    ethers.parseEther(goalInEth),
    durationInSeconds
  );

  await tx.wait();
  alert("Campaign created!");
}

Two steps, and the gap between them matters.

contract.createCampaign(...) sends the transaction — MetaMask pops up, the user approves it, and it gets broadcast to the network. But sending a transaction and it actually being confirmed are different moments.

tx.wait() pauses until the transaction is actually mined into a block. Skip this step and your UI might say "Campaign created!" before the campaign genuinely exists on-chain — which is exactly the kind of bug that makes a DApp feel broken even when the contract is fine.

Contributing to a campaign

async function contributeToCampaign(campaignId, amountInEth) {
  const contract = await getContract(provider);

  const tx = await contract.contribute(campaignId, {
    value: ethers.parseEther(amountInEth),
  });

  await tx.wait();
  alert("Contribution sent!");
}

Same pattern as the test we wrote in the last post — value in the call is what actually attaches real ETH to this transaction. The only difference now is a real human is clicking a real button, MetaMask is popping up with a real gas estimate, and real money is moving.

This is the moment the whole project stops feeling like an exercise.

What it actually feels like end to end

Here's the full user journey, now that all of it connects:

Open the app, click Connect Wallet — MetaMask pops up, user approves
Fill in a goal and duration, click Create Campaign — MetaMask pops up again asking to confirm the transaction
Wait a few seconds for confirmation, campaign appears
Someone else opens the app, connects their own wallet, contributes ETH to that campaign — another MetaMask popup, another confirmation
Refresh, and the campaign's raised amount has actually updated — read directly from the blockchain, not from any database

No login. No backend tracking sessions. No "forgot password" flow. Just wallets, signatures, and a contract that doesn't care who you are beyond your address.

The bug that taught me something

First time I tested this flow, I created a campaign, switched MetaMask to a different test account, and tried to contribute — except the contribution amount field still showed the old account's input because I hadn't reset my component state on account change.

MetaMask lets users switch accounts anytime, and your app needs to actually listen for that:

window.ethereum.on("accountsChanged", (accounts) => {
  setAccount(accounts[0]);
});

Without this listener, your UI can silently show stale data tied to an account the user already switched away from. Small thing. Easy to miss. Definitely the kind of bug that erodes trust fast if a real user hits it.

Why this matters beyond just "it works now"

Stepping back for a second — what we just built is genuinely different from a normal web app's login flow.

There's no "Srashti's account" sitting in a database somewhere that the platform can suspend, ban, or quietly modify. There's a wallet address, and whatever that address has done on-chain, visible to anyone, controlled by nobody but its owner.

That's not a minor technical detail. That's the entire pitch of what we're building, finally made visible instead of theoretical.

What's next

Wallet connects. Campaigns get created. Contributions go through. The full loop actually works, end to end, with a real face on it.

What's left is polish and reality — proper UI for displaying all active campaigns, progress bars toward each goal, and eventually pushing this from a local Hardhat network onto a real public testnet where anyone, anywhere, could actually try it.

That's where this story is headed next.

I'm Srashti Gupta, building in the Web3 space. I write about real builds, real bugs, and blockchain development from scratch. Let's connect on LinkedIn.

From Remix to Hardhat: What Changes When You Go Pro

Srashti — Fri, 19 Jun 2026 16:00:13 +0000

Remix spoiled me.

Open browser. Write code. Compile. Deploy. No installation, no config files, no "why is this not working" at 11pm.

Hardhat is the opposite of that. And honestly? That's the point.

Why leave Remix at all

Remix is great for learning. It is genuinely bad for building anything real.

You can't version control it properly. You can't write proper automated tests. You can't integrate it with a frontend easily. Every real Web3 project — the ones actually shipping to mainnet — uses something like Hardhat or Foundry.

So if the crowdfunding DApp is going to be a real thing and not just a browser tab, it has to move out of Remix.

This is the "going pro" moment. It's also the first moment things stopped being smooth.

The Node version trap nobody warns you about

Here's the thing that cost me actual time before I even wrote a line of contract code.

Hardhat needs a recent Node.js version. If you're running an older version — anything below Node 20 — newer Hardhat versions will either refuse to install properly or throw confusing errors that have absolutely nothing to do with the real problem.

You'll see errors about modules, about syntax, about things that sound like your code is broken. It's not your code. It's your Node version.

Check yours first:

node -v

If you're below v20, update before doing anything else. I'm using nvm (Node Version Manager) to handle this because switching Node versions between projects is just a fact of life in this ecosystem now.

nvm install 20
nvm use 20

Save yourself the hour I lost. Check this before you touch Hardhat at all.

Actually installing Hardhat

Once Node is sorted, this part is simple.

mkdir crowdfund-dapp
cd crowdfund-dapp
npm init -y
npm install --save-dev hardhat

Then initialize the project:

npx hardhat init

This gives you options — pick the JavaScript project (TypeScript is great too, but one new thing at a time). It'll ask to install some dependencies. Say yes.

The config file that doesn't always behave

Here's the second honest problem.

Hardhat creates a hardhat.config.js file automatically. Sometimes it generates clean. Sometimes — depending on the version, the Node setup, or honestly just bad luck — it doesn't set up correctly, and you get errors when you try to compile.

If that happens to you, don't panic and don't assume you broke something fundamental. Just rewrite the config manually. Here's a clean baseline that works:

require("@nomicfoundation/hardhat-toolbox");

/** @type import('hardhat/config').HardhatUserConfig */
module.exports = {
  solidity: "0.8.20",
  paths: {
    sources: "./contracts",
    tests: "./test",
    cache: "./cache",
    artifacts: "./artifacts",
  },
};

Make sure the Solidity version here matches the pragma solidity line in your contract. Mismatch between these two is one of the most common compile errors beginners hit, and the error message doesn't always make that obvious.

Setting up the project structure

Hardhat expects a specific folder structure:

crowdfund-dapp/
├── contracts/
│   └── CrowdFund.sol
├── test/
├── scripts/
└── hardhat.config.js

Drop the contract we wrote in the last post into contracts/CrowdFund.sol. Exactly as written before — createCampaign, contribute, withdraw, refund, all of it.

Compiling for the first time

This is the moment of truth.

npx hardhat compile

If everything's set up right, you'll see something like:

Compiled 1 Solidity file successfully

If you see red text instead — read the actual error, not just the first line. Most Hardhat compile errors are one of these three things:

Solidity version mismatch — your pragma line and your config don't agree
Missing semicolon or bracket — Solidity is strict, unlike JS where you can get away with a lot
Node version issue — back to the trap from earlier. If the error looks unrelated to your actual code, suspect this first

What compiling actually does

When this succeeds, Hardhat generates an artifacts folder. Inside it sits the compiled bytecode and the ABI (Application Binary Interface) — basically the instruction manual that tells anything talking to this contract what functions exist and what they expect.

This is the same ABI we'll eventually feed into Web3.js so the React frontend can actually talk to this contract. Compiling isn't just "checking for errors" — it's generating the exact files the rest of the DApp depends on.

The honest difference from Remix

In Remix, compiling is instant and invisible. You don't think about Node versions, config files, or folder structures. It just runs.

Hardhat makes you own all of that. More setup, more things that can break, more moments of staring at an error message that doesn't explain itself.

But here's what you get in return — a project that's actually testable, versionable, and deployable to a real network in a real, repeatable way. Remix can't give you that.

This is the trade every Solidity developer makes eventually. Comfort for control.

What's next

Contract is compiled. Files are generated. Project structure exists.

Next up — actually writing tests. Because a contract that compiles isn't a contract that works. Those are two very different claims, and the gap between them is where bugs live.

We're going to deliberately try to break this thing before anyone else gets the chance to.

I'm Srashti Gupta, building in the Web3 space. I write about real builds, real setup headaches, and blockchain development from scratch. Let's connect on LinkedIn.

The Smart Contract That Handles Your Money. No Bank Needed

Srashti — Tue, 16 Jun 2026 05:42:12 +0000

The Smart Contract That Handles Your Money. No Bank Needed.

By Srashti Gupta |Blockchain Developer

This is the part where it gets real.

Not "real" like inspirational. Real like — this contract will hold actual ETH. If I write the logic wrong, money doesn't go where it should. There's no "oops, let me push a fix." There's no customer support. There's no undo.

So let's write it carefully. And let's actually understand every piece.

What this contract needs to do

Before touching Solidity, I always write the logic in plain English first. Sounds obvious. Saves hours.

Here's what our crowdfunding contract needs to handle:

A creator starts a campaign — sets a goal (in ETH) and a deadline
Anyone can contribute ETH to a campaign
If the goal is hit before the deadline → creator withdraws the funds
If the deadline passes and the goal isn't hit → contributors get refunded
Nobody can cheat any of this. The code enforces it.

Five rules. One contract. Let's build it.

Setting up the contract

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract CrowdFund {

    struct Campaign {
        address creator;
        uint256 goal;
        uint256 deadline;
        uint256 amountRaised;
        bool withdrawn;
    }

    mapping(uint256 => Campaign) public campaigns;
    mapping(uint256 => mapping(address => uint256)) public contributions;
    uint256 public campaignCount;
}

Okay, three things happening here worth pausing on.

The Campaign struct is how we store each campaign. Think of it as a row in a database — except this database is the blockchain and nobody owns it. creator is the wallet address of whoever started the campaign. goal and deadline are set at creation. amountRaised tracks total ETH contributed. withdrawn is a boolean that makes sure the creator can only pull funds once.

The first mapping — mapping(uint256 => Campaign) — connects a campaign ID (just a number) to its Campaign struct. Campaign 0, Campaign 1, Campaign 2. Simple.

The second mapping is the interesting one. mapping(uint256 => mapping(address => uint256)) — for each campaign, it tracks how much each wallet address contributed. This is what makes refunds possible. The contract remembers exactly who sent what.

campaignCount starts at zero and increments every time a new campaign is created. That's our ID system.

Creating a campaign

function createCampaign(uint256 _goal, uint256 _duration) public {
    require(_goal > 0, "Goal must be greater than zero");
    require(_duration > 0, "Duration must be greater than zero");

    campaigns[campaignCount] = Campaign({
        creator: msg.sender,
        goal: _goal,
        deadline: block.timestamp + _duration,
        amountRaised: 0,
        withdrawn: false
    });

    campaignCount++;
}

msg.sender is one of my favourite things in Solidity. It's automatically the wallet address of whoever called this function. No login. No JWT token. No session. The blockchain already knows who you are.

block.timestamp is the current time on the blockchain — in seconds. Adding _duration (also in seconds) to it gives us the deadline.

The require statements are Solidity's way of saying "if this condition isn't true, stop everything and revert." Nobody can create a campaign with a zero goal or zero duration. The contract simply won't let it happen.

Contributing to a campaign

function contribute(uint256 _campaignId) public payable {
    Campaign storage campaign = campaigns[_campaignId];

    require(block.timestamp < campaign.deadline, "Campaign has ended");
    require(msg.value > 0, "Contribution must be greater than zero");

    campaign.amountRaised += msg.value;
    contributions[_campaignId][msg.sender] += msg.value;
}

Two things here that are unique to Solidity.

payable — this keyword is what allows a function to receive ETH. Without it, any ETH sent to this function gets rejected. Most functions aren't payable. This one has to be.

msg.value — the amount of ETH sent with this transaction, in wei (1 ETH = 10¹⁸ wei). When someone calls contribute, the ETH they send travels with the function call and lands in the contract. The contract holds it. Not a bank. Not a server. The contract itself.

Campaign storage campaign — the storage keyword means we're pointing directly at the data on the blockchain, not making a copy of it. Changes we make here actually update the stored campaign. If we used memory instead, changes would be lost. This is one of those Solidity details that bites beginners hard.

Withdrawing funds (if goal is hit)

function withdraw(uint256 _campaignId) public {
    Campaign storage campaign = campaigns[_campaignId];

    require(msg.sender == campaign.creator, "Only creator can withdraw");
    require(campaign.amountRaised >= campaign.goal, "Goal not reached");
    require(!campaign.withdrawn, "Already withdrawn");

    campaign.withdrawn = true;

    (bool success, ) = payable(campaign.creator).call{value: campaign.amountRaised}("");
    require(success, "Transfer failed");
}

Three require checks before a single wei moves. This is the security mindset Solidity forces on you.

Only the creator can withdraw. The goal must be hit. And withdrawn must be false — meaning this hasn't been called before. Setting campaign.withdrawn = true before the transfer is intentional. It's called the checks-effects-interactions pattern, and it protects against a nasty attack called reentrancy where a malicious contract tries to drain funds by calling withdraw repeatedly before the first call finishes. Mark the state changed first. Then move the money.

The .call{value: ...}("") syntax is the modern, recommended way to send ETH in Solidity. It returns a success boolean which we check. If the transfer fails for any reason, the whole transaction reverts.

Refunding contributors (if goal isn't hit)

function refund(uint256 _campaignId) public {
    Campaign storage campaign = campaigns[_campaignId];

    require(block.timestamp >= campaign.deadline, "Campaign still active");
    require(campaign.amountRaised < campaign.goal, "Goal was reached, no refund");

    uint256 contributed = contributions[_campaignId][msg.sender];
    require(contributed > 0, "Nothing to refund");

    contributions[_campaignId][msg.sender] = 0;

    (bool success, ) = payable(msg.sender).call{value: contributed}("");
    require(success, "Refund failed");
}

Same pattern. Check everything first. Update state. Then move ETH.

contributions[_campaignId][msg.sender] = 0 before the transfer — again, reentrancy protection. If we checked the balance after the transfer, a malicious contract could call refund repeatedly before the balance zeroes out and drain the whole thing.

Each contributor calls refund themselves. The contract doesn't loop through everyone and send it back automatically — that would be expensive in gas and risky. Instead, each person claims their own refund. Cleaner, safer.

The full contract

Here's everything together:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract CrowdFund {

    struct Campaign {
        address creator;
        uint256 goal;
        uint256 deadline;
        uint256 amountRaised;
        bool withdrawn;
    }

    mapping(uint256 => Campaign) public campaigns;
    mapping(uint256 => mapping(address => uint256)) public contributions;
    uint256 public campaignCount;

    function createCampaign(uint256 _goal, uint256 _duration) public {
        require(_goal > 0, "Goal must be greater than zero");
        require(_duration > 0, "Duration must be greater than zero");

        campaigns[campaignCount] = Campaign({
            creator: msg.sender,
            goal: _goal,
            deadline: block.timestamp + _duration,
            amountRaised: 0,
            withdrawn: false
        });

        campaignCount++;
    }

    function contribute(uint256 _campaignId) public payable {
        Campaign storage campaign = campaigns[_campaignId];

        require(block.timestamp < campaign.deadline, "Campaign has ended");
        require(msg.value > 0, "Contribution must be greater than zero");

        campaign.amountRaised += msg.value;
        contributions[_campaignId][msg.sender] += msg.value;
    }

    function withdraw(uint256 _campaignId) public {
        Campaign storage campaign = campaigns[_campaignId];

        require(msg.sender == campaign.creator, "Only creator can withdraw");
        require(campaign.amountRaised >= campaign.goal, "Goal not reached");
        require(!campaign.withdrawn, "Already withdrawn");

        campaign.withdrawn = true;

        (bool success, ) = payable(campaign.creator).call{value: campaign.amountRaised}("");
        require(success, "Transfer failed");
    }

    function refund(uint256 _campaignId) public {
        Campaign storage campaign = campaigns[_campaignId];

        require(block.timestamp >= campaign.deadline, "Campaign still active");
        require(campaign.amountRaised < campaign.goal, "Goal was reached, no refund");

        uint256 contributed = contributions[_campaignId][msg.sender];
        require(contributed > 0, "Nothing to refund");

        contributions[_campaignId][msg.sender] = 0;

        (bool success, ) = payable(msg.sender).call{value: contributed}("");
        require(success, "Refund failed");
    }
}

Under 70 lines. Handles real ETH. No database. No backend. No bank.

What this contract can't do yet

Being honest — this is a solid foundation, not a finished product.

It doesn't have events yet — which means frontends can't listen for things like "campaign created" or "goal reached" in real time. That's next.

It doesn't have an emergency pause. If a bug is found after deployment, this contract can't be stopped. That's what upgradeable contract patterns are for — a whole separate topic.

And it hasn't been tested yet. Writing Solidity is one thing. Proving it does what you think it does is another. That's what Hardhat is for — and that's exactly what we're setting up next.

What just happened

We wrote a contract that:

Accepts real ETH from real wallets
Tracks who contributed what
Releases funds only when conditions are met
Refunds automatically when they're not
Can't be tampered with by anyone — including me

No Kickstarter. No bank. No middleman.

Just code, sitting on a chain, doing exactly what it says.

Next up — getting off Remix and setting up Hardhat. Because before this thing touches a testnet, we're going to break it on purpose and make sure it survives.

I'm Srashti Gupta, building in the Web3 space. I write about real builds, real mistakes, and blockchain development from scratch. Let's connect on LinkedIn.

I'm Building a Crowdfunding DApp. Here's Why Kickstarter Should Be Nervous

Srashti — Mon, 15 Jun 2026 05:23:03 +0000

Okay Kickstarter isn't actually nervous. They don't know I exist.

But hear me out.

The problem with crowdfunding platforms today

Someone has a idea. A real one. They build a campaign, post it on Kickstarter or Indiegogo, and people start funding it. Thousands of people. Real money. Real trust.

And then — Kickstarter takes 5%. Payment processors take another 3-5%. The creator waits weeks for the money to clear. The platform can suspend the campaign if they don't like something. The funds sit in an account controlled by a company you've never met.

You trusted the idea. You're also trusting the platform. You don't get to choose.

That bothered me. Because the platform isn't the product. The idea is the product. Why does the middleman get 10% and this much control?

So I decided to build the version without the middleman.

What I'm building

A decentralized crowdfunding DApp on Ethereum.

Here's how it works:

Anyone can create a campaign — set a goal (in ETH), set a deadline
Anyone can fund a campaign — send ETH directly to the smart contract
If the goal is hit before the deadline → funds release automatically to the creator
If the goal isn't hit → every contributor gets their money back. Automatically.

No platform holding your funds. No approval process. No 5% cut disappearing into a company's revenue.

The contract is the platform. The code is the rulebook. And anyone can read it.

The stack

Here's what I'm working with:

Solidity — for the smart contract. This is where the actual logic lives. Campaign creation, contribution tracking, goal checking, fund release — all of it written in Solidity and deployed on Ethereum.

Hardhat — for development and testing. Think of it as the environment where I write, compile, test, and deploy contracts without touching real ETH until I'm ready. If Remix was training wheels, Hardhat is the actual bike.

Web3.js — the bridge between the frontend and the blockchain. When someone clicks "Fund This Campaign" on the UI, Web3.js is what talks to their MetaMask wallet and sends the transaction to the contract.

React — for the frontend. Campaign cards, contribution forms, progress bars, wallet connection. The part users actually see.

Four technologies. One DApp. Starting from zero.

Why I'm documenting this as I build

Here's the honest reason.

I learn better when I write. Writing forces me to actually understand what I'm doing instead of copy-pasting from Stack Overflow and hoping it works. When I have to explain something, I find out fast whether I actually get it or just think I do.

So this isn't a finished tutorial. I'm not going to pretend I built this perfectly and now I'm graciously sharing my wisdom.

I'm building it right now. You're reading it as it happens. When something breaks — and things will break — I'll write about that too. When I don't understand something, I'll say so.

That's the deal.

What's coming next

Here's what we're building, piece by piece:

Next — The smart contract. Writing the core Solidity code that handles campaigns, tracks contributions, and moves ETH. This is the heart of the whole thing.

After that — Setting up Hardhat. Getting off Remix, writing real tests, deploying to a testnet.

Then — Connecting MetaMask. Making the frontend actually talk to the contract.

Finally — Wrapping it all together. The full DApp, live on testnet, with everything working.

One feature at a time. One post at a time.

The part that genuinely excites me

Here's what I keep coming back to.

When this DApp is done, there's no server I'm running. No database I'm maintaining. No backend that goes down at 3am and pages me. The contract sits on Ethereum, and as long as Ethereum exists, the DApp exists.

I write the code once. I deploy it. It runs.

Forever.

No AWS bill. No downtime. No "we're performing scheduled maintenance." Just a contract, on a chain, doing exactly what it says.

That's the thing about building on blockchain that web dev can't give you. You don't just build a product. You build something that genuinely doesn't need you anymore once it's live.

For a third-year CS student who can't afford servers — that's pretty great.

Come build this with me

If you're learning Solidity, this is a good project to follow along with. Not too simple to be boring, not too complex to understand.

If you're not learning Solidity — that's fine too. The concepts transfer. What does it mean to write logic that handles real money? What does it mean to build without a backend? These questions matter regardless of your stack.

I'm building it in public. All of it — the working parts and the broken ones.

Let's see what happens.

I'm Srashti Gupta, building in the Web3 space. I write about blockchain, real builds, and things I'm figuring out as I go. Let's connect on LinkedIn.

# Why I Chose Blockchain Over Normal Web Dev (And What I Gave Up)

Srashti — Sun, 14 Jun 2026 05:16:40 +0000

Let me be honest with you about something.

Choosing blockchain over regular web dev as a third-year CSE student is not the "safe" move. Nobody's recruiter is sliding into your DMs because you know Solidity. The placement cell doesn't have a checkbox for "deployed smart contracts on Ethereum."

I chose it anyway. Here's the actual story.

The moment I looked at web dev and felt nothing

First year. Everyone around me was learning React. HTML, CSS, JavaScript, then React, then Next.js, then whatever framework dropped last Tuesday.

I tried. I built things. A portfolio site. A to-do app. The classic beginner projects that every tutorial sends you to build and every recruiter has already seen ten thousand times.

And I kept thinking — who else is doing exactly this right now?

The answer was: a lot of people. A genuinely uncomfortable amount of people. All learning the same stack, building the same projects, competing for the same internships at the same companies.

I didn't want to be in that queue. Not because I'm too good for it — I'm not. But because the queue was already so long, and I wasn't even sure I wanted to be at the front of it.

Then I found the question that changed everything

What if you could write code that nobody could tamper with?

I've written about this before. But it's worth saying again because it's genuinely the reason I switched.

Not the money. Not the hype. Not because "Web3 is the future" — I don't know if it is. Nobody does.

It was that question. The idea that logic could sit on a chain, execute automatically, and be readable by anyone. No company behind it. No server you have to trust. No terms of service that can change overnight.

Code as law. Not metaphorically. Literally.

That idea grabbed me in a way that "build a full-stack CRUD app" never did.

What I actually gave up

I'm not going to pretend this was a cost-free decision. It wasn't.

The internship path is harder.

Web dev has a pipeline. Learn React → build projects → apply to startups → land a frontend internship. It's competitive but it's mapped. The roadmap exists. Companies know what to look for. Candidates know what to build.

Blockchain doesn't have that yet. Not in India. Not at the second-year level. There are companies building in Web3, but they're fewer, they're pickier, and they often want experience that takes longer to build.

I knew this going in. I chose it anyway.

The community is smaller.

Stuck on a React bug? Stack Overflow has fourteen answers, three YouTube walkthroughs, and a Reddit thread from 2019 that somehow still applies.

Stuck on a Solidity error? You're reading the docs, the GitHub issues, and occasionally a Discord server where someone might reply in four hours.

I got used to figuring things out alone. Honestly? That's made me better at it.

The tutorials run out faster.

Web dev content is infinite. You could watch tutorials for a year and still have a queue.

Solidity tutorials are good — Patrick Collins is genuinely excellent — but you hit the edge faster. At some point, you're reading Ethereum Improvement Proposals and audit reports to understand something. That's a different kind of learning.

What I got instead

Here's the thing nobody tells you about picking the less crowded path.

When the field is smaller, you stand out faster.

I'm a second-year student. I've deployed contracts on testnet, I'm building a crowdfunding DApp, and I write about it publicly. In web dev, that's table stakes. In blockchain, at my year, in my city? It's genuinely rare.

I'm not saying I'm exceptional. I'm saying the bar to be visible is lower because fewer people are showing up consistently.

And the problems are genuinely unsolved. In web dev, the wheel has been invented. You're optimizing it. In blockchain, people are still figuring out what the wheel should even be. Smart contract security, gas optimization, decentralized identity, cross-chain bridges — these aren't finished problems. They're open questions.

I want to work on open questions.

The honest version of "follow your passion"

Everyone says follow your passion. Nobody says what happens when your passion is inconvenient.

Blockchain is inconvenient. It's harder to learn, harder to get hired in, and harder to explain to relatives who want to know when you're getting a "real job."

But every time I deploy a contract and watch it execute — no server, no company, no middleman — I feel something that I never felt building a to-do app.

That feeling is worth the inconvenience.

If you're deciding right now

If you're a CS student weighing this choice — I'm not telling you to pick blockchain. I'm telling you what I picked and why.

Web dev is not lesser. It pays well, it has a clear path, and there's real craft in building great products. If React excites you the way Solidity excites me, do React. The passion matters more than the stack.

But if you're in that queue and feeling nothing — maybe look at what's outside it.

The crowded path is crowded for a reason. But it's not the only one.

I'm Srashti Gupta, building in the Web3 space. I write about blockchain, real experiences, and things I'm figuring out in public. Let's connect on LinkedIn.

# What is a Smart Contract? I'll Explain It Like You're 15.

Srashti — Fri, 12 Jun 2026 14:34:12 +0000

Okay real talk.

When I first heard the term "smart contract" — I genuinely thought it was some kind of AI thing. Like a contract that reads itself and highlights the suspicious clauses your lawyer missed.

It is not that.

It's actually way cooler. And also kind of simpler. Let me explain it the way nobody explained it to me.

First, forget everything you know about contracts

A normal contract — the kind lawyers write — is a piece of paper (or a PDF nobody reads) that says:

"If X happens, then Y must do Z."

If you buy a house, the contract says — seller hands over keys, buyer hands over money. Simple enough. But here's the thing: someone has to enforce it. A bank. A lawyer. A court. Some middleman who takes a cut and also goes on holiday at the worst possible time.

A smart contract does the same thing. If X happens, then Y must do Z.

Except nobody enforces it. The code does.

No middleman. No fees to a third party. No "we're processing your request, please allow 5-7 business days."

Just: condition met → action executed. Automatically. On a blockchain. Forever.

The vending machine analogy (because it actually works)

Think of a vending machine.

You put in ₹20. You press B3. The chips drop. Done.

The vending machine doesn't care who you are. It doesn't ask for your ID. It doesn't have a manager who needs to approve your chip request. You gave it the right input, it gave you the right output.

Now imagine that vending machine is:

Publicly visible — anyone can see exactly how it works
Tamper-proof — nobody can secretly reprogram it to steal your money
Running forever — it can't be "shut down" by any one person

That's a smart contract.

Okay but what does the code actually look like

Here. I'll show you the simplest one that actually does something:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract SimpleStorage {
    uint256 public myNumber;

    function store(uint256 _number) public {
        myNumber = _number;
    }

    function retrieve() public view returns (uint256) {
        return myNumber;
    }
}

This contract does two things:

Store a number on the blockchain
Let anyone retrieve that number

That's it. No database. No backend server. No hosting bill. The number lives on Ethereum — accessible to anyone, changeable only through the store function, and permanent.

"But Srashti, that's just a variable. My first Python script did that."

Yes. But your Python script lived on your laptop. This lives on a global decentralized network that nobody controls. That's the difference.

Why does this matter? (The part that actually hit me)

Let me give you a real example.

Imagine you and a friend make a bet. India wins the World Cup — you owe them ₹500. They win — they owe you ₹500.

Normal situation: one of you is going to "forget." Or dispute the terms. Or just Venmo the wrong amount and pretend it's fine.

Smart contract situation: you both lock ₹500 into a contract. The match result gets submitted (via something called an oracle — different topic). The contract automatically sends ₹1000 to the winner. No arguments. No awkward reminders. No "I'll pay you back next week."

The code is the agreement. The code is the enforcement. They are the same thing.

The part that sounds too good to be true

"But what if the code has a bug?"

Great question. This is actually the terrifying part.

Once a smart contract is deployed on Ethereum, it's immutable — meaning it can't be changed. If there's a bug, the bug is there forever. In 2016, a vulnerability in a smart contract called The DAO got exploited, and $60 million was drained.

The code was the law. The code had a flaw. The law had a flaw.

This is why security in Solidity is treated like a religion. You don't ship and hotfix. You audit, test, audit again, and then maybe think about deploying.

It's also why I find it more interesting than regular web dev — the stakes are real. A badly written if-statement doesn't just break a feature. It can empty a wallet.

So where do smart contracts actually live

On the Ethereum blockchain. Specifically, they live at an address — just like your wallet has an address, contracts do too.

Anyone can interact with a contract if they have its address and ABI (basically the contract's instruction manual — what functions exist and what they take as input).

You don't need to trust the developer. You don't need to trust the platform. You just read the code and decide for yourself. Because the code is open, on-chain, and exactly what's running.

That's the part that got me. Not the tech. The philosophy.

What if the rules of a system were visible to everyone? What if "trust me" could be replaced by "read this"?

That's what smart contracts are building toward.

The quick version if you zoned out

A smart contract is code that runs on a blockchain
It executes automatically when conditions are met — no human needed
It's immutable once deployed — which makes security critical
Anyone can read it — no black boxes, no "trust us"
It's not AI. It's not magic. It's just logic that nobody can tamper with

What's next

From here, smart contracts get more interesting — events, mappings, modifiers, inheritance. The SimpleStorage above is barely scratching the surface.

But the mental model? You now have it.

Code is the contract. The blockchain is the judge. And nobody can bribe either of them.

still learning still documenting

I Learned Solidity From YouTube. Here's Exactly What Happened.

Srashti — Wed, 10 Jun 2026 10:42:26 +0000

Hey, I'm Srashti 👋 I'm a CSE student who is genuinely obsessed with blockchain and decentralized technology.

While the standard path for many computer science students starts with building classic CRUD apps, I found myself pulled down a different rabbit hole entirely: deploying smart contracts on Remix and trying to understand the inner workings of Ethereum. I learned Solidity through YouTube, broke countless contracts, and slowly started to stitch the pieces together.

Here is the honest breakdown of how I went from struggling with basic syntax to deploying decentralized applications—and how you can do it too.

Why Web3 Captured My Attention

I wasn't chasing the crypto hype or looking at NFTs. What actually pulled me into the ecosystem was a foundational software engineering question:

What if you could write code that nobody could tamper with?

No middlemen. No centralized servers controlled by a single entity. Just pure, immutable logic sitting on a blockchain, executing exactly as written forever. That concept shifted how I thought about programming. Eager to understand it, I went looking for high-quality educational resources and stumbled onto Patrick Collins' content on YouTube.

Finding the Right Mentor

If you are a beginner trying to learn Solidity, Patrick Collins is highly recommended for a reason. His teaching style is clear, honest, and structurally sound. He explains the why behind architectural patterns, not just the how. For someone curious but completely new to web3 development, his deep dives made all the difference.

What Is Remix? (And Why It’s the Perfect Launchpad)

Remix IDE is a browser-based development environment for writing, compiling, and deploying Solidity smart contracts.

No Setup Required: You don't have to fight your local environment, install dependencies, or configure path variables. You just open the tab and write code.
Heavy Lifting Included: Remix handles the compiler, local deployment runtimes, and test networks out of the box, allowing you to focus purely on learning the language semantics.

The Gap Between Theory and Code

Understanding the high-level theory of a smart contract is straightforward. It functions essentially like a digital vending machine: you provide the correct input, and it guarantees a specific output without human intervention.

But writing actual Solidity for the first time? That is where the friction starts. Take a look at this basic SimpleStorage contract:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract SimpleStorage {
    uint256 public myNumber;

    function store(uint256 _number) public {
        myNumber = _number;
    }

    function retrieve() public view returns (uint256) {
        return myNumber;
    }
}

It looks simple on paper, but as a beginner, every line introduces a new mental hurdle:

Why does every file require an SPDX-License-Identifier?
What is the specific role of the pragma solidity compiler flag?
Why favor uint256 explicitly over standard integers?
How do visibility modifiers like public alter the state behavior and gas metrics?

Bridging the gap between conceptual understanding and functional syntax is where most developers stall. My approach was iterative: I consistently rewatched technical breakdowns, analyzed compiler errors, and rewrote the same logic line-by-line until the underlying architecture made sense.

The Moment It Clicked

Everything changed when I deployed this contract to a local simulated network inside Remix. I executed the store function, passed a parameter, signed the transaction, and called retrieve. Seeing the state update seamlessly on a simulated blockchain layout made the theory real. There was no traditional database or centralized server backend—just the autonomous execution of the code.

Key Takeaways Beyond the Syntax

Moving past the basics taught me a few fundamental realities of blockchain development:

Solidity requires a completely different mental model. While the syntax mirrors JavaScript, the execution environment does not. You are writing code for a decentralized state machine where every operations carries a gas cost and state modifications are permanent. Optimization is a necessity, not an afterthought.
Remix is a testing ground, not a production suite. Remix is incredible for rapid prototyping. However, scaling up means transitioning to professional frameworks like Hardhat or Foundry, and managing state interactions via developer tools like MetaMask.
Debugging is the best teacher. Deploys will fail, transactions will revert, and logic will break. Analyzing transaction logs and EVM execution errors teaches you more about the runtime environment than any passive tutorial ever could.

My Current Stack and Next Steps

Since writing that first SimpleStorage contract, I've expanded my technical toolkit to include:

Advanced smart contract development with Solidity
Testing, scripting, and local deployment pipelines using Hardhat
Integrating decentralized backends with frontend applications using MetaMask and Web3.js

The learning curve in Web3 is continuous, and the best way to master it is to build actively. If you're looking to start, don't wait until you feel like you know everything. Open up an IDE, write a basic contract, analyze the edge cases, and start deploying.

Are you currently learning Solidity or building in Web3? Let's connect in the comments below—I'd love to hear about the projects you're working on or the resources that helped you clear the hurdle!