We Turned a Real Knowledge Transfer Into Verifiable Evidence on Base Sepolia
Today we completed an experiment inside MyZubster that connects real human collaboration, GitHub history, cryptographic commitments, and blockchain verification.
The goal was not to “put knowledge on blockchain.”
The goal was more precise:
Can we take a real technical collaboration, freeze the resulting public work into a canonical record, hash it deterministically, anchor that commitment on-chain, and verify it independently later?
We used the ongoing Nicola / N4K48 MyZubster pilot as the real case.
The result is now public and reproducible.
The real source of evidence: GitHub
Nicola’s public MVP is here:
https://github.com/nicolaususnicola-lgtm/myzubster-mvp
Live pilot:
https://myzubster-mvp.onrender.com/
During the September 18 collaboration, the repository advanced across:
economic provenance;
persistent ledger storage;
revenue and asset APIs;
derived balances;
source-specific revenue breakdown;
UTC timestamps;
asset/revenue history;
MYZ ledger UI;
public documentation;
revenue simulation.
Instead of describing that work loosely, we identified an exact Git history window:
Base commit:
8da7435ddc1b9ae8b2f5c2eea5debd2df4bc5f47
Head commit:
b9ac4e8801d65b84ef882baf78fa09ce5b6b5059
That snapshot contains 30 commits.
This gives us a concrete technical object to reference.
We introduced a knowledge-transfer manifest
We created a new schema:
myzubster.knowledge-transfer.v1
with transfer ID:
KNOWLEDGE-N4K48-2026-09-18-001
The manifest records:
source identity;
recipient identity;
repository;
base commit;
head commit;
changed files;
knowledge scope;
blockchain target;
evidence boundaries.
The important design choice is that we separate:
source assertion
from
recipient attestation
At anchor time, Nicola’s recipient attestation was still:
PENDING
That is intentional.
A blockchain transaction should never be interpreted as automatic consent from another human.
Deterministic hashing
The manifest is canonicalized by:
recursively sorting object keys;
preserving array order;
serializing compact JSON;
UTF-8 encoding;
calculating SHA-256.
The resulting hash is:
39ab3a177734b5e3e254657cfe6015100644bcda2fb008cf2561d000669b9e14
The blockchain payload is:
MZ-KNOWLEDGE-V1:39ab3a177734b5e3e254657cfe6015100644bcda2fb008cf2561d000669b9e14
This is the core architecture:
large public evidence set
↓
canonical manifest
↓
SHA-256
↓
small on-chain commitment
We do not need to put source code, documentation, personal data, or full knowledge content directly on-chain.
Anchoring on Base Sepolia
For the pilot we used:
Network: Base Sepolia
Chain ID: 84532
Value: 0 ETH
The transaction was confirmed:
0xff3c108275625673ad22a886da2df7120ae81b8f0106ec833613513b03c7bc31
Block:
47000958
Confirmed at:
2026-09-18T22:23:24.000Z
Explorer:
https://sepolia.basescan.org/tx/0xff3c108275625673ad22a886da2df7120ae81b8f0106ec833613513b03c7bc31
A real integration bug: MetaMask rejected self-targeted calldata
Our first implementation tried to submit:
from: wallet
to: same wallet
value: 0
data: commitment
MetaMask rejected it with:
External transactions to internal accounts cannot include data
So we changed the design to use a fixed zero-value evidence sink:
0x000000000000000000000000000000000000dEaD
No ETH is transferred.
Only the commitment is carried in calldata.
Then smart accounts changed the transaction shape
After the transaction confirmed, the first version of our verifier reported:
MISMATCH
At first glance that looked wrong.
The receipt was successful.
The chain was correct.
The value was zero.
But the transaction destination and top-level calldata were not what our verifier expected.
The reason: MetaMask submitted the request through a delegated smart-account transaction.
The top-level transaction was type 4 and the anchor execution was wrapped inside:
redeemDelegations(...)
This forced us to improve the verifier.
Instead of only checking:
tx.to === evidenceSink
tx.data === expectedPayload
we added delegated execution decoding.
The verifier now inspects the nested execution and validates:
target
value
calldata
execution mode
Inside the delegated call we found:
Target:
0x000000000000000000000000000000000000dEaD
Value:
0
Payload:
MZ-KNOWLEDGE-V1:39ab3a177734b5e3e254657cfe6015100644bcda2fb008cf2561d000669b9e14
The result became:
MATCH
This was one of the most useful parts of the pilot.
A synthetic demo probably would not have exposed this distinction between a normal EOA transaction and a delegated smart-account execution.
Public verifier
We deployed a public verifier endpoint:
https://www.myzubster.com/api/knowledge-anchor/n4k48/0xff3c108275625673ad22a886da2df7120ae81b8f0106ec833613513b03c7bc31
It checks:
chainId ✅
receipt success ✅
top-level value = 0 ✅
delegated call recognized ✅
nested target match ✅
nested value = 0 ✅
exact calldata match ✅
execution mode match ✅
Current status:
{
"success": true,
"status": "MATCH"
}
Human-readable page:
https://www.myzubster.com/knowledge-anchor-n4k48
What exactly is proven?
This is where engineering language matters.
The blockchain anchor proves evidence about:
existence
integrity
timestamp
for the exact canonical manifest.
It does not prove:
authorship of every idea
learning
understanding
scientific validity
legal ownership
commercial value
truth of every human claim
This distinction is fundamental.
Blockchain is useful here as a tamper-evident timestamp and integrity layer, not as a replacement for human verification, peer review, contracts, or scientific validation.
The final human layer
The next step belongs to Nicola.
He now needs to add a separate attestation from his own GitHub account confirming that the record actually represents knowledge, guidance, and collaboration he received and used.
We intentionally do not modify the original anchored manifest, because that would change its hash.
Instead, Nicola can create something like:
knowledge/N4K48-ATTESTATION-KNOWLEDGE-2026-09-18.md
and commit a statement acknowledging:
KNOWLEDGE-N4K48-2026-09-18-001
and its anchored hash.
This creates a stronger chain:
source assertion
↓
public development evidence
↓
canonical hash
↓
blockchain anchor
↓
independent verifier
↓
recipient acknowledgement
Why we think this architecture matters
A lot of blockchain systems start from the wrong question:
“What can we put on-chain?”
A better question is:
“What evidence should stay off-chain, and what minimal commitment should be anchored on-chain?”
For MyZubster, this leads to a cleaner architecture:
GitHub → evidence history
SHA-256 → integrity
Base Sepolia → timestamp anchor
Human attestation → consent / acknowledgement
Research review → validation
MYZ ledger → internal accounting
Each layer does one job.
That separation avoids a lot of semantic confusion.
Knowledge is not the token
Another design principle we are keeping explicit:
knowledge ≠ blockchain asset
MYZ ≠ crypto token
GitHub commit ≠ legal ownership
blockchain timestamp ≠ scientific proof
MYZ remains an internal MyZubster accounting unit.
The knowledge anchor is a separate evidence mechanism.
The two may interact later through explicit business rules, but they should never be silently merged into one concept.
Public references
Nicola / N4K48 repository:
https://github.com/nicolaususnicola-lgtm/myzubster-mvp
Live pilot:
https://myzubster-mvp.onrender.com/
MyZubster verification page:
https://www.myzubster.com/knowledge-anchor-n4k48
Verifier endpoint:
https://www.myzubster.com/api/knowledge-anchor/n4k48/0xff3c108275625673ad22a886da2df7120ae81b8f0106ec833613513b03c7bc31
BaseScan:
https://sepolia.basescan.org/tx/0xff3c108275625673ad22a886da2df7120ae81b8f0106ec833613513b03c7bc31
MyZubster Core:
https://github.com/MyZubster-Ecosystem/myzubster
What we learned
The biggest lesson was not about hashes or blockchains.
It was about evidence boundaries.
Real systems need to distinguish:
recorded
from
verified
verified
from
validated
validated
from
owned
owned
from
understood
Once those boundaries are explicit, blockchain becomes much more useful.
Not as a magical source of truth.
But as one precise component in a larger evidence architecture.
