Concepts You’ll Master

• Calling functions of another contract

• Address casting (address(contract).functionName)

• Using import statements to organize code

Example Application

Imagine having one contract ask another to do some math for you — that’s exactly what we’re doing here. By calling another contract, we can:

• Reuse code

• Keep contracts modular

• Interact safely across deployed contracts

This mirrors real-world applications, like price oracles, DeFi contracts, or multi-contract systems where one contract depends on another for logic or data.

Code Overview

• Calculator contract: Implements basic arithmetic functions.

• SmartCalculator contract: Calls the Calculator contract to compute results.

• Key Solidity patterns: Inter-contract calls, address casting, and imports.

Submission and Code

Check out my GitHub submission here: SmartCalculator.sol Day 9

Day 8 of the #30DaysOfSolidity challenge brings a fun and practical project TipJar.sol!
This contract is like a digital “Buy Me a Coffee” button, but smarter it supports multiple currencies and real Ether tips directly on-chain.

You’ll learn how to handle Ether payments, simulate currency conversions, and track who contributed, all within a Solidity smart contract.

Concepts You’ll Master

• Payable functions — accepting Ether directly in a contract.

• Currency conversion logic — simulating tips in different denominations (like USD or EUR).

• msg.value — understanding how much Ether a user sends.

• Mapping contributors — storing and tracking who sent what.

Example Application

Imagine you’re a creator or developer who wants to receive tips in Ether.
Your friends or followers can:

• Send you ETH directly as a tip.

• Choose a simulated “currency” like USD or EUR to represent the value.

• View total contributions and who has tipped so far.

This is similar to a decentralized version of Buy Me a Coffee, but powered entirely by Solidity and Ethereum.

Code Overview

Here’s what the contract does:

• Accepts Ether using a payable function.

• Simulates multi-currency tips (e.g., converts “USD tips” to ETH).

• Tracks each user’s total tip balance.

• Allows the contract owner to withdraw the total funds.

The contract’s logic demonstrates:

• Secure ETH transfers using msg.sender and msg.value.

• Maintaining transparency in transactions.

• Adding flexibility through simulated currency conversions.

Real-World Insight

Tipping and micropayments are essential for supporting creators, developers, and open-source projects.
By learning how to implement an on-chain Tip Jar, you’re exploring the foundations of decentralized crowdfunding, content monetization, and Web3 patronage models.

My Submission

You can check out my full submission here 👇
Day 8 GitHub Submission – TipJar.sol

Challenge Overview

Contract Name: SimpleIOU.sol
Concept: On-chain debt and repayment tracking among friends
Goal: Learn to handle Ether transfers, manage user balances, and ensure secure validation

Challenge :

Build a simple IOU contract for a private group of friends. Each user can deposit ETH, track personal balances, log who owes who, and settle debts — all on-chain.

What I Learned

This challenge expanded my understanding of real-world financial modeling using Solidity. Here’s what I explored:

• Addresses and Payable Functions:
  I learned how to mark functions as payable to allow them to receive Ether.

• Ether Transfers:
  Used transfer() and call() methods to move ETH securely between users.

• Nested Mappings:
  Introduced a mapping structure like mapping(address => mapping(address => uint)) to track who owes who.

• Validation with require():
  Ensured that only valid transactions are allowed — for example, you can’t repay a debt you don’t owe!

How the Contract Works

1. Deposit Ether:
   Users can deposit ETH into the contract and update their balances.

2. Record Debt:
   A user can record that they owe another user a certain amount.

3. Repay Debt:
   When repaying, the contract transfers ETH and updates both users’ balances.

4. Transparency:
   Anyone can view their current debts and check who owes them.

Example Code Snippet

pragma solidity ^0.8.0;

contract SimpleIOU {
    mapping(address => mapping(address => uint)) public debts;
    mapping(address => uint) public balances;

    function deposit() external payable {
        balances[msg.sender] += msg.value;
    }

    function recordDebt(address _to, uint _amount) external {
        require(balances[msg.sender] >= _amount, "Insufficient balance");
        debts[msg.sender][_to] += _amount;
    }

    function repayDebt(address _to, uint _amount) external payable {
        require(debts[msg.sender][_to] >= _amount, "No such debt");
        debts[msg.sender][_to] -= _amount;
        payable(_to).transfer(_amount);
    }
}

Submission

My GitHub Submission:
Day 7 – SimpleIOU.sol

Key Takeaway

This challenge felt like building a mini decentralized Venmo, but on-chain.
I learned how to combine state management, Ether transfers, and validation to simulate real financial relationships between users.

Every line of code taught me more about how Solidity handles money securely.

