We Anchored a Real Knowledge Transfer on Base Sepolia — Here’s How MyZubster Did It
Today we moved one of the MyZubster pilot experiments from an idea about “verifiable knowledge” to something concrete, inspectable, and reproducible.
The goal was simple:
Can we document a real technical collaboration between two people, connect it to the actual work produced on GitHub, and create a public blockchain timestamp/integrity proof without pretending that the blockchain proves learning, authorship, or scientific truth?
We used the ongoing Nicola / N4K48 MyZubster pilot as the real-world case.
The result is now live, public, and independently verifiable.
The starting point: real work, not a synthetic demo
Nicola has been building his own public MyZubster MVP:
Repository
https://github.com/nicolaususnicola-lgtm/myzubster-mvp
Live pilot
https://myzubster-mvp.onrender.com/
Comics API
https://myzubster-mvp.onrender.com/api/comics
During our collaboration on September 18, Nicola's repository advanced significantly.
The work included:
economic provenance primitives;
persistent ledger storage;
revenue and asset APIs;
derived participant balances;
source-specific revenue accounting;
asset and revenue history;
UTC audit timestamps;
MYZ ledger views;
Balance / My Assets / Revenue interfaces;
revenue simulation;
project documentation.
Instead of simply saying “we transferred knowledge”, we wanted to connect that statement to something externally inspectable.
GitHub gave us that evidence layer.
Step 1: freezing the GitHub evidence
We identified the public development window for the collaboration.
The snapshot covers:
Base commit:
8da7435ddc1b9ae8b2f5c2eea5debd2df4bc5f47
Head commit:
b9ac4e8801d65b84ef882baf78fa09ce5b6b5059
That interval contains 30 commits.
The changed material includes files such as:
README.md
ROADMAP.md
docker-compose.yml
index.html
persistence_helper.py
src/api/server.py
src/core/economics.py
tests/test_ai_api.py
tests/test_economics.py
That is important.
We are not anchoring a vague statement like:
“Daniel taught Nicola something.”
We are anchoring a manifest that points to a specific, reproducible public development snapshot.
Step 2: creating a canonical knowledge-transfer manifest
We introduced a new evidence schema:
myzubster.knowledge-transfer.v1
The transfer ID is:
KNOWLEDGE-N4K48-2026-09-18-001
The manifest contains things like:
source public identity;
recipient public identity;
repository;
base commit;
head commit;
commit count;
changed files;
knowledge scope;
evidence boundaries;
intended blockchain network.
The source side is recorded as:
Daniel / H4X0R
The recipient is:
Nicola / N4K48
The recipient's explicit attestation is deliberately kept separate.
At the moment of anchoring it was:
PENDING
That separation matters.
A blockchain transaction should not silently turn one person's assertion into another person's consent.
Step 3: canonicalization and SHA-256
Before anchoring anything, the manifest is canonicalized.
For our v1 format we:
recursively sort object keys;
preserve array order;
serialize as compact JSON;
encode as UTF-8;
calculate SHA-256.
The resulting commitment is:
39ab3a177734b5e3e254657cfe6015100644bcda2fb008cf2561d000669b9e14
The blockchain payload is:
MZ-KNOWLEDGE-V1:39ab3a177734b5e3e254657cfe6015100644bcda2fb008cf2561d000669b9e14
Only this commitment needs to go on-chain.
The full knowledge, source code, documentation, or private communication does not need to be placed on a blockchain.
That is a much cleaner model.
Step 4: anchoring it on Base Sepolia
We chose Base Sepolia for this pilot.
Network: Base Sepolia
Chain ID: 84532
Transaction value: 0 ETH
The transaction was successfully confirmed:
Transaction:
0xff3c108275625673ad22a886da2df7120ae81b8f0106ec833613513b03c7bc31
Block:
47000958
Confirmed at:
2026-09-18T22:23:24.000Z
BaseScan:
https://sepolia.basescan.org/tx/0xff3c108275625673ad22a886da2df7120ae81b8f0106ec833613513b03c7bc31
We hit an interesting MetaMask problem
The first implementation attempted to send a zero-value transaction back to the same wallet with calldata.
MetaMask rejected it with:
External transactions to internal accounts cannot include data
So we changed the design.
Instead of sending the zero-value transaction to the originating account, the page targeted a fixed evidence sink:
0x000000000000000000000000000000000000dEaD
with:
value = 0 ETH
and the knowledge commitment in calldata.
No funds are transferred.
Only testnet gas is consumed.
Then MetaMask made it more interesting
After confirmation, our first independent verifier reported a mismatch.
The transaction existed.
The chain was correct.
The receipt succeeded.
The value was zero.
But the top-level destination and calldata did not look like what we had submitted.
Why?
Because MetaMask had executed the transaction using a delegated smart-account flow.
The transaction was type 4, and the payload was wrapped inside a delegated call rather than appearing directly as the top-level transaction calldata.
So we improved the verifier.
Instead of simply checking:
tx.to === evidenceSink
tx.data === expectedPayload
it now recognizes and decodes:
redeemDelegations(...)
and inspects the nested execution.
Inside that delegated transaction we verified:
target = 0x000000000000000000000000000000000000dEaD
value = 0
calldata =
MZ-KNOWLEDGE-V1:
39ab3a177734b5e3e254657cfe6015100644bcda2fb008cf2561d000669b9e14
The result became:
MATCH
This is exactly the kind of thing that makes real pilots useful.
A simple happy-path demo would never have exposed this integration detail.
Step 5: independent verification
We added a public MyZubster verifier.
You can inspect the result here:
The current result is:
success: true
status: MATCH
The verifier checks:
Base Sepolia chain ID ✅
Successful transaction receipt ✅
Zero top-level ETH value ✅
Delegated execution recognized ✅
Evidence sink target ✅
Nested value = 0 ✅
Exact knowledge commitment ✅
Execution mode ✅
We also published a human-readable verification page:
https://www.myzubster.com/knowledge-anchor-n4k48
What the blockchain actually proves
This distinction is critical.
The confirmed transaction provides evidence that this exact commitment existed no later than the blockchain confirmation time.
Later, anyone can take the canonical manifest, recompute the SHA-256 hash, and compare it with the value committed on-chain.
So the anchor gives us evidence about:
integrity
+
existence
+
timestamp
It does not automatically prove:
who invented every idea
who legally owns the knowledge
that Nicola learned or mastered it
that every statement is scientifically correct
that the software has commercial value
that a human interaction happened exactly as described
Blockchain is an evidence layer.
It is not an oracle of truth.
The final missing piece: Nicola's attestation
There is still one important step.
Nicola should now make an explicit statement from his own GitHub account confirming that the record corresponds to knowledge, guidance, and collaboration he actually received and used.
We deliberately did not modify the original anchored manifest after confirmation.
Changing that file would produce a new hash.
Instead, Nicola can create a separate record such as:
knowledge/N4K48-ATTESTATION-KNOWLEDGE-2026-09-18.md
and commit something like:
I, Nicola / N4K48, confirm that the record
KNOWLEDGE-N4K48-2026-09-18-001 corresponds to
technical knowledge, guidance and collaboration I
received and used during the MyZubster/N4K48 work
of 18 September 2026.
I acknowledge the anchored commitment:
39ab3a177734b5e3e254657cfe6015100644bcda2fb008cf2561d000669b9e14
I confirm this statement through this GitHub commit.
That gives us two independent human sides:
source assertion
+
recipient acknowledgement
rather than pretending the blockchain replaces either one.
The full evidence chain
We now have this:
Daniel / H4X0R
↓
technical knowledge + collaboration
↓
Nicola / N4K48 development
↓
public GitHub history
↓
canonical knowledge manifest
↓
SHA-256
↓
Base Sepolia
↓
confirmed transaction
↓
delegated MetaMask execution decoded
↓
independent verifier
↓
MATCH
↓
Nicola recipient attestation
The last step is currently pending Nicola's confirmation.
Why this matters for MyZubster
MyZubster is experimenting with a broader idea:
Knowledge should be shareable, reproducible, attributable, and verifiable without forcing all knowledge itself onto a blockchain.
Git can preserve the actual evolution of technical work.
Cryptographic hashes can commit to a precise state.
Blockchain can provide a public timestamp/integrity anchor.
Human attestations can preserve consent and attribution.
Research and peer review can remain separate layers.
That means we can keep different concepts separate:
knowledge ≠ blockchain transaction
blockchain evidence ≠ scientific validation
GitHub commit ≠ proof of authorship of every idea
recipient acknowledgement ≠ proof of mastery
MYZ accounting ≠ blockchain token
Those boundaries are not limitations.
They are what make the evidence meaningful.
Public links
Nicola / N4K48 MVP
https://myzubster-mvp.onrender.com/
Nicola repository
https://github.com/nicolaususnicola-lgtm/myzubster-mvp
Knowledge anchor
https://www.myzubster.com/knowledge-anchor-n4k48
Independent verifier
BaseScan
https://sepolia.basescan.org/tx/0xff3c108275625673ad22a886da2df7120ae81b8f0106ec833613513b03c7bc31
MyZubster Core
https://github.com/MyZubster-Ecosystem/myzubster
What comes next
The immediate next step is Nicola's explicit GitHub attestation.
After that, we can experiment with:
recipient-signed acknowledgements;
multiple knowledge contributors;
reproduction evidence;
versioned knowledge updates;
independent reviewers;
research validation;
linking verified knowledge contributions to MyZubster's internal MYZ accounting system without confusing MYZ with cryptocurrency.
This pilot started from something very ordinary:
two people working together on software.
What we added was a way to make the resulting knowledge trail inspectable:
human collaboration → Git history → cryptographic commitment → blockchain timestamp → independent verification.
That is a much more interesting use of blockchain than simply putting another token on-chain.
