AFRINIC and the economics of leasing contract risk

The first sign of trouble in an IPv4 lease is often not a lawsuit, a policy paper or a public argument over regional governance. It is a ticket at 02:17 on a Sunday morning. A hosting provider has moved a banking customer onto a leased AFRINIC-administered /22. Traffic is live. Firewall rules, mail relays, fraud controls, monitoring scripts and partner allowlists now point at addresses the customer treats as stable production infrastructure. Two upstreams accepted the route after seeing a letter of authorisation from the registered holder. Reverse DNS was supposed to follow the cutover. A route-origin authorisation was expected but has not appeared. The abuse mailbox still forwards to the lessor's network team. A geolocation vendor places part of the block in a country that does not match the sales deck. Payment callbacks start failing, and the customer asks whether the provider actually controls the addresses it sold as part of the service.

The operations room then discovers that every answer sits somewhere different. The registry record names one organisation. The lease names another. The origin AS belongs to the hosting provider. Reverse-DNS delegation is still controlled by the lessor. The IRR object was created by a broker's technical contact. The RPKI change requires access to a registry account that the lessor says is delayed by an account review. The customer contract promises continuity, while the address lease allows withdrawal of use if the lessee triggers abuse complaints or if the registry questions the arrangement. The bank does not care which clause failed. It only knows that an address range bought as part of dependable service now behaves like a chain of private promises.

That is the leasing-contract problem. IPv4 leasing lets an operator use scarce addresses without completing a registry-recognised transfer. The arrangement can be efficient. A holder with unused or underused space earns revenue without surrendering long-term control. A network that needs addresses for a product launch, migration, data-centre customer, security service or temporary expansion obtains usable capacity without the capital cost, delay or policy uncertainty of a purchase. But the efficiency is bought by moving risk out of the registry ledger and into contract. The ledger records a holder. The network needs an operating reality. The lease must explain how those two facts coexist.

AFRINIC is a sharp test case because the gap between ledger, policy and operational demand has become unusually visible. The organisation administers number resources for Africa and parts of the Indian Ocean region and provides the services that make address use legible: WHOIS and RDAP records, reverse DNS, an Internet Routing Registry, resource certification and RPKI, abuse-contact publication, membership administration and resource-management processes. Public exhaustion material records that AFRINIC entered Soft Landing Phase 2 in January 2020, leaving ordinary new IPv4 allocations or assignments constrained to small sizes. Its policy manual treats registration accuracy, needs justification, regional use and transfer conditions as core features of the system. Public reporting has also described address-theft allegations, the Cloud Innovation dispute over use, leasing and out-of-region service, a 2021 resource freeze and court fight, years without normal board function, receivership from 2023, troubled election attempts in 2025, a board election in September 2025 and continuing litigation and restoration questions in 2026.

Those facts are background exhibits, not a verdict on every lease. They matter because each changes the cost of private contracting. The lessee wants to know whether it may originate routes, whether reverse DNS and RPKI will be under timely control, who answers abuse, who absorbs reputation damage, what happens when the contract ends, what happens if registry recognition changes, how customers are protected during a dispute, whether subleasing is allowed, how regional-use and geolocation facts are handled, and whether the private agreement makes operational reality more visible or hides it from everyone relying on the address record. Leasing is not an escape from governance. It is governance by contract where the public ledger is too thin to describe use.

The thesis is narrow. AFRINIC is not here mainly an example of payment-release risk, price opacity, title-inspection practice or address-financing discount, though each can appear at the edge of a transaction. It is a test of how much operational and institutional risk can be pushed into a private agreement when registry-recognised transfer cannot satisfy demand quickly, cheaply or confidently enough. A leasing market can help networks survive scarcity. It can also create shadow allocation if contracts do not allocate control, liability and evidence with precision.

Leasing starts where registry-recognised transfer cannot meet demand

Leasing is often described as a second-best substitute for ownership. That misses the more important distinction in IPv4 markets: registry-recognised control versus operational use. A full transfer tries to align the registered holder, commercial owner, operating network and future risk bearer. A lease deliberately separates them. The holder remains in the registry record; the lessee operates the addresses; customers rely on the lessee; routing systems, reputation systems and abuse desks observe use that may not match the record's simple reading.

