Storage Limits

Makechain enforces per-account storage limits to prevent unbounded state growth. Each account has storage units (default: 1 for free tier), and limits scale with units.

Per Storage Unit (Yearly)

Enforcement

Limits are enforced at state transition time:

• Projects: PROJECT_CREATE and FORK check project_count < storage_units * 10 before incrementing. PROJECT_REMOVE decrements the count, freeing capacity for new projects.
• Refs: REF_UPDATE checks ref_count < 200 when creating a new ref. Updating an existing ref doesn't change the count. REF_DELETE decrements.
• Collaborators: COLLABORATOR_ADD checks collaborator_count < 50 when adding a new collaborator. Permission updates don't change the count.
• Commits: COMMIT_BUNDLE always appends commits, then triggers auto-pruning if the count exceeds 10,000.
• Keys: KEY_ADD checks key_count < 50 when adding a new key. KEY_REMOVE decrements.
• Verifications: VERIFICATION_ADD checks verification_count < 50 when adding a new verification. VERIFICATION_REMOVE decrements.

Commit Pruning

When a project exceeds its commit metadata limit, the oldest unprotected commits are pruned from consensus state:

A commit referenced by any active ref is never pruned. The ref's head commit and its entire parent chain (reachable via parent links) are protected.

Pruning Algorithm

1. Build the protected set: BFS from all active ref heads through parent links
2. Enumerate all commits; collect those not in the protected set
3. Sort unprotected commits by indexed_at ascending (oldest first)
4. Delete oldest unprotected commits until at or below the limit

What This Means in Practice

• Head commits for every branch/tag are always retained
• Intermediate commits on active branches are retained
• Commits on deleted branches with no remaining ref are pruned first
• Full commit history remains recoverable from the DA layer — pruning only removes CommitMeta from validator state

Error Types