Summary

  • ARIN's transfer row for 158.51.155.0/24 says Crossroads Broadband of Indiana, Inc sent 256 IPv4 addresses to Tekion at 2026-10-30T21:54:17Z. The exact current RDAP object's registration event is the same instant, written as 17:54:17 Eastern daylight time.
  • That row is absent from ARIN's cumulative snapshot dated 2 November at 04:59:13 UTC, more than 55 hours after the event. It is present in the 3 November snapshot at the same clock time, more than 79 hours after. The public transfer-file appearance falls between those snapshots; the present RDAP timestamp alone cannot date its first public visibility.

ARIN's transfer ledger has a peculiar sense of the present. Ask its 2 November cumulative file whether a particular /24 changed hands and the answer is silence. Open the next day's file and a receipt appears, stamped three days earlier. The addresses did not multiply overnight. One dated publication learned about an already dated event later than another of ARIN's records says it occurred.

The object is modest: 158.51.155.0–158.51.155.255, a single /24 of 256 IPv4 addresses. In the 3 November transfer original, ARIN lists a RESOURCE_TRANSFER from Crossroads Broadband of Indiana, Inc to Tekion. Both country codes are US, both RIR fields are ARIN, and the original and transferred ranges are identical. The source registration date in that row is 10 January 2020. The transfer time is 2026-10-30T21:54:17Z, a Friday.

The 2 November dated original is the revealing control. Its filename marks 04:59:13 UTC, two days, seven hours, four minutes and 56 seconds after the transfer timestamp. Its 46,031 transfer rows contain no Tekion recipient and no transfer set for 158.051.155.000–158.051.155.255, the zero-padded form ARIN uses in the later file. The 3 November original has 46,050 rows and the Tekion line. That later snapshot is three days, seven hours, four minutes and 56 seconds after the event. ARIN's format explanation describes these dated files as snapshots of the cumulative transfer log. The comparison establishes a publication interval, not the internal reason for it.

Now query ARIN's exact RDAP object. It spans precisely those 256 addresses and names TEKIO, handle NET-158-51-155-0-1, as an active direct allocation with Tekion as registrant. Its registration event is 2026-10-30T17:54:17-04:00. Convert the offset and it is exactly 2026-10-30T21:54:17Z, the transfer time in the Tuesday receipt. The RDAP object's last changed event is 2026-11-02T16:53:30-05:00, or 21:53:30 UTC on Monday. Eastern daylight time had turned to standard time between the two events; reading only the wall-clock hours would corrupt the sequence.

The registrant entity has its own clock. ARIN's current exact response shows the TEKIO entity registered on 13 October 2026 and last changed on 21 October, before the /24 transfer. That is consistent with a receiving organization already present in the register. It says nothing by itself about when the address object was first served to public RDAP clients. A current registration event records a date in the object; it is not an archived screenshot of what a caller would have seen on Friday.

This distinction matters because a missing line looks temptingly final. A buyer reconciling a portfolio on Monday could have taken the cumulative JSON as a complete list through that morning. For this /24 it was not. An operator checking present registration would find a specific Tekion object today, but today's answer cannot recreate Monday's live RDAP response. A versioned file tells what ARIN published at that snapshot; an exact current object tells what its database now reports about the resource. Neither should impersonate the other.

An archived RDAP response or ARIN publication-job log would establish when the IP object first became publicly visible and why the transfer line entered the cumulative file between the two snapshots. The demonstrated problem is narrower and sharper: 55 hours after ARIN's own recorded event, the dated cumulative export still had no receipt. The next day it did. A registry that supplies both exact clocks and retrospective ledgers should make their different update rhythms easy to see. Otherwise the reader gets a beautifully timestamped absence and must discover later that it was temporary.

ARIN originals