#Key and Hash Sizes

The Encoding Primer showed how binary bytes become readable text through Base16, Base64, and Base58. The Post-Quantum Cryptography page explained why Avatarnet chose its five algorithms and why they produce keys and signatures that are dramatically larger than classical alternatives. This page puts both together: every key, hash, and signature in the protocol, with its exact size in bytes and in the encodings you will encounter on the wire.

Before looking at the sizes, it helps to understand what these cryptographic objects actually are and what role each one plays.

#What is a public key?

A public key is a piece of data you share with the world. It is published alongside your .avtr domain so that anyone can look it up. Its only job is verification: given a signature and a message, the public key lets anyone confirm that the message was signed by the holder of the corresponding private key. The public key cannot sign anything, and knowing it does not let you forge signatures or impersonate the owner.

#What is a private key?

A private key is the secret half of the keypair. It never leaves your device. Its job is signing: it takes a message and produces a signature that only this specific private key could have created. Anyone who has the public key can verify the signature, but nobody can work backwards from the signature to discover the private key.

#What is a signature?

A signature is proof of authorship. It is a piece of data produced by combining a message with a private key. It answers one question: did the owner of this keypair approve this exact message? If even a single character of the message changes, the signature becomes invalid.

#What is a hash?

A hash is a fingerprint. It takes any input, regardless of length, and produces a fixed-size output. The same input always produces the same hash. Different inputs produce different hashes. And there is no way to recover the original input from the hash. On Avatarnet, the hash of an engram becomes its permanent address.

#How they work together

You write an engram:

  1. SHA-512(content)              → Content hash      (the address)
  2. Sign(hash, private key)       → Signature         (proof you wrote it)
  3. Publish: [content + hash + signature]

Anyone verifies it:

  1. SHA-512(content)              → Recalculate hash  (does it match?)
  2. Verify(signature, public key) → Valid?            (did the author sign it?)

No secrets needed to verify. The public key and the content are enough.

Everything below is organized around the three concepts introduced on the Avatar & Mind page. Your Network Estate is your place on the network, protected by one cryptographic pillar. Your Avatar is the body, protected by one pillar. Your Mind is everything the body holds, protected by three more. Five pillars in total, each with its own algorithms and sizes.

#Five Keys at a Glance

Before going pillar by pillar, here are all five keypairs the protocol uses, side by side. Four are required for every Avatar; the fifth is optional and only generated when a hosting provider registers a .host brand.

All four required keys live encrypted on the user's device, with an Argon2id-derived encryption key from the user's password. The optional Provider Key is generated only when a hosting provider chooses to register a .host brand. There is no remote custody, no DKG, no protocol-level inheritance: every key is local, and losing the device without backups means losing the keys, the same way Bitcoin treats wallet keys.

The Avatar / Estate split shapes which keys do what. The Estate Key controls the hosting position (the sellable property), and the Identity Key controls authorship (the unsellable identity). When you sell an Estate, the Estate Key rotates to the buyer; the Identity Key stays with you. This is why one person can move between estates while keeping their verifier track record, and why an estate can change hands without changing its preserved Mind.

The per-pillar sub-tables below show the exact bytes each key produces in signatures, hashes, and encodings.

#🏠 Network Estate (your place on the network)

The Network Estate is your accumulated hosting position on the network: your level, your boost badges, and your guaranteed backup slots. It is controlled by its own keypair, the Estate Key, which is separate from the Identity Key that proves who you are. This separation means that compromising one key does not compromise the other.

#🏠🔑 Estate Ownership

This estate is yours.

The Estate Key uses the same algorithm and sizes as the Identity Key below, but the two keypairs are generated independently and serve different purposes. The Estate Key controls your hosting position. The Identity Key proves your authorship.

#👤 Avatar (the body)

The Avatar is your cryptographic identity, a separate keypair from the Estate Key, that signs every engram you write and every update you make. It has one pillar to protect it, and the sizes below are what that pillar actually looks like on the wire.

#👤🪪 Avatar Identity

This avatar is you.

The public key is what the Avatar Name System stores alongside your .avtr domain, so that anyone looking up einstein.avtr can retrieve the same 64 bytes and verify any signature you have ever produced. The private key never leaves your device.

#🧠 Mind (what the body holds)

The Mind is everything you write or record about yourself, stored as engrams: stories, lessons, memories, anything you want preserved. Three pillars protect it, one for authorship, one for integrity, and one for privacy. Each pillar has its own algorithms and its own sizes, and they are shown separately below so it is easy to see which bytes are doing what.

#🧠✍️ Mind Authorship

You wrote this engram.

Every commit your Avatar publishes carries a signature produced by the SLH-DSA Identity Key that defines the Avatar itself. Each commit signs the root of a Merkle DAG containing every engram you have written, so a single signature covers many engrams at once. The signature is what proves authorship to anyone who later reads your words, and it is dramatically larger than a classical signature because post-quantum hash-based signing requires far more data to remain secure.

