Today we reached an important milestone with MyZubster.
We started with something deliberately ordinary and physical: a real hand-delivery of kefir culture between two people.
We then followed that event through MyZubster's digital handover workflow, created a deterministic cryptographic commitment from the recorded event, anchored that commitment to Base Sepolia, verified the resulting transaction, and connected the blockchain receipt back to the MyZubster record.
This was not a blockchain demo built around synthetic data.
It started with a real-world community exchange.
The objective was to explore a much more interesting question:
Can MyZubster connect real community activity to independently verifiable digital evidence without putting personal data on-chain or pretending that blockchain proves more than it actually does?
For this experiment, the answer is increasingly becoming: yes — with carefully defined evidence boundaries.
The MyZubster idea
MyZubster is being developed around a simple loop:
Share → Try → Observe → Improve → Share again
The broader goal is to turn real community practices and exchanges into structured, traceable knowledge.
The project is open source:
MyZubster main repository:
https://github.com/MyZubster-Ecosystem/myzubster
MyZubster Ecosystem:
https://github.com/MyZubster-Ecosystem
Kefir / fermentation knowledge project:
https://github.com/DanielIoni-creator/Myzubster-fermentation-kefir
MyZubster Marketplace project:
https://github.com/DanielIoni-creator/MyZubster-Marketplace
The experiment described below connects several of these ideas: marketplace exchange, evidence, provenance, cryptographic commitments, and public blockchain infrastructure.
- It started with a real kefir handover
A kefir culture was physically handed over to Nicola.
Inside MyZubster, we represented the exchange through a dedicated MarketplaceHandover workflow rather than treating a marketplace interaction as completed simply because somebody clicked a button.
The lifecycle distinguishes different events:
ACCEPTED
↓
HANDED_OVER
↓
RECEIVED
↓
RECORDED
This distinction matters.
A donor saying “I handed it over” is not the same piece of evidence as a recipient saying “I received it.”
And neither of those statements should automatically mean “this event is now on a blockchain.”
For the Nicola experiment, the completed application record reached:
METHOD=HAND_DELIVERY
STATE=RECORDED
with separate timestamps for handover, reception and final recording.
This gave us the application-level evidence from which to construct the cryptographic commitment.
- Creating a deterministic representation of the event
The next problem was reproducibility.
If we want to hash an event, we need a deterministic representation of exactly what is being committed.
For this first handover commitment schema, the payload contained:
{
"schema": "myzubster.marketplace-handover.v1",
"handoverId": "6aab8faca70ce84f926d0b41",
"listingId": "6aa9ee1b821964be0b43ff6e",
"method": "HAND_DELIVERY",
"state": "RECORDED",
"handedOverAt": "2026-09-17T07:28:24.874Z",
"receivedAt": "2026-09-17T07:45:03.261Z",
"recordedAt": "2026-09-17T07:46:09.606Z"
}
The important architectural decision is that this JSON was not written directly to the blockchain.
Instead, MyZubster generated a SHA-256 commitment.
The resulting hash was:
ba9973f08ce86d16a3611c3cccbb9cc2cc779b9ea1cb6fd87a2e5864e557b6b9
This gives us a compact cryptographic fingerprint of the committed record.
- Keeping personal data off-chain
One of the design requirements was that we should not solve provenance by dumping application records or personal information onto a public blockchain.
The blockchain payload therefore contains a prefixed commitment:
MZ-HANDOVER-V1:ba9973f08ce86d16a3611c3cccbb9cc2cc779b9ea1cb6fd87a2e5864e557b6b9
The public chain receives the commitment.
The underlying MyZubster application retains the structured handover information.
This creates an important separation:
Real-world event
↓
MyZubster application record
↓
Canonical representation
↓
SHA-256 commitment
↓
Public blockchain anchor
That separation is intentional.
- The commitment was actually anchored to Base Sepolia
We did not mark the handover as on-chain merely because a hash had been calculated.
A real EVM transaction was submitted to Base Sepolia.
The confirmed transaction is:
Network: Base Sepolia
Chain ID: 84532
Value: 0 ETH
Block: 46933575
Gas used: 24160
Status: CONFIRMED
Confirmed at: 2026-09-17T08:57:18.000Z
Transaction hash:
0x998a98b1733312e248f74a1387319dae30aab8123a6115c517e4ffe0ef9584bf
You can independently inspect the transaction here:
BaseScan — MyZubster kefir handover transaction:
https://sepolia.basescan.org/tx/0x998a98b1733312e248f74a1387319dae30aab8123a6115c517e4ffe0ef9584bf
This is the public evidence layer of the experiment.
- We verified the blockchain before modifying the MyZubster record
Another important part of the experiment was the direction of trust.
We did not simply store a transaction hash in MongoDB and assume it represented the expected transaction.
Before connecting the receipt to the handover, we verified the blockchain transaction and checked the expected chain, transaction, block and commitment.
The verification produced:
CHAIN_ID=84532
TX_ID=0x998a98b1733312e248f74a1387319dae30aab8123a6115c517e4ffe0ef9584bf
BLOCK=46933575
HASH=ba9973f08ce86d16a3611c3cccbb9cc2cc779b9ea1cb6fd87a2e5864e557b6b9
CONFIRMED_AT=2026-09-17T08:57:18.000Z
Only after that verification did we persist the blockchain metadata into the MyZubster handover record. The database update matched and modified exactly one handover.
- RECORDED and ONCHAIN_RECORDED mean different things
This distinction is central to the architecture.
The application state remains:
STATE=RECORDED
Blockchain status is derived separately:
ONCHAIN_RECORDED=true
For Nicola's handover, the persisted evidence now includes:
HANDOVER_ID=6aab8faca70ce84f926d0b41
STATE=RECORDED
NETWORK=base-sepolia
TX_ID=
0x998a98b1733312e248f74a1387319dae30aab8123a6115c517e4ffe0ef9584bf
HASH=
ba9973f08ce86d16a3611c3cccbb9cc2cc779b9ea1cb6fd87a2e5864e557b6b9
CONFIRMED_AT=
2026-09-17T08:57:18.000Z
ONCHAIN_RECORDED=true
This prevents a dangerous shortcut where an application could label something "on-chain" simply because blockchain functionality exists somewhere in the codebase.
For MyZubster, onchainRecorded=true requires actual blockchain receipt information.
- We then moved the experiment into the MyZubster codebase
Doing a single blockchain transaction manually is useful for experimentation.
It is not enough for a platform.
So we implemented persistent blockchain commitment metadata directly in MarketplaceHandover.
The model can store information such as:
schema
algorithm
hash
preparedAt
network
txId
anchoredAt
confirmedAt
We also implemented an authenticated endpoint for preparing a commitment for a recorded handover:
POST /:handoverId/prepare-blockchain-commitment
The route checks that the caller is a participant in the handover and that the handover has reached the appropriate recorded state before preparing its commitment.
This moves the experiment from:
“We managed to anchor one handover.”
toward:
“MyZubster has a reusable data model for representing blockchain commitments associated with handovers.”
- We tested the integration
We did not stop after the code compiled.
The relevant marketplace test suites were executed after installing the dependencies declared by the repository.
The final result was:
PASS tests/marketplaceFlow.test.js
PASS tests/marketplaceEvidence.test.js
Test Suites: 2 passed, 2 total
Tests: 4 passed, 4 total
Snapshots: 0 total
TEST_EXIT=0
There were email-notification credential warnings in the test environment, but they did not fail the test suites.
- The integration is public
The work has now been pushed to the public MyZubster repository.
We opened:
PR #1230 — Integrate on-chain handover commitment support
https://github.com/MyZubster-Ecosystem/myzubster/pull/1230
The PR contains the model and route integration: two commits and two changed files.
The main repository is here:
https://github.com/MyZubster-Ecosystem/myzubster
This means the experiment is not represented only by a post or a blockchain transaction. The implementation itself can be inspected.
- What the blockchain proves
It is important to be precise here.
The blockchain transaction does not prove that the kefir was microbiologically safe.
It does not certify its composition.
It does not scientifically validate fermentation practices.
It does not independently prove that the physical handover happened exactly as described.
And it does not magically transform community observations into verified scientific knowledge.
What it provides is narrower — and useful:
a public, timestamped cryptographic commitment that can later be compared against the corresponding digital record.
If the committed data changes, recomputing the commitment will no longer produce the same hash.
So blockchain becomes an integrity and timestamp layer, rather than a replacement for the application database, scientific validation or real-world evidence.
- Why this matters for MyZubster
The interesting part is not simply that MyZubster can write something to a blockchain.
Many applications can do that.
The interesting problem is connecting several different evidence layers without confusing them:
PHYSICAL WORLD
Real kefir handover
↓
HUMAN EVIDENCE
Donor and recipient actions
↓
APPLICATION STATE
MarketplaceHandover → RECORDED
↓
STRUCTURED EVIDENCE
myzubster.marketplace-handover.v1
↓
CRYPTOGRAPHIC EVIDENCE
SHA-256 commitment
↓
PUBLIC EVIDENCE
Base Sepolia transaction
↓
VERIFICATION
Hash + transaction + block + confirmation
Each layer answers a different question.
That is much more useful than treating "blockchain" as a generic badge of truth.
- Where this could go next
The next architectural step is to make this verification increasingly reproducible.
A future verifier should be able to take an eligible MyZubster record, reproduce its canonical representation, calculate its SHA-256 commitment, obtain the blockchain receipt, inspect the transaction calldata and determine whether the commitment matches.
Conceptually:
MyZubster record
↓
canonicalize
↓
SHA-256
↓
expected commitment
↓
compare
↓
Base transaction calldata
↓
MATCH / NO MATCH
This can eventually become part of a broader provenance system for MyZubster.
The important rule remains:
We should never claim more than the evidence actually proves.
Project links
MyZubster — main open-source repository
https://github.com/MyZubster-Ecosystem/myzubster
MyZubster Ecosystem on GitHub
https://github.com/MyZubster-Ecosystem
PR #1230 — On-chain handover commitment integration
https://github.com/MyZubster-Ecosystem/myzubster/pull/1230
Kefir and fermentation knowledge repository
https://github.com/DanielIoni-creator/Myzubster-fermentation-kefir
MyZubster Marketplace repository
https://github.com/DanielIoni-creator/MyZubster-Marketplace
Public Base Sepolia transaction
https://sepolia.basescan.org/tx/0x998a98b1733312e248f74a1387319dae30aab8123a6115c517e4ffe0ef9584bf
MyZubster website
https://www.myzubster.com
Building provenance from real activity
This experiment began with something extremely simple: sharing kefir with another person.
But that simplicity is useful.
If a provenance architecture cannot clearly represent a small real-world exchange, adding more technology will not fix it.
Our approach with MyZubster is therefore to build from real interactions upward:
real activity → explicit human actions → structured records → cryptographic commitments → public verification.
Not everything belongs on-chain.
Not everything recorded by an application is automatically true.
And not every community observation is scientific evidence.
The goal is instead to make the relationships between these things explicit, inspectable and increasingly verifiable.
That is the direction we are exploring with MyZubster.
Share → Try → Observe → Improve → Share again.