This separation appears because demand does not wait for perfect administrative mobility. AFRINIC's free-pool scarcity limits what a growing network can obtain through ordinary allocation. Its transfer rules are need-based and regionally framed: the recipient must justify need, become an AFRINIC member, sign the registration-services agreement and accept current policies. Transferred legacy resources no longer enjoy legacy treatment. Source entities face cooling-off conditions. Those rules may serve conservation, fairness and anti-speculation purposes, but they also make transfer a more elaborate institutional event than a private purchase order. If a data-centre operator needs addresses this quarter, and if a recognised transfer would take uncertain time or expose the parties to policy review, a lease becomes commercially attractive.

Leasing also appears where the holder values future optionality. A holder may not want to sell a block because it expects later internal demand, wants strategic reserve, fears losing bargaining power, or does not want to convert a recognised position into a transfer file that may be questioned. A lease turns dormant or spare capacity into yield while keeping the holder's name in the registry record. For the lessee, the trade is different. It receives immediate use but not the same durable control as a transfer. The contract is therefore not a rental invoice with technical annexes. It is a private constitution for divided control.

AFRINIC's recent history increases demand for such constitutions. Public accounts of the Cloud Innovation dispute describe a disagreement over whether actual use, out-of-region customer service and commercial leasing were compatible with earlier representations, policy expectations and contractual obligations. The dispute was not only about addresses. It was about whether changed operational reality could become a defect in registry recognition. That question is exactly what a lessee worries about. If the registry later challenges the holder, the lessee's network may suffer even though the lessee was not the original applicant, did not sign the older justification and may have no direct standing in the registry account.

The contract must therefore answer a question the ledger does not answer by itself: what does the lessee actually get? It cannot sensibly promise "addresses" in the abstract. It must define a bundle of rights and services: route-origin permission, exclusive or shared use, minimum term, support obligations, reverse-DNS handling, RPKI and IRR changes, abuse routing, reputation remediation, geolocation cooperation, customer-notice obligations, continuity during disputes and exit assistance. Without that bundle, the lessee has paid for a number string and a hope.

A lease is a control package, not a rent schedule

The commercial form of an IPv4 lease is deceptively familiar. One party pays periodic rent. Another provides access to a defined block. The customer may post a deposit, provide use-case information, accept abuse rules and agree not to sublease without consent. This makes the arrangement look like equipment hire or office space. It is not. A leased address block is a coordination object that depends on independent systems accepting a story about control.

The first control is exclusivity. If the lessor keeps the registry record but gives the lessee operational use, the lessee needs assurance that no other party will announce, sell, lease, pledge, reserve or route the same prefix during the term. Duplicate use can create route conflicts, leaks, filtering problems and customer outages. A lessor with multiple brokers, resellers or historical customers may accidentally create overlapping claims. A registry record naming the lessor will not tell the lessee whether another private agreement exists.

The second control is authority. The lessee needs evidence that the lessor can grant use. That evidence may include current registry records, corporate authority, account access, absence of known disputes, historical route control, records of past delegation and written authorisation for the lessee's origin AS. This resembles diligence in a transfer, but the question is more operational than archival: can this party support the lessee's use today and maintain the necessary registry-linked controls during the term? Authority evidence is an input into continuity, not the article's central object.

The third control is cooperation. A lessor can keep its name in WHOIS and still make the lease useless by failing to publish ROAs, update reverse DNS, approve IRR objects, answer abuse escalations, sign letters for upstreams, support geolocation corrections or give notice when the registry raises a question. Many failures in a lease are failures to cooperate after the first route comes up. The contract should convert cooperation from courtesy into duty, with service windows, authorised contacts, emergency paths and consequences for delay.

The fourth control is risk allocation. If abuse comes from the lessee's customer, who absorbs filtering and blocklist damage? If a geolocation database assigns the block to the wrong country, who pursues correction? If the registry asks the holder to explain use, who prepares evidence and who bears cost? If a court or registry action interrupts service, does rent pause, does the lessor provide replacement space, does the lessee receive transition time, and what happens to downstream customers? These are not exotic edge cases. They are the ordinary risks created by separating registry recognition from operational use.

Rent matters, but only after the control package is visible. A lease with clear route authority, long notice periods, usable RPKI, clean reputation and strong continuity terms has different economics from a lease that offers only route permission and a mailbox. Price cannot be assessed apart from the hidden control package. A cheap lease with weak operational promises may be the most expensive address plan in the room.

Regional-use facts belong inside the agreement

