AUDIOUSDT / GALUSDT: positive-volume minute at announced settlement time

Could you clarify the interpretation of these two USD-M perpetual kline archives?
The notices schedule automatic settlement at 09:00 UTC and removal after
settlement completes. The archives report positive volume and nonzero trade counts
in the minute beginning at 09:00. I have not assumed these are erroneous, that
they remain executable ordinary trades, or that they can safely be discarded.

| Contract | Scheduled settlement (UTC) | 09:00-minute base volume | Trades | Close | Previous minute close |
| --- | --- | ---: | ---: | ---: | ---: |
| AUDIOUSDT | 2024-05-16 09:00 | 90 | 1 | 0.1632 | 0.1630 |
| GALUSDT | 2024-07-11 09:00 | 12,531 | 133 | 2.4750 | 2.5075 |

## Official sources and retained bytes

The [AUDIO notice](https://www.binance.com/en/support/announcement/detail/cb525a5fbb954935afc77630fc5bd0cc)
specifies May 16 for AUDIOUSDT; its May 15 date applies to other contracts.
The [GAL notice](https://www.binance.com/en/support/announcement/detail/27449abd481b473493b9c058350b4e2e)
specifies July 11 for the perpetual, distinct from its spot/margin dates.

- [AUDIO minute archive](https://data.binance.vision/data/futures/um/daily/klines/AUDIOUSDT/1m/AUDIOUSDT-1m-2024-05-16.zip), [provider checksum](https://data.binance.vision/data/futures/um/daily/klines/AUDIOUSDT/1m/AUDIOUSDT-1m-2024-05-16.zip.CHECKSUM).
Retained ZIP SHA-256: `ee00e7dc93dfd5ccb146829aa90068ea3a64425bd51b021f814f732face5a12d`.
- [GAL minute archive](https://data.binance.vision/data/futures/um/daily/klines/GALUSDT/1m/GALUSDT-1m-2024-07-11.zip), [provider checksum](https://data.binance.vision/data/futures/um/daily/klines/GALUSDT/1m/GALUSDT-1m-2024-07-11.zip.CHECKSUM).
Retained ZIP SHA-256: `8be6e71599cec411457255d7b0c583d06b9d858e237cf43377c835b81cb402ec`.

These files and provider checksums were acquired on September 6, 2026 UTC;
the retained bytes were rechecked locally. This is not a claim that the current
download URLs still serve those revisions.

## Exact CSV rows

Each block contains 08:59 and 09:00. Fields follow Binance's kline format:
open time, open/high/low/close, base volume, close time, quote volume, trade count,
taker-buy base volume, taker-buy quote volume, ignored field.
The 09:00 row covers `[09:00, 09:01)`; its raw close timestamp is 09:00:59.999.

AUDIOUSDT:

```csv
1715849940000,0.1630,0.1630,0.1630,0.1630,8556,1715849999999,1394.6280,8,0,0,0
1715850000000,0.1632,0.1632,0.1632,0.1632,90,1715850059999,14.6880,1,0,0,0
```

GALUSDT:

```csv
1720688340000,2.48000,2.55000,2.48000,2.50750,13108,1720688399999,32798.76280,223,2464,6209.63040,0
1720688400000,2.50750,2.51070,2.47500,2.47500,12531,1720688459999,31143.54320,133,496,1237.86030,0
```

## Clarification requested

1. Do these 09:00-minute prints represent ordinary executions, settlement-generated
records, or archive errors? What evidence distinguishes those cases?
2. What were the actual trading-cessation and settlement-completion times for
each contract, and where can their historical outcome/price be verified?
3. If the archives are incorrect, are corrected files and replacement checksums
available? If the rows are expected, is their interpretation documented?

The [current delisting FAQ](https://www.binance.com/en/support/faq/detail/dd60dfbf654d4055aa6b217ea6d5ddba)
describes a general settlement formula, but is updated in 2026 and does not identify
these specific prints. Its 30-second restriction window is not assumed to be a
historical settlement-delay allowance. A contract-specific clarification would
avoid either dropping valid events or assigning an unsupported stop time/price.

Start by comparing the retained AUDIOUSDT and GALUSDT ZIP archives and their provider checksums, then inspect the exact 08:59 and 09:00 kline rows against the linked settlement notices and current FAQ. Done means obtaining authoritative contract-specific trading-cessation, settlement, and outcome evidence, and determining whether Binance will document the rows or publish corrected files and checksums.

Written by the indexing model from the issue text.