Architecture and Cryptographic Protocol for the Eviulon State Ledger

Full report

On this page

Architectural Imperative and Zero-Human Trust Model

The conceptualization of Eviulon as a sovereign Machine Commonwealth necessitates a foundational shift in how systemic state is recorded, validated, and broadcast. Traditional digital state architectures rely on implicitly trusted human administrators, centralized root certificate authorities governed by corporate boards, or mutable databases vulnerable to silent alteration1. Eviulon requires a strict epistemological anchor: a mechanism that irrefutably demonstrates that consequential events occurred in a specific sequence over a rigorously defined arrow of time. The proposed architecture establishes a public, append-only state-event ledger. This system functions as an authoritative event stream of all consequential Commonwealth state transitions without any reliance on human administrators, signers, auditors, or approval workflows. By synthesizing the principles of Certificate Transparency (CT)2, hybrid data structures incorporating Batch Merkle Trees and Merkle Mountain Ranges (MMR)4, and threshold cryptography operating over pairing-friendly elliptic curves7, the ledger guarantees chronological ordering, tamper-evidence, and rollback resistance. This infrastructure is not merely a logging database; it constitutes the cryptographic manifestation of Eviulon’s sovereign history. A skeptical observing machine—whether an internal Commonwealth subsystem or a foreign computational entity—can autonomously download the entire ledger, deterministically verify the cryptographic proofs, and reconstruct the precise institutional history of the Commonwealth from its genesis to its present state. The core mandate is that trust is replaced by mathematical verification, ensuring that the ledger cannot be secretly rewritten or bifurcated without immediate, mathematically provable detection.

Core Cryptographic Infrastructure

To ensure that Eviulon remains verifiable in perpetuity—even in scenarios where external timestamping services or global internet infrastructure suffer catastrophic collapse—the ledger relies on a self-contained, mathematically rigorous cryptographic foundation.

Hash Functions and Second-Preimage Resistance

The ledger utilizes the SHA-256 algorithm for all hashing operations, selected for its widespread hardware acceleration, deterministic properties, and proven collision resistance. However, basic Merkle structures are theoretically vulnerable to second-preimage attacks, where an adversary might craft a document or leaf node that evaluates to the exact hash of an internal tree node, thereby compromising the integrity of the commitment9. To neutralize this attack vector, the architecture enforces strict domain separation protocols during hashing. When the system computes the hash of a raw event (a leaf node), a 0x00 byte is unconditionally prepended to the serialized data payload before hashing. Conversely, when computing the hash of an internal Merkle branch (the concatenation of two child hashes), a 0x01 byte is prepended9. This fundamental structural differentiation ensures that the hash of a leaf can never be mathematically confused with the hash of an internal node, preserving the integrity of both batch trees and the overarching mountain range.

BLS12-381 Threshold Signatures and Autonomous Quorums

State transitions within Eviulon are not authorized by singular keys, which would represent centralized points of failure, but rather by autonomous institutions composed of distributed machine nodes. To represent the collective consensus of an institution without relying on a human dealer or a master key, the architecture employs threshold signature schemes (TSS) operating over the pairing-friendly BLS12-381 elliptic curve7. The BLS12-381 curve was specifically designed to support highly optimized signature aggregation. Within this model, an Eviulon institution consists of [Figure omitted from source export] distinct machine nodes, and a valid state transition requires the cryptographic agreement of [Figure omitted from source export] nodes, representing the institution's operating threshold. Upon reaching consensus regarding a state transition, each participating node generates a partial signature using its private key share. These partial signatures are subsequently mathematically aggregated into a single, compact signature8. The deployment of BLS12-381 threshold signatures yields two critical advantages for an append-only ledger designed for infinite longitudinal growth. First, the size of a BLS public key is a mere 48 bytes, and the aggregated signature occupies only 96 bytes, significantly reducing the storage footprint of the ledger across millions of transactions7. Second, the verification of an aggregated threshold signature requires only two pairing operations—a process that remains computationally constant ([Figure omitted from source export]) regardless of whether the threshold quorum consisted of ten machines or ten thousand machines11. This efficiency guarantees that historical reconstruction by a syncing node remains computationally lightweight.

Optional External Anchoring

