VeriRx
Inspiration
What does a microbiology graduate have to do with writing code? Most people would not find an easy answer. Neither did I, for a long time.
I studied microbiology at university and have spent time close to healthcare, close enough to know how much trust people place in a box of medicine without any real way of checking what is actually inside it. Separately, I have always been the kind of person who needed to know how technology works underneath, which is what pulled me into software engineering in the first place.
Web3 sat outside that curiosity for a long time. I felt I had not earned it yet, still learning how the internet itself worked before trying to climb a new mountain on top of it. MLH pushed me into it anyway, through the 100 Days of Solana challenge. I did not finish it, but I understood enough by the time I stopped: wallets, transactions, and what it really means for something to live permanently on a blockchain.
Later, thinking about what project would actually be worth finishing, I went back to what I already know. Fake and substandard medicine is a real, dangerous problem in Nigeria, one that agencies like NAFDAC fight every single day. A counterfeit pill packaged to look real is often impossible for a patient or even a pharmacist to catch on the spot. That is exactly the kind of problem a tamper proof, permanent record is good for. VeriRx is where those two unrelated parts of my life finally met.
What it does
VeriRx lets a pharmaceutical manufacturer register a drug batch, name, batch ID, manufacture date, expiry date, by connecting a Solana wallet and signing one transaction. That record is written permanently to Solana using the Memo program, so anyone can independently verify it on Solana Explorer without needing to trust me or the app.
Because Solana itself has no way to search transactions by their content, VeriRx also keeps a small public lookup index in Firestore, mapping a batch ID to its transaction. This index exists purely so a lookup is instant. The blockchain record is what actually guarantees the data has not been tampered with, not the index.
Anyone, a pharmacist, a patient, a regulator, can enter a batch ID on the Verify page and get an immediate answer: genuine, expired, or never registered at all.
How I built it
- React, TypeScript, TanStack Start, Tailwind CSS, and Vite for the frontend
- @solana/wallet-adapter-react and @solana/web3.js for wallet connection and building and sending the on chain transaction, targeting Solana Devnet
- The Solana Memo program to record batch data on chain, chosen deliberately over writing a custom program so the project stayed realistic to finish rather than stalling on smart contract development
- Firebase Firestore for the public lookup index, with security rules that allow public reads but block any update or delete, so a registered batch can never be altered after the fact
- Deployed on Netlify
Challenges I ran into
Getting a real wallet connection working reliably was harder than expected. I hit a broken dependency inside a wallet adapter package, a Node versus browser compatibility issue with Solana's own libraries, and eventually discovered my Phantom browser extension itself had a corrupted internal state, confirmed by testing on a completely unrelated production Solana site before finally fixing it.
The bigger challenge came when deploying to Netlify. The app uses server side rendering, and Solana's libraries are not fully compatible with running inside a Node based server function. The fix required isolating all wallet related code into a client only module using TanStack Start's own client only boundary tooling, so the server never even attempts to load code that was never meant to run there.
Accomplishments that I am proud of
A real, working, end to end loop: connect a wallet, sign a genuine transaction, watch it confirm on Solana Devnet, and look it back up moments later, all without a single fake or mocked piece of data left in the flow. I am also proud of catching and fixing a server crash before it reached real users, and of shipping a Firestore setup that is actually locked down rather than left wide open out of convenience.
What I learned
That building on Solana in a modern frontend framework means understanding two worlds at once, the blockchain layer and the server rendering layer, and that they do not always agree with each other by default. Also, that a working demo backed by an honest story about real limitations is more convincing than pretending something is more finished than it is.
What's next for VeriRx
The clearest next step is closing the one honest gap in the current design: the Firestore index can be written to by anyone who calls the right function directly, even though the app itself only ever writes correct data. A small server side check that verifies a signature against the real Solana transaction before accepting it into the index would close that gap properly. Beyond that, moving from Devnet to Mainnet, and eventually a custom on chain program instead of the Memo program, are the natural next steps once the core idea has proven itself.
Built With
- css
- javascript
- react
- solana
- tailwind
- tanstack
- typescript
Log in or sign up for Devpost to join the conversation.