Every RIR faces the problem of matching registry region to operational geography. AFRINIC's version is unusually consequential because regional-use arguments have moved from policy text into litigation and market practice. The background is plain enough. AFRINIC's service region covers Africa and parts of the Indian Ocean. Its exhaustion and transfer rules are designed around regional scarcity and needs-based distribution. Its policy manual contains registration requirements and resource-management rules that assume the registry can ask where and why addresses are being used. Public analyses of the Cloud Innovation dispute report that AFRINIC questioned discrepancies between registered usage and actual countries of use, consistency with stated need and the requirement that services originate within the defined region.

For a lease, this creates a drafting problem. Suppose the registered holder is in the AFRINIC region, the lessee is incorporated elsewhere, the origin AS is operated from a European data centre, customers are global, the address block supports Africa-facing services through a content platform, and geolocation databases show several countries depending on routing and commercial datasets. Is that compliant regional use, impermissible offshore use, ordinary global service, or an incomplete record? The lease cannot decide the policy question for AFRINIC. But it can decide what facts must be disclosed, who represents what, and what happens if the registry or a counterparty challenges the arrangement.

A weak contract avoids the issue with vague language: "customer shall comply with applicable registry policy" or "addresses shall not be misused." That may satisfy a form, but it does not allocate risk. The lessee needs to know whether out-of-region origination is permitted, whether use must support African connectivity, whether customer geography is restricted, whether the lessor has made representations to AFRINIC that limit use, and whether the lessor will provide copies or summaries of relevant constraints. The lessor needs to know whether the lessee's deployment will expose it to resource review, reputational damage or termination risk.

The better architecture treats regional-use facts as contract data. The lessee should state where services are operated, which ASNs will originate routes, what customer categories will use the space, whether any portion is intended for Africa-facing service, whether geolocation claims will be made, and whether subdelegation is expected. The lessor should state whether the block is subject to known policy correspondence, dispute status, past representations, transfer restrictions, resource-review conditions or usage commitments that could affect the lease. These disclosures need not make every commercial secret public. Between the parties they must be specific enough to prevent later surprise.

This is not an argument for private contracts to evade regional policy. It is the opposite. A leasing contract that names operational geography honestly gives the parties, upstreams and possibly the registry a more accurate picture than one that pretends the holder and operator are the same. Where policy forbids a use, the contract should not paper over the prohibition. Where policy is unclear, the contract should say who bears uncertainty. The worst outcome is not commercial leasing itself. It is a leasing market that survives by hiding the facts that everyone later claims to need.

Route origination is the first control right

The most visible act in a lease is the route announcement. Until a prefix is originated, the lessee has no service. Once it is originated, the rest of the internet begins to form an opinion about who controls the block. Transit providers, peers, route servers, route collectors, monitoring systems and customers observe the origin AS. Some ask for a letter of authorisation. Some check IRR route objects. Some rely on RPKI. Some apply local filters. The route is where private permission becomes public behaviour.

A leasing contract must therefore define route-origin authority before anything else. It should identify the authorised origin AS or ASNs, whether multi-origin is permitted, whether more-specific announcements are allowed, what prefix lengths may be advertised, which upstreams or IXPs may receive the route, and whether the lessee can move the prefix between networks during the term. It should define who signs letters of authorisation, who may revoke them, how quickly revocation can occur in a real emergency, and what notice is required before a lessor withdraws ordinary authorisation. A lease that simply says the lessee may "use" the block is dangerously incomplete.

Route authority is also the first place where customer continuity meets lessor control. A lessor may want immediate suspension rights if the lessee violates abuse rules, fails to pay, subleases without consent or creates legal risk. The lessee needs cure periods and proportional remedies because abrupt withdrawal can break customer services, payment flows, VPNs, mail systems and security allowlists. The contract must distinguish emergencies from ordinary defaults. A hijack, active fraud campaign or court order may justify rapid action. A billing dispute or paperwork delay usually should not. Without that distinction, the lessor holds a private kill switch over the lessee's customers.

AFRINIC's institutional setting makes the route question more than technical. If the registry challenges the holder's use, or if a dispute changes the holder's account status, upstreams may hesitate to accept the lessee's authorisation. The lessee may not solve this by showing the lease alone; networks may still ask whether the registry-recognised holder supports the route and whether registry-linked security objects are current. A contract should anticipate this by requiring the lessor to maintain continuing evidence of authorisation and to notify the lessee within a defined notice period of any registry, court or account event that could affect route acceptance.