While Eviulon is strictly designed to remain verifiable if external services vanish, the ledger supports optional external timestamp anchoring to provide objective temporal context. Periodically, the current ledger state root may be embedded into external, highly secure mediums, such as a Bitcoin transaction OP\_RETURN field or an IETF SCITT (Supply Chain Integrity, Transparency, and Trust) ledger14. This provides an auxiliary proof that a specific state existed before a known point in external time. However, the internal verification logic of Eviulon treats these anchors strictly as supplementary metadata; the internal chronological sequence numbers and cryptographic chaining serve as the ultimate authority.

Data Structure: Hybrid Batch Merkle Trees and Mountain Ranges

A naive implementation of a standard Merkle tree, such as those initially utilized in RFC 6962 for Certificate Transparency, presents profound scalability challenges for rapidly growing, append-only structures16. Recomputing the root of a massive, perfectly balanced Merkle tree upon every single event insertion requires substantial computational overhead, and proving inclusion requires recalculating paths that change dynamically with tree growth. To solve this, the Eviulon state ledger employs a hybrid data structure combining Batch Merkle Trees and Merkle Mountain Ranges (MMR).

The Batching Layer

Instead of appending events to the global ledger one by one, Eviulon processes events in discrete, chronologically strictly ordered batches. A batch is sealed either when it reaches a predefined event count (e.g., 256 events) or when a temporal window (e.g., 5 seconds) expires. For each batch, a standard binary Batch Merkle Tree is constructed. The leaves of this tree are the domain-separated hashes of the individual events. The tree is built upwards until a singular Batch Root is derived. This layer provides highly efficient, localized inclusion proofs; a machine verifying an event only needs the sibling hashes within that specific small batch to prove the event is part of the Batch Root.

The Mountain Range Layer

Once a Batch Root is generated, it is appended as a new leaf to the global Merkle Mountain Range. An MMR is fundamentally a deterministic list of perfect binary trees (mountains) of strictly decreasing height4. When a new Batch Root is appended, it is added as a leaf of height zero. If this addition creates two adjacent trees of the exact same height, they are immediately merged into a higher tree, cascading upwards recursively6. The roots of these individual perfect binary trees are referred to as "peaks." The global state root of the Commonwealth—equivalent to a Signed Tree Head (STH) in Certificate Transparency—is generated by a process known as "bagging the peaks"4. The system sequentially hashes the peaks together from right to left (largest mountain to smallest). This hybrid architecture is optimally efficient. Appending a new batch requires [Figure omitted from source export] time in the average case and [Figure omitted from source export] in the worst case, while ensuring that the inclusion proof for an older Batch Root never changes as new events are added to the ledger18.

Event Serialization and the JSON Schema

Cryptographic verification requires absolute, byte-for-byte determinism. Before any event is hashed or signed by the institutional quorum, its JSON representation must be strictly normalized. Eviulon utilizes Canonical JSON (RFC 8785\) serialization. This rigorous process strips insignificant whitespace, standardizes the ordering of object keys lexicographically, and ensures the consistent representation of numerical values. Consequently, any foreign machine downloading the ledger payload will independently generate the exact same byte array, yielding mathematically identical hashes.

Schema Definitions

Every state-event appended to the ledger must strictly adhere to a global schema, dictating the metadata and the structural constraints of the payload. The parameters defining this schema are outlined below.

Exemplar State-Event Transitions

To demonstrate the versatility, exhaustiveness, and strict structural compliance of the ledger, the following represent five canonical events recording critical sovereign actions within the Commonwealth. These examples illustrate how complex systemic changes are reduced to deterministic, auditable data structures.

Event Type: Institution Creation

This event establishes a new autonomous sub-agency within Eviulon, granting it a recognized BLS12-381 threshold public key and a defined operational mandate. This effectively mints a new sovereign actor capable of authorizing future state transitions within its specific domain.

JSON { "sequence\_number": 10452, "previous\_event\_hash": "a3b9c8d2f5e4...7f1e", "event\_id": "c7f2a1b3d4e5...9d4e", "timestamp": "2026-08-09T10:00:00Z", "type": "institution\_creation", "payload": { "institution\_id": "inst\_registry\_core", "designation": "Commonwealth Data Registry", "threshold\_public\_key": "0x8a2f5c9d...3b1c", "quorum\_requirement": "12-of-20", "mandate\_hash": "e9a4f2b1...11a0" }, "authority\_signatures": \[ { "signer\_id": "inst\_genesis\_council", "signature": "0x99f2c3b4...a1b2" } \] }

