Trading Venue

A venue is a tenant's own market: its own members, its own calendar, its own fees, under one on-chain identity, and a tenant runs as many as it needs. A market is one trading line inside a venue, so the same pair listed on two venues is two markets with two prices.

Listing gives the venue contract no custodian power. A DALP leg stays inside the trader's own wallet; a plain ERC-20 leg sits in the venue's escrow vault. The one custodian role a listing grants goes to the organisation's operations signer, which the platform uses only to reverse a delivered trade after an approved bust.

A fill is not delivery. With a positive holding period, both legs stay reserved until delivery; a market with a holding period of zero delivers inside the fill's own transaction, with no window at all.

Why trading needs a venueCopy Anchor Link

Issuance is a single event. A primary offering sells newly created units once, and the register then closes to that offer. What a holder does with the position afterward is a separate question the sale itself never answers.

An institutional buyer prices that gap in before they ever subscribe. An instrument nobody can exit is worth less to hold than one that trades, and that discount lands on the offering itself, not just on the holder stuck with it later. A venue is what turns a single sale into an instrument with an ongoing market.

That places trading downstream of issuance, inside the same asset's working life rather than beside it. Asset Lifecycle names the stage directly: after an instrument is issued and unpaused, it is serviced for as long as it lives, and settling trades sits in that same Service stage next to paying coupons, freezing holdings, and collecting fees. Primary Offering is the contract-governed first sale that life begins from; a venue is what happens to the same asset afterward, for as long as anyone wants to trade it.

Why this venue runs on the platform, not beside itCopy Anchor Link

The alternative to a venue built into the platform is a venue built beside it. That second system lists the same tokens under its own view of who may hold them. It needs its own way to hold units mid-trade too, because a trade in progress has to sit somewhere between the seller and the buyer, and each of those is a seam. A seam is where the exchange's own rules and the issuer's rules can quietly disagree: a trade the venue allows and the token's own compliance would have refused.

This venue carries no such seam, because the venue contract never becomes a second custodian. The same identity check and transfer rule that govern every other movement of a listed token are the same check and rule that govern its delivery here, described in full below. A delivered trade is a normal token transfer, so it lands in that asset's own record the same way every other movement does, next to the coupons, freezes, and fee collection Asset Lifecycle already indexes there.

That single fact is also most of why a financial institution reaches for this rather than a bolt-on exchange. Compliance risk stays with the token: every delivery runs through the token's own rules, and the platform checks those rules against the reversal transfers before it accepts a bust on a delivered trade. And the operator keeps the fee schedule and market-making arrangement it already runs, rather than adopting a third party's.

What a venue is, and what a market is inside itCopy Anchor Link

A venue is a tenant's own market, run on its own terms. It admits whoever it decides to admit, keeps its own calendar and fee defaults, and carries its own on-chain identity to back that up, so who can trade there is answered by that venue's admission policy and nothing else. A tenant runs as many venues as it needs, one for retail members and one for institutional desks, or one per jurisdiction.

A market is one trading line on one venue: a base token, a quote token, and the book, price band, fee schedule, and holding period that make them tradable there. The same pair listed on two venues is two markets, with two order books and two prices, and halting one leaves the other trading. Exactly one market per token is that token's reference market, and only its official close reaches the token's price feed. A market's close is computed by a defined methodology set at the market: the last trade price, or a volume-weighted average over a configured window before the close, or over the whole session when no window is set. A session with no settled trade closes at the price its opening auction set.

Listing: how a token trades without handing over custodyCopy Anchor Link

Listing grants the venue contract no custodian role over a token. Its own code is written so that role cannot exist, whatever an operator might otherwise promise. Every reservation request the venue makes is written to never name which backend it is talking to: it asks the token's bound backend to reserve, release, or deliver, and nothing else, ever. No path in the venue contract reaches a forced transfer, an address freeze, or a recovery, on any listed token.

Listing does give one platform account a custodian role. The organisation's operations signer, the same account that submits settlements, receives the custodian role on the access manager of both the base and the quote token, signed by the listing signer. That role exists for one job: reversing a trade that already delivered, after an approved bust, through custodian forced transfers. The platform uses it nowhere else. The grant is skipped when the operations signer already holds the role, and it never blocks a listing. When it cannot be made, for example on a plain ERC-20 with no access manager or when the listing signer cannot grant roles on the token, the platform logs the step to fix: a token admin grants the custodian role to the operations signer on the token's Permissions page. Until then, a bust on that market cannot reverse that leg after delivery.

