MESH2/docs/specs/MESH-Protocol-Specification-Suite-v0.1.0.md

MESH PROTOCOL

Minimal-Exchange Settlement Hypergraph

Formal Protocol Specification Suite

Version 0.1.0-draft

March 2026

CLASSIFICATION: PUBLIC --- OPEN STANDARD

License: Apache 2.0 (specification) / CC-BY-SA 4.0 (documentation)

Table of Contents

SPEC-001: Overview, Conventions, and Threat Model

1.1 Purpose

This document suite constitutes the formal specification of the MESH protocol (Minimal-Exchange Settlement Hypergraph). It is intended to provide sufficient detail for an independent engineering team to produce a conformant implementation without access to the authors, the reference implementation, or any other materials beyond these specifications and the referenced academic papers.

Each specification in this suite is self-contained for its component, but cross-references other specifications where interfaces exist. Implementers MUST read SPEC-001 before any other specification, as it defines the conventions, terminology, and threat model that apply to all subsequent documents.

1.2 Document Conventions

RFC 2119 Keywords: The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in these documents are to be interpreted as described in RFC 2119. All uses are capitalised for emphasis.

Notation: Mathematical notation follows standard conventions. Sets are denoted by capital letters (A, E, V). Functions use lowercase (f, g, σ). The symbol ≺ denotes the causal partial order. The symbol ‖ denotes concatenation of byte strings. The symbol ⊕ denotes XOR. The notation [n] means the set {0, 1, ..., n-1}.

Byte Encoding: All multi-byte integers are encoded in little-endian format unless explicitly stated otherwise. All cryptographic values (public keys, signatures, hashes) are encoded as fixed-length byte arrays. Lengths are specified in bytes.

Pseudo-code: Algorithm descriptions use Python-like pseudo-code with explicit type annotations. This is descriptive, not prescriptive --- implementations may use any language or approach that produces identical outputs for identical inputs across all test vectors.

1.3 Specification Suite Index

---

Spec ID Title Scope

SPEC-001 Overview, Conventions, and This document. Global Threat Model conventions, terminology, threat model, and security properties.

SPEC-002 Settlement Hypergraph Data Core data structures: Model accounts, transitions, hyperedges, causal ordering, the Value Semiring.

SPEC-003 Tier 1 --- Consensusless Byzantine Consistent Broadcast Settlement Protocol for simple payments. Sub-300ms finality path.

SPEC-004 Tier 2 --- DAG-BFT Ordered DAG-based consensus for Settlement complex multi-party settlements requiring total order.

SPEC-005 Tier 3 --- Asynchronous BFT Liveness-guaranteed fallback Fallback under network partition. aBFT protocol.

SPEC-006 Cryptographic Primitives and All cryptographic operations, Cipher Suites key formats, cipher suite negotiation, PQ migration.

SPEC-007 Privacy Layer Pedersen commitments, Bulletproofs+ range proofs, stealth addresses, selective disclosure.

SPEC-008 Value Routing and Exchange Multi-hop routing, PTLC atomicity, connector protocol, packet format, price discovery.

SPEC-009 Network Transport and Peer Wire protocol, message Discovery framing, peer discovery, eclipse attack resistance.

SPEC-010 Validator Operations and Validator lifecycle, key Governance management, upgrade protocol, fee model, governance.

---

1.4 System Model

1.4.1 Participants

The MESH network consists of the following participant types:

• Accounts: End-user entities identified by a public key. An account holds balances in zero or more asset types and initiates settlements. An account has a monotonically increasing sequence number that prevents replay attacks. Accounts do not run persistent software --- they interact via client applications (wallets).

• Validators: Infrastructure nodes that verify and certify state transitions. The validator set V = {v₁, v₂, ..., vₙ} is known to all participants and changes only through the governance protocol (SPEC-010). Each validator holds a signing key pair. Validators are expected to have persistent storage and reliable network connectivity.

• Connectors: Nodes that hold balances in multiple asset types and facilitate cross-asset settlement by providing liquidity. Connectors are a specialisation of accounts --- they are accounts that additionally run the connector protocol (SPEC-008). Any account MAY become a connector.

1.4.2 Threat Model

MESH assumes the following threat model, which applies to all specifications:

Byzantine Validators: Up to f < n/3 validators may be Byzantine (arbitrarily malicious). Byzantine validators may: crash, send conflicting messages to different parties, collude with each other, delay messages selectively, and attempt to forge or suppress settlements. They may NOT break the cryptographic assumptions (see SPEC-006).

Network Model: The network is partially synchronous for Tier 1 and Tier 2 protocols. This means there exists an unknown bound Δ such that after Global Stabilisation Time (GST), all messages between correct validators are delivered within Δ. Before GST, messages may be delayed arbitrarily. For Tier 3, the network is fully asynchronous (no timing assumptions).

Byzantine Accounts: Any account may be Byzantine. A Byzantine account may attempt to: double-spend (issue two conflicting transitions from the same state), forge transaction certificates, or collude with Byzantine validators. The protocol MUST prevent all such attacks when f < n/3.

Cryptographic Assumptions: Security relies on: (a) the hardness of the Discrete Logarithm Problem in the chosen elliptic curve group (Suite 0), (b) the hardness of Module-LWE (Suite 1+), (c) collision resistance of SHA-3/SHAKE, (d) the random oracle model for Fiat-Shamir transforms. These are specified precisely in SPEC-006.

1.4.3 Security Properties

The protocol MUST satisfy the following properties under the stated threat model. These are the acceptance criteria for any conformant implementation.

SAFETY-1 (No Double-Spend): If a settlement certificate is issued for a transition t on account a, then no conflicting transition t′ (same account, same sequence number, different content) can ever receive a valid settlement certificate. This holds even if f < n/3 validators are Byzantine.

SAFETY-2 (Value Conservation): For every settlement hyperedge e, the sum of all value debited from source accounts equals the sum of all value credited to destination accounts, within the same asset type. Cross-asset exchanges are modelled as paired settlements with an exchange rate, not as creation or destruction of value.