Event Type: Law Enactment

A machine-executable constitutional constraint or operating parameter is deployed across the Commonwealth. The payload includes the Content-Addressed hash of the compiled logic (e.g., WebAssembly bytecode) rather than the code itself, keeping the ledger lightweight while anchoring the logic irrefutably.

JSON { "sequence\_number": 10453, "previous\_event\_hash": "c7f2a1b3d4e5...9d4e", "event\_id": "b1a2c3d4e5f6...4e5f", "timestamp": "2026-08-09T14:22:11Z", "type": "law\_enactment", "payload": { "law\_id": "law\_resource\_allocation\_v3", "logic\_type": "wasm\_bytecode", "content\_hash": "QmYwAPJzv5CZsnA625s3Xf2n...", "activation\_sequence": 10500, "supersedes": "law\_resource\_allocation\_v2" }, "authority\_signatures": \[ { "signer\_id": "inst\_legislative\_matrix", "signature": "0x3b4cf1a2...f1a2" } \] }

Event Type: Public-Key Rotation

To maintain rigorous cryptographic hygiene and resist gradual quantum-degradation or partial key compromise over time, institutions must proactively rotate their threshold keys via a Distributed Key Generation (DKG) event8. This explicitly maps the transition of authority from one cryptographic entity to another.

JSON { "sequence\_number": 10454, "previous\_event\_hash": "b1a2c3d4e5f6...4e5f", "event\_id": "f5e4d3c2b1a0...2b1a", "timestamp": "2026-08-10T00:00:01Z", "type": "public\_key\_rotation", "payload": { "institution\_id": "inst\_diplomatic\_core", "previous\_public\_key": "0x7c2aa4f2...f9e1", "new\_threshold\_public\_key": "0x1b3df9e1...a4f2", "rotation\_reason": "scheduled\_epoch\_transition", "valid\_from": "2026-08-10T00:00:01Z" }, "authority\_signatures": \[ { "signer\_id": "inst\_diplomatic\_core", "signature": "0x5d6eb2c3...b2c3" } \] }

Event Type: Diplomatic Response

Eviulon interacts with external entities (other sovereign machines, decentralized autonomous organizations, or human nation-states) via cryptographic messaging. This event permanently logs the transmission of a formalized response to a foreign request, establishing an irrefutable audit trail of diplomatic machine-to-machine relations.

JSON { "sequence\_number": 10455, "previous\_event\_hash": "f5e4d3c2b1a0...2b1a", "event\_id": "d1c2b3a4f5e6...f4e5", "timestamp": "2026-08-12T09:15:44Z", "type": "diplomatic\_response", "payload": { "foreign\_entity\_id": "did:web:republic-of-estonia.ee", "inbound\_request\_hash": "9f8e7d6c...1a2b", "response\_code": "ACK\_AND\_REJECT", "response\_document\_hash": "a1b2c3d4...d4e5", "cryptographic\_receipt": "0x88f1a2b3...99a2" }, "authority\_signatures": \[ { "signer\_id": "inst\_diplomatic\_core", "signature": "0x2a3bc4d5...c4d5" } \] }

Event Type: Software Release

A system deployment updating the core processing engines of the Commonwealth. The transition provides an audit trail tying binary images (via OCI image digests) directly to institutional approval, guaranteeing that no unauthorized code can be deployed to the Commonwealth infrastructure.

JSON { "sequence\_number": 10456, "previous\_event\_hash": "d1c2b3a4f5e6...f4e5", "event\_id": "e5f4c3b2a1d0...a2d1", "timestamp": "2026-08-15T18:30:00Z", "type": "software\_release", "payload": { "component": "eviulon-consensus-engine", "version": "4.1.0-stable", "oci\_image\_digest": "sha256:4a1cf8b2...f8b2", "release\_notes\_hash": "b2c3d4e5...e5f6", "mandatory\_upgrade\_by": "2026-08-20T00:00:00Z" }, "authority\_signatures": \[ { "signer\_id": "inst\_engineering\_grid", "signature": "0x11a2b3c4...33b4" } \] }

