Buying a block from a company the record does not name: what a public report can corroborate and what only the registry settles

The record was never going to name your counterparty

Start by defusing the alarm you arrived with. A registry record names the registered holder of a block. It does not name the party selling it, and it was never built to. An agent can sign for a holder, a parent can hold space its subsidiary uses, a company can be renamed without anybody updating an object and a record can simply have gone unmaintained for years, which is the reason stale registration exists as a label in the first place. An upstream's provisioning desk meets the same gap and handles it the same way, which is why a letter of authorization exists at all: it is the document that bridges a contracting entity and a registry record that do not match. So the first reading of a name that does not match is not suspicion. It is arithmetic: you now have two names and a distance between them, and the whole of this post is how to measure that distance from public records before it costs anybody anything.

Four reads are free and public, and they run cheapest first. Which registry object the offer is actually describing. Whose name the Organisation row carries, and the days it carries something that is not a name at all. Who else the record already names in a contact role, which is the one place your counterparty can appear without being the holder. And whether the seller's own network has ever carried the space, which is the only read here that shows use rather than paperwork. They end in four branches, and the last is stop, so nobody is waiting for a reassurance that does not come. A field with nothing in it reads n/a, and the docs say that is no data rather than a finding.

Two things this post deliberately does not do, because two published posts already own them. It does not walk the block's own history, which the checks, in order sets out cheapest and most disqualifying first. And it does not re-argue the dates, because why the dates mislead already establishes that a registry timestamp records when an object was last written rather than when control moved. The paper trail a transfer leaves is the shape of the whole event; this post is the one question that has to be settled before any of it is worth reading, because every other check assumes you know who you are buying from.

Which registry object the offer is actually describing

Type the exact prefix from the offer sheet, and read the heading before you read a single row. When the registry holds one registered block and it is not the block you typed, the panel is headed Registration followed by that block as a link. That is the first tell, and it is a large one: the offer is describing a slice of a larger registry object, and whether the holder of that object has to be in the deal is a question about the status on that object rather than one this read can answer. Confirmed on a live lookup on 16 September 2026, a /24 typed into the box returned a registration resolving to the enclosing /21, with the typed block appearing nowhere as an object of its own. Where the allocation covers several blocks the heading stays plain and a Registered blocks row lists them instead, and the same question then has to be asked of every block on the offer rather than once for the lot.

Two things beneath the heading finish the read. The collapsed Enclosing blocks table prints Block, Name, Type and Country for each larger block containing this one, which the docs call the parent blocks. And the finding Part of something bigger, in the findings under the overview, names the enclosing range, its address count and the registry's own name for it before you reach the Registration panel at all. Read the Registration panel's Type row in the same pass and hand its vocabulary straight to what a status lets the holder do, which already rules which statuses can change hands on their own and which belong to a service agreement instead. The counterweight sits here too: a parent object is also simply how a registry files an allocation, so an enclosing block is not evidence that your seller is somebody's tenant. It is evidence that the object on the offer and the object in the registry are not the same object, which is a different and more useful fact.

The Organisation row, and the days it is not a name

The Organisation row prints what the registry publishes and nothing more, which the docs put as country and organisation, as registered. On live lookups on 16 September 2026 that row came back three different ways. As a company name carrying a legal suffix, which is a string you can hold against the name on an offer sheet. As a registry organisation handle, an identifier rather than a name. And as a maintainer handle, which is an identifier for the credentials that authorise changes to an object and not a party at all. Only the first of the three is a name, so the test you came to run is sometimes simply not available, and knowing which of the three you are looking at is most of the skill. One more thing the row can be: where the registry publishes no organisation against the holder itself, the value falls back to the first organisation the record carries anywhere, or to the registry's own free-text description of the block, so a name matching there and matching again in a contact role can be one field read twice rather than two records agreeing.

Where the row carries a handle, the next move is to resolve that handle at the registry rather than to treat it as a mismatch. Each registry publishes the lookup. The RIPE Database resolves an object through a path shaped source, object type and primary key, and an organisation object carries the company name in its own org-name attribute; an organisation handle there begins with ORG- and ends with the database source, and only one of the registry's organisation types can be created by a user at all, the rest being set by the registry itself. ARIN resolves an Org handle through its Whois RESTful service at a path ending in the handle, and describes an Org ID as defined by a legal name, a postal address and points of contact. Lookups of an organisation handle made on 16 September 2026, with no credentials sent, came back with the name recorded against that handle at both registries. That is the registry repeating its own record, not anybody confirming that the organisation exists or still holds anything.

Two limits belong in the same breath as the read. The site prints no history of the Organisation row as such; what it holds is a change event from the day a lookup noticed a record move, and that begins when the site first saw the block rather than when the registry wrote it, so the chain of custody stays yours to assemble from registry papers and corporate records, as reading your own report like a skeptical buyer already says from the seller's chair. And a handle is not always what it looks like: one legal entity may hold more than one identifier at a registry, so two different handles are not evidence of two different companies, and a maintainer's free-text description is text somebody chose rather than anything the registry attests. What a record can and cannot prove is the general form of that caution, and it applies here at full strength.

