Release an EXPIRED split / merge lock after verifying on-chain absence

User-initiated recovery for an EXPIRED dual-signed operation when the backend’s automatic sweeper is disabled in observation-only mode. Releases the off-chain lock back to the caller’s balance after PG-side chain verification that the operation did NOT execute on-chain.

Supported op_kind: SPLIT and MERGE. CONVERT / REDEEM follow in subsequent releases.

Gates checked in order (any failure short-circuits with no balance movement):

1. Ownership — caller’s X-User-Wallet must resolve to the same vault_address recorded on the signed op (else 403 vault_owner_mismatch).
2. Op kind — must be SPLIT or MERGE (else 400 op_kind_unsupported).
3. Already terminal — if the op is already EXPIRED / CANCELLED / REVERTED / REJECTED / FAILED (i.e. refunded by some other path), the call is a 200 no-op with refundAppliedNow=false for idempotent client retries.
4. Age — now - deadline >= 90s (else 425 op_too_recent). The 90s safety buffer matches the auto-sweeper’s SAFETY_SEC_DEFAULT so a tx mined just after the off-chain deadline cannot be double-counted.
5. Chain-watcher liveness — exchange-service probes chain-watcher’s own /health/chain-sync endpoint and refuses the release if the indexer is lagging (else 503 chain_watcher_lagging / chain_watcher_unreachable / chain_watcher_url_unset). Without this gate, an unindexed chain-confirmed split/merge would falsely look like a no-execute and double-credit the vault.
6. Chain-row absence — LEFT JOIN against the per-kind events table (chain_watcher.vault_position_split_events for SPLIT, chain_watcher.vault_positions_merged_events for MERGE) keyed by (vault, conditionId, amount). If a matching row exists the call returns 409 op_confirmed_on_chain with the chain event_key / tx_hash / blockNumber in the error details payload so operators can re-drive the chain-event-router manually instead of unlocking duplicate funds.

On success the op transitions to EXPIRED, refunded=true, and a single balance_events row is appended with reason split_user_refund_verified (SPLIT) or merge_user_refund_verified (MERGE) — distinct from the sweeper’s *_expired_refund so audit / reconcile queries can attribute the unlock to the user-driven path.

POST /api/dual-signed-ops/{opId}/release-expired

Release an EXPIRED split / merge lock after verifying on-chain absence

cURL

curl --request POST \
  --url https://core-api.adipredictstreet.com/api/dual-signed-ops/{opId}/release-expired \
  --header 'X-Api-Key: <api-key>'

200

{
  "signedOpId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
  "status": "<string>",
  "vaultAddress": "0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb3",
  "deadline": 123,
  "refunded": true,
  "refundAppliedNow": true,
  "updatedAt": "2023-11-07T05:31:56Z",
  "reason": "<string>",
  "txHash": "<string>"
}

Authorizations

X-Api-Key · string · header · required

Partner / integrator key — format ps_live_<keyId>_<secret>. Issued by PredictStreet ops on request; never self-service. Never ship to a browser. multi_wallet partners must additionally send X-User-Wallet: 0x<40-hex> on every authenticated request to declare the acting wallet. See the API keys guide for scope taxonomy, partner kinds, rate limits, and rotation procedure.

Headers

X-User-Wallet · string

Required for multi_wallet partners on every authenticated request; ignored for single_wallet. Declares the acting end-user wallet for this request — drives KYC checks, balances/positions/orders attribution, rate-limit buckets, and audit. Lower-cased server-side. Missing on a multi_wallet key → 401 api_key_user_wallet_required; malformed → 401 api_key_user_wallet_invalid. The on-chain CTFExchange/Vault contracts still verify EIP-712 signer ↔ vault binding, so loosening API-layer attribution is safe by construction.

Pattern: ^0x[a-fA-F0-9]{40}$

Example:

"0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb3"

Path Parameters

opId · string<uuid> · required

signed_ops.id UUID returned by the original split / merge / convert signature endpoint.

Response

200

application/json

Refund applied, or no-op snapshot of an already-terminal op (use refundAppliedNow to distinguish).

signedOpId · string<uuid> · required

signed_ops.id — same UUID the original signature endpoint returned.

opKind · enum<string> · required

Operation kind. Always SPLIT or MERGE on success — other kinds short-circuit with 400 op_kind_unsupported.

Available options: SPLIT, MERGE

status · string · required

Post-call status. EXPIRED after a successful refund; whatever the row was already in (EXPIRED / CANCELLED / REVERTED / REJECTED / FAILED) on an idempotent re-request.

vaultAddress · string · required

Pattern: ^0x[a-fA-F0-9]{40}$

Example:

"0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb3"

deadline · integer · required

Unix seconds the op was signed against. Always more than 90s in the past on a successful response.

refunded · boolean · required

signed_ops.refunded after this call — true for any EXPIRED/CANCELLED/REVERTED/REJECTED/FAILED terminal.

refundAppliedNow · boolean · required

true if this call performed the refund transition; false for an idempotent re-request against an already-terminal op (the row is returned unchanged).

updatedAt · string<date-time> · required

ISO-8601 timestamp of the last signed_ops mutation.

reason · string | null

signed_ops.reason audit string — set to user:<vaultAddress> after a successful refund by this endpoint; may be sweeper / cosigner / etc. on rows refunded by other paths.

txHash · string | null

signed_ops.tx_hash. Always null on this endpoint's responses — the op never confirmed on-chain by definition.