A desk is an internal trading limit an operator grants a trader wallet, separate from the eligibility a wallet needs to trade at all. On the Desk administration tab, a venue operator proposes a desk limit and a different operator approves it. A proposed limit constrains no order until that approval. The tab also lists the venue configuration changes that wait for a second operator, where a different operator approves or rejects each one.
The “Desk administration” tab with “Desk name”, “Trader wallet” and “Open-exposure cap” fields and the “Propose desk limit” button, above the “Proposals” and “Effective desk limits” tables.
Steps
Propose a desk limit
Pick the Instrument by its pair, such as EUROC / AEDT. When the venue lists the same pair twice, the trading model tells the two apart.
Enter the “Desk name”, choose the “Trader wallet”, and enter the “Open-exposure cap”, which must be above zero and counts the resting orders plus the new order in the quote token.
Select Propose desk limit and confirm with your wallet verification. While the “Trading venues” row is on, the Console reads “Desk limit proposed. A different operator must approve it.” With the row off it reads “Desk limit active.”
Decide a proposal
A different venue operator opens “Desk administration”, finds the limit under “Proposals” with the “Proposed by” column, and selects Approve or “Reject”, confirming with their wallet verification. An approved limit moves to “Effective desk limits”, and a rejected one leaves the list.
Proposals lists only the proposals that wait for a decision. On a proposal you made, the row reads “Needs a different venue operator” and offers no “Approve” or “Reject”. Another operator sees both. When nothing waits, the list says “No desk limit proposals are open”.
Approve or reject a venue configuration change
Venue configuration approvals on “Desk administration” lists the changes to this venue that wait for a second operator. Expand a row to see what the change does. Each changed field appears under its own name, with its “Before” and “After” value. Each value reads as the operator entered it. Prices show in the quote token and sizes and notionals with the token symbol. Windows and periods show as durations such as “5m”, and on and off settings, countries and fees show in words. A list such as the trading week, date exceptions, closed days, collection windows or fee tiers shows one line per entry. A field the stored state does not carry reads “Not set”.
The “Actions” column appears only while a row has an action for you. Select Approve change to apply it or “Reject change” to drop it, and confirm with your wallet verification. A change you proposed offers neither, because a different operator must decide it. When nothing waits, the table reads “No venue configuration changes are waiting for approval”.
Which changes need a second operator
The Trading venues row under “Approvals” on the “General” page of “Organisation settings” decides whether these changes, sent through the Console or the Platform API, wait for a second operator. An exception there can turn it on or off for one venue. A venue admin can also turn the second operator on or off for this venue through the Platform API, and turning it off waits for a second venue admin like the changes below:
- desk limits and trade busts
- single order cancels and mass cancels. A venue submitter wallet that calls the venue contract directly cancels any order with no second person, and so does a venue operator wallet unless the venue's default admin set an on-chain approval rule for that cancel
- instrument listings, settings, fees, price bands, order limits, order types and closing method
- instrument halts, suspensions, resumptions, delistings and scheduled status changes, except an emergency halt the venue admin has allowed to skip approval, which runs at once
- removing a participant from an instrument
- the venue and instrument trading calendars, closed days and collection windows
- the venue price band, listing rules, VAT policy, retention period, fee tiers and admission. Admission, the venue calendar and closed days also wait for a second person while the Administration row protects the “Venue administration” group
- fee schedule changes
- pausing or resuming the venue
- turning the second operator off for the venue, or letting an emergency halt skip it. A venue with a single admin has to add a second admin first, because the proposer cannot approve their own change. Turning the second operator on, or stopping emergency halts from skipping it, applies at once
Only venue admins propose and decide a change to the venue price band, admission, listing rules, VAT policy, retention period, venue calendar or closed days, and the resumption of a paused venue. Deciding a change to an instrument's listing, settings, fees, price bands, order limits, order types, closing method, halt, status or participants also needs the Platform admin or Owner role. A fee schedule change is approved by a different platform administrator or organisation owner. The distinct-operator rule is per record: any venue operator may propose some changes and approve others, and the server refuses only a decision on a record that same operator proposed.
With the row off, none of them asks for a second person: a desk limit is enforced at once, a bust of an undelivered trade starts its undo at once, a new fee schedule version becomes the active schedule, the VAT policy is saved, and a cancel runs. Each change applied this way is logged as not approved by a second person. A bust of a delivered trade always waits for a second operator, because its reversal moves the holders' tokens with a forced transfer. Cancelling all of one participant's orders is a mass cancel limited to that participant, so it follows the same row: with the row off, one venue operator runs it at once after wallet verification.
An instrument listing on a venue whose row is on waits under Venue configuration approvals until a second operator approves it. The listing wizard ends with a link to this tab. Price bands and order limits you set in the wizard travel with the held listing, the approval row shows them to the second operator, and the approval applies them to the new instrument.
An approved desk limit is read at order intake as a ceiling on that trader wallet's exposure, on top of whatever eligibility or venue-wide authorisation already applies.
When a proposal expires
A desk limit, bust, mass cancel or fee schedule proposal that no second operator decides in time expires. The window is 24 hours by default. The platform operator can set a different window for desk limits, for busts, and for mass cancels and fee schedule changes together. A venue configuration change expires after 24 hours. A single order cancel does not expire, because its approval is refused once the order is no longer open.
The “Expires” column on the Mass cancellations tab and the “Due” column in the Actions inbox show the deadline of a proposal. An expired proposal shows Expired and offers no “Approve” or “Reject”, and the server refuses a decision that arrives after the deadline. The platform closes an expired proposal within about a minute and records the expiry in the audit trail. An expired bust clears its flag in the same way as a rejection, so the delivery can proceed. If the change is still necessary, propose it again.
Troubleshooting
A proposed desk limit has no effect
A proposed desk limit does nothing until a different operator approves it. Until then, the limit that was effective before still applies, or none. The server rejects a self-approval, so ask another venue operator to approve a limit you proposed.
API routes
A venue admin turns the second operator on or off for this venue with PUT /api/, after wallet verification. Turning the second operator off, or setting allow to true, answers with the proposed change instead of the new setting and waits under Venue configuration approvals until a different venue admin approves it. The setting stays as it was until then. Turning the second operator on, or setting allow to false, applies at once, and so does any change on a venue whose row is already off. While the “Administration” row protects the “Venue administration” group, an owner also approves the request first. The other desk limit and approval routes are in the v2 API reference.