Summary
- A registry entry is not created by one universal agreement. Global policy and the IANA Numbering Services SLA govern service delivery between ICANN and the five RIRs; they do not make a holder or end user a party.
- The direct holder relationship varies by registry. RIPE NCC uses a membership service agreement, APNIC a corporate membership agreement, ARIN a registration services agreement, AFRINIC a Mauritius-law RSA, and LACNIC requires approved recipients to execute its own service documentation.
- National registry, sponsoring-LIR, customer and end-user contracts can add further layers. Their parties and remedies cannot be inferred from the public record alone.
- Routing gives the record practical effect but is not automatic contractual performance. Networks independently announce and accept routes; RPKI, reverse DNS and directory data can support reliance without proving ownership or binding every operator to the same contract.
Start with one line, then ask who promised what
Imagine a public registry record for one block of Internet addresses. It identifies a registered organisation, a range, contacts, status and perhaps related routing-security or reverse-DNS information. To a reader, the record appears to be one institutional statement: this resource is associated with this holder in this registry.
That visual unity conceals a layered structure. The pool from which the block came may have been supplied to a Regional Internet Registry through the global numbering system. The RIR may have approved a request under policy. A company may have signed a registration or membership agreement. A national registry or sponsoring provider may sit between the RIR and the operational user. A customer contract may authorise a network to use addresses without making the customer the direct registered holder. Routers then decide whether announcements are propagated and accepted.
Each layer answers a different question. The global layer asks whether IANA numbering services were delivered to an RIR according to agreed procedures and performance standards. The regional corporate layer asks how the RIR validly adopts policy and authorises staff. The holder contract asks what services the registry provides, what the account holder must do and what happens when the relationship ends. The downstream layer asks who may use, assign, sub-assign or manage the resource. The routing layer asks what networks will actually carry.
The layers reinforce one another, but they are not one contract. The parties differ. The governing laws differ. The remedies differ. A service-level breach between ICANN and the RIR is not automatically a claim by an end user. A holder's breach of an RSA does not by itself bind every routing operator. A customer may depend on addresses while lacking contractual standing against the RIR.
This article traces a hypothetical entry rather than inventing facts about a real holder. The method is to stop at every institutional handoff and ask five questions: who are the parties; what instrument applies; what service or right is described; what remedy exists; and who remains outside the agreement?
Layer one: global policy and IANA service delivery
The highest contractual layer in the present system is the Service Level Agreement for the IANA Numbering Services. ICANN and the five RIRs signed it on 29 June 2016. It became effective with the stewardship transition on 30 September 2016. Amendment 1, dated 12 November 2024, added reverse-resolution services to its covered work.
The SLA matters because it replaced an easily misunderstood idea of informal global stewardship with a written operational relationship. It identifies parties, services, performance expectations, reporting, escalation and dispute mechanisms. It makes the delivery of numbering services reviewable between institutions rather than resting only on custom.
Its scope is also a hard limit. The agreement is between ICANN and the five RIRs. The ordinary resource holder is not listed as a contracting party. A downstream ISP customer is not a party. A person whose traffic uses the addresses is not a party. The SLA does not transfer ownership of a particular block to an end user, nor does it supply the complete terms governing one public holder record.
That distinction prevents a common leap. It is tempting to reason that because IANA supplies number pools to RIRs under a global agreement, every later registry decision carries the authority of that agreement. The text does not support that conclusion. The SLA makes RIR-facing services contractual. It does not turn an RIR's holder agreement into an ICANN contract or give ICANN the role of direct counterparty to every holder.
Global policy and service delivery are related but not identical. Policy determines the conditions under which number pools move at the global level. The SLA governs how the IANA operator delivers agreed services. A request can therefore have a policy basis while performance failures are handled through contractual service mechanisms.
For the hypothetical record, this layer explains how a pool became available to the relevant RIR. It does not yet explain why a particular organisation appears in the public record, which contract version governs that organisation, or whether an operational customer has rights against anyone above it.
The five RIRs are joint parties above, different institutions below
At the SLA layer, the five RIRs appear together as counterparties to ICANN. Below that layer, they separate into distinct legal persons. Their service regions form a coordinated global system, but their corporate forms, agreements, policies and governing-law clauses are not interchangeable.
This is the first reason not to speak of "the RIR contract" as though a universal form exists. A RIPE NCC member contracts with a Dutch association. An APNIC member contracts with an Australian company. An ARIN holder signs a registration-services form under ARIN's stated terms. An AFRINIC resource member contracts with a Mauritian company. LACNIC uses its own service documentation.
The distinction has practical effects. A member may possess voting rights in one institutional model that are not identical to the rights of a registration customer elsewhere. Liability caps and dispute forums vary. Termination language varies. Incorporation of current policies varies. Legacy and non-member relationships may use additional forms.
Coordination does not erase those differences. The RIRs can receive global services under one SLA and maintain compatible registry data while preserving separate holder contracts. A globally unique number can therefore be supported by institutional cooperation at one layer and domestic private law at another.
This layered settlement is neither inherently illegitimate nor inherently complete. It is a practical way to coordinate a global ledger without one worldwide membership contract. Its weakness appears when rhetoric collapses the layers and implies that global coordination itself proves every regional power. Its strength appears when each institution can identify the precise instrument authorising a precise act.
For a record audit, the regional label is not enough. One must identify the legal registry, the applicable account type, the agreement version, the policy snapshot and any intermediary. Without those details, the public record indicates administrative recognition but not the complete contract stack.
Layer two at RIPE NCC: membership and services in one agreement
The RIPE NCC Standard Service Agreement, RIPE-812, dated November 2023, shows one way to connect corporate membership and registry service. It identifies the RIPE NCC as a Dutch association, defines the member relationship, describes services, incorporates policies and procedures, states member duties, allocates liability, and addresses termination and cooperation with deregistration.
This agreement is much closer to the hypothetical registry entry than the IANA SLA. It can explain why the RIPE NCC provides services to a direct member, what the member promises, and how current policy documents enter the relationship. If a dispute concerns non-payment, information duties, closure or termination, this is a natural place to begin.
Yet it is still not the whole record. The agreement covers RIPE NCC members under its scope. It does not prove that every independent end user is a direct member. A sponsoring LIR may hold the direct contractual relationship while an end user receives an assignment or related service through another instrument. Legacy-resource relationships may follow different documentation. The date on the public form does not prove which version a specific holder accepted years earlier.
The agreement also illustrates why corporate and service authority must be separated even when they appear in one document system. Membership can give corporate rights. The service terms can impose operational duties. Incorporated policies can change the rules applied to requests and records. A General Meeting decision, a management service decision and a policy outcome may all affect the member, but they arise through different institutional acts.
If the hypothetical record belonged in the RIPE NCC region, a competent audit would retrieve the signed or accepted agreement, determine its effective version, list incorporated documents on the relevant date, identify any sponsoring relationship, and separate membership termination from resource-record consequences. The current standard form is evidence of the model, not evidence of one holder's complete history.
The limit is important for third parties. A customer using addresses supplied by a member may rely heavily on continuity, but reliance does not automatically make the customer a party to RIPE-812. The customer may need to look to its contract with the member unless another instrument grants direct rights.
APNIC: corporate membership with regional variation underneath
The Standard APNIC Membership Agreement, APNIC-079, version 002 dated 9 February 2012, offers a different architecture. It identifies APNIC Pty Ltd, refers to APNIC's special committee, establishes annual renewal, addresses resource services, incorporates APNIC Documents, limits liability and provides for Queensland law.
Like the RIPE agreement, it turns institutional participation into a bilateral legal relationship. The member is not simply part of an atmospheric regional community. It contracts with a named company. The agreement can require compliance with incorporated documents and define consequences within the relationship.
The Australian corporate setting matters because the agreement cannot be read as a treaty for the Asia Pacific. It is a private agreement supported by the company's constitution, Australian law and the accepted APNIC document system. Its geographic reach may be large, but the legal counterparty remains specific.
APNIC also demonstrates why the direct-RIR model cannot be universalised. National Internet Registries operate in parts of the region. Non-member arrangements and downstream assignments may use other instruments. A public record associated with a national registry may therefore have an extra contractual handoff between APNIC and the operational holder.
For the hypothetical entry, seeing APNIC in the chain would not answer whether the holder signed APNIC-079 directly, contracted through an NIR, or obtained use through a provider. It would not establish which annual renewal terms or document versions apply. It would not show the rights of customers using services built on the range.
The proper finding is bounded. APNIC-079 proves that one important class of APNIC relationship is contractual, renewable and connected to incorporated policy documents under a stated legal framework. It does not prove that all records in the region share one privity chain.
This variation is not administrative noise. It determines notice, remedy and standing. If an operational user disputes a change, the first question is whether it can claim directly against APNIC, must proceed against an NIR, or must rely on its provider contract. A public database line alone cannot answer that question.
ARIN's RSA puts registration rights at the centre
The ARIN Registration Services Agreement, version 14.0, dated 15 August 2025, is especially useful for understanding the difference between a number and the registry relationship around it. The agreement defines Included Number Resources in terms of registration rights, separates ARIN's services from the number itself, states holder duties and ARIN remedies, and includes governing-law and dispute provisions.
That drafting helps locate the legal entity. The agreement is not a sale contract from ICANN through ARIN to a holder. It is an agreement about registration services and recognised rights within ARIN's system. The public entry is therefore connected to a contractual service relationship without requiring the conclusion that ARIN owns the addresses or transfers a physical entity.
This distinction matters when people use the language of ownership too casually. The holder may have economically important, transferable and operationally embedded interests. ARIN may have contractual powers concerning records and services. Routing operators may rely on the registration. Those propositions can coexist without every legal system classifying the address block identically.
Versioning matters sharply. RSA 14.0 is current evidence for the 2025 form, but a legacy record may have no current RSA, may be covered by a Legacy RSA, or may remain connected to an earlier agreement. Old RSA versions can continue to matter. The correct contract cannot be selected merely because the latest PDF is easy to find.
For the hypothetical entry, an ARIN audit would need the agreement status shown for the holder, execution date, version, any legacy form, transfer history and policies incorporated at decisive moments. It would then distinguish the holder's registration rights from a customer's right to use addresses under a separate service contract.
ARIN's clarity about registration rights is valuable, but it does not answer the routing question. An RSA can establish duties between ARIN and the holder. It cannot command every autonomous system to accept the holder's routes. Practical effect still depends on technical publication, operator decisions and wider trust in the registry record.
AFRINIC's RSA connects membership, policy and high-impact remedies
The AFRINIC Registration Service Agreement, dated 27 November 2017, identifies African Network Information Centre Ltd as the Mauritian counterparty. It connects resource membership, registry services, policy compliance, insolvency, revocation, liability and dispute terms.
This is a dense layer because the agreement links a direct relationship to policies and to potential consequences for resources and services. It is therefore central to any claim that AFRINIC may require information, enforce obligations or end a relationship. Broad statements about regional responsibility are not enough; the relevant RSA clause and incorporated policy must be identified.
The RSA's recitals and institutional descriptions are still statements made within an agreement. They can bind or inform the parties according to applicable law, but they do not prove a sovereign delegation from every state or network in Africa. The legal effect depends on the holder, facts, applicable Mauritius law and later court orders.
Downstream users are again a key boundary. A customer that receives connectivity from an AFRINIC resource member is not automatically a party to the RSA. It may suffer if the member's registry relationship changes, yet its claim may lie against the provider under a customer agreement. This separation between dependency and privity is one of the contract stack's most important risks.
The AFRINIC example also shows why remedies must be proportionate to layers. Terminating a bilateral agreement, ending membership, changing a registry record and affecting live routing are distinct consequences. A contract may connect them, but an analyst should not narrate them as one administrative click. Each effect may require a condition, notice, decision and review route.
For one hypothetical entry, the audit would ask whether the direct holder signed the 2017 form or another version, which policies applied, whether the holder was solvent and in good standing, who operated the network, and which customers depended on continued recognition. It would not infer any of those facts from the public line alone.
LACNIC proves the contract exists, while exact terms still need capture
LACNIC's registration documents page confirms that approved recipients of IP addresses or autonomous system numbers sign a LACNIC service agreement. The page also locates related documentation, including confidentiality and bulk-Whois instruments.
This establishes the existence of a contractual holder layer. It is enough to reject the idea that a LACNIC record rests solely on informal regional consensus. A named recipient enters a service relationship after approval.
It is not enough for exact clause analysis. The embedded Spanish contract must be downloaded, preserved, dated and versioned before making claims about duties, liability, termination, governing law or amendment. A landing page can identify the document family without exposing the complete operative text in a stable analytical form.
This evidentiary limit illustrates a broader rule: document locators are not substitutes for instruments. A current web page may change. An embedded PDF may be replaced at the same link. Translations may differ. An audit should store the version that governed the transaction, its hash, signature date and language priority.
For the hypothetical LACNIC entry, the public record and document page would identify the likely contractual route, but not prove the exact agreement accepted by that holder. Any further claim should be conditional until the executed or applicable form is captured.
That may sound procedural, but it affects rights. A dispute can turn on one notice period, liability clause or definition. General descriptions of LACNIC's role cannot supply missing words. The contract stack is only as reliable as its version history.
Layer three: national registries and sponsoring providers
The direct RIR-holder relationship is not always direct. In some regions, a National Internet Registry can receive and administer resources within the larger regional system. In others, a sponsoring LIR can maintain a relationship for an independent end user. These arrangements add a layer between the RIR and the entity whose network uses the resource.
This intermediary can perform useful functions. It may provide local language, billing, documentation, technical support and knowledge of domestic operations. It can reduce the cost of dealing with a distant regional institution. It can also make privity harder to see.
Suppose the hypothetical record names an end-user organisation but a sponsoring provider holds the direct service relationship. The end user may have an agreement with the sponsor. The sponsor has an agreement with the RIR. The public record may identify contacts for both. If the sponsor fails to pay or closes, the end user's operational dependence does not automatically create direct contract rights against the RIR.
The reverse problem also occurs. A registry may need the end user to cooperate with documentation or transfer, even though the sponsor is its direct member. Policies can create procedural expectations, but contractual enforcement must still identify who promised what.
National registry arrangements can add domestic law and their own membership rules. A holder may therefore sit beneath global policy, the IANA SLA, the regional registry's corporate rules, an RIR-NIR arrangement and a local service contract. Calling all of this "community policy" hides the agreements that allocate actual duties.
The available evidence does not provide a global count of records by direct RIR contract, NIR contract, sponsoring relationship, legacy status or downstream arrangement. That missing denominator limits systemic claims. One cannot responsibly say that most records follow a particular stack without a cross-registry inventory.
A better public registry would disclose relationship type without exposing confidential terms: direct member, national-registry recipient, sponsored end user, legacy holder or downstream assignment. That label would help users understand where the operative contract sits and which institution should receive a correction request.
Layer four: operator and customer contracts
The address range often creates value below the registered holder. A hosting company assigns addresses to customers. An ISP uses them for subscribers. A cloud provider allocates them to services. A leasing arrangement permits another operator to announce them. A managed-network contract gives a third party operational control.
These downstream agreements can be economically more important to the user than the RIR contract. The customer pays for connectivity, uptime, abuse handling, portability or dedicated addresses. It may never interact with the RIR and may not know which RSA applies.
The public record rarely reveals the full customer chain. That is appropriate; registries should not publish every commercial contract. But governance analysis must acknowledge the unseen reliance. A change at the holder layer can affect parties with no vote in the RIR and no standing under its agreement.
This is why notice and continuity protections matter. A direct holder's breach may justify action within the contract. The consequences should still be designed with downstream reliance in mind. Where possible, the system should distinguish account suspension, service termination, record status and routing-security effects rather than converting one bilateral dispute into immediate harm for unrelated customers.
The downstream contract also determines who bears risk. A provider may promise stable addresses while reserving a right to renumber. A lessee may warrant compliance with registry policy. A customer may have indemnities or service credits. None of those terms binds ICANN or the RIR unless another legal route creates that effect.
For the hypothetical entry, a complete map would list the direct registered holder, operational announcer, infrastructure manager and affected customer classes. It would then identify contracts connecting them. The registry entry alone cannot establish that chain, but the chain explains the record's real impact.
Layer five: routing is coordinated action, not contract execution
A registry entry does not make packets move. Border Gateway Protocol announcements and operator routing policies do. An autonomous system originates a route; other networks decide whether to propagate and accept it. Filters, commercial relationships, route objects, RPKI validation and operational judgment influence the result.
The registry record matters because it supplies trusted information. It can support contact, transfer, reverse DNS and routing-security systems. Operators may use it when building filters or assessing authority. Shared reliance gives the line practical force beyond the parties to one contract.
But reliance is not universal contractual privity. An operator that accepts a route is not thereby signing the holder's RSA. A network can accept a technically valid announcement despite a registry dispute, or reject an announcement despite a current record. Routing policy remains distributed.
This gap is a source of resilience and uncertainty. It is resilient because no registry directly operates every router. A mistaken administrative action does not necessarily stop traffic instantly. It is uncertain because registry, RPKI and routing realities can diverge, leaving counterparties to decide which signal to trust.
RPKI narrows some ambiguity by allowing cryptographic statements about authorised route origins. Reverse DNS provides another delegated service. Internet Routing Registry entities provide operational assertions. Yet each has its own authority chain and lifecycle. Ending one contract layer may affect certificates or entities, but the result must be traced rather than assumed.
The evidence available here does not show how RPKI certificates, IRR objects, reverse DNS and routing acceptance respond across all registries when a holder contract ends. That is an important missing study. It should follow dated examples and separate administrative status from observed routing.
For the hypothetical entry, the final line of the stack is not a contract at all. It is a field of network decisions. The legal chain can make an announcement easier to recognise, but it cannot turn distributed routing into performance by one institutional party.
Privity explains who can sue, not everyone who can be harmed
Contract law begins with parties. The IANA SLA gives rights and duties to ICANN and the RIRs. A holder agreement gives rights and duties to the RIR and holder. A sponsor agreement may bind sponsor and end user. A customer contract binds provider and customer. The exact law may recognise third-party rights in limited circumstances, but those rights cannot be presumed.
Operational dependence is wider than privity. A customer can lose service without being party to the RSA. A relying network can suffer uncertainty without being party to the IANA SLA. A government can face communications consequences without having signed any registry agreement.
This mismatch is one reason registry governance attracts public concern despite private legal forms. A private contract can have external effects because the record is widely trusted. The response should not be to pretend the contract is public law. It should be to design notice, review, continuity and transparency proportionate to the foreseeable reliance.
Third-party effect must still be analysed cautiously. Wide reliance does not mean every observer has a legal claim. Nor does lack of privity mean the registry owes no duty under any other body of law. Tort, competition, statutory, judicial or equitable doctrines may matter depending on jurisdiction and facts. Those questions require case law not available in the present evidence.
A complete study would therefore pair contract mapping with court and arbitral decisions. It would ask whether downstream users obtained interim protection, whether routing reliance influenced remedies, and how tribunals treated legacy or sponsored relationships.
Until that record exists, the safe finding is structural: the parties with the greatest operational exposure may sit several contracts below the institution whose record they rely on. The stack coordinates them, but it does not automatically give them equal standing.
Incorporated policy is a bridge, not a freestanding contract
RIR agreements frequently incorporate policies or other published documents. This allows the relationship to evolve without renegotiating every operational detail. Registry work would be impractical if every request procedure required a new bilateral signature.
Incorporation also creates a bridge between collective process and individual contract. A policy developed through the applicable regional procedure may become relevant to a holder because the agreement says current policies govern services. The binding path is therefore not simply "the community decided." It is corporate adoption, policy procedure, contractual incorporation and application to facts.
That path should be traceable. The analyst needs the agreement clause, the policy version, effective date, notice and transition terms. A current manual cannot automatically prove what governed a transaction five years earlier.
The bridge has limits. A policy cannot necessarily alter every negotiated right merely because it is called policy. Whether dynamic incorporation is effective, and how far it reaches, depends on agreement language and applicable law. That unilateral-amendment problem deserves its own analysis; here the narrower point is that policy and contract are separate links.
This separation improves accountability. If the dispute concerns the wisdom of a policy, the policy forum may be relevant. If it concerns valid incorporation, the contract matters. If it concerns staff application, operational review matters. If it concerns corporate competence, bylaws and host law matter.
Collapsing those questions into one claim of mandate makes remedies harder to find. Mapping the stack routes each disagreement to the institution and instrument capable of answering it.
Legacy records resist the neat stack
Not every registry entry began with a modern RIR agreement. Some resources predate current institutions or standard forms. Records may have been migrated, maintained under legacy services, transferred later, or brought under a legacy agreement voluntarily.
This history matters because the public appearance of two records can be similar while their contractual foundations differ. One holder may have signed the latest RSA. Another may have an older form. A third may have no current standard agreement but still receive limited registry maintenance.
The ARIN RSA explicitly raises the issue through separate legacy arrangements and persistent old versions. RIPE NCC and other regions also encounter historical relationships that do not fit a simple new-member model. The hypothetical trace must therefore begin with provenance, not assumption.
Legacy status does not mean no rules apply. Host law, policies, transfer conditions, accepted services and later contracts may all matter. It means the applicable chain must be proved. A modern website form cannot be retroactively assigned to an old record without evidence.
This creates practical governance risk. If a registry describes all records as though one current agreement governs them, holders cannot predict rights and third parties cannot evaluate status. If it treats legacy records as beyond any standards, data quality and security can suffer.
The better approach is explicit classification, version history and proportionate service terms. The record should reveal enough status to identify the relationship while preserving confidential documents. Disputes should focus on the instrument actually accepted, not a general theory of registry authority.
What termination at one layer does not automatically prove
If the IANA SLA were breached or terminated, that would be serious for institutional service delivery. It would not automatically decide ownership of every downstream resource or terminate every holder agreement. Continuity arrangements and other legal acts would be needed.
If an RIR terminates a holder agreement, that may end specified services and trigger stated record consequences. It does not automatically terminate every downstream customer contract, although the provider may become unable to perform it. Nor does it directly command routers to withdraw announcements.
If a sponsoring agreement ends, the end user may need a new sponsor or direct relationship. The correct outcome depends on policy and contract. Immediate loss of the underlying operational position is not logically necessary unless the instruments make it so.
If a customer contract ends, the direct holder may remain unchanged in the registry. The addresses can be reassigned within the holder's network or returned according to downstream terms. The public record may never have named the customer.
These distinctions are the practical value of the stack. They prevent one dispute from being described as the collapse of every relationship. They also reveal where continuity rules are missing. A well-designed system states which layers survive, which must be transferred, and how dependent parties receive notice.
The same logic applies to remedies. A service credit under a customer contract is not a remedy for a registry error. An RIR arbitration route may not hear a dispute under the IANA SLA. An SLA escalation does not compensate an end user. Each remedy belongs to its parties unless law extends it.
The missing denominator is relationship type
The five RIR systems publish large quantities of statistics, but the evidence here does not establish a global denominator for contract status. How many records are held under current direct agreements? How many use legacy forms? How many pass through NIRs or sponsors? How many support downstream customers with no direct registry standing?
Without that inventory, examples can illustrate architecture but not prevalence. RIPE-812 proves a model, not its share of every relationship. APNIC-079 proves a membership form, not the distribution of NIR and direct holders. ARIN RSA 14.0 proves current drafting, not the number of legacy records outside it.
Publishing aggregate relationship types would improve accountability without exposing commercial details. Each RIR could report counts by direct agreement, legacy agreement, no standard agreement, sponsored end user, national registry and other defined category. It could report transfers between categories and disputes by type.
Those denominators would help assess risk. A system dominated by direct current agreements has different continuity needs from one with many historical or intermediary relationships. It would also make policy consultation more honest by showing which principals are affected by proposed change.
The absence of data should produce caution, not a universal story. No analyst should treat one standard contract as the legal foundation of every record. The correct statement is that the registry is a collection of relationship classes presented through a common data service.
How to audit one real entry
A full audit would begin with the registry record and its change history. It would identify the current RIR, original allocation source, transfers, mergers, name changes, contacts and status. It would preserve dated copies rather than relying on a live page that may later change.
Next it would capture the global instrument and policy applicable when the pool moved to the RIR. The IANA SLA explains current service relations after 2016, but older allocations require historical context. The audit should not apply a 2016 contract to a 1990s event.
At the regional layer, it would retrieve the RIR's constitution, policy manual and delegated authority for the decision. It would then identify the holder agreement actually executed, including version, signature, renewals, amendments and incorporated documents.
If an NIR or sponsor appears, the audit would capture both its agreement with the upper institution and its agreement with the holder. At the downstream layer, it would identify assignment, lease, hosting or customer terms necessary to explain operational use.
Finally, it would compare legal status with technical evidence: origin announcements, RPKI objects, reverse DNS, routing registry entries and observed acceptance. Differences would be recorded rather than forced into one answer.
The result would be a dated relationship map, not an ownership certificate. It would show which institution can change which record, which party can invoke which remedy, who bears operational risk and where evidence is missing.
No such fully documented sample appears in the evidence used for this article. That absence prevents a case-specific conclusion. It also defines the next research task clearly.
A better contract stack would make handoffs visible
The existing system benefits from coordination. One global numbering service, five recognised regional registries and shared data conventions help preserve uniqueness. Standard agreements give direct parties predictable terms. Incorporated policies allow operational evolution.
The system could become more accountable without pretending every layer should merge. First, public records should identify relationship class and governing contract version where disclosure is lawful. Second, each agreement should state clearly which policies are incorporated and how holders are notified of change.
Third, continuity clauses should address intermediary failure. A sponsored end user should know how to move to another sponsor. An NIR disruption should not erase the underlying registration history. A customer should know whether addresses are portable or subject to renumbering.
Fourth, high-impact registry action should separate account, record, security and routing consequences. The institution should identify the precise contractual ground and review route. A dispute at one layer should be isolated where possible rather than propagated downward.
Fifth, technical services should preserve auditable chain of custody. RDAP, reverse DNS, RPKI and registry history need succession plans. The importance of the ledger is a reason to make administrators replaceable, not to imply that one corporate agreement is sovereign.
Finally, aggregated remedy data should be published: terminations, suspensions, record changes, sponsor failures, appeals, reversals and restoration times. Documents show possible authority. Use data show how the stack behaves.
The finding: one record, several limited promises
The public registry entry is singular because uniqueness requires a clear answer. Its institutional foundation is plural. The IANA Numbering Services SLA supports service delivery between ICANN and the five RIRs. It does not contract with every holder. Regional constitutions and policies authorise corporate action. RIR agreements bind defined members or holders under distinct legal systems. NIR, sponsor and customer contracts can add more parties. Routing operators act independently.
This is not a defect to be hidden. It is the real architecture. The danger comes from describing the stack as one universal mandate. That language obscures privity, makes remedies difficult to locate and exaggerates what any single instrument proves.
The opposite error is to treat the layers as unrelated. They are deliberately coordinated. Policies, contracts and registry data connect them. Technical uniqueness gives the final record practical authority beyond a private bilateral promise. The system works because these limited relationships point toward a common ledger.
Good governance depends on preserving both truths. The record is globally useful, but each legal power remains bounded. The holder can be contractually accountable without being a party to the IANA SLA. The RIR can maintain authoritative data without controlling every router. A downstream user can be operationally dependent without possessing direct rights against the registry.
The discipline is simple. Whenever a registry entry is invoked as proof, ask which layer it proves. Whenever a power is asserted, ask which party promised compliance. Whenever harm is feared, identify who bears it and whether that party has a remedy. Whenever the word "community" appears, return to the signed instruments and actual corporate acts.
One line in a registry is not one contract. It is the visible point at which several limited promises, historical records and distributed technical decisions converge. Accountability begins by keeping those promises separate enough to enforce, and connected enough to preserve a truthful, continuous ledger.