Faisal Khan.

Traditional voting systems — paper ballots, centralized e-voting databases — all share one weakness: you have to trust the people running them. I built a fully on-chain voting dApp with Solidity 0.8.24, React, and ethers.js. Every election, candidate, and ballot lives in contract storage. A nested mapping makes double voting impossible, while custom errors, OpenZeppelin Ownable, ReentrancyGuard, and time-locked elections keep the system efficient and verifiable. The 21-test Hardhat suite covered double votes, invalid time windows, unauthorized actions, and bad inputs. The biggest lesson: writing the contract is easy; getting it right is the hard part.

Security in smart contracts is not a feature you add at the end. It is a set of habits built into every function: validate before touching state, protect value and state changes with ReentrancyGuard, prefer typed custom errors over revert strings, define access control from day one, and validate every input and time window at the boundary. None of these patterns is exotic. That is the lesson — smart contract security is mostly discipline, testing, and consistently handling the failure path.

Component thinking, deliberate state management, event-driven interfaces, and TypeScript strictness all transfer naturally from React to Solidity. But gas changes everything, immutable contracts leave no room for casual hotfixes, debugging requires a different toolkit, and payable functions handle real value. Coming from React is not a disadvantage: you already think in state, events, and components. You just need to learn what happens when the runtime charges you for every operation.