LITUSDT fundingRate archives contain post-delisting rows; REST omits old-contract history after ticker reuse

## Summary

Could you clarify how to interpret the old Litentry LITUSDT funding-rate archives and retrieve that contract's REST history after the ticker was reused for Lighter?

The 2025-01 through 2025-06 monthly fundingRate ZIPs contain **417 rows after the announced removal of the old contract**, all with a funding rate of `0.0001`. The relevant REST queries return no old-contract rows. I have not assumed that an empty REST response proves there were no funding events.

## Official contract timeline

- Binance announced automatic settlement/removal of the **Litentry** LITUSDT perpetual at **2025-01-31 09:00 UTC**: [official announcement](https://www.binance.com/en/square/post/19274348315658).
- Binance later announced a **Lighter Protocol** LITUSDT pre-market perpetual starting **2025-12-23 17:30 UTC**: [official announcement](https://www.binance.com/en-NZ/support/announcement/detail/6a33be00231c4539b3a4a625538e4d1e).

These are different underlying assets sharing the same symbol.

## Archive observations and integrity verification

Archive URL pattern:

```text
https://data.binance.vision/data/futures/um/monthly/fundingRate/LITUSDT/LITUSDT-fundingRate-2025-MM.zip
```

The first post-removal row is **2025-01-31 16:00:00 UTC** and the last is **2025-06-19 08:00:00.003 UTC**. Counts below refer only to rows after the old contract's announced removal and before the new contract's launch.

On **2026-09-07 03:06 UTC**, all six current official `.zip.CHECKSUM` endpoints returned HTTP 200, and their declared ZIP digests matched the actual downloaded ZIP bytes:

| Month | Post-removal rows | ZIP SHA-256 |
|---|---:|---|
| 2025-01 | 1 | `123947019f2f158cbec1578270b28654d82660bf0f4740958bb95bcc5286369a` |
| 2025-02 | 84 | `70428539456e476461fbe1993e4f9e5345008bebcbb12498c18f0b18a34ce2bf` |
| 2025-03 | 93 | `a11e684080dd5fe3cd69f315c40d4420bd510dd942896e5ebd4395441ea78138` |
| 2025-04 | 90 | `a1ab0ff7f1ebb3ba345a05e32c2b6b3a3caaf377ae8f109434fe42d74049c28a` |
| 2025-05 | 93 | `f4a834b5b308cc06d7306ec6a4fdd7eed1dc93ea8fbeb013e27792594f0590e7` |
| 2025-06 | 56 | `d5f6247ee879703a02e08afe0aa1f30bf3c0f8208537479631ace442c4612f80` |

All 417 rates are `0.0001`. This may be consistent with continued placeholder generation, but I have not found an authoritative rule confirming that interpretation.

## Minimal REST reproduction

Observed on **2026-09-07 around 02:49 UTC**, using the public endpoint without an API key. Time bounds are inclusive Unix milliseconds. Requests were spaced at least three seconds apart.

1. Old-contract window immediately before the announced settlement:

```sh
curl -sS 'https://fapi.binance.com/fapi/v1/fundingRate?symbol=LITUSDT&startTime=1738281600000&endTime=1738310400000&limit=1000'
```

Observed response: `[]`.

2. A 120-second window centered on the last old-era archive row:

```sh
curl -sS 'https://fapi.binance.com/fapi/v1/fundingRate?symbol=LITUSDT&startTime=1750319940003&endTime=1750320060003&limit=1000'
```

Observed response: `[]`.

3. From that archived timestamp through the first new-contract funding timestamp:

```sh
curl -sS 'https://fapi.binance.com/fapi/v1/fundingRate?symbol=LITUSDT&startTime=1750320000003&endTime=1766520000005&limit=1000'
```

Observed response:

```json
[{"symbol":"LITUSDT","fundingTime":1766520000005,"fundingRate":"0.00005000","markPrice":"3.65645000","rateType":"Regular"}]
```

Only the newer anchor is returned; the older archived anchor is absent, including in the narrow query above.

## Questions

1. Do the 417 post-removal archive rows represent actual settlements, placeholders, or an archive-generation issue?
2. If they are placeholders, is there an official field or documented lifecycle rule that distinguishes them from actual funding events?
3. How can the old Litentry contract's funding history be queried after LITUSDT ticker reuse? Is there an immutable contract identifier or an official historical endpoint?
4. If these archives require correction, are replacement files/checksums or a correction notice available?

Thank you. A documented interpretation or reproducible official retrieval method would help avoid conflating the two contracts or treating missing REST history as proof of no events.

Start with the six LITUSDT fundingRate ZIPs and CHECKSUM files listed in the issue, verify the post-removal rows, then reproduce the three fapi.binance.com fundingRate queries. Done means documenting whether the 417 rows are valid events or placeholders, identifying any official lifecycle or immutable contract identifier, and noting whether corrected archives or checksums exist.

Written by the indexing model from the issue text.