Hi everyone,

I want to introduce GenosDB (GDB), a project I’ve been building. It’s a peer-to-peer, modular graph database designed from the ground up to embed zero-trust security directly into the data layer.

This is not just “another database.” GenosDB is an experiment in combining distributed systems, cryptographic identity, and fine-grained access control into a unified framework where trust is enforced at the edge — without central servers.

🔍 The Problem It Tries to Solve

Peer-to-peer systems have always faced a central challenge: how can peers trust each other without relying on a server or central authority?

Typical decentralized apps often end up cheating: they use a P2P database for storage but fall back to centralized servers for identity, authentication, and permissions. That single point of control undermines the decentralization.

GenosDB tries to address this by designing security into the core database engine: every peer, every operation, every role check is verified independently. The network is held together not by trust in servers, but by cryptography and a shared constitution of rules.

Watch the video

🧩 Core Architecture

GenosDB is a graph database where data is stored as nodes and edges, and peers can synchronize updates in real time. On top of that, it provides:

• P2P Synchronization – Each instance can connect to others over WebRTC or relays, exchanging updates and applying them locally.
• Eventual Consistency – Updates flow asynchronously, but cryptographic checks guarantee that only valid, authorized changes are accepted.
• Reactive Queries – Peers can subscribe to queries and get real-time updates as the graph evolves.

But the real innovation is the Security Manager (SM), which is not an add-on but an integral part of the architecture.

🔒 The Security Manager (SM)

The SM enforces a zero-trust model at multiple levels:

1. Identity Management

Every user is an Ethereum address backed by a private key. No passwords are involved. Private keys are protected by:

• WebAuthn – biometric devices, hardware security keys (phishing-resistant).
• Mnemonic phrases – for recovery and portability.

This means authentication is both decentralized and resistant to common attacks.

2. Operation Signing and Verification

Every database operation is signed by the user’s active key. When a peer receives an operation:

1. It verifies the signature (authenticity and integrity).
2. It checks the sender’s role and permissions.
3. It rejects the operation if either fails.

Unsigned or tampered operations never enter the system.

3. Role-Based Access Control (RBAC)

A hierarchy of roles (guest, user, manager, admin, superadmin) defines permissions like read, write, delete, assignRole.

• Role assignments are stored inside the graph itself, synchronized like any other data.
• Roles can be customized at initialization.
• Authority flows from superadmins, who are defined in the initial configuration.

4. Access Control Lists (ACLs)

For more granular control, ACLs can be attached to nodes. For example, a document can explicitly list which peers may read or write it. ACLs are enforced alongside RBAC, so both conditions must be satisfied.

5. Secure Data Storage

When a user stores data through the SM, it is automatically encrypted with a key derived from their identity. Only the rightful owner can decrypt it.

🚪 The Zero-Trust Entry Model

One of the hardest problems in zero-trust systems is the bootstrap paradox: how does a brand-new user even join the network if they have no permissions yet?

GenosDB’s solution is a single welcome exception:

• A new address is allowed exactly one operation — creating its own identity node as a guest.
• The system overwrites any attempted role with guest (preventing privilege escalation).
• After that, the user is limited to minimal permissions (read, sync) until promoted by a superadmin.

This creates a secure, one-way entry point. No shortcuts, no backdoors.

🕸 The Distributed Trust Model

Trust in GenosDB is not delegated to a central server. It emerges from three principles:

1. Cryptographic Identity and Signatures Every action is signed. No one can impersonate another.
2. Shared Constitution Rules (roles, permissions) are encoded in the SM and shared across all peers. They are not arbitrary — they are uniform and verifiable.
3. Local Enforcement Each peer checks operations independently. Even if one peer is compromised or malicious, others enforce the rules and reject invalid operations.

This makes the system resilient: a rogue client cannot rewrite its local code to cheat, because other nodes will still reject unauthorized actions.

⚖️ Consistency and Security

GenosDB favors security over availability. For example:

• If Bob is promoted to admin by a superadmin, but a lagging node hasn’t received the promotion yet, Bob’s delete operations will initially be rejected.
• Once the promotion arrives, those operations are accepted.

This ensures no operation is accepted without verifiable proof, even if it delays availability slightly.

🌍 Why It Matters

Most “decentralized” systems still centralize identity and trust. GenosDB demonstrates that:

• A database itself can carry identity, access control, and trust as first-class citizens.
• P2P apps can enforce zero-trust security without needing external servers.
• Collaborative systems — from shared documents to social platforms to multiplayer games — can be built on a substrate where every action is verified cryptographically.

In short: it’s a database where security is the foundation, not an afterthought.

📚 Resources

• Whitepaper
• Documentation
• API Reference
• Distributed Trust Model
• Zero-Trust Security Model
• Repository
• Discussions

🙌 Invitation

Note: GenosDB is proprietary, but the bundle is free to use without restrictions.

GenosDB is currently in stable beta. The architecture is functional, the zero-trust flows are enforced, and the P2P engine is running.

I’m sharing this here because I’d love to:

• Experiment with it.
• Stress test it.
• Help shape the roadmap.

If you care about security, decentralization, and real-time collaboration, I’d be thrilled to hear your feedback.

Esteban Fuster Pozzi (estebanrfp)