Route origination also separates legitimate delegation from hidden transfer. A clean lease can say that the holder remains the registered resource holder; the lessee may originate specified routes for specified services during a defined term; registry contacts and security objects will identify or support that operational delegation where feasible; and no ownership-like transfer is claimed. A shadow arrangement says little, routes through intermediaries and leaves outsiders guessing whether the lessee is authorised or merely exploiting a stale record. The difference is not moral language. It is evidence.

Reverse DNS, RPKI and IRR turn permission into reachability

Leased IPv4 space fails quietly when adjacent controls lag behind routing. A BGP route may come up while reverse DNS still points to a previous use, RPKI still authorises the lessor's old origin, IRR objects are missing or stale, and abuse contacts still land in a mailbox that no one on the lessee's side reads. Engineers sometimes treat these as housekeeping tasks. In a lease they are part of the asset.

Reverse DNS is the clearest example. Many services use PTR records for mail reputation, logging, diagnostics, customer support and institutional comfort. AFRINIC's policy manual treats reverse delegation as a registry service tied to registered assignments or sub-allocations and membership status. If the lessor remains in control of reverse DNS, the lessee must know how updates will be requested, what naming policy applies, how long changes take, whether customers can receive delegated control for their ranges, and what happens at termination. If reverse DNS cannot be updated because the lessor's account is in dispute or not current, the lessee's customer may experience deliverability or trust problems that look like service failure.

RPKI is even more consequential because it can turn authority into automated filtering. If a valid ROA authorises the wrong origin, or if no ROA is present where the upstream expects one, the lessee may face partial reachability failures. If the lessor can revoke or alter ROAs without notice, the lessee's network is exposed to a private administrative action with global effects. The contract should specify who requests or creates ROAs, what origin AS and maxLength values are permitted, how emergency changes are handled, whether the lessee may receive delegated certification control if available, and what notice is required before revocation. It should also require testing before cutover, not after customers complain.

IRR objects sit between contract and routing habit. Many networks still filter using route objects even when RPKI is available. A lease should identify which IRR database will be used, who maintains route and route6 objects, which maintainer controls them, whether the lessor will authenticate objects created by the lessee, and how stale objects will be removed at the end. Stale IRR data can keep a route looking authorised after the lease ends, or make a legitimate route look suspicious during the lease. Both cases create risk.

These services are where the registry ledger, private contract and operational internet intersect. AFRINIC's service materials list reverse DNS, IRR, RPKI, WHOIS and RDAP because the holder record alone is not enough. A leasing contract that ignores these controls leaves the lessee dependent on goodwill. A serious contract treats them as deliverables with times, evidence, fallback paths and customer-facing consequences.

Abuse handling decides whether risk follows the customer or the prefix

Abuse is the recurring moral vocabulary of IPv4 leasing. Critics point to spam, fraud, botnet infrastructure, phishing and evasive hosting. Defenders answer that abuse can occur on any network and that transparent contacts are better than hidden use. Both claims can be true. The contract question is more practical: when harmful traffic or content comes from a leased block, who receives notice, who investigates, who acts, who reports back and who bears the reputation cost?

AFRINIC's policy manual recognises a dedicated abuse-contact object as a way to route complaints to the right network contact. It also notes the familiar data-accuracy problem. In a lease, accuracy becomes harder because the registry-recognised holder may not be the network operating the customers. If abuse complaints go only to the lessor, the lessee may learn too late. If they go only to the lessee, the lessor may face registry or upstream consequences without visibility. If they go to a broker or reseller, both principal parties may be insulated from operational reality. The contract should require direct escalation paths, shared ticket references and defined response times.

Abuse clauses also need proportionality. A lessor cannot tolerate a lessee that burns reputation, ignores complaints and exposes the block to filtering. A lessee cannot operate if the lessor can terminate the entire prefix for one unverified report. The contract should classify events: ordinary complaints, repeated unresolved complaints, severe verified abuse, law-enforcement or court notices, upstream suspension threats, registry inquiries and reputation emergencies. Each class should have a remedy: notice, cure, customer isolation, temporary null-route, deposit draw, replacement range, suspension of a subnet or termination. The remedy should match the operational harm.