Who else the record already names

The Registry contacts table is the cheapest thing on the page that can put your counterparty inside the record, and it is the part buyers skip. It is collapsed, and it prints Role, Name, Organisation and Email for every contact the registry publishes with a name, an organisation or an address behind it, which the docs describe as every published contact and its role. Confirmed live on 16 September 2026, one European block returned contacts across the registrant, administrative, technical and abuse roles, and one North American record returned a registrant party whose name differs from the Organisation row on the same record only by its legal suffix. That shape is what this post is about: two names, one legal suffix apart, on one record read on one day. It tells you the two strings are close. It does not tell you they are one company, and nothing on the page can.

A company named in a technical or an administrative role that is not the company on the Organisation row is the shape of a parent, an acquirer or an appointed administrator, and finding your counterparty there is the strongest free corroboration this page offers. Three counterweights belong in the same paragraph rather than a later one. Registry contacts are self-reported, and the published vocabulary of roles describes a function rather than an authority: no registry publishes a role that says its holder may sell. The table shows the names of individuals, which are there to be read on the record and not to be collected into a file about anybody. And a contact is a route to a question, not an answer to one, which what a record proves already settles in the other direction: a record tells you which operator to ask, never who is using an address today. What a role mismatch actually gives you is a question to put to the seller in writing, namely how the named holder and the named party are related, and that question is either answered with a document from the named holder, backed by that holder appearing in the registry's own transfer process or by the acquisition evidence the registry accepts in its place, or it is the fourth branch. A paper answer the seller supplies is not the answer on its own: falsified letters of authority are the documented shape of this fraud, and only the registry's own process settles the relationship.

Whether the seller's own network has ever carried the space

The other three reads are paperwork. This one is use. Origin history prints one row per announcing network and the prefix it announced, so a network that deaggregates appears more than once, with Network stacking the AS number over its holder, then Prefix, then When as first seen to current or to a last seen date, and it keeps covering routes from larger blocks in a collapsed section of their own, described on the page as transit rather than control. Where nothing inside the block has been announced at all the panel says so in words, that no announcement of this exact prefix is recorded. Confirmed on a live lookup on 16 September 2026, a /24 returned exactly that line with covering routes beneath it: a block whose reachability comes entirely from somebody else's aggregate, and which therefore has no announcement of its own to show you.

Four findings decide whether the space is somebody else's operation today rather than the seller's. Space is sub-let names the companies the feeds report using sampled addresses when they are not the network that runs them. Announced by someone else carries the site's own sentence that this is how leased or sub-allocated space looks. The route changed hands counts the distinct networks that have announced the block. And It changed hands recently is a different count, of how many times the announcing network changed in the last twelve months. None of them is a verdict on your seller, and the counterweight belongs in the same paragraph: origin history is what collector peers saw and never what anybody authorised, which what the data cannot tell you states as the rule that holds everywhere, and legitimate transfers, upstream changes and acquisitions all change an origin, which a parade of origins reads pattern by pattern. A block nobody has announced for years has no use to read at all, and dormant space cuts both ways is what that silence is worth.

What the registries test, and where the transfer history lives

Now the part that decides the shape of the whole deal, and it is worth reading in the registries' own words. The three registries whose policy text this post reads all test the source on standing to release rather than on the bargain, with the conditions and the calendar locks set out from the seller's side in confirm you can sell it at all. ARIN's Number Resource Policy Manual, version 2025.1 dated 3 March 2026, opens its transfer section by making number resources nontransferable unless ARIN has expressly and in writing approved a request for transfer, and its conditions on the source are that the source is the current registered holder and is not involved in any dispute as to the status of those resources. Section 8.5 is headed Specified Transfer Recipient Requirements and is written against the party receiving. APNIC's policy text, APNIC-127 version 015 dated 20 February 2025, uses almost the same two-part wording for its source, and says outright that for historical resource transfers it does not review the agreements between the parties. The RIPE NCC's transfer policy uses a different formula, the legitimate resource holder wording the status decoder already sets against the dependent statuses, and its due diligence document, on the agreement that establishes the relationship in the first place, describes the check as verifying that the contractual parties exist and are valid and that they are properly represented in the signing of the agreement.

