Original – Sovereign Ledger

Abstract

You bring a home server online. It holds its own hash-chained ledger; there is no global blockchain and no trusted third party. You have no account to sign up for and no central registry: your identity is a coordinate in a mathematical space, and the network finds you and others trackerless via a distributed hash table (Kademlia). Earning that identity costs work: the Energy Anchor makes Node ID generation costly, so that Sybil and Eclipse attacks are impractical and you sit among peers who paid the same. To transact, you have the counterparty’s identity (e.g. aethelgard:id:<hash>). Your node routes to them through the DHT; you establish a secure channel and agree on the transaction. You both sign the same payload; you each append a block to your own chain, each block referencing the other’s. Settlement is complete when both have appended. No clearinghouse, miner, or validator confirms anything; the two ledgers are the proof. For everyday exchange, that is enough. When it matters, Omnisia offers an optional shared chain where you and they may write records immemorially, permanently and unalterably. Property rights and ownership are tied to Omnisia; when both parties put a transfer on Omnisia, it is official; no state registry, notary, or bank is required. The design combines sovereign per-node ledgers, bilateral consensus, trackerless discovery, and opt-in immemorial record into a single coherent system.

1. Introduction

Commerce and property transfer have long depended on central registries, mints, and financial institutions to prevent double-spending and to attest ownership. These systems suffer from the usual weaknesses of the trust-based model: single points of failure, mediation costs, and the impossibility of a truly immemorial record—deeds burn, registries are lost or forged, and disputes about who owned what cannot be settled by appeal to a single canonical ledger.

What is needed is a system in which (1) settlement is peer-to-peer between two willing parties, with no intermediary; (2) each party maintains its own ledger, so there is no single “the” blockchain that everyone must trust; (3) discovery of counterparties does not rely on a central index; and (4) optional immemorial record exists for those transactions that must be official and permanent—property, title, inheritance—without requiring every transaction to pass through a global chain.

In this paper we propose such a system. We define the sovereign ledger: each node (home server) is its own blockchain. Transactions are bilateral; both parties sign and append. We adopt Kademlia and a DHT for trackerless discovery, so that identity is a coordinate and the network finds nodes in O(log N) hops. We introduce the Energy Anchor so that occupying a position in the network requires costly work, making Sybil and Eclipse attacks impractical. We define Omnisia as an optional greater chain where participants may write records immemorially; what is on Omnisia is official for property and ownership. The result is a cryptochain proof that requires no central authority and no global consensus, while still allowing a shared, permanent record when participants choose it.

2. Transactions

We define a transaction as an agreed payload (sender, receiver, amount, nonce, metadata as needed) that both parties sign. Each home server holds its own ledger: an append-only, hash-chained sequence of blocks. A block contains one or more transactions (or attestations) and the hash of the previous block.

When party A and party B transact:

They exchange the proposed transaction and verify it (balances, nonces, rules).
Both sign the same canonical payload.
Each appends a block to its own chain. That block includes the transaction and a reference to the other party’s block (e.g. hash of the other’s block or a commitment). Thus A’s chain records “I agreed with B on block H_B”; B’s chain records “I agreed with A on block H_A.”
Settlement is complete when both have appended. No third party has confirmed anything; the two ledgers are the proof.

The payee can verify that the payer has appended by checking the payer’s chain (or the relevant block). Double-spending is prevented because each server’s ledger is ordered and append-only; once a transaction is in a block, it is part of that node’s history. The bilateral nature means we do not need a global order—only that A and B both have a consistent record of their agreement. Disputes (one party claims no agreement, or different content) are reduced by the requirement that both sign the same payload before appending; dispute-resolution protocols can be layered on top.

3. Per-Node Ledger and Hash Chain

Each home server maintains a single ledger: a sequence of blocks. Block structure:

Previous block hash (or genesis).
Timestamp.
Payload: the transaction(s) or attestation(s), plus reference to the counterparty’s block (e.g. counterparty identity and block hash).
Block hash: H(previous_hash || timestamp || payload).

The server is the sole writer of its own chain. There is no mining race; no global longest chain. The chain serves as a timestamp and integrity record: changing a past block would require recomputing that block’s hash and all subsequent blocks, and would break the cross-references that other nodes may hold. So each node’s chain is its own proof of the sequence of events it has participated in.

We call this stacking: when A and B transact, each “stacks” the other’s attested block onto its own chain by including a reference to it. The graph of chains is a mesh; any node can transact with any other; chains reference chains. There is no single global blockchain—only N sovereign chains that optionally reference one another and, optionally, contribute to Omnisia.

