Trading Venue

Why the venue runs on the platform#

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.

The venue holds traders' units in one escrow it controls, and the escrow pays out only through each token's own transfer, so the token's rules still judge every delivery. On a token with the current compliance contract, the seller's deposit into the escrow runs the token's sender-side rules. The delivery out of the escrow runs its rules for the buyer as recipient. A recipient the rules refuse does not undo the trade: its leg waits in its free escrow balance until it passes the rules again. 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.

Compliance risk stays with the token, because every delivery runs through the token's own rules. A reversal of a delivered trade uses custodian forced transfers, which skip those rules on chain, so the platform checks the rules against the reversal transfers before it accepts the bust. A platform administrator or the organisation owner sets each instrument's maker and taker fees and its fee account on chain, signing with a wallet that holds the venue operator role.

What a venue is, and what an instrument is inside it#

A venue is a tenant's own exchange, run on its own terms. It admits whoever it decides to admit, keeps its own calendar and fee schedule, carries its own on-chain identity, and records its admission policy on chain, which the platform checks at order intake. A private instrument narrows it further to the participants it names, and the token's own compliance still decides every delivery. A tenant runs as many venues as it needs, one for retail members and one for institutional desks, or one per jurisdiction.

The trading venue is the “Secondary market” licensed module, and a deployment ships with it off. While features.tradingVenue is off for the deployment, the venue routes answer as not found and the Console shows no venue screens. While it is off for one organisation, that organisation keeps read access to its venues and instruments, and every write is refused with HTTP 403 platform.module.DISABLED, error DALP-20531, with data.module set to tradingVenue. The FIX drop copy also needs the surveillance module.

An instrument 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 instruments, with two order books and two prices, and halting one leaves the other trading. At most one instrument per token on each system is that token's reference instrument, and only its official close reaches the token's price feed. An instrument's close is computed by a defined methodology set at the instrument: the last trade price, or a volume-weighted average over a configured window before the close. A session with no settled trade closes at its auction price and then the previous close, or straight at the previous close, as the instrument's “No-trade fallback” decides.

Listing: what a venue gets and what stays with the issuer#

Listing grants the venue contract no custodian role over a token. The venue asks its escrow to lock, unlock, relock and pay out the units owners committed. A venue admin can also have the escrow sweep out a surplus, meaning units that reached the escrow without being owed to any owner. No path in the venue contract reaches a forced transfer, an address freeze, or a recovery on a listed token. The venue and its escrow follow their factory's implementation, so a holder of the system manager role, or the add-on registry, can repoint the factory and change the code of every live venue and escrow at once. The escrow itself keeps two emergency exits. For a DALP token, any holder of that token's custodian role, the organisation's operations signer included, can move an owner's free and locked escrow units to another wallet through the escrow. The escrow pays with an ordinary token transfer, so the recipient must pass the token's rules. For a plain ERC-20, only the venue contract may force a transfer, and the venue contract has no code that does. A recovery moves a lost wallet's free escrow balance only to the wallet the identity registry names as its replacement.

Listing gives no platform account a custodian role either. A bust lends one. A delivered trade's bust always waits for a second operator, so the venue never waives it. When that bust is approved or resumed, the platform grants the organisation's operations signer the custodian role on the access manager of both the base and the quote token, signed by the listing signer, and waits for both grants to settle on chain. It then sends the forced transfers that reverse the trade, and revokes the role from both tokens when the reversal ends, whether it completed, failed or stalled. A proposal that waits for its second operator grants nothing, so a proposal that is rejected or expires never leaves a role behind. The platform lends only a role the operations signer does not already hold, so a role a token admin granted on the token's Permissions page stays. When the grant 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 bust is refused and names the step to fix: a token admin grants the custodian role to the operations signer on the token's Permissions page. A reversal that stalls partway can lose the role while a transfer is still in flight, and resuming the bust lends it again. When a revoke cannot be sent or does not settle, the platform logs the token so a token admin can revoke the role on the token's Permissions page. Tokens listed before busts lent the role still carried the role their listing granted, because nothing revoked it. The platform takes those back too: it finds each one by matching the role the chain shows to the grant transaction the organisation's own queue recorded for that listing, and the operations signer gives the role back with no admin role needed. A role a token admin granted sits in a different transaction and is never touched. The platform leaves a token alone while a bust on one of its markets is approved, executing or failed and waiting to resume, so a cleanup never takes the role away from a reversal that is under way. A renounce that fails is sent again on a later pass under a new request key, up to eight attempts, and after the last the platform logs an error so a token admin can revoke the role on the token's Permissions page. Only a role held by the organisation's current operations signer is given back. When the holder is a former operations signer, or the organisation has no managed operations signer, the role stays, and the platform logs the token and counts it so a token admin can revoke it on the token's Permissions page.