SAFETY-3 (No Inflation): No state transition may increase the total supply of any asset type. The only way to introduce new value into the system is through the on-ramp protocol (SPEC-008 §8.6), which requires proof of external settlement.

LIVENESS-1 (Settlement Finality): If a correct account initiates a valid Tier 1 settlement and at least 2f+1 validators are correct and reachable, the settlement achieves finality within 2Δ time (two message delays).

LIVENESS-2 (No Deadlock): The protocol MUST NOT reach a state where a correct account's funds are permanently locked. All conditional settlements have timeouts. All escrows have expiration. No correct account can be denied access to its own balance indefinitely.

PRIVACY-1 (Amount Confidentiality): Settlement amounts MUST NOT be observable by any party other than the sender, recipient, and (where applicable) the connectors on the settlement path. Validators verify amount validity through zero-knowledge proofs without learning the amounts.

PRIVACY-2 (Unlinkability): Given two settlement certificates, no observer (including validators) can determine whether they involve the same sender or recipient, except with negligible probability, unless the sender or recipient voluntarily discloses this linkage.

1.5 Versioning and Compatibility

The MESH protocol uses semantic versioning (MAJOR.MINOR.PATCH). A change in MAJOR version indicates a breaking change that requires all validators to upgrade simultaneously (hard fork). A change in MINOR version indicates a backward-compatible addition. A change in PATCH version indicates a bug fix.

All protocol messages include a version field. Validators MUST reject messages with an unsupported MAJOR version. Validators SHOULD process messages with a higher MINOR version than their own, ignoring unknown fields. This enables rolling upgrades without network-wide coordination for non-breaking changes.

SPEC-002: Settlement Hypergraph Data Model

2.1 Purpose

This specification defines the core data structures of the MESH protocol. All other specifications reference these structures. Implementers MUST support all data types defined here with the exact byte-level encoding specified.

2.2 Primitive Types

---

Type Size Description

u8 1 byte Unsigned 8-bit integer.

u32 4 bytes Unsigned 32-bit integer, little-endian.

u64 8 bytes Unsigned 64-bit integer, little-endian.

u128 16 bytes Unsigned 128-bit integer, little-endian. Used for all value amounts. Supports up to 3.4 × 10³⁸ base units.

Hash 32 bytes Output of SHA3-256. Used for content addressing and Merkle commitments.

PublicKey 32 bytes Ed25519 public key. For Suite 1+, see SPEC-006 (Suite 0) for expanded sizes.

Signature 64 bytes Ed25519 signature. For Suite 1+, see SPEC-006. (Suite 0)

Commitment 32 bytes Pedersen commitment point (compressed Edwards form). See SPEC-007.

RangeProof variable Bulletproofs+ range proof. See SPEC-007 for encoding.

AssetID 32 bytes SHA3-256(asset_name || issuer_pubkey || precision). Uniquely identifies an asset type.

---

2.3 Account State

An account is the fundamental unit of participation in the MESH network. Each account is identified by its public key and maintains local state that is updated by state transitions.

2.3.1 AccountState Structure

struct AccountState {

owner: PublicKey, // The account's public key (identity)

sequence: u64, // Monotonically increasing counter

balances: Map<AssetID, Commitment>, // Balance per asset (committed)

state_hash: Hash, // SHA3-256 of serialised state

last_cert: Hash, // Hash of most recent settlement certificate

created_at: u64, // Unix timestamp (seconds) of account creation

}

The sequence number starts at 0 for new accounts and increments by exactly 1 for each transition. A validator MUST reject any transition whose sequence number is not exactly last_sequence + 1. This is the primary mechanism preventing double-spends: two conflicting transitions would share the same sequence number, and the equivocation is detectable.

Balances are stored as Pedersen commitments, not plaintext values. A commitment C = vG + bH commits to value v using blinding factor b. The validator cannot learn v, but can verify that transitions are consistent using the homomorphic property of the commitments (see SPEC-007).

2.3.2 Account Creation

An account is created by its first state transition. There is no separate registration step. The first transition MUST have sequence number 0 and MUST be a receive transition (receiving value from another account or from the on-ramp protocol). An account with no balances and no transitions does not exist in the protocol.

2.4 State Transitions

A state transition is an atomic change to one or more accounts. Transitions are the edges of the causal graph.

2.4.1 Transition Structure

struct Transition {

version: u8, // Protocol major version

transition_type: TransitionType, // enum: Send, Receive, Exchange, OnRamp, OffRamp

sender: PublicKey, // Account initiating the transition

sequence: u64, // Sender's next sequence number

recipients: Vec<Recipient>, // One or more recipients (hyperedge)

asset_id: AssetID, // Asset being transferred

amount: Commitment, // Value committed (Pedersen)

range_proof: RangeProof, // Proves amount ≥ 0 and ≤ sender balance

fee: Commitment, // Fee committed (paid to validators)

fee_proof: RangeProof, // Proves fee ≥ 0

causal_deps: Vec<Hash>, // Hashes of transitions this depends on

expiry: u64, // Unix timestamp after which transition is void

memo: [u8; 256], // Encrypted end-to-end data (opaque to validators)

signature: Signature, // Sender's signature over all above fields

}

2.4.2 Recipient Structure

struct Recipient {

address: PublicKey, // Recipient's public key (or stealth address)

amount: Commitment, // Value committed to this recipient

range_proof: RangeProof, // Proves amount ≥ 0

}

A transition with multiple recipients is a single atomic operation. Either all recipients receive their amounts, or none do. This is how MESH natively supports multi-party settlements without requiring smart contracts.

2.4.3 Transition Validation Rules

A validator MUST apply the following checks to every transition, in order. If any check fails, the transition MUST be rejected with the specified error code.

1. VERSION_CHECK: transition.version MUST equal a supported protocol major version. Error: ERR_UNSUPPORTED_VERSION.

