Blockchain-BOD - AI can forget. The project should not.

[BogdanXI]

AI coding agents can lose context between sessions.

Git preserves files and project history, but Git alone does not prove that a proposed project-state change was executed and verified under an explicit policy.

Blockchain-BOD is an experiment around this problem.

The current model separates:

- Task - authorizes work and reward
- Candidate - proposes a state transition
- Evidence - records the proof bundle
- Verification - evaluates the candidate under a named policy
- Settlement - applies the canonical result

The intended trust boundary is:

Git -> isolated execution -> deterministic verification -> cryptographic commitments -> blockchain settlement

The important point is that an AI agent is not automatically the authority over canonical project state.

This is not a claim of universal correctness. Passing a verification suite does not prove that software can never be wrong. The goal is narrower: make the acceptance rule explicit, reproducible and externally auditable.

Current work is experimental. Economic parameters are not final, and the Arbitrum work is an adapter experiment, not a new consensus mechanism.

Public repository:
https://github.com/BogdanXI/Blockchain-BOD

I am looking for people who want to break the design:

- Where can a candidate bypass the intended authority separation?
- Which evidence is insufficient?
- Where can verification be gamed?
- Which assumptions fail under adversarial workloads?
- What should be made deterministic before this can be trusted?

If the design is wrong, finding the failure is useful. The project will document failures and changes rather than hide them.

[BogdanXI]

We built a small adversarial test for AI-assisted state transitions. Try to break it.

Instead of publishing another project announcement, we wanted to put one concrete claim under test:

If a proposed state transition violates an explicit protocol invariant, the reference state machine should reject it.

The public experiment currently tests:

- invalid signature
- wrong evidence binding
- replayed candidate
- conflicting parent state
- verification under the wrong policy
- settlement without valid verification

There is also one valid candidate path, so the test is not simply checking that everything gets rejected.

The experiment is intentionally small and reproducible:

python3 scripts/break_state_machine.py

The public repository contains the experiment, its test, and the protocol implementation.

We are not claiming this proves consensus security or a new consensus mechanism. It is a falsifiable state-machine experiment.

If you can find an input that should be rejected but is accepted, please show the smallest reproducible case. That is more valuable to us than a positive review.

We are building this as an open experiment. If the work proves useful, we will also document transparent ways for people to support infrastructure and continued development.