Every token is handled the same way, because the venue has one escrow and the escrow has one set of rules. The escrow is an instance of the escrow add-on, a custody contract that the venue controls for many owners, and it keeps a free balance and locked balances per owner and token. When a trader places an order, the venue checks the signature, pulls from the trader's wallet only the shortfall, the part of the commitment the trader's free balance lacks, and locks the order's amount. The trader's only approval is an ERC-20 approval to the venue's escrow, for a DALP token and a plain ERC-20 alike, and an order that free balance already covers needs none. A commit the approval does not cover is refused on chain and the order never rests. The escrow has its own on-chain identity with a dalpEscrow claim and sits on the compliance bypass list. A deposit into it therefore runs the token's sender-side rules, such as the address block list and time lock, and skips the rules that judge the recipient. On a token that uses the first version of the token compliance contract, a deposit into the escrow skips every rule, sender-side ones included. A payout from it runs the recipient's rules in full. A token with holding rules exempts the escrow's claim from those holding rules.

A platform administrator or the organisation owner can list a token. The listing is accepted only when three things hold: the listing signer has the venue operator role, the organisation has an operations signer on the chain, and that signer has the venue submitter role. A failed check refuses the listing with the step and account to fix. The listed instrument then stays pending until its go-live preconditions complete: a registered feed writer, an eligible fee account, a trading schedule, a trading model, a valuation price, a floor price where the instrument needs one, and listing rules the instrument meets. A listing the venue contract itself reverts is refused with the venue's error name, so the caller sees which venue rule the listing broke. Listing needs no hold feature and no reserver authorisation from an issuer.

What the venue limits for every instrument, and what it only suggests#

A venue can limit the order types and the time in force that every instrument on it accepts. The limit is a ceiling, and it applies to instruments already listed as well as to new ones: an instrument accepts what it sets for itself and the venue also allows. Orders already resting stay on the book. Raising a limit again restores the option for instruments that still list it. A limit that would leave a listed instrument with no order type, or no time in force, is refused when the venue admin saves it, so a venue never strands an instrument that traders can no longer use.

The venue can also hold starting values for the maker and taker fee, the fee account, the market-order protection band and the holding period. These are not limits. The listing wizard copies them once, when an operator opens it, and the operator can change each one. Once the instrument is listed it keeps its own value, and a later change to the venue's starting value does not reach it. A venue admin sets both on the Listing rules page, and a venue that requires a second approver holds the change for one. Venue operations covers the page.

Trading: how a resting order becomes a fill#

Every order is an EIP-712-signed intent, a typed structured message signed for the maker's wallet: by the custody provider after the investor's wallet verification for a custodial wallet, or by the investor's own wallet. The venue contract checks that signature, so it cannot place or change an order the maker's wallet did not sign. An order carries a type and a time in force, independently of each other.

