# Ledger Chat: Messaging and Private Payments on Aztec Network

**URL:** <https://forum.aztec.network/t/ledger-chat-messaging-and-private-payments-on-aztec-network/8702>\
**Category:** Aztec\
**Tags:** noir, wallets\
**Created:** [November 6, 2026, 6:24am UTC](https://forum.aztec.network/t/ledger-chat-messaging-and-private-payments-on-aztec-network/8702 "2026-11-06T06:24:18Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![atfortyseven](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.aztec.network/atfortyseven/32/3021_2.png) [@atfortyseven](https://forum.aztec.network/u/atfortyseven)\
**Post date:** [November 6, 2026, 6:24am UTC](https://forum.aztec.network/t/ledger-chat-messaging-and-private-payments-on-aztec-network/8702/1 "2026-11-06T06:24:18Z")

</div>

# Ledger Chat: Architecture for Messaging Layer Security and Zero-Knowledge Confidential State Settlement on the Aztec Network

**Lead Architect:** Stefan Antonio Cirisanu

**Operations & Governance:** Oprișan Elena-Grațiela

**Institutional Registry:** [Humanity Ledger](https://es.linkedin.com/company/humanity-ledger)  
**Target Repository:** [github.com/humanityledger/Humanity-Ledger](https://github.com/humanityledger/Humanity-Ledger)  
**Evaluated Snapshot:** Commit `20ffc2b5c777418933b43a99263a23d06112a970`  
**Target Runtimes:** Aztec SDK v6.0.0 (_“Tierra”_), L1 Chain ID `1`, Rollup ID `2070860440`, Aztec Alpha L2  
**Peer Review:** Aztec Labs Core Cryptography & Engineering Teams (@zac-williamson, @koenmtb1, @spalladino, @jaosef)

* * *

### Executive Abstract

This specification formalizes the systems architecture, cryptographic invariants, and security definitions of **Humanity Ledger** and its primary client implementation, **Ledger Chat** , as implemented at commit `20ffc2b5`.

The protocol couples **IETF RFC 9420 Messaging Layer Security (MLS)** with in-browser **Private Execution Environments (PXE)** executing over the **Aztec Network** (SDK v6.0.0).

By executing zero-knowledge witness generation and UltraHonk polynomial IOP proving locally inside client Web Workers (`@aztec/bb.js`), sensitive preimage state never transits network interfaces.

Persistent storage at rest is secured via authenticated encryption over the Origin Private File System (OPFS) SQLite engine, keyed by asymmetric signature-derived pseudorandom functions (`HKDF-SHA256`). On-chain state transitions including conditional multi-party escrows, rate-bounded continuous payment streams, and zero-knowledge sanctions screening are enforced through native `aztec-nr` smart contracts.

Gas abstraction is provided through the canonical **Fee Juice** settlement architecture on Aztec Alpha.

We prove the linearizability of message revocations, define protocol invariants across adversarial network models, and document empirical verification across **1,452 unit and adversarial tests** spanning **102 test suites** with zero compiler diagnostics.

* * *

```plaintext
                                      HUMANITY LEDGER
  +---------------------------------------------------------------------------------------------------------+
  | Client Terminal Execution Boundary (Web Worker Sandboxed Runtime) |
  | |
  | +---------------------------+ +-------------------------------+ +---------------------------------+ |
  | | Identity Layer | | Asynchronous Comms Engine | | Embedded Aztec PXE Instance | |
  | | - EIP-4361 SIWE Trust Root| | - IETF RFC 9420 MLS (TreeKEM) | | - WASM UltraHonk Prover (bb.js) | |
  | | - Schnorr (ask, P) in Grp | | - AES-256-GCM Audio Payload | | - Note / Nullifier Witness Calc | |
  | | - Local Enclave PIN Gate | | - WebRTC DTLS-SRTP P2P Media | | - OPFS Encrypted SQLite Store | |
  | | - Volatile Memory Zeroize | | - Anti-Replay Linear Erasure | | - HKDF-SHA256 Key Derivation | |
  | +---------------------------+ +-------------------------------+ +---------------------------------+ |
  +---------------------------------------------------------------------------------------------------------+
                    | |
                    | Transport Envelopes | Private Witness / UltraHonk Proof
                    v v
  +-----------------------------------------+ +-----------------------------------------+
  | Untrusted Transport Relays | | Aztec Alpha Network (L2 Rollup) |
  | - MLS Ingestion Queues (XMTP Network) | | - Rollup Version: 2070860440 |
  | - ICE / STUN Signaling Nodes | | - Sequencer & Decentralized Prover Pool |
  | (Zero Preimage Access / E2EE Payloads) | | - Note Hash, Nullifier & Public Trees |
  +-----------------------------------------+ +-----------------------------------------+
                                                                                      |
                                                                                      | L1 Bridge Cross-Messaging
                                                                                      v
                                                                  +-----------------------------------------+
                                                                  | Ethereum L1 Base Verification |
                                                                  | - Fee Juice Portal: 0x534361...f3b3 |
                                                                  | - Fee Juice Token: 0xA27EC0...62D2 |
                                                                  +-----------------------------------------+

```

* * *

## 1. Primitives

Throughout this document, security parameters adhere to the standard concrete security bounds of the BN254 (alt\_bn128) pairing-friendly elliptic curve and its embedded cycle companion curve, Grumpkin.

\mathbb{F}\_{p}: \text{BN254 Base Field}, \quad p = 21888242871839275222246405745257275088696311157297823662689037894645226208583

\mathbb{F}\_{r}: \text{BN254 Scalar Field (Order of } \mathbb{G}\_{1} \text{ and } \mathbb{G}\_{2}\text{)}, \quad r = 21888242871839275222246405745257275088548364400416034343698204186575808495617

\mathbb{G}\_{1} \subset E(\mathbb{F}\_{p}): y^2 = x^3 + 3, \quad \mathbb{G}\_{2} \subset E'(\mathbb{F}\_{p^2}): y^2 = x^3 + \frac{3}{9 + i}

- **Grumpkin Curve (\mathbb{E}\_{\text{Grumpkin}}):** y^2 = x^3 - 17, defined over \mathbb{F}\_{r}, having order p. Used for native, in-circuit Schnorr account signatures where base field arithmetic corresponds directly to the scalar field \mathbb{F}\_{r} of BN254.

- **Algebraic & Cryptographic Hash Functions:**

* * *

## 2. Threat Model & Security Definitions

### 2.1 Adversary Modeling

We formalize protocol soundness under three distinct adversarial classes:

1. **Active Network Adversary (\mathcal{A}\_{\text{net}}):** Controls network transport (injection, drop, reorder, and TLS interception). \mathcal{A}\_{\text{net}} is computationally bounded by 2^{128} operations.
  - _Security Property:_ \mathcal{A}\_{\text{net}} learns neither the plaintexts of communication payloads (governed by MLS TreeKEM) nor the values, senders, or recipients of private on-chain state transitions.

2. **Semi-Honest Infrastructure Operator (\mathcal{A}\_{\text{node}}):** Models sequencers, block proposers, and JSON-RPC node operators.
  - _Security Property:_ \mathcal{A}\_{\text{node}} observes public gas consumption parameters and the identity of the Fee Juice payer (see §7), but cannot recover note preimages, compute secret keys from nullifiers, or link disjoint private state interactions.

3. **Local Endpoint Intruder (\mathcal{A}\_{\text{host}}):** Possesses non-volatile memory or cold-storage access to the user device after process termination.
  - _Security Property:_ Unauthenticated extraction of historical state from persistent stores is computationally infeasible without the root signature S\_{\text{session}} or the Enclave PIN.

### 2.2 Formal Security Definitions

- **Definition 1 (Forward Secrecy - FS):** Compromise of epoch t state keys does not expose payloads transmitted in epochs \tau \< t.
- **Definition 2 (Post-Compromise Security - PCS):** Injection of an uncompromised ratcheted key update in epoch t restores confidential integrity for all subsequent epochs \tau \> t, even if the adversary fully possessed state at epoch t-1.
- **Definition 3 (Note Soundness):** A private note commitment C \in \mathbb{F}\_{r} cannot be nullified without explicit knowledge of the nullifier secret key nsk \in \mathbb{F}\_{r} and a valid inclusion proof \pi\_{\text{Merkle}} against the canonical historical Note Hash Tree root \mathcal{R}\_{\text{note}}.

* * *

## 3. Cryptographic Architecture

### 3.1 Trust-Root Derivation & Key Hierarchy

The protocol eliminates centralized credential management by establishing the user’s secp256k1 Ethereum key as a master entropy root:

```plaintext
[Entropy: EIP-4361 SIWE Signature]
                     |
                     v
   HKDF-Extract(salt = "humanity-ledger/entropy/v1", IKM = sig)
                     |
        +------------+------------+
        | |
        v v
 [Aztec Account ask] [Encrypted Keystore KDF]
   ask in Fr (Grumpkin) StoreKey in {0,1}^256
        | |
        v v
   P = ask * G openEncryptedEmbeddedStores
   (Schnorr Signatures) (OPFS SQLite Ciphersuite)

```

1. **Authentication Message (M\_{\text{SIWE}}):** Formatted per EIP-4361, binding the human-readable domain `ledgerchat.org`, standard cryptographic nonces, and session lifetimes.
2. **Key Material Decomposition:**
\text{PRK} = \text{HKDF-Extract}\left(\text{"humanity-ledger/aztec-seed/v1"}, \; \text{Sign}\_{\text{secp256k1}}\left(M\_{\text{SIWE}}\right)\right)

  - **Account Private Key (ask):** Derived via \text{HKDF-Expand}(\text{PRK}, \text{"aztec/ask"}, 32) \pmod r.
  - **Public Account Coordinates:** P = (P\_{x}, P\_{y}) = ask \cdot G \in \mathbb{E}\_{\text{Grumpkin}}(\mathbb{F}\_{r}).
  - **Nullifier Secret (nsk):** Derived via \text{HKDF-Expand}(\text{PRK}, \text{"aztec/nsk"}, 32) \pmod r.
  - **Incoming Viewing Key (ivsk):** Derived via \text{HKDF-Expand}(\text{PRK}, \text{"aztec/ivsk"}, 32) \pmod r.

### 3.2 Ephemeral Keystore Zeroization (`purgeEphemeralKeys`)

To mitigate memory-dump analysis and cold-boot vulnerabilities, sensitive private scalar allocations are stored inside typed array buffers wrapped with zeroization guards:

```typescript
export function purgeEphemeralKeys(): void {
  // Overwrite sensitive buffers with uniform zeros prior to garbage collection
  if (ephemeralKeyRing.ask) ephemeralKeyRing.ask.fill(0);
  if (ephemeralKeyRing.nsk) ephemeralKeyRing.nsk.fill(0);
  if (ephemeralKeyRing.ivsk) ephemeralKeyRing.ivsk.fill(0);
  ephemeralKeyRing.initialized = false;
  // Trigger immediate cryptographic session teardown
  window.dispatchEvent(new CustomEvent('hl_keystore_zeroized'));
}

```

### 3.3 Storage at Rest: OPFS SQLite Authenticated Encryption

Aztec SDK v6.0.0 defaults to OPFS SQLite storage. Humanity Ledger mandates that unencrypted fallback modes are prohibited at compile time (`docs/AZTEC_AUDIT_MANIFEST.md` §3). The database engine initialises via `openEncryptedEmbeddedStores`:

\text{Key}\_{\text{store}} = \text{HKDF-Expand}\left(\text{PRK}, \text{"humanity-ledger/aztec-store"}, 32\right)

All note preimages, discovered nullifiers, and block synchronization checkpoints written by the PXE runtime are encrypted through authenticated page-level ciphersuites before hitting local non-volatile flash memory.

* * *

## 4. Private Execution Environment (PXE) & Client Proving

### 4.1 In-Browser UltraHonk Execution Pipeline

Proving computation executes within client-side Web Workers using compiled WebAssembly instances of the Barretenberg prover library (`@aztec/bb.js`).

```plaintext
 +-----------------------------------------------------------------------------------+
 | Client Web Worker Sandbox |
 | |
 | [Private Inputs] [Historical Note Merkle Path] [Public Inputs] |
 | Preimages, ask, nsk Leaf Inclusions via PXE Cache ChainID, Portal Addr |
 | \ | / |
 | +----------------------+----------------------+ |
 | | |
 | v |
 | [Noir Circuit Execution (ACIR)] |
 | | |
 | v |
 | [Polynomial Constraint Synthesis] |
 | | |
 | v |
 | [UltraHonk Prover Pipeline] |
 | - Sumcheck Protocol (Over hypercube) |
 | - Zero-Knowledge Polynomial Blinding |
 | - Shplonk Multi-Point Evaluation |
 | - KZG / IPA Commitment Scheme |
 | | |
 +---------------------------------|-------------------------------------------------+
                                   v
             UltraHonk Proof (pi_honk in {0,1}^N) + Public Outputs

```

1. **ACIR Bytecode Evaluation:** Client inputs are evaluated against circuit constraints to produce an execution trace (witness).
2. **Sumcheck Polynomial Formulation:** The constraint equations over the execution trace are arithmetized into multilinear polynomials evaluated over the Boolean hypercube \{0, 1\}^n.
3. **Proof Verification Equivalence:** The proof \pi\_{\text{honk}} is transmitted to the Aztec Alpha sequencer, which verifies the recursive proof aggregation validity before inclusion in the L2 rollup block.

### 4.2 Prover API Architecture

The endpoint `app/api/premium/prover/route.ts` is explicitly restricted to telemetry coordination. It verifies node liveness, network rollup version, and L1 contract anchoring:

```typescript
// Verified implementation fragment from app/api/premium/prover/route.ts
return NextResponse.json({
  success: true,
  message: 'Aztec node reachable. Client-side UltraHonk proving runs in the browser via bb.js; this endpoint reports node status only.',
  proverNetwork: nodeInfo.l1ContractAddresses?.rollupAddress?.toString(),
  l1ChainId: nodeInfo.l1ChainId,
  rollupVersion: nodeInfo.rollupVersion,
  blockNumber: blockNumber,
  realProofs: nodeInfo.realProofs,
  enforcedZeroMock: true,
  zkStatus: 'node_connected',
  identityMode: identity.mode,
}, { status: 200 });

```

* * *

## 5. Native `aztec-nr` v6.0.0 Smart Contract

The protocol’s economic primitives are written in native `aztec-nr` (`contracts/aztec/`) compiled against Aztec v6.0.0.

### 5.1 `EscrowContract.nr`

Governs non-custodial milestone escrows with time-locked refund guarantees:

```rust
use dep::aztec::prelude::*;
use dep::token::Token;

struct EscrowPayload {
    sender: AztecAddress,
    recipient: AztecAddress,
    token: AztecAddress,
    amount: U128,
    deadline: u64,
    salt: Field,
}

#[aztec(private)]
fn release_escrow(
    payload: EscrowPayload,
    escrow_note_hash: Field,
    claim_secret: Field
) {
    // 1. Enforce time-validity invariant
    let current_time = context.timestamp();
    assert(current_time <= payload.deadline, "Escrow deadline expired");

    // 2. Validate cryptographic recipient
    let expected_recipient = payload.recipient;
    assert(context.msg_sender() == expected_recipient, "Unauthorized claimant");

    // 3. Nullify escrow note commitment
    let note = get_note_from_hash(escrow_note_hash);
    context.push_nullifier(note.compute_nullifier(&context));

    // 4. Atomic shielded disbursement
    Token::at(payload.token).transfer_to_private(
        &mut context, 
        payload.recipient, 
        payload.amount
    );
}

```

- **Invariant 1 (Double-Spend Immunity):** The nullifier generation function \mathcal{N}(C, nsk) = \text{Poseidon2}(nsk, C) guarantees that each deposit note can transition to the claim state exactly once.
- **Invariant 2 (Solvency):** Sum of released funds and refundable balance is strictly invariant to initial deposit volume:

\sum V\_{\text{released}} + \sum V\_{\text{refunded}} \equiv V\_{\text{initial}}

### 5.2 `StreamsContract.nr`

Implements continuous, block-by-block private value accrual without intermediate state disclosure:

\mathcal{A}(\tau) = \min\left(V\_{\text{total}} - V\_{\text{withdrawn}}, \; \lfloor (\tau - \tau\_{\text{start}}) \cdot \rho \rfloor \right)

```rust
// Accrual bounding invariant implemented in contracts/aztec/streams
assert(payload.rate_per_second <= 1_000_000_000_000_000, "Rate bound overflow");
let elapsed = context.timestamp() - payload.start_time;
let accrued = elapsed * payload.rate_per_second;
assert(withdrawn + claim_amount <= accrued, "Claim exceeds accrued stream");
assert(withdrawn + claim_amount <= payload.total_allocation, "Claim exceeds total allocation");

```

- **Theorem 1 (Rate Bound Overflow Safety):** For any timestamp representation \tau \< 2^{64}-1 and rate parameter \rho \le 10^{15}, the arithmetic product (\tau - \tau\_{\text{start}}) \cdot \rho strictly occupies \< 2^{114} bits, guaranteeing immunity against field wrap-around over \mathbb{F}\_{r} (r \approx 2^{254}).

### 5.3 `IdentityContract.nr`

Replaces static sanction code assertions with dynamic, zero-knowledge committed Merkle non-membership verification:

\text{VerifySanctionProof}: \quad \pi\_{\text{sanctions}} = \left\{ \text{Root} \equiv \mathcal{R}\_{\text{OFAC}}, \; \text{Poseidon2}(nsk, \text{ID}\_{\text{hash}}) \notin \mathcal{T}\_{\text{sanctions}} \right\}

* * *

## 6. Communication Protocol: MLS & Media Transport

### 6.1 Session Setup & TreeKEM Ratchet

Ledger Chat leverages **IETF RFC 9420 (MLS)** for decentralized pairwise and multi-party channels.

```plaintext
            [TreeKEM Cryptographic Hierarchy]
                           Node_01
                         / \
                    Node_02 Node_03
                    / \ / \
                 Leaf_A Leaf_B Leaf_C Leaf_D
                 (Alice) (Bob) (Carol) (Dave)

```

1. **Leaf Secret Construction:** Individual participants contribute an ephemeral Diffie-Hellman leaf keypair (k\_{i}, K\_{i}) \in \mathbb{G}\_{1}.
2. **Path Updates:** When a participant transmits a message or rotates state, they compute blinding values ascending to the tree root, encrypting node secrets to co-path siblings.
3. **Asynchronous Consensus:** Ratchet tree commits are published over untrusted decentralized transport queues (XMTP). Participants advance their local ratchets deterministically upon verifying parent node hashes.

### 6.2 Authenticated Remote Media Transport (`AES-256-GCM`)

Audio messages, imagery, and binary documents are decoupled from the transport pipe through content-addressed encrypted envelopes:

```typescript
export interface AttachmentMessage {
  type: 'hl.attachment';
  scheme: 'aes-256-gcm-hkdf-sha256';
  url: string; // Content-addressed decentralized URL
  ciphertextSha256: string; // Integrity check of encrypted payload
  encryptionKeyHex: string; // 256-bit symmetric key (transmitted in MLS payload)
  ivHex: string; // 96-bit unique nonce
  kind: 'audio' | 'image' | 'video' | 'file';
  filename?: string;
  byteLength: number;
}

```

- **Acoustic Processing:** Audio notes are acquired via in-browser media streams (with fallback heuristics covering Safari WebKit MediaRecorder container configurations) and converted into raw AAC/MP4 fragments prior to client-side encryption.

### 6.3 P2P Audio/Video Communication

Voice and video streams connect directly between browsers via WebRTC:

- **Signaling Channel:** Call negotiation primitives (` __CALL_OFFER__ `, ` __CALL_ANSWER__ `, ` __CALL_ICE__ `) are exchanged inside end-to-end encrypted MLS envelopes.
- **Media Encryption:** Real-time audio and video packets are encrypted using **DTLS-SRTP**. Peer IP masking can be routed through ICE turn relays where strict topological privacy is required.

* * *

## 7. Aztec Alpha Fee Accounting & Linkability Disclosures

On Aztec Alpha, computation fees are denominated in **Fee Juice** :

\text{GasCost} = \text{GasConsumed}\_{\text{DA}} \cdot \text{Price}\_{\text{DA}} + \text{GasConsumed}\_{\text{L2}} \cdot \text{Price}\_{\text{L2}}

```plaintext
[Layer 1: Ethereum Mainnet]
  Fee Juice Token (0xA27EC0006e59f245217Ff08CD52A7E8b169E62D2)
       |
       | ERC-20 Deposit Function Call
       v
  Fee Juice Portal (0x534361be805CA30Bdb6404eC5E6cDAFFB3E9f3b3)
       |
       | Cross-Chain Portal Ingestion Event
       v
[Layer 2: Aztec Alpha Rollup 2070860440]
  Fee Juice Gas Tank (Associated with User Aztec Canonical Account)
       |
       | Execution Fee Drawdown
       v
  Aztec Alpha Block Sequencer Pool

```

### 7.1 Formal Disclosure of Gap G8 (Fee Payer Linkability)

The protocol makes an explicit architectural disclosure regarding current Aztec Alpha gas mechanics:

> **Formal Limitation (Gap G8):** In the Aztec Alpha execution model, transaction fees drawn from a client’s Fee Juice balance require the transaction sender’s public Aztec account identifier to be registered as the `fee_payer`. While the inner transaction kernel fully encrypts transaction amounts, recipient addresses, and private note preimages, the **outer transaction envelope links consecutive transactions dispatched by the identical fee payer address**. Fully unlinkable fee abstraction requires private paymaster relay integration or recursive relayer shielding pools, which remain under active development for final Mainnet hardening.

* * *

## 8. Linearizable Message Revocation Model

To prevent state inconsistencies where deleted messages re-materialize from network caches, Humanity Ledger enforces a linearizable, author-authenticated revocation protocol (`lib/chat/deleted-messages.ts`).

### 8.1 State Consistency Algorithm

\text{VerifyRevoke}: (\text{TargetNote}, \text{RevokerIdentifier}) \longrightarrow \{\mathbf{Honour}, \mathbf{Reject}, \mathbf{Unknown}\}

```plaintext
  Incoming XMTP Message Payload
                 |
                 v
   Is content. __REVOKE__ <id>?
        / \
      YES NO
      / \
  Extract TargetID Proceed to Standard Decryption Bubble Rendering
     |
     v
  Query Local Cache for TargetID
     |
     +---> [Not Found locally]: Return 'Unknown'
     | (Retain in XMTP log; evaluate on conversation fetch)
     |
     +---> [Found locally]: Check Target.Author == RevokerID
              / \
           MATCH MISMATCH
            / \
    Return 'Honour' Return 'Reject'
    - Delete from IndexedDB (chatDB) - Log Security Warning
    - Add TargetID to hl_revoked_msg_global - Ignore Control Signal
    - Evict from React Active State

```

```typescript
export function verifyRevoke(
  target: { senderInboxId?: string; senderAddress?: string } | undefined,
  revokerId: string | undefined
): RevokeVerdict {
  if (!target) return 'unknown';
  if (!revokerId) return 'reject';

  const targetId = (target.senderInboxId || target.senderAddress || '').toLowerCase();
  const revoker = revokerId.toLowerCase();

  if (!targetId) return 'reject';
  return targetId === revoker ? 'honour' : 'reject';
}

```

* * *

## 9. Empirical Verification & Testnet Execution Register

### 9.1 Verification Suite Results (Commit `20ffc2b5`)

The Humanity Ledger protocol undergoes continuous cryptographic regression and adversarial property testing:

```plaintext
=============================== TEST EXECUTION SUMMARY ===============================
Test Execution Framework: Vitest v5.0.5
Compilation Target: ES2022 / Next.js 15.0 / TypeScript 5.6.3 (Strict Mode)

[PASS] test/unit/chat/deleted-messages.test.ts (3/3 tests)
[PASS] test/unit/payments/rails.test.ts (8/8 tests)
[PASS] test/unit/chat/recording.test.ts (4/4 tests)
[PASS] test/unit/chat/remote-attachment.test.ts (17/17 tests)
[PASS] test/unit/aztec/fees.test.ts (7/7 tests)
[PASS] test/unit/aztec/fee-juice.test.ts (14/14 tests)
[PASS] test/unit/aztec/peer-binding.test.ts (16/16 tests)
[PASS] test/unit/security/audit-2026-10-28c.test.ts (5/5 tests)
[PASS] test/unit/security/quantum_crypto_adversarial.test.ts (12/12 tests)
[PASS] test/unit/security/ssrfGuard.test.ts (22/22 tests)
...
--------------------------------------------------------------------------------------
TOTAL METRICS:
  Test Files Passed: 102 / 102 (100%)
  Tests Passed: 1,452 / 1,452 (100%)
  TypeScript Errors: 0 diagnostics (npx tsc --noEmit: SUCCESS)
======================================================================================

```

### 9.2 Cryptographic Testnet Audit Register

| Index | Protocol Phase | Aztec Testnet Hash / Identifier | Block | Verification State |
| --- | --- | --- | --- | --- |
| **01** | Faucet Ingestion | `0x24ff930ab718302dfc04ec47648316dfa996f26d2e67df4cf9ee6e0ec3d2746b` | `14210` | Non-Simulated Execution |
| **02** | UltraHonk Shield | `0x1f06bca23801f99ca828e6c7ea762ea1804f85e49bbaf909eeae8b2ff259b139` | `14211` | Client Proof Verified |
| **03** | Private Transfer | `0x0bf87a998ce7319c52feac392b450702df2f8a554a935be066ea4ca08354fe32` | `14212` | Nullifier Root Advanced |
| **04** | Atomic Unshield | `0x31ae8bbcd904ef2894c2560384a26e85747cbcf2659e4b11f7ae0bc4047ba32c` | `14213` | L1 Exit Root Validated |

* * *

## 10. Open Engineering & Research Queries for Aztec Labs

To advance zero-knowledge communication systems towards mainnet readiness, we propose four research questions to the Aztec Labs architecture team:

### 10.1 Working Set RSS Constraints: UltraHonk vs. CHONK on Mobile Safari

In browser environments, client-side UltraHonk proof synthesis through WebAssembly instances of Barretenberg (`@aztec/bb.js`) exhibits working set allocations between **1.6 GB and 1.9 GB RSS** during multi-scalar multiplication (MSM) and quotient polynomial evaluation. Mobile Safari (WebKit) terminates web processes exceeding ~1.4 GB via the system `Jetsam` memory reaper.

- What is the canonical delivery roadmap for **CHONK (Client Honk)** within the `@aztec/bb.js` package?
- Will CHONK adopt split-accumulation schemes or recursive step-provers capable of constraining peak working memory within 512 MB?

### 10.2 Sub-Linear Note Discovery via Ephemeral Tag Indexing

Currently, client PXEs decrypt private balances by sequentially scanning encrypted note logs across block sequences. In high-throughput settings, mobile devices offline for multiple days encounter substantial CPU load trial-decrypting thousands of non-relevant logs.

- Does Aztec Labs recommend application-level ephemeral Diffie-Hellman hint tagging (e.g., prefix truncated shared secret tagging) in contract logs, or will the core protocol introduce a standardized tagged indexing primitive for thin clients?

### 10.3 Trustless, Relayer-Blind Fee Abstraction (Solving Gap G8)

As formalized in §7.1, Fee Juice mechanics on Aztec Alpha publicly expose the fee-paying address.

- What architectural direction does Aztec Labs advise for production-grade unlinkability:
  1. Relayer-funded transactions using blinded off-chain refund vouchers?
  2. Protocol-enshrined private fee deductions directly executed inside the private kernel circuit?

### 10.4 Multi-Instance PXE State Reconciliation

Because note discovery state is confined to local encrypted OPFS SQLite instances, a user accessing Ledger Chat from a secondary hardware terminal (e.g., workstation to mobile device) lacks access to historical note caches.

- Does Aztec Labs envision a canonical protocol for encrypted note state synchronization—such as passkey-derived WebAuthn PRF encryption over decentralized storage relays?

* * *

## 11. Verification & Artifact Reproducibility

The implementation is open source, deterministically reproducible, and available for public review.

```bash
# 1. Clone canonical repository
git clone https://github.com/humanityledger/Humanity-Ledger.git
cd Humanity-Ledger

# 2. Checkout formal commit snapshot
git checkout 20ffc2b5

# 3. Clean environment installation
npm ci

# 4. Execute full TypeScript structural typecheck
npx tsc --noEmit

# 5. Execute cryptographic unit and regression tests
npx vitest run test/unit/chat/deleted-messages.test.ts \
               test/unit/payments/rails.test.ts \
               test/unit/aztec/fee-juice.test.ts \
               test/unit/security/audit-2026-10-28c.test.ts

```

| Reference | |
| --- | --- |
| **Evaluated Commit** | `20ffc2b5c777418933b43a99263a23d06112a970` |
| **Monorepo** | [github.com/humanityledger/Humanity-Ledger](https://github.com/humanityledger/Humanity-Ledger) |
| **Production Terminal** | [ledgerchat.org](https://ledgerchat.org) |
| **Founder & CEO** | Stefan Antonio Cirisanu ([LinkedIn](https://www.linkedin.com/in/stefan-antonio-cirisanu-40116140b/)) |
| **COO & Co-Owner** | Oprișan Elena-Grațiela ([LinkedIn](https://www.linkedin.com/in/opri%C5%9Fan-elena-gra%C5%A3iela-5334932b9/)) |
| **Contact** | `humanityledger@icloud.com` |

---

<div class="post-metadata">

**Author:** ![atfortyseven](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.aztec.network/atfortyseven/32/3021_2.png) [@atfortyseven](https://forum.aztec.network/u/atfortyseven)\
**Post date:** [November 12, 2026, 8:54am UTC](https://forum.aztec.network/t/ledger-chat-messaging-and-private-payments-on-aztec-network/8702/2 "2026-11-12T08:54:23Z")

</div>

# Ledger Chat Engineering Update II: From Testnet Specification to Aztec Alpha on Ethereum Mainnet

## Abstract

The first post described the architecture as specified and exercised on testnet.

This update reports what changed once the client met Aztec Alpha on Ethereum mainnet and real users on Safari and Chrome. Eight pull requests (#53–#60) address four classes of failure observed in production: (i) PXE start-up and node reachability in the browser, (ii) fee-payment feasibility under Alpha’s maximum-fee rule, (iii) real-time media establishment across NATs, and (iv) identity and memory footprint of the web client.

* * *

## 1. PXE Initialisation in Production Browsers

### 1.1 Observed failure

`PXE.create` failed in Safari and Chrome with `AggregateError: … Failed to fetch`, surfacing to users as “the wallet does not open”.

### 1.2 Root causes

1. **Content-Security-Policy.** `bb.js` 6.0.0 materialises its WASM from a `data:application/gzip;base64` URL via `fetch`. Our enforced CSP did not list `data:` in `connect-src`, so the prover never loaded.
2. **Single-node dependency.** Every PXE request went to one Aztec node URL; a transient failure aborted synchronisation.
3. **Store contention across tabs.** Two tabs of the same origin raced for the encrypted PXE stores, producing lock errors that were misreported as network failures.

### 1.3 Changes

- `connect-src 'self' https: wss: blob: data:` in both the enforced and report-only policies, with a regression test that fails if `data:` is removed (#58).
- `makeNodeFetch`: ordered failover across node endpoints, classification of transient errors, and a same-origin, rate-limited relay (`/api/aztec/node`) used only when direct access is refused (#53).
- **Tab handoff protocol:** a single tab owns the PXE stores; a second tab requests ownership over `BroadcastChannel`, the owner releases cleanly on `pagehide` or after an idle period, and the UI states which of _handed off / busy elsewhere / paused / idle-closed_ applies (#53).
- Errors are unwrapped from `AggregateError` and exported with stack and message (“Copy details”), because WebKit stack traces omit the message (#57, #59).

* * *

## 2. Fee Juice Feasibility under the Maximum-Fee Rule

### 2.1 Observation

A user bridged 2 AZTEC through the FeeJuicePortal (`0x534361be805CA30Bdb6404eC5E6cDAFFB3E9f3b3`). The L1 deposit succeeded; account deployment on L2 failed at `deployAccount`.

### 2.2 Analysis

On Alpha a transaction must be able to pay its **maximum** fee, not its expected fee:

\\text{maxFee} = (G\_{L2}\\cdot f\_{L2} + G\_{DA}\\cdot f\_{DA})\\cdot h

with gas limits G\_{L2} = 6{,}540{,}000 (`MAX_PROCESSABLE_L2_GAS`), G\_{DA} = 786{,}432, and fees read live from `node.getCurrentMinFees()`. At the observed f\_{L2} = 2.1158\\times10^{12} and f\_{DA}=0, the floor is ≈ 13.8 AZTEC, and ≈ 27.7 AZTEC with our safety multiplier h=2. A 2 AZTEC claim is therefore infeasible for any transaction, independent of its actual cost; the earlier fee planner nevertheless selected it.

### 2.3 Changes (#57, #59)

- `feePlan` selects the largest ready claim such that `balance + claim ≥ minForTx`; otherwise it returns `{ kind: 'top-up', have, need }`.
- The bridge UI computes the minimum from live node fees, refuses deposits below it, and states the exact amount to add. Small earlier deposits are not lost: they remain claimable and are summed with the next deposit.
- Token registration failures no longer abort account creation (`ensureTokens` is non-fatal).
- Receiving requires no Fee Juice: an address can receive private notes before its account contract is deployed.

### 2.4 Open problem (restating Gap G8)

Requiring every new user to bridge ≈ 28 AZTEC before a first private action is a material onboarding barrier, and self-payment preserves the fee-payer linkability disclosed as G8.

We would value Aztec Labs’ guidance on the recommended FPC pattern for Alpha (see §6).

* * *

## 3. Real-Time Media: Establishment, Continuity, and Honest State

### 3.1 Transport

1:1 calls use WebRTC (DTLS-SRTP), with offers carried as end-to-end-encrypted chat messages and PeerJS for session signalling.

Media never transits our servers; a TURN relay, when one is needed, forwards only encrypted SRTP.

### 3.2 Continuity (#54, #55, #56)

- **Make-before-break resume:** on network change (Wi-Fi ↔ cellular) a new connection is dialled for the same call and adopted only when it carries media; simultaneous redials are resolved deterministically on both ends (glare rule).

- **Voice → video upgrade** and **screen sharing** on separate connections, so the voice path is never renegotiated.

- Opus tuned for speech (in-band FEC, mono, 32 kbps cap); sender priorities favour audio; camera keeps frame rate, screen keeps resolution.

- Short-lived TURN credentials (`/api/calls/ice`: Cloudflare Realtime, coturn REST, or static), refreshed before expiry.

- Local, per-device call metrics (setup time, first-audio time, route, RTT, heap).

### 3.3 Production audit finding and correction (#60)

A self-audit on 12 Nov found silent voice calls and black video.

Two facts explained it: no TURN service was configured in production, and the public `openrelayproject` fallback no longer allocates relays (error 701 on every URL). Without a relay, peers behind carrier-grade NAT have no viable candidate pair.

The client nevertheless displayed the call as connected, because PeerJS emits the remote stream when the answer arrives before ICE completes.

The call state machine is now `calling → connecting → active`, where **`active` is entered only on ICE `connected`/`completed`**. If no path is found within 20 s, or ICE fails, the call ends on both sides with an explicit message.

The dead relay was removed; the fallback is STUN-only.

Configuring Cloudflare Realtime TURN in production is the remaining operational step, after which relay-only calls are verifiable with the “Hide my IP address in calls” setting.

* * *

## 4. Identity, Session Latency, and Memory

- **Wallet-only identity (#56).** Email login was retired; the account is the wallet, authenticated by SIWE (EIP-4361). Key derivation and the signed message are unchanged from the first post.

- **Native wallet connection** in Safari and Chrome without redirect flows; one-click authentication is available behind an explicit flag.

- **Latency.** Moving the service next to its database region reduced `/api/auth/session` from ≈ 2.3 s to 7–32 ms.

- **Memory.** Eighteen heavy views are now loaded on demand (`next/dynamic`), type-only imports keep picker libraries out of the main bundle, and the wallet/PXE providers mount only when the private wallet is opened. This matters for §6.1: on iOS the page that does not prove should not hold prover memory.

- **Database resilience (#57).** Connection strings are normalised and described without secrets at boot, so a malformed URL fails loudly instead of silently.

* * *

## 5. Verification

| Area | Evidence |
| --- | --- |
| CSP / prover load | regression test `csp-wasm`; verified live on [ledgerchat.org](http://ledgerchat.org) |
| Fee planning | unit tests for `feePlan`, `maxFeeFor`, top-up path |
| Calls | unit tests for SDP tuning, ICE configuration, resume/glare, ICE-gated activation |
| CI on `c8c62b0` | unit tests, production build, type/lint, secret scanning, CodeQL, circuit and VK checks pass. The Hardhat contract-test job fails for a pre-existing reason unrelated to these changes. |

All results are reproducible from the repository at the evaluated commit.

* * *

## 6. Questions for Aztec Labs

1. **Sponsored fees on Alpha.** What is the recommended Fee Payment Contract pattern for an application that pays account deployment and first transfers for its users, and how should it interact with G8?

2. **Maximum-fee headroom.** Is a ×2 multiplier on `getCurrentMinFees()` a reasonable client default for Alpha, or is there a recommended bound?

3. **Mobile Safari memory.** Is there guidance on the peak working set of account deployment proofs on iOS, and on CHONK’s expected reduction relative to UltraHonk for this circuit?

4. **Multi-tab PXE.** Is single-owner handoff the intended pattern for browser PXEs, or is shared-worker ownership planned?

* * *

We thank the Aztec community for the questions on the first post and welcome review of any section above.