What is a Unified Trading Account?
A Unified Trading Account collapses all your connected venues into a single balance sheet and buying-power view — and it's the layer that makes agent-run trading coherent.
When an agent researches a trade, it needs to know what you can actually afford — not the balance on one exchange, but your full picture across every venue.
The problem a UTA solves
Most traders operate across several venues at once: a spot exchange, a derivatives platform, a brokerage for equities. Each has its own balance, margin model, and settlement cycle. Keeping those in sync manually is tedious. Asking an agent to trade intelligently across them without a unified view is worse — it can't see the whole picture.
A Unified Trading Account (UTA) solves this by presenting a single, consolidated balance sheet across all connected venues. From the agent's perspective — and yours — there is one desk with one pool of capital.
What the UTA consolidates
| Dimension | Without UTA | With UTA |
|---|---|---|
| Balance visibility | Per-venue, checked separately | Single consolidated view |
| Buying power | Calculated per venue | Aggregated across venues |
| Margin / collateral | Siloed | Cross-margined where venues allow |
| Agent context | Partial — one venue at a time | Full desk snapshot in every prompt |
| Guard rules | Duplicated per venue | One rule set applied desk-wide |
How Qoc implements it
The UTA lives in your workspace's snapshots/ directory. Every time the desk syncs with a venue, it writes a snapshot file — a plain JSON record of positions, balances, and open orders. The runtime aggregates these into the consolidated view that agents and guards read.
Because snapshots are plain files under version control, you can inspect any point-in-time picture of your desk with a standard diff tool. There are no hidden state machines.
Reading a snapshot
qoc snapshot list
# 2026-03-04T09:14:22Z snapshot-0041.json
# 2026-03-04T08:00:01Z snapshot-0040.json
qoc snapshot show snapshot-0041.jsonBuying power and the agent loop
When an agent starts a research cycle, the first thing it reads is the current UTA snapshot. This tells it total equity, per-venue available margin, and any open proposals that are pending approval. A proposal that would exceed available buying power is blocked by the guard layer before it ever reaches your inbox.
This means the agent's proposals are always grounded in reality. It isn't proposing a trade you couldn't physically execute; it already knows your constraints.
Guards run against the UTA, not a single venue
When you write a guard rule — say, 'never exceed 10% of desk equity in a single position' — that percentage is calculated against your full consolidated balance, not just the balance on the venue where the trade would execute.
This makes cross-venue risk rules straightforward to express and impossible to accidentally bypass by using a venue the rule wasn't written for.
What goes into the UTA snapshot
- Cash balances — fiat and stablecoin holdings across all connected venues
- Open positions — long and short, with venue, size, cost basis, and current mark
- Open orders — resting limit orders and any pending desk proposals
- Margin utilization — initial and maintenance margin consumed per venue
- Pending settlements — trades executed but not yet settled, to avoid double-counting