Rollback

Rollback path depends on failure type.

Configuration rollback

Use when problem came from:

• wrong webhook secret
• wrong API key deployment
• wrong market visibility mode
• wrong wallet adapter config

Flow:

1. stop new risky traffic if needed
2. restore last known-good config
3. confirm configuration/authentication under the authorized release procedure, preferring read-only checks over money probes
4. review selected targets and queue bounded callback recovery only after fixing the receiver; keep event deduplication active

For Polyflight, configuration rollback means disabling new operator entry. Continue payouts, refunds, compensation, reconciliation, webhooks, and report reads for existing obligations.

Application rollback

Use when operator-side code broke signature verification, raw-body handling, wallet adapter responses, or idempotency/ambiguous-response handling.

For Opinion-only traffic, use a compatible stable version that preserves the original wallet identities, frozen execution evidence, cash-outcome history, and settlement safeguards. Coordinate any functional checks separately; do not use live money movement as a rollback probe.

For Polyflight, never deploy a version that cannot read and process polyflight-v5, native tickets, wallet obligations, or native statements while any such records exist. Use the last v5-capable build or forward-fix. Reverting future generation policy does not rewrite existing flights. Where operator-underwritten private markets exist, do not roll back to consumers that ignore permanent ownership. Discovery, direct access, execution, redemption, and settlement must retain the boundary; changing visibility rules or withdrawing a request cannot transfer principal risk back to Polynion. Coordinate a compatible rollback or forward-fix with Polynion.

Incident guardrails

• do not replay money-related requests blindly
• do not create new idempotency keys for the same business action during investigation
• do not rotate multiple variables at once unless compromise is confirmed
• do not drop/reverse Polyflight tables, commitments, events, obligations, or finalized statements as traffic rollback
• do not change committed valuation, snapshot, result, payout, or ticket terms
• do not delete wallet idempotency records, support/cash-resolution history, endpoint history, or event deduplication records
• do not treat webhook backfill/resend as a financial rollback or authorize a new payment from a failed callback alone

After rollback

• collect failing IDs and timestamps
• compare last good vs first bad change
• update troubleshooting docs if new failure mode discovered
• reconcile all existing Polyflight liabilities and ambiguous effects
• verify statement/export parity and preserve proof/audit evidence
• follow up the original Operator Support conversation with the deployed/configuration change and remaining debt; closing a ticket does not close liabilities