Summary

  • An RIR's transfer review answers a narrow set of registration questions under the applicable regional policy. It is not a warranty of purchase price, unrestricted title, clean routing history, global reachability, email reputation, sanctions compliance, geolocation accuracy or fitness for the buyer's network.
  • Buyer diligence should be layered. Begin with the seller's legal existence and signatory authority; reconstruct the corporate and registration chain; map the exact CIDRs and transfer path; search for disputes, insolvency and legal restraints; then investigate BGP, RPKI, IRR, RDAP, reverse DNS, abuse and blocklist history.
  • Evidence must be time-aware. A current RDAP record may identify today's registrant but not explain an old merger. A present valid ROA may conceal a disruptive origin history. A clean blocklist lookup today may follow years of abusive use. Snapshots, historical routing, dated corporate records and explicit seller representations are necessary.
  • Holder authority and technical use are different facts. A seller can be registered but represented by an unauthorized employee. A block can be routed by a customer or mitigation provider without being sold. A court can restrain a registered holder. No single database should be allowed to stand in for the whole transaction.
  • The transfer path must be tested before signing. Source and recipient regions, legacy or contractual status, holding periods, recipient qualification, minimum size, inter-RIR compatibility, disputes and account readiness can determine whether the proposed transaction is registrable in the form priced by the parties.
  • Good contracts turn diligence findings into closing mechanics: conditions precedent, escrow release tied to registry completion, warranties on authority and history, covenants for ROA and reverse-DNS transition, holdbacks for cleanup, walk-away rights and evidence retention after closing.

Approval is not an inspection certificate

The most expensive mistake in an IPv4 purchase begins with a comforting sentence: "The registry will check it."

The registry will check some of it. It will usually authenticate a request through accounts connected to the registered organizations. It will apply source and recipient conditions, test whether the resources are eligible for the proposed path, review specified documents and coordinate a record change. Those checks are important. They reduce false transfers and contradictory registration.

But the RIR does not inspect the asset in the commercial sense. It does not promise that the price reflects risk. It does not run the buyer's mail servers, ask every transit provider whether the routes will be accepted, clear every private blocklist, search every court in which a creditor may have sued, or decide whether sanctions law in the buyer's jurisdiction permits the transaction. Its approval does not certify that the seller disclosed all prior leases, letters of authorization, security incidents or geolocation problems.

ARIN's current transfer guide makes the limited nature of approval visible. A transfer request carries a non-refundable fee that does not guarantee approval. For an in-region specified-recipient transfer, an authorized representative of the registered organization must submit the request, and the recipient must qualify under policy. If the current registrant no longer exists, ARIN requires a merger-and-acquisition step to create a clear chain of registration before the specified-recipient transfer proceeds.

Those are not buyer-protection representations. They are conditions for ARIN to change its record. A careful buyer reaches that stage after resolving its own evidence questions. It uses registry approval as a closing condition, not as permission to start diligence.

The ordering matters because risk becomes costly once price, financing and deployment dates are fixed. A buyer that finds a disputed corporate successor after signing may have little leverage. A buyer that discovers obsolete ROAs two days before cutover may face invalid routes. A buyer that learns after closing that a /16 carries widespread mail filtering may own exactly what it bought and still be unable to use it for the intended service.

The disciplined question is not "Will the registry say yes?" It is "What would remain unproven even if the registry said yes today?" The answer defines the diligence plan.

Start with a written use case and an exact prefix schedule

Before investigating the seller, the buyer must define what it intends to buy. "A clean /20" is not a specification. The file should list every CIDR, inclusive address range, originating registry, current registration handle, known more-specifics, intended origin AS, required deployment date and whether the buyer can accept fragmentation.

Exactness prevents substitution. A seller may market a contiguous aggregate but later propose several smaller blocks. The total address count can be identical while operational value changes. More-specific blocks may be harder to route, easier to filter or more expensive to maintain. A /24 is globally routable in common practice; anything more specific may be widely rejected. A fragmented purchase creates more route objects, ROAs, reverse zones and reputation surfaces.