2. SIGNATURE_CHECK: The signature MUST be valid under the sender's public key over the canonical serialisation of all fields except the signature itself. Error: ERR_INVALID_SIGNATURE.

3. SEQUENCE_CHECK: transition.sequence MUST equal the sender's current sequence number + 1. Error: ERR_INVALID_SEQUENCE.

4. EXPIRY_CHECK: The current time MUST be less than transition.expiry. Error: ERR_EXPIRED.

5. BALANCE_CHECK: The committed amount + fee MUST be provably ≤ the sender's committed balance for the specified asset, using the homomorphic property. Error: ERR_INSUFFICIENT_BALANCE. (Details in SPEC-007.)

6. RANGE_CHECK: All range proofs MUST verify. This proves all amounts are non-negative and within the valid range [0, 2⁶⁴). Error: ERR_INVALID_RANGE_PROOF.

7. CONSERVATION_CHECK: The sum of recipient amount commitments + fee commitment MUST equal the sender's debited amount commitment. Formally: Σ(recipient.amount) + fee = amount. This is checked on the commitment points: Σ(C_recipient_i) + C_fee = C_amount. Error: ERR_CONSERVATION_VIOLATION.

8. CAUSAL_CHECK: Every hash in causal_deps MUST reference a transition that the validator has already processed and certified. Error: ERR_UNKNOWN_DEPENDENCY.

9. EQUIVOCATION_CHECK: The validator MUST NOT have previously signed a vote for a different transition with the same (sender, sequence) pair. If it has, this is an equivocation attempt. The validator MUST produce an equivocation proof (both conflicting transitions) and broadcast it. Error: ERR_EQUIVOCATION.

2.5 Settlement Certificates

A settlement certificate is cryptographic proof that a transition has been accepted by a quorum of validators and is therefore final.

2.5.1 Certificate Structure

struct SettlementCertificate {

transition_hash: Hash, // SHA3-256 of the certified transition

epoch: u64, // Validator set epoch (see SPEC-010)

votes: Vec<ValidatorVote>, // Votes from ≥ 2f+1 validators

}

struct ValidatorVote {

validator_id: PublicKey, // Voting validator's public key

signature: Signature, // Signature over (transition_hash || epoch)

}

A settlement certificate is valid if and only if: (a) it contains votes from at least 2f+1 distinct validators in the epoch's validator set, (b) all vote signatures are valid, and (c) no equivocation proof exists for the certified transition.

Settlement certificates are the fundamental unit of finality in MESH. Once a valid certificate exists for a transition, that transition is irreversible. Any participant can independently verify a certificate without contacting any validator. Certificates are transferable: a recipient can present a certificate to any third party as proof of payment.

2.6 The Causal Partial Order

Transitions in MESH are ordered by causality, not by time. Transition t₁ causally precedes transition t₂ (written t₁ ≺ t₂) if and only if at least one of the following holds:

10. t₂.causal_deps contains the hash of t₁ (direct dependency).

11. There exists a transition t₃ such that t₁ ≺ t₃ and t₃ ≺ t₂ (transitive closure).

12. t₁ and t₂ are on the same account and t₁.sequence < t₂.sequence (same-account ordering).

Two transitions t₁ and t₂ are concurrent (written t₁ || t₂) if neither t₁ ≺ t₂ nor t₂ ≺ t₁. Concurrent transitions on different accounts can be processed in any order or in parallel, because they do not affect each other's validity.

This causal structure forms a directed acyclic graph (DAG). The graded structure is defined by the rank function ρ(t) = 1 + max({ρ(d) : d ∈ t.causal_deps} ∪ {ρ(prev_t) : prev_t is the previous transition on the same account}), with ρ(genesis) = 0. The rank provides a natural "logical clock" for the system without requiring synchronised physical clocks.

2.7 The Value Semiring

The Value Semiring 𝕍 = (V, ⊕, ⊗, 0, 1) formalises multi-asset value operations:

• V is the set of all (amount: u128, asset_id: AssetID) pairs.

• ⊕ (aggregation): (a₁, id) ⊕ (a₂, id) = (a₁ + a₂, id). Only defined for same asset_id. Aggregation of different assets produces a ValueSet (multiset over V).

• ⊗ (exchange): (a, id₁) ⊗ rate = (a × rate.numerator / rate.denominator, id₂) where rate is an ExchangeRate from id₁ to id₂. This models currency conversion.

• 0: The zero value (0, any_id). Identity element for ⊕.

• 1: The identity exchange rate (numerator = denominator = 1, same asset). Identity element for ⊗.

The semiring axioms (associativity, commutativity, distributivity of ⊗ over ⊕, absorbing zero) guarantee that multi-hop payment path composition is well-defined and that value conservation can be verified algebraically. Implementers MUST use exact integer arithmetic (u128) for all value calculations. Floating-point arithmetic is PROHIBITED.

2.8 Serialisation

All structures are serialised using a deterministic binary encoding. The canonical serialisation is the input to all hash and signature operations. The encoding rules are:

13. Fixed-size fields are encoded in their natural byte representation (little-endian for integers).

14. Variable-length fields (Vec<T>) are encoded as: length (u32) || element₁ || element₂ || ... || elementₙ.

15. Optional fields are encoded as: presence_flag (u8, 0 or 1) || value (if present).

16. Structs are encoded as the concatenation of their fields in declaration order.

17. Maps are encoded as a sorted (by key) Vec of (key, value) pairs.

Implementers MUST produce identical byte sequences for identical data. The canonical serialisation of a structure S is denoted encode(S). The hash of a structure is hash(S) = SHA3-256(encode(S)).

SPEC-003: Tier 1 --- Consensusless Settlement Protocol

3.1 Purpose

This specification defines the protocol for simple settlements that do not require global transaction ordering. Tier 1 handles the common case of one-to-one and one-to-many payments where the sender is the sole owner of the transferred value. This is the fast path, designed for sub-300ms finality in retail payment scenarios.

