VERIFIABLE CODEBASE FACTS

Code is math. Here are the exact numbers.

We audited MNDO's identity generation, dictionary combinatorics, cryptography, Signal messaging, voice notes, and encrypted storage. Every figure below is mathematically grounded, code-inspected, and defensible.

Audited against MNDO main codebase

Username Space
14.9T

888 × 1,000 × 16⁶ unique combinations

Identity Entropy
2¹²⁸

~3.4 × 10³⁸ BIP-39 entropy states

Historical Scale
~127×

All humans ever born (~117B estimate)

Dual Encryption
256-bit

Signal Double Ratchet + SQLCipher

Server Dependency
Zero

Pure client-side offline keygen

FACT 01·COMBINATORICS
14,898,167,808,000
14.9 Trillion

The full username space is ~14.9 trillion combinations

Every initial username is formatted as [Adjective] [Noun] #[Hex6]. Combining 888 unique adjectives, 1,000 unique nouns, and 16,777,216 hex suffixes produces nearly fifteen trillion human-readable handles.

→888 adjectives × 1,000 nouns × 16⁶ hex suffixes = 14,898,167,808,000 combinations
FACT 02·COMPARISON
~127× Historical Scale
127× Scale

~127× larger than all humans who have ever lived

The Population Reference Bureau estimates roughly 117 billion humans have ever been born on Earth. MNDO's username namespace of 14.9 trillion is approximately 127 times larger than that total.

→14.898 Trillion ÷ 117 Billion ≈ 127.3× all humans in history
FACT 03·POPULATION RATIO
1,817 per human
1,817 : 1

~1,800 combinations for every person alive today

Against the global population of roughly 8.2 billion people, MNDO can provide over eighteen hundred unique, human-readable username combinations per living human without exhausting its namespace.

→14,898,167,808,000 ÷ 8.2 Billion ≈ 1,817 usernames / person
FACT 04·DICTIONARY AUDIT
888,000 Word Pairs
888 / 1,000

888 unique adjectives × 1,000 unique nouns

Code inspection confirms the dictionary contains exactly 888 unique adjectives and 1,000 unique nouns. This yields 888,000 distinct word pairs before the 6-character hex suffix is appended.

→888 adjectives × 1,000 nouns = 888,000 base phrases
FACT 05·ENTROPY SUFFIX
16,777,216 Suffixes
16⁶ (24 bits)

16.7 million hexadecimal suffix possibilities

