trading-venue.trade.retracted
A trade was undone by an approved trade bust and the reversal landed on chain: the venue's DeliveryUndone log with the bust reason. Its trading-venue.trade.final event no longer stands. Not emitted when a bust is only queued.
Delivery contract
| Field | Value |
|---|---|
| Event type | trading-venue.trade.retracted |
| Version | 1 |
| Lifecycle state | final |
| Counter-signed receipts | No event-specific advice |
| SDK type | Webhook.TradingVenueTradeRetractedV1 |
The receipt recommendation does not change delivery behavior. DALP waits for a counter-signed receipt only if the webhook endpoint's counterSignedReceipts value is true when DALP queues the delivery. When the value is false, a normal 2xx response completes the delivery.
Related references:
idxr_trading_venue
Handle the retraction
Verify the delivery before processing it. When supersedes names an event you stored, use it to find the earlier event. It is absent when this endpoint was never sent that event, and it can name an event you never stored when that delivery did not succeed; then match the retraction by the payload identifiers instead. Mark that event as retracted, then reconcile or reverse the downstream changes it created. Deduplicate by evt_id so retries do not repeat this work.
If the retraction arrives first, retain it and prevent the earlier event from taking effect if it arrives later. Keep both events in your audit record. A retraction does not request a new ledger transaction.
See webhook idempotency and on-chain outcome for retry, replay, and lifecycle handling.
Payload schema
The schema and examples describe the full payload. Thin delivery omits personal data fields. Use the payload-shape guidance to choose the endpoint configuration.
{
"type": "object",
"properties": {
"venueAddress": {
"type": "string",
"minLength": 42,
"maxLength": 42,
"pattern": "^0x[a-fA-F0-9]{40}$",
"description": "A valid Ethereum address (42 characters, starting with 0x)",
"examples": ["0x71C7656EC7ab88b098defB751B7401B5f6d8976F"]
},
"marketId": {
"type": "string",
"pattern": "^0x[0-9a-f]{64}$"
},
"venueTradeId": {
"type": "string",
"pattern": "^0x[0-9a-f]{64}$"
},
"chainId": {
"type": "integer",
"exclusiveMinimum": 0
},
"transactionHash": {
"type": "string",
"pattern": "^0x[a-fA-F0-9]{64}$"
},
"blockNumber": {
"type": "integer"
},
"logIndex": {
"type": "integer"
},
"reason": {
"type": "string",
"enum": ["bust"]
}
},
"required": [
"venueAddress",
"marketId",
"venueTradeId",
"chainId",
"transactionHash",
"blockNumber",
"logIndex",
"reason"
],
"additionalProperties": true
}TypeScript SDK example
Use the request's raw body and headers with your endpoint's webhook secret. This handler illustrates verification and event selection. Before writing downstream state, deduplicate deliveries by evt_id and recognize replayed outcomes by their domain identifiers.
const result = await verifyWebhook({
rawBody,
headers,
secret: process.env.DALP_WEBHOOK_SECRET!,
});
if (!result.ok) {
throw new Error(`Webhook verification failed: ${result.code}`);
}
if (result.event.type === "trading-venue.trade.retracted") {
const event: Webhook.Event<"trading-venue.trade.retracted"> = result.event;
console.log(event.payload);
}HTTP delivery example
This illustrative request shows the delivery shape. Its timestamp and signature are placeholders; a verifier rejects them. Use a signed platform delivery to verify your endpoint.
curl -X POST https://consumer.example.com/dalp/webhooks \
-H "content-type: application/json" \
-H "webhook-id: evt_c8840dc43f96bb6438749e84f291fb8c" \
-H "webhook-timestamp: 1778112000" \
-H "webhook-signature: v1,docs-example-signature" \
--data '{"evt_id":"evt_c8840dc43f96bb6438749e84f291fb8c","source_id":"example:trading-venue.trade.retracted@1:0","lifecycle_state":"final","payload":{"venueAddress":"0x9999999999999999999999999999999999999999","marketId":"0x1111111111111111111111111111111111111111111111111111111111111111","venueTradeId":"0x2222222222222222222222222222222222222222222222222222222222222222","chainId":537001,"transactionHash":"0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa","blockNumber":1204311,"logIndex":3,"reason":"bust"},"related":{"idxr_trading_venue":"idxr_trading_venue_example"},"type":"trading-venue.trade.retracted","version":1,"request":{"idempotency_key":"idem_01JZP7R5W8M9N0P1Q2R3S4T5"}}'Version and manifest
This page documents version 1 of trading-venue.trade.retracted. This event type is not deprecated. The DALP events manifest contains the machine-readable AsyncAPI entry.
trading-venue.trade.final
A trade's delivery completed on chain: the venue's Delivered log, emitted when the holding period is over and the legs have moved. A trade is final only then, never when its settlement transaction is merely queued. Carries the log's coordinate; read the trade through the venue API.
xvp.approval-revoked.final
A settlement participant withdrew its approval, and any escrow it had locked is returned through xvp.assets-refunded.final or parked through xvp.refund-deferred.final; carries the approval tally after the change; sent once the chain finality watermark reaches its source block, and only to endpoints on the System that owns the settlement's factory.