AxisCorePay — Custodial Crypto Payment Platform

At a glance

The Problem

Most custodial wallets store private keys in one place. That single place is also the single point of failure. A compromised server means every user’s funds are at risk. A malicious insider with root access achieves the same outcome.

The client came to us with an unambiguous mandate: build a payment processing platform for merchants — crypto and fiat — at institutional-grade security. The requirements:

• No single point of compromise — the private key must never exist assembled on any single server.
• Multi-chain — Ethereum ERC-20 and Tron TRC-20 from day one, extensible to others.
• Fiat gateway — buy and sell crypto with pluggable fiat providers.
• API-first — full REST API for merchant integration, with separate sandbox and production environments.
• Audit-ready — append-only operation logs, RBAC, a clear path toward PCI DSS and SOC 2.

The challenge: combine cold-storage-level security with hot-wallet convenience.

Architecture

The platform runs as four Go microservices, each with a single, well-defined responsibility.

API Gateway handles all inbound HTTP — JWT RS256 authentication with 15-minute token lifetimes, six-role RBAC, rate limiting, and routing. It also serves hosted payment pages for merchants.

Wallet Service manages HD wallets (hierarchical deterministic address derivation) and balances. Each organisation gets an isolated address namespace.

Signer Service is the security-critical core. It implements MPC-TSS with a 2-of-3 threshold: two of three key shares are sufficient to sign any transaction, but no single node ever holds the assembled private key. Shares are encrypted AES-256-GCM with Argon2id-derived keys.

Blockchain Service abstracts over chain nodes. It handles transaction broadcast, confirmation tracking, and deposit monitoring for both Ethereum and Tron.

The Core Innovation: DTES

DTES — the Distributed Transaction Execution System — answers the question fundamental to any custodial platform: how do you authorise a transaction without creating a single decision point?

DTES runs in three configurable modes, selectable per transaction type:

PreSign — the signer produces the signature first, then DTES splits it via Shamir and distributes shares to verifiers. Execution proceeds only when a configurable quorum is reached.

PostSign — DTES splits the transaction data first; verifiers vote; only after quorum does the signer receive authorisation.

KeyDist — the most secure mode. Key material itself is split and distributed; signing happens across nodes; all shares are destroyed immediately after execution.

Every mode supports configurable verifier count, quorum size, and timeout. The cardinal rule: zero-state. DTES holds nothing sensitive between operations. All materials are zeroed on completion.

Settlement: Shamir 2-of-2

For merchant payouts, DTES is supplemented with an additional explicit bilateral confirmation layer using Shamir’s Secret Sharing.

When a merchant requests a payout:

1. The system generates a signing payload and splits it 2-of-2 using Shamir’s Secret Sharing.
2. Share 1 goes to the platform admin, encrypted with their dedicated AES-256-GCM key.
3. Share 2 goes to the merchant, encrypted with their key.
4. Both parties confirm independently.
5. The system decrypts and combines the shares, verifies the reconstructed payload matches the original (constant-time comparison), then signs and broadcasts.

The mathematical guarantee: with only one share, an attacker obtains zero bits of information about the payload. No server compromise, however complete, is sufficient alone.

For a detailed technical walkthrough of the Shamir implementation — GF(2⁸) arithmetic, Go code, and the security pitfalls — read the engineering deep-dive →

Results

• No single point of compromise — the private key never exists assembled in any one process. Full server compromise does not yield signing capability.
• Multi-chain extensibility — adding a new blockchain requires implementing one interface. No changes to payment business logic.
• Full payment lifecycle — invoice creation → unique deposit address generation → automatic settlement with bilateral signing.
• Audit-ready — append-only operation log with hash chaining; ready for external security audit.
• Developer-friendly integration — sandbox/production API keys, HMAC-signed configurable webhooks, hosted payment pages.
• Independent scalability — microservice split allows blockchain indexing and signing capacity to scale independently from the API layer.
• Fast development cycles — the Repository pattern with in-memory implementations eliminated real-node dependencies during development.

Stack

Go · PostgreSQL 16 · Redis 7