A stop order is a limit order with a trigger price. The venue reserves the order's full amount when the trader places it, the same amount a limit order at that price reserves, and holds it while the stop is armed. The stop does not rest on the book. It is armed until the instrument prints a trade at or through the trigger price: a sell stop fires when a trade prints at or below the trigger, a buy stop when a trade prints at or above it. Any trade print counts, an auction uncross included. A fired stop joins the book as a limit order at its limit price, with the reservation it already holds, and is reported as a new order. A trader cancels an armed stop like any resting order, and the cancel releases the reservation in full. A stop also closes when it expires. A stop stays armed while an instrument is halted and activates once the instrument is live again. A suspension or a delisting cancels it with the rest of the book. Intake refuses a stop whose trigger is already on the wrong side of the last trade (a sell stop at or above it, a buy stop at or below it), a stop with a market order type, and a stop set to immediate-or-cancel or fill-or-kill: a stop is good-til-cancelled, good-til-date or day. The trigger price is not part of the maker's signed digest, so the order signature binds the amount, price and expiry, and the venue enforces the trigger server-side. A private instrument, one open only to the participants it names, takes limit orders only: good-til-cancelled, plus good-til-date and day orders on an instrument with a continuous book. A public instrument can allow every order type and time in force above. An instrument with no trading calendar refuses day orders, because no session close would expire them.

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 lock behind the removed quantity returns to the trader's free escrow balance. A new price or a larger quantity needs a newly signed order, because the maker never signed those terms. The venue cancels the original, which unlocks its remainder back to free balance, and then places the replacement from that free balance plus any shortfall deposited from the trader's wallet. When a fill of the original has no recorded settlement yet, as right after a partial fill, the cancel still stops new fills at once, and the request waits up to the reservation timeout for the venue to record that settlement before the remainder unlocks. The original closes as replaced, and 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. If the replacement fails after the cancel, the venue answers HTTP 409 with ORDER_AMENDMENT_INCOMPLETE, error DALP-12375: the original is cancelled and the replacement was not placed. A settlement the venue does not record within that wait answers this 409, and the remainder stays locked until the venue records the settlement and unlocks it to free balance. When the escrow or the book refuses the replacement itself, the remainder is already free. A repeat of the same amendment, once the remainder is free, places that replacement without cancelling the original a second time: an API caller sends the same signed replacement again, and a replacement the venue signs with the trader's custody wallet, as the Console and the Investor portal send it, is the same replacement when its terms are the same, because those apps derive its salt from the original order and the requested price and quantity. A replacement with other terms, sent as an amendment of the cancelled original, answers TRADING_VENUE_ORDER_NOT_FOUND. On this 409 the Console and the Investor portal say the original is cancelled, show whether its remainder is still locked or already back in free balance, and tell the trader to place a new order once the remainder is 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 commits it in its escrow: it checks the trader's signature, deposits only the shortfall from the trader's wallet, and locks the order's amount. The order rests and appears in the book only once that commitment confirms on chain. A commitment that reverts or times out, including one the trader's escrow approval does not cover, rejects the order before it joins the book, and rejected is terminal: the trader signs a new order, because the original is never retried. Once resting, the book shows each price level, streamed to readers as a full snapshot followed by diffs. Each instrument sets which attributes of a level its participants see: the price always, and the resting quantity and order count when the instrument 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 cancel, an expiry, or a prune unlocks the order's remainder back to the trader's free escrow balance, and nothing leaves the escrow. Free balance belongs to the trader, who withdraws it to their wallet from the Balances panel in the Console or the Investor portal, or through the venue balances API. The panel shows free and locked escrow balances per leg, and a withdrawal is refused when it asks for more than the free balance. A settlement that fails undoes its fill and frees both trade locks into free escrow the same way, and the Console desk rereads the escrow balances as soon as the fill reads Undone, so “Reserved for orders” clears with it.

A buy limit order locks enough of the quote token to pay its limit price plus a fee at the maximum fee rate the trader signed into the order, which the venue caps at its own maximum. The order ticket in the Console and the Investor portal signs the higher of the instrument's maker and taker fees, with VAT included when the venue collects VAT on chain. A fill below the limit price spends less than that. The unspent quote amount stays locked while the order stays open, and the venue unlocks it back to free escrow balance when the order closes: when it fills completely, or when it is cancelled, expires or is rejected. Until that unlock is on chain, the trader's Balances panel keeps showing the unspent amount as locked. The settlement stands either way.

An instrument can also run an auction, at the open or at the end of a collection window. During an auction the book collects limit orders without matching them, and the auction then matches the collected orders once, at a single clearing price. Every auction on an instrument prices by the instrument's “Pre-open price rule” setting, which has two options. Under the default, “Tie average”, the platform tests each price level that lies between the best sell price and the best buy price and keeps the level at which the largest quantity trades. When several levels trade that largest quantity, it keeps those that leave the smallest quantity unmatched. When more than one level is still tied, the clearing price is the mean of every tied level, not the midpoint between the lowest and the highest. The reference price and the last trade price play no part in a tie. When no buy price reaches a sell price, the auction does not trade.

