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
Target Repository: 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.
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.
-
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:
- \text{Poseidon2}(x_{1}, \dots, x_{k}): The algebraic hash permutation over \mathbb{F}_{r}, configured with state size t = k+1, full rounds R_{F} = 8, and partial rounds R_{P} = 56, representing the canonical primitive for note commitments and Merkle trees.
- \text{HKDF-SHA256}(\text{IKM}, \text{salt}, \text{info}): Key derivation adhering to RFC 5869.
- \text{AES-GCM-256}(K, IV, P, A): Authenticated symmetric encryption with 96-bit nonces and 128-bit authentication tags (NIST SP 800-38D).
2. Threat Model & Security Definitions
2.1 Adversary Modeling
We formalize protocol soundness under three distinct adversarial classes:
- 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.
- 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.
- 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:
[ 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)
- Authentication Message (M_{\text{SIWE}}): Formatted per EIP-4361, binding the human-readable domain
ledgerchat.org, standard cryptographic nonces, and session lifetimes. - 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:
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:
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).
+-----------------------------------------------------------------------------------+
| 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
- ACIR Bytecode Evaluation: Client inputs are evaluated against circuit constraints to produce an execution trace (witness).
- Sumcheck Polynomial Formulation: The constraint equations over the execution trace are arithmetized into multilinear polynomials evaluated over the Boolean hypercube \{0, 1\}^n.
- 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:
// 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:
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:
5.2 StreamsContract.nr
Implements continuous, block-by-block private value accrual without intermediate state disclosure:
// 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:
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.
[ TreeKEM Cryptographic Hierarchy ]
Node_01
/ \
Node_02 Node_03
/ \ / \
Leaf_A Leaf_B Leaf_C Leaf_D
(Alice) (Bob) (Carol) (Dave)
- Leaf Secret Construction: Individual participants contribute an ephemeral Diffie-Hellman leaf keypair (k_{i}, K_{i}) \in \mathbb{G}_{1}.
- 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.
- 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:
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:
[ 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
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
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:
=============================== 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.jspackage? - 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:
- Relayer-funded transactions using blinded off-chain refund vouchers?
- 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.
# 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 |
| Production Terminal | ledgerchat.org |
| Founder & CEO | Stefan Antonio Cirisanu (LinkedIn) |
| COO & Co-Owner | Oprișan Elena-Grațiela (LinkedIn) |
| Contact | humanityledger@icloud.com |