The hardest cases involve downstream customers. A hosting company may lease a block and assign addresses to hundreds of customers. One customer sends spam or hosts phishing content. The lessor demands termination of the whole lease. The hosting company says it can isolate the customer. Upstreams threaten filters. The registry asks who is responsible. Without a contract, everyone points elsewhere. With a good contract, the lessee must maintain customer identity records, acceptable-use rules, investigation files and rapid containment capacity; the lessor must avoid broader disruption than necessary; and both sides have an evidence package for external escalation.

Abuse handling also influences whether private agreements reveal or hide reality. If the lease provides accurate operational contacts and records downstream responsibility, complaints reach the party that can act. If the lease hides the lessee behind the holder, the public record looks clean until it fails. Leasing then becomes associated with evasion even when many leases are ordinary capacity arrangements. The way to defend legitimate leasing is not rhetoric. It is contactability.

Reputation has to be delivered, maintained and returned

IPv4 reputation is not stored in one database. It accumulates in blocklists, mail systems, geolocation vendors, payment gateways, hosting-provider histories, fraud engines, routing records, customer memories and informal network-operator judgement. A lease creates joint exposure to this reputation. The lessee can damage the block through customer behaviour. The lessor can damage the lessee's service by providing a block with undisclosed history. The registry can affect both by associating the block with dispute or policy uncertainty. No single record tells the whole story.

A lease should therefore treat reputation as both a condition of delivery and a continuing covenant. At delivery, the lessor should disclose known blocklist status, recent abuse history, prior customer categories, geolocation anomalies, route-history issues, reverse-DNS residue and any registry or public dispute that may affect onboarding. The lessee should test the block before production and accept or reject it within a defined period. If the lessee accepts a known condition, it should not later treat that condition as breach. If the lessor hides a material condition, rent credit alone is unlikely to compensate for failed customer migrations.

During the term, reputation must be maintained. The lessee should operate acceptable-use controls, preserve customer records, answer complaints, avoid rapid churn that looks like evasive hosting, and cooperate with remediation. The lessor should support delisting where its holder status is needed, maintain registry contacts and avoid leasing adjacent or overlapping space in ways that contaminate reputation. Both parties should keep records of remedial steps. Reputation is often recovered by evidence, not assertion.

The termination period is especially risky. A departing lessee may have customers still using DNS records, allowlists or APIs tied to the addresses. A lessor preparing to lease the block again needs assurance that old customers are gone, abuse is remediated and reverse-DNS or IRR residue is removed. A new lessee does not want to inherit the previous lessee's mail reputation or geolocation mistakes. The contract should provide a reputation handback process: final scan, blocklist report, abuse-ticket closure, route-object cleanup, reverse-DNS reset, geolocation status and certification changes. This is the operational equivalent of returning premises in good repair.

AFRINIC's background reinforces the point because the region's public stories include both alleged record manipulation and disputed commercial use. That combination can make outsiders treat AFRINIC-administered leased space as riskier even when a particular block is clean. A contract cannot repair institutional reputation by itself. But it can prevent the parties from adding private opacity to public uncertainty.

Termination is hard because addresses become customer memory

Most leases are drafted as if the end of the term returns the world to its earlier state. IPv4 leasing rarely works that way. Addresses become embedded in customer systems. They appear in DNS, firewalls, API allowlists, VPN configurations, mail headers, fraud models, payment processors, monitoring tools, certificates, security policies and vendor documentation. A customer may not know that its provider leased the space. It only knows that the address works. When the lease ends, withdrawing a route can become a commercial outage.

Termination rights therefore require more care than payment clauses. The lessor wants protection against non-payment, abuse, unauthorised subleasing, policy breach, loss of registry recognition and reputational harm. The lessee wants predictable notice, cure rights, migration assistance and customer continuity. A contract that gives the lessor immediate termination for broad "policy concern" or "reputation risk" may be commercially unusable. A contract that traps the lessor for months while abuse continues may be reckless. The drafting problem is to distinguish default types and match them to transition periods.

Ordinary non-payment can usually be handled through notice, short cure periods, deposits and staged suspension. Severe abuse may require immediate containment of a customer or subnet, but not necessarily withdrawal of the entire block. Unauthorised subleasing may justify suspension of the unauthorised portion while preserving innocent customer service. Registry challenge may require an evidence response and contingency plan rather than automatic termination. Court orders may override contract but should still trigger cooperation duties and customer-notice processes. Each event has a different continuity profile.

