Libertaria Open Problems

Status: ACTIVE RESEARCH
Purpose: Community discussion forum for unresolved architectural challenges

---

We document unknowns so the community can navigate them together.

---

1. $STASIS BOND STORAGE ALGORITHMS (UNSPECIFIED)

An Archive Node goes dark. The bond slashes. A proof-of-retrievability check fires somewhere in the protocol stack, and nobody can agree on whether the algorithm was sufficient.

Problem: RFC-0620 ($STASIS Bond Schema) and RFC-0850 (Archive Negotiation Protocol) both reference storage algorithms and proof mechanisms. No canonical set of approved algorithms exists at the protocol level.

Current State

RFC-0620 mentions:

• Storage proof mechanisms (implied)
• Thermodynamic cost anchoring
• Bond slashing on data loss

RFC-0850 specifies:

enum StorageProofType {
    MerkleInclusion { root, path, leaf_index },
    ProofOfRetrievability { challenge, response },
    AnchorProof { chain, tx_id, block_height, merkle_proof },
    MultiArchiveAttestation { attesters, signatures },
}

But no specification exists for:

• Minimum acceptable proof-of-retrievability algorithms (PoR)
• Challenge/response protocols (frequency, complexity, validation)
• Merkle tree construction standards (hash function, balancing, depth limits)
• Acceptable anchor chain standards (Bitcoin only? Kaspa? Chapter chains?)

Open Questions

Question	Impact	Priority
What PoR algorithms are protocol-approved?	Archive Node interoperability	HIGH
What is the minimum challenge frequency?	Security vs. operational cost	HIGH
Can Archives use custom proof schemes?	Flexibility vs. standardization	MEDIUM
What happens if proof schemes are deprecated?	Long-term storage guarantees	HIGH
Should there be a “proof difficulty” standard?	Prevent weak Archives	HIGH

---

2. REPUTATION ORACLE CONSENSUS (UNDEFINED)

Two members attest to the same person. The attestations conflict. One says trustworthy. The other says fraud. The QVL is supposed to resolve this. It does not specify how.

Problem: RFC-0120 (Quasar Vector Lattice) describes reputation as “emergent from attestations.” It does not specify how conflicting attestations resolve, the threshold for “sufficient reputation,” Sybil resistance in bootstrapping, or the decay function for stale attestations.

Current State

The QVL is described as “ambient.” It is computationally undefined.

Open Questions

• Is reputation global, Chapter-specific, or context-dependent?
• How do we prevent “reputation inflation” (mutual back-scratching)?
• What is the “right to be forgotten” in a permanent ledger?
• How do negative attestations (slashings) propagate?

---

3. CHAPTER MERGE/FORK PROTOCOLS (INCOMPLETE)

A Chapter splits. Half the members walk. The assets sit in a shared wallet. The reputation ledger has one entry for the Chapter, and now there are two Chapters. Nobody knows which one inherits what.

Problem: RFC-0200 (Chapter Genesis) specifies creation and exit. It does not specify how Chapters merge, how they split amicably, how assets and reputation port across merges, or how disputes resolve when forks disagree on history.

Context

The “right to fork” is sacred. Forking without protocol leads to Balkanization.

Open Questions

• Should merged Chapters retain separate L2 governance?
• How do we prevent “fork spam” (malicious Chapter fragmentation)?
• What is the “genesis block” of a forked Chapter?
• Can a Chapter “un-merge” later?

---

Call for Contributions

These problems require community wisdom. The Core Team will not dictate solutions.

To propose a solution:

1. Write an RFC draft
2. Post to the technical forum
3. Tag with #open-problem-{number}
4. Await peer review

The best solutions will be canonized. The rest will be documented as “considered alternatives.”