Imagine you build a suggestion box out of clear glass and bolt it to the wall in a busy hallway. Everyone can see who dropped in a slip and what it says, but you've added a lock so nobody can tamper with the slips once they're inside. That's this paper: a transparent, tamper-evident container marketed as a voting system, missing the property that actually matters — secrecy. The committed claim is that a Solidity/Hardhat/React/MetaMask stack can support hospital ethics committee voting with role-based access, duplicate-vote prevention, and receipt-based inclusion verification. The authors are upfront that vote events expose wallet addresses and vote values on-chain, meaning the system provides pseudonymous auditability rather than ballot secrecy. This is an honest disclosure, but it also means the system cannot be used for any vote where coercion, retaliation, or social pressure is a concern — which describes nearly every ethics committee deliberation worth having. The evaluation consists of 22 passing Hardhat unit tests and gas measurements on a local node, including 284,137 gas per vote (~$0.50–$2.00 at typical mainnet prices, though the paper never prices it). A 12-participant Monte Carlo simulation uses assumed probability distributions rather than real human subjects, so it tells you about the model's assumptions, not about how people actually behave when voting on whether to approve a clinical trial. No adversarial testing was conducted. The paper lists residual risks — multiple wallets, admin compromise, front-running, denial of service — but does not test any of them. The architecture is standard dApp engineering: Solidity smart contracts on Ethereum (tested on Hardhat's local EVM), a React frontend, MetaMask for wallet management, and ethers.js for contract interaction. There is no zero-knowledge proof layer, no homomorphic encryption, no mixnet — none of the cryptographic machinery that distinguishes serious e-voting research from a web3 tutorial with a governance theme. The receipt-hash mechanism verifies transaction inclusion but is explicitly not receipt-free, meaning a voter can prove how they voted to a coercer. The baseline problem is severe. The paper does not name or compare against any existing e-voting system — not Helios, not Belenios, not the Swiss Post system, not even a paper-ballot baseline. Without a ladder to climb, we cannot assess whether this system improves on anything. The 22-test suite covers happy-path functionality (role assignment, vote casting, state transitions) but not the adversarial scenarios that define voting-system security. The honest read on what's missing: a real user study with actual ethics committee members, encrypted ballots (e.g., via SNARKS or threshold encryption), and adversarial red-teaming. The authors acknowledge all of these gaps in their future-work section. The most likely reason they weren't included is scope — this reads as a conference demo paper, not a security research contribution. The IEEE AIBThings venue is a broad AI/blockchain/IoT conference, not a specialized security or e-voting venue, and the work is calibrated accordingly. For practitioners: this is a clean pedagogical example of role-gated smart contract design with event-based auditability. If you're teaching a blockchain development course and need a worked example with tests, it's useful. If you're evaluating whether to put your hospital's ethics votes on Ethereum, this paper does not give you the evidence you need — and to the authors' credit, they mostly say so.