The customer layer is the reason termination cannot be a private duel. If a lessee serves enterprises, banks, public agencies, hospitals, content platforms or access networks, abrupt withdrawal may injure parties that never negotiated the lease. The contract should require the lessee to maintain a customer inventory at an appropriate level of confidentiality, identify critical services where lawful and feasible, and prepare migration plans. The lessor need not become responsible for every downstream customer, but it should not be allowed to ignore foreseeable harm when a less disruptive remedy is available.

Termination also affects evidence after the fact. Stale routes, stale ROAs, old IRR objects, lingering reverse DNS and customer DNS records can make a returned block look hijacked, dirty or contested. The lease should require a handback checklist and an attestation that operational control has ended. This protects the lessor, the next lessee and the wider network. A clean exit is one of the strongest signs that leasing is an orderly delegation rather than a hidden transfer.

Registry events need their own clauses

The risk most specific to AFRINIC is that registry recognition may not remain a quiet background assumption. A lessor may be the recognised holder when the lease is signed. Later, the registry may question use, suspend a service, reject an update, refuse a transfer, change policy interpretation, receive a complaint, become subject to a court order, or face operational constraints of its own. The lessee's contract with the holder does not bind the registry. That is the fundamental asymmetry of leasing.

AFRINIC's recent history gives this risk a concrete form. Public reporting describes a 2021 resource action against Cloud Innovation, litigation that affected the registry's bank accounts, years of board and executive dysfunction, receivership, annulled and repeated election attempts, a September 2025 board election, statements in 2026 about recovery and budgets, and further litigation around winding-up, publications and leasing-related representations. These facts do not decide any private lease. They show why a lessee cannot assume that registry services will always be administratively routine.

The contract should therefore define registry-event clauses. A registry event may include loss of good standing, resource review, adverse correspondence, rejection of a requested technical update, dispute flag, court order, receivership constraint, change in policy affecting the lease, or public statement that materially impairs route acceptance or customer confidence. The lessor should have a duty to notify the lessee without delay, provide non-privileged information, cooperate on a response and avoid making unilateral admissions that prejudice the lessee's operation. The lessee should have a duty to provide deployment facts and customer-impact information needed for the response.

Rent treatment should be secondary but clear. If registry action prevents use, rent may abate or credits may apply. A deposit or prepaid rent may secure performance or transition obligations. But the central issue is not payment mechanics. It is who bears the operational consequences when public recognition and private use diverge. A lessee that has moved customers onto the prefix needs evidence, service levels and transition rights more than a later accounting adjustment.

Registry-event clauses should also avoid pretending that every registry concern is illegitimate. If the lessee's deployment violates a clear disclosed policy constraint, the lessee should bear that risk. If the lessor failed to disclose prior correspondence or restrictions, the lessor should bear it. If the policy environment changes unpredictably, the parties may share risk through termination rights, replacement space, transition periods or rent adjustment. The point is to allocate uncertainty before the ticket arrives.

Subleasing is where delegation becomes opacity

Subleasing is the point at which an efficient capacity arrangement can turn into a shadow market. A holder leases a block to a network. That network leases pieces to hosting customers, resellers, VPN operators, cloud tenants or managed-service providers. Some of those customers assign addresses again. After two or three layers, the party named in the registry may have little idea who originates traffic, who receives abuse complaints, who controls reverse DNS for a slice, or which customer will be harmed by termination. The public ledger sees one holder; the internet experiences a chain.

Not all downstream delegation is abusive. Many network services require it. A data centre may assign addresses to colocation customers. An ISP may provide static addresses to enterprises. A managed hosting provider may allocate addresses to customer servers. The problem is not delegation as such. It is uncontrolled delegation without evidence, contacts or flow-down obligations. A registry policy that condemns all delegation may drive it underground. A contract that permits all delegation without controls invites abuse and customer harm.

A good leasing contract distinguishes ordinary customer assignment from commercial subleasing. Ordinary customer assignment may be allowed within the lessee's service, subject to acceptable-use rules and abuse records. Commercial subleasing, where the customer can resell, route independently, control reverse DNS or present itself as provider of the addresses, should require written consent, identity checks, flow-down terms and operational disclosure. The lessor should know whether the lessee is a network operator using addresses for its own services or an intermediary building a second leasing market.

Flow-down obligations matter because the lessor cannot enforce what the downstream customer never agreed to. Abuse response, no-hijack covenants, routing limits, geolocation claims, termination assistance, customer record retention, cooperation with registry inquiries and no-further-sublease rules must follow the addresses. If they stop at the first lessee, the chain breaks exactly where evidence is needed. The lessee should remain responsible for downstream acts, but responsibility without records is theatrical.

