Venue operations

Venue operations is the operator control room for every market on the trading venue. From here you list a market, move it through its lifecycle, tune its price bands and fee schedule, grant desk trading limits, and undo a pending delivery through the trade-bust control. Reach for this page when you administer the venue itself, not when you place an order.

Trading is the investor and desk workspace for trading on a market that already exists; Venue operations is where that market is built, watched, and, when something goes wrong, corrected. This page is also distinct from Pause and freeze. Pausing or freezing acts on the token contract itself and reaches every venue and every wallet that holds the token. Halting a market here stops matching on this one venue only, and it leaves the token's other transfer paths and other markets' status unchanged. Shared token or network restrictions can still affect them.

A venue is a deployed contract that lists one or more markets, each a base and quote token pair with its own tick size, lot size, price bands, and fee schedule. A desk is an internal trading limit an operator grants a trader wallet, separate from the eligibility a wallet needs to trade at all. Market DataMarket Data gives valuation, compliance, and reporting one governed price for an asset or currency pair, so they stop reconciling separate copies of the market.Read the concept owns the price-data model the operator's tape and chart read from. Transfer-Path ComplianceTransfer-Path Compliance enforces a regulated token's rules inside the on-chain transfer itself, so a movement that fails any rule reverts and never settles.Read the concept governs delivery. An undo releases reservations; an escrow release can become a credit the trader must claim under the token's transfer rules. Maker-checkerMaker-checker keeps a single mistaken instruction or a single compromised account from moving money, filing a report, or approving a corporate action alone.Read the concept is the two-operator pattern desk limits and busts run on.

Every market carries one of four states, and what an operator can do next depends on which one it is in. Before the listing is accepted, the listing signer must hold the venue operator role and the organization's operations signer must hold the venue submitter role. The base and quote reservation backends must also be ready: a DALP token needs its hold feature and the issuer's authorization for this venue as a reserver; a plain ERC-20 needs the venue's escrow vault bound. A missing prerequisite refuses the listing and identifies the step and account to fix. An accepted market starts pending while its listing ceremony checks the reservation backends, registered feed writer, and eligible fee account. The "Listing ceremony" checklist on the market detail marks each item "Complete", "Blocked", or "Awaiting" and refreshes itself every ten seconds while the listing is pending. A live market accepts orders and matches them under its price bands; from live, an operator can halt it or delist it. A halted market accepts no new orders and matches nothing; from halted, an operator can resume it or delist it. Delisting is available from every state and moves a market to its fourth and final state, where new trading remains disabled. Pending delivery obligations keep their own lifecycle.

Halting is reversible, delisting is notCopy Anchor Link

Halting and delisting sound similar. They do very different things to what is already in flight.

Most listing choices get a later edit, three do notCopy Anchor Link

The listing wizard asks for more than a token pair, and its choices differ in how long they bind.

A continuous market matches orders as they arrive; an auction-only market matches only in auction crosses. A private market restricts trading to approved participant wallets in either matching mode, and its participant list stays editable after listing. A private market never shows an indicative price or quantity.

A private listing also asks who initiated it, under "Listing initiated by": the issuer (sponsored) or a holder (unsponsored). On a sponsored market the venue refuses an order, buy or sell, from a wallet whose registered country the security's country rules exclude, or whose country it does not know. When the venue's listing rules set admission minimums, the wizard asks for the value in US dollars and the number of shares made available, and the venue refuses a private listing below either minimum. An optional floor price, in ticks, on the risk step is saved with the price bands.

A DALP token gives each venue a hold lifetime, and a hold that expires before the holding period ends undoes the pending trade as refused. A hold's lifetime runs from the reservation, so an order that rests before it fills uses up part of it. When a leg token's hold lifetime for this venue is at most the market's holding period, the risk and summary steps show "A hold can expire before its trade settles". When the lifetime is longer but not 0, which never expires, they show "A resting order can lapse before delivery" and name how long an order can rest before it fills. On a market with no holding period, that notice says an order resting longer than the whole lifetime loses its reservation and is cancelled. When the Console cannot read the hold lifetime, they show "The hold lifetime could not be checked" instead. None of these notices blocks the listing. Ask the token's issuer for a longer hold lifetime, or shorten the holding period, before you list: no editor changes the holding period afterward.