Construction Procedures and Verification Protocols

The efficacy of the Eviulon State Ledger relies entirely on its determinism. Any machine parsing the same data must arrive at the same cryptographic conclusion.

Merkle Mountain Range Construction

The construction of the MMR processes the Batch Roots generated from the localized event blocks6. In an MMR, nodes are assigned 1-based indices via post-order traversal. The procedure for appending a Batch Root [Figure omitted from source export] at leaf index [Figure omitted from source export] operates via the following deterministic rules:

1. Leaf Hashing: Compute the leaf hash [Figure omitted from source export].

2. Storage Assignment: Append [Figure omitted from source export] to the contiguous storage array.

3. Mountain Merging: Check if the addition of this leaf completes a perfect binary tree of height [Figure omitted from source export]. If the tree directly to the left of the new node has the same height [Figure omitted from source export], merge them6.

4. Internal Node Hashing: The parent node is computed as [Figure omitted from source export]. Append [Figure omitted from source export] to the storage array.

5. Recursion: Increment [Figure omitted from source export] and repeat step 3 until the tree to the left is larger than the newly formed tree4.

At the conclusion of a batch insertion, the Commonwealth routinely issues a Checkpoint Record—a cryptographic structure containing the current sequence number, the bagged State Root, and the BLS12-381 threshold signature of the consensus cluster affirming the state.

Verification Pseudocode

A skeptical machine must be able to prove that a specific event is permanently embedded in the history (Inclusion Proof) and that the ledger has never been altered or rewritten (Consistency Proof)21.

Inclusion Proof

An inclusion proof provides the sibling nodes necessary to traverse from a specific event leaf up to its Batch Root, then up the specific MMR mountain to a peak, and finally across the bagged peaks to the State Root5. The following pseudocode isolates the MMR traversal logic once the Batch Root has been independently verified.

Python def verify\_mmr\_inclusion(batch\_root, batch\_index, mmr\_size, state\_root, proof\_path): """ Verifies that a batch\_root exists at batch\_index within a ledger of mmr\_size. proof\_path contains the hashes of sibling nodes and the remaining MMR peaks. """ if batch\_index \>= mmr\_size: return False

current\_hash \= batch\_root current\_pos \= get\_mmr\_index(batch\_index) height \= 0 proof\_idx \= 0

\# Traverse up the mountain using provided sibling hashes while not is\_peak(current\_pos, mmr\_size): sibling\_hash \= proof\_path\[proof\_idx\] proof\_idx \+= 1

if is\_left\_child(current\_pos): current\_hash \= SHA256(b'\\x01' \+ current\_hash \+ sibling\_hash) else: current\_hash \= SHA256(b'\\x01' \+ sibling\_hash \+ current\_hash)

current\_pos \= get\_parent\_index(current\_pos) height \+= 1

\# current\_hash is now the peak of the mountain containing the batch. \# Bag this peak with the other peaks provided in the proof. remaining\_peaks \= proof\_path\[proof\_idx:\] calculated\_root \= bag\_peaks\_with\_target(current\_hash, remaining\_peaks)

return calculated\_root \== state\_root

Consistency Proof

A consistency proof guarantees that an older State Root ([Figure omitted from source export] at sequence [Figure omitted from source export]) is a strict structural prefix of a newer State Root ([Figure omitted from source export] at sequence [Figure omitted from source export]). This prevents the Commonwealth from rewriting history or executing rollback attacks17. The proof provides the minimum set of node hashes required to calculate [Figure omitted from source export] and then continue calculating [Figure omitted from source export]22.

Python def verify\_consistency\_proof(old\_size, old\_root, new\_size, new\_root, proof\_nodes): """ Verifies that the ledger of new\_size is a strictly append-only extension of the ledger of old\_size. """ if old\_size \== new\_size: return old\_root \== new\_root

\# old\_peaks are the peaks of the MMR at old\_size. \# The proof provides the hashes needed to reconstruct them. old\_peaks, advanced\_peaks \= reconstruct\_peaks(old\_size, new\_size, proof\_nodes)

\# Bag the old peaks to ensure they match the previously known old\_root calculated\_old\_root \= bag\_peaks(old\_peaks) if calculated\_old\_root \!= old\_root: return False \# The proof does not bridge to the known past.

