ARIN and the economics of registry-layer risk

Summary

• ARIN shows how a mature registry can still turn address records, transfer recognition and registry-tied services into a priced risk layer above routes, contracts and customers; in North America that risk now travels through diligence files, escrow mechanics.
• The first alarm in an address-heavy acquisition is not always a routing alarm.

The risk appears before the network breaks

The first alarm in an address-heavy acquisition is not always a routing alarm. The packets may still move. The acquired customers may still be live. The data-centre racks may still answer probes, VPN concentrators may still terminate sessions, and mail may still leave with the reverse-DNS names customers expect. The lawyers may have signed the purchase agreement, the lenders may have circulated final comments, and the integration team may already be building migration windows. Then the diligence call turns to a less visible question: will the registry record survive closing?

In a North American transaction room that question is not academic. A buyer looking at a hosting platform, network-security business, enterprise carve-out, access network, cloud region or managed-services provider is not only buying routers, contracts, customers and code. It may be buying, or relying on, blocks of IPv4 address space whose economic usefulness depends on a public registry state maintained by ARIN. The buyer wants to know who ARIN recognises as the current holder, whether the source organisation still exists, whether an officer can sign for it, whether old corporate history is clean, whether the resources are under a Registration Services Agreement or a legacy boundary, whether fees are current, whether a dispute marker exists, whether a transfer can be recognised, and whether reverse DNS, RDAP, Whois, RPKI or routing-registry entries will remain coherent after the deal closes.

None of that is ordinary packet forwarding. None of it is simply contract law between buyer and seller. It is the registry layer: the administrative record and service perimeter that sits above routing reality and below legal-economic reliance. It is easy to underestimate because it often works quietly. A customer sees service continuity; a lawyer sees a signed asset schedule; an engineer sees BGP announcements; a finance team sees address capacity inside an acquisition model. ARIN sits in a different position. It keeps the public registration record, processes changes, validates authority, maintains related registry services and applies policy conditions before the market receives registry finality.

That layer adds real value. A buyer can transact more confidently because there is a shared record to check. A seller can prove recognised control because ARIN publishes and maintains a registry state. Operators can maintain reverse DNS, RDAP and Whois data. Routing-security services can be tied to the recognised holder. Fraudulent claims can be resisted. Duplicate registrations can be avoided. In a market where IPv4 has become scarce, priced and operationally embedded, those functions are not clerical trivia. They are part of the trust stack.

The same layer also creates a risk premium. If recognition depends on review, agreement status, contact data, unpaid fees, policy interpretation, dispute handling, documentation rounds or security-service eligibility, a commercial transaction is not final merely because private parties have signed. The buyer may have contractual rights against the seller, but its practical reliance still depends on whether ARIN's records and services align with the new economic reality. A signed agreement can close faster than a registry record can be made clean. A network can route while title confidence remains uncertain. A customer contract can promise continuity while reverse-DNS or RPKI state still depends on registry-facing work.

That is the economics of registry-layer risk. It is not a complaint that ARIN is in obvious crisis. ARIN is a mature and orderly registry compared with the more dramatic cases in the RIR world. Its public processes are documented, its transfer categories are legible, and its legacy-resource materials recognise historical complexity. Precisely for that reason it shows a subtler problem: even orderly registry process can become an operating risk layer when IPv4 blocks are embedded in acquisitions, platform capacity planning, security products, hosting contracts, financing assumptions and legacy-resource histories.

The North American buyer on the diligence call does not ask whether ARIN is useful. It asks where ARIN's usefulness ends and its settlement power begins. The answer can affect price, escrow, warranties, closing conditions, lender comfort, customer migration plans and the buyer's willingness to take the asset at all.

The registry layer is neither the route table nor the purchase agreement

The registry layer should be separated from two neighbouring systems that often confuse the debate. It is not the route table. ARIN does not make every network accept a prefix, and a clean registry record does not guarantee reachability through every upstream, filter set or peering arrangement. Routing depends on thousands of operational decisions by network operators. BGP announcements, routing policies, prefix filters, reputation systems, RPKI validation practices and peering relationships decide whether packets actually travel as expected.

The registry layer is also not ordinary private contract law. A buyer and seller can allocate risk in a purchase agreement, declare what is being sold, set warranties, agree to indemnities and appoint an escrow provider. Those private terms matter. They can decide who bears the loss if a transfer fails, if a seller lacks authority, if a block carries undisclosed reputation damage or if a security record cannot be migrated. But a private contract does not itself update ARIN's public records. It does not automatically cause RDAP or Whois to identify the buyer. It does not move reverse-DNS delegation. It does not create or remove ROAs. It does not prove to ARIN that a source officer had authority or that a chain of merger documents is sufficient.

Between those two layers sits a record-and-recognition system. ARIN's transfer materials distinguish transfers caused by mergers, acquisitions and reorganisations; specified-recipient transfers within the ARIN region; and inter-RIR transfers with compatible RIRs. The same materials describe ARIN Online requests, Admin or Tech Point of Contact authority, transfer processing fees, signed Registration Services Agreements, officer acknowledgement, documentation, source and recipient review, and completion after the required agreements and fees are received. These are not merely office steps. They are the means by which private economic facts become public registry facts.

