Summary

  • ARIN records three Krypt transfers of 20,480 unique addresses from one repeatedly listed /17 original set; adding the three original-set fields would produce a false 98,304.
  • Five exact current ARIN RDAP intervals show North Central, TensorWave and Fatbeam on three pieces, while Krypt retains two pieces totalling 12,288 addresses.

Three lines in ARIN's transfer file can make one /17 look as though it moved three times. Each line repeats 173.214.0.0–173.214.127.255 as the original_set for Krypt Technologies. The field that records what actually left is transfer_set. Read that field, and the giant block resolves into three outgoing pieces, two gaps that stayed, and five current RDAP holders' intervals. The arithmetic changes from a bogus 98,304 repeated addresses to 20,480 transferred addresses.

The first cut came on 16 October 2026. Krypt sent 173.214.0.0–173.214.31.255, a /19 containing 8,192 addresses, to NORTH CENTRAL TELEPHONE COOPERATIVE CORPORATION. On 29 October it sent 173.214.96.0–173.214.111.255, a /20 of 4,096 addresses, to Fatbeam, LLC. On 2 November, 173.214.32.0–173.214.63.255, another /19 with 8,192 addresses, went to TensorWave Inc. Three dates, three recipients, and no overlap between the transferred intervals.

The shared original_set is a label for the larger source range in each row. Summing it three times would say 32,768 times three, or 98,304 addresses. Yet the transfer_set intervals sum to 20,480. More than a third of the original /17, 12,288 addresses, is absent from those transferred sets. It occupies two exact gaps: 173.214.64.0–173.214.95.255, a /19, and 173.214.112.0–173.214.127.255, a /20. These are not empty number slots. They are untransferred pieces with a current registered holder.

Five exact ARIN RDAP lookups close the puzzle. The first /19 names North Central. The next /19 names TensorWave. The middle /19, .64–.95, still names Krypt. The later /20, .96–.111, names Fatbeam. The final /20, .112–.127, again names Krypt. Together the five disjoint intervals tile the full 32,768-address /17 with no gap in the address space and no address counted twice. The transfer history has gaps in ownership change, not gaps in numbering.

A query for the broad /17 itself resolves to an ARIN parent object wider than the Krypt source range; it is the five exact child objects that establish today's holder pattern. That distinction matters because the transfer export is historical while RDAP reports current registration. A user who checks only the source range can lose the three recipients. A user who checks only a transferred /19 can lose the two Krypt remnants. Both errors start with choosing the convenient boundary instead of the actual one.

The newest recipient, TensorWave, may tempt a story about data-centre capacity. ARIN's transfer record supplies no price, deal term or deployment plan. It supplies something more exact: a dated 8,192-address /19, its source /17 context and a current matching RDAP object. The three recipients have different industry identities, but the file is about number resources, not their business forecasts. The stakes for an address buyer or auditor are immediate: a repeated original_set can create a false 98,304-address count, and a recipient list can hide the two ranges the source still controls.

ARIN's common JSON format publishes enough fields to avoid that trap. It does not perform the reader's arithmetic. The little word “original” is the bait. The smaller transfer_set objects are the receipts. Read the five current pieces against the three dated cuts, and the /17 stops looking like one vanished asset. It looks like a ledger with three exits and two ranges still registered to Krypt.

ARIN originals