Day 6 of the 30DaysOfSolidity challenge introduces a fun and practical concept building a digital piggy bank on the blockchain!
This contract allows users to deposit and withdraw Ether, helping you understand how to manage balances, handle payable functions, and track ownership using msg.sender.

It’s like creating your own decentralized savings account — transparent, secure, and completely on-chain.

Concepts You’ll Master

• Payable Functions — Allow contracts to receive Ether.

• Deposits & Withdrawals — Managing Ether safely on the blockchain.

• Mappings — Tracking user balances (address => uint).

• msg.sender — Identifying who is sending or withdrawing Ether.

Code Breakdown

Here’s what the contract does step-by-step:

1. Deposit Ether:
   Users can send Ether to the contract using a deposit() function marked as payable.
   Their deposit amount is stored in a mapping that keeps track of all user balances.

2. Withdraw Ether:
   Users can withdraw any amount they’ve deposited — but only up to their available balance.
   The contract checks using a require() statement to prevent overdrawing.

3. Check Balance:
   Each user can view how much Ether they’ve saved in their personal piggy bank.

4. Security:
   The logic ensures users can’t withdraw more than they own, maintaining fairness and safety.

Real-World Insight

This simple “Piggy Bank” concept forms the foundation of many DeFi applications — from staking systems to lending platforms.
Understanding payable functions and Ether transfers is crucial for any Solidity developer aiming to build secure, value-driven dApps.

My Submission

Day 6 GitHub Submission – EtherPiggyBank.sol

Conclusion

This challenge proves how even simple concepts in Solidity can model real-world financial behavior.
You’ve just built your first on-chain savings system one deposit at a time!

🔗 My Submission: Day 5 — AdminOnly.sol on GitHub

Concepts You’ll Master

• Modifiers — reusable pieces of logic that restrict or validate function calls.

• msg.sender — identifies who is calling the function (the user’s wallet address).

• Basic Access Control — allows only the owner to perform certain actions.

Example Application

Imagine a Treasure Chest controlled by an owner:

• The owner can add treasures.

• The owner can approve withdrawals for specific users.

• Users can withdraw only if approved and haven’t withdrawn before.

• The owner can also transfer ownership or reset withdrawal statuses.

This setup is just like having admin privileges in a game or platform — you decide who gets access and what they can do.

Code Overview

Here’s what the AdminOnly.sol contract demonstrates:

• Ownership Initialization: The deployer automatically becomes the contract owner.

• Restricted Functions: Using a custom onlyOwner modifier to secure certain functions.

• Controlled Withdrawals: Ensures users can only withdraw if permitted.

• Ownership Transfer: Admin can pass control to another address.

These concepts lay the foundation for more complex smart contracts such as NFT marketplaces, DAOs, and DeFi platforms, where admin permissions are essential.

Real-World Insight

Access control is one of the most fundamental design patterns in blockchain development.
From governance contracts to treasury systems, being able to restrict functions to trusted entities is vital for maintaining security and trust in decentralized systems.

Reflection

Today’s challenge reminded me that even though blockchain is decentralized, controlled permissions are key to order and security.
Learning how to manage ownership and access is an important step toward building secure and scalable dApps.

Day 4 of the 30 Days of Solidity challenge takes us deeper into real-world smart contract logic — this time, we’re building a simple auction house!

We’ll use Solidity features like if/else statements, time tracking (block.timestamp), and basic bidding logic to simulate an on-chain auction where users compete to be the highest bidder before time runs out.

Concepts You’ll Master

• Using if/else statements for decision-making

• Handling time on the blockchain using block.timestamp

• Implementing bidding logic and updating highest bids dynamically

Example Application

We’ll create a simple auction where:

• Users can place bids on an item.

• The highest bidder wins once the auction timer expires.

• Solidity’s block.timestamp helps track when the auction should end.

This is like building a decentralized eBay, showing how logic and time control interact in smart contracts.

Code Overview

Here’s what the contract handles:

• Auction creation — defining an item, starting price, and end time.

• Bidding system — users can place higher bids as long as time hasn’t run out.

• Winner logic — once the auction ends, the contract determines the highest bidder and closes the auction.

You’ll rely on if/else checks to ensure:

• The auction hasn’t ended.

• The new bid is higher than the previous one.

• Only valid bids are accepted.

Real-World Insight

Auctions are at the core of many blockchain applications — from NFT marketplaces to token sales and governance proposals.
Understanding how to handle conditional logic and timestamps prepares you for writing more complex decentralized applications.

🔗 GitHub Submission

Here’s my official submission for Day 4: AuctionHouse.sol
👉 View Pull Request