The use case determines which evidence deserves the highest weight. A cloud provider that needs customer-assigned public addresses will care about geolocation, abuse history and mail reputation. A carrier-grade NAT deployment may care less about inbound email reputation but more about routability and aggregation. A buyer acquiring space for a network migration needs a precise cutover plan. An investor intending a later transfer faces holding-period, financing and market-liquidity questions that an immediate operator may not.

The specification should also state prohibited histories. The buyer may refuse blocks used for unsolicited email, residential proxies, command-and-control infrastructure or sanctions-sensitive services. It may require no unresolved route hijack claims, no live leases extending beyond closing and no reverse-DNS delegation that the seller cannot terminate. These are commercial requirements; the RIR will not invent them for the buyer.

A baseline evidence snapshot belongs next to the schedule. Record current RDAP data, BGP origins and visibility, RPKI validation, route objects, reverse nameservers, representative PTR answers, reputation lookups and geolocation results. Date every observation. The snapshot protects against a seller changing the environment during diligence and gives the buyer a comparison point after closing.

No diligence can establish certainty about every address in a large block, but a defined sampling method is better than intuition. Test every announced prefix and every /24 for reputation where tools operate at that granularity. Examine unannounced space separately. A quiet address is not necessarily clean; it may simply have no recent observable use.

Layer one: prove the seller exists and the signer can bind it

Registration is not signatory authority. An RDAP response may show an organization name and contacts, but the person negotiating the sale may be a former employee, consultant, broker, minority shareholder or administrator whose account access exceeds legal authority.

The buyer should obtain current formation records, status certificates where available, constitutional documents and an organization chart showing the selling entity and its controlling relationships. It should identify directors or managers, review signing rules and demand a board resolution or equivalent authorization tailored to the exact prefixes and agreement. The signatory's identity should be verified independently of contact details supplied in the email thread.

If a broker is involved, the buyer needs two authorities, not one. The broker must be authorized to market or coordinate the resources, and the seller must be authorized to transfer them. A broker engagement letter may allow introductions without allowing the broker to accept price or sign closing documents. Payment instructions should be confirmed directly with an authorized seller representative through a known channel.

In insolvency, dissolution, receivership or probate, ordinary corporate authority may have shifted. A trustee, receiver, liquidator, administrator or court-appointed representative may control the transaction. The buyer should obtain the appointment order, confirm its scope and determine whether separate court approval is required. A director listed in old corporate records may no longer be able to convey anything.

Authority must also align with the RIR account. ARIN says transfer requests require an online account linked to an administrative or technical point of contact with authority for a valid organization identifier. That operational credential is evidence, but it does not end the legal inquiry. A compromised or stale point of contact can submit an unauthorized request. Conversely, the proper legal officer may lack account access and need a recovery process before closing.

Fraud is not theoretical. ARIN's fraud-reporting guidance expressly covers false documents used to obtain or transfer resources, unauthorized Whois changes and registry hijacking. The United States Department of Justice's Micfo case described fictitious companies and persons used to obtain hundreds of thousands of IPv4 addresses, followed by sales worth millions. A registrant name, corporate website and notarized page can all be fabricated or misused.

The correct test is convergence: corporate authority, identity, registry access and transaction documents should point to the same authorized seller. If they do not, stop before discussing escrow.

Layer two: reconstruct the chain, not just the current record

The current registration position is the beginning of chain analysis. It is not the chain.

Companies merge, change names, split divisions, dissolve subsidiaries and leave acquired resources registered under old entities. Legacy space may have been issued before the current RIR existed. A block may have passed through several reorganizations while public registration remained unchanged. The seller may therefore have a legitimate economic chain and a stale record, or a current-looking record with a defective underlying transition.

Build a chronological table. Start with the earliest documented issuance or registration. For every change of name, control or resource holder, record the date, parties, transaction type, supporting instrument, registry update and any period of unexplained use. Corporate filings, merger certificates, asset purchase agreements, bills of sale, court orders and RIR correspondence should connect each step.