The setting's other option, “Previous close reference”, anchors the auction on the instrument's previous official close. An instrument with no close yet uses the instrument's reference price, set at listing, instead. The option tests each order price on the book between the best sell price and the best buy price, and ranks the levels by the quantity that trades and then by the smallest gap between the buy and the sell quantity at that level. One best level is the clearing price. When several levels tie, the auction clears at the tied level nearest the anchor, and at the anchor itself when two tied levels sit equally near it. Without either a previous close or a reference price, the auction does not trade and the collected orders carry to the book. This option never averages prices, so the “Auction price rounding” setting plays no part. When no level trades and an anchor exists, the “Auction remainder” setting decides what happens to the collected orders, and that anchor is recorded as the auction price.

A public continuous instrument can end its continuous session with a closing auction. The calendar sets when it starts, between the open and the close, and before Trade at last when the day has one. From that time the book collects limit orders without matching them. One uncross at the end of the auction, at the Trade at last time or else at the close, matches them at a single price under the instrument's “Pre-open price rule”, and the “Auction remainder” setting decides what happens to the orders left unmatched. A band-refused or tie-blocked uncross does not hold the session open. The auction's price is the instrument's official close. An auction-only or private instrument has no closing auction. Day orders expire at the close.

A public continuous instrument can end its day with a Trade-At-Last session. The calendar sets when it starts, between the open and the close. From that time until the close, an order trades only at the last price: the last trade, else the previous official close, else the reference price. The instrument accepts limit orders at exactly that price, matches them against resting orders ignoring the price band, and refuses market, immediate-or-cancel and fill-or-kill orders and any other price. An unfilled good-till-cancelled or good-till-date remainder rests at the last price. The official close uses the trades up to the start of the session, so trades at the last price do not move it. An auction-only or private instrument has no Trade-At-Last session.

A price step, also called the tick size, is the smallest price change the instrument allows. Under the Tie average option, when the mean of the tied levels falls between two price steps, the instrument's “Auction price rounding” setting decides the clearing price. “Nearest step, half up” and “Nearest step, half down” round the mean to a price step. “Block between price steps” is the default and leaves the tie unresolved, so the auction does not trade. When this happens at the scheduled open, the instrument keeps collecting orders. When it happens at the end of a collection window, the instrument session closes. The instrument's “Auction remainder” setting decides what happens to the orders an auction leaves unmatched, including every collected order when the session closes this way: “Carry to the book” keeps them resting, and “Cancel remainders” cancels them.

The auction fills orders in the same priority as continuous trading. Buy orders fill from the highest price down and sell orders from the lowest price up, and at one price the earlier order fills first. Every fill trades at the clearing price.

An instrument whose session has a preopen, a period before the open in which the book collects orders without matching them, runs its opening auction at a moment no one knows in advance. The platform draws that moment at random inside a window that starts at the scheduled open time, so no order can aim at it, and it never publishes the drawn moment. The window length is a deployment setting. The trading calendar read returns it in milliseconds as uncrossWindowMs, and during the preopen the Console shows “Opens within N seconds after” the scheduled time, with the window length in seconds as N. A continuous instrument with no preopen has no opening auction and opens at the scheduled time.

A preopen order goes first only at the opening auction, which prices the collected orders together. Whatever the auction leaves unfilled then rests like every other order, by price first and arrival time second. A later order at a better price fills ahead of a leftover preopen order, and a later order at the same price fills behind it. This holds for a buy and a sell, and for as long as the order rests.

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

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 and chooses no 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 unlocks their locked balances.

An instrument can also carry a volatility interruption, a circuit breaker that is off until an operator sets it. The rule has a threshold in basis points, a duration in seconds, and a reference price: the last trade or the previous official close. A fill that would print further from the reference than the threshold does not print. Fills inside the threshold stand, and continuous trading stops at the first resting order beyond it. For the duration, the instrument collects orders without matching them. Then one single-price auction clears the book, and continuous trading resumes. The auction price is not bound by the market-order protection band, but the static band, the price band and the floor still apply, and an auction that cannot clear is retried on the next scheduler pass. A session change away from continuous trading ends the interruption. The instrument stream carries the interruption and its end time with the band, the drop copy sends it as a market report, and each start and end is recorded in the audit log.

