1. Introduction

This chapter is informative. It states what Makechain is, what the protocol covers, what it is built to achieve, and what it deliberately does not attempt at launch. The normative definition begins at chapter 3.

Makechain is a Byzantine-fault-tolerant provenance ledger. It maintains one finalized total order of facts about content-addressed content: who published which object to which project, where a project's references point, and who is authorized to write. The content itself lives outside the protocol, so what the chain holds is attribution and authorization, not bytes.

1.1 Scope

Makechain orders and permanently attests publication facts:

• who created a project,
• which content-addressed commitments were published to it and by whom,
• where its references point,
• who may write to it,
• and how those rights change over time.

The vocabulary of commit, reference, and push follows version control because code is the first workload, but a commitment names any content-addressed object under a registered scheme (chapter 8). Makechain does not store content. It gives clients cryptographic proof of those facts against a BFT-finalized chain (chapter 15), and it lets collaborators pay for their footprint with credits imported by proof from an external settlement chain (chapter 16).

Everything in this document that is a policy, including block format, finality rule, fee model, mempool policy, and execution rules, is a Makechain choice. The underlying library prescribes none of them.

1.2 Goals

1. One BFT-finalized total order of project and account actions.
2. Any content-addressing scheme, git included, without making git the protocol model.
3. Deterministic, bounded consensus work under Byzantine input.
4. No per-commit validity-state index growth, with bounded validator history retention and bounded per-command work, and with memory and bootstrap cost growing with funded resident state.
5. Permanent, authenticated commitment membership that is never erased.
6. Client-verifiable current state, historical inclusion, and finality, in a browser, with no trusted intermediary.
7. Consensus truth separated from object availability and from derived query views.
8. Clean evolution: immutable chain identity, finalized signed release governance, and a genesis-committed validator lifecycle, including governed membership under DynamicReshareV1.
9. Alignment with the pinned library's primitives, contracts, and stability rules, with no upstream fork.

1.3 Non-goals at launch

The following are outside the protocol at launch:

• automatic slashing or removal,
• a fee market, tips, or priority auctions,
• general execution,
• consensus storage or retrieval of objects,
• social features in consensus, including links, reactions, merge requests, profiles, feeds, and search,
• scheduled or sponsored commands,
• spending limits on delegated keys,
• social account recovery, noting that threshold control is in scope (chapter 7),
• project visibility flags, reader roles, and object-retrieval ACLs in consensus,
• protected refs,
• compatibility with any prior format or state.