Two of the choices with an editor carry mechanics worth knowing before you rely on them. Maker and taker fees, in basis points and zero allowed, adjust through "Edit fee schedule" on the Fees tile, which opens the fee schedule in a side panel with the resting-order impact shown before a raise applies. The official close methodology opens through "Edit official close" on the Trading style tile and saves through "Save methodology", between "Last trade" or "VWAP" with its window. Price bands and order caps open through "Edit price bands" on the Risk controls tile.

A tighter band rejects new orders, not the ones already restingCopy Anchor Link

A market's fee schedule and price bands change what already-resting orders can do without cancelling them outright, and the two react differently.

Raising the fee schedule above a resting order's signed fee cap does not silently charge the difference. It prunes that order the next time it would otherwise fill, exactly like a fee increase during ordinary trading. Before you apply the change, the fee-schedule screen reports the number of resting orders it affects, or states plainly that the affected count is not yet reported if the venue cannot compute the figure yet.

Two separate controls on the market detail tune the post-listing bands: "Static band (bps)" and "Dynamic band (bps)". Both reject an incoming order priced outside them; neither touches a resting order directly. They are distinct from the "Price protection band (bps)", which is set once at listing and has no editor afterward: it guards market orders instead, closing one that would fill outside it with a protection-band reason rather than letting it walk the book. The static band needs a session reference price to anchor against before it can judge anything, so confirm one exists before you rely on it.

Tightening either band, or the maximum order size, rejects incoming orders only. Saving a tighter limit never cancels a resting order by itself, so an order that now sits outside the new limits keeps resting until you separately choose "Prune out-of-band orders". Pruning is its own confirmed step: it removes those specific orders, marks them "Pruned" rather than "Cancelled", and releases their reserved balances.

Desk limits and trade busts both need a second operatorCopy Anchor Link

Desk limits and trade busts use maker-checker approval. One operator proposes; a different operator approves. The server rejects self-approval. A desk trading limit, once approved, is read at order intake as a ceiling on that trader wallet's exposure, separate from whatever eligibility or venue-wide authorization already applies. A limit that is only proposed does not yet constrain anyone's orders.

A trade bust undoes a pending deliveryCopy Anchor Link

The Console retains the label "Trade busts" for its undo workflow. A proposal can target a pending delivery whose holding period has not ended, within 24 hours of the trade. It flags the trade to stop scheduled delivery while the operators decide, and the flag holds the trade past its due time until the decision. A different operator approves or rejects the proposal.

Approval runs the undo at once: the settlement service submits one on-chain call that releases both reserved legs. No operator key can submit that call itself. The undo does not reverse delivered assets or refund a fee already paid. Rejection clears the flag so the delivery can proceed. A delivered trade, a trade without a pending obligation, or an expired holding period cannot enter this flow.

If the chain call completes before the platform records the result, "Resume" completes the remaining record updates. The trade becomes "Undone" and its market-data contribution is corrected. A stop order already triggered by that trade stays triggered.

Venue health starts unreported, never falsely healthyCopy Anchor Link

The venue-health panel reports four independent measures. Each one starts as "Not yet reported" rather than a false "Healthy", because a metric the venue has not yet supplied is not the same claim as a metric that checked out fine. Once the venue exposes a real read, each measure moves to "Healthy", "Attention", or "Failed" against its own threshold.

A calendar override adds one exception for today, and still needs savingCopy Anchor Link

A market's trading calendar sets its normal weekly session and any dated holiday or half-day exception. The operator overrides "Delay open", "Extend trading", and "Close early" are not a separate mechanism from that calendar: each one prefills a dated exception for today on top of whatever the calendar already says, and the exception takes effect when you select "Save calendar". "Delay open" moves today's open 30 minutes later, "Extend trading" moves the close 60 minutes later, and "Close early" sets the close to the next minute, never at or before the open. An override does nothing on a day with no session, whether the weekday is disabled or a holiday exception suppresses it, because there is nothing to delay, extend, or end early. The exception an override writes is marked with the override's name, "Unsaved override" until you save and "Override" afterwards, and the mark is stored with the calendar, so an intervention stays distinct from a hand-entered half-day after a reload.

A day without a preopen opens straight into tradingCopy Anchor Link