An instrument can instead suspend the orders a band excludes. The band setting outOfBandCarryOver is close by default, which keeps the behaviour above. Set to suspend, it moves each resting order outside the band, including a good-till-cancelled or good-till-date order carried over from an earlier day, to the status suspended. The order records the reason, above-price-band or below-price-band, in its close reason field. A suspended order leaves the book and no trade can match it, but it keeps its reservation and its place in the time queue.

Every band change runs a reinstatement pass: a new session band, a widening after a trade, a saved policy, or a policy switched off. A suspended order that the band covers again returns to the book in its original time priority, and it trades at once if it now crosses resting orders. A suspended good-till-date order still expires on schedule, and its reservation is released. A participant can cancel a suspended order. New and replacement orders outside the band are still rejected. Drop copy reports a suspension as an execution report with order status Suspended and the reason in its text, and a reinstatement as the order being New again.

Issuer floors and anchor-based widths stored before this band policy keep applying. Turning the price band off does not remove those limits or per-order size limits. The separate market-order protection band also remains in force.

The maximum order size and the minimum and maximum order value can differ by participant class. A venue sets general limits, which apply to every class, at venue level and for each instrument. Either level can add limits for the retail, institutional or proprietary class. Claim topics are the identity evidence types a venue can require for admission, and the venue maps them to those classes. When the sender's identity holds mapped topics for more than one class, the order takes the most protective class: retail before institutional, and institutional before proprietary. When it holds none, the order takes the “Client classification” the instrument lists for that participant wallet, when there is one. The venue checks every limit that applies and keeps the strictest, which is the smallest maximum and the largest minimum. A class limit can therefore tighten the general limits but never loosen them. An order with no class is checked only against the general limits. The Console shows and edits an instrument's general limits. It has no field for the venue-level general limits, the class limits or the topic mapping, so you set those through the Platform API.

An instrument itself moves through one lifecycle: pending until every listing precondition completes, then live. An operator can halt or suspend a live instrument and resume it back to live, and a halted instrument can also be suspended. A delisting is permanent, and an operator can delist an instrument from any other state, a pending one included. The figure shows the main path and leaves out suspension and the delisting of a pending instrument.

A halt also suspends the instrument's scheduled auctions. An opening auction or a collection-window clearing that falls due while the instrument is halted does not run. The first session step after the operator resumes the instrument runs it. When a session ends while the instrument is still halted, it closes without its opening auction. A continuous session with no preopen also holds its open while the instrument is halted or suspended. The open applies on resume, and any crossing orders uncross.

An instrument can also carry a resume cut-off in whole minutes, and the venue's listing rules hold a default for instruments that set none. From that many minutes before the session close until the close, the platform refuses to resume a halted or suspended instrument with HTTP 409 MARKET_RESUME_INSIDE_CUTOFF, error DALP-174401, which carries the close time and the cut-off. After the close a resume is allowed, a cut-off of 0 blocks nothing, and an empty cut-off leaves resume unrestricted.

Settlement: a fill is not delivery#

A matched trade is reported, priced, and published straight away, and on an instrument with a positive holding period both legs stay locked in the escrow, 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 an instrument's holding period to zero delivers inside the fill's own transaction, with no window before delivery. A bust on such a trade reverses a delivered trade with custodian forced transfers.

Before delivery, an undo is not a reversal. Nothing has moved yet, so unlocking 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. The venue undoes a pending trade with the same event and bookkeeping whatever the cause. The causes are an approved bust, an outside cause at delivery, and the settlement submitter's automatic undo. An outside cause is one the trader did not choose. The venue lists four: a paused token on either leg, a trade lock that a custodian shrank below what the legs need, a frozen sending side (the account that owns the lock, or the escrow itself), and a receiver added to the compliance bypass list during the holding period. The API reports an undo for an outside cause as refused. It is not a bust, which always starts with an operator's proposal. An undo for an outside cause 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. An undo unlocks each leg back to its owner's free escrow balance, and the owner withdraws it to their wallet.