That intermediary position is why registry-layer risk can be underestimated by both engineers and lawyers. Engineers may say the addresses route, so the network is fine. Lawyers may say the purchase agreement assigns the asset, so the buyer is protected. Both statements can be partly true and still miss the actual risk. A routed prefix can have a stale registry record. A signed contract can leave unresolved whether ARIN will recognise the buyer as the registrant. A clean corporate sale can still require evidence tying old resources to acquired network assets. A technically successful renumbering plan can still be hostage to reverse-DNS timing or RPKI transition hygiene.

The registry layer matters because it is the place where operational reliance, public record, policy conditions and legal authority meet. It translates the messy history of organisations into a current recognised state. It helps outsiders distinguish a holder from a pretender. It tells counterparties where to look for contacts. It provides the reference that downstream tools, diligence reports, abuse desks, routing-security systems and transfer participants use to orient themselves. When it works well, it lowers transaction costs and reduces fraud. When it becomes uncertain, it adds a premium to every deal that depends on it.

That premium does not require arbitrary conduct. A stable rule can still impose a predictable tax. A professional review can still create timing risk. A transparent policy can still move liability from the registry to the operator, buyer, customer or intermediary. A public process can still be too slow for a financing deadline. ARIN's maturity does not remove the risk. It lets the risk be described without relying on scandal.

The distinction also clarifies what a legitimate registry should be trying to protect. It should protect uniqueness, authority, record accuracy, dispute integrity and service continuity. It should verify that a change request is real, that the source is the recognised holder, that old corporate history has not been fabricated, that a pending dispute is not being laundered through a quick sale, and that security and DNS state can transition without misleading the rest of the Internet. Those are strong registry questions. They are the reason a trusted record has value.

Other questions sit on weaker ground. Does the buyer's business model satisfy allocation-era language? Is a future capacity plan too speculative? Should a legacy holder accept broader contractual terms to access a service that is becoming operationally expected? Should cross-region mobility depend on policy compatibility beyond what is needed to preserve a reliable record? Those questions may have policy answers, but they are not the same as verifying the record. In a scarce market, the difference has economic consequences.

Commercial diligence now reads the registry file

Address diligence used to be a specialist appendix. In many North American transactions it is now part of the main risk file. A buyer wants to know not only how many IPv4 addresses are used by the business, but how the registry state supports the claim that they can be transferred, maintained or relied upon after closing. The questions are practical, cumulative and often unglamorous.

The first question is identity. Which organisation is the current registered holder? Does the name in ARIN's record match the selling entity, a predecessor, a subsidiary, a dissolved company, a university department, a trade name or a forgotten acquisition vehicle? If the holder is not the seller, what corporate chain connects them? If there were asset sales, mergers, reorganisations or name changes, are the documents sufficient to show that the resources followed the network, customers or business line that now forms part of the transaction?

The second question is authority. Which Admin or Tech Point of Contact can act for the organisation in ARIN Online? Is the Point of Contact current, validated and controlled by someone with real authority? Is an officer acknowledgement required? Can a seller produce a signed and notarised officer letter without delay? If an old contact has left the company, died, moved to a divested unit or used an email domain no longer controlled by the holder, can the organisation recover authority before the deal clock runs out?

The third question is agreement status. Are the resources under a current Registration Services Agreement, an earlier Legacy Registration Services Agreement, or no ARIN agreement? ARIN's legacy-resource materials state that legacy holders not under agreement can maintain unique registration in Whois/RDAP, update public data, manage reverse-DNS delegations, maintain registry records through ARIN Online and access DNSSEC. They also state that RPKI and Internet Routing Registry access require the resources to be under an ARIN agreement. That distinction is not a footnote for counsel. It changes how a buyer assesses routing-security readiness, service access and contract leverage.

The fourth question is fee standing and account status. Registry fees are small relative to a large acquisition, but non-payment can create disproportionate consequences if service access, renewal, transfer processing or account standing becomes a closing condition. In a portfolio with many blocks, multiple Org IDs and legacy histories, a missed invoice or neglected billing contact can become a transaction issue. The money may be minor. The delay may not be.

The fifth question is dispute status. ARIN's specified-recipient and inter-RIR transfer requirements include source-side conditions that the current registrant not be involved in a dispute over the status of the resources. From a market perspective that condition is sensible. A registry should not let contested resources move as if nothing were wrong. But a dispute marker also changes price. It may require escrow, a special indemnity, a closing condition, a side letter or a decision to exclude the block from the deal.

The sixth question is transfer eligibility. Is the transaction a merger, acquisition or reorganisation transfer, where ARIN processes the movement of resources connected to acquired assets or networks and does not conduct a needs-based assessment during that 8.2 process? Or is it a specified-recipient transfer inside the ARIN region, where the source and recipient submit separate linked requests and the recipient must satisfy transfer-recipient requirements? Or is it an inter-RIR transfer, where reciprocal, compatible, needs-based policy and the receiving RIR's validation become part of the path? The answer affects timing, documentation and business structure.