ARIN's guide lists authenticated asset-purchase documents, finalized merger agreements, government filings, court orders and official name-change records as acceptable evidence for merger, acquisition and reorganization requests. It also says multiple transactions may require documentation for each link. That is exactly the buyer's standard. A missing intermediate acquisition is not cured because the last entity can log in today.

The chain must distinguish an acquisition of the holder from an acquisition of assets that used the addresses. Buying servers from a failed company is not automatically buying every number resource once routed by those servers. Buying all shares of the registered entity may preserve the holder while changing control. A corporate reorganization can move a business without being a market sale of addresses. Each path has different evidence.

Look for duplicate claims. Search sale announcements, broker listings, litigation, old letters of authorization and leases. Ask whether the seller previously promised the block to another buyer, granted an exclusive marketing mandate or pledged proceeds to a lender. The buyer should require a schedule of all current and former third-party rights, not a bare statement that none exist.

Historical routing can expose gaps but cannot fill them. If a predecessor company originated the prefix, that supports operational continuity. It does not prove that every legal transition occurred. If an unrelated ASN originated the prefix, there may be a customer, lease, mitigation provider or hijack. The explanation must be documented rather than inferred from the AS name.

The output is a chain with confidence levels. Verified documentary links can be green. Links supported only by public registration and consistent routing are amber. An unexplained leap between unrelated companies is red. The registry may help repair a legitimate chain; it should not be expected to invent one after the buyer has paid.

Layer three: understand what RDAP says and what it omits

RDAP is the modern standardized method for querying registration data. ARIN's RDAP documentation explains that it returns structured JSON, supports referrals and identifies the source registry. An IP-network response can contain the range, handle, name, type, entities, events, links and notices.

For diligence, query both the full block and representative addresses. Follow referrals to the authoritative RIR. Preserve the raw response and retrieval time. Record the start and end addresses, CIDR representation, parent handle, registration and last-change events, entity roles, status values and terms-of-use notices. Compare those fields with the seller's schedule.

RDAP is excellent at answering "What does the registry publish now?" It is weaker at "How did this entity obtain its position?" Event fields are not a complete conveyancing history. A last-changed timestamp may reflect a contact update rather than a transfer. Privacy redaction may hide personal details. Reassignments can identify downstream users without changing the direct registrant. Different RIRs expose different fields and histories.

The buyer must also distinguish direct registration from reassignment or reallocation. ARIN's record-management guidance explains that a direct registrant can retain authority over a reassignment, while a reallocation creates a more independent management relationship for a downstream provider. A customer appearing in public data may not hold the top-level transfer right.

Check points of contact for freshness, not just presence. Do domains resolve? Do role addresses accept mail? Are contacts employees of the named organization? Has annual validation occurred where shown? A generic address at a defunct domain is a continuity risk even if the organization name is correct.

Where public history is limited public evidence, ask the seller for registry correspondence and use the RIR's formal process. Do not scrape a commercial history service and call the result conclusive. Third-party archives can identify questions, but the buyer needs authenticated evidence for the chain and a written registry path for any correction.

Most importantly, do not describe RDAP as title insurance. It is a public registration view. It can reveal current recognized control and discrepancies. It does not warrant all private rights, liens, sanctions or operational quality.

Layer four: search disputes, insolvency, liens and legal restraints

A registered seller may be unable to complete a sale because another legal process has constrained it. The diligence scope follows the seller, its owners, the asset history and the governing law of the agreement.

Search for insolvency, receivership, dissolution and restructuring proceedings in every relevant jurisdiction. Review court dockets for injunctions, preservation orders, asset-freeze orders and claims specifically naming Internet number resources. Search litigation between shareholders, former business partners and prior purchasers. Ask the seller to disclose threatened claims, not only filed cases.

Secured-creditor analysis depends on local law and document language. IPv4 interests may appear in a broad grant covering general intangibles, contract rights or all assets. The buyer should have counsel review applicable security filings, loan agreements and release mechanics. A registry's dispute check is not a lien search, and silence from the registry does not discharge a lender.

Court orders require exact reading. An order may authorize a sale but condition closing on further consent. It may be stayed pending appeal. It may sell only a debtor's interests rather than guaranteeing an absolute right against everyone. It may direct liens to proceeds while preserving specified exceptions. Record the docket, issuing court, date, finality, affected parties, exact prefixes and operative paragraphs.

