This document addresses technical and architectural questions commonly raised by developers evaluating HODLXXI.
It assumes familiarity with cryptography, distributed systems, and adversarial threat models.
HODLXXI explores whether long-term commitments and reciprocity can be made observable and durable without centralized authority.
It is not a general-purpose identity system. It is not a governance framework. It is not a consensus protocol.
It is a coordination layer focused on time, accountability, and voluntary participation.
It is a set of architectural constraints and primitives.
Specific deployments are implementations. No single implementation is canonical.
Forking is expected. Divergence is acceptable.
Bitcoin provides:
These properties are difficult to replicate artificially.
HODLXXI does not require Bitcoin scripting extensions, sidechains, or tokens.
No.
On-chain interactions are optional and minimal. Most logic exists off-chain.
Bitcoin is used primarily as: - a time anchor, - a settlement layer for commitments, - and a credibility boundary.
Identity is defined as control over a cryptographic key.
There are no accounts, usernames, or recovery flows enforced by the system.
Key rotation, aggregation, or abstraction may be implemented at higher layers, but are not assumed at the core.
Most DID systems optimize for: - portability, - interoperability, - and institutional adoption.
HODLXXI optimizes for: - exit, - adversarial durability, - and long-term commitments.
Interoperability is secondary to constraint integrity.
Minimal.
There is no assumption of honesty, alignment, or goodwill.
The system assumes:
It does not attempt to prevent all attacks. It attempts to make sustained abuse costly.
Reputation is not a scalar.
It is an observable history of commitments and outcomes. Interpretation is delegated to agents and applications.
No global aggregation function is required or provided.
Sybil resistance is contextual.
HODLXXI does not attempt universal Sybil prevention. Instead, it allows commitments to define their own cost structures.
Sybil identities become expensive only where they matter.
No.
There is no global state that requires agreement. There is no leader election. There is no final arbiter.
Local agreement and forkability are preferred.
They diverge.
Disagreement does not imply failure. Forced agreement is considered a failure mode.
Forking and exit are first-class outcomes.
Slowly and visibly.
Backward compatibility is preferred. Breaking changes must be opt-in.
No automatic migration is assumed.
That depends on the scope.
HODLXXI is not a turnkey solution. It is a research-driven framework.
Deployments should be: - limited in scope, - explicit in assumptions, - and conservative in enforcement.
Examples include:
Any of these invalidate the system’s core claims.
Yes, in principle.
CRT is compatible with artificial agents provided they operate under persistent identity and repeated interaction.
However, safety and alignment considerations are out of scope for the core system.
With skepticism.
Read the invariants. Read what the project explicitly is not. Inspect the assumptions.
If your use case requires: - speed, - certainty, - or centralized guarantees —
this framework is likely inappropriate.
HODLXXI is not optimized for adoption.
It is optimized for constraint integrity.
Developers are encouraged to treat it as: - a design space, - a set of architectural warnings, - and an invitation to critique.
Participation is optional. Forking is expected.