• Users can vote for their favorite candidates.

• The contract remembers who voted, so each address can vote only once.

• Votes for each candidate are stored on the blockchain.

This teaches how to manage arrays, mappings, and basic voting logic in Solidity.

Key Concepts Learned

1. Arrays – storing a list of candidates.

2. Mappings – linking voters to their chosen candidate.

3. Events – notifying the blockchain when someone votes.

4. Require statements – ensuring valid candidate selection and preventing double voting.

PollStation.sol Overview

Here’s what the contract does:

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

contract PollStation {
    string[] public candidates; // list of candidates
    mapping(uint => uint) public votes; // candidateId => vote count
    mapping(address => bool) public hasVoted; // check if an address voted

    event Voted(address voter, uint candidateId);

    constructor(string[] memory _candidates) {
        candidates = _candidates; // add candidates when deploying
    }

    function vote(uint candidateId) public {
        require(candidateId < candidates.length, "Invalid candidate");
        require(!hasVoted[msg.sender], "You have already voted");

        votes[candidateId] += 1;
        hasVoted[msg.sender] = true;

        emit Voted(msg.sender, candidateId);
    }

    function getCandidatesCount() public view returns (uint) {
        return candidates.length;
    }

    function getCandidate(uint candidateId) public view returns (string memory, uint) {
        require(candidateId < candidates.length, "Invalid candidate");
        return (candidates[candidateId], votes[candidateId]);
    }
}

How It Works

1. Adding candidates: When deploying, you pass an array of candidate names, e.g., ["Alice","Bob","Charlie"].

2. Voting: Users call vote(candidateId). The contract:

   • Checks the candidate exists

   • Ensures the voter hasn’t voted before

   • Adds a vote and marks the address as voted

   • Emits a Voted event

3. Checking results:

   • getCandidatesCount() → total candidates

   • getCandidate(id) → returns candidate name and vote count

Key Takeaways

• Arrays and mappings are essential for structured data on-chain.

• Events help track activity transparently.

• Smart contracts can enforce rules (like “one vote per address”) automatically.

🔗 Links

• GitHub Submission: PollStation.sol

• Full Challenge Calendar: Web3 Compass

The Challenge

The task for Day 2 was to build a contract called SaveMyName.sol.
The idea is simple: let users save their name and a short bio on-chain, then be able to retrieve it whenever needed.

This introduces the use of strings in Solidity and teaches how to store data in state variables.

Concepts Covered

• State variables → using string to hold data.

• Storage and retrieval → functions to save and return values.

• Function parameters & returns → passing user input and getting it back.

The Code

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

contract SaveMyName {
    // State variables
    string public name;
    string public bio;

    // Function to save name and bio
    function saveProfile(string memory _name, string memory _bio) public {
        name = _name;
        bio = _bio;
    }

    // Function to retrieve both at once
    function getProfile() public view returns (string memory, string memory) {
        return (name, bio);
    }
}

🔎 How It Works

1. Deploy the contract on Remix.

2. Call saveProfile("Alice", "I build dApps").

3. Use getProfile() → it will return both the name and the bio stored on-chain.

This simple contract demonstrates how blockchain can be used for basic identity and profile storage.

🚀 My Submission

• 📝 Code: Day 02 on GitHub

• 🔗 PR: Day 02 Submission PR

Reflection

Compared to Day 1, today’s challenge made me think more about data types. Storing numbers was straightforward, but handling text (string) gave me a better understanding of how Solidity manages different forms of data.

Building something as simple as a profile reminds me how real-world applications like decentralized social media or identity systems begin with these small building blocks.

Tomorrow, I’ll continue with Day 3 and keep building step by step.

I submitted my solution here:
Day 01: My first Solidity contract PR

What I Built

• A state variable (uint count) to hold the current count

• A click() function that increments the counter

• A decrement() (or unclick()) function to decrease the counter (with checks so it doesn’t go negative)

• (Optional) A reset() function to bring the counter back to zero

This contract teaches how to declare variables, modify them via functions, and manage state—one of the core powers of smart contracts.

Key Learnings

Even a small counter helps internalize how data lives and changes on-chain.

How I Did It (Simplified Steps)

1. Built the contract in Remix

2. Downloaded or copied the .sol file

3. Placed it in my local forked repo under Day01/

4. Committed & pushed changes

5. Created a Pull Request

6. Submitted the PR link in Telegram to register my submission

Reflections

Day 1 felt approachable yet powerful. It confirmed that even the simplest contracts teach core Solidity principles: state, functions, and contract logic.

I’m excited to continue this 30-day challenge and share what I learn along the way.