Sanctions screening is a separate workstream. Screen the seller, beneficial owners, directors, brokers, escrow providers, financing parties and material affiliates under the regimes applicable to the buyer and transaction. For United States exposure, OFAC provides a sanctions-list search tool and calls for tailored, risk-based compliance rather than a single universal procedure. Name screening must account for aliases, ownership rules, geography and changes through closing.

The IP addresses themselves are not a substitute for counterparty screening. A prefix may have routed traffic linked to a sanctioned service without the registered holder being designated. Conversely, a clean network history does not make a transaction with a blocked person lawful. Legal status attaches through rules that may concern ownership, control, parties, jurisdictions and prohibited services.

Require bring-down evidence shortly before closing. Corporate status can change. A new injunction can issue. A sanctions list can update. A seller can enter insolvency after signing. Diligence performed at term-sheet stage should not be treated as permanently current.

Layer five: read BGP history as use evidence, not ownership proof

BGP history shows how prefixes appeared to route collectors. It can identify origin ASes, announcement and withdrawal periods, more-specifics, visibility changes and abrupt transitions. It is one of the strongest independent evidence sources for operational history.

RIPE NCC's Routing Information Service receives BGP updates from volunteer peers at distributed route collectors and stores the data. The RIPEstat routing-history endpoint groups observed prefixes by origin and provides timelines, peer counts and optional visibility. Raw MRT archives support deeper reconstruction.

For each offered prefix, query at least several years and expand to more-specifics. Record first and last observations, origin AS changes, periods of multi-origin operation, long withdrawals and visibility. Compare the timeline with claimed ownership changes, leases, data-centre moves and incidents. Use more than one collector ecosystem where material because no observer sees every route.

Several patterns deserve explanation. A long-standing origin belonging to the seller is consistent with direct use. A third-party transit ASN may reflect legitimate managed routing. Rapid origin rotation can indicate proxy services, abuse or frequent leasing. More-specific announcements from unrelated networks may reflect customer delegations or hijacks. A block that has never been visible may be unused, privately used or simply unseen from the collectors.

BGP does not convey legal rights. RFC 4271 describes reachability information and path attributes, not sale deeds. An ASN at the origin is evidence that some collectors saw a path ending there. It does not show who paid for the space or whether the announcement was authorized. The buyer must ask for letters of authorization, customer contracts or incident reports that explain material origins.

Visibility is also not reachability from every intended network. Collectors have a limited set of peers. Some routes can be accepted in one geography and filtered in another. Before closing, the buyer should ask intended upstreams to review the exact prefixes, test route filters where possible and identify any minimum-prefix or policy problem.

The best BGP finding is not "clean." It is an explained history with no unresolved material anomaly. That wording leaves room for legitimate complexity without excusing silence.

Layer six: examine RPKI and route objects before cutover

RPKI adds cryptographic evidence about route-origin authorization. A ROA identifies prefixes, an authorized origin ASN and a maximum length. Route Origin Validation can classify an observed route as valid, invalid or not found relative to the available validated entities. Those states affect how networks applying validation policy treat the route.

Inventory every current ROA covering the offered space, including ROAs on a larger aggregate. Record the origin, maximum length, trust anchor and expiry where visible. Model the buyer's intended announcements. A buyer planning /24 more-specifics will create invalid routes if the new ROA authorizes only the aggregate without a sufficient maximum length. An overly broad maximum length can authorize more-specific origins beyond what the buyer intends.

ARIN's transfer guidance for routing security says the source should remove transferred prefixes from ROAs, update or remove obsolete IRR route objects and coordinate reverse DNS. When an ARIN transfer completes, the source certificate is reissued to reflect the change. A recipient with a certificate receives the resource in its renewed certificate but remains responsible for creating new ROAs.

That creates a sequencing problem. Deleting the source ROA too early may turn a live route from valid to not found or invalid depending on other covering entities. Leaving it too long may preserve an obsolete authorization. The buyer, seller and registry should agree on a make-before-break schedule permitted by the service. Monitor validator output from multiple vantage points during the transition.