Tier 1 is based on Byzantine Consistent Broadcast (Bracha, 1987). The key insight is that pre-funded, single-owner transfers do not require consensus because there is no shared state to agree on --- only the sender's balance needs to be checked, and the sender's account chain is single-writer.

3.2 Preconditions

A transition is eligible for Tier 1 processing if and only if ALL of the following hold:

18. The transition involves exactly one sender account.

19. The sender account has sufficient committed balance (verifiable via range proofs).

20. The transition does not depend on any uncommitted (pending) transition from a different account.

21. The transition does not involve conditional logic (no escrows, no time-locks beyond the standard expiry).

If any precondition is not met, the transition MUST be routed to Tier 2. The routing decision is made by the sender's wallet software, not by validators. A wallet that incorrectly routes a Tier-2-eligible transition to Tier 1 will receive rejection from validators (ERR_TIER1_INELIGIBLE).

3.3 Protocol Steps

The Tier 1 protocol consists of two phases: Vote Collection and Certificate Broadcast. The sender coordinates both phases.

3.3.1 Phase 1: Vote Collection

The sender constructs a valid Transition (per SPEC-002 §2.4) and sends it to all validators.

Message: VOTE_REQUEST

sender → all validators

payload: Transition

Upon receiving a VOTE_REQUEST, each correct validator vᵢ performs the following:

22. Apply all validation rules from SPEC-002 §2.4.3, in order.

23. If all checks pass, compute vote_signature = Sign(vᵢ.secret_key, transition_hash || current_epoch).

24. Send VOTE_RESPONSE(validator_id, vote_signature) to the sender.

25. Record (sender, sequence, transition_hash) in local state to enable equivocation detection.

If any validation rule fails, the validator sends VOTE_REJECT(error_code, error_detail) to the sender. The validator MUST NOT sign a vote for a transition that fails any check.

CRITICAL: Step 4 is the equivocation lock. Once a validator has voted for transition t with (sender, sequence) = (A, 42), it MUST NOT vote for any other transition t′ with the same (A, 42). If it receives such a request, it MUST respond with ERR_EQUIVOCATION and broadcast an equivocation proof.

3.3.2 Phase 2: Certificate Assembly and Broadcast

The sender collects VOTE_RESPONSE messages. Once the sender has 2f+1 valid votes from distinct validators, it assembles a SettlementCertificate.

Message: SETTLEMENT_CERTIFICATE

sender → all validators

payload: SettlementCertificate

Upon receiving a SETTLEMENT_CERTIFICATE, each correct validator:

26. Verifies the certificate contains ≥ 2f+1 valid, distinct votes for the referenced transition hash.

27. Verifies that all vote signatures are valid under the respective validator public keys in the current epoch's validator set.

28. Applies the transition to its local state: debits the sender's committed balance, credits each recipient's committed balance, increments the sender's sequence number.

29. Stores the certificate and its transition as part of the permanent record.

After step 3, the transition is final. The sender's balance has been irrevocably reduced and the recipient's balance has been irrevocably increased. There is no rollback mechanism.

3.3.3 Recipient Notification

Recipients learn of incoming payments by one of the following mechanisms:

• Push notification: Validators MAY push SETTLEMENT_CERTIFICATE messages to the recipient if the recipient is online and connected to the validator.

• Pull query: Recipients MAY poll validators for new certificates addressed to their public key (or stealth addresses --- see SPEC-007).

• Out-of-band: The sender MAY transmit the certificate directly to the recipient via any channel (QR code, NFC, Bluetooth, messaging app).

The recipient does not need to be online during the settlement. Certificates are persistent and can be claimed at any time. However, a recipient MUST submit a Receive transition (with the certificate as a causal dependency) to update their account state and make the received funds spendable.

3.4 Timing Analysis

Under normal network conditions (after GST), the protocol completes in:

---

Step Duration Cumulative

Sender → Validators RTT/2 (≈50ms 50ms (VOTE_REQUEST) intra-continental)

Validator processing + ≈10ms per transition 60ms signing

Validators → Sender RTT/2 (≈50ms) 110ms (VOTE_RESPONSE)

Sender assembles <1ms 111ms certificate

Sender → Validators RTT/2 (≈50ms) 161ms (CERTIFICATE)

Validator applies ≈10ms 171ms transition

---

Total wall-clock time from initiation to finality: approximately 170ms intra-continental. This is well below the 300ms threshold required for contactless payment terminals and comparable to current card network authorisation times.

The sender does not need to wait for all 2f+1 responses; it needs only the fastest 2f+1. With n validators geographically distributed, the effective latency is the (2f+1)-th order statistic of the RTT distribution, not the maximum.

3.5 Equivocation Handling

An equivocation occurs when a Byzantine sender attempts to issue two different transitions with the same sequence number, sending each to a different subset of validators.

3.5.1 Detection

If a validator vᵢ receives a VOTE_REQUEST for transition t′ with (sender, sequence) = (A, k), but has already voted for a different transition t with the same (A, k), then vᵢ constructs an equivocation proof:

struct EquivocationProof {

transition_1: Transition, // First observed transition

transition_2: Transition, // Conflicting transition

detector: PublicKey, // Validator that detected equivocation

detector_sig: Signature, // Validator's signature over the proof

}

3.5.2 Propagation

The detecting validator broadcasts the EquivocationProof to all other validators. Upon receiving a valid equivocation proof, every correct validator:

30. Rejects both transitions permanently for this (sender, sequence) pair.

31. Revokes any vote previously issued for either transition.

32. Stores the equivocation proof as permanent evidence.

An equivocating account's funds are not lost but are frozen at the last known-good state. The account owner must submit a new transition with the correct sequence number (skipping the equivocated one) to resume operations. The protocol MAY impose a cooldown penalty (SPEC-010).

3.6 Sharding

Tier 1 supports horizontal sharding because each account is independent. A validator MAY partition its accounts across multiple machines (shards), each handling a disjoint subset of accounts. The partitioning function is: shard_id = hash(account_pubkey) mod num_shards.

