Tokens, venues, and the configuration model
What is code, and what is a setting
Abyss draws a clear line between the two: connecting a new exchange for the first time is engineering work; everything else about how the desk trades is a live setting.
| Requires an engineering change | Is a live, no-deploy setting | |
|---|---|---|
| A brand-new exchange | Yes, one adapter class speaking that exchange's API, added once | — |
| An exchange already connected | — | Enable, disable, credentials, connection parameters, endpoint |
| A token | — | Listing, activation, per-venue instrument mapping |
| A pair | — | Adding it, pausing it, its base spread, its size limits |
| Risk and hedge budgets | — | Per-asset caps, per-venue notional limits, breaker thresholds |
| Partner access | — | Issuing, scoping, and revoking API keys |
| Alerting | — | Who is notified, on what, how often |
The exchange adapter is a one-time cost per venue. Once it exists, the exchange is managed like every other, through the same console and the same partner API. The remaining settings carry no engineering cost.
What trades today
The catalog on the live test network is small: NIGHT (Midnight's native token), ADA, and ETH, quoted against each other (NIGHT–ADA, NIGHT–ETH, ADA–ETH). ADA and ETH carry perpetual futures on all five connected venues; NIGHT on three. USDC and USDT are recognized as stable assets throughout the risk logic. These are current settings, not fixed properties: adding a token means deploying its on-chain contract and registering it, its pairs, and its per-venue symbols, live, with no code change and no restart.
The partner surface
Beyond its own console, the desk exposes a managed API for programmatic partners. It covers: tokens (list, activate, deactivate), instruments (per-venue symbol mappings), venues (connections, credentials, live account and position reads), budgets (per-asset hedge capacity), notifications (alert routing), and feeds (read-only price and connectivity state). Spreads and risk thresholds are not on the partner surface; those remain the desk's.
- Keyed, revocable access. Partner keys are issued once, shown once, and stored only as cryptographic hashes. They can carry expiry dates, be revoked individually, or be cut off by suspending the partner. Failed authentications return an identical response regardless of the reason.
- Credentials are write-only. A partner's exchange credentials are probed against the live exchange before being stored, and can never be read back through the API, only replaced.
- Every write carries a reason, into the same audit trail the console uses.