IRR objects require separate review. Determine which databases contain route or route6 entities for the prefixes, who maintains them and whether upstreams use those databases to build filters. Stale entities can allow an old origin through automated filtering or prevent the new origin from appearing in generated prefix lists. The buyer should know which entities the seller can delete and which require help from database operators.

A valid ROA is not proof of good title. It shows an authorization under a resource-certificate hierarchy at a point in time. An organization with compromised credentials can create one. A seller can have valid ROAs while violating a contract. Conversely, legacy resources without the agreement required for RPKI access may lack ROAs despite a legitimate registration.

Treat RPKI and IRR as operational-control evidence. Align them with the legal and registry chain, but never use them to replace it.

Layer seven: test reverse DNS as a delivery surface

Reverse DNS maps addresses to names through PTR records beneath in-addr.arpa. Mail systems, security tools, logging platforms and customers may depend on it. Control often sits with the direct registrant or a delegated operator, and transition can lag behind a commercial closing.

Query the nameserver delegation for every relevant reverse zone. Check authority, DNSSEC status, lameness, response consistency and representative PTR records. Compare the names with the seller's disclosed use. A range filled with customer hostnames may still be operationally occupied. Names suggesting old proxy, mail or hosting services can direct deeper reputation review.

ARIN's reverse-DNS guidance explains that holders manage nameserver delegations and DS records through its provisioning service. Its transfer practices place responsibility on source and recipient to coordinate the change. The buyer should identify who operates the current authoritative servers and whether that provider will cooperate after closing.

The transition plan should specify new authoritative nameservers, zone content, TTL reduction, DNSSEC key and DS handling, cutover time and verification. If the seller's nameservers will remain temporarily, the contract should define duration and service level. If the buyer needs a clean namespace, it should plan removal of old PTR records rather than assuming transfer erases them.

Reverse DNS can affect reputation. Spamhaus's reputation guidance notes that PTR and HELO consistency can matter in diagnosis of low-reputation email addresses. A buyer intending mail use should test forward-confirmed reverse DNS and provider-specific sender requirements before valuing the block.

Like BGP, DNS evidence has limits. A PTR record can be set by an authorized customer without implying ownership. Absence of PTR data does not prove nonuse. Cached delegations can outlive a change. The buyer is looking for control, dependency and residue, not a title certificate.

Layer eight: investigate reputation at address and block level

IPv4 addresses carry history because other networks remember behavior. Mail providers, security vendors, fraud platforms, ad networks, search engines and private enterprises maintain risk models built from prior traffic. A sale does not oblige them to forget.

Start with public blocklists and reputation tools, including the Spamhaus IP and Domain Reputation Checker. Test every /24 and a defensible sample of addresses, with extra attention to addresses visible in passive DNS, BGP or seller records. Record list name, reason, listing date where available, last observed activity and removal procedure.

One clean tool is not enough. Lists cover different behavior and update at different speeds. Some are transparent; others are private. Large mail platforms may apply internal reputation that is not visible in a public checker. A block can be absent because it has been unrouted, not because it has an established good reputation. New use can trigger renewed scrutiny.

Search passive DNS and certificate-transparency data for domains historically tied to the range. Review abuse reports supplied by the seller, public threat feeds, malware observations and spam histories. Look for residential proxy networks, bulletproof hosting, credential phishing, command-and-control, scanning, denial-of-service participation and repeated reassignment to high-risk customers.

Reputation should be measured by intended use. For outbound mail, conduct controlled deliverability tests after obtaining authority and before full migration if the transaction permits. For advertising or account platforms, ask whether fraud systems flag the range as proxy, hosting or non-residential. For consumer access, test major geolocation and content services. For cloud use, determine whether customers will inherit a history that raises support costs.

Geolocation is related but distinct. Compare several providers and document country, city, network type and organization. A block registered in one region and routed in another may retain old location data for weeks or months. The seller should submit correction requests where possible, but no contract can force every database to update on a fixed day.

