Trading Overview

GoMarket runs a hybrid-decentralized order book: matching happens off-chain for speed, settlement happens on-chain for finality. The platform never holds your funds.

What that means concretely


Your keys	Stay yours. Orders are signed, not deposited.
Your tokens	Stay in your wallet until a match settles.
Matching	Off-chain, in the Order Manager, price-time priority.
Settlement	On-chain, `markets::execute_trade`, atomic.
Custody	None. The program moves tokens directly between counterparties.

The bridge between the two halves is the delegate allowance: a standing SPL Approve granted to a program-derived address.

Delegate PDA   seeds = ["delegate", maker]

When a match settles, the maker’s tokens move through that delegate — the program signs for it. The maker never signs the settlement transaction and can be offline entirely. Signers on execute_trade are the taker, the config operator, and the program itself.

The services

       HTTP (SIWS) / gRPC
             │
   ┌─────────▼──────────┐
   │   Order Manager    │  books, matching, validation
   └──┬──────────┬──────┘
      │ gRPC     │ gRPC          REST
      ▼          ▼                │
┌──────────┐ ┌──────────┐  ┌──────▼──────┐
│  Ledger  │ │ Executor │  │ Markets API │
│ PG+Redis │ │ tx build │  │  catalogue  │
└──────────┘ └────┬─────┘  └─────────────┘
                  │ Solana JSON-RPC
                  ▼
        markets program · execute_trade

Service	Job
Order Manager	In-memory books, validation, matching. The front door.
Ledger	PostgreSQL persistence of orders and trades; Redis event fan-out.
Executor	Builds, signs and sends settlement transactions; tracks confirmations.
Markets API	The market catalogue — the source of truth for token IDs and mints.

→ Architecture

What’s distinctive here

Same-side matching

Two traders who both want to buy opposite outcomes can be matched. The engine mints a fresh YES+NO pair from their combined collateral and gives each of them their side. Two sellers of opposite sides are matched by merging their pair back into collateral.

This means a market can trade without anyone holding inventory first — a large part of why bootstrapping liquidity works at all.

→ Match Types

No on-chain order state

There is no nonce account and no fill-status account. The program validates a maker’s signature at settlement time and moves tokens; it keeps no record that the order was filled.

Replay protection therefore lives in the Executor, which de-dupes by full trade key and persists that set across restarts. The executor is the single trusted settlement instance. A caller who bypasses it and calls execute_trade directly could settle the same signed order repeatedly, bounded only by the maker’s standing allowance.

This is the most important thing to understand about GoMarket’s trust model, and it is why the operator signature is required on every settlement.

Order hash as identity

The domain-separated SHA-256 order hash is the orderID, the de-dup key, and the digest verified on-chain against a top-level ed25519 instruction. The same hash is computed identically in the order manager, the ledger, the executor and the program, pinned by known-vector tests in each.

Getting started


Authentication	Sign in with your Solana wallet
Place Orders	Order shape, types, validation
Manage Orders	Cancel, query, reconcile
Match Types	COMPLEMENTARY, MINT, MERGE
Settlement	What happens on-chain
Market Making	Quoting, allowances, inventory
Real-Time Data	The notifications stream