The seventh question is service state. Who controls reverse DNS? Which PTR zones are delegated where? Are there existing ROAs that must be edited or deleted by the source? Are routing-registry entries current? Will the recipient be able to create its own RPKI statements and routing records quickly enough? Does RDAP show unvalidated contacts or stale related entities? ARIN's transfer guide itself tells source organisations involved in 8.3 and 8.4 transfers to handle ROAs, maxLength values, routing-registry entries and reverse-DNS delegation plans. That is not legal ornament. It is the operational part of settlement.

The result is a diligence stack that reads like a blend of corporate history, technical operations, registry policy and market settlement. Current holder, officer authority, organisation history, contact accuracy, signed agreements, unpaid fees, dispute status, transfer eligibility, prior transfers, reverse DNS, RDAP/Whois and security-state dependencies all become part of the commercial file. A clean block is not simply a block that routes. It is one whose registry and service state can be understood, transferred and maintained without exposing the buyer's customers to avoidable interruption.

Three different risks hide under one administrative surface

Registry-layer risk becomes clearer when it is divided into three categories: record-integrity risk, process-finality risk and service-dependency risk. They are related, but they are not the same.

Record-integrity risk is the danger that registry data is false, stale, incomplete or contested. The named holder may no longer exist. A contact may be unvalidated. The organisation history may not match the seller's narrative. A successor may lack a clean chain of documents. A prior transfer may have left confusing remnants. A dispute may exist but not be understood by the buyer. The public record may point to an old address, an old officer, an old network name or a legacy structure that no one inside the company can explain.

This risk is not solved by moral confidence in the seller. It is solved by evidence. A buyer needs corporate filings, asset-transfer documents, merger records, court orders, board resolutions, historical Whois data where available, ARIN account authority and technical confirmation that the resources in the deal are the resources actually used by the business. ARIN's role is valuable here because the registry can insist on evidence before changing the record. A market without such discipline would be vulnerable to forged sales, hijacked contacts and double claims. Record-integrity review protects both the market and the Internet.

Process-finality risk is different. It appears when a transaction is signed but the registry has not yet recognised the change. The parties may believe they have settled between themselves. Funds may be in escrow. The buyer may have paid for an operating business that includes address capacity. Yet until ARIN completes the record update, the market does not have full registry finality. If a documentation question emerges, if a fee must be paid, if an RSA must be signed, if the source and recipient tickets are not aligned, if recipient requirements are contested, or if an inter-RIR partner needs to certify compatibility, the deal can sit in a gap between private closing and public recognition.

That gap is where settlement risk lives. In a conventional transaction, closing is designed to be the decisive moment. In address transactions, closing can become a sequence. Private agreement, escrow release, ARIN approval, signed agreement, fee payment, record update, reverse-DNS handover and RPKI/routing updates may not occur at the same instant. If the buyer's customer commitments assume all of them have occurred, risk has been mispriced.

Service-dependency risk is the third category. It is the risk that operational services tied to registry status, agreement status or account access change the economics of the resource. Reverse DNS may affect mail deliverability, security systems, spam filtering, logging and customer trust. RDAP and Whois affect contactability, abuse handling, diligence and public accountability. RPKI affects route-origin assurance. Routing-registry entries affect filtering practices in many networks. DNSSEC may matter where reverse-DNS zones are part of a security posture. If these services depend on a specific account, agreement, contact, delegation or transfer sequence, registry status becomes operational status.

Service-dependency risk is often discovered late because the network may continue to route while the service layer is not ready. A buyer can announce prefixes and still inherit broken PTR records, stale abuse contacts, old ROAs, conflicting routing-registry entries or a legacy agreement boundary that prevents immediate use of ARIN-hosted routing-security services. A seller can believe it has transferred an economic position while leaving behind security statements that mislead validators or confuse customers. An acquirer can schedule customer migration while the DNS delegation plan is still unresolved.

The three categories require different controls. Record-integrity risk needs evidence, chain-of-authority review and accurate public data. Process-finality risk needs closing conditions, escrow mechanics, registry timing assumptions and clear responsibility for approvals. Service-dependency risk needs technical transition planning, account access, reverse-DNS delegation, RPKI and routing-record hygiene, and customer-facing contingency plans. Treating all three as "ARIN paperwork" is a mistake.

The more valuable IPv4 becomes, the more these distinctions matter. A block can be clean for routing but weak for title confidence. It can be clean for title confidence but slow for process finality. It can be recognised by ARIN but messy in service transition. Sophisticated buyers price each layer separately. Smaller buyers often discover them together, under time pressure, after the bargain has already been struck.

ARIN is orderly, and order can still be costly

