Balance Operations

Balance Operations is the operator-facing audit view for wallet adapter mutations.

Dashboard path

Operator Dashboard → Operations → Balance Ops

Required scope: balance_operations:read

What operators can do

• filter by an inclusive UTC date range, defaulting to the first and last UTC day of the current month
• filter by external user ID
• filter by market slug or market ID
• filter by status, direction, and operation type
• inspect Opinion operations; this page does not currently expose a product selector and uses the API's Opinion default
• stage filter edits before explicitly applying them; Reset restores the current UTC month
• include manual_review in status filtering
• distinguish trade and resolution operations using the current Type selector
• inspect amount, currency, and balance-after evidence when returned by the wallet adapter
• export all filtered rows as CSV
• copy the current page as an HTML or plain-text table
• keep rows, filtered metrics, pagination, route state, and all-filtered CSV exports on the same applied filter snapshot

Filtered metrics

Three cards summarize every row matching the applied filters, not only the current page:

• Credits Amount: credit + debit_reversal
• Debits Amount: debit + credit_reversal
• Balance Ops Volume: Credits Amount + Debits Amount

Amounts include every matching status. The current dashboard page requests Opinion by default, so Polyflight money is not silently mixed in. Apply a status filter when a succeeded-only or review-only report is needed: the unfiltered volume is activity, not confirmed cash. Cards use the authenticated operator's configured currency code.

Operation type

Operation type is derived from the source record:

• trade: operation has order_id
• resolution: operation has redemption_item_id
• unknown: no recognized source link exists

The API also recognizes polyflight_purchase and polyflight_ticket from their source links when a Polyflight product scope is explicitly requested. These are not options in the current generic dashboard Type selector; use the dedicated Polyflight page.

Market filter

The dashboard uses the compact market query parameter. It accepts either numeric market ID or market slug.

Examples:

/balance-operations?market=fifa-final-2026
/balance-operations?market=123
/balance-operations?type=resolution&market=fifa-final-2026

Balance after

balance_after_minor is nullable. It is populated only when the wallet mutation response includes balanceMinor or balance_minor.

Old records may not have balance-after evidence. Do not infer zero from a blank value.

Source API

The page reads GET /api/operator/balance-operations.

Use this page when reconciling money movement. Use Trades or Resolutions for business-level reporting.

For focused Polyflight request/response evidence, use /polyflight/balance-operations, which requires both polyflight:read and balance_operations:read and exposes immutable source linkage/state version without permitting operator-side resolution.

Market PnL warnings and cash-flow triage

Market PnL warning banners and row badges link to Operations → Cash Flow Triage (/market-pnl-issues). The link preserves the applied market, user, search, and resolution-date filters. Triage has no default creation-date cutoff, so an older unresolved payment does not disappear behind a current-month filter.

Triage requires all three scopes: trades:read, redemptions:read, and balance_operations:read (or *). Expand a source record, then expand an operation's Recorded request / response logs or Resolution audit history. Evidence is redacted and bounded; it is not a live Cloudflare log stream. A stored retry timestamp does not prove that a manual-review source is being retried.

Recorded request/response logs use a bounded field allowlist. Headers, raw/unstructured bodies, transport URLs and unknown adapter fields are withheld; strings can be truncated or credential-scrubbed. This is safe inspection evidence, not byte-exact signed transport data, and an omitted field does not prove it was never sent. Protect exports and copied tables as sensitive customer/financial records.

Operator triage is read-only. Open Polynion Admin to resolve opens the exact operator/source record in the environment-matched Admin app and requires a separate authorized Admin session. Financial decisions require mini_app:write, an operator-ledger evidence reference, a reason, and confirmation of the immutable operation context.

• Completed / confirmed applied records an externally confirmed wallet effect; it does not send another payment.
• Failed / confirmed not applied records a terminal failed wallet outcome. If a payout remains owed, it stays explicitly visible as failed/unpaid; failure is not a write-off.
• Active/in-flight, stale, contradictory, or unsupported source states cannot be forced through a terminal action. Source-level blockers without a wallet operation remain inspectable and require financial follow-up.

Never use these decisions merely to dismiss a warning. Reconcile the original idempotency key, recipient, amount, and currency against the operator ledger. No action creates a replacement key or recomputes historical FX.