Platform Docs

Platform Overview

A technical description of the iKash P2P software architecture, defining system boundaries, component responsibilities, and integration patterns.

System Purpose

iKash is a peer-to-peer (P2P) crypto on/off-ramp platform built on the Stellar blockchain network. It enables users to exchange cryptocurrency assets for fiat currency directly with one another, eliminating the need for a centralized custodian.

The system is designed around a strictly non-custodial architecture. iKash never holds, controls, or has access to user private keys or funds at any point during a transaction. The security of funds in transit is guaranteed by smart contract-based escrows deployed directly on the Stellar network, managed through Trustless Work, an audited, production-grade escrow infrastructure recognized within the Stellar ecosystem.

Architectural Topology

The platform operates on a two-component logical architecture: a client-side frontend application and a server-side backend orchestration layer.

The client application serves as the exclusive signing authority. It is the user-facing interface where wallet connections reside and where all transaction signing occurs. When the client receives a prepared External Data Representation (XDR) from the backend, it delegates the signature to the user's locally installed wallet (via the Stellar Wallet Kit), and returns the signed payload.

The backend orchestration layer acts purely as a state manager and coordinator. Its access is limited to reading on-chain state, preparing unsigned transactions, and maintaining relational data. It relies on the Stellar SDK to construct XDR envelopes but lacks the capability to authorize them. Once a transaction is signed client-side, the backend relays the payload to the network or delegates execution to Trustless Work.

Persistence and State Management

State persistence is divided into two distinct layers based on data structure. Structured, relational data—such as user profiles, order matching records, escrow metadata (including contract IDs and transaction hashes), and chat message logs—is managed by a PostgreSQL database. The backend interfaces with this database exclusively through the Prisma Object-Relational Mapper (ORM), ensuring type-safe query generation and rigid schema enforcement.

Unstructured data, specifically the payment evidence (e.g., bank transfer receipts or screenshots) required during the fiat settlement phase of an escrow, is handled by a dedicated object storage service on Google Cloud Storage (GCS). The backend generates secure upload references and associates the resulting artifact URLs with the corresponding escrow record in the PostgreSQL database, ensuring evidence remains tightly coupled to its transactional context while keeping the relational store optimized.