Which backend a token gets follows from how it was made. A DALP token is issued through the platform's own factory, the contract that deploys every instrument the platform creates, so it carries a hold feature the venue can call directly. The committed units stay inside the trader's own wallet, unspendable elsewhere while the order works, and they leave the wallet only at delivery. A plain ERC-20 exposes no such interface, because nothing about it was built for this. The venue's escrow vault pulls the units in against the trader's approval instead, and can pay them out only to the trader as a claimable credit or to a counterparty at delivery. A listing is accepted only when each DALP issuer admits the venue as a hold reserver, each plain ERC-20 has the venue's escrow vault bound, the listing signer has the venue operator role, and the organisation's operations signer has the venue submitter role. A failed precondition refuses the listing with the step and account to fix. Listing asks an issuer for the right to reserve on one named venue, and for nothing broader; the issuer sets how long a hold stays effective and can drop the venue at any time.

Trading: how a resting order becomes a fillCopy Anchor Link

Every order is an EIP-712-signed intent, a typed structured message signed by the trader's own key, so the venue can neither fabricate nor alter an order before it moves a token. An order carries a type and a time in force, independently of each other.

A stop is not a fourth order type. It carries a trigger price on a limit or a market order instead, and the venue reserves nothing for it until a settlement-confirmed trade reaches that price.

A resting order can be amended in two ways, and the way decides its place in the queue. Lowering its quantity at the same price is done in place: the order keeps its id, its signature and its position, and the reservation behind the removed quantity is released. A new price or a larger quantity needs a newly signed order, because the maker never signed those terms. The venue closes the original as replaced and enters the new order in the same step, so there is no moment with both or neither on the book. The new order takes its own id, joins the back of the queue at its price, and may trade at once if its price crosses. It inherits the original's reservation, so only the difference is reserved or released. Both kinds of amend are recorded in the order log, so a drop copy can report them as replacements.

An accepted order does not join the book directly. The venue first reserves the committed quantity through the market's bound backend, and the order rests and appears in the book only once that reservation confirms on chain. A reservation that reverts or times out rejects the order before it joins the book, and rejected is terminal: the trader signs a new order rather than expecting the original to retry. On a leg that the token's hold feature backs, each reservation carries a single-use receipt on the venue. When no order rests on a reservation, the platform closes its receipt, which returns exactly the units that reservation froze, or stops it from landing if it has not landed yet. The trader's budget counts the reservation until the finalized chain shows the receipt closed. Once resting, the book shows each price level, streamed to readers as a full snapshot followed by diffs. Each market sets which attributes of a level its participants see: the price always, and the resting quantity and order count when the market allows them. A hidden attribute is sent as null, and the venue operator sees every attribute. The engine matches strictly by price and then by the order's time of arrival.

A buy limit order reserves enough of the quote token to pay its limit price plus the higher of the market's maker and taker fees. A fill below the limit price spends less than that. Once the settlement transaction confirms and the fills are recorded, the platform releases each buyer's unspent quote reservation for the filled quantity, so price improvement returns to the trader at the fill. Each holder's surplus is its own release request, and the platform retries it durably, up to five attempts, before it falls back to a manual resolution by an operator. The settlement stands either way. The surplus release and the release of an expired good-till-date order each carry the drain serial recorded on the order's reservation at placement, and the venue skips an entry whose serial a trader's exit has moved, so a delayed release never returns backing that a newer order holds. If the venue reverts such a release as exceeding the reservation, retries stop: the amount stays counted and is reported for an operator. Placement refuses an order when the venue's drain serial cannot be read.

A venue price band limits both accepted limit prices and trade prices. The venue default starts Off. Each instrument inherits that default, turns the policy off, or overrides it for its market models.

Both bounds are inclusive. A dynamic band widens only the side a trade reaches, by one expansion step, up to the cap. The reference remains the previous official close until the next session close resets the band. Without an anchor, a dynamic band blocks trading rather than choosing a reference price.

The venue rejects an out-of-range limit order as above or below the band. Continuous fills and auction clearing prices must also stay inside it. A market order is signed at its separate protection-band edge, but its fills still stop at the effective price band. Saving a tighter policy cancels excluded resting orders and releases their reserved balances.

Existing issuer floors and legacy anchor-based widths remain effective for stored configurations and persisted history. Turning the new policy off does not remove those limits or per-order size limits. The separate market-order protection band also remains in force.

A market itself moves through one lifecycle: pending until every listing precondition completes, then live, with an operator-controlled halt and resume, and a delisting that is permanent from either state.

A halt also suspends the market's scheduled auctions. An opening auction or a collection-window clearing that falls due while the market is halted does not run. The first session step after the operator resumes the market runs it. When a session ends while the market is still halted, it closes without its opening auction. A continuous session with no preopen only changes session state, so it keeps its schedule through a halt.

Settlement: a fill is not deliveryCopy Anchor Link

