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

Sawtak (صوتك) – Decentralized Public Complaints Platform

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

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

What was broken before this system existed?

Traditional public complaint systems suffer from centralized censorship, lack of verifiable audit trails, and citizen fear of retaliation. Citizens needed a cryptographic guarantee that their reports could not be quietly deleted or modified in a database, while authorities required verifiable audit trails.

02 / Role & Technical Ownership

What did I actually engineer and own?

As the Blockchain & Systems Engineer, 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 system using Cosmos SDK and CometBFT (Tendermint Core) consensus. State transitions (complaint submission, authority status updates, resolution proofs) are permanently recorded on an application-specific blockchain. Coupled with an IPFS decentralized storage pipeline and a high-speed Bun/PostgreSQL CQRS read cache for public exploration.

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 on a fee-less public chain. Solved through cryptographic challenge-response rate limiting and proof-of-work puzzles 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

• Engineered a 4-node local testnet achieving deterministic sub-2s block finality with CometBFT consensus.
• Implemented Ed25519 ephemeral cryptographic receipts, allowing citizens to verify issue progress without maintaining a trackable identity.
• Decoupled blockchain consensus from query serving via CQRS, delivering sub-10ms UI query latency.

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.