arrow_back Back to Selected Work Case Study Layer 2 // Deep Technical Dive
Web3 / Blockchain business Graduation Project May 2026

Sawtak (صوتك) – Decentralized Complaints Platform

Tamper-proof, decentralized public issue reporting platform with cryptographic anonymity and state machine consensus.

ROLE OWNERSHIP Blockchain Developer
TIMELINE Q4 25 - Q1 26
PRIMARY ARCHITECTURE Distributed-Systems
Sawtak (صوتك) – Decentralized Complaints Platform
01 / The Context & Problem

What was broken before this system existed?

Traditional public complaint systems suffer from centralized censorship, lack of trust, vulnerability to database tampering, and citizen fear of retaliation. Citizens needed a verifiable way to submit evidence without exposing their identity, while authorities required verifiable audit trails.

02 / Role & Technical Ownership

What did I actually engineer and own?

As the Blockchain Developer, I owned the system end-to-end: from initial requirements definition and architectural design to database schema modeling, backend pipeline development, and final production deployment.

Architected a dual-layer architecture separating consensus from query serving. Developed a sovereign Cosmos SDK blockchain module with CometBFT consensus where state transitions (issue submission, status updates, authority resolution) are permanently signed and immutably ordered. Coupled with an IPFS decentralized storage pipeline and a high-throughput Bun/Elysia caching gateway.

03 / System Architecture & Data Flow

How the system is structured

Two-Layer State Management: Architected a clear separation of concerns where CometBFT handles immutable block storage while an embedded LevelDB manages mutable application state for rapid access.

Decentralized P2P Network: Deployed a 3-node validator network communicating via an authenticated Gossip Protocol over port 26656.

Containerized Infrastructure: Containerized the entire blockchain network using Docker and deployed it on a Hostinger VPS to simulate a realistic production environment.

High-Availability Indexing: Built a custom Cosmos Indexer service using Bun/Elysia that polls the CometBFT RPC endpoint, parsing block events and synchronizing them into a relational PostgreSQL database to facilitate high-speed, complex frontend querying.

04 / Architectural Decisions & Trade-Offs

Why this architecture? Tradeoffs & judgment

1. Why Cosmos SDK / Sovereign App-Chain over Smart Contracts (Ethereum/Solidity): App-chain provides custom state transition rules, zero gas fees for citizens via fee-grant modules, deterministic block finality (CometBFT), and full sovereignty over governance.

2. Why Two-Layer State Architecture (CometBFT + PostgreSQL CQRS): Blockchain is the single source of truth for write transactions; PostgreSQL acts as a read-model cache populated by real-time blockchain indexers to enable millisecond search queries without hammering validator nodes.

3. Why Ed25519 Ephemeral Keypairs: Allowed zero-knowledge style unlinkable complaints while providing citizens with a cryptographic receipt to check status without a persistent login identity.

4. What happens at 10x traffic: CometBFT transactions scale horizontally with pipelined mempool gossip; state pruning ensures validator disk usage remains bounded by archiving historical state to decentralized storage.

5. What was deliberately NOT built: Did not implement volatile speculative tokens or DeFi mechanics; focused strictly on cryptographic verification and civil utility.

05 / Technical Challenges Overcome

Hardest engineering hurdles

Balancing citizen anonymity with spam prevention. Solved through cryptographic challenge-response rate limiting and proof-of-work puzzle validation at the gateway layer before mempool inclusion.

Custom Application-Specific Blockchain: Engineered from scratch using the Cosmos SDK framework and Go, rather than relying on external smart contracts.

Proof of Authority (PoA) Protocol: Developed a custom module to restrict block production and validator access strictly to pre-authorized entities, disabling public inflation and staking.

On-Chain Cryptographic Verifier: Implemented logic within the blockchain keeper to verify Ed25519 signatures, authenticating anonymous complaints mathematically without exposing PII (Personally Identifiable Information).

Security Middleware: Designed a custom AnteHandler decorator to intercept transaction pipelines, effectively mitigating unauthorized state modifications and Authz bypass vulnerabilities.

Decentralized Storage: Integrated IPFS via Pinata to pin evidence files, storing only lightweight cryptographic hashes on-chain to prevent state bloat.

06 / Measurable Outcomes

Quantified results & production impact

Absolute Immutability: Eliminated single-point-of-failure risks associated with traditional databases, providing a 100% verifiable and tamper-proof audit trail for government complaint records.

Instant Finality: Leveraged BFT consensus to ensure transactions are permanently finalized upon block commit, with no risk of chain reorganizations or orphan blocks.

Zero-Knowledge Architecture: Enabled citizens to report critical issues securely without maintaining on-chain wallets, preserving complete anonymity.

07 / Retrospective

What I would change at 10x scale

Separating the write path (consensus state machine) from the read path (CQRS relational projections) is essential for any high-performance distributed application.