Each username appends a 6-character hexadecimal discriminator (#abcdef). With 16 possibilities per hex character (0-9, a-f), the suffix alone provides over 16.7 million unique tags per word pair.

→16⁶ = (2⁴)⁶ = 2²⁴ = 16,777,216 distinct suffixes
FACT 06·BIT SLICE
56 bits of SHA-256
7 Bytes

Username uses only the first 7 bytes (56 bits) of SHA-256

MNDO hashes the Ed25519 public key with SHA-256, but the generator only takes the first 7 bytes: bytes 0–1 index the adjective, bytes 2–3 index the noun, and bytes 4–6 form the hex suffix.

→Bytes 0-1 (Adjective) + Bytes 2-3 (Noun) + Bytes 4-6 (Hex Suffix) = 7 bytes (56 bits)
FACT 07·INFORMATION THEORY
43.76 Bits
43.8 Bits

Username carries ~43.8 bits of effective namespace

Because dictionary indexing compresses the 56-bit hash slice, the visible username represents log₂(14,898,167,808,000) ≈ 43.76 bits of distinguishability. The username is a friendly display handle; the 32-byte Ed25519 public key is the true cryptographic identity.

→log₂(14.898 × 10¹²) = 43.76 bits of entropy
FACT 08·COLLISION PROBABILITY
~4.5M Identities
Collision Safe

Birthday paradox: 50% collision probability around ~4.5M users

With no central registration server, username collisions are mathematically possible. In a 14.9T space, the birthday paradox predicts a 50% chance of at least one pair sharing a handle at ~4.5M users. Because messaging routes to keys (not handles), collisions do not impact security.

→n ≈ √(2 × 14.9 × 10¹² × ln(2)) ≈ 4,547,000 identities
FACT 09·ZERO NETWORK
0 Network Calls
Offline

100% deterministic & offline username generation

No registration database is queried to generate the initial username. Same mnemonic → same seed → same Ed25519 public key → same username. It can be computed on an air-gapped device in under a millisecond.

→f(Master Ed25519 Public Key) ➔ Deterministic Username
FACT 10·ROOT ENTROPY
~3.4 × 10³⁸ States
128-Bit Entropy

Identity space starts at 2¹²⁸ possibilities (BIP-39)

MNDO generates a 12-word BIP-39 mnemonic representing 128 bits of cryptographic entropy plus a 4-bit SHA-256 checksum. That yields 340,282,366,920,938,463,463,374,607,431,768,211,456 possible states.

→2¹²⁸ ≈ 3.4028 × 10³⁸ (2.9 × 10²⁷ times all humans ever born)
FACT 11·KEY DERIVATION
2,048 Iterations
512-Bit Seed

PBKDF2-HMAC-SHA512 expands mnemonic to 512-bit seed

The BIP-39 mnemonic is stretched using PBKDF2 with HMAC-SHA512 and 2,048 iterations to produce a 64-byte (512-bit) master seed. The first 32 bytes are sliced to initialize the master Ed25519 keypair.

→PBKDF2(HMAC-SHA512, iterations: 2048) ➔ 512-bit Seed ➔ 32-byte Ed25519 Key
FACT 12·SIGNATURE SCHEME
32-byte Keys
Ed25519

Master cryptographic identity is Ed25519 (RFC 8032)

The master root identity uses Ed25519 on Curve25519. Public keys are 32 bytes (256 bits, 64 hex characters) and digital signatures are 64 bytes, providing 128-bit security against all known attacks.

→Public Key: 32 bytes (256 bits) · Signature: 64 bytes (512 bits)
FACT 13·KEY SEGREGATION
Dual Key Isolation
Isolated Keys

Separate Nostr transport key derived via SHA-256

The master Ed25519 key and the Nostr relay transport key are cryptographically separated. MNDO derives the Nostr private key by computing SHA-256(mnemonic + '_nostr'). Transport compromise cannot leak the master identity.

→Nostr Key = SHA-256(Mnemonic + '_nostr') ≠ Master Ed25519 Key
FACT 14·DELEGATION BINDING
MNDO-BIND Proof
Cryptographic Proof

Master identity cryptographically binds Nostr transport key

MNDO signs a delegation statement formatted as 'MNDO-BIND:<nostr_pubkey>:<timestamp>' using the master Ed25519 key. Peers can verify with mathematical certainty that a given Nostr transport key is authorized by that master identity.

→Sign_Ed25519('MNDO-BIND:' + nostrPubkey + ':' + timestamp)
FACT 15·AUTHENTICITY
Dual Signatures
Dual Authenticated

Two-layer cryptographic presence authentication

Presence updates are Nostr events signed by the Nostr transport key, with an inner payload containing a masterSig signed by the Ed25519 root identity. Status cannot be spoofed by relay operators.

→Event(Sign_Nostr) ➔ Payload(Sign_Ed25519)
FACT 16·MESSAGE PIPELINE
Nostr Kind 4444
Kind 4444

Signal Protocol encryption encapsulated in Nostr Event 4444

The pipeline is: Plaintext → MNDO Message Envelope → libsignal Double Ratchet Encryption → Nostr Event Kind 4444 → Relay Mesh. Relays only ever receive and forward ciphertext.

→Plaintext ➔ Signal Session ➔ Ciphertext Blob ➔ Kind 4444 Event
FACT 17·SEPARATION OF CONCERNS
Clean Separation
Zero-Knowledge

Nostr is the transport carrier; Signal is the encryption engine

Nostr provides decentralized relay transport, event delivery, and pubkey addressing. Signal provides cryptographic sessions, prekey distribution, and ratcheting. Relays cannot decrypt or tamper with payloads.

→Nostr = Blind Routing Layer · Signal = Cryptographic State Machine
FACT 18·FORWARD SECRECY
Ephemeral Keys
Double Ratchet

Double Ratchet changes encryption key on every message

The Signal Double Ratchet derives a fresh symmetric key for every single message and steps Diffie-Hellman ratchets. Exposing one message key never unlocks prior messages (Forward Secrecy) or future ones (Post-Compromise Security).

→Message 1 (Key 1) ➔ Message 2 (Key 2) ➔ Message n (Key n)
FACT 19·OFFLINE SESSIONS
Offline Initiated
X3DH

Asynchronous session initiation via X3DH prekeys

Devices publish Signal PreKey bundles: Identity Public Key, Signed PreKey + signature, One-Time PreKeys, and Registration ID. Any peer can establish an encrypted chat session even when the recipient is offline.

→DH1 + DH2 + DH3 + DH4 (Extended Triple Diffie-Hellman)
FACT 20·EVENT TAXONOMY
5 Dedicated Kinds
Structured Kinds

Dedicated Nostr event kinds prevent metadata cross-contamination

MNDO cleanly partitions traffic across Nostr event kinds: 4444 (Encrypted Messages), 21111 (Ephemeral Presence), 0 (Profile Metadata), 10446 / 14446 (Signal PreKey Bundles), and 24242 (Blossom Media Auth).

→Kinds: 4444 (Chat) · 21111 (Presence) · 0 (Metadata) · 10446 (PreKeys) · 24242 (Blossom)
FACT 21·MEDIA CIPHER
256-bit Key + 96-bit Nonce
AES-256-GCM

Voice notes get dedicated AES-256-GCM encryption

MNDO does not stream raw audio. Voice notes are encrypted locally before upload using AES-256-GCM with a newly generated 256-bit key and an unpredictable 96-bit nonce.

→AES-256-GCM(audio_bytes, key: 256-bit, nonce: 96-bit)
FACT 22·CONTENT HASH
SHA-256(Ciphertext)
SHA-256 Blob

Encrypted audio files addressed via SHA-256 content hashes

After encryption, MNDO computes SHA-256 over the ciphertext bytes. The resulting hash serves as the immutable content identifier on Blossom storage servers, verifying tamper-proof delivery.

→Blob ID = SHA-256(AES_GCM_Ciphertext)
FACT 23·BLOSSOM SEPARATION
Zero Storage Knowledge
Split Secret

Encrypted media hosted on Blossom; key sent via Signal E2EE

Encrypted voice recording bytes are stored on Blossom servers, while the 256-bit key and 96-bit nonce needed for decryption are transmitted inside the Signal end-to-end encrypted message.

→Encrypted Blob ➔ Blossom Server · Decryption Secret ➔ Signal Ratchet
FACT 24·AT-REST ENCRYPTION
Drift + SQLCipher
SQLCipher 256

Local database encrypted via SQLCipher with 256-bit key

Persistent client-side data uses Drift over SQLite backed by SQLCipher. The 256-bit database encryption key is generated via Random.secure() and sealed in the hardware keystore via flutter_secure_storage.

→Drift ORM ➔ SQLite ➔ SQLCipher (AES-256 CBC + HMAC-SHA512)
FACT 25·HARDENING PRAGMA
cipher_memory_security
RAM Wiped

SQLCipher memory-security explicitly enabled via PRAGMA

MNDO executes 'PRAGMA cipher_memory_security = ON;' during database initialization. This instructs SQLCipher to zero out decrypted cache pages from RAM when freed, preventing memory dump inspection.

→PRAGMA cipher_memory_security = ON;
FACT 26·TOPOLOGY
3 Independent Relays
Multi-Relay

Three configured default Nostr relays out of the box

The default build connects to relay.damus.io, nos.lol, and relay.snort.social simultaneously. Messages route through any active relay; the loss of one or two relays does not halt communication.

→Relays: relay.damus.io · nos.lol · relay.snort.social
FACT 27·AUDITED REALITY
Defensible Facts
Mathematically True

The core claims that are mathematically indisputable

What MNDO genuinely delivers is extraordinary: 14.9 trillion human-readable usernames (~127× all humans who ever lived), 2¹²⁸ identity entropy states (~3.4 × 10³⁸), 0 central servers, and per-message Double Ratchet keys.

→14.9T Usernames · 2¹²⁸ Identity States · 0 Phone Numbers · 100% Verifiable
VERIFICATION AUDIT

Directly Inspected Source Files

Every formula, dictionary length, encryption parameter, and key derivation routine on this page was directly audited from these files in the MNDO repository:

TRANSPARENT SYSTEM

Explore How MNDO Operates in Practice

From our 1ms client-side key derivation to Signal ratcheting over Nostr relay meshes, dive into our technical diagrams and interactive architecture guides.