Each weekday in a calendar reads preopen, open, close. Leave the preopen time empty and that day has no preopen phase: the market stays closed, refusing new orders, until the open, then goes straight into continuous trading at the open itself, with no opening auction and no randomized uncross window. An auction-only market without a preopen still runs its opening call at the open over the orders it collected before the last close, then collects for the next one. This suits a private market with no opening price to discover. A private continuous market cannot schedule a preopen at all: the platform rejects a calendar that sets a preopen time on a weekday or an open exception for it, and the market always opens straight into trading at the open. A dated exception that states an open and a close but no preopen keeps whatever the weekday says, so a half-day on a day without a preopen has none either.

StepsCopy Anchor Link

TroubleshootingCopy Anchor Link

The market action is unavailable

Each state allows a different set of controls, and the market you are looking at may not offer the one you expected. A pending market offers only delisting; nothing else is available until its listing ceremony completes on its own. A live market offers halt and delist. A halted market offers resume and delist. A delisted market offers nothing further; it is a closed state with no controls at all. If the control is visible but the submission is refused, that is the server's role check. Market administration is gated server-side on the venue-operator role, so a session without it sees the controls and receives, on dispatch, the refusal described in the error catalog.

There is no New market control

The venue does not exist yet. The Console shows "New market" only once your organization has provisioned a venue, because a listing with no venue behind it cannot succeed. Use the "Provision a trading venue" card on this screen: name the venue, optionally describe it, and confirm with your wallet, and it deploys from the Trading Venue factory registered in your system. If the platform reports that the factory itself is not available, the system deployment's addon registration has not finished indexing, or the trading-venue addon was never installed; the error catalog describes both refusals.

A market is halted

Open the market detail and review its controls and health signals before you resume trading. A halt blocks new orders and matching, but every resting order and reserved balance from before the halt is untouched, and a submitted settlement batch keeps its own execution outcome. Nothing about resuming needs to account for cancelled orders, because a halt never cancels any.

A venue-health measure shows Attention or Failed

The panel only reports the read; fixing what it reports happens outside it. "Attention" on settlement failures means at least one fill failed in the trailing 24 hours; review the failing fills before they reach five, which is "Failed". "Attention" on the gas budget means the settlement submitter's wallet balance has dropped below your organization's configured warning floor; fund that wallet before it reaches zero, which is "Failed" and stops submissions outright. "Attention" on feed publishing means the market has no feed configured yet; "Failed" means a configured feed has stalled, and either state needs the feed fixed at its source. "Attention" on reconciliation means one is already running; "Failed" means the chain state has diverged from the venue's own record, and you should not treat the venue's reported balances as current until that divergence is resolved.

A fee schedule or price band change did not do what you expected

A fee schedule increase never cancels a resting order outright; it prunes an affected order only at the moment that order would otherwise fill. Before you apply it, the screen tells you the number of resting orders that carry a signed fee cap below the new schedule, or states that the affected count is not yet reported if the venue cannot compute it yet. A price band or order-size change behaves differently: saving a tighter limit leaves every existing resting order exactly where it was, even one that now falls outside the new limits. If you need those out-of-band orders gone, use "Prune out-of-band orders" as its own separate, confirmed step; it marks the affected orders "Pruned" and releases their reserved balances.

A desk limit proposal is not yet effective

A proposed desk limit does nothing until a distinct operator approves it; the trader wallet's exposure is still governed by whatever limit, if any, was effective before. If you proposed the limit yourself, you cannot also approve it: the server rejects a self-approval outright, since the whole point of maker-checker is that a second person confirms the first person's proposal. Ask another venue operator to review and approve it.

A trade bust cannot be proposed or remains incomplete

Check that the trade has a pending delivery and that its holding period has not ended. Delivered or already-undone trades, missing pending obligations, and duplicate open proposals are refused. A proposal flags the trade, so its holding period cannot end the trade's pending state while it awaits a decision. If the chain applied the undo but the record is incomplete, use "Resume" and verify the released reservations. Escalate a reported reconciliation mismatch before signing it off.

An operator calendar override had no effect

Two causes look identical from the trading screen, and the fix differs. The overrides prefill a dated exception for today in the calendar editor; if you selected "Delay open", "Extend trading", or "Close early" and then navigated away, nothing was saved, so open the calendar again and select "Save calendar" after the override. The other cause is a day with no session. An override does nothing when the weekday is disabled in the template or a holiday already suppresses today, because there is no open to delay, no close to extend, and no session to end early. Overrides never touch tomorrow's schedule or the weekly template.

Frequently asked questionsCopy Anchor Link