Trading venue compliance model
What the Trading Venue can and cannot do with the custodian role it holds, why the token remains the final compliance judge at fill, how private-market visibility and trade busting are bounded, and what audit evidence the venue produces.
The Trading Venue executes trades without weakening the compliance model of the tokens it lists. This page states the venue's control boundaries for auditors and compliance reviewers: what the token still decides, what the custodian-role grant actually delegates, and what the venue's contract provably cannot do. It also states how private-market visibility and trade busting are bounded, and what evidence the venue produces.
Fast answer for reviewers
- Only identity-registered participants can place orders, on both the investor and institutional tiers; a private market additionally requires the maker wallet on its approved-participant list.
- Every fill settles through the listed tokens' own transfer path, so the token's identity and compliance-module checks remain the final judge at execution. The venue cannot move tokens between ineligible parties.
- The venue holds each listed token's custodian role, and that role is broad at the token level. The venue's own contract, however, exposes no path to forced transfers, address freezes, or token recovery; it calls only partial freeze, partial unfreeze, and allowance-based transfers. This holds for trade busting too: the compensating reversal runs through an operator-held custodian identity, never through the venue contract.
- Every order is an EIP-712-signed intent verified on-chain, so the venue can neither fabricate nor alter an order, and an on-chain cancellation can never be filled.
- Trade busting never rewrites settlement: the original settlement stays final, and the bust is a second, maker-checker-approved, pre-checked compensating transaction.
- Private-market privacy is application-surface access control; the on-chain footprint, feed prices included, is intentionally public.
- The venue keeps an identity-linked audit trail of signed orders, book events, session transitions, auction uncrosses, stop triggers, fills, matching skips, and busts, deterministically replayable for regulator review.
The token remains the final compliance judge
The venue settles a fill in one transaction frame: it releases the reserved amounts in the traders' own wallets, then pulls them under each trader's trading authorization through the token's normal transfer path. That path runs the full identity and compliance-module evaluation that governs every platform transfer. The venue deliberately does not use forced transfers for settlement, because forced transfers bypass compliance modules; a fill that would violate the token's rules reverts instead of settling.
Eligibility is checked three times: at order intake against the identity registry, at match time by simulating the settlement call, and at execution by the token itself. A resting order whose owner loses eligibility is pruned when the change is detected, or its fill reverts in isolation if the change lands between simulation and execution.
The custodian-role grant and its breadth
Listing a market requires the issuer of each listed token to grant the venue the token's custodian role. Reviewers should evaluate this grant as it is, not as it is used:
| Fact | Consequence for review |
|---|---|
| The custodian role carries the token's full custodial powers: partial freeze and unfreeze, forced transfer, address freeze, and recovery. No freeze-only variant exists. | The grant is a real delegation. The issuer's consent is a listing precondition, and a declined grant leaves the market unlistable. |
The venue's contract calls only freezePartialTokens, unfreezePartialTokens, and allowance-based transferFrom. It exposes no entrypoint that reaches forced transfer, address freeze, or recovery. | The breadth of the role is bounded by the venue's code. Verify the deployed venue implementation, and re-verify after an upgrade, rather than relying on the role scope. |
| The role is revoked on delisting only when no other live market lists the token. | A token shared by two markets keeps the grant while either market lives. |
The venue uses the role for exactly one purpose: reserving accepted orders as reserved balances in trader wallets, and releasing those reservations at fill, cancellation, expiry, or pruning.
Non-custodial settlement
The venue never takes possession of funds. Tokens stay in trader wallets until the moment a fill transfers them; there is no pooled account, no omnibus wallet, and no venue-held float. What backs a resting order is a reserved balance in the trader's own wallet, reduced atomically with each partial fill. Reviewers can reconcile reservations and fills directly against on-chain events, and after a crash the venue does the same before it resumes matching.
Signed intents and cancellation
Every order is signed by the maker's key, smart-account signers included, and the settlement contract verifies the signature, price, quantity, expiry, and signed fee cap on-chain before any token moves. Cancellation is effective on-chain, per order and as a bulk cancel, so a cancelled signed order cannot fill even when the venue matched it before the cancel arrived.
Institutional funding under maker-checker
Desk trading authorizations and desk limits pass four-eyes control: a proposer submits them and a distinct approver confirms them before the desk can trade. Orders beyond approved limits are rejected at intake. Approval governs funding and limits, never individual fills, so the control does not create a per-trade intervention point.
Approvals are persisted platform records, not screen state, and one approval store backs desk limits and trade busts. Every proposal and decision carries its actor and timestamp, and a decided record accepts no second decision. The distinct-actor rule is enforced by the platform and additionally pinned by a database constraint.
Private-market visibility and its boundary
A private market's participant list is enforced at a single visibility choke point that every read, list, and stream surface inherits. To a caller without an approved wallet, the market does not exist: list responses omit it, and direct reads answer not-found, never forbidden, so an unauthorized probe cannot even confirm the market exists on the platform. An open stream re-checks membership continuously and stops delivering within one poll cycle of a removal, and removal also prunes the wallet's resting orders and dormant stops with reservations released.
State the boundary precisely in any review: privacy is application-surface access control. The market's on-chain footprint, creation events, reservation events, fills, and published feed prices, is intentionally public, because the venue publishes prices for every market into the feed infrastructure that anchors bands, valuations, and mark prices. A private market is confidential distribution on governed rails, not chain-level secrecy.
Trade busting: a bounded, dual-controlled remedy
Busting reverses an erroneous trade without touching settlement finality. Verify these control properties in review.
Settlement stays final. The original on-chain settlement is never modified or rolled back. The bust is a second transaction: a compensating reversal returning both legs, plus a fee refund from the operator fee account. Both transactions remain in the audit trail.
The venue contract plays no part in the reversal. It executes compliance-path-first through an operator-held custodian identity, under the tokens' own transfer rules. The venue's contract keeps zero forced-transfer surface, so the bust capability adds no power to the venue itself. If the compliance path cannot move the tokens, the bust is refused, never forced.
The pre-check runs twice. Eligibility (both orders fully closed, chain-confirmed fill, inside the operator-configured window), counterparty balances, fee-account balance, and compliance-path viability are verified at proposal time, where a failure refuses the request and records nothing. The same checks re-run in full at approval time, because state can move between the two.
A distinct actor decides. The proposer can never approve their own bust; the platform refuses it and the approval store's constraint pins it. Execution is atomic: the reversal and the fee refund complete together or not at all, and a failure marks the record failed with no leg applied. There is no one-legged state.
Downstream data corrects honestly. The busted trade stays visible, flagged, in history and both counterparties' blotters, while candles and the ticker recompute excluding it. Feed submissions cannot be retracted, so the published price is corrected by a new, marked observation, and a busted official close recomputes and republishes. Stop triggers and band evaluations that already fired are not reversed; that is recorded behavior, not an omission.
Randomized uncross secrecy
A session-based market opens through a call auction whose uncross moment is randomized inside an operator-configured window. The platform publishes the scheduled open and the window width; the drawn instant is generated server-side from a cryptographically secure source and is never serialized to any API response, stream event, or client surface. This is a deliberate information boundary: a participant who could learn the exact uncross instant could game the final order before the open. Reviewers should treat the drawn instant as operator-confidential material and verify that only the scheduled boundary and window width appear on published surfaces.
Identity-linked audit trail
Every venue participant is registered in the deployment's identity registry, so every order, fill, and cancellation ties to a registered identity. The venue records signed orders, book events, session transitions, auction uncrosses, stop arms and triggers, fills, matching skips (including self-cross skips), and settlement outcomes in a sequenced audit trail. The engine's book state is deterministically replayable from that trail, across session boundaries, auctions, and stop cascades. On-chain, per-order fill accounting is the source of truth for what settled. Participants read their own working orders, reserved balances, and trade blotter through participant-scoped API routes; market administration is role-gated to the venue operator, and participant-list and approval changes are audit-trailed with their actors.
See also
- Trading Venue capability for the full architecture and trust boundaries.
- Compliance and custody split for the platform-wide control split the venue inherits.
- Trading venue order lifecycle for where each check runs in the flow.
- Trading venue market structure for sessions, auctions, bands, stops, and busting as concepts.
- Bust an erroneous trade for the operator procedure behind the bust controls.
- Run private markets for the operator view of the visibility model.
- Trading venue operations for the operator controls: listing, calendars, halts, fees, and desk administration.
Compliance and custody control split
Understand how DALP separates identity and compliance decisions from custody approvals and signing policies when token operations are executed.
Mint replay, idempotency, and supply controls
How DALP keeps EVM mint retries tied to one queued transaction while preserving nonce ordering, signer approval, and per-asset supply controls.