Protocol Overview

Makechain is a realtime decentralized protocol for ordering and storing git-like messages — project creation, commits, ref updates, access control — with permissionless publishing and cryptographic attribution.

Design Goals

High throughput — 10,000+ messages per second with sub-second finality
Permissionless publishing — anyone can create projects and push code
Self-authenticating messages — every message verifiable without external lookups
Thin consensus — consensus orders metadata and ref pointers; file blobs live in a separate DA layer

Message Envelope

Every message on the network is wrapped in a self-authenticating envelope:

Message {
  data: MessageData       // The operation
  hash: bytes(32)         // BLAKE3(data)
  signature: bytes(64)    // Ed25519 signature over hash
  signer: bytes(32)       // Ed25519 public key
}

Verification: check that signer is a registered key for data.mid with sufficient scope for the message type.

Message Semantics

Every message type follows one of two paradigms:

1P (One-Phase)

The message creates or updates state unilaterally. No paired "undo" message exists.

Sub-type	Behavior	Examples
Singleton	Creates a new resource, irreversible	`FORK`
LWW Register	Last-write-wins per conflict key	`PROJECT_METADATA`, `ACCOUNT_DATA`
Append-only	Adds entries to a growing set	`COMMIT_BUNDLE`
State transition	Moves resource to terminal state	`PROJECT_ARCHIVE`

2P (Two-Phase)

Add and Remove pairs operating on a set. On a timestamp tie, remove wins.

Sub-type	Behavior	Examples
Set	Standard add/remove with remove-wins	Project, Collaborator, Key, Verification sets
CAS-ordered	Compare-and-swap for sequencing	`REF_UPDATE` / `REF_DELETE`

Content-Addressed IDs

Project IDs are content-addressed — the project_id is the BLAKE3 hash of the PROJECT_CREATE message itself (i.e., Message.hash). Forked project IDs are the hash of the FORK message. This means two projects with the same name get different IDs because the hash includes MID, timestamp, etc.