Case study 02
Market-Neutral Multi-Account Execution System
I adapted and operated a multi-account execution system for controlled market-neutral activity on a perpetual venue. Three accounts is the minimum configuration; the same workflow coordinates more.
The system was built for protocol participation and execution-cost research where trading activity may be one input into an incentive or eligibility program. It is not presented as organic market demand, guaranteed reward generation or a source of trading profit. Venue terms, self-trade rules and eligibility criteria remain hard boundaries.
The operating goal was narrower: coordinate several accounts, keep aggregate directional exposure close to neutral, measure the real cost of completed cycles and make failures visible without continuous screen time.
The problem
Running the same workflow manually across multiple accounts introduces several risks:
- long and short notional can drift apart;
- one order may fill while another does not;
- aggressive leverage can consume the safety margin;
- a dead proxy can silently collapse account separation;
- a process restart can leave positions open;
- estimated order prices can be mistaken for actual fills;
- reports can show apparent profit or cost based on the wrong data source;
- an automated loop can continue even after the system has become unsafe.
The challenge was not simply to send more orders. It was to preserve accounting integrity and operational control across the full open–hold–close cycle.
What I built
The workflow coordinates every connected account as one execution group:
- 1
Allocate sides
Split the group so one side is carried by more accounts than the other — at the three-account minimum that is two against one — and rotate the configuration between cycles.
- 2
Match notional
Calculate leverage and position size so total long and total short exposure remain aligned.
- 3
Preflight checks
Verify balances, minimum order sizes, spread limits, proxy health and existing positions.
- 4
Open the group
Place the legs and wait for venue state to settle before declaring success.
- 5
Hold within a bounded window
Keep the cycle active for a configured period while preserving stop and shutdown controls.
- 6
Close and reconcile
Close all legs, retrieve actual trade history and compare reported PnL with collateral changes.
- 7
Report
Send a Telegram summary with positions, real fills, volume, realized PnL and normalized execution cost.
The system runs as a supervised background service and can be controlled through Telegram with status, start, stop, close-all, balance and activity commands.
Guardrails
Operational controls
The production profile uses conservative leverage rather than the upstream high-leverage defaults. Position utilization is capped to preserve margin headroom, and the allocation logic is tested across repeated runs to ensure that the account carrying the larger side does not approach full margin use.
Each account has a strict one-to-one proxy mapping. A missing, duplicate or unhealthy proxy causes a startup failure instead of silently assigning two accounts to one connection.
Process controls prevent two bot instances from running at the same time. A service shutdown follows a separate path from a normal strategy pause so that restarting the service does not leave the previous cycle open and block recovery.
The Telegram layer is intentionally operational rather than promotional. It shows what opened, what closed, which fills were confirmed and whether the cycle completed normally.
Risk and compliance boundary
Market-neutral does not mean risk-free. The main risks are partial fills, spread cost, funding, liquidation, venue downtime, key compromise and a temporary directional position when one leg fails.
There is also a separate compliance risk: coordinated multi-account activity may be excluded by a venue’s incentive rules or interpreted as wash or sybil behavior. The system does not guarantee eligibility. Any public or commercial use requires a review of venue terms, self-trade prevention and applicable restrictions before deployment.
The system should never be described as a way to fabricate organic demand. Its legitimate value is in controlled execution, reconciliation, monitoring and cost measurement.
Validation and result
A controlled 17-hour run produced:
- 21 completed cycles;
- 126 confirmed fills;
- approximately $4,914 in open-and-close volume;
- zero emergency closures during the measured window;
- realized PnL of approximately -$0.33;
- an observed cost of about $6.75 per $100,000 of volume at that configuration.
The change in aggregate collateral reconciled with the PnL calculated from venue trade history. This mattered because the preliminary order log displayed limit ceilings, not actual execution prices. Using those log values would have overstated cost by roughly fifteen times.
The case therefore became as much an accounting and reconciliation exercise as an automation project: the useful number was not how many orders the bot attempted, but what the venue actually filled and what happened to the balances.
My role
I reviewed the original system, reduced unsafe defaults, added headless operation, introduced Telegram control, enforced account/proxy separation and designed the reporting format.
I also tested the live workflow, found settlement-timing and restart failures, and changed the measurement source from intended order parameters to actual trade history and collateral reconciliation.
Stack
- Python
- Perpetual exchange SDK
- Telegram Bot API
- Encrypted local key vault
- Proxy health checks
- systemd
- Automated tests
Proof
Private repository — it holds live exchange credentials and the account-separation setup. The run described above is a measured session, reconciled against venue trade history rather than the bot's own log.
Key lesson
A multi-account system is only market-neutral if the positions, fills and balances reconcile in reality. Matching the plan is not enough; the external venue state must confirm it.