Technical Architecture

The Sudo ecosystem’s technical architecture has been designed to ensure high availability, low latency, and robust privacy protections, all while integrating seamlessly with Web3. The system is composed of modular layers, each optimized for its specific role in the communication lifecycle.

1. Layered Architecture for Modularity & Scalability

Sudo follows a layered approach to isolate functions, allowing independent scaling and upgrading of each module:

Identity Layer:

• Handles user authentication via EVM-compatible wallets.

• Removes centralized ID dependencies like phone numbers and email addresses.

• Enables multi-chain interoperability with Ethereum, BSC, Polygon, and more.

Encryption Layer:

• Utilizes Libsignal Protocol for secure, end-to-end encryption of both messages and associated metadata.

• Prevents interception or decryption by servers or intermediaries.

Transport Layer:

• Primarily WebSocket-based for real-time low-latency communication.

• Optional Waku Protocol for fully decentralized, peer-to-peer message transport in censorship-prone environments.

Storage Layer:

• PostgreSQL for persistent, structured metadata storage.

• Redis for high-speed caching and message queueing.

• Drift DB (Flutter-based) for secure, offline-ready client-side message storage.

Sync Layer:

• Real-time delivery powered by Ably WebSocket infrastructure, with automatic fallback to HTTP polling when WebSocket connections fail.

Smart Contract Sync Layer:

• Monitors blockchain event logs to verify wallet interactions with dApp contracts, automatically updating group memberships and permissions.

1. Wallet-Based Identity Model

In Sudo, a user’s wallet address is their identity. This eliminates passwords, centralized servers for authentication, and KYC dependencies. Additional flexibility is achieved through:

• Optional ENS or Sudo Username NFT linking for human-readable names.

• Multi-chain wallet support to maintain a single identity across ecosystems.

1. Secure Messaging Flow

Sudo’s message delivery process ensures security without sacrificing performance:

• Encryption: Sender signs and encrypts the message using Libsignal.

• Routing: The message is sent via WebSocket to the backend routing layer.

• Pub-Sub Delivery: Redis pub-sub broadcasts the message to the recipient’s active connection.

• Decryption & Storage: Recipient decrypts the message locally and stores it in Drift DB for offline access.

This ensures that only the sender and receiver ever see the content, and messages are inaccessible even to Sudo’s servers.

1. Database & Storage Architecture

• PostgreSQL: Maintains persistent records for user profiles, group/channel details, message indexes, smart contract bindings, and token reward logs.

• Redis: Handles real-time message delivery, caching, and rate-limiting. Also powers anti-spam mechanisms.

• Drift (Local DB): Stores messages client-side, ensuring users can access past communications even without network connectivity.

5. Performance Optimization Strategies

To achieve high throughput and low latency, Sudo implements:

• Horizontal Scaling: Containerized microservices can be deployed independently, enabling on-demand scaling.

• Load Balancing: NGINX load balancers distribute WebSocket connections across multiple nodes.

• Smart Batching & De-duplication: Blockchain sync calls are batched and duplicate queries are eliminated, reducing RPC overhead.