Subleasing also affects regional-use claims. A lessee may be regionally compliant in its own deployment but permit a downstream reseller to use the space elsewhere. Or it may claim Africa-facing service while most downstream use is global. If the lease does not track that distinction, the holder may make inaccurate statements to the registry or to counterparties. Transparency need not mean public disclosure of every customer. It means the contract preserves enough truth to answer the next serious question.

Geolocation turns competing facts into contract risk

Geolocation is often treated as an external database problem. In leasing it becomes a contract problem because address use, registered holder location, origin AS, customer location and commercial purpose may point in different directions. A block administered by AFRINIC can be held by an African or Indian Ocean region member, routed from a European data centre, used by customers on several continents and tagged by commercial geolocation providers in yet another country. None of those signals alone proves misuse or legitimacy. Together they create inference risk.

A 2026 research project, WHEREIS, is useful background because it treats registration geo-consistency as a measurement problem rather than a slogan. The researchers built a way to compare measured prefix location with RIR region and registered organisation location. They found that most prefixes were consistent in aggregate, but that variation across RIRs matters and AFRINIC was a case study. They also showed that inconsistencies can appear in commercial geolocation databases and that structural issues, not merely IPv4 exhaustion, shape the problem. For leasing, the lesson is not that every out-of-region signal proves breach. The lesson is that operational reality is harder to infer when the record, route and customer story diverge.

Contracts should not outsource this problem to geolocation vendors. They should specify who is responsible for geolocation correction, what country or region claims may be made, what evidence the lessee may submit to databases, and whether the lessor must support correction requests. If the service is sold as African connectivity, that claim should be supported by actual operational facts. If the service is global hosting using AFRINIC-administered space, the parties should not pretend otherwise between themselves. Inaccurate geolocation may break content licensing, fraud controls, banking access, tax localisation, public-sector portals and customer analytics. Those losses should not be left to generic indemnity language.

Regional-use claims also require humility. A policy category may not map cleanly onto network architecture. A content-delivery service outside Africa may improve African user experience. A global anti-abuse service may use addresses in multiple regions. A cloud customer may be incorporated in one country, serve users in another and route through a third. A registry may focus on where services originate. A customer may focus on where users are. A geolocation database may focus on latency. The lease cannot eliminate these definitions, but it can prevent the parties from switching definitions opportunistically.

This is where private agreements can either improve or degrade public understanding. A lease that records deployment geography, customer category and contact responsibility can help explain why measured location differs from registered holder location. A lease that hides those facts makes the same difference look like evasion. In a region where out-of-region use has been litigated and politicised, opacity is not neutral. It becomes evidence in somebody else's story.

The public ledger and private contract should meet at control

The most important institutional choice in IPv4 leasing is whether contracts make operational reality more legible. A lease can reveal reality by documenting the holder, lessee, route origin, technical contacts, abuse desk, reverse-DNS arrangements, RPKI responsibilities, customer categories, subdelegation rules, regional-use facts and termination plan. It can bury reality by naming only the holder, routing through intermediaries, leaving contacts stale, using generic authorisations, hiding subleases and treating every inquiry as a hostile act. Both structures may produce traffic. Only one produces trust.

Registry policy can unintentionally decide which structure prevails. If the registry provides a safe way to record operational delegation without treating every lease as a forbidden transfer, responsible parties have a reason to be candid. If the registry treats candour as a trigger for broad business-model review, parties will disclose less. The database then becomes less accurate, and the registry may cite inaccuracy as a reason for more control. That cycle is not unique to AFRINIC, but AFRINIC's crisis makes it visible.

The public ledger does not need to publish every commercial term. Rent, margins, customer lists, deposits, termination fees and business strategy can remain private. But certain operational facts are infrastructure facts. Who may originate the prefix? Who receives abuse reports? Who can change ROAs? Who controls reverse DNS? Is the registered holder also the operating network? Is there a known dispute? Is there a customer-impact plan if recognition changes? These facts affect third parties. They are not merely private bargaining points.

There are ways to respect confidentiality while improving legibility. The lessor can provide a limited operational-authorisation statement to upstreams and customers. The lessee can publish accurate abuse contacts. The parties can maintain customer records available under defined legal or registry conditions. Technical objects can identify maintainers without disclosing sensitive economics. Dispute status can be recorded without declaring guilt. The lease can require truthful answers to carriers, banks, public buyers and registry inquiries. The design principle is simple: hide prices if necessary; do not hide control.