Any other refusal at delivery does not undo the trade. A receiver can make the token refuse a transfer to itself, for example by removing its own identity claim during the holding period, and undoing the trade for that would hand the receiver a free option to walk away from a price that moved against it. Instead the venue pays every leg that can be paid and books each refused leg to its receiver's free balance in the escrow. That booked leg is a parked leg. The trade counts as delivered, and the venue emits a DeliveryLegParked event for each parked leg next to the delivery event. Each leg is judged on its own: the base leg, the quote leg and each fee leg can park separately, and both sides of a trade can park. The parked units sit in the receiver's free balance, and the receiver withdraws them like any other free balance. The withdraw runs the token's compliance and freeze checks again, so a receiver that is still unverified or frozen cannot take them out. It cannot sell them on the venue either: placing an order that would lock units from the free balance is refused with MakerCannotReceiveToken while the token's identity registry does not verify the maker, or while the token's compliance would refuse the escrow paying that maker.

On a venue whose Trading venues row under “Approvals” is on, a bust needs two venue operators. One proposes it within 24 hours of the trade, and a different operator approves or rejects it. With the row off, a bust of an undelivered trade is recorded already approved and the undo starts at once, with no second person. A bust of a delivered trade reverses it with forced transfers of the holders' tokens, so it needs a second operator whether the row is on or off. When the trade is still pending, the proposal flags it on chain at once. Delivery skips a flagged trade for up to seven days past its due time, so the clock cannot settle a trade while the decision is open. Delivery itself needs no role: once a trade is due and no review holds it, any account can call it on the venue contract. A rejection clears the flag, and the trade delivers once it is due. An approval runs the undo at once. If delivery remains pending after the flag's review window closes, the settlement service can still complete the approved undo. On chain, only a holder of the venue submitter role can undo a trade, and the platform holds that role in the organisation's operations signer. The platform submits the undo only after the bust's approval. The second approval is a platform check, and the venue admin grants and revokes the submitter role. 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. The Console and the Platform API set and clear the flag only through a bust proposal and its decision. A holder of the venue operator or venue submitter role can also flag or clear a pending trade directly on the venue contract, with no proposal and no second approval, which holds that trade back from delivery for up to seven days past its due time. 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 the trade stays held until an operator clears the flag or the seven-day review window ends.

A trade that already delivered is outside the venue contract. A bust on a delivered trade is still possible inside the same 24 hours, from the Console or the Platform API, 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, both fees, and any VAT paid on chain go back to the buyer. The Console lists delivered and pending trades alike for a bust proposal.

A forced-transfer reversal is queued as one chain of transfers signed by the operations signer, each under its own fixed idempotency key. The queue confirms each transfer on chain before it queues the next, and the approval waits for the whole chain for as long as its request allows, keeping back enough time to record the outcome. When the queue does not confirm the chain in that time, the outcome is unknown, because the transfers may already be queued and still land. The bust then goes back to approved. “Resume” reads the bust's own queued transfers first. It records the bust as executed when all of them have been sent, and it re-sends under the same keys when they have not, so no transfer goes out twice. Only a reversal the queue refuses outright fails the bust.

Market data: what an instrument publishes#

An instrument keeps its own price record from its trades: an official close for each session, a ticker, candles and live streams. The ticker and the candles leave out an undone trade, because a bust takes the trade out of the prices as well as out of the books. Every instrument opens and closes on a trading calendar that its venue and the instrument set together, and every venue event that concerns a participant lands in their notification list. Venue market data explains the close, the ticker and candles, the streams, watchlists and price alerts, the trading calendar and how a participant hears about an order.

Announcements#

A venue operator publishes an announcement to the whole venue or to one instrument, and an issuer can publish one about its own security, which waits for a venue operator's approval. Announcements covers scheduling, attachments, issuer announcements, history and publication windows.

Controls and evidence#

Admission is checked when an order arrives. Revoking a participant's admission does not cancel the orders they already have resting. Cancel those from the Orders screen. At intake the maker must be a participant the venue admits and, on a private instrument, a participant of that instrument. Removing a wallet from a private instrument cancels its open orders on that instrument and leaves one cancellation batch. An instrument denial is narrower than losing admission: it bars one wallet from one instrument, records the reason and who recorded it, and leaves the venue's other instruments open to that wallet.