Shards operate independently --- they share no state. A settlement between accounts on different shards requires the sender to contact validators on the sender's shard only (because only the sender's balance and sequence number are checked). The recipient's shard learns about the settlement when the certificate is presented.

This means throughput scales linearly with the number of shards. A validator with 16 shards across 16 machines can handle 16× the throughput of a single machine, with no coordination overhead.

SPEC-006: Cryptographic Primitives and Cipher Suites

6.1 Purpose

This specification defines all cryptographic operations used by the MESH protocol. All implementations MUST use the exact algorithms, parameters, and encodings specified here. Deviations will produce incompatible signatures and proofs, causing interoperability failures.

MESH uses a cipher suite abstraction that allows the protocol to upgrade cryptographic primitives without changing the protocol logic. Each cipher suite is a complete, internally consistent set of cryptographic algorithms.

6.2 Cipher Suite 0 (Launch Suite)

Cipher Suite 0 is the mandatory-to-implement suite for the initial protocol launch. It uses well-established, patent-free cryptographic primitives.

---

Operation Algorithm

Digital Signatures Ed25519 (RFC 8032). Curve: Curve25519. Key size: 32 bytes. Signature size: 64 bytes.

Key Agreement X25519 (RFC 7748). Ephemeral ECDH for session key establishment.

Hash Function SHA3-256 (FIPS 202). Output: 32 bytes. Used for all content hashing.

Extendable Output SHAKE256 (FIPS 202). Used for key derivation and domain separation.

Symmetric Encryption ChaCha20-Poly1305 (RFC 8439). For memo encryption and transport layer.

Commitment Scheme Pedersen Commitments over Curve25519. C = vG + bH. See SPEC-007.

Range Proofs Bulletproofs+ over Curve25519. See SPEC-007.

KDF HKDF-SHA3-256 (adapted from RFC 5869 using SHA3-256).

---

6.3 Cipher Suite 1 (Post-Quantum Hybrid)

Cipher Suite 1 adds post-quantum algorithms in a hybrid configuration. Security holds if either the classical or PQ assumption is unbroken. This suite is OPTIONAL for launch and MUST be supported within 18 months of mainnet.

---

Operation Algorithm

Digital Signatures Ed25519 || ML-DSA-65 (FIPS 204). Hybrid: both signatures are computed and concatenated. Verification requires BOTH to be valid. Combined signature size: 64 + 3309 = 3373 bytes.

Key Encapsulation X25519 || ML-KEM-768 (FIPS 203). Hybrid KEM: shared secret = HKDF(X25519_secret || ML-KEM_secret). Combined ciphertext: 32 + 1088 = 1120 bytes.

Hash Function SHA3-256 (unchanged --- already quantum-resistant).

Hash-based Signatures SLH-DSA-SHA2-128f (FIPS 205). Used for (fallback) long-term keys where signature size is less critical.

Backup KEM HQC-128 (NIST 5th standard). Used as secondary KEM for cryptographic diversity.

---

6.4 Key Formats

6.4.1 Account Key Pair

Each account has a single key pair used for signing transitions and receiving stealth payments.

struct AccountKeyPair {

secret_key: [u8; 32], // Ed25519 secret seed

public_key: [u8; 32], // Ed25519 public key = ScalarBaseMult(secret_key)

view_key: [u8; 32], // For stealth address scanning (see SPEC-007)

}

The view_key is derived deterministically: view_key = HKDF-SHA3-256(secret_key, salt="mesh-view-key", info="", length=32). The view_key allows a third party (e.g., a watch-only wallet) to detect incoming payments without the ability to spend them.

6.4.2 Validator Key Pair

Each validator has a signing key pair for voting on transitions. Validators MUST use threshold key generation (SPEC-010) so that no single ceremony participant knows the full secret key.

6.5 Domain Separation

All hash and signature operations MUST use domain separation to prevent cross-protocol attacks. The domain separator is a fixed-length prefix prepended to the input:

hash_transition = SHA3-256("MESH-TRANSITION-V0" || encode(transition))

hash_certificate = SHA3-256("MESH-CERTIFICATE-V0" || encode(certificate))

hash_equivocation = SHA3-256("MESH-EQUIVOCATION-V0" || encode(proof))

sign_vote = Sign(key, "MESH-VOTE-V0" || transition_hash || epoch)

Domain separators are ASCII strings, NOT null-terminated, and are NOT length-prefixed (their length is fixed per domain). If a new domain is added in a future version, it MUST use a unique prefix.

6.6 Cipher Suite Negotiation

During transport-layer handshake (SPEC-009), peers exchange their supported cipher suites ordered by preference. The highest-preference suite supported by both peers is selected. If no common suite exists, the connection MUST be rejected.

All validators MUST support Suite 0. Suite 0 MUST remain supported for at least 5 years after Suite 1 becomes mandatory, to allow migration. A validator MAY support multiple suites simultaneously and process transitions from accounts using different suites.

An account's cipher suite is determined by the format of its public key. Suite 0 keys are 32 bytes. Suite 1 keys are 32 + 1952 = 1984 bytes (Ed25519 pubkey || ML-DSA-65 pubkey). The first byte of the key encoding indicates the suite version.

6.7 Constant-Time Requirements

All cryptographic operations that process secret data MUST be implemented in constant time. Specifically:

• Signature generation MUST NOT have data-dependent branches or memory access patterns.

• Key comparison MUST use constant-time byte comparison (e.g., subtle::ConstantTimeEq in Rust).

• Commitment generation and range proof computation MUST NOT leak the committed value through timing.

Implementations MUST be validated against timing side-channels using tools such as dudect or ctgrind. The formal verification effort (SPEC-010 §10.8) SHOULD include verification of constant-time properties at the assembly level.

SPEC-007: Privacy Layer

7.1 Purpose

This specification defines the privacy mechanisms that make settlement amounts and participant identities confidential by default. Every transition in MESH uses the mechanisms defined here. There is no "transparent mode" --- privacy is not optional.