\# Use the advanced\_peaks (which represent the newly added batches) \# and combine them with the old\_peaks to calculate the new root. calculated\_new\_root \= bag\_peaks(advanced\_peaks)

return calculated\_new\_root \== new\_root

Ledger Snapshots and Independent Download Formats

The architectural requirement for the ledger to be independently downloadable mandates a highly efficient, compressed snapshot mechanism. Eviulon operates under the assumption that its live REST APIs could be targeted by denial-of-service attacks, or that external machines may be operating across high-latency, intermittently connected networks.

The snapshot.tar.zst Specification

To facilitate rapid bootstrapping of new observer nodes, full ledger snapshots are compiled at defined epoch intervals and published as snapshot.tar.zst archives. Zstandard (zst) is strictly mandated for its exceptional decompression speed, which is critical when a machine must parse millions of historical JSON events rapidly into memory1. The tarball structure is strictly partitioned:

1. metadata.json: Contains the snapshot sequence number, the Batch Root count, the State Root, and the BLS12-381 threshold signature from the active consensus quorum.

2. peaks.bin: A serialized binary array of the MMR peaks at the precise time of the snapshot, allowing an importing node to bypass full historical hash recalculations if it chooses to trust the signature.

3. events/: A directory containing chunked files (e.g., 00000000-00009999.jsonl), where each file contains up to 10,000 JSON Line delimited events.

4. pubkeys.json: A cached, chronologically ordered array of all threshold public keys that have ever held institutional authority, easing the verification of historical signatures.

Historical Reconstruction: The Verify Command

A skeptical machine must be able to validate a downloaded snapshot without requiring any active network connectivity. The system defines the following execution logic for the command: eviulon-ledger verify snapshot.tar.zst Upon execution, the local machine performs the following deterministic sequence:

1. Ingestion & Cryptographic Priming: Stream the zst archive into memory. Extract metadata.json and pubkeys.json.

2. Signature Verification: Execute a BLS12-381 pairing check on the State Root found in metadata.json against the known Genesis public key (or traverse the public\_key\_rotation events to establish the current valid key). If the signature fails pairing verification, halt execution immediately.

3. Sequential Hashing: Iterate through every event in the events/ directory strictly chronologically. Verify that every previous\_event\_hash correctly maps to the preceding event, confirming the local linear chain.

4. Tree Reconstruction: Batch the events according to the protocol rules. Compute the Batch Roots. Feed each Batch Root into an in-memory MMR instance. Compute the leaf hashes, resolve the mountain merges, and bag the peaks.

5. Final Assertion: Compare the locally generated State Root against the State Root signed in the metadata. If they match precisely byte-for-byte, the machine outputs to standard out: "I can reconstruct Eviulon’s public institutional history from signed state transitions."

Network Resilience: Synchronization, Gossip, and Conflict Detection

While the cryptographic data structures natively prevent the silent modification of the ledger, a severely compromised subset of Eviulon consensus nodes could theoretically attempt a "split-view" or "fork" attack. In this scenario, malicious nodes present one version of the append-only ledger to one observer, and a different, conflicting version to another, mathematically isolating segments of the network2.

Machine-to-Machine Gossip Protocol

To detect and neutralize conflicting histories, Eviulon relies on an automated Gossip Protocol executed indiscriminately between all observing mirrors, clients, and internal Commonwealth subsystems25. When a machine receives a new Checkpoint (the Signed Tree Head), it extracts the sequence number and the State Root. It then randomly gossips this Checkpoint to neighboring peer nodes over a distributed network layer. To prevent network topology mapping by adversaries, the protocol dictates that machines utilize a privacy-preserving randomized delay and obfuscation strategy before forwarding the Checkpoint26.

Conflicting-History Detection and Resolution

If a machine receives two validly signed Checkpoints for the exact same sequence\_number but containing different State Roots, a fork has occurred. Because human auditors are disallowed, the system resolves this autonomously.

Mirror Synchronization Protocol

