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.

To stop the whole venue, open its Overview tab and select Pause venue. A venue operator or admin can pause it after wallet verification. The venue then refuses new orders with the reason venue-paused, stops opening sessions, and stops settlement. Existing orders stay on the book. Only a venue admin can select Resume venue. Resuming the venue does not resume a market that was halted separately. Use this control for a venue-wide incident; use a market halt when only one market must stop.

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, eligible fee account, trading schedule, valuation price, and price floor. A continuous market needs weekly trading days, its own or the venue's; an auction-only market needs a collection window in the market's or the venue's timezone. A private continuous market always needs a price floor. The market goes live only when every item is complete and a private listing still states its sponsorship and meets the venue's current minimum admission value and share count. A market that falls short stays pending until a later check finds it complete. 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. It shows participants only the top of the book, one level a side, even when the market listed before that rule with full depth stored. A public market keeps its own "Full depth" or "Top of the book only" setting, which the "Book shown" tile on the market detail names.

A private market carries "Good till cancelled" and "Good till date" orders that did not fill in an auction to the next auction by default ("Carry to the book"). "Cancel remainders" stays selectable at listing. A carried order keeps its hold, and a "Good till date" order still expires on its date. When an auction is blocked or refused at the window close, a carry market keeps its resting orders. Only a market set to "Cancel remainders" cancels them.

Each market also sets which attributes of a book level its participants see. The price is always shown. The quantity and the order count are each optional, and a new market shows all three. You choose them in the listing wizard and change them later under "Participants see" in the market's order rules editor, where "Price" is locked on. A hidden attribute reaches participants as null over the API, in both the book read and the stream, and the order book ladder shows "Hidden" in place of a hidden size. The depth chart shows "This market does not show quantities, so there is no depth to chart." The venue operator always sees full depth with every attribute. A change to a hidden quantity sends participants no stream update.

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 pending trade is paid from the holds at its due time. A hold's lifetime runs from the reservation, so an order that rests before it fills uses up part of it. The venue refuses a fill whose delivery would fall due at or after either hold's expiry: the fill fails with a hold-expiry reason and both orders keep their reservations. The venue refuses a holding-period increase for a leg token with a finite hold lifetime. A decrease always goes through. 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. A VWAP close is the volume-weighted average price of the settled trades in that window before the close, rounded down to the tick. If nothing traded in the window, the close uses the same window strictly before the session's last trade, excluding that trade. If the fallback window has no trades, the previous official close is used. If the session had no trades, the close is the session's auction price when an auction set one, otherwise the previous official close. A trade that settles after the session closes updates the official close once it settles. Price bands and order caps open through "Edit price bands" on the Risk controls tile.

A tighter price band cancels excluded resting ordersCopy Anchor Link

Set the "Venue price band" on the venue's "Listing rules" page. Its default is "Off". "Static" takes a minimum and maximum quote price. Both must fit every inheriting market's tick size exactly; an incompatible market prevents the change. "Dynamic" takes an initial percentage, an expansion step, and a maximum threshold.

On the market detail, open "Edit price bands" on the Risk controls tile. The instrument's "Price-band setting" offers "Inherit venue default", "Off for this instrument", or "Instrument override". That selection applies across the instrument's market models. Inheriting instruments follow later venue-default changes; an override uses its own static or dynamic policy.

A dynamic band starts around the previous official close. A trade at a bound widens only that side by one step, up to the maximum threshold. The next session close resets it around the new official close. Trading is blocked when the dynamic policy has no anchor. Static and dynamic bounds include both endpoints and apply to continuous fills and auction clearing prices as well as limit-order admission.

Saving a tighter policy cancels every resting order outside the new range and releases its reserved balance. No separate prune action is required. The order ticket shows the configured range. Market orders retain their separate signed protection limit, but each fill must also stay inside the effective price band.

Existing issuer floors, maximum order sizes and values, and legacy anchor-based widths remain effective for stored configurations and persisted history. "Off" disables only the new price-band policy. Raising the issuer floor also cancels resting orders below it. The separate "Price protection band (bps)" remains set at listing, with no editor afterward.

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.

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. The flag holds the trade past its due time for at most seven days, and never later than one hour before either side's hold expires. After that the trade delivers and the bust can no longer undo it. 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.

Settlement instructions show what each settlement movesCopy Anchor Link

Finance operations needs to know which token moves from whom to whom, and in what amount, before and after a trade settles. The "Settlements" tab of a venue answers that without a chain explorer. It is read only and needs the venue-operator role, the same as the trade-bust list.

The tab lists the venue's trades in batches. Trades that settle in one transaction form one batch. A trade that has no settlement transaction yet is its own batch, shown as "Awaiting settlement". Open a batch to see each trade with its legs: the securities, the cash, and the fee, each with payer, payee, and amount. A trade that has not settled shows its cash at gross value and no fee leg, because the fee is fixed when the trade settles. Batch totals leave out undone trades.

Filter the list by batch status, or export the loaded batches from the table menu. The tab loads the newest 200 batches and says when the venue has more. Delivery versus payment batches that do not come from this venue are on the XvP settlements page, and the tab links to it when that add-on is deployed.

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, up to seven days past the due time or one hour before a hold expires. A bust approved after that point is refused, and the trade delivers. 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