ARIN's public mechanics are not obscure. Transfers of resources issued by ARIN or its predecessors are governed by ARIN policy. Its transfer guide describes three broad commercial paths. A merger, acquisition or reorganisation transfer applies where an organisation has acquired assets, customers, equipment, a network or the organisation as a whole. A specified-recipient transfer applies where a current holder releases unused IPv4 address space or an ASN to a qualified recipient in the ARIN region. An inter-RIR transfer applies where resources move between ARIN and another RIR with reciprocal, compatible, needs-based policy.

The mechanics include sensible protections. Transfer requests require an ARIN Online account linked to an authorised Admin or Tech Point of Contact for a valid Org ID. A source in a specified-recipient transfer must be the current registered holder, must not be involved in a dispute over the resources, must provide a signed and notarised officer acknowledgement, and must satisfy source-side restrictions such as minimum transfer size and recent-receipt limits. M&A transfers require evidence such as asset-purchase documents, merger filings, court orders, public filings or name-change documentation. Inter-RIR transfers require compatible policy and can require certification from the receiving RIR. Recipients must satisfy ARIN's transfer-recipient requirements and, where relevant, demonstrate need.

These are not irrational requirements. A registry that accepts a transfer from the wrong source corrupts the record. A registry that ignores a live dispute may help one claimant defeat another by speed. A registry that does not ask for succession documents in an acquisition will not know whether resources followed the network or merely appeared on a schedule. A registry that allows stale contacts to move resources will invite hijacking. Order protects the market from fraud.

The economic point is different: order does not prove neutrality. A stable, professional and transparent process can still create timing risk, information asymmetry and liability transfer. If a rule is predictable but costly, it is still a cost. If an official requirement is clear but difficult for small operators, it still favours scale. If an inter-RIR compatibility rule is public but blocks a commercial movement that would otherwise make operational sense, it still creates a capital wedge. If recipient need review is consistently applied to private transfers, it still imports allocation-era logic into a market transaction.

The same is true of agreement status. ARIN's agreements page says legal contracts define and bind the relationship between ARIN and customers, that a signed RSA is required before ARIN approves creation of an Org ID in ARIN Online, and that existing and newly approved customers must sign the current RSA for each resource request. That is a normal service-contract architecture for a registry. It is also an economic dependency when the resource has market value. Signing an RSA may be a routine step for one buyer and a material legal issue for another. A legacy holder may view agreement as a path to services and certainty, or as a movement into a contractual perimeter it has historically avoided.

ARIN's legacy boundary makes the point sharper. Legacy holders not under agreement can maintain Whois/RDAP data, reverse DNS and registry records, but cannot use ARIN's RPKI and Internet Routing Registry services unless covered by an ARIN agreement. When routing security is optional, that boundary looks like a service menu. As RPKI and routing-record hygiene become ordinary diligence expectations, the same boundary begins to look like a commercial pressure point. The record remains available; some strategically important services sit behind a contract line.

No scandal is required for such costs to appear. The institution can be acting in good faith. Staff can be competent. The policy can be published. The cost still exists because commercial finality has been made dependent on a registry process whose duties, liability and timing are not identical to the buyer's commercial promises. In a North American market where address resources may sit inside acquisition financing, cloud capacity and enterprise continuity commitments, that dependency is priced.

The old asset vocabulary lost to asset reality

The market's treatment of IPv4 shifted before institutional vocabulary fully adapted. The 2011 Nortel/Microsoft address sale remains a useful historical marker not because it should dominate the ARIN story, but because it made the contradiction visible early. A bankrupt technology company had address resources that buyers valued. A court-supervised sale process interacted with registry recognition. The transaction showed that addresses were no longer merely internal administrative records. They had become part of asset reality.

Markets do not wait for perfect legal vocabulary. RIR materials often avoid treating IP addresses as ordinary property, and there are sound reasons to be careful with real-property analogies. An IP address is not land. It is not a machine. It is a unique numerical identifier used inside a global coordination system. But the economic behaviour around it is unmistakable. IPv4 blocks are bought, sold, leased, financed indirectly, valued in acquisitions, reviewed by auditors, protected by lawyers, watched by boards and embedded in customer revenue. If a resource is scarce, durable, transferable under rules, useful in operations and tied to public recognition, markets will treat it as an asset even if institutions prefer different words.

The registry layer is pulled into that asset reality because the record is part of the resource's usefulness. The commercial and operational value comes from networks and customers, not from ARIN's database by itself. Yet the database is the public reference layer that helps the world know who is recognised for operational purposes. The record does not create the whole value, but it can preserve, impair or delay the value. That is enough to make registry process economically significant.

This creates a vocabulary gap. A seller may speak as though it owns a block. ARIN may speak in terms of registration, services and policy. A lawyer may draft asset-transfer language. An engineer may speak about announcements and filters. A lender may ask whether the block can support collateral-like value. A customer may care only whether service stays up. All are describing parts of the same reliance chain. The registry-layer question is whether these descriptions can be reconciled without destroying confidence.

The best way to avoid sterile argument is to focus on reliance. Who is recognised as the holder? Can authority be proven? Can the record be changed predictably when the business changes hands? Can services follow the resource without avoidable disruption? Can disputes be isolated without damaging unrelated customers? Can the registry explain which conditions protect uniqueness, accuracy and continuity, and which conditions are broader policy controls?