7.2 Pedersen Commitments

All value amounts in MESH are represented as Pedersen commitments rather than plaintext integers. A Pedersen commitment to value v with blinding factor b is:

C = v·G + b·H

where G is the Ed25519 base point and H is a secondary generator point. The point H MUST be generated via a nothing-up-my-sleeve construction:

H = HashToCurve(SHA3-256("MESH-PEDERSEN-H-V0"))

using the hash-to-curve method specified in RFC 9380 (Elligator 2 for Curve25519). The discrete logarithm of H with respect to G is unknown and computationally infeasible to determine. This ensures the binding property: no one can open a commitment to a different value.

7.2.1 Commitment Operations

Pedersen commitments are additively homomorphic:

• Addition: Commit(v₁, b₁) + Commit(v₂, b₂) = Commit(v₁ + v₂, b₁ + b₂). This allows validators to verify that inputs equal outputs by checking that the sum of input commitments equals the sum of output commitments + fee commitment.

• Subtraction: Commit(v₁, b₁) - Commit(v₂, b₂) = Commit(v₁ - v₂, b₁ - b₂). Used for balance verification.

• Scalar multiplication: k · Commit(v, b) = Commit(k·v, k·b). Used for exchange rate application.

Validators perform conservation checks entirely on commitment points. They never learn the underlying values.

7.2.2 Blinding Factor Management

The sender MUST generate a fresh, cryptographically random blinding factor for every commitment. Blinding factors MUST be generated from a CSPRNG seeded with at least 256 bits of entropy. Reusing blinding factors across commitments leaks information about the committed values.