Price the cleanup. A discounted block with remediable listings may be rational. A range with persistent private filtering and no explanation may not. The seller should warrant disclosed history and cooperate with removal, but the buyer should avoid an absolute promise that reputation will become clean; third parties control their own decisions.

Layer nine: determine whether the block is still serving someone

An offered block can be legally transferable and operationally occupied. Customers may have addresses assigned under contracts that survive a change of control. A lessee may have a term extending beyond the seller's proposed closing. An upstream may still announce the space. A mitigation provider may hold a letter of authorization. Reverse DNS and route objects may be maintained by third parties.

Demand a utilization schedule. It should map active services, customers, origin ASes, assignments, leases, letters of authorization, DNS providers and planned termination dates to prefixes. Compare the schedule with BGP, RDAP reassignments, reverse DNS and passive observations. Unexplained traffic is a red flag.

Contract review should determine whether third-party rights can be terminated or assigned. A seller may describe a lease as informal while the customer possesses a binding service agreement. A customer may have prepaid for a term. A court order may be needed in insolvency. The RIR's record change will not necessarily terminate those private rights or stop the customer's routers.

The buyer needs a decommissioning plan. Customer notices, route withdrawal, LOA revocation, access removal, DNS changes and data retention should have dates and owners. If services cannot end before registry completion, the buyer must decide whether a transitional use license is acceptable. That license should define routing, abuse response, security credentials and liability.

Monitor for shadow announcements. A seller can withdraw the aggregate while a customer continues to announce a more-specific route. Because longest-prefix matching favors the more-specific, traffic can continue to flow away from the buyer. Search all covered prefixes, not only the purchased aggregate, during and after closing.

Occupancy is not automatically bad. A buyer may purchase a live network or retain customers. The risk is undisclosed dependency. The price and cutover plan must reflect who is using the addresses and how their authority ends.

Layer ten: map the transfer path before signing

The same prefixes can be transferable through one path and blocked through another. The buyer must identify the source RIR, recipient RIR, source status, recipient account, transfer type and any required intermediate correction.

Within ARIN, a specified-recipient transfer under section 8.3 requires the source to be the current registered holder, free of a dispute over status, and subject to timing restrictions. The recipient must meet section 8.5, sign an agreement and satisfy block-size conditions. A merger or reorganization under section 8.2 uses different evidence and is not subject to a needs assessment during that transfer. Misclassifying an asset purchase as a simple market transfer can create a broken chain.

Inter-RIR transactions add two institutions. ARIN policy requires reciprocal, compatible needs-based policies and confirmation from the counterpart. APNIC's transfer guide, RIPE's IPv4 transfer policy and LACNIC's IPv4 policy text set their own source, recipient and record conditions. The buyer should obtain a written path from both sides rather than assume that global routability means global transferability.

Check minimum block size, reserved-pool exclusions, waiting-list consequences, prior-receipt holding periods, recipient need, account standing and fees. For legacy resources, determine whether an agreement exists and which services are available before and after transfer. ARIN currently allows certain registration and reverse-DNS services for uncovered legacy resources but requires an agreement for RPKI and IRR access.

Pre-approval can reduce recipient risk but does not approve a specific seller's chain, resource history or reputation. Record its amount, expiry, conditions and portability. If the deal crosses regions, ensure the approval fits the exact source RIR and proposed size.

Build a transfer-path memo with decision points and elapsed-time assumptions. Mark who submits first, which documents each RIR needs, when fees are due, how inter-RIR coordination occurs, what event counts as completion and what happens if one side approves while the other does not. That memo should shape the contract's long-stop date and escrow terms.

A broker's assurance that "we do these every day" is not evidence of this path. Ask for written RIR guidance tied to the facts without disclosing price or unnecessary commercial terms.

Turn evidence into conditions, warranties and price

Diligence that does not change the contract is merely research. Each material finding should produce a closing condition, representation, covenant, indemnity, holdback, price adjustment or decision to walk away.

Authority findings become representations that the seller exists, owns or controls the transferable interest, has approved the transaction and has not granted conflicting rights. Chain findings become a schedule of prior transactions and a duty to provide additional documents requested by the RIR. Legal findings become conditions for releases, court approval or expiry of a stay.

