MiN: A Decentralized On-Chain Cab Service

I led a team called 5G Only to build MiN, a decentralized cab-booking app, for Smart India Hackathon 2024 (Problem ID 1589, under the Blockchain & Cybersecurity theme). The pitch was simple: what if a ride-hailing service didn't need a company sitting in the middle taking a cut and holding everyone's data?

Instead of a central platform matching riders and drivers, MiN puts that logic on-chain. The blockchain becomes the trust layer, so riders and drivers can transact directly.

Why I made it

Every ride-hailing app has the same shape: a company owns the matching, the payments, and your identity. That central party is convenient, but it's also a single point of control and cost. For SIH we wanted to show a different model:

direct matching between riders and drivers, with no middleman,
reduced cost, because there's no platform commission skimmed off every ride,
transparent, tamper-proof transactions recorded on-chain.

The goal wasn't to ship a production Uber-killer in a hackathon weekend. It was to prove the core mechanics — identity, matching, and payment — could live in smart contracts.

How it's built

MiN splits cleanly into contracts and a frontend:

Smart contracts (Solidity) — the on-chain logic, developed and deployed with Hardhat. Two main contracts carry the app:
- a Ride Request Contract for the booking flow,
- a User Info Contract for on-chain user identity.
Frontend (Next.js) — a dApp (cab-daap) that talks to the chain through Web3.js, with MetaMask as the wallet, reading the deployed contract addresses from environment config.
Escrow system — funds are securely held during the ride process rather than paid upfront to a stranger, so neither side has to fully trust the other before the trip completes.

Locally the whole thing runs on a Hardhat node: compile the contracts, spin up the local chain, deploy both modules, wire their addresses into the frontend, and open it in the browser against MetaMask.

What I learned

Leading this at a hackathon taught me as much about scoping as about Solidity:

Escrow is the real primitive. The interesting part of a decentralized service isn't matching — it's holding money safely between two parties who don't trust each other.
On-chain identity changes the data model. Once identity lives in a contract, you stop thinking about user tables and start thinking about who controls what.
Contracts need respect. We leaned on smart contract best practices and treated auditability as a first-class concern, because on-chain bugs aren't something you can hotfix away.

For a longer-term build I'd move to a Layer 2 like Polygon to keep transaction costs sane — Ethereum mainnet fees would make short rides absurd.

If you want to look at the code, here it is: SIH2024 on GitHub.