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.
Top comments (0)