An access profile sets what one participant may do on one instrument: place orders, see the instrument in watchlists, see order book depth, and trade the instrument groups the profile lists. Every instrument always has a default access profile that matches its privacy: “Full access” on a public instrument, “Watchlist only” on a private one. No instrument is without one, so a participant who has no profile of their own always follows the instrument's default. A venue operator can override each setting for one participant, and a setting the override leaves out follows the profile. PUT /api/v2/addons/trading-venues/{venueAddress}/markets/{marketId}/participants/{walletAddress}/access replaces the profile and the overrides in one call. It needs a reason of up to 500 characters and a wallet verification, and only a platform administrator or the organisation owner can call it. A venue operator or venue admin can read the same route, which returns the profiles the instrument offers, the participant's overrides and the effective access. The effective access still honours instrument membership and any denial, so a barred wallet has no access whatever its overrides say. The instrument's participant list (GET /api/v2/addons/trading-venues/{venueAddress}/markets/{marketId}/participants) returns that effective access for each wallet in access, and the Console Participants table shows it in an Access column: the actions the wallet can take, or Denied for a barred wallet. A new order from a participant whose instrument group list holds neither the instrument's group nor all is refused with instrument-group-not-permitted.

A participant without depth access sees only the best bid and ask by default, or no book when the instrument's depth-denied mode is none, and no indicative quote either way. Venue operators see 50 price levels. On a public instrument, an entitled participant sees the instrument's entitledDepthLevels and other participants see participantDepthLevels, each from 1 to 50. A participant on a private instrument sees only the best bid and ask. The depth read and every stream snapshot carry depthAccess as allowed, top-of-book or none, so a client knows what the book shows. GET /api/v2/addons/trading-venues/{venueAddress}/participants/{walletAddress}/access gives a venue operator or venue admin one wallet's whole access to the venue: its admission, block, required verifications, freezes on the listed securities, private-instrument memberships, effective access on every instrument and approved desk limits. A wallet that is not a participant of the venue answers 404 TRADING_VENUE_PARTICIPANT_NOT_FOUND.

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. The platform rebuilds a book's state by replaying that trail, and it rebuilds the drop-copy reports and the daily surveillance files from the same trail. The trail is the platform's own record. Order commits, fills, deliveries and undos are also on chain, and the retention policy moves expired records to the venue archive.

Every order also has a trading member: the broker a venue operator assigned to the participant that owns the wallet, or the participant itself when it has no broker. The platform works the member out as of the moment of the order, so assigning or clearing a broker changes the member of later orders only. An earlier order keeps the member it had. Only venue operators receive the member. PATCH /api/v2/addons/trading-venues/{venueAddress}/participants/{walletAddress}/access assigns it. A trader or a broker never sees a member, another participant's name or the counterparty's order on the platform. The venue contract's trade events name both wallets on chain, so a reader of the chain can still link a trade to the buyer's and the seller's wallets.

A running venue changes only through the venue role each change needs, and a second holder of that role approves while the venue's Trading venues switch under Approvals is on. When the deployment enables the FIX drop copy, the venue also sends a surveillance provider each order and trade event as it records it, and the platform rebuilds a completed trading day's reports and the daily surveillance files from the same trail. Venue controls covers who can change a running venue and who must agree, the drop copy session and its reports, the order-lifecycle file mapping, the replay and the daily surveillance files.

The integration contract#

For an integrator, the Trading Venue is a versioned API route group under /api/v2/addons/trading-venues. Chain-writing calls such as venue and instrument administration writes can answer 202 with a status URL to poll. Placing an order answers 200 with the order's id and hash once its escrow commitment confirms and the order is on the book. When the commitment has not confirmed inside the request, or the caller asked for an asynchronous answer, the call answers 202 with a Location header. Poll GET /api/v2/addons/trading-venues/{venueAddress}/order-placements/{orderId} until its status reads placed or failed. An order amendment answers the same way.

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 figure below omits one open state: suspended, which an instrument that suspends orders outside its price band uses between working and a close or a return to the book. It counts as open, so the order still holds its reservation.

In the API, a trade's status is pending-delivery, delivered or undone, and an undone trade carries an undoReason of bust, refused or reserver-removed. refused means an outside cause blocked delivery. Any other refusal parks the refused leg, and the trade is delivered. reserver-removed marks the settlement submitter's automatic undo of a pending trade, which needs no bust proposal. An order also carries a settlementStatus that rolls up its trades: none, pending-settlement, partially-settled, completed or settlement-failed.

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

Frequently asked questions#