f2d62fa03d
Rust workspace with 5 crates (mesh-types, mesh-crypto, mesh-network, mesh-validator, mesh-wallet), PROJECT_CONSTITUTION.md for CHORUS automated ingestion, and the full MESH protocol specification suite. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
1506 lines
56 KiB
Markdown
1506 lines
56 KiB
Markdown
**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.
|