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. Backend tooling and automation. Connecting smart contracts to real-world data and workflows.
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.
Solidity contract for secure donation pooling with controlled withdrawal. Built to understand vault patterns and access control fundamentals.
On-chain voting contract. Built to understand proposal logic, delegation, and the complexity of fair vote counting in decentralized systems.
Ongoing Foundry exercises, test patterns, and debugging experiments. A public notebook for everything learned about testing smart contracts.
Planned backend tooling for connecting smart contracts to real-world data pipelines. 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.