That reliance-based approach is stricter than property rhetoric and stricter than official vocabulary. It does not need to declare that ARIN sells property. It also does not let anyone pretend that a public registry entry around scarce IPv4 is economically insignificant. It asks what prudent counterparties can rely on and who bears the loss when reliance fails.

Asset reality has already reached the diligence room. The vocabulary will catch up through contracts, prices, insurance exclusions, lender questions, broker practices and disputes. ARIN's institutional choice is whether to reduce that adjustment cost by making its recognition role narrow, transparent and auditable, or to let the market add a larger risk premium around every registry-dependent resource.

Settlement finality is a commercial product

In a market for scarce operational assets, finality is valuable. A buyer does not merely want a promise that the seller will cooperate. It wants to know that the transaction can become a stable public state. In address transactions, that means registry recognition, public data update, service transition and clean authority after closing. The more steps between signed contract and recognised state, the more finality must be bought through legal and operational design.

ARIN's process makes the sequence visible. In a specified-recipient transfer, both source and recipient submit requests. ARIN links the tickets after review. A processing fee is paid. The requests are processed independently. On approval, invoices and an RSA may follow. After applicable fees and signed agreement are received, ARIN completes the transfer. In an inter-RIR transfer, the sequence also involves the other registry's policy and validation. In an M&A transfer, documentation must show that assets, customers, equipment, networks or organisational control have actually moved.

Each step is legitimate from ARIN's perspective. Each step also creates a point where closing risk can live. A buyer may require ARIN pre-approval as a condition to closing. A seller may want escrow release only after registry recognition. A lender may condition funding on clean transfer approval. A buyer may seek a holdback for unresolved reverse-DNS or RPKI transition tasks. A seller may insist that the buyer's failure to meet recipient requirements is not a seller breach. A broker may charge more for navigating the process because the broker is effectively selling experience with registry finality.

These structures are not signs that the market is irrational. They are signs that the registry layer has become part of settlement architecture. The private contract allocates risk because the registry process decides when public recognition arrives. If ARIN were merely a passive address book, there would be little reason for such controls. If it were a full legal title office with strong liability, insurance and adjudication duties, the market would price it differently. Instead, ARIN sits between: powerful enough that recognition matters, limited enough that counterparties must protect themselves privately.

That middle position is where process-finality risk becomes expensive. Escrow instructions need to address partial failure. Warranties must cover source authority, no undisclosed disputes, accurate registry data, absence of prior encumbrances, agreement status, fee standing and cooperation with ARIN. Purchase agreements need covenants requiring timely ticket submission, officer acknowledgement, response to documentation requests, removal or update of ROAs, routing-record cleanup and reverse-DNS transition. Closing conditions must specify whether private closing occurs before or after ARIN completion. Indemnities must decide who pays if the registry refuses recognition for reasons tied to the seller's history or the buyer's qualification.

Where the risk cannot be allocated cleanly, price adjusts. A buyer may discount the block. A seller may prefer a known market participant with stronger ARIN experience. A small buyer may lose to a larger buyer not because the larger buyer values the addresses more, but because it looks easier to get through recognition. A resource with clean M&A documentation may trade at a premium to a resource with a murky legacy chain. A block with uncertain service state may be excluded from working-capital calculations or placed in a special escrow.

Finality is therefore not a philosophical idea. It is a commercial product produced by clean records, predictable process and credible service transition. ARIN can increase that product's supply by making recognition questions narrower and more observable. It can reduce supply by allowing process uncertainty to remain opaque. The market will price the difference.

Service dependencies turn administrative status into customer exposure

The customer normally never hears the words "ARIN transfer request". That does not mean the customer is insulated from registry-layer risk. Address resources sit under services that customers do notice: email deliverability, VPN access, firewall allowlists, geolocation, security monitoring, incident response, logging, authentication systems, content delivery, cloud migration and network reputation. Registry services are not the only cause of those outcomes, but they supply reference points that many systems use.

Reverse DNS is a simple example. ARIN's reverse-DNS materials describe PTR records, in-addr.arpa for IPv4, ip6.arpa for IPv6, spam and phishing screening, troubleshooting, logging and name-to-address relationships. In commercial terms, reverse DNS is part of reputation and operability. A hosting company migrating customers after an acquisition cannot treat PTR delegation as an afterthought. A security vendor with customer-facing mail or scanning infrastructure may need reverse DNS to remain coherent during and after closing. A managed-services provider may have customers whose allowlists, SIEM rules or incident-response processes assume specific naming patterns.

RDAP and Whois are another dependency. They provide public registration information, related entities, contacts, registration dates, last-changed dates, POC roles and unvalidated-contact signals. Diligence teams use them. Abuse desks use them. Counterparties use them. Customers and researchers use them. A stale RDAP or Whois record may not break routing, but it can reduce confidence, delay abuse handling, complicate regulatory responses or raise questions during a financing or sale.