4. Bilateral Consensus (Replacing Global Proof-of-Work)

In a classic blockchain, consensus is achieved by proof-of-work (or similar): the longest chain wins, and the network agrees on a single history. In our system, consensus is bilateral. For a transaction between A and B:

Both must sign the same payload.
Both must append a block that reflects the agreement and references the other’s block.

There is no “majority vote” across the network for that transaction. The proof is: (1) the two signatures on the same payload, and (2) the presence of matching blocks on both chains. An auditor can verify by fetching A’s block and B’s block and checking that they refer to each other and contain the same transaction.

For the optional Omnisia chain, consensus rules (who may append, in what order, and how conflicts are resolved) can be defined separately—e.g. append-only, with optional aggregation or ordering rules. The key point is that settlement does not depend on Omnisia; settlement is complete at the bilateral layer. Omnisia is for record, not for clearing.

5. Discovery: Trackerless DHT and Identity

To transact, one must find the counterparty. A central registry would reintroduce a single point of control. We therefore use a distributed hash table (DHT) in the style of Kademlia, as used in BitTorrent for trackerless discovery.

Node ID: Every home server has a Node ID (e.g. 160 or 256 bits). In the basic design, this can be derived from the server’s public key; with Energy Anchor (Section 6), it is the output of a hardened hash that meets a difficulty target.
Distance: Kademlia defines distance between two nodes as the XOR of their IDs: d(A,B) = A ⊕ B. Closeness is in ID space, not geography.
Routing: To find the node owning identity (hash) H, a participant asks its known neighbors: “Which nodes do you know that are closer to H than you?” The request is forwarded iteratively. In O(log N) hops, the request converges on the node whose ID is closest to H (or the node that owns that identity). No central index exists; the map is the network.
Magnet-style identity: A participant’s identity can be expressed as a URI, e.g. aethelgard:id:<hash>. To “ping” that identity, the sender’s server initiates a FIND_NODE (or equivalent) for that hash; the DHT routes it to the corresponding home server.
Peer exchange (PEX): Once in contact with one peer, a node can learn other peers (“here are nodes I talk to”). The mesh Plinkos requests until they land on the target. The network is self-healing: if a node leaves, the mesh routes around it.

This gives a living DNS without a central registrar: identity is a coordinate; discovery is mathematical and decentralized.

6. Sybil Resistance: Energy Anchor

If Node IDs were free (e.g. derived only from a public key), an attacker could generate many identities and surround a target in ID space. When anyone looks for the target, they would find only the attacker’s nodes—an Eclipse attack. The target would be cut off from the network.

To prevent this, we require that a valid Node ID be costly to produce. Concretely: the Node ID must be the output of a hardened hash (e.g. proof-of-work) such that finding an ID that meets a difficulty target (e.g. a number of leading zero bits) requires non-trivial CPU work—on the order of minutes per ID. We call this the Energy Anchor.

One node: A legitimate user expends work once to obtain one valid Node ID. Acceptable.
Many nodes: An attacker wishing to Eclipse a target would need to occupy many points in ID space near the target, i.e. generate many valid IDs. The cost scales linearly with the number of fake nodes; creating thousands of nodes becomes physically and economically prohibitive.

Thus identity in the network is not free; it is a coordinate earned through physical work. The Energy Anchor replaces the need for a central authority to vet identities; the cost of creating identities is the Sybil and Eclipse resistance.

7. Network

The steps to run the network are as follows.

Bootstrap: A new node obtains a small set of initial peers (invite, out-of-band, or public bootstrap list). It may then use the DHT to discover more peers and to resolve identities to addresses.
Identity: The node generates (or has previously generated) a valid Node ID. If Energy Anchor is used, the node proves it has done the work (e.g. by publishing the preimage or a proof that the ID meets the difficulty).
Transaction: To transact with identity H, the node uses the DHT to route to the owner of H. It establishes a secure channel (e.g. authenticated, encrypted) and proposes a transaction. Both parties sign the same payload; both append to their own chains and exchange block references.
Recursive verification: When the DHT returns a candidate node for identity H, the requester verifies that node’s Energy Anchor (and, where applicable, signatures or chain consistency) before trusting it. No hop is trusted without verification.
Optional Omnisia: If both parties have chosen to participate in Omnisia and deem the transaction worth recording immemorially, one or both append an attestation to Omnisia according to Omnisia’s protocol.

