What has to be true on-chain before a tap means anything
MLabs wrote the Cardano smart contracts behind ProofTap and provides ongoing engineering support to the project. Published with ProofTap's approval.
ProofTap uses NFC tags and the Cardano blockchain to tie a physical item to what it calls "permanent, publicly verifiable digital records". It is built for global enterprises and universities as much as for individual collectors and resellers, and it ships on iOS and Android soon. MLabs wrote the on-chain half.
NFC has been in phones for years, and public blockchains have been recording things for longer. Joining the two has been the painful part. Doing it yourself means a chain account to fund, a record to mint for every item, and a reader that knows how to make sense of what it finds. ProofTap describes the result as "a simple tap of a phone or tablet", after which anyone can create, access and verify. That is the gap it closes, and closing it is harder than it sounds.
The reason is the word verifiable, and who is doing the verifying.
Verification is a claim about strangers
The person holding the phone did not create the record. They do not run the servers, they have no relationship with whoever made the item, and — this is the part that decides the architecture — they have no reason to take the platform's word for anything. A record is only verifiable if it still means something to someone who trusts none of the parties that produced it.
That constraint is unforgiving, and it rules out most of the easy designs. If checking an item requires an API to answer, the API's operator is the trust anchor and the blockchain is decoration: the stranger has simply moved from trusting the manufacturer to trusting a different company's uptime and good intentions. If the on-chain record is a hash whose meaning lives in a database, the same problem applies one step removed. What has to be true is narrower and harder — that the chain alone carries enough for the check to succeed, and that a reader can tell a genuine record from something anyone could have written.
Public verifiability is also permanent in a way that ordinary software is not. A record published today is read by a client written in five years, against rules that were fixed when the record was made. There is no migration window and no deprecation notice. Whatever the contracts said when they minted something is what a future reader will be checking against, so the decisions that matter most are the ones taken before anything ships.
What MLabs does with that
We write Cardano smart contracts — Aiken, Plutarch and Plinth — and the work that makes them worth trusting: the specification that says what the protocol is supposed to permit and forbid, and a test suite that demonstrates the difference. On ProofTap we wrote the on-chain code and stayed with the project afterwards, which is the arrangement we prefer. On-chain systems generate engineering on their own schedule — a dependency moves, the protocol changes underneath you — and the cheapest team to answer a question about on-chain behaviour is the one that made the decision in the first place.
If you are building something whose whole value depends on a stranger being able to check it, the on-chain design is not the last step of the product. It is the constraint the rest of the product has to fit.
ProofTap ships soon
ProofTap is available soon on iOS and Android, with early access before launch. It is on X as @ProofTap2026, and Daniel Stone, at ProofTap, is on LinkedIn.
We do this work for teams building on Cardano. The cheapest time to talk is before the design is settled.
Cardano and blockchain development at MLabs →
MLabs is the developer of the ProofTap on-chain smart contracts and a provider of ongoing engineering support. MLabs is not the auditor of those contracts. Quoted ProofTap material is from prooftap.io, September 2026.