Operational findings become transition covenants. The seller removes or modifies ROAs and route objects at the agreed time, withdraws unauthorized routes, assists reverse-DNS change, terminates old letters of authorization and provides abuse-history records. The buyer creates new credentials and conducts acceptance tests. Both sides preserve service during an agreed overlap where necessary.

Reputation findings affect price and holdback. A buyer can reserve part of the consideration until specified public listings are removed or until the seller completes agreed cooperation. The condition should concern observable acts, not a promise that every private platform will regard the addresses favorably. If the intended use depends on one provider, make successful testing with that provider a condition.

Payment release should be tied to registry evidence. A sensible escrow instruction identifies the exact RIR completion notice or record state, not a vague broker email saying the transfer is done. If legal closing occurs before operational migration, divide the consideration and delivery receipts accordingly.

Remedies should match control. The seller can indemnify for undisclosed prior contracts, forged authority or known litigation. It cannot guarantee every future route decision. The buyer controls its network plan and should bear the risks of its own configuration. The registry controls the timing and correctness of its record, subject to its agreement. Clear allocation discourages every failure from becoming an argument about ownership.

The contract should preserve evidence after closing. Insolvent sellers disappear; employees leave; broker files age. Keep authenticated corporate documents, registry notices, prefix schedules, baseline measurements, closing receipts and transition logs for a period proportionate to the asset's life and dispute risk.

Use a stoplight that can actually stop the deal

An executive summary should not average all risk into a comforting score. Some defects are fatal regardless of how clean the rest of the block appears.

Red conditions include an unauthorized seller, an unexplained break in the chain, conflicting sale commitments, a live court restraint, a sanctioned counterparty where the transaction is prohibited, a registry dispute that cannot be resolved, a proposed path rejected by either RIR, active hostile more-specific announcements or evidence that the prefixes were fraudulently obtained. Money should not move while a red condition remains.

Amber conditions can be priced or cured. Examples include stale contacts, fixable ROAs, manageable route-object cleanup, inconsistent geolocation, public blocklist entries with documented causes, a customer migration with a short defined term or a corporate name change awaiting record update. Each amber item needs an owner, evidence of cure, deadline and consequence.

Green means evidence converges, not that risk is zero. The seller's authority is verified; the chain is documented; RIRs confirm a feasible path; legal searches reveal no material restraint; routing history is explained; credentials can transition; reputation fits the use case; and contract mechanics allocate remaining uncertainty.

The stoplight should be prefix-specific. A seller offering ten blocks may have nine green ranges and one red range. The buyer can remove the defective block rather than contaminate the whole transaction. Pricing can differ by operational history and cleanup burden.

Set escalation thresholds. A new origin during exclusivity, an undisclosed listing, a changed corporate officer or a delayed registry response should trigger re-review. Silence should not turn amber into green automatically. Expiry dates matter: a status certificate or sanctions screen from three months earlier is not current at closing.

Most importantly, the deal team must retain the authority to stop. If sunk legal fees and deployment pressure make every red flag negotiable, the framework is decorative. IPv4 scarcity creates urgency, but scarcity is not a reason to buy a claim that cannot be registered or a block that cannot serve the intended network.

Recheck the evidence after the registry says yes

Registry completion changes the evidence landscape. The buyer should immediately capture the completion notice and fresh RDAP response, then verify every promised operational surface.

Confirm the direct registrant, organization handle, contacts, range boundaries and relevant agreement. Test account access and authority. Verify that reverse-DNS delegations point to the intended nameservers. Check RPKI certificates and ROAs from independent validators. Confirm route objects in databases used by the buyer's upstreams.

Announce in a controlled sequence. Monitor RIS and other collectors for origin, visibility, more-specifics and unexpected competing routes. Ask critical upstreams to confirm filter state. If the block remains unannounced, monitor for unauthorized use while deployment is pending.

Repeat reputation and geolocation checks. Some services react to a new origin or changed registration; others do not. Open correction requests with evidence of the transfer where appropriate. Preserve ticket identifiers and responses. Do not flood third parties with identical unsupported requests; provide a coherent account of the change.