RPKI adds a sharper security dimension. ARIN describes RPKI as a way for legitimate resource holders to obtain certificates and make cryptographically signed statements about which ASNs should originate prefixes, allowing operators to compare BGP announcements with RPKI validity data. That service is increasingly relevant to route-origin assurance. It is not the whole routing system, but it has become part of responsible operation for many networks. A transfer that fails to cleanly delete, edit or recreate ROAs can create operational confusion. A buyer that cannot immediately access the needed service because of agreement status must plan around that gap.

Routing-registry entries create a related practical problem. Many networks still consult routing registries for filtering and operational coordination. Stale entries can cause confusion about who may announce a prefix, especially during a handover. ARIN's transfer guide explicitly tells source organisations to update or remove routing-registry entries that no longer apply after transfer. That advice is a recognition that service state must move with registry state.

The service layer changes who is exposed. If registry status changes tomorrow, the first visible harm may not fall on the board or the address broker. It may fall on a customer whose mail is rejected, a security team whose route-origin validation fails, a SaaS platform whose allowlists need emergency update, a government agency whose vendor cannot explain a record change, or a lender whose collateral file no longer matches the public registration state. The further downstream the customer sits, the less likely it is to understand the cause.

That is why service-dependency risk should be part of board-level diligence. A director approving an address-heavy acquisition should ask not only whether the blocks are listed on a schedule, but whether the registry-linked services have a transition plan. Who owns the ARIN account workstream? Who has POC authority? Are fees current? Are reverse-DNS delegations mapped? Are ROAs listed and staged for change? Are routing records inventoried? Does the buyer need an RSA before using services? Are legacy resources outside agreement, and if so, what security-service limitations matter? Which customer contracts promise continuity that could be affected by delay?

These questions may sound technical. They are economic. They decide whether a scarce address resource can remain useful under stress.

Liability sits in the wrong place

Registry-layer risk becomes more serious when control and liability are not aligned. ARIN can affect recognition, service access, transfer timing and record state. The downstream economic exposure can sit with holders, buyers, sellers, customers, lenders, brokers and network operators. The registry's contractual liability, like that of other RIRs, is narrow compared with the commercial value that may depend on the registry layer. That mismatch is not a claim that ARIN is uniquely irresponsible. It is a structural feature of the current system.

The mismatch is easiest to see in a failed or delayed transaction. Suppose a buyer signs for an address-heavy business, but registry recognition is delayed because a predecessor entity cannot be tied cleanly to the current holder. Customers remain live, but the buyer cannot treat the resources as cleanly settled. The seller says the delay is administrative. The buyer says the seller failed to deliver. The lender asks whether the address capacity can support the acquisition model. ARIN may be acting carefully to protect the record. The cost of that caution falls on the parties.

Or suppose a reverse-DNS or RPKI transition is mishandled. The source has old ROAs or routing records; the recipient lacks immediate access; customers experience operational friction. ARIN's transfer materials place responsibility on source and recipient organisations to handle a clean transition. That allocation is understandable. The registry cannot run every customer's network. But it also shows the liability structure: registry services are essential reference points, while the practical continuity burden rests heavily on operators.

The same pattern appears with agreement status. If a legacy holder outside an ARIN agreement cannot use ARIN-hosted RPKI or routing-registry services, and a buyer or customer now expects those services, the holder bears the cost of entering the agreement perimeter or finding another operational path. If the agreement terms or fees change, the holder may have limited exit options because the record and services are tied to a monopoly-like registry function. The registry's legal exposure is limited; the holder's business exposure may be substantial.

Markets respond to this mismatch by private risk allocation. Warranties become more detailed. Escrows become longer. Holdbacks appear. Brokers charge process premiums. Buyers demand indemnities for registry rejection. Sellers demand caps on registry-facing obligations. Insurers exclude or narrow coverage for title-like uncertainties around number resources. Lenders discount address value unless control, transferability and registry status are clean. Large acquirers build internal registry teams. Small operators pay intermediaries.

The deeper issue is institutional. A registry's legitimacy is strongest when the questions it asks are tied tightly to the harm it can prevent. If ARIN asks for proof of authority, the prevented harm is clear: unauthorised transfer. If it requires current contacts, the prevented harm is clear: stale record and operational unreachability. If it coordinates reverse-DNS and RPKI transition expectations, the prevented harm is clear: service confusion. If it extends review into business-plan evaluation or broad policy discretion, the harm prevented must be shown more carefully because the registry is imposing costs it does not fully bear.

That is why liability mismatch should discipline registry power. The narrower the remedy available to parties affected by registry action or delay, the narrower the registry's discretionary field should be. A low-liability registry can be legitimate if it performs a narrow, auditable coordination function. It becomes harder to justify if it exercises broad market-shaping discretion while externalising most downside.

For ARIN, the constructive answer is not to pretend every registry decision can carry full market liability. That would be unrealistic and might make the registry unable to operate. The answer is to reduce the surface on which high-value commercial outcomes depend on discretionary interpretation. Make the record questions clearer. Make process timing more visible. Make service boundaries explicit. Make dispute status legible. Make the rationale for market-affecting policy conditions measurable. When liability cannot expand, discretion should contract.

