HackIndia Logo
HackathonsNewsSkillsGrowth
HackIndia LogoContact: +91 9910125804

General

  • Companies
  • Colleges
  • Board of Advisors
  • Brand Ambassadors
  • FAQ
  • Contact
  • Report a Bug

Hackathons

  • Upcoming Hackathons
  • Judges
  • Mentors
  • Partners
  • Participating Colleges
  • Testimonials

Resources

  • About Us
  • Branding
  • Latest News
  • Growth
  • Skills
  • Builders
  • Ecosystem
  • Forum
  • Ideas
  • Prompt Optimizer
  • Games

© 2026 HackIndia. All rights reserved.

Privacy PolicyTerms of ServiceCode of ConductSitemap

Build 2.139 · 05 Nov 2026, 10:27 UTC

    HackIndia
    HackathonsNewsInternshipsSkillsGrowthPro Perks
    SolidityWorking towardsSolidity
    0%

    0 of 10 steps done · +100 XP · +50 SHARP when it is yours

    1. 1Write your first clean contract5 min · +10 XP · +5 SHARP
    2. 2Use types and data locations4 min · +10 XP · +5 SHARP
    3. 3Control state and access5 min · +10 XP · +5 SHARP
    4. 4Set up Hardhat tests4 min · +10 XP · +5 SHARP
    5. 5Spend less gas by design4 min · +10 XP · +5 SHARP
    6. 6Avoid student-contract vulnerabilities4 min · +10 XP · +5 SHARP
    7. 7Deploy to a testnet4 min · +10 XP · +5 SHARP
    8. 8Submit the recruiter-ready repo4 min · +10 XP · +5 SHARP
    9. The check10 questions, 7 to pass · +10 SHARP
    10. Hand in the taskA project that uses the skill
    11. Skill and certificate+100 XP · +50 SHARP
    Lesson 6 of 8 4 min

    Solidity

    Avoid student-contract vulnerabilities

    • +10 XP for this lesson
    • +100 XP when the skill is proved
    • Nobody here has proved it yet
    In 30 seconds
    • Spot the common bugs that make student Solidity projects look unsafe.
    • Use Checks-Effects-Interactions, msg.sender, and bounded work by default.
    Add a short security notes section that recruiters can read quickly.
    Key point

    One rule

    Assume every public or external function will be called by a stranger, a bot, or another contract. Write the function so it is still safe.

    A safer contract checks first, updates its own state second, and talks to other contracts last. This is Checks-Effects-Interactions.

    Public means public

    Do not store secrets in a contract. Private variables are not secret. Local variables are not secret either. Anyone can inspect contract data on-chain.

    Use Solidity 0.8.x arithmetic checks. Do not add unchecked blocks unless you can explain why wrapping is safe.

    Common mistake

    Bad authorisation

    Never use tx.origin to decide who is allowed to do something. A phishing contract can trick the original wallet into calling through it.

    Use msg.sender-style checks, a clear owner variable, or a reviewed library such as OpenZeppelin Ownable installed from the package. Do not copy-paste library source into your repo.

    Example

    Safer withdrawal

    This shape is better than pushing Ether to users inside a loop. Each user withdraws their own balance.

    The important part is order: check amount, set balance to zero, then make the external call.

    // SPDX-License-Identifier: MIT
    pragma solidity ^0.8.0;
    
    contract PrizeVault {
        mapping(address => uint256) public winnings;
    
        error NothingToWithdraw();
        error TransferFailed();
    
        function claim() external {
            uint256 amount = winnings[msg.sender];
            if (amount == 0) revert NothingToWithdraw();
    
            winnings[msg.sender] = 0;
    
            (bool ok, ) = msg.sender.call{value: amount}("");
            if (!ok) revert TransferFailed();
        }
    }
    Tip

    Watch external calls

    Any Ether transfer or call to another contract hands control away. That other contract may call you back before your first function finishes.

    For simple projects, avoid complex cross-contract calls. If you must use them, keep the contract small, test the failure path, and consider ReentrancyGuard from OpenZeppelin Contracts 5.x.

    Common mistake

    Unbounded loops

    A loop over a storage array can work in your test with 3 users and fail later with 3,000 users. If the loop needs more gas than a block allows, the function can become unusable.

    Do not write one admin function that pays every participant, deletes every record, or recalculates every score. Prefer per-user actions, pagination, or fixed-size limits.

    Your to-do

    Security notes file

    Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

    0 of 5 done

    Your to-do

    Do this now

    Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

    0 of 5 done

    Sources

    Checked against the current documentation on 21 September 2026.

    • Types · docs.solidity.org
    • Developing smart contracts · docs.openzeppelin.com
    • Utils · docs.openzeppelin.com
    • Security Considerations · docs.solidity.org

    Quick check

    0 of 2 right
    1.Your contract sends Ether to a user. What order should the function follow?
    2.You need owner-only access for an admin function. What should you avoid?

    Answer the quick check to finish this lesson.

    ← Lesson 5Skip to lesson 7 →
    Solidity
    Working towards
    Solidity +100 XP

    0 of 8 lessons done · proved by a project that uses the skill

    See the track