Multi-Venue Trading Connectivity and Execution Prototype
Actual VenueWire UI rendered with deterministic sanitized Testnet fixture data; no live account identifiers are shown.
Bybit and Deribit | REST and JSON-RPC | WebSocket | FIX 4.4
VenueWire demonstrates multi-venue connectivity, normalized order and account state, durable trade intents, uncertain-outcome recovery, reconciliation, and real-time account observability.
Testnet only. VenueWire does not support Mainnet, withdrawals, transfers, or real funds.
VenueWire is a Go and Vue 3 trading-connectivity prototype built around two independent venue adapters. Its primary interface is an authenticated Web Console, while the CLI exposes engineering and validation workflows for REST, JSON-RPC, WebSocket, FIX, persistence, and reconciliation.
The browser Quick Trade flow supports Bybit BTC/ETH to and from USDT and Deribit BTC to and from USDC. It reviews a short-lived quote, persists an idempotent trade intent, submits a no-borrow Limit IOC order, and tracks the result through exchange events and reconciliation.
Trading connectivity has failure modes that ordinary CRUD applications can often ignore:
- An order-submission timeout does not mean the exchange rejected the order.
- A connected WebSocket does not mean its data is fresh.
- A REST acknowledgement does not mean an order filled.
- A snapshot and a real-time stream do not automatically form consistent state.
VenueWire focuses on these boundaries through durable trade intents, normalized venue state, idempotency, reconciliation, freshness tracking, and failure isolation.
flowchart LR
UI[Vue Web Console] --> API[VenueWire Go Backend]
API --> Auth[Auth and Sessions]
API --> Core[Trading Core]
API --> Obs[Observability]
Core --> State[Normalized Account and Order State]
Core --> Intent[Durable Trade Intents]
Core --> Recon[Reconciliation]
Core --> B[Bybit Adapter]
Core --> D[Deribit Adapter]
B --> BR[REST]
B --> BW[WebSocket]
B --> BF[FIX]
D --> DR[JSON-RPC]
D --> DW[WebSocket]
D --> DF[FIX 4.4]
Trade execution follows a durable identity chain:
Trade Intent
-> Client Order ID
-> Venue Order ID
-> Execution Events
-> Reconciliation
See Architecture for component and data-flow details.
- Uncertain outcomes: transport failures after submission become
Unknown; VenueWire reconciles them and never resubmits automatically. - State consistency: snapshots, private streams, public streams, and polling feed revisioned normalized state with stale-data detection.
- Idempotent execution: intent, quota reservation, and client identity persist before the first venue write.
- Venue isolation: Bybit and Deribit retain their own protocols, units, authentication, rate limits, and FIX dialects.
- Exact amounts: order planning and reconciliation use exact decimal arithmetic for quantities, prices, fees, and net proceeds.
- Failure containment: one venue can be degraded without converting its failure into a false zero or corrupting the other venue's result.
| Capability | Bybit | Deribit |
|---|---|---|
| Environment | Testnet | Testnet |
| Request protocol | REST V5 | HTTP JSON-RPC |
| Public WebSocket | Implemented and Testnet verified | Implemented and Testnet verified |
| Private WebSocket | Implemented and Testnet verified | Implemented and Testnet verified |
| Browser Spot execution | BTC/ETH to and from USDT | BTC to and from USDC |
| FIX 4.4 | Locally tested; live Testnet blocked by external gate | Real Testnet order flow verified |
The evidence and limitations behind each entry are in the Capability matrix.
Demo access is available on request. The intended interviewer flow is:
- Sign in to the testnet-only Web Console.
- Switch between Bybit and Deribit account views.
- Inspect account values, stream freshness, and System Status.
- Open Quick Trade and review a protected IOC order.
- If server-side trading is explicitly enabled, confirm once and follow the durable lifecycle.
Recheck queries venue evidence. It does not resubmit or force-resolve an order.
- Exact endpoint allowlists reject Mainnet and unexpected redirect targets.
- Browser trading is disabled unless
WEB_TRADING_ENABLED=true; venue read, trading, and FIX gates remain independent. - Credentials and session secrets are loaded from process environment or an ignored local dotenv file. They are never sent in browser DTOs.
- Browser orders use fixed liquid Testnet Spot routes, a five-second quote, Limit IOC, 0.5% protection, and no borrowing.
- Accepted intents persist before submission. Duplicate confirmation cannot create a second logical trade.
- Local builds and automated tests use mocks or fixtures and do not place Testnet orders.
- Testnet writes and deployment changes require explicit operator authorization.
See Security for credential and repository guidance.
Prerequisites are the Go version declared in go.mod, Node.js 24, and npm.
git clone https://github.com/herefindalex/venuewire.git
cd venuewire
cp .env.example .env
# Configure Testnet credentials locally. Keep all write gates disabled initially.
npm --prefix web ci
(cd web && npx playwright install chromium)
make verify
make build
./bin/venuewire --env-file .env webThe Go server binds private HTTP behind an HTTPS/WSS Nginx proxy; it does not terminate TLS. See Deployment before exposing a demo.
The CLI-only build does not require generated frontend assets:
make build-cli
./bin/venuewire helpCurrent verified scope is documented in:
Mock or fixture coverage is never labeled as Testnet verification. Hosted CI and Gitleaks runs passed on master at commit 8c03731986b0095c88d152a1362f45ef5f6399b9; account-level and repository-level settings still require separate verification in GitHub.
| Path | Purpose |
|---|---|
cmd/venuewire/ |
CLI and Web process composition |
internal/ |
Venue adapters, domain state, intents, reconciliation, Web API, and observability |
web/ |
Vue 3 Web Console, unit tests, linting, and browser fixtures |
docs/ |
Architecture, capability, security, deployment, protocol, and validation evidence |
.github/workflows/ |
Credential-free CI and secret scanning |
Makefile |
Canonical build, formatting, and non-mutating verification entry points |
- Testnet only.
- No withdrawals or transfers.
- No automatic cross-venue routing or failover.
- No strategy engine or automated trading strategy.
- No HFT performance claim.
- FIX capability differs by venue and validation level.
- Account valuation is not a portfolio-margin or liquidation engine.
- Demo authentication and recent history are shared-instance prototypes, not multi-tenant production controls.
- The host firewall ACL remains an operator verification item even when the public Nginx path passes.