A matched trade is reported, priced, and published straight away, and on a market with a positive holding period both legs stay reserved, untouched, for a window after that. The token's own compliance check is the venue's final authority on whether a transfer is legal, and that check only runs at the moment of delivery: the holding period is what waits for it. Atomic settlement at the moment of the trade is available too: setting a market's holding period to zero delivers inside the fill's own transaction, with no window and no undo, because there is nothing left to undo.

Before delivery, an undo is not a reversal. Nothing has moved yet, so releasing both legs has nothing to move back and no fee to refund; it is closer to the trade never finishing than to the trade being cancelled. Whether an approved bust undoes a pending trade or the token itself refuses the transfer at delivery, the venue fires the identical event with identical bookkeeping, one mechanism with two triggers rather than two separate features. The token's own refusal is the one case that looks like a real correction, since the trade was already reported: the price is corrected, the trade drops from clean history, and both sides are told why. Whichever backend held the leg, an undo pays out differently: a hold's units return to the trader's wallet on their own, an escrowed leg becomes a balance the trader claims from the vault.

A bust needs two venue operators. One proposes it within 24 hours of the trade, and a different operator approves or rejects it. When the trade is still pending, the proposal flags it on chain at once. Delivery skips a flagged trade, even after its due time, so the clock cannot settle a trade while the decision is open. A rejection clears the flag, and the trade delivers once it is due. An approval runs the undo at once. Only the settlement service, which holds the venue submitter role, can submit that undo on chain, and it does so only after the approval. No operator or admin key can undo a trade on its own. Before queueing the undo, the platform refuses a bust the venue would reject: a delivery that is past its due time without a review flag, or an organisation operations signer that lacks the venue submitter role. The refusal applies when the bust is proposed and again when it is approved or resumed. An operator can still flag or clear a trade by hand. Setting and clearing the flag is best effort, and a failure never cancels the proposal or the decision. When the flag cannot be set, only the holding period keeps the trade from delivering. When the flag cannot be cleared after a rejection, the platform logs the gap, and an operator clears the flag before the trade can deliver.

A trade that already delivered is outside the venue contract. Through the Platform API, a bust on a delivered trade is still possible inside the same 24 hours, and the platform first checks that the token's compliance rules allow the reversal transfers. An approved bust then sends custodian forced transfers under the operations signer: the base units go back to the seller, and the quote units the seller received and both fees go back to the buyer. The Console offers a bust only on a pending delivery.

Controls and evidenceCopy Anchor Link

Admission is checked repeatedly, not once. At intake the maker must be a participant the venue admits, and admission is checked again when a stop triggers and again immediately before matching or settlement. Five data changes re-run it too: an admission policy change, a membership revocation, a removed claim, a removed trusted issuer, and an identity registry status change. A participant who loses admission has their resting and pending orders pruned and their reservations released.

Evidence is identity-linked, sequenced, and venue-scoped: the trail carries signed orders, book events, session transitions, fills, deliveries, and undos with their reason, each naming the venue it belongs to. From that trail, the book's state is deterministically replayable, so what happened is something a regulator can recompute rather than take on trust.

What each drop copy report carriesCopy Anchor Link

The drop copy sends one Financial Information eXchange (FIX) ExecutionReport for each order and trade event. Besides the order, price, quantity and status tags, every report carries the fields a surveillance system uses to attribute and time the event.

The first restart after an upgrade that changes these fields rebuilds the drop copy's saved order state from the venue log.

Validus OLC v6.4 mappingCopy Anchor Link

The Validus order-lifecycle (OLC) file is a comma-separated file with a fixed 68-column schema. The dsched drop-copy olc command emits the file from the drop-copy reports. The mapping below records the source used for each column. empty means that the drop-copy report does not carry a value for that field.

The current drop-copy report contract has no spread envelope, leg, trader, or operator identity fields. It therefore emits SPREAD_ID empty, LEG_FILL and SPREAD as 0, and preserves replacement ancestry through RELATED_ID; a future spread/leg source must be added to the report contract before those fields can be populated without guessing.

The report body supplies the event fields. Session identifiers are not stored in that body, so the sender, target, deliver-to, and on-behalf-of columns come from the drop-copy session context and are empty when that context is unavailable.

The integration contractCopy Anchor Link

For an integrator, the Trading Venue is a versioned API route group. A chain-writing call answers with an accepted status and a status URL, and acceptance is not placement: an order becomes matchable only after its reservation confirms on chain.

An order's own status and a trade's delivery status are two separate tracks, and reading one for the other is the mistake that costs an integrator a real position.

The full contract, every status, every field, every error, is in the API reference.

Frequently asked questionsCopy Anchor Link