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 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 Watch the video 🧩 Core Architecture 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. 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 Security Manager (SM) The SM enforces a zero-trust model at multiple levels: 1. Identity Management 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. 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 2. Operation Signing and Verification Every database operation is signed by the user’s active key. When a peer receives an operation: It verifies the signature (authenticity and integrity).
It checks the sender’s role and permissions.
It rejects the operation if either fails. It verifies the signature (authenticity and integrity). It checks the sender’s role and permissions. It rejects the operation if either fails. Unsigned or tampered operations never enter the system. 3. Role-Based Access Control (RBAC) 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. 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) 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 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. 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 The Distributed Trust Model Trust in GenosDB is not delegated to a central server. It emerges from three principles: Cryptographic Identity and Signatures Every action is signed. No one can impersonate another.
Shared Constitution Rules (roles, permissions) are encoded in the SM and shared across all peers. They are not arbitrary — they are uniform and verifiable.
Local Enforcement Each peer checks operations independently. Even if one peer is compromised or malicious, others enforce the rules and reject invalid operations. Cryptographic Identity and Signatures Every action is signed. No one can impersonate another. Shared Constitution Rules (roles, permissions) are encoded in the SM and shared across all peers. They are not arbitrary — they are uniform and verifiable. 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 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. 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 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. 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 Resources Whitepaper
Documentation
API Reference
Distributed Trust Model
Zero-Trust Security Model
Repository
Discussions Whitepaper Whitepaper Documentation Documentation API Reference API Reference Distributed Trust Model Distributed Trust Model Zero-Trust Security Model Zero-Trust Security Model Repository Repository Discussions Discussions 🙌 Invitation Invitation Note: GenosDB is proprietary, but the bundle is free to use without restrictions. Note: 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. 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) estebanrfp

This post provides insights into new product. 

This story contains new, firsthand information uncovered by the writer.

This is a PR written by or for the company mentioned within it. The writer has a vested interest in the company and products mentioned within.

This writer has a vested interest be it monetary, business, or otherwise, with 1 or more of the products or companies mentioned within.

Introducing GenosDB: a P2P Graph Database with Built-In Zero-Trust Security

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

10 Decentralized Applications Integrate Sui’s Groundbreaking zkLogin Google Authentication

3 Reasons Why Free TON is the 1st Truly Decentralized Blockchain Platform

5 Open-Source Tools You Can Donate to via Kivach, Episode VI: Decentralized Services

5 Web3 UX Innovations That Can Encourage Mass Adoption of Web3 Technology

52 Stories To Learn About Decentralized Apps

10 Decentralized Applications Integrate Sui’s Groundbreaking zkLogin Google Authentication

3 Reasons Why Free TON is the 1st Truly Decentralized Blockchain Platform

5 Open-Source Tools You Can Donate to via Kivach, Episode VI: Decentralized Services

5 Web3 UX Innovations That Can Encourage Mass Adoption of Web3 Technology

52 Stories To Learn About Decentralized Apps

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps