For Illustrations & diagrams check out Project Diagrams.

1. High-Level System Structure & Network Isolation

The Sawtak platform is built on an intricate, defense-in-depth architecture strictly segregated into four isolated Trust Zones. This ensures that even if one component is compromised, the sensitive inner layers remain protected. No outer layer can bypass the layer directly beneath it.

Zone 1: Public Zone (Frontend)

The open internet where citizens and administrators interact with the platform via the User Interface.

• Next.js 16 (App Router): Utilizing a modern React architecture for optimal performance.
• It handles user authentication (via a mocked Haweya OAuth), renders the public complaint feed, and manages evidence file selections.
• The frontend never speaks directly to the backend database or the blockchain. All API requests are strictly routed to the DMZ Proxy.

Zone 2: DMZ (Demilitarized Zone)

This is the only endpoint exposed to the internet (running on Port 4000).

• Privacy Proxy (Bun/Elysia): A high-performance server acting as a secure buffer.
• Sanitization Engine: Aggressively strips all Personal Identifiable Information (PII) from incoming requests, including User-Agent, x-forwarded-for, cf-connecting-ip, Cookies, and Referrers.
• Rate Limiting: Utilizing a dedicated Redis instance, it enforces strict endpoint-specific rate limiting to prevent DDoS attacks.
• Proxy Signature: Once a payload is sanitized, the proxy injects an internal cryptographic signature (PROXY_SECRET) and a sanitized user-agent (Sawtak-Proxy/1.0) before forwarding it to the backend.

Zone 3: Internal Zone (Core Backend & DB)

The core business logic resides here (running on Port 8000), completely hidden from the public internet. It cannot be accessed directly.

• Validation Check: The Backend instantly rejects any incoming requests that lack the exact cryptographic PROXY_SECRET applied by the DMZ Proxy.
• Core Backend API (Bun/Elysia): Processes sanitized data, triggers AI content validations, and handles the business logic for complaints and identities.
• Cryptographic Backend Identity: The backend possesses a unique cryptographic identity defined by a Private Key (PEM) and a corresponding Public Key. This identity is used to sign every anonymous submission, creating a verifiable proof that the complaint originated from a trusted source before it reaches the blockchain.
• Database (PostgreSQL 15): A highly secure database storing encrypted identified complaints (using AES-256-GCM encryption) and cached blockchain data.

⛓️ Zone 4: Sawtak Blockchain Zone (Cosmos-based)

A private, 3-node high-performance blockchain network built using the Cosmos SDK.

• Consensus Model: Operates on a Proof of Authority (POA) model, ensuring blocks are produced strictly by vetted authority nodes. Standard staking and inflation modules are disabled.
• Immutability: Guarantees that once a verified complaint and its evidence hash are recorded, they cannot be altered, censored, or deleted.

2. Detailed System Workflows

Payload Lifecycle: Anonymous vs. Identified Submissions

Anonymous Mode

• Payload Handling: The user’s device submits the complaint with absolutely no session or identity tokens. The DMZ Proxy strips all network footprints.
• AI Validation: The backend queues the payload to an AI Content Validation pipeline to filter out spam or malicious content.
• Evidence Storage: Any attached evidence is routed directly to a decentralized IPFS node (via Pinata). A cryptographic Content Identifier (CID) is returned.
• Verification Proof: The backend uses its Private Key (PEM) to sign the encrypted identifier, attaching a cryptographic proof to the message.
• Blockchain Broadcast: The Backend formats the payload into a Sawtak Blockchain transaction (MsgSubmitAnonymousComplaint) and broadcasts it via the RPC node.