-
-
Brush buddy Demo
-
Our computer vision model verifies the session, an oracle signs the proof, and the user claims a streak on-chain via Solana and Phantom.
As computer science students, we don't have the best reputation for good hygiene... That's why we built BrushBuddy -- a real-world verification oracle that allows proof of hygiene to be proven on-chain.
BrushBuddy is a system that observes physical activity through a camera, verifies it using computer vision, converts the result into a cryptographically signed receipt, and updates a user’s state on Solana.
While most health apps rely on easily faked client-side logic (you can just say you did the habit), BrushBuddy uses a sovereign oracle architecture to ensure that only authenticated, time-bound brushing sessions are recorded on the blockchain. This turns a physical habit into a tamper-resistant digital record.
How it works
A webcam stream is processed in real time using a YOLOv8 model that detects:
- a person
- and a toothbrush
The system accumulates verified brushing time and only succeeds after a continuous, confident detection period. This prevents simple spoofing (like briefly showing a toothbrush).
When the brushing session completes, the backend constructs a JSON payload containing:
- verified duration
- detection confidence
- timestamp
- user wallet
The server signs this payload using Ed25519.
This signed receipt is the oracle proof: a cryptographic statement that the action actually occurred. A Solana program verifies:
- the oracle’s signature
- nonce replay protection
- user ownership
If valid, the contract updates the user’s streak account on-chain. The blockchain never trusts the client, rather, it trusts the signed oracle receipt.
Challenges we ran into
One of the hardest parts of the project was getting cryptographic verification working correctly on-chain.
Our oracle signs a receipt using Ed25519, and the Solana program must verify that signature before updating a user’s streak. In practice this was much more difficult than expected. We had to canonicalize the JSON payload so that the exact same byte representation was produced off-chain and verified on-chain. Small differences in serialization, field ordering, or encoding caused the signature verification to fail, which was a big pain point.
We also implemented nonce-based replay protection, which required correctly reading and validating instruction data and ensuring a receipt could never be reused. Debugging this was challenging because failures only appeared during transaction simulation and required inspecting Solana program logs and compute budget behavior. Further, since it is next to impossible to undo a cryptographic receipt, the program was difficult to test in practice, since we set it up to only allow two receipts a day.
Most of our development time was spent not on the UI or the model, but on making the oracle receipt verifiable and secure. Once Ed25519 verification worked reliably, the system finally became trustless -- the blockchain was no longer trusting the client or our server, only a valid signed proof.
Log in or sign up for Devpost to join the conversation.