Trading Venue
The Trading Venue capability provides a permissioned central limit orderbook per deployment: identity-registered participants trade listed platform token pairs with non-custodial reservation, deterministic matching, and failure-isolated on-chain settlement.
The Trading Venue is the execution venue in front of the platform's settlement layer. Each deployment runs its own venue: a permissioned central limit orderbook where the deployment's identity-registered investors and institutional desks trade any pair of listed platform tokens. The venue owns price discovery, order matching, and trade execution. It is not a shared exchange across deployments, not a bridge, and not a fiat cash settlement rail. The broker or exchange legal role also remains with the operating institution.
Every order is an EIP-712-signed intent from the trader's own key, smart-account signers included. The matching engine is deterministic and applies price-time priority. Matched fills settle on-chain in batches where each fill executes independently, so one failing fill never blocks the rest. The settlement contract verifies each order signature before any token moves.
Owned contracts
| Contract | Responsibility |
|---|---|
| DALPTradingVenueImplementation | Market registry, EIP-712 order verification, fill accounting, fees, cancels |
| DALPTradingVenueFactoryImplementation | Factory deployment of the venue instance for a deployment |
| DALPTradingVenueProxy | Upgradeable proxy for the venue instance |
Market model
A market lists any two distinct platform tokens as base and quote within one deployment. Stablecoin or deposit-token quotes are the expected common case, not a constraint. Each market defines a tick size, a minimum lot and notional, a price protection band, and a maker/taker fee schedule.
Traders place limit and market orders and can cancel working orders. A market order executes as a marketable limit bounded by the operator-set price protection band, anchored to an independent reference price feed when the market has one, else the last trade. An order that would execute outside the band is refused, not filled at any price. Resting interest is visible as aggregated depth; an incoming order never matches a resting order of the same identity.
Custody model
The venue is non-custodial. Tokens stay in trader wallets until the moment a fill transfers them, and the venue holds no pooled funds.
When the venue accepts an order, it reserves the committed quantity in the trader's own wallet as a reserved balance: base token for sells, quote token plus the maximum applicable fee for buys. An accepted order joins the book only after its reservation confirms on-chain. Cancellation, expiry, or a remainder below the market minimum releases the reservation. Reservation accounting is cumulative per wallet and token across all markets, and each partial fill reduces the reservation atomically with its settlement.
Before a trader's first order, the trader establishes a trading authorization to the settlement contract. The venue rejects any order whose authorization is below the reserved amount plus the maximum applicable fee.
Listing ceremony
Listing a market is an explicit ceremony with named preconditions. A market missing any precondition cannot go live, and the operator surface shows the blocked step.
- The venue operator creates the market with its pair, tick and lot sizes, price protection band, and fee schedule.
- The issuer of each listed token grants the venue the token's custodian role. This grant is broad: the custodian role carries the token's full custodial powers, not a venue-scoped subset, so the issuer's decision is a real delegation and a declined grant leaves the market unlistable.
- The venue verifies its feed-writer registration for the market so it can publish traded prices.
- The operator fee account is identity-registered and stays monitored; a fee account that loses eligibility halts the affected markets.
Delisting mirrors listing: the venue cancels all resting orders, releases the reservations, and permanently closes the market. The venue's custodian role on a token is revoked only when no other live market lists that token.
Compliance guarantee
Only participants registered in the deployment's identity registry may place orders, on either tier. The token's own transfer eligibility check remains the final compliance judge at fill time: a fill settles only when both legs pass the same checks that govern every platform token transfer. The venue cannot move tokens between ineligible parties, because settlement executes through the tokens' own compliance path.
A custody or compliance change can invalidate resting orders: an address freeze, a forced transfer, or a compliance-module change. The venue detects the chain event and prunes the affected orders in bulk, releasing their reservations, instead of discovering the divergence at fill time.
Institutional desk funding passes maker-checker approval: an approver distinct from the proposer approves trading authorizations and desk limits before the desk can trade, and the venue rejects orders that exceed approved limits before they reach the book. Approval governs funding and limits, never individual fills, so the book stays live.
Fees
Each market carries a maker/taker fee schedule set by the venue operator; zero is allowed. Fees are taken from the quote leg at fill into the operator fee account, atomically with settlement. Every signed order carries a maximum fee. A fee-schedule increase never applies to a resting order beyond its signed maximum. Orders whose signed maximum falls below the new schedule are pruned.
Pricing feeds
The venue integrates with the platform's price feed infrastructure in both directions. It reads reference prices for the price protection band and mark-price display, anchoring the band only to sources independent of the venue. It publishes each market's last-traded price back into the feed infrastructure, marked venue-sourced, so valuations elsewhere on the platform can consume venue prices.
Roles
| Role | Permissions |
|---|---|
| Venue operator | Lists markets, sets fee schedules, halts, resumes, and delists markets |
| Issuer | Grants and revokes the venue's custodian role on a listed token |
| Investor | Places and cancels orders within identity-registry eligibility |
| Desk trader | Trades within approved desk limits |
| Desk approver | Approves desk trading authorizations and limits under maker-checker |
| Settlement submitter | System role that signs and submits fill batches on-chain |
Trust boundaries
Signed intents: the venue can neither fabricate nor alter an order. The settlement contract verifies each order's EIP-712 signature on-chain and enforces the signed price, quantity, expiry, and maximum fee.
Cancellation is effective on-chain, per order and as a bulk cancel-all, so a cancelled signed order can never fill, even if the venue matched it before the cancel arrived.
Failure isolation: each fill in a settlement batch executes independently. A fill that fails at settlement is pruned from the book, the surviving counterpart order re-rests at its priority, and both parties are notified.
Crash safety: settlement submission is idempotent, with on-chain per-order fill accounting as the source of truth. After a crash, the venue reconciles reservations and fills from on-chain events before it resumes matching.
Auditability: the venue produces a complete audit trail of signed orders, book events, fills, and matching skips, from which the engine's state is deterministically replayable for regulator review.
Operator surfaces
Venue operations are available through the Console and the API.
- Console (investor): a trading screen per market with the order book ladder, depth chart, price candles with volume, recent trades, an order ticket with reserved-balance preview and estimated fees, working orders, and the trade blotter.
- Console (operator): venue operations with the markets list, market creation, listing-ceremony status, fee schedules, halt and resume, delisting, venue health, and desk administration under maker-checker.
- API: market data, including book snapshots, trades, candles, and ticker, plus order placement and cancellation, follows the platform API's versioned-route conventions with live streaming updates.
Halting a market stops matching and new order acceptance. It cancels no orders and lets already-submitted settlement batches complete.
Failure modes
| Failure | System behavior |
|---|---|
| Reservation does not confirm | The order never joins the book and is not shown in depth |
| Fill fails at settlement | The fill is isolated; the counterpart order re-rests; both parties are notified |
| Order expires | The venue removes the order and releases its reservation; expiry is also on-chain |
| Compliance change hits resting orders | Affected orders are pruned in bulk and their reservations released |
| Fee account loses eligibility | Affected markets halt until the operator restores an eligible fee account |
| Engine crash | The venue reconciles from on-chain events before matching resumes; no double fills |
Related
- XvP Settlement for bilateral atomic exchange without an orderbook
- Capabilities layer overview for how capabilities extend the platform
- SMART Protocol integration (ERC-3643) for the compliance framework
- Component catalog for the full platform inventory
Capabilities - System addons for asset operations
Capabilities are optional system addons for asset operations. They add focused workflows for orderbook trading, atomic settlement, and issuer-signed market data without putting every workflow into an asset contract.
XvP Settlement for atomic cross-party exchange
The XvP Settlement capability provides atomic cross-party token exchanges with all-or-nothing local execution, per-sender approvals, expiration controls, and optional hashlock coordination for referenced external legs.