An instrument is one tradable line on a venue. An instrument deny list bars one wallet from one instrument and leaves every other instrument of the venue open to it. It exists because the coarser tools a venue holds cannot express that case: they stop a wallet everywhere, or they decide who sees a private instrument, and neither records why one participant lost one instrument.
Where a denial fits
A venue block stops the wallet on every instrument the venue lists, which is a venue-wide consequence for a problem on one trading line. A private instrument decides access through its participant list, and a public instrument has no such list. An access-profile override narrows trading, watchlist or depth inside an instrument the wallet can already see. It cannot hide a public instrument from that wallet, and it carries no reason and no actor.
A denial is its own record: one instrument, one wallet, the reason, the user who recorded it and the time. The denial is a platform record, not an on-chain one. The platform's order intake and market data enforce it, and the wallet's admission on the venue contract does not change. There is at most one per instrument and wallet, so barring a wallet that is already barred replaces the reason and the actor instead of adding a second entry. Lifting a bar deletes the record, and lifting a wallet that is not barred succeeds without a change.
Bar a wallet
The API calls an instrument a market, so the deny list lives under the market's path. POST /api/ records the bar. The body names the wallet, the reason, which holds 1 to 500 characters after trimming, and the wallet verification:
{
"walletAddress": "0x2a9f4c7b1d8e3056af72b4c9d0e1f6a3b8c5d2e7",
"reason": "Repeated wash trades against its own resting orders in this instrument",
"walletVerification": { "verificationType": "PINCODE", "secretVerificationCode": "482913" }
}The answer is 200 with the recorded denial. The identifiers in this example are shortened:
{
"data": {
"marketId": "…",
"walletAddress": "0x2a9f4c7b1d8e3056af72b4c9d0e1f6a3b8c5d2e7",
"reason": "Repeated wash trades against its own resting orders in this instrument",
"actor": "…",
"createdAt": "2026-06-12T09:41:07.000Z"
},
"links": {
"self": "/api/v2/addons/trading-venues/0x7f3c2b5e8a1d4c6f9b0e2a5d8c1f4b7e0a3d6c9f/markets/…/denials/0x2a9f4c7b1d8e3056af72b4c9d0e1f6a3b8c5d2e7"
}
}actor is the user behind the session, which on an impersonated session is the person acting and not the user they act as. The stored wallet address is lowercase.
Only a platform administrator or the organisation owner can bar or lift a wallet. A bar and a lift apply at once, with no second approval, whatever the Trading venues row under “Approvals” says. Any other caller gets 404 TRADING_ instead of a refusal, so the answer does not reveal whether the instrument exists. A bar without the wallet verification in its body, or a lift without it in its header, is refused with 400 WALLET_ and changes nothing.
DELETE .../ lifts one bar, with the same roles. A lift has no body, so its wallet verification travels in the X-Wallet-Verification header as a JSON object, for example {"verification. GET .../ lists the bars of one instrument with offset, limit and sort. Without sort the list is newest first. sort takes createdAt or walletAddress, ascending, or descending with a leading -. A holder of the venue operator role can read the list without being a platform administrator or the organisation owner, and cannot change it. In the Console that operator still sees Bar wallet, and a bar they submit is refused as not found.
What the bar changes
Barring a wallet takes its resting orders on that instrument off the book and releases their reservations. The cancellation runs as a participant cancel-all limited to that one instrument, so it shows among the venue's cancellation batches with the operator's reason. Orders the wallet has on other instruments stay where they are. Lifting a bar restores nothing: cancelled orders stay cancelled.
The instrument then behaves for that wallet as if it were not listed. It disappears from instrument lists, from the instrument read and from market data such as the ticker, the order book and the stream, and the wallet's access on the instrument reports the denial with no trading, no watchlist and no depth. A new order is refused at intake with the rejection reason market-access-denied and the message “Your access to this instrument is disabled”. Order intake reads the instrument without the per-wallet gates and refuses a barred wallet with its own reason, so the trader learns why the order failed instead of reading an unknown instrument.
Visibility is decided per wallet. A caller that holds several wallets still sees the instrument through any wallet that is not barred, so keeping a person off an instrument means barring every wallet that person holds, including the signing address behind a smart wallet. A caller who operates the venue, or a platform administrator or organisation owner, still sees the instrument through that role.
Where an operator bars a wallet
In the Console, the Barred wallets tile on a public instrument's settings takes a “Wallet address” and a “Reason for the bar”. “Bar wallet” asks for your wallet verification. Each barred wallet is listed with its reason and a “Lift bar” button, whose verification asks whether to let the wallet, named by its address, “see and trade this instrument again”. The tile is not offered on a private instrument, where the participant list decides who trades, and it is hidden from a caller who cannot read the list.
The list belongs to one instrument, so the same wallet can be barred on one instrument while it keeps trading on the next. Venue operations covers the rest of a venue's controls, and Trading Venue covers how an instrument, its orders and its trades work.