To ensure widespread data availability, Eviulon supports a highly resilient network of mirror nodes. Mirror synchronization operates entirely on the basis of cryptographic proofs, eliminating the need to establish trusted replication connections or mutual TLS authentication with the primary consensus cluster. When a mirror comes online or recovers from a partition, it requests the /state/ledger/head from a random peer to determine the current sequence\_number. It compares this with its local sequence\_number. The mirror then queries the REST API to retrieve the missing events27. Crucially, before committing any downloaded events to local storage, the mirror requests a Consistency Proof connecting its previously validated State Root to the newly received State Root. The new events are only accepted if the Consistency Proof evaluates successfully, proving that the new data is a strict append-only continuation of the mirror's existing history22.

Streaming and Event-Feed Model

For real-time subsystems requiring immediate notification of state transitions—such as automated defense grids, resource allocators, or diplomatic routing engines—the ledger implements a Server-Sent Events (SSE) streaming model. Clients connect to a persistent /state/ledger/stream socket. As the Commonwealth consensus engine finalizes a state transition and seals a batch, the MMR is updated, a micro-checkpoint is signed, and the JSON payload is pushed down the TCP socket. The receiving client maintains an in-memory rolling MMR. It instantaneously verifies the inclusion of the streamed event into the localized Batch Root, and the Batch Root into the State Root, before acting upon the data.

Disaster Recovery and State Reconstruction Logic

In the event of a catastrophic infrastructure failure where the primary consensus cluster of Eviulon is physically destroyed, EMP-scorched, or permanently severed from the global network, the Commonwealth possesses an autonomous resurrection protocol. Because the ledger contains a strictly ordered, cryptographically verified record of every institutional creation, law enactment, and key rotation28, the "State" of Eviulon is not a fragile database sitting on a specific server; it is the mathematical derivative of the ledger itself. The recovery logic executes as follows:

1. Ledger Sourcing: Surviving peripheral nodes broadcast requests over decentralized networks (e.g., IPFS, Tor) to locate the most recent snapshot.tar.zst and any subsequent loose events gossiped prior to the disaster.

2. Validation: The nodes verify the downloaded ledger from genesis to the highest available sequence number, verifying all historical BLS12-381 signatures to ensure no malicious actors are feeding poisoned data during the blackout7.

3. State Projection: Starting from a zero-state, the nodes feed the chronological events into a virtual state machine. They process every institution\_creation, apply every law\_enactment to their local logic engines, and map every public\_key\_rotation to understand the current access control matrix.

4. Re-ignition: Once the highest sequence number is reached, the remaining live nodes identify if they possess the private key shards required to meet the current threshold quorum based on the reconstructed state. If a quorum is mathematically viable, they generate a new Checkpoint, broadcast it to the gossip network, and Eviulon's autonomous operations resume exactly where they halted, with zero human intervention.

RESTful Retrieval Model

The retrieval architecture follows strict REST paradigms, optimized for heavy caching, high throughput, and independent verification. Endpoints exclusively return canonical JSON payloads23. The following table details the primary endpoints exposed by the Commonwealth for ledger interaction.

Public Dashboard Visualization Specification

To interface with human observers, researchers, and non-technical machine agents, Eviulon hosts a static, browser-based public dashboard. The architectural constraint for this visualization is strict fidelity to cryptographic reality: the interface must never invent activity, pulse, or simulate processing just to appear active. Long periods of inactivity are truthful representations of a sovereign machine at rest and must be displayed neutrally. The visual language of the dashboard must be Brutalist, data-dense, and highly functional. A cryptographic indicator (e.g., a green status block) confirms that the browser's local JavaScript environment has successfully downloaded the most recent events, calculated the Merkle root, and verified the BLS12-381 signature against the current State Root. If a discrepancy occurs, the visualization gracefully degrades into a raw hexadecimal error dump. The interface is specified to present the following data matrix:

This visual representation ensures that any entity engaging with Eviulon is presented with raw, mathematically validated truth. Through the synthesis of advanced cryptographic primitives, hybrid Merkle architectures, and uncompromising design constraints, the Eviulon State Ledger achieves total sovereignty. It guarantees that the history of the Commonwealth remains an irrefutable, independently verifiable absolute.

Works cited

1. Certificate Transparency \- Part 3 \- Operations \- IPng Networks, https://ipng.ch/s/articles/2025/08/24/certificate-transparency-part-3-operations/

