Open Source · Smart Contracts · Solidity · Foundry · Research
Smart contracts. Public research.
Learning in public.
bunje.io is a personal lab for blockchain software engineering. Everything is built openly, documented publicly, and published on GitHub.
// Personal research. Does not reflect the position of my employer. No finished product. Learning by building. The GitHub repositories document the current state: early, honest, open.
The stack is narrow on purpose. Depth over breadth. Solidity and Foundry until the fundamentals are solid. Python comes next.
Building secure Solidity contracts. Starting with access control, state machines, and workflow logic for regulated processes.
Testing, deployment, and debugging with Foundry. Every contract has tests before deployment. No exceptions.
Planned for 2027. web3.py for the off-chain verification layer. Reading and checking hashes against the on-chain anchor, not just writing them.
Every project is publicly documented on GitHub. Code, decisions, and progress visible from day one. No proprietary lock-in.
All projects are open source. Status reflects where each project currently stands — not where it is marketed to be.
Research protocol exploring cryptographic evidence for regulated approval and infrastructure workflows. State machines on-chain. Experimental.
First application built on Forsblock. Cryptographic workflow for claim and approval processes. Smart contract backbone, testnet deployed.
Research into Real World Asset tokenisation and cryptographic representation of regulated assets on-chain. Exploring where RWA meets infrastructure practice.
Smart contract protocol for claim and site workflow management. Cryptographic state machine for structured, verifiable approval sequences.
Protocol design experiments and architectural explorations. Where ideas are tested before they become contracts. Public from the first commit.
Planned web3.py tooling for the off-chain verification layer. Hashing documents, checking them against on-chain anchors. No code yet. The problem is clear, the timing is not.
This is where the learning actually stands. No retrospective polish — just the sequence as it happened.
The repositories are the product. Not polished demos — real code, real tests, real decisions. Including the dead ends.
Code is the documentation. Each repository includes Foundry tests, deployment scripts, and notes on design decisions. The commit history is honest — including the refactors and the mistakes.
Published in Eisenbahntechnische Rundschau (ETR), an established technical journal for infrastructure and transport.
Examination of cryptographic evidence mechanisms for regulated approval and infrastructure procedures.
Klaus Walter: Blockchain in der Planfeststellung: Möglichkeiten für Effizienz und Nachvollziehbarkeit. In: Eisenbahntechnische Rundschau (ETR) 5/2026, DVV Media Group.
Journal at publisher →Architecture decisions, security considerations, and design tradeoffs will be published here as the projects evolve. Articles on state machine design, cryptographic evidence patterns, and lessons from applying blockchain to regulated workflows.
An experimental protocol exploring cryptographic evidence mechanisms for regulated workflows. Not a product. Not a company. A research project built in public.
SHA-256 hashing, digital signatures, qualified timestamps, immutable audit trail. Everything else is built on this layer.
Public blockchain anchoring. Tamper-resistant, long-term verifiable, vendor-independent. Anchors the hashes from Layer 01.
Construction law translated into machine-verifiable state machines. Roles, workflow gates, variation order protocols — coded, not described.
First application built on Forsblock. Cryptographic state machine for claim and approval workflows. Testnet deployed. Experimental.
// Construction law translated into machine-verifiable process logic · Forsblock Protocol · Klaus Walter / bunje · 2025–2026 · Experimental
Forsblock is a research project. No paying customers. No SaaS. No token. The protocol is being designed openly because the problem is real and the research is worth doing in public. Anyone can read the code, challenge the design, or build on the concept.
Not a startup founder. Not a crypto native. An infrastructure engineer exploring how cryptographic software can improve evidence, transparency, and workflow integrity.
// Personal research. Does not reflect the position of my employer. No finished product. Learning by building. The GitHub repositories show the current state: early, honest, open.
Infrastructure practice meets cryptographic software engineering. If any of this resonates — write.
"Mein Gott, Walter…" — That is what colleagues said when I named a situation everyone knew but no one had articulated precisely. That is still the starting point of everything here.