Two consequences follow for the person holding an offer sheet, and they differ by registry. At ARIN the standing is attested rather than independently established: its transfers page requires the source to provide the signed and notarised officer letter the seller has to line somebody up for, whose published blank form has the source's own officer attest that the organisation is the authorised registrant and holder of the rights, is not involved in any dispute and is not aware of any fact or circumstance that would let another party claim the resources. That is an attestation signed by an officer of the seller and notarised, which is a real thing for the registry to hold, though a copy handed to a buyer is not evidence that the registry ever received it or accepted it: a notary attests the signature and not the assertions above it, and ARIN will not confirm to you that any ticket exists. At the RIPE NCC the same document goes further for a transfer: both parties must sign the RIPE NCC's Transfer Agreement template, the transferring party's signatory must have the capacity to act for that organisation, and the RIPE NCC says it may require official documentation, or notarisation where official sources do not carry it, that the signatory is authorised to sign. Its wider due diligence goes to the existence of the contracting parties and to their representation in signing. Neither is a check you can run or see, which is the second consequence: ARIN states that it cannot provide information on ticketed requests from other organisations, and the RIPE NCC states that it will not report audit findings to a party who reported a concern unless that party is proven to have a valid claim on the resources. Neither publishes a way for one side of a transfer to learn what the registry concluded about the other, and ARIN places the commercial terms outside its remit, saying the negotiation between two parties is a matter for resolution between those parties. What the pre-checks step calls verification is, in the paperwork, an attestation on one side and a check of existence and representation on the other.

Which leaves the transfer history, and a report carries the part a registry dates rather than the whole of it. Registry events land on the timeline beside the routing windows, with the space moving between registries shown as RIR holding rows, and the registration record's first registration, allocation and last record change are dates about an object rather than about a deal. What no report reconciles is any of that against the registries' own complete logs, and those are published: ARIN at ftp.arin.net/pub/stats/arin/transfers/, the RIPE NCC at ftp.ripe.net/pub/stats/ripencc/transfers/ and APNIC at ftp.apnic.net/pub/stats/apnic/transfers/, each read on 16 September 2026. Go there rather than inferring a transfer from a registration date, and read APNIC's own caution inside its file, that the log captures what was true at the moment of the transfer and is not meant to carry everything about it. Custody is four dates carries the weaknesses of those files, including which of their fields are optional and why the delegated statistics files are not a substitute, so this post does not restate them.

The four branches, and the one that is not yours to decide

Before the table, the vocabulary that would move a branch. The ownership labels in the tag vocabulary are Shell ASN, Fabricated registration, Hijacked space, Revived dormant space, Frequent origin change and Address leasing, with Unreachable abuse contact and Stale registration beside them in the quality group. Only Fabricated registration and Hijacked space move a branch in the table below. Revived dormant space moves none of them and still deserves a slower read, because dormant space attracts hijackers precisely for the reason it is quiet, so a block can carry announcements its registered holder never authorised. A confirmed tag carries a confidence and sits in the confirmed row under a label naming whether analysts, the site's own active checks or both put it there; a machine proposal sits in its own row headed as suggested by automated sampling and not yet confirmed. A confirmed ownership label is a judgement with evidence behind it rather than a score, and the absence of one is nothing at all: no tag is not innocence, on this page or in your diligence.

Four notes on the table. The first row is the one buyers hope for, and it is the row that proves least: a matching Organisation row is a record agreeing with a document, which is not standing, and the thing that tests standing happens inside the registry where neither of you will see it. The second row is the one people panic about, and it is not an accusation: it is a request for a document that exists if the relationship does. The third row is the one people misread as the fourth, and a handle resolves at the registry in one lookup. And the fourth means what it says: you are handing the registry a question rather than a conclusion, and you will not be told the answer. ARIN's fraud reporting process lists submitting false documentation and information in order to obtain resources among the categories it accepts reports about, and says it may reclaim resources that were issued or transferred on the strength of fraudulent data, which places that cure after closing rather than before it. That pattern has been adjudicated, and the adjudicated case is where it is set out in full; read it for what a registry can and cannot unwind rather than as a template for what is on your screen, because nothing a public record shows you is evidence of it. The part a buyer needs from it is ARIN's own account of the matter, read on 16 September 2026, which records in a footnote that it chose not to interfere with resources that had already reached good-faith purchasers outside its region. A block that has moved on can carry a history nobody is going to unwind for you.

What a report can do here it does honestly: it names the registered holder and the parties on the record, it shows the enclosing object the offer is really describing and it shows whether anybody has ever announced the space. What it cannot do, stated in the same breath. It never puts a seller's name on a block, and it keeps no history of the Organisation row reaching back before the site first saw the block. It does not verify that a company exists, that anybody may sign for it or that a relationship between two names is real. It holds no reverse DNS and no PTR record anywhere. Nothing it prints is a check anybody ran on a person: registry material is passthrough, and the one thing the site verifies for itself is address behaviour. And it notifies nobody: changes are archived when something is looked up again, never pushed to you, so a record that changes after you read it changes silently. Whatever testing happens, happens inside the registry rather than on any public page, and a report that reads public records narrows the question honestly without ever answering it. None of this is advice about your transaction: it is a reading of public records, and the documents, the terms and the decision are yours and your advisers'. The site's own terms say the rest in its own voice: sources disagree, lag and make mistakes, confidence scores are estimates and not verdicts, everything is provided as is, so verify independently before you block, buy, accuse or decide. Before you sign is the block's side of that work, what the letter is, and is not is why a document naming a prefix proves less than it looks, and contacts, assignments and the registry's own rules is what waits on the far side of closing. Vetting an IPv4 lessee is the same counterparty question asked from the other side of a lease, where the last branch here, the one that hands the matter to a registry, does not exist.