For context, Ed25519 (the algorithm used by Bitcoin, Signal, and SSH) produces 64-byte signatures. SLH-DSA signatures are roughly 780 times larger, which sounds extreme until you remember that the smaller signatures have an expiration date measured in years, while the larger ones are expected to hold up for decades beyond the arrival of practical quantum computers.

The 49 KB cost is paid once per commit, not once per engram. An Avatar with 5,000 engrams across hundreds of commits still pays only one signature per commit cycle, and a single commit covering a thousand new engrams costs the same 49 KB as a commit covering one. The absolute size of the signature stops mattering as soon as it amortizes across an entire Mind snapshot.

#🧠🔗 Mind Integrity

Your words unchanged, backed up forever.

Integrity is what guarantees that a single character of your engram cannot be altered without the network noticing immediately. Every engram, memory, and experience is hashed with SHA-512, and that hash becomes its permanent content address. Change anything and the hash changes, and every parent in the hierarchy changes with it.

The hash itself is small, yet it is the foundation on which all the larger structures rest, because every signature ultimately signs one of these 64-byte fingerprints rather than the full content.

#🧠🔐 Mind Privacy

Only you can read it.

Privacy applies to any engram you mark private or personal. The content is encrypted with AES-256-GCM so that even the machines hosting it cannot read a single word, and the encryption key is exchanged using ML-KEM-1024, a post-quantum key encapsulation mechanism that replaces classical Diffie-Hellman approaches like X25519.

The AES key itself stays small, but the ML-KEM structures that let two Avatars agree on that key are significantly larger than their classical predecessors. That extra weight is another consequence of choosing algorithms that will outlast quantum computers, and it is the same tradeoff the authorship signatures make, just expressed in a different shape.

#🌐 Network infrastructure (supporting keys)

The five pillars cover what users see and care about. Beneath them, the protocol uses two more keypairs at the network infrastructure layer. The Node Key identifies a physical machine on the network, generated automatically the first time the software runs. The optional Provider Key signs the DHT record that maps a .host domain to the fleet of machines underneath it, generated only when a hosting provider chooses to register a public brand.

Both keypairs use the same SLH-DSA-SHA2-256f sizes as the Estate Key and the Identity Key, because every signature on Avatarnet runs through the same post-quantum algorithm. The Node Key answers "which machine am I talking to?" The Provider Key answers "does this .host brand really point at this fleet of machines?" A solo user running their own Avatar on their own machine has a Node Key but no Provider Key, since they have nothing to brand.

#What you see on screen

#Avatarnet's addressing model

Avatarnet:  chatp://einstein.avtr             (human-readable domain)
                     │
                     ↓  network lookup
            public_key:a1b2c3d4...            (SLH-DSA public key)
                     │
                     ↓  network lookup
            [PeerID@oxfordarchive.host]       (where the data lives)

Like DNS:   google.com  →  142.250.80.46      (human name → IP)
Like us:    einstein.avtr → key → node        (human name → key → location)

Users rarely see raw keys in daily use, because the Avatar Name System maps human-readable .avtr names to cryptographic identities behind the scenes. Encoding matters most under the hood, where keys need to travel through URLs, configuration files, QR codes, and paper backups without losing a single bit along the way.

#How a Peer ID is constructed

Every machine on the network has a Peer ID, a compact identifier derived from the machine's public key. The Peer-to-Peer page covers how the network uses Peer IDs. Here, we focus on how they are constructed.

Peer ID = base58btc( multihash( SHA-256( protobuf( public_key ) ) ) )

Steps:
  1. Take SLH-DSA public key                     (64 bytes)
  2. Wrap in protobuf CryptoKey                  (~68 bytes, adds type + length prefix)
  3. SHA-256 hash the protobuf                   (32 bytes)
  4. Prepend multihash header                    (34 bytes, 0x12 SHA-256 + 0x20 length)
  5. Encode as base58btc                         (~46 characters)

Step 3 is where Avatarnet's post-quantum keys change the construction. With classical ed25519 (32 bytes), the protobuf-wrapped key is only 36 bytes, small enough to embed directly using an identity multihash. That skips the hash step entirely and produces the familiar 12D3KooW... prefix that libp2p users recognize. SLH-DSA's 64-byte public key pushes the wrapped result past libp2p's 42-byte inline threshold, so the key is SHA-256 hashed before encoding. The result is shorter than the raw key but no longer contains the key itself, only a fingerprint of it.

In multiaddr format, a node's full network address combines its IP, port, and Peer ID into a single string:

/ip4/198.51.100.0/tcp/4242/p2p/QmYwAPJzv5CZsnN...

This is the address the network stores when locating the machine that holds a given avatar's data.

Now that you have seen the sizes and know the algorithms behind them, the final piece is understanding how each algorithm actually works under the hood: how SLH-DSA builds signatures from Merkle trees, how SHA-512 fingerprints content, how AES-256-GCM encrypts engrams, and how ML-KEM lets two Avatars agree on a shared secret. That is the subject of Signing and Encryption.