How the market prices the registry layer

Registry-layer risk is priced in quiet instruments rather than a single line item. It appears in the warranty schedule of an acquisition agreement. It appears in the premium charged by a broker who knows how to move a difficult block. It appears in escrow instructions, lender haircuts, closing conditions, customer migration budgets and management presentations. It appears in the buyer's decision to prefer an entire corporate acquisition over a standalone transfer because the M&A path better fits ARIN's recognition mechanics. It appears in the seller's decision to clean up Org IDs and POCs before going to market.

Warranties are the first price signal. A seller may represent that it is the current recognised holder; that no dispute exists; that fees are current; that no prior transfer, pledge, lease or customer arrangement conflicts with the sale; that all contacts are accurate; that it has authority to request the change; that resources are not from a reserved pool; that it will cooperate with ARIN; and that no undisclosed registry correspondence threatens status. The more uncertain the record, the more detailed the warranty.

Escrow is the second signal. If registry recognition occurs after signing, money may be held until ARIN updates the record. If service transition remains open, a portion may be held until reverse DNS, ROAs and routing records are clean. If a dispute exists, escrow may hold funds until resolution or exclude the affected block. Escrow turns registry timing into cash timing.

Closing conditions are the third signal. Buyers may require ARIN approval before closing, or at least evidence that both parties have submitted requests and no obvious objection has been raised. Lenders may require clean registry evidence before funding. Strategic buyers may make customer migration plans contingent on registry milestones. A closing condition is an economic admission: private agreement is not enough.

Price discounts are the fourth signal. A clean /20 with current records, validated contacts, no dispute, clear agreement status, documented corporate history and staged service transition is not equivalent to a /20 buried inside a dissolved predecessor with stale contacts and uncertain legacy status. The route table may treat the two blocks similarly. The market will not.

Broker premiums are the fifth signal. Intermediaries are paid not merely for matching supply and demand, but for reducing uncertainty around source quality, documentation, registry process, counterparty behaviour and service transition. A thin broker can introduce parties. A stronger execution adviser can help structure finality, identify record problems, stage technical handover and allocate risk. The premium reflects the difficulty of the registry layer.

Insurance and financing terms are the sixth signal. An insurer may be reluctant to cover registry refusal or unclear address status. A lender may give limited credit to address value unless transferability is clean. A financing model may discount IPv4 capacity if it depends on an agreement step, a disputed legacy chain or a service limitation. The registry layer therefore influences cost of capital even without setting a price.

Customer migration budgets are the seventh signal. A buyer may set aside resources for renumbering, dual operation, allowlist updates, mail reputation repair, reverse-DNS work, RPKI transition, abuse-contact updates and customer notice. Some of those costs are not caused by ARIN; many are network realities. But registry state is one reason they must be planned. The market pays for what it cannot assume.

Small-operator disadvantage is the eighth signal. A large cloud platform or telecom group can hire counsel, pay brokers, maintain internal registry expertise, manage ARIN Online accounts, prepare utilisation documentation, stage RPKI changes and absorb delay. A regional hosting provider or small ISP may face the same process with fewer people and less bargaining power. Fixed registry costs and fixed diligence costs are regressive. They consume a larger share of a small transaction and give sellers reason to prefer larger counterparties.

These price signals should matter to ARIN because they are feedback. A registry that lowers uncertainty increases the value of the resources it records. A registry that leaves too much uncertainty around recognition, services or process forces the market to buy private protection. The invoice may not come from ARIN, but ARIN's layer helped create it.

A narrow institutional test would strengthen ARIN

The constructive test for ARIN is not whether every market participant likes every policy. It is whether the registry can explain which questions protect uniqueness, authority, record accuracy and service continuity, and which questions merely carry allocation-era discretion into a market era. That distinction would make ARIN stronger, not weaker.

Some questions are plainly registry questions. Is the source the current registered holder? Does the source organisation still exist? If not, is there a documented succession path? Does the person submitting the request have authority through an Admin or Tech POC or officer acknowledgement? Is there a dispute over status? Are the resources eligible for the requested transfer path? Are reverse-DNS delegations, ROAs and routing records being handled in a way that avoids misleading the operational community? Are RDAP and Whois records current enough to support contactability and accountability? These questions protect the record and the services that depend on it.

Some questions are mixed. Agreement status is necessary for service delivery and legal clarity, but it can also create leverage. Fee standing is necessary for operating the registry, but non-payment consequences can affect high-value resources. Inter-RIR compatibility can protect policy coherence, but it can also create borders around a technically global resource. Needs-based recipient review can prevent certain forms of hoarding or sham demand, but it can also suppress legitimate forward capacity planning and turn a market purchase into an administrative rationing exercise. Mixed questions require evidence and proportionality.