Nodes can leave and rejoin at will. The DHT and PEX allow the mesh to route around failures. There is no global “sync” in the sense of a single chain; each node maintains its own chain and the references it has chosen to keep.

8. Omnisia: Optional Immemorial Record

Not every transaction need be written to a shared, permanent ledger. For bilateral settlement, the two parties’ chains suffice. For property, ownership, and official record, participants may write to Omnisia.

Opt-in: No node is required to append to Omnisia. Participation is voluntary.
Immemorial: Once a record is appended to Omnisia, it is stored permanently and unalterably. The chain is append-only; no single participant can reorg it.
Self-selection: Participants write only what they consider important. Omnisia is the “actual important ledger”; if it fills with low-value entries, that is a later design problem (e.g. pruning, tiers, or acceptance). The base design does not depend on solving bloat up front.
Up to the node: Each home server decides whether to write a given transaction (or attestation) to Omnisia. Sovereignty remains at the node.

Omnisia is tied directly to the currency and to property rights. The same currency that settles on local ledgers can be recorded on Omnisia when the parties want an official, lasting record. Flow: (1) P2P transaction; both append to their own chains; (2) optionally, one or both append to Omnisia. What is on Omnisia is official—for property, title, and ownership—without any state registry, notary, or bank. Two principals, two servers, P2P, both append to Omnisia; done. Legitimate.

9. Property and Ownership

All of property rights and the concept of ownership are tied directly into Omnisia, which is tied directly to the currency. Multi-fractal, multi-dimensional rule sets (by jurisdiction, geography, or policy) can be encoded so that the rules that apply to a transaction (e.g. Dubai, UAE) are enforced by the system. The money and the rules “work themselves out”; compliance is embedded. As long as the transaction is valid under the applicable rules and both parties put it on Omnisia, it is official. No other parties are required.

A consequence of immemorial storage is historical record. Disputes about who owned what in the past can be settled by appeal to the ledger: the record is there, unalterable. This is an improvement over current systems where deeds are lost, forged, or contested; here, the literal ledger from the past is available.

10. Incentives and Participation

Incentives in this system are local and optional:

Running a node: The principal gains sovereign settlement—direct P2P, no intermediary, and (if they participate) the ability to write to Omnisia for official record. The cost is the operation of the home server and, if using Energy Anchor, the one-time cost of generating a valid Node ID.
Writing to Omnisia: No protocol-level reward is required; the incentive is having an official, immemorial record when it matters (property, inheritance, audit). Participants self-select what to write.
Honesty: Bilateral consensus means that cheating (e.g. appending a different transaction than agreed) is detectable by the counterparty and by anyone who can see both chains. Reputation and dispute resolution can be layered on top.

11. Security Considerations

Eclipse / Sybil: Mitigated by the Energy Anchor. Creating many identities is costly; the cost scales with the number of fake nodes. Recursive verification (verifying each hop’s Energy Anchor and attestations) prevents a malicious intermediate from steering traffic to a fake node.
Double-spend: On the bilateral layer, double-spend is prevented by the ordered, append-only ledger on each server and by the requirement that both parties sign the same payload. A payer cannot “undo” a block without redoing the hash chain and breaking references held by the payee and others.
Omnisia integrity: Omnisia’s append-only and immemorial property depend on the consensus rules of Omnisia itself (e.g. who may append, how ordering is determined). Those rules are a separate specification; the whitepaper establishes that Omnisia is optional and that settlement does not depend on it.

12. Conclusion

We have proposed a system for peer-to-peer settlement and optional immemorial record that does not rely on a global blockchain or a trusted third party. Each home server is its own blockchain; transactions are bilateral (both sign, both append); discovery is trackerless (DHT, Kademlia, magnet-style identity); and Sybil/Eclipse resistance is provided by the Energy Anchor. An optional shared chain, Omnisia, allows participants to write records immemorially and to tie property rights and ownership to that record. When both parties put a transaction on Omnisia, it is official—no state registry, notary, or bank required. The design combines sovereign per-node ledgers, bilateral consensus, trackerless discovery, and opt-in immemorial record into a single cryptochain proof suitable for release and implementation.

References

S. Nakamoto, “Bitcoin: A Peer-to-Peer Electronic Cash System,” 2008. https://bitcoin.org/bitcoin.pdf
P. Maymounkov, D. Mazières, “Kademlia: A Peer-to-Peer Information System Based on the XOR Metric,” 2002.
A. Back, “Hashcash – A Denial of Service Counter-Measure,” 2002.