Confirm that the seller's access has ended where it should. Old points of contact, API credentials, DNS providers, routing accounts and customer letters can outlive closing. The registry record may be correct while a third party still accepts an obsolete authorization. Revoke or replace each dependency explicitly.

Finally, compare the post-close state with the baseline. Every difference should be expected or investigated. A new route, changed PTR pattern or disappearing ROA may be part of migration. An unexplained difference can expose a mistake while escrow holdbacks and seller cooperation remain available.

The registry's yes is therefore a milestone, not absolution. It proves that the recognized record changed under the applicable process. The buyer's acceptance proves that the purchased resource is ready for its intended use.

Better markets require evidence that can travel

Today, each IPv4 transaction rebuilds much of the same evidence privately. Corporate authority sits with counsel. Registry state sits with an RIR. BGP history sits with collectors. Reputation sits with many third parties. Legal orders sit in national courts. The buyer pays to reconcile them under time pressure.

Some fragmentation is unavoidable because the facts come from independent institutions. Centralizing every judgment in an RIR would not solve the problem; it would hide uncertainty behind one approval. The improvement is portability and clear scope.

A seller should be able to prepare a reusable evidence packet containing authenticated authority, a chronological registration chain, exact prefix inventory, current agreements, routing history explanations, ROA and IRR inventory, reverse-DNS plan, disclosed use, dispute statement and dated reputation observations. Sensitive terms can remain confidential while core evidence is verified.

The registry should provide machine-readable receipts for recognized state, pending holds and completion. Routing collectors already provide time-indexed observations. Courts can issue authenticated orders. Reputation providers can expose dated status and reason codes. None of these receipts needs to claim more than it knows.

Number Resource Society points toward a market in which recognized control can move through deterministic, auditable transitions without making one private association the judge of every commercial fact. Buyers would still perform diligence because legal, operational and reputation risks remain. They would spend less time proving the same registration chain repeatedly and more time testing actual use.

The governing principle is evidence separation. Holder authority is not BGP use. BGP use is not registry recognition. Registry recognition is not clean reputation. Clean reputation is not sanctions clearance. A court order is not a ROA. The transaction is safe only when the relevant layers converge.

That principle also disciplines claims after failure. If a route is filtered, inspect routing credentials and upstream policy. If another buyer appears, inspect authority and contract history. If a registry refuses the change, inspect the path and record chain. A market becomes accountable when failures can be located instead of being attributed to a mystical thing called ownership.

Due diligence must finish before dependence begins

IPv4 buyers often face a genuine deadline. A customer launch needs addresses. A migration is consuming inventory. A seller's exclusivity period is short. Another bidder may be waiting. The pressure is real, but the sequence should not change.

Define the prefixes and use case. Verify the seller and signer. Reconstruct the corporate and registration chain. Search legal restraints and sanctions. Read BGP history. Inventory ROAs, route objects, RDAP, reverse DNS, reputation and current users. Confirm the exact regional path. Put every material finding into closing mechanics. Then ask the registry to recognize the transaction.

If approval comes, it should confirm what the buyer already understands: the named source can use the specified path to place the listed resources with the recipient under the applicable rules. It should not surprise the buyer with the existence of an old holder, an incompatible region or an agreement requirement that no one priced.

The registry's role remains vital. Accurate records and authenticated transitions protect the whole market. The danger lies in allowing that necessary function to substitute for buyer judgment. An RIR cannot know the buyer's use case, contractual risk tolerance, mail dependency, sanctions exposure or acceptable routing history. It should not pretend to certify them.

The buyer who waits for the registry's yes has reversed the order of knowledge and dependence. By approval time, deposits may be committed, teams scheduled and alternatives lost. The buyer who diligences first can negotiate from evidence, abandon a defective block and use registry approval for what it is: a decisive administrative receipt in a much larger transaction.

Scarcity rewards speed only when speed preserves choice. The fastest safe deal is not the one with the shortest checklist. It is the one that resolves fatal questions before they become closing emergencies.

Sources