Some questions should be treated with suspicion. Does the registry need to judge the buyer's business strategy beyond concrete transfer-recipient requirements? Should capital movement be limited because the old allocation vocabulary distrusts reserve capacity? Should a legacy holder be pressured into a broader contract because a routing-security service has become operationally expected? Should a policy process made up of active participants be treated as consent by every customer, investor and downstream network exposed to the result? These are not impossible questions, but they should not be hidden inside the language of routine administration.

ARIN can reduce risk by making more of the process observable in aggregate. It could publish clearer data on transfer processing times, documentation rounds, reasons for delay or abandonment, dispute-related pauses, inter-RIR bottlenecks, recipient qualification outcomes and service-transition issues. It need not disclose private prices or confidential business plans. Aggregate friction data would help the market price risk more accurately and would let ARIN defend rules with evidence rather than inherited vocabulary.

It can also improve pre-closing certainty. Clearer pre-transfer status signals would help buyers distinguish record problems from ordinary process. A resource-state report, even if limited, could identify agreement status, validated contacts, dispute posture, reverse-DNS delegation status, routing-security eligibility and transfer-path issues. The goal would not be to guarantee every transaction. It would be to reduce surprise.

It can narrow needs review where the free pool is not the source of supply. A market transfer between willing parties is different from a request for scarce residual registry inventory. The buyer's willingness to pay is not a perfect measure of operational need, but it is a stronger economic signal than allocation-era policy often admits. If ARIN keeps needs-based review central to transfers, it should explain the concrete harms prevented and the cost imposed on liquidity. If the harms are real, the evidence will strengthen the rule. If not, the market should not pay for inherited rationing logic.

It can make legacy service boundaries candid. If ARIN believes RPKI and routing-registry access must require agreement, it should say why in operational and legal terms, and it should keep reassessing the boundary as those services become more important to ordinary network operation. A boundary that was tolerable when optional can become coercive when industry norms change. Mature institutions notice when optional services become practical necessities.

The principle is modest: the registry should be strict where the record is threatened and restrained where the market is better placed to decide. That is not anti-ARIN. It is the standard that makes a high-value registry sustainable.

The operating question belongs in the boardroom

Registry-layer risk is no longer a specialist concern for policy mailing lists or address brokers. It belongs in board packs, lender diligence, M&A checklists, customer-continuity plans and cloud-capacity strategy. The reason is simple: IPv4 addresses now support revenue, customer promises and asset valuations, while registry status can affect whether those promises are durable.

Boards should ask what part of the company's customer base depends on ARIN-registered IPv4 resources, and whether the company understands the registry state behind them. Are the resources under the right organisation? Are contacts current? Are fees paid? Are legacy resources under or outside agreement? Are RPKI and routing-record services available where needed? Are reverse-DNS delegations documented? Are leases, customer assignments and internal inventories consistent with public records? Is there any unresolved dispute, old corporate chain or dormant predecessor that could complicate a sale?

Acquirers should ask how the address layer would close if the rest of the deal closed tomorrow. Which resources move under M&A treatment? Which require specified-recipient transfer treatment? Which are not moving but must continue to support customers? Which have service dependencies that must be staged? Which warranties and holdbacks reflect registry finality? Which customer contracts would be exposed if recognition were delayed?

Resource holders should ask whether they can prove their own story. A legacy holder with old space should not wait until a sale to reconstruct corporate history. A hosting company should not wait until acquisition diligence to clean POCs. A cloud or security provider should not wait until a transfer to inventory ROAs, routing records and reverse-DNS zones. A small ISP should not wait until an emergency to learn which ARIN account controls its public record.

ARIN should ask the same question from the other side. If a registry action or delay can affect customer continuity, market settlement and asset valuation, which parts of the process are narrow enough to justify that effect? Which parts protect uniqueness, authority, accuracy, dispute integrity and service continuity? Which parts extend historical allocation discretion into a market that now prices IPv4 as operational capital? Which costs can ARIN measure, publish and reduce?

The answer will not come from pretending that registry risk is merely paperwork. It will come from treating the registry layer as market infrastructure. That infrastructure should be accurate, restrained, auditable and boring in the best sense. It should make the public record more reliable than private rumour. It should make fraud harder and settlement easier. It should let service transitions happen without turning customers into collateral. It should keep policy conditions close to the harms they prevent.

ARIN's strongest legitimacy lies there. Not in denying that IPv4 has asset reality. Not in repeating allocation-era vocabulary as if scarcity had not changed the economics. Not in expanding the registry's discretion because the registry is useful. Its strongest claim is that North America needs a reliable record and coherent registry services for resources already embedded in networks, contracts, customers and balance sheets.

The final operating question is blunt. If ARIN status changed tomorrow - a contact lost authority, a transfer paused, an agreement boundary mattered, a dispute marker appeared, a reverse-DNS delegation failed, a ROA could not be updated, a fee issue blocked action - which customer commitments, contracts, security assertions and asset valuations would be exposed?

Any board, acquirer or resource holder that cannot answer that question has not yet priced the registry layer. Any registry that wants durable legitimacy should want the answer to be easier, narrower and less expensive than it is today.