diff --git a/docs/reference/architecture.md b/docs/reference/architecture.md
index cebcdf99..3e1028a3 100644
--- a/docs/reference/architecture.md
+++ b/docs/reference/architecture.md
@@ -2,9 +2,9 @@
 
 ### Node ID
 
-In order to interact with other nodes, PolyKey uses a unique node ID identifier.
+In order to interact with other nodes, Polykey uses a unique node ID identifier.
 Currently, the fingerprint of the root public key of a keynode is calculated
-using a sha256 has function and is then transformed into base64 encoding to
+using a SHA256 hash function and is then transformed into base64 encoding to
 obtain a keynode’s Node ID. This will consistently produce a string of 44
 characters. In the future, PolyKey will used an ed25519 public key directly
 encoded using base64 to create the Node ID. As the signature of ed25519 keys can
diff --git a/docs/reference/architecture/DES.md b/docs/reference/architecture/DES.md
new file mode 100644
index 00000000..72d0acb8
--- /dev/null
+++ b/docs/reference/architecture/DES.md
@@ -0,0 +1,122 @@
+# Symmetric Data Encapsulation Scheme (DES)
+
+Polykey’s state is completely stored in the database. This means everything
+critical to the system's function—keys, metadata, and configurations—is written
+to disk. To ensure the security and integrity of this data, we encrypt the
+database using a **32-byte Data Encryption Key (DB Key)** and the
+**XChaCha20-Poly1305** symmetric encryption algorithm, provided by
+**libsodium**.
+
+## Why We Use Symmetric Encryption
+
+Encryption is non-negotiable for a system like Polykey, where data security is a
+core priority. Symmetric encryption is used for:
+
+- **Confidentiality** - Ensuring database contents are only accessible to the
+  rightful owner.
+- **Integrity** - Preventing unauthorized tampering by detecting any
+  modifications.
+- **Performance** - Symmetric encryption is significantly faster than asymmetric
+  encryption for large datasets.
+
+## Database Encryption Key (DB Key)
+
+### **How the DB Key Works**
+
+The DB Key is a **randomly generated 32-byte key** that encrypts all database
+content. This key is stored on disk, but never in plaintext—it is always
+encrypted before being written to storage.
+
+The DB Key is used to encrypt and decrypt the entire database, meaning that
+without it, **all data in the system is inaccessible**.
+
+### **Why the DB Key is Not Derived from the Root Key**
+
+A common approach in cryptographic systems is to derive all keys from a single
+root key. However, this is not how Polykey manages database encryption. The DB
+Key is independent from the root key for the following reasons:
+
+1. **Key Rotation & Flexibility**  
+   If the root key were used to derive the DB Key, changing the root key would
+   require re-encrypting the entire database. This would be a **catastrophic**
+   operation in terms of efficiency and usability. Instead, by keeping the DB
+   Key separate, the database can remain encrypted even when the root key is
+   changed.
+
+2. **Minimizing Attack Surfaces**  
+   If an attacker compromises the root key, they still cannot access the
+   database contents without the DB Key. This adds an extra layer of security.
+
+3. **Persistence Across Keypair Changes**  
+   In Polykey, root keypairs can be swapped out periodically for security
+   reasons (like how passwords should be rotated). By decoupling the DB Key, the
+   database encryption remains stable across key rotations.
+
+## Encryption Algorithm: XChaCha20-Poly1305
+
+Polykey uses **XChaCha20-Poly1305**, a widely respected symmetric encryption
+scheme known for its:
+
+- **256-bit key size** - Strong encryption without performance tradeoffs.
+- **192-bit nonce** - Ensures nonce reuse attacks are virtually impossible.
+- **Authenticated encryption** - Includes integrity checks, so any unauthorized
+  modifications are detected.
+
+### **Why XChaCha20-Poly1305?**
+
+1. **Nonce Misuse Resistance**  
+   Unlike AES-GCM, which has strict nonce reuse requirements, XChaCha20 allows
+   for random nonce generation with no risk of catastrophic failures.
+
+2. **High Performance**  
+   Stream ciphers like XChaCha20 are significantly faster than block ciphers
+   like AES in many scenarios, making them well-suited for encrypting large
+   datasets.
+
+3. **Compatibility with Libsodium**  
+   Libsodium is a battle-tested cryptographic library that provides a simple and
+   secure implementation of XChaCha20-Poly1305, reducing the risk of
+   implementation errors.
+
+## Key Rotation & Secure Storage
+
+### **Key Rotation Strategy**
+
+Regular key rotation is a fundamental security practice. However, since
+re-encrypting an entire database is computationally expensive, Polykey manages
+key rotations in a way that minimizes disruption:
+
+1. **The DB Key is swapped periodically** - This reduces long-term key exposure.
+2. **New keys are securely generated and encrypted using KEM (Key Encapsulation
+   Mechanism)** - This ensures a smooth transition without exposing old
+   encrypted data.
+3. **Polykey handles the transition automatically** - Users do not need to worry
+   about database re-encryption when keypairs are rotated.
+
+### **How the DB Key is Stored**
+
+The DB Key is **never stored in plaintext**. Instead, it is encrypted and saved
+as a **JWE (JSON Web Encryption) file**. This file is securely managed to ensure
+that only authorized nodes can decrypt and use it.
+
+## Security Considerations
+
+- **Loss of the DB Key = Complete Data Loss**  
+  If the encrypted DB Key is lost, **all data within Polykey is permanently
+  inaccessible**. Users must ensure backups are properly managed.
+
+- **Frequent Key Rotation is Good Practice**  
+  Regularly rotating the DB Key prevents long-term exposure and mitigates risks
+  from potential future cryptographic weaknesses.
+
+- **Secure Backup Management is Critical**  
+  Since Polykey does not store plaintext recovery keys, **users must securely
+  back up their 24-word recovery code** to ensure they can regain access if
+  needed.
+
+## Conclusion
+
+The **Symmetric Data Encapsulation Scheme (DES)** is a critical component of
+Polykey's security model. By leveraging XChaCha20-Poly1305 for high-speed
+encryption and ensuring the **DB Key remains independent from the root key**,
+Polykey maintains a **balance between security, performance, and usability**.
diff --git a/docs/reference/architecture/README.md b/docs/reference/architecture/README.md
new file mode 100644
index 00000000..0f911165
--- /dev/null
+++ b/docs/reference/architecture/README.md
@@ -0,0 +1,5 @@
+import DocCardList from '@theme/DocCardList';
+
+# Architecture
+
+<DocCardList />
diff --git a/docs/reference/architecture/ecis.md b/docs/reference/architecture/ecis.md
new file mode 100644
index 00000000..2f9f620b
--- /dev/null
+++ b/docs/reference/architecture/ecis.md
@@ -0,0 +1,129 @@
+# Elliptic Curve Integrated Encryption Scheme (ECIES)
+
+## Overview
+
+Polykey's security model is built around **Elliptic Curve Integrated Encryption
+Scheme (ECIES)**. ECIES is a hybrid cryptosystem that combines the efficiency of
+symmetric encryption with the security of asymmetric encryption, making it ideal
+for key exchange and encrypted communication.
+
+At its core, ECIES allows secure communication between parties without requiring
+them to share a secret key in advance. Instead, it uses elliptic curve
+cryptography (ECC) to derive a shared secret dynamically, ensuring both
+confidentiality and authenticity.
+
+## Why Polykey Uses ECIES
+
+Polykey leverages ECIES because it provides:
+
+- **Strong security**: ECC-based key exchange ensures forward secrecy.
+- **Efficient performance**: ECC is computationally faster than RSA at
+  equivalent security levels.
+- **Hybrid encryption**: Uses symmetric encryption for bulk data and asymmetric
+  encryption for key exchange.
+- **Secure key encapsulation**: Keys are encrypted in a way that prevents
+  exposure during transmission.
+
+## How ECIES Works
+
+ECIES works by using Elliptic Curve Diffie-Hellman (ECDH) for key exchange and a
+symmetric cipher for encryption.
+
+The encryption process follows these steps:
+
+1. **Key Exchange**:
+
+- The sender generates a temporary ephemeral key pair.
+- The sender derives a shared secret using their ephemeral private key and the
+  recipient's public key.
+
+2. **Key Derivation**:
+
+- The shared secret is used to generate encryption keys through a Key Derivation
+  Function (KDF).
+
+3. **Encryption**:
+
+- A symmetric encryption algorithm (e.g., XChaCha20-Poly1305 ) encrypts the
+  plaintext.
+- An authentication tag is generated to prevent tampering.
+
+4. **Transmission**:
+
+- The ciphertext, ephemeral public key, and authentication tag are sent to the
+  recipient.
+
+5. **Decryption**:
+
+- The recipient uses their private key to derive the shared secret.
+- The symmetric key is reconstructed using the same KDF.
+- The ciphertext is decrypted, and authenticity is verified.
+
+## ECIES in Polykey
+
+Polykey uses ECIES as the foundation for secure communication, storage, and key
+management. Specifically, it is used for:
+
+- **Key Encapsulation Mechanism (KEM)**: Encapsulating encryption keys for
+  secure storage.
+- **Node-to-Node Communication**: Establishing secure tunnels between Polykey
+  nodes.
+- **Key Exchange**: Securely transferring symmetric encryption keys for
+  encrypted storage.
+
+### Key Encapsulation and Secure Storage
+
+Polykey encrypts sensitive keys using ECIES-based encapsulation. This means:
+
+- The Data Encryption Key (DB Key) is never stored in plaintext.
+- The DB Key is wrapped using ECIES before being saved.
+- Only an authenticated node with the correct private key can unwrap the DB Key
+  and decrypt the database.
+
+### Secure Messaging Between Nodes
+
+When Polykey nodes communicate, they exchange keys using ECIES. This allows them
+to:
+
+- Establish a secure session without pre-sharing a secret key.
+- Prevent man-in-the-middle attacks by ensuring only authorized nodes can
+  decrypt messages.
+- Authenticate each other using their public-private key pairs.
+
+## Why ECIES is Preferred Over RSA
+
+Historically, RSA-based encryption was the standard for key exchange, but ECIES
+provides several advantages:
+
+| Feature             | ECIES (ECC) | RSA                           |
+| ------------------- | ----------- | ----------------------------- |
+| **Key Size (bits)** | 256         | 2048                          |
+| **Security Level**  | Stronger    | Weaker at equivalent key size |
+| **Performance**     | Faster      | Slower                        |
+| **Key Exchange**    | Supported   | Not ideal for key exchange    |
+
+Because ECIES achieves the same level of security as RSA with much smaller key
+sizes, it is the preferred choice for modern cryptographic systems like Polykey.
+
+## Future-Proofing Against Quantum Attacks
+
+Polykey is designed to evolve with cryptographic advancements. While ECIES is
+secure today, quantum computers could potentially break ECC in the future. When
+quantum-resistant encryption becomes practical, Polykey will migrate to a
+Post-Quantum Integrated Encryption Scheme (PQIES).
+
+## Conclusion
+
+ECIES is at the heart of Polykey's encryption model, providing secure,
+efficient, and scalable key exchange. By combining elliptic curve cryptography
+with hybrid encryption techniques, Polykey ensures strong security, efficient
+performance, and forward secrecy.
+
+Polykey's implementation of ECIES allows:
+
+- Secure key exchange without pre-shared secrets.
+- Confidential and authenticated communication between nodes.
+- Safe and efficient key storage using encapsulated encryption.
+
+As cryptographic standards evolve, Polykey remains committed to using the most
+secure and performant encryption schemes available.
diff --git a/docs/reference/architecture/encryption-algorithms.md b/docs/reference/architecture/encryption-algorithms.md
new file mode 100644
index 00000000..131e49e3
--- /dev/null
+++ b/docs/reference/architecture/encryption-algorithms.md
@@ -0,0 +1,84 @@
+# Encryption Algorithms and Security Considerations
+
+## Overview
+
+Polykey's security model is built on modern cryptographic principles to ensure
+confidentiality, integrity, and authentication across all operations. This
+document outlines the encryption algorithms Polykey employs, their strengths,
+and key security considerations for maintaining a secure system.
+
+## Encryption Algorithms Used in Polykey
+
+Polykey integrates a hybrid cryptosystem, combining symmetric and asymmetric
+cryptographic algorithms for optimal security and performance.
+
+### Symmetric Encryption
+
+- **AES-GCM (Advanced Encryption Standard - Galois/Counter Mode)**
+  - Used for encrypting data at rest and in transit.
+  - Provides both encryption and authentication in a single step.
+  - 256-bit key length for strong security.
+  - Resistant to padding oracle attacks due to its authenticated encryption
+    structure.
+
+### Asymmetric Encryption
+
+- **X25519 (Elliptic Curve Diffie-Hellman)**
+
+  - Used for key exchange and secure session establishment.
+  - Based on Curve25519, which is efficient and resistant to side-channel
+    attacks.
+  - Provides forward secrecy by generating ephemeral session keys.
+
+- **Ed25519 (Elliptic Curve Digital Signature Algorithm)**
+  - Used for signing and verifying messages and transactions.
+  - Strong resistance to side-channel attacks.
+  - Deterministic signatures prevent nonce-related vulnerabilities.
+
+### Key Encapsulation Mechanism (KEM)
+
+- **ECIES (Elliptic Curve Integrated Encryption Scheme)**
+  - Facilitates secure encryption of symmetric keys during key exchange.
+  - Uses elliptic curve cryptography for efficient and secure key wrapping.
+  - Ensures confidentiality and authenticity of the exchanged key.
+
+## Security Considerations
+
+### 1. Key Management
+
+- **Recovery Codes:** Users must securely store their 24-word recovery code, as
+  Polykey does not store private keys.
+- **Key Rotation:** Regular key rotation mitigates the risk of long-term key
+  exposure.
+- **Secure Storage:** Encrypted key material must be stored in a secure
+  environment to prevent unauthorized access.
+
+### 2. Forward Secrecy
+
+- Polykey ensures forward secrecy through ephemeral key exchange using X25519.
+- If a private key is compromised, past communications remain secure.
+
+### 3. Authentication & Integrity
+
+- Digital signatures (Ed25519) ensure data authenticity and prevent tampering.
+- Authenticated encryption (AES-GCM) guarantees data integrity.
+
+### 4. Resistance to Quantum Threats
+
+- While current encryption methods are secure, future quantum computing
+  advancements may break classical cryptography.
+- Polykey's roadmap includes exploring post-quantum cryptographic alternatives.
+
+### 5. Attack Surface Reduction
+
+- Minimizing reliance on outdated cryptographic algorithms.
+- Eliminating common cryptographic pitfalls such as RSA-based key exchanges,
+  which are vulnerable to decryption with modern computing power.
+
+## Conclusion
+
+Polykey employs a combination of AES-GCM, X25519, Ed25519, and ECIES to ensure
+strong security across all cryptographic operations. By following best practices
+in key management, forward secrecy, and attack surface reduction, Polykey
+maintains a robust security posture. Future updates may incorporate post-quantum
+cryptographic schemes to address emerging threats.
diff --git a/docs/reference/architecture/hybrid-cryptosystem.md b/docs/reference/architecture/hybrid-cryptosystem.md
new file mode 100644
index 00000000..1392ceb2
--- /dev/null
+++ b/docs/reference/architecture/hybrid-cryptosystem.md
@@ -0,0 +1,91 @@
+# Hybrid Cryptosystem
+
+Polykey's security model is built on a Hybrid Cryptosystem, which combines both
+symmetric and asymmetric encryption to achieve secure communication, storage,
+and identity management.
+
+## Why Hybrid Encryption?
+
+Encryption is necessary to protect sensitive data, but different encryption
+methods serve different purposes. A hybrid cryptosystem merges the strengths of
+both:
+
+**Asymmetric Encryption** (Public and Private Key Pairs)
+
+- Used for securely exchanging encryption keys
+- Allows verification of signatures
+- Ensures secure communication without prior key exchange
+
+**Symmetric Encryption** (Shared Secret Keys)
+
+- Used for encrypting large amounts of data efficiently
+- Faster than asymmetric encryption
+- Requires a secure method to exchange keys
+
+By combining these two, Polykey ensures security in transit, at rest, and in
+use.
+
+## Polykey's Implementation of Hybrid Cryptography
+
+Polykey's hybrid cryptosystem is based on the Elliptic Curve Integrated
+Encryption Scheme (ECIES) and consists of two primary mechanisms:
+
+1. **Key Encapsulation Mechanism (KEM)**
+
+- Uses symmetric encryption to securely exchange a symmetric key.
+- This ensures that even if an attacker intercepts the communication, they
+  cannot derive the encryption key without access to the private key.
+
+2. **Data Encapsulation Scheme (DES)**
+
+- Uses symmetric encryption (XChaCha20-Poly1305) to encrypt all Polykey data.
+- This ensures that once the symmetric key is established, encryption is fast
+  and efficient.
+
+### How This Works in Polykey
+
+- The sender encrypts data using a symmetric key.
+- This symmetric key is then encrypted using the recipient's public key.
+- The recipient decrypts the symmetric key using their private key.
+- Once the symmetric key is obtained, it is used to decrypt the original data.
+
+This method keeps encryption fast and secure, reducing computational overhead
+while maintaining strong security guarantees.
+
+## Why Not Just Use One Type of Encryption?
+
+Each encryption method has limitations:
+
+**Asymmetric encryption is slow**
+
+- Encrypting large amounts of data with public-private key pairs is inefficient.
+- It is only practical for encrypting small pieces of data, like symmetric keys.
+
+**Symmetric encryption needs secure key exchange**
+
+- If a secret key is leaked or intercepted, the encrypted data is compromised.
+- It requires a secure way to distribute and manage encryption keys.
+
+A **hybrid cryptosystem** provides the best of both worlds:
+
+- **Asymmetric encryption** protects the key exchange.
+- **Symmetric encryption** handles bulk data encryption efficiently.
+
+## Future-Proofing with Post-Quantum Cryptography
+
+Polykey currently uses Elliptic Curve Cryptography (ECC) for its hybrid system,
+specifically **Ed25519**. However, quantum computing could break ECC in the
+future. When quantum-safe encryption becomes more practical, Polykey will
+upgrade to a Post-Quantum Integrated Encryption Scheme to maintain long-term
+security.
+
+## Conclusion
+
+A hybrid cryptosystem is essential for balancing security, efficiency, and
+scalability. By leveraging symmetric encryption for key exchange and symmetric
+encryption for data protection, Polykey ensures robust security while keeping
+performance high.
+
+Polykey's use of ECIES, KEM, and DES provides a secure foundation for encrypted
+communication, identity management, and data storage. This hybrid approach
+ensures that data remains protected, both now and in the future.
diff --git a/docs/reference/architecture/json-webx-standards.md b/docs/reference/architecture/json-webx-standards.md
new file mode 100644
index 00000000..6d4de023
--- /dev/null
+++ b/docs/reference/architecture/json-webx-standards.md
@@ -0,0 +1,132 @@
+# JSON Web X Standards in Polykey
+
+## Overview
+
+Polykey uses the **JSON Web X (JWX)** standards to represent keys, encrypt data,
+and authenticate messages. These standards provide interoperability with other
+cryptographic systems, making Polykey flexible and compatible across different
+implementations.
+
+The core JSON Web X standards used in Polykey are:
+
+- **JSON Web Token (JWT)**: Used to package claims in a structured format.
+- **JSON Web Algorithm (JWA)**: Defines cryptographic algorithms used in
+  JSON-based security applications.
+- **JSON Web Signature (JWS)**: Ensures integrity and authenticity by signing
+  messages.
+- **JSON Web Encryption (JWE)**: Encrypts messages to ensure confidentiality.
+- **JSON Web Key (JWK)**: Represents cryptographic keys in a JSON format.
+
+## Why Polykey Uses JSON Web X Standards
+
+The JWX family of standards was chosen for Polykey due to:
+
+- **Interoperability**: JSON-based cryptographic systems are widely used and
+  supported.
+- **Flexibility**: The standards allow different cryptographic algorithms and
+  key representations.
+- **Usability**: JSON is a widely understood and easily parsed format.
+- **Security**: Strong cryptographic primitives ensure integrity,
+  confidentiality, and authenticity.
+
+However, some of these standards have historically been too flexible, which has
+led to implementation mistakes. Despite this, JWX standards are generally far
+better than **legacy PKCS** (Public Key Cryptography Standards), which are more
+difficult to understand and implement correctly.
+
+## Understanding JSON Web Tokens (JWT)
+
+JWT is a container format that holds structured claims, typically for
+authentication or authorization. It consists of:
+
+1. **Header**: Specifies the algorithm and type.
+2. **Payload**: Contains claims (e.g., user data, permissions, expiration).
+3. **Signature**: Ensures the integrity and authenticity of the token.
+
+Example JWT payload:
+
+```json
+{
+  "userId": "12345",
+  "username": "johndoe",
+  "exp": 1716239022
+}
+```
+
+WT is not inherently secure. Without encryption, the payload is base64-encoded
+but not hidden. If sensitive data is included, it must be encrypted using JWE.
+
+## JSON Web Signature (JWS) vs. JSON Web Encryption (JWE)
+
+### JSON Web Signature (JWS)
+
+JWS represents signed data. This ensures the integrity and authenticity of a
+message.
+
+- Signed with a symmetric key: Provides integrity & authenticity.
+- Signed with an asymmetric key: Provides integrity, authenticity, and
+  non-repudiation.
+
+JWS does not encrypt data, it only verifies that the message has not been
+tampered with.
+
+### JSON Web Encryption (JWE)
+
+JWE is used to encrypt data. It supports both symmetric and asymmetric
+encryption.
+
+- Encrypted with a **symmetric key**: Efficient but requires shared key
+  distribution.
+- Encrypted with an **asymmetric key**: More secure for key exchange but
+  computationally heavier.
+
+If a payload needs both signing and encryption, the process is:
+
+1. Sign the data with JWS.
+2. Encrypt the signed data with JWE.
+
+## How Polykey Uses JWX
+
+### JWK and Key Management
+
+Polykey stores cryptographic keys in JSON Web Key (JWK) format. This allows
+standardized key representation and exchange.
+
+- **Public and private keys** are encoded as JWKs.
+- **JWKs are used in Polykey’s Key Encapsulation Mechanism** (KEM) to protect
+  symmetric keys.
+- **JWKs can be exported/imported**, making them interoperable with other
+  systems.
+
+### Storing JWX Objects
+
+JWX objects in Polykey can be stored in three representations:
+
+1. **Compact Representation**: Short, URL-safe format (used in JWTs).
+2. **General Representation**: More flexible JSON structure.
+3. **Flattened Representation**: Used for encrypted JWKs, ensuring a structured
+   encryption format.
+
+Polykey specifically encrypts JWKs as Flattened JWE JSON, meaning private keys
+are stored securely while remaining accessible when needed.
+
+## Future of JWX in Polykey
+
+There are alternative standards, like **PASETO** (Platform-Agnostic Security
+Tokens) and **PASERK** (PASETO Embedded Key Format), that attempt to reduce
+security risks found in JWX. However, these standards are not widely adopted
+yet, and Polykey continues to rely on JWX for its flexibility and industry
+support.
+
+## Conclusion
+
+JSON Web X standards form the backbone of Polykey’s security model. They
+provide:
+
+- Interoperability with modern cryptographic systems.
+- Secure key management through JWK and JWE.
+- Authentication & Integrity using JWS.
+- Confidentiality via JWE encryption.
+
+By leveraging these standards, Polykey ensures its encryption and authentication
+mechanisms are both robust and flexible.
diff --git a/docs/reference/architecture/kem.md b/docs/reference/architecture/kem.md
new file mode 100644
index 00000000..b346483f
--- /dev/null
+++ b/docs/reference/architecture/kem.md
@@ -0,0 +1,83 @@
+# Asymmetric Key Encapsulation Mechanism (KEM)
+
+Polykey's hybrid cryptosystem relies on Key Encapsulation Mechanism (KEM). to
+securely encrypt symmetric keys using asymmetric cryptography. This allows
+Polykey to efficiently encrypt and decrypt the database key (DB Key) while
+maintaining strong security.
+
+## What is KEM?
+
+A **Key Encapsulation Mechanism (KEM)** is a cryptographic protocol used to
+encrypt a symmetric key using an asymmetric keypair. Instead of encrypting
+entire messages with asymmetric encryption, which is inefficient, KEM
+encapsulates a randomly generated symmetric key, which is then used for
+encrypting actual data.
+
+In Polykey, KEM is used to encrypt the DB Key using an Ed25519 public key. The
+encrypted DB Key can then be safely stored on disk, ensuring that only the
+rightful owner can decrypt and access the database.
+
+## How KEM Works in Polykey
+
+KEM in Polykey is implemented using Elliptic Curve Diffie-Hellman
+Ephemeral-Static (ECDH-ES). Here is how it works:
+
+1. **Key Generation**
+
+- A 32-byte Ed25519 keypair is generated.
+- The public key is shared, and the private key is kept secret.
+
+2. **Encapsulation**
+
+- A random symmetric key is generated.
+- This symmetric key is encrypted using the receiver's Ed25519 public key.
+- The encrypted symmetric key is stored as a JWE (JSON Web Encryption) file.
+
+3. **Decapsulation**
+
+- The receiver uses their Ed25519 private key to decrypt the encapsulated
+  symmetric key.
+- This decrypted symmetric key is then used to decrypt the DB Key.
+- Once the DB Key is restored, the full database can be decrypted and accessed.
+
+## Why Polykey Uses KEM
+
+Using KEM allows Polykey to securely encrypt keys without storing them in
+plaintext. This provides multiple advantages:
+
+- **Security**: If an attacker compromises the database, they still cannot
+  decrypt it without the encapsulated DB Key.
+- **Efficiency**: Instead of encrypting the entire database with an asymmetric
+  key, only the DB Key is encapsulated.
+- **Forward Secrecy**: By using ephemeral sender keys, old messages remain
+  protected even if a private key is compromised.
+- **Decoupling of Encryption Layers**: The DB Key remains independent of user
+  keypairs, allowing key rotations without requiring full database
+  re-encryption.
+
+## Polykey's Implementation of KEM
+
+Polykey uses a customized KEM implementation based on ECDH-ES:
+
+- The sender generates an ephemeral keypair for the encryption process.
+- The receiver's public key is used to derive a shared secret.
+- This shared secret is used to encrypt the DB Key using XSalsa20-Poly1305.
+- The resulting ciphertext is stored in a JWE file on disk.
+
+This ensures that even if an attacker gains access to the encrypted DB Key file,
+they cannot decrypt it without the private key.
+
+## Key Takeaways
+
+- **KEM** encapsulates the DB Key, making Polykey's encryption secure and
+  efficient.
+- **Ed25519 keys** are used for lightweight and strong asymmetric encryption.
+- **JWEs** files store encrypted keys, ensuring that private data remains
+  protected.
+- **ECDH-ES** provides forward secrecy, reducing the impact of compromised keys.
+- **XSalsa20-Poly1305** is used to encrypt the DB Key, balancing speed and
+  security.
+
+By using KEM, Polykey keeps database encryption secure while maintaining
+efficiency, ensuring that even if encrypted key files are leaked, they remain
+useless without the correct private key.
diff --git a/docs/reference/architecture/key-encryption-management-storage.md b/docs/reference/architecture/key-encryption-management-storage.md
new file mode 100644
index 00000000..c89d5160
--- /dev/null
+++ b/docs/reference/architecture/key-encryption-management-storage.md
@@ -0,0 +1,117 @@
+# Key Management and Storage in Polykey
+
+Key management is the backbone of secure systems, dictating how encryption keys
+are generated, stored, shared, and revoked. In Polykey, key management is
+designed to balance security, usability, and cryptographic best practices,
+ensuring data remains protected without imposing excessive complexity on users.
+
+## Symmetric vs. Asymmetric Encryption
+
+Polykey leverages both symmetric and asymmetric encryption for different parts
+of the system.
+
+### Symmetric Encryption
+
+- Uses a shared secret key for both encryption and decryption.
+- Highly efficient and fast.
+- Requires a secure channel to distribute the shared key.
+- Vulnerable to _man-in-the-middle (MITM) attacks_ if the key is intercepted.
+
+### Asymmetric Encryption
+
+- Uses a key pair: a public key (shared openly) and a private key (kept secret).
+- The public key encrypts data, and only the corresponding private key can
+  decrypt it.
+- More computationally expensive but solves the secure key distribution problem.
+- A fundamental part of trust-based cryptographic systems.
+
+Polykey employs a hybrid cryptosystem, combining symmetric and asymmetric
+encryption to achieve both efficiency and security.
+
+## Key Storage Mechanisms
+
+### Root Key Pair
+
+The root keypair in Polykey consists of:
+
+- **1 Public Key**
+- **1 Private Key**
+
+It is based on the Ed25519 key scheme, which is optimized for both security and
+performance. The private key is never exposed in plaintext and is stored
+securely within the system.
+
+- **PublicKeyX** -> x25519 version
+- **PrivateKeyX** -> x25519 version
+- **SecretKey** -> `PrivateKey || PublicKey` (concatenated)
+
+This structure enables secure key derivation and avoids the need for
+re-concatenation when using cryptographic libraries like Libsodium.
+
+### Key Encapsulation Mechanism (KEM)
+
+Polykey uses Elliptic Curve Diffie-Hellman (ECDH) Key Encapsulation Mechanism
+(KEM) to securely exchange encryption keys. This ensures that keys remain
+protected even if the transport channel is compromised.
+
+Supported methods:
+
+- **ECDH-SS (Static-Static)**
+  - Uses pre-established key pairs.
+  - No forward secrecy.
+  - Key compromise exposes all past and future messages.
+- **ECDH-ES (Ephemeral\*Static)**
+  - Uses an ephemeral keypair for the sender.
+  - Provides **forward secrecy**, meaning past messages remain safe even if
+    future keys are compromised.
+
+### Encapsulated JWK Storage
+
+Polykey uses **JWK (JSON Web Key) encryption** to store and manage keys
+securely. The JWK format ensures compatibility with modern cryptographic systems
+and allows:
+
+- Secure key wrapping.
+- Efficient key rotation.
+- Interoperability with other secure systems.
+
+Encrypted JWKs are stored using **Flattened JWE JSON**, ensuring the integrity
+and confidentiality of keys at rest.
+
+## Security Considerations
+
+### Forward Secrecy
+
+Forward secrecy ensures that past communications remain secure even if a key is
+compromised. This is achieved through ephemeral key exchange mechanisms like
+ECDH-ES.
+
+### Trusted Identity and Key Authenticity
+
+One of the major challenges in key management is ensuring that public keys
+belong to the correct entity. Polykey does not rely on traditional Centralized
+Certificate Authorities (CAs). Instead, it utilizes:
+
+- **Decentralized trust models** to verify keys.
+- **Identity-based key management** to ensure key authenticity.
+
+This eliminates the single point of failure problem present in CA-based models.
+
+### Secure Key Distribution
+
+Key distribution is managed through secure channels to prevent interception.
+Polykey uses encapsulateWithPublicKey() to encrypt the database key (symmetric
+JWK), ensuring it can only be decrypted by authorized entities.
+
+## Summary
+
+Polykey's key management and storage strategy is built on strong cryptographic
+foundations while maintaining practical usability. By combining:
+
+- **Hybrid cryptosystems** (symmetric + asymmetric encryption),
+- **Elliptic Curve KEMs** for key exchange,
+- **JWK-based encrypted storage**, and
+- **Decentralized identity verification**,
+
+Polykey ensures that stored and transmitted data remain secure, resilient, and
+future-proof against evolving cryptographic threats.
diff --git a/docs/reference/architecture/node-id.md b/docs/reference/architecture/node-id.md
new file mode 100644
index 00000000..a6555343
--- /dev/null
+++ b/docs/reference/architecture/node-id.md
@@ -0,0 +1,64 @@
+# How Polykey Handles Node IDs
+
+## The Basics
+
+Polykey generates and encodes Node IDs using Multihash and Multibase to make
+them flexible, self-describing, and interoperable.
+
+- **Multihash**: A format that encodes the hashing algorithm alongside the hash
+  itself. This ensures that the Node ID always carries metadata about how it was
+  generated.
+- **Multibase**: A format that specifies how the hash is encoded, like Base32
+  Hex. The 'v' prefix is used to indicate Base32 Hex encoding in Polykey.
+
+## How Node IDs Are Generated
+
+### Step 1: Public Key to Multihash
+
+- The Ed25519 Public Key is first hashed using a cryptographic hash function.
+- This produces a Multihash output, which includes both the hash algorithm and
+  the digest.
+
+### Step 2: Multihash to Multibase
+
+- The Multihash result is then encoded using Multibase.
+- In Polykey, we use Base32 Hex encoding with a 'v' prefix to keep it easy to
+  read and portable.
+
+## Why Multihash and Multibase?
+
+- **Future-Proofing**: Since Multihash includes the hash algorithm, we can
+  change the algorithm later without breaking compatibility.
+- **Interoperability**: Other cryptographic systems that use Multihash and
+  Multibase can parse Polykey Node IDs without any issues.
+- **Flexible Rendering**: A single Node ID can be represented differently if a
+  different encoding or hash function is chosen.
+
+## Default Representation in Polykey
+
+Polykey defaults to rendering Node IDs as Base32 Hex, which has some major
+advantages:
+
+- A 32-byte hash always results in a 52-character string.
+- The alphabet is simple and does not use special characters, making it easy to
+  copy, paste, and use anywhere.
+- The lexicographic sort order of the raw 32-byte Node ID matches its encoded
+  form. This keeps things consistent whether Node IDs are stored in memory or
+  displayed in a human-readable format.
+
+## How This Works in Practice
+
+- Node IDs always go through Multihash first, then Multibase.
+- Base32 Hex is the default format, but the same Node ID can be rendered in
+  other ways.
+- If a different base or hash is chosen, the Node ID will look different but
+  still represent the same key.
+
+## Key Takeaways
+
+- Node IDs are hashed first (Multihash) and then encoded (Multibase).
+- The default encoding is Base32 Hex, but other formats are possible.
+- Base32 Hex ensures sort order consistency, easy readability, and portability.
+- The [Polykey codebase](https://github.com/MatrixAI/Polykey) and the
+  [js-id](https://github.com/MatrixAI/js-id.git) repo have more details if
+  needed.
diff --git a/docs/reference/root-keypair.md b/docs/reference/architecture/root-keypair.md
similarity index 100%
rename from docs/reference/root-keypair.md
rename to docs/reference/architecture/root-keypair.md
diff --git a/sidebars.ts b/sidebars.ts
index a585d32f..1c9fb799 100644
--- a/sidebars.ts
+++ b/sidebars.ts
@@ -123,8 +123,25 @@ const sidebars: SidebarsConfig = {
         id: 'reference/README',
       },
       items: [
-        'reference/architecture',
-        'reference/root-keypair',
+        {
+          type: 'category',
+          label: 'Architecture',
+          link: {
+            type: 'doc',
+            id: 'reference/architecture',
+          },
+          items: [
+            'reference/architecture/root-keypair',
+            'reference/architecture/DES',
+            'reference/architecture/ecis',
+            'reference/architecture/encryption-algorithms',
+            'reference/architecture/hybrid-cryptosystem',
+            'reference/architecture/json-webx-standards',
+            'reference/architecture/kem',
+            'reference/architecture/key-encryption-management-storage',
+            'reference/architecture/node-id',
+          ],
+        },
         {
           type: 'category',
           label: 'Polykey-CLI',