The agreement should also preserve versioned evidence. IPv4 leases often last long enough for staff, routing policy, customers, upstreams and registry practice to change. A letter of authorisation issued at commencement may not explain a later AS migration. A reverse-DNS delegation made for one customer class may not explain a later hosting product. A geolocation correction submitted in one quarter may be contradicted by new routing the next. The lease should require an evidence file that evolves with the deployment: current origin ASNs, current technical contacts, current downstream-use categories, material customer migrations, significant abuse events, registry correspondence, ROA changes, IRR changes and termination notices. This is not bureaucracy for its own sake. It is the memory that lets the parties prove continuity when an upstream, court, customer or registry asks why the route still deserves trust.

Legibility is also a defence against opportunism between the parties. A lessee that keeps accurate records cannot easily claim later that it never knew of a disclosed regional-use constraint. A lessor that signs specific route authority cannot easily deny that the lessee's origin was authorised. A downstream customer that receives flow-down terms cannot easily treat the block as resale inventory if the service was only an assignment. The contract therefore acts less like a wall against outsiders than like a shared fact base. In a market where memory is fragmented across tickets, WHOIS objects, BGP collectors, email threads and private invoices, that fact base has economic value.

This distinction is critical for AFRINIC because public arguments around leasing have become highly charged. If leasing is defended through exaggerated claims that courts have approved every commercial model, it invites correction and mistrust. If leasing is attacked as inherently illegitimate despite real operational demand, it drives use into less visible forms. A better contract culture would make modest claims: this holder authorises this operator for this use, under these controls, with these contacts, for this period, subject to these disclosed constraints. That is not a political manifesto. It is infrastructure hygiene.

The temptation in a troubled registry environment is to make contracts louder. A lessor promises uninterrupted control. A lessee demands sweeping indemnities. A broker assures everyone that the registry will not matter. Customers receive polished service descriptions that omit the difference between transferred and leased space. None of this reduces risk. It only converts uncertainty into future breach.

A workable AFRINIC-related IPv4 lease should do the opposite. It should narrow uncertainty. It should state exactly what the lessor can provide and what it cannot. It should acknowledge that the registry record remains with the holder unless and until a recognised transfer occurs. It should define the lessee's operational rights without pretending those rights are ownership. It should allocate route, reverse-DNS, RPKI, IRR, abuse, reputation, geolocation, subleasing, regional-use and termination responsibilities. It should create cooperation duties for registry events. It should protect customers through notice, cure and migration planning where possible. It should reserve emergency remedies for real emergencies.

This architecture benefits the lessor as much as the lessee. A lessor with clear contracts can show that it controls who uses its space, that abuse routes to the correct desk, that downstream delegation is governed, that regional-use facts are known, and that technical objects match operational reality. That makes the lessor less vulnerable to the accusation that leasing is indistinguishable from abandonment or evasion. It also protects the value of the block by reducing reputation damage and chaotic exits.

It benefits the lessee because it converts a fragile dependency into a managed dependency. The lessee still does not own the registry position. It still faces risk if AFRINIC, a court, an upstream, a geolocation vendor or a customer disputes the arrangement. But it has evidence, service levels, notice rights and a plan. For many operators, that may be enough to justify leasing during IPv4 scarcity. For others, purchase, provider addresses, IPv6 transition, CGNAT or renumbering may be more rational. The contract's job is not to force one answer. It is to make the trade visible.

It also benefits the registry system, if the system is willing to learn from it. A registry cannot satisfy every operational demand through new allocation. It may not want to endorse every transfer. It may have legitimate reasons to worry about regional leakage, fraud, abuse and speculation. But suppressing responsible leasing without offering a legible delegation path does not eliminate demand. It pushes demand into private documents, routing workarounds and incomplete records. The result is less visibility over the very operational reality the registry says it must understand.

AFRINIC's test is therefore institutional economics in miniature. Scarcity creates demand. Policy constrains transfer. Operators seek continuity. Private contracts fill the gap. The quality of those contracts decides whether leasing becomes a disciplined form of operational delegation or a shadow allocation market. The registry ledger can say who is recognised. It cannot, by itself, decide who answers at 02:17 when the customer outage begins. That answer has to be written before the prefix is routed.