Validators
How the Zentalk validator network works, what validators do, and why running a node matters for the decentralized mesh.
What is a Validator?
A validator is an independent node operator who runs a relay server that powers the Zentalk network. Validators route encrypted messages between users, store encrypted data chunks, and participate in peer discovery — all without being able to read any of the content they handle.
The Zentalk network has no central server. Instead, it relies on a distributed mesh of validator nodes operated by independent participants around the world. The more validators join the network, the more resilient, private, and censorship-resistant it becomes.
Validators handle only encrypted data. Even a malicious validator cannot decrypt messages, read files, or identify who is communicating with whom.
What Validators Do
Each validator node performs three core functions simultaneously:
Message Relay
The relay module routes encrypted messages between users in real-time. When a recipient is offline, messages are queued in an encrypted store and delivered when they reconnect. All routing uses 3-hop onion encryption — no single relay knows both the sender and recipient of any message.
Mesh Storage
The storage module holds encrypted data chunks distributed across the network using Reed-Solomon erasure coding. Files are split into shards and spread across multiple validators, ensuring data survives even if some nodes go offline. Validators store these shards without the ability to reconstruct or read the original data.
Peer Discovery
The DHT (Distributed Hash Table) module enables validators to find each other and new users to discover available nodes. This uses the Kademlia protocol via libp2p, with automatic health monitoring and recovery. Validators also participate in GossipSub for network-wide announcements.
Why Run a Validator
Earn Rewards — Validators earn CHAIN tokens for relaying messages and providing storage services to the network
Support Privacy — Every validator strengthens the decentralized network, making surveillance and censorship harder
Low Barrier — A single binary deployment with Docker support, no complex infrastructure required
Full Monitoring — Built-in Prometheus metrics, health endpoints, and support for Grafana dashboards
Open Participation — Anyone can join as a validator, no permission required
How It Works
Server-Blind Architecture
Validators operate on a "lockbox" principle. They receive, store, and forward encrypted blobs — but they never hold the keys to decrypt them. This is enforced by cryptography, not policy:
Message content is encrypted with Signal Protocol before it ever reaches a validator
Routing information is wrapped in 3 layers of onion encryption (RSA-4096 per layer)
Group membership is hidden through Sealed Fanout delivery
Storage chunks are encrypted with AES-256-GCM before sharding
Even if a validator operator inspects every byte passing through their node, they see only encrypted data with no way to determine its contents or link senders to recipients.
Federation
Validators automatically discover each other through the DHT network. When a user connected to one validator sends a message to a user on a different validator, the message is forwarded between relays using TLS with mutual authentication and certificate pinning.
The network uses weighted relay selection to optimize routing:
Balanced
Latency, capacity, reputation, geography
General messaging
Latency
Lowest response time
Voice and video calls
Capacity
Most available storage
File sharing
Reputation
Highest reliability score
Critical communications
Self-Healing
The network automatically handles node failures:
Disconnected peers are retried with exponential backoff
Degraded storage shards are automatically repaired by the anti-entropy service
Routing tables are refreshed every 10 minutes
Unhealthy nodes are temporarily excluded from relay selection
Network Security
Validators are hardened with multiple security layers:
Transport Encryption
TLS 1.3 + Noise Protocol for all node communication
Anti-Sybil
Peer scoring (100 points baseline, disconnect below 20)
Subnet Diversity
Max 3 peers per IPv4 /24 to prevent eclipse attacks
Rate Limiting
3-layer: per-IP, per-address, and ZKP-based (RLN)
Replay Prevention
Nonce tracking with 45-second timestamp window
DDoS Protection
10K connection limit with load shedding
Membership Tokens
Ed25519 signed tokens with epoch-based revocation
Node Capacity Management
Validators automatically manage their resources:
0–70%
Healthy
Accept all writes
70–80%
Warning
Accept writes, log warnings
80–90%
Degraded
Reject large files
90–95%
Critical
Serve existing users only
95–100%
Emergency
Reject all new writes
The network routes around overloaded validators automatically, ensuring consistent service quality.
Resilience Testing
The validator software is tested against 49+ chaos engineering scenarios including:
Network partitions and split-brain conditions
Node failures and unexpected restarts
Storage corruption and disk pressure
Certificate expiration and key rotation failures
Memory pressure and resource exhaustion
This ensures the network remains operational under real-world failure conditions.
Performance
Benchmarked on Apple M3 Pro:
Message relay
1,000+ messages/sec
Storage writes
100+ MB/s
3-hop routing latency (p95)
< 100 ms
Concurrent connections
10,000+ per node
AES-256-GCM encryption
590,000 ops/sec
Getting Started
The Zentalk validator program is currently in development. If you are interested in running a validator node, visit zentalk.chat for the latest information on the validator program, requirements, and how to participate.
Running a validator requires staking CHAIN tokens and meeting minimum hardware requirements. Full details, staking contracts, and setup instructions will be available at zentalk.chat when the validator program opens.
Last updated
Was this helpful?