The sender MUST transmit the blinding factor to the recipient (encrypted with the recipient's public key) so the recipient can verify and spend the received funds. The blinding factor is included in the encrypted memo field of the transition.

7.3 Bulletproofs+ Range Proofs

A Pedersen commitment hides the value but does not prevent negative values. Without range proofs, a malicious sender could commit to a negative amount, effectively creating value from nothing. Bulletproofs+ range proofs prove that a committed value lies in [0, 2⁶⁴) without revealing the value.

7.3.1 Parameters

---

Parameter Value

Curve Curve25519 (Ristretto group for Bulletproofs+)

Range [0, 2⁶⁴). All amounts are unsigned 64-bit integers in base units.

Proof size (single) Approximately 576-672 bytes depending on the number of range statements.

Aggregation Multiple range proofs in a single transition SHOULD be aggregated into a single proof. Aggregated proof size is O(log₂(n · 64)) group elements.

Proving time Target: < 500ms on a 2020-era mobile SoC (ARM Cortex-A78 or equivalent).

Verification time Target: < 10ms per proof on validator hardware.

---

7.3.2 Proof Generation

The sender generates a Bulletproofs+ range proof for each committed amount using the Fiat-Shamir heuristic for non-interactivity. The transcript MUST include the following domain-separated inputs, in order:

33. The domain separator: "MESH-BP+-V0".

34. The commitment point C (32 bytes, compressed Ristretto).

35. The transition hash (32 bytes) --- binds the proof to the specific transition.

Implementations MUST use the Merlin transcript protocol for Fiat-Shamir challenges, as specified in the dalek-cryptography Bulletproofs library documentation. The proof encoding follows the dalek format: 2·⌈log₂(64)⌉ + 2 curve points + 3 scalars.

7.4 Stealth Addresses

Stealth addresses prevent observers from linking payments to a recipient's long-term public key.

7.4.1 Protocol

To send a payment to recipient with public key P_recipient and view key V_recipient:

36. Sender generates an ephemeral key pair: (r, R = r·G).

37. Sender computes shared secret: S = HKDF(r · V_recipient, salt="mesh-stealth", length=32).

38. Sender computes one-time stealth address: P_stealth = P_recipient + SHA3-256(S)·G.

39. Sender addresses the transition to P_stealth and includes R (the ephemeral public key) in the encrypted memo.

To detect incoming payments, the recipient (or a delegated scanner with the view key):

40. For each new transition with recipient P_stealth and ephemeral key R:

41. Compute S = HKDF(view_key · R, salt="mesh-stealth", length=32).

42. Compute P_expected = P_recipient + SHA3-256(S)·G.

43. If P_expected == P_stealth, this payment is for us. The spending key for this stealth address is: s_stealth = s_recipient + SHA3-256(S), where s_recipient is the recipient's secret key.

7.5 Selective Disclosure

When a participant needs to prove properties of their transactions to a third party (auditor, tax authority, counterparty), they generate a zero-knowledge proof that reveals only the required information.

Example disclosure types:

• Balance proof: "My balance in asset X is at least Y." Proven by opening a range proof on the current balance commitment with a lower bound.

• Transaction history proof: "My total outgoing transfers in period [t₁, t₂] were Z." Proven by aggregating commitments from the relevant transitions and opening the aggregate.

• Counterparty proof: "I paid entity E exactly amount A on date D." Proven by revealing the blinding factor for a specific transition to the verifier.

Selective disclosure proofs are generated client-side by the disclosing party. Validators are not involved. The proofs are standard Schnorr proofs of knowledge of the opening of Pedersen commitments, which are straightforward to implement and verify.

SPEC-008: Value Routing and Exchange

8.1 Purpose

This specification defines how value is routed across multiple hops and exchanged between different asset types. This is the currency-agnostic layer that enables MESH to settle any form of value without being tied to a specific currency.

8.2 The MESH Packet

Inspired by the Interledger Protocol (ILPv4), MESH routes value in small packets. Each packet is an independent, atomic unit of value transfer.

8.2.1 Packet Structure

struct MeshPacket {

version: u8,

packet_type: PacketType, // enum: Prepare, Fulfill, Reject

destination: Address, // MESH address of final recipient

amount: u128, // Amount in the destination asset's base units

source_asset: AssetID, // Asset being sent

dest_asset: AssetID, // Asset to be received

condition: Hash, // PTLC condition (point, not hash --- see §8.4)

expiry: u64, // Unix timestamp

data: [u8; 32768], // End-to-end encrypted data (opaque to connectors)

}

8.3 Addressing

MESH uses a hierarchical address scheme inspired by IP addresses and ILP addresses:

mesh.<network>.<connector>.<account>

Examples:

• mesh.mainnet.au-bank-connector.alice --- Alice's account via an Australian bank connector

• mesh.mainnet.solar-exchange.grid42 --- Energy grid account via a solar exchange connector

Connectors route packets based on address prefixes, similar to IP routing tables. A connector that handles the prefix mesh.mainnet.au-bank-connector will accept packets addressed to any account under that prefix.

8.4 Point Time-Locked Contracts (PTLCs)

MESH uses PTLCs instead of HTLCs for atomic multi-hop settlement. PTLCs use adaptor signatures rather than hash preimages, providing two critical privacy improvements:

44. No correlation: In HTLCs, the same hash preimage is used across all hops, allowing any observer to link hops in the same payment. In PTLCs, each hop uses a different adaptor point, making hops unlinkable.

45. Scriptless: PTLCs do not require the underlying settlement layer to support hash locks or any scripting. They work with plain Schnorr signatures, which are supported in Suite 0.

8.4.1 PTLC Construction

Setup: Sender Alice wants to pay Recipient Bob through Connector Charlie.

46. Alice generates a random secret scalar s and computes the corresponding point Y = s·G.

47. Alice sends a Prepare packet to Charlie with condition Y.

48. Charlie generates a new random scalar s′ and computes Y′ = s′·G + Y (his adaptor is offset from Alice's).

49. Charlie sends a Prepare packet to Bob with condition Y′.

50. Bob knows the expected Y′ (communicated by Alice out-of-band in the encrypted data field). Bob computes the adaptor signature under Y′ and sends a Fulfill to Charlie.

51. Charlie uses Bob's adaptor signature to recover s′, then computes the adaptor signature under Y for Alice. Charlie sends Fulfill to Alice.

52. Alice uses Charlie's adaptor signature to recover s, confirming the payment completed.

At each hop, the adaptor point is different, so an observer who sees the (Charlie → Bob) hop cannot link it to the (Alice → Charlie) hop. The math ensures atomicity: either all hops complete (everyone learns their respective secrets) or none do (timeouts expire and funds are refunded).

8.5 Packet Splitting

Large payments are split into small packets to minimise per-packet risk:

• Default packet size: Configurable per connector, recommended default: 1000 base units of the source asset (~$10 AUD at standard precision).

• Parallelism: Multiple packets MAY be sent simultaneously along different paths.

• Retry: If a packet is rejected (Reject response), the sender MAY retry on a different path.

• Completion: The payment is complete when the sender has received Fulfill for all packets. Partial completion is possible (some packets fulfilled, others expired). The sender's wallet is responsible for retrying or notifying the user.

The recipient's wallet MUST be able to reconstruct the total payment from individual packets. The sender includes a payment_id and packet_index in the encrypted end-to-end data of each packet.

8.6 On-Ramp and Off-Ramp

Value enters and exits the MESH network through on-ramp and off-ramp connectors. These are connectors that bridge between MESH and external settlement systems (bank accounts, card networks, mobile money, blockchains).

8.6.1 On-Ramp Protocol

53. User deposits value into the on-ramp connector's external account (e.g., bank transfer).

54. On-ramp connector verifies the deposit on the external system.

55. On-ramp connector initiates a Tier 1 settlement crediting the user's MESH account with the corresponding committed amount.

56. The on-ramp transition includes a reference to the external deposit (e.g., bank transaction ID) in the causal_deps field (as an opaque hash) for auditability.

On-ramp connectors are trust points: the user must trust the connector to honour deposits. This is analogous to trusting a bank with a deposit. The MESH protocol does not eliminate this trust requirement --- it minimises it by making the on-ramp the only point where external trust is needed.

8.6.2 Off-Ramp Protocol

57. User initiates a settlement to the off-ramp connector's MESH account.

58. Off-ramp connector receives the settlement certificate.

59. Off-ramp connector initiates the external transfer (e.g., bank transfer to user's bank account).

60. Off-ramp connector provides the user with an external settlement proof (e.g., bank transaction confirmation).

The off-ramp connector bears counterparty risk: it has already received value on MESH and must honour the external transfer. Connectors manage this risk through reputation, insurance, or regulatory compliance.

SPEC-010: Validator Operations and Governance

10.1 Purpose

This specification defines validator lifecycle management, the governance model for protocol upgrades, the fee model, and the formal verification requirements. Validators are the infrastructure backbone of MESH. This spec ensures validators are incentivised, accountable, and replaceable.

10.2 Validator Set

The validator set is the set of public keys authorised to vote on settlements. It is defined per epoch.

10.2.1 Epochs

An epoch is a period during which the validator set is fixed. Epoch duration is a governance parameter; the recommended initial value is 24 hours. At each epoch boundary:

61. The new validator set is computed based on the governance protocol's decisions.

62. Validators perform a distributed key generation (DKG) ceremony to produce new threshold signing keys.

63. The new epoch is activated when 2f+1 validators have confirmed readiness.

10.2.2 Initial Validator Set

The genesis epoch's validator set is hardcoded in the protocol specification. It consists of 7 validators operated by the founding organisations. This is an acknowledged centralisation point that is mitigated by:

• A public commitment to expand to 21 validators within 12 months of mainnet launch.

• A public commitment to transition to reputation-based entry within 36 months.

• All validator software, keys (public), and operational procedures are published.

• Any single founding validator can be removed by a 5/7 vote of the remaining validators.

10.3 Fee Model

Validators are compensated through per-settlement fees paid by the sender. Fees are denominated in the settlement's asset type (not in a native token).

10.3.1 Fee Structure

The fee for a Tier 1 settlement is: fee = max(base_fee, amount × fee_rate), where:

• base_fee: Minimum fee per settlement. Governance parameter. Recommended initial value: equivalent of $0.001 AUD.

• fee_rate: Proportional fee rate. Governance parameter. Recommended initial value: 0.001% (1 basis point).

Tier 2 settlements pay 2× the Tier 1 fee (to reflect the higher resource cost of consensus). Tier 3 settlements pay 3×.

Fees are committed (Pedersen commitment) just like amounts. Validators verify the fee meets the minimum using range proofs but do not learn the exact amount. Fee revenue is distributed equally among all validators in the epoch.

10.4 Governance Protocol

Protocol changes follow a structured process:

10.4.1 MESH Improvement Proposals (MIPs)

64. Draft: Anyone may submit a MIP to the public repository. MIPs must include: motivation, specification changes (in the format of this document suite), backward compatibility analysis, security analysis, and formal verification plan.

65. Review: Minimum 30-day public review period. All feedback must be addressed in writing.

66. Formal Verification: For any MIP affecting Tier 1, 2, or 3 protocols, the changed properties must be re-verified in TLA+ and/or Tamarin. Proof artifacts must be published.

67. Validator Vote: 2/3 supermajority of the current validator set must vote to accept. Voting is on-chain (a Tier 2 settlement to a governance contract address).

68. Activation: Accepted MIPs are activated at the next epoch boundary (or a specified future epoch). Validators that have not upgraded by activation are automatically excluded from the new epoch's validator set.

10.5 Key Management

Validator signing keys are generated using a distributed key generation (DKG) protocol. The DKG ensures:

• No single party ever knows the full signing key.

• Any t-of-n subset of validators can produce a valid signature (threshold t = 2f+1).

• The key generation ceremony is verifiable: all participants can confirm the output is correct.

The specific DKG protocol is Pedersen's DKG (1991) with Feldman's VSS (1987) for verifiability. These are patent-free, well-studied protocols with existing open-source implementations.

10.6 Formal Verification Requirements

The following properties MUST be formally verified before mainnet launch. "Formally verified" means: a machine-checked proof exists in a published proof artifact, using one of the specified tools, and the proof artifact is reproducible from source.

---

Property Tool Scope

No double-spend (SAFETY-1) TLA+ (TLC model Tier 1 protocol state checker) machine, up to 5 validators, 3 accounts

Value conservation TLA+ Tier 1 and Tier 2 (SAFETY-2) settlement paths

Liveness (LIVENESS-1) TLA+ Tier 1 protocol, partial synchrony model

Signature unforgeability Tamarin Prover Ed25519 signing/verification protocol

Commitment binding Tamarin Prover Pedersen commitment scheme

PTLC atomicity Tamarin Prover Two-hop PTLC construction

Stealth address ProVerif Stealth address unlinkability generation and detection protocol

Key secrecy (DKG) Tamarin Prover Distributed key generation ceremony

---

For each entry in this table, the verification MUST cover: (a) the stated property holds under the threat model (SPEC-001 §1.4.2), (b) the property is violated if the threat model assumptions are weakened (sanity check), and (c) the proof artifact is published alongside the specification.

Verification of the implementation (as opposed to the protocol model) is a continuous process. The reference implementation MUST pass all test vectors derived from the formal models. Property-based testing (e.g., using proptest in Rust) MUST cover at least 90% of the protocol state space as measured by state coverage analysis.

10.7 Test Vectors

Each specification MUST include a set of test vectors: known input/output pairs that any conformant implementation MUST produce identically. Test vectors are provided as JSON files in the protocol repository under /test-vectors/{spec-id}/. At minimum, each specification requires:

• 10 positive test vectors (valid inputs that must be accepted).

• 10 negative test vectors (invalid inputs that must be rejected with the specified error code).

• 5 edge case vectors (boundary conditions, maximum values, empty collections).

Test vector files include: the input data (hex-encoded), the expected output (hex-encoded), and a human-readable description of what the test verifies.

Document Control

Revision History

---

Version Date Author Description

0.1.0 2026-03-09 MESH Foundation Initial draft. Specifications 001, 002, 003, 006, 007, 008, 010.

---

Outstanding Items

• SPEC-004 (Tier 2 DAG-BFT): Draft in progress. Requires clean-room protocol synthesis from academic literature.

• SPEC-005 (Tier 3 aBFT): Draft in progress. Protocol selection pending performance benchmarking.

• SPEC-009 (Network Transport): Draft in progress. Wire protocol and peer discovery.

• Test vectors: To be generated after reference implementation reaches alpha.

• Formal verification artifacts: TLA+ models in progress for SPEC-003.

References

• Bracha, G. (1987). Asynchronous Byzantine agreement protocols. Information and Computation, 75(2), 130-143.

• Baudet, M., Danezis, G., Sonnino, A. (2020). FastPay: High-Performance Byzantine Fault Tolerant Settlement. ACM AFT 2020.

• Bünz, B., Bootle, J., Boneh, D., Poelstra, A., Wuille, P., Maxwell, G. (2018). Bulletproofs: Short Proofs for Confidential Transactions and More. IEEE S&P 2018.

• Bünz, B., Agrawal, S., Zamani, M., Boneh, D. (2020). Bulletproofs+. Crypto 2020.

• FIPS 202: SHA-3 Standard. NIST, 2015.

• FIPS 203: ML-KEM. NIST, 2024.

• FIPS 204: ML-DSA. NIST, 2024.

• FIPS 205: SLH-DSA. NIST, 2024.

• RFC 8032: Edwards-Curve Digital Signature Algorithm (EdDSA).

• RFC 8439: ChaCha20 and Poly1305 for IETF Protocols.

• RFC 9380: Hashing to Elliptic Curves.

• Thomas, S., Schwartz, E. (2015). Interledger Protocol (ILP). W3C Community Group.

• Pedersen, T.P. (1991). Non-Interactive and Information-Theoretic Secure Verifiable Secret Sharing. CRYPTO 1991.

• Feldman, P. (1987). A practical scheme for non-interactive verifiable secret sharing. FOCS 1987.