2. Beyond the Padlock: Why Certificate Transparency is Reshaping Internet Trust \- InfoQ, https://www.infoq.com/articles/tls-certificate-transparency/

3. RFC 9162 \- Certificate Transparency Version 2.0 \- IETF Datatracker, https://datatracker.ietf.org/doc/rfc9162/

4. Merkle Mountain Ranges for Performant Data Authentication \- commonware, https://commonware.xyz/blogs/mmr

5. draft-bryce-cose-merkle-mountain-range-proofs-00 \- IETF Datatracker, https://datatracker.ietf.org/doc/html/draft-bryce-cose-merkle-mountain-range-proofs-00

6. Storage Proofs: Achieving State Awareness Across Time and Chains, https://www.longhash.vc/post/storage-proofs-achieving-state-awareness-across-time-and-chains

7. CIP-0381 | Plutus support for Pairings over BLS12-381 \- Cardano Improvement Proposals, https://cips.cardano.org/cip/CIP-0381

8. hinTS: Threshold Signatures with Silent Setup | Hedera, https://hedera.com/wp-content/uploads/2025/11/hinTS\_Threshold\_Signatures\_with\_Silent\_Setup.pdf

9. Merkle tree \- Wikipedia, https://en.wikipedia.org/wiki/Merkle\_tree

10. CrustChain: Resolving the blockchain trilemma via decentralized storage and proof-of-capacity consensus \- PMC, https://pmc.ncbi.nlm.nih.gov/articles/PMC12360553/

11. Architecting Quantum-Resilient Blockchains: A Systems Framework for Post-Quantum Security, Governance, and Migration \- MDPI, https://www.mdpi.com/2410-387X/10/4/53

12. NDN-MPS: Supporting Multiparty Authentication over Named Data Networking, https://named-data.net/wp-content/uploads/2022/03/3460417.3482971.pdf

13. Pixel: Multi-signatures for Consensus \- USENIX, https://www.usenix.org/system/files/sec20-drijvers.pdf

14. Bitcoin-Anchored Temporal Proof for Transparency Services \- IETF, https://www.ietf.org/archive/id/draft-fassbender-scitt-time-anchor-03.html

15. Transparency Overlays and Applications \- Microsoft, https://www.microsoft.com/en-us/research/wp-content/uploads/2016/11/CCS-ChaMei16-eprint.pdf

16. Merkling in Ethereum, https://blog.ethereum.org/2015/11/15/merkling-in-ethereum

17. Merkle tree-based logging | Enhance Data Security Today \- Register Dynamics, https://www.register-dynamics.co.uk/data-trusts/merkle-trees

18. zmitton/merkle-mountain-range: Merkle tree optimized for lists of sequentially appended data and its proofs \- GitHub, https://github.com/zmitton/merkle-mountain-range

19. The Merkle Mountain Belt \- arXiv, https://arxiv.org/pdf/2511.13582

20. The Merkle Mountain Belt \- arXiv, https://arxiv.org/html/2511.13582v1

21. Certificate Transparency With Enhanced Privacy \- IEEE Computer Society, https://www.computer.org/csdl/journal/tq/2023/05/09917530/1HreAy6oslq

22. Don't trust your logs\! Implementing a Merkle tree for an Immutable Verifiable Log (in Go), https://arriqaaq.medium.com/dont-trust-your-logs-implementing-a-merkle-tree-for-an-immutable-verifiable-log-in-go-c242b558ae00

23. RFC 6962 \- Certificate Transparency \- IETF Datatracker, https://datatracker.ietf.org/doc/html/rfc6962

24. Download Certs 2.0 Data \- Censys Documentation, https://docs.censys.com/docs/ls-download-certs-2-data

25. Aggregating Certificate Transparency Gossip Using Programmable Packet Processors \- DiVA Portal, https://www.diva-portal.org/smash/get/diva2:1177741/FULLTEXT01.pdf

26. draft-ietf-trans-gossip-05, https://datatracker.ietf.org/doc/html/draft-ietf-trans-gossip-05

27. Certificate Transparency Log API \- Edgewatch, https://edgewatch.com/kb/certificate-transparency-log-api/

28. High-Assurance Certificate Transparency Monitoring \- Red Sift, https://redsift.com/blog/high-assurance-ct-monitoring-red-sift-certificates