The trouble begins after the route comes up.
An African hosting provider has bought or leased what looks like a clean /24 for a regulated customer base. The registry record is not visibly broken. The upstreams accept the announcement. The routers carry traffic. The customer migration is planned for a weekend because banks, public agencies and payment companies do not like address changes during office hours. The engineers do what network engineers are paid to do: obtain address space, originate the prefix, configure reverse DNS, place customers, update firewalls and watch for packet loss.
By Monday morning the block has become a different asset. Mail receivers throttle it. A payment processor's callback endpoint fails because a fraud engine still associates part of the range with earlier botnet traffic. A security vendor treats neighbouring addresses as hostile because a previous hosting tenant used the same neighbourhood for short-lived command infrastructure. A government customer asks whether the problem belongs to the provider, the prior user, the registered holder, the broker, the lessor, the upstream, the blacklist operator, the registry record or the customer that has just been moved. The prefix routes. Its memory does not reset.
That memory is address-reputation contamination. An IPv4 prefix is not only a number range, a routable object or an entry in a registry database. It carries accumulated social and machine memory in mail systems, DNS reputation engines, web-application firewalls, payment-fraud tools, hosting histories, geolocation vendors, threat-intelligence feeds, law-enforcement files, upstream filters, customer allowlists and the informal judgement of operators who remember which networks caused trouble. Some of this memory is formal and queryable. Much of it is private. Some of it is accurate. Some of it is stale, derivative or unfair. All of it can become economically real.
AFRINIC is a useful test case because scarcity and institutional uncertainty make address memory harder to ignore. The African Network Information Centre serves Africa and parts of the Indian Ocean as the regional registry for IPv4, IPv6 and autonomous system numbers. Its IPv4 Soft Landing Phase 2 began in January 2020, leaving ordinary new IPv4 allocation and assignment sizes constrained to small blocks. Reported record manipulation involving valuable dormant African IPv4 space, the dispute with Cloud Innovation over resource use and registry authority, court proceedings, receivership, election disruption, later board recovery and continuing litigation questions have all made registry confidence a practical concern. Those facts are not the main story here. They matter because they make one point visible: under scarcity, a record is not the whole asset.
Markets already know the price of a dirty car, a contaminated plot of land or a receivable with disputed debtors. IPv4 has its own version. A block can be technically usable yet commercially impaired because strangers have learned to distrust it. It can have a valid registry record yet face filtering by systems that do not consult the registry. It can be acquired by an innocent operator yet still carry the residue of a previous user. It can be repaired, but repair requires evidence, time, escalation paths and sometimes replacement space. The cost is not merely an abuse-ticket cost. It is an asset-quality cost.
This makes reputation contamination distinct from nearby problems. Abuse reports are one signal through which reputation is observed; they are not the whole economics. Suballocation visibility can help identify the customer or reseller behind an incident; it does not by itself restore trust. Leases and transfers move exposure between parties; they are channels for memory, not the whole subject. Liquidity discounts are a consequence of the defect, not the frame. Title, routing security, route objects and certification can prove important facts about recognition and origin authority. They do not say whether a payment processor, mail receiver or enterprise firewall has forgiven a prefix.
The central question is colder: who pays when scarce address space arrives with memory? In an abundant world, a provider might avoid suspect space and obtain another allocation. In a scarce world, the contaminated asset may still be needed. The provider may have to segment risky customers, warm up mail traffic, pursue delistings, prove change of control, buy monitoring, negotiate with fraud vendors, reassure public-sector buyers, accept lower sale or lease value, or reserve the range for less sensitive workloads. The bad actor may be gone. The invoice remains.
Reputation is a second ledger around the registry ledger
The registry ledger records recognition. It says who is associated with a block, which contacts and technical data exist, and what registration services can be derived from that relationship. That ledger is essential because uniqueness and attribution need a common reference point. But it is not the only ledger that determines whether an address can be used commercially.
Around it sits a second ledger made by operational memory. Mail receivers track sending history. Fraud vendors associate addresses with account-takeover attempts, card-testing, phishing, bot traffic, proxy use, scraping or suspicious sign-up patterns. Security companies record scans, malware callbacks, brute-force attempts and hosting patterns. Content platforms remember abuse complaints. Upstreams remember whether complaints were ignored. Public agencies and banks keep internal allowlists and blocklists. Geolocation vendors attach country, city, hosting and risk attributes. Incident responders retain notes that never become a registry record. A block may have passed from one operator to another, but many of these systems continue to treat it as the same neighbourhood.
This second ledger is fragmented, private and often opaque. There is no single authority that can clear a prefix everywhere. A delisting at one mail blocklist may not affect a payment-fraud engine. A clean RDAP record may not affect an enterprise firewall using an old threat feed. A new ROA may improve route-origin confidence but say nothing about spam history. A reverse-DNS change may help deliverability yet leave a botnet archive untouched. A provider can fix the registry facts and still face distrust in systems it cannot see.
That is why reputation is not merely security. It is a market interface. A provider selling hosting, mail, SaaS, payment infrastructure, public-sector portals or enterprise connectivity is not selling packets alone. It is selling the expectation that those packets will be accepted by counterparties. If counterparties silently throttle, challenge or block the addresses, the service loses value. If customer support has to explain why a new deployment is being treated as suspicious, the provider has inherited a reputation debt.
The second ledger also has a different evidentiary culture. Registry facts ask who is recognised now. Reputation systems ask what has been observed before. The registry can say that a holder changed. A fraud engine may still weigh older abuse because attackers often move through delegated space, leased space and reseller chains. The registry can say that a contact is current. A mail receiver may still wait to see months of benign traffic before trusting the range. The registry can correct a name. A law-enforcement file may still contain historical references. The two ledgers answer different questions.
Markets price the harder ledger. A buyer of addresses asks not only whether the seller can transfer control, but whether the block will be usable for the intended customers without hidden cleanup. A lender asks whether address-dependent revenue is stable or vulnerable to filtering. A public-sector customer asks whether critical services will be caught in someone else's history. A broker asks whether reputation problems should be disclosed. A lessor asks whether a risky user will contaminate space that must later be used by someone else. The registry ledger enables the transaction. The reputation ledger determines whether the transaction performs.
AFRINIC's role is indirect but important. It cannot clear every external feed. It should not become a reputation police force. Yet its record quality, dispute handling, transfer clarity, suballocation legibility and service continuity affect how easily a new operator can prove that a contaminated history belongs to someone else. A narrow registry does not own the second ledger. It can still reduce the cost of explaining it.
Scarcity makes yesterday's bad traffic a priced asset defect
Scarcity changes the status of historical dirt. When addresses were easier to obtain, a network with a tainted range could renumber, reserve the problem space for less sensitive workloads or ask for another allocation. Those choices were never free, but they were plausible. Under IPv4 scarcity they become harder. A /24 that is difficult to use for mail or payments is still too valuable to throw away. The holder must either repair it, discount it, isolate it or sell it to someone with a different risk tolerance.
That is what turns reputation into an asset defect. It is not enough to say that abuse happened in the past. The question is whether that past limits today's economic uses. A block with old spam history may still be fine for infrastructure addresses, CDN nodes, lab environments, VPN egress, game servers or workloads that do not send mail or touch regulated counterparties. The same block may be unsuitable for a bank, a public-health portal, a government identity service or a payments platform. The defect is use-specific, but the cost is real.
In financial terms, the block has impaired optionality. A clean block can support many customer categories. A suspect block supports fewer categories or requires more preparation before sensitive use. That difference affects sale value and lease value even when routeability is identical. A buyer who wants to place enterprise customers on the range will not value it like a buyer who only needs generic hosting capacity. A lessor will think differently if the user may damage future reputation. An acquirer will ask whether address inventory can be used across the combined business or only in low-trust segments.
The defect also changes time. Clean use can begin quickly. Contaminated use requires a warm-up period, reputation monitoring, ticket history, customer communication, reverse-DNS hygiene, mail throttling, abuse evidence, threat-feed outreach and sometimes replacement inventory for sensitive customers. Time matters because addresses are not held for decoration. They support launches, migrations, tenders, renewals and financing events. A three-month reputation repair is a working-capital cost.
Scarcity magnifies the unfairness. The operator inheriting the defect may have done nothing wrong. It may be a regional ISP, a data-centre company or a public contractor that needs scarce public IPv4 to serve ordinary customers. The previous user may have disappeared, changed providers or hidden behind a reseller. The blocklist operator may have no practical way to distinguish the innocent neighbour from the old offender. The payment vendor may refuse to disclose its risk logic. The customer may not care; it bought a service that was supposed to work.
This is why address-reputation contamination should not be treated as a moral label. It is a cost-allocation problem. If the bad actor pays nothing and the innocent successor pays through lost customers, lower address value and cleanup expense, the market has produced an externality. If every address in the region receives a reputation haircut because record uncertainty makes attribution hard, the externality spreads from bad users to good holders. If registries, sellers and lessors deny the problem, the cost does not vanish. It moves to buyers, customers and downstream operators.
AFRINIC's scarcity context makes the externality sharper because replacement space is limited and institutional trust has been contested. A provider cannot assume that more addresses will arrive from a deep free pool. It cannot assume that registry-backed history alone will satisfy third-party systems. The block has to be made credible in many ledgers at once. That is expensive work, and scarcity makes it unavoidable.
AFRINIC adds proof risk to technical contamination
Reputation contamination can happen in any region. A careless hoster in Europe, a bulletproof network in North America or a compromised reseller in Asia can poison a block. AFRINIC's case is distinctive because the address-memory problem sits on top of a registry that has itself been a public stress case.
The facts should be used carefully. AFRINIC administers number resources for its service region and operates registration-adjacent services such as public registration data, reverse DNS, routing registry functions and resource certification. Its exhaustion status is also clear: Phase 2 of its IPv4 Soft Landing process began in January 2020, and small allocations became the normal frontier for new supply. Reported cases have described record manipulation involving dormant African IPv4 space, a long dispute between AFRINIC and Cloud Innovation over resource use and registry authority, court proceedings, frozen funds, receivership, contested election activity, later board recovery and continuing litigation over the institution's restoration.
For this article, the important consequence is not a verdict on each dispute. It is the extra diligence burden. If a block from an ordinary market has a reputation history, the buyer asks: what happened on the block? If a block from a stressed registry environment has a reputation history, the buyer also asks: can the holder prove the current state cleanly, can the registry record explain the transition, can the history be separated from alleged record manipulation, can a court or receivership issue affect continuity, and will outside systems believe the explanation?
That second set of questions matters because reputation repair depends on evidence. A mail receiver, security vendor or enterprise customer may ask for proof of new control, changed operations, removed customers, updated contacts, abuse response and time without new incidents. Strong registry records help. Weak or contested records weaken the story. If address-theft reporting has made dormant records suspect, a buyer of old space must prove that the block's history is not only operationally clean but legitimately continuous. If commercial delegation has become politically charged, a user must prove that it is not merely the latest opaque party in a chain. If receivership or election issues have made institutional authority visible, a counterparty may ask whether today's registry state will survive tomorrow's challenge.
The contamination problem therefore has two layers. The first is direct: what did prior users do with the prefix? The second is institutional: how confidently can the current user prove that prior behaviour is no longer relevant? AFRINIC's crisis history makes the second layer more expensive. It does not mean every AFRINIC-administered block is suspect. It means that the market has learned to ask more questions before trusting the answer.
Registry statements about continued service are not enough. A registry can continue to operate RDAP, WHOIS, reverse DNS and resource certification while the market still worries about particular records, authority chains and external reputational states. Conversely, critics can overstate institutional failure while particular blocks remain operationally and reputationally sound. Address reputation is granular. Serious analysis has to stay granular.
The right unit of analysis is the block, the history, the current operator, the evidence file and the intended use. AFRINIC is the setting because scarcity and governance stress raise the price of evidence. The registry does not create every contamination event. But when the registry environment is uncertain, it becomes harder for clean operators to isolate contamination and persuade outsiders that the memory should stop attaching to them.
Clean-looking records do not clean inherited histories
The most dangerous phrase in address diligence is "the record is clean." It may be true and insufficient. A registry record can show a current holder, current contacts, a plausible route origin, valid reverse-DNS delegation and no visible dispute. That does not prove that the block has no inherited reputation damage. Reputation is observed at the edge of use, not only at the point of registration.
An inherited history can sit in many places. The previous user may have sent spam, hosted phishing kits, operated open proxies, served malware, supported credential stuffing, ignored abuse complaints, run a poor VPN product, tolerated bulletproof-hosting customers or allowed compromised tenants to remain online. The bad traffic may have ended long ago. Yet third-party systems may keep the range in a risk tier because their calculations value historical association. Some vendors refresh quickly. Others depend on derivative feeds, old manual notes or customer-specific blocklists. A bank may never tell the provider which feed caused the failure.
This creates a diligence problem unlike ordinary title review. Title review asks whether the seller or holder has authority and whether adverse claims exist. Reputation diligence asks whether the address can be trusted by strangers after deployment. The evidence is different. It includes blocklist checks, mail warm-up tests, passive DNS, historical BGP, malware-hosting archives, abuse-ticket patterns, geolocation records, upstream complaint history, previous tenant categories, web-hosting reputation, customer allowlists and the experience of similar prefixes in the same netblock.
No single check is decisive. A block absent from public blocklists may still be penalised by private fraud systems. A block appearing on one list may be clean enough for some uses after a short remediation. A geolocation error may look like risk when the real issue is a stale database. A noisy neighbour may contaminate a larger aggregate even if the specific /24 is quiet. A new holder may have strong registry evidence but weak operational history. The diligence file is probabilistic.
That uncertainty affects prices and deployment choices. A buyer may demand a trial period, a right to reject addresses that fail defined tests or a lower price for ranges with unverified history. A customer may require proof that a range can pass mail, payment or procurement checks before migration. A seller may resist broad assurances because it cannot know every private feed. A broker may describe a block as clean based only on public checks, which is commercially tempting and analytically weak.
For AFRINIC-administered space, the diligence problem is compounded by old-record concerns. Reported address-theft cases showed that weakly monitored or dormant African records could become economically attractive targets once IPv4 had market value. That does not make every old block dirty. It means old blocks require better evidence. Who held the space? Was it routed? By whom? Was it delegated? Were contacts maintained? Did the address appear in blocklists? Did any intermediary use it? Was it sold, leased, recovered, reclassified or left dormant? A clean current record may be the beginning of that inquiry, not the end.
The market should become more precise about the word clean. Clean for what use? Clean over what period? Clean in which public lists? Clean in which private customer tests? Clean at the /32, /29, /24, /20 or ASN level? Clean after geolocation correction? Clean after a change of holder? Clean enough for outbound mail, payment callbacks, public-sector hosting, cloud onboarding or low-risk infrastructure? Without a use case, clean is an adjective pretending to be evidence.
Contamination spreads through neighbours, not just the guilty host
Address reputation is rarely perfectly granular. That is why innocent neighbours pay. A single compromised server may damage a /32. A spam campaign may damage a /24. A bulletproof customer may damage an ASN. A provider known for tolerating abuse may contaminate every range it touches. A fraud vendor may treat new sign-ups from a whole netblock as risky because past bad traffic came from nearby addresses. A mail receiver may throttle an entire range because fine-grained distinction is too costly.
This pooling is rational from the receiver's perspective. A bank, mail provider or security company does not exist to maximise the resale value of someone else's IP inventory. It exists to reduce fraud, spam, malware and customer harm. If its evidence says bad behaviour clusters by provider, ASN, reseller or address neighbourhood, it will use that cluster. The cost of false positives is borne by the address holder and its customers. The benefit of caution accrues to the receiver's users.
Pooling creates the contamination externality. A bad tenant's behaviour can reduce the value of neighbouring addresses. A reseller's tolerance can affect a holder's whole block. A lessor's weak customer controls can reduce future income from space used by innocent parties. A hosting provider that removes one customer may still face aggregate distrust because upstream observers remember the neighbourhood, not the corrected host. The asset is local, but the reputation is social.
The externality becomes acute in scarce markets because segregation consumes inventory. A provider can protect premium customers by isolating them in known-clean ranges, reserving separate blocks for high-risk hosting, keeping mail traffic away from generic VPS customers and avoiding mixed use between regulated and anonymous workloads. That is operationally sensible. It is also expensive. Every segmentation rule reduces fungibility. Addresses that could once have served any customer now have different trust classes.
Reputation contamination therefore creates a hidden zoning system. Some ranges become suitable for outbound mail. Some become suitable only for inbound services. Some are kept for customer categories that accept higher failure rates. Some are avoided for financial services. Some are quarantined while delistings proceed. Some carry a discount because they are close to a bad ASN or historical hoster. The market begins to price not just size and registry status, but neighbourhood quality.
This has consequences for African operators. Smaller providers often cannot afford large segregated inventories. They may have one or two meaningful blocks and a mixed customer base. If one risky customer contaminates the block, the provider cannot simply move regulated customers to a separate clean range. If a new block arrives with inherited dirt, the provider may not have spare clean addresses for the customer that complains. A large global cloud can absorb reputation zoning across portfolios. A regional hoster cannot.
Suballocation visibility affects this problem, but it is not the whole answer. Knowing which customer caused an incident helps with attribution and remediation evidence. It does not automatically repair the reputation of neighbours. The market must still decide whether the holder's controls are good enough to prevent recurrence, whether the affected range should be segregated, whether innocent customers need migration, and whether future buyers or users should be warned. Visibility is evidence. Containment is an operating design.
AFRINIC's recovery should be judged partly by whether its record environment helps operators narrow contamination. If records, role tags and update histories can distinguish holder-operated space, downstream ISP use, managed hosting, privacy-protected assignments and disputed ranges, then outsiders can aim their distrust more precisely. If the record leaves all use under one holder label, receivers and security vendors will keep using rougher clusters. Rough clusters are cheaper for them and more expensive for everyone else.
Delisting is evidence work, not a customer-support ritual
Removing a contaminated address from bad reputation is often described as delisting, as if the operator merely fills a form and waits. In practice it is evidence work across many jurisdictions of trust. Each system wants a different proof. A mail blocklist may ask that spam has stopped and reverse DNS is sensible. A security feed may ask for cleanup of infected hosts. A payment vendor may want evidence of customer vetting and low fraud rates. An enterprise allowlist owner may require a new contract contact. A law-enforcement file may not be reachable at all. A private risk engine may provide no appeal.
The first cost is discovery. The provider has to learn which systems are objecting. Customers often see symptoms before the provider does: bounced mail, failed API calls, rejected sign-ups, extra fraud checks, blocked dashboards, strange geolocation, VPN suspicion or procurement risk flags. The provider then has to separate address reputation from application error, DNS error, TLS problem, customer misconfiguration, ASN reputation and content risk. This takes senior time, not just helpdesk time.
The second cost is proof of change. Delisting bodies are understandably sceptical of claims that a range is under new management. Attackers also claim new management. A credible proof package may include registry records, corporate authority, dates of acquisition or lease, routing changes, reverse-DNS changes, customer removal, abuse-response logs, clean traffic history, monitoring reports, mail-volume ramp-up data and statements from upstreams. In AFRINIC's case, strong registry evidence can help, but if registry authority or old records are contested, external systems may demand more.
The third cost is waiting. Reputation systems do not all move on the same clock. Some public lists clear quickly when traffic stops. Others age out slowly. Private vendors may update in batches. Enterprise customers may keep old manual blocks until their next review. Payment systems may require low-risk history over time rather than a one-time proof. During that waiting period, the provider must decide whether to keep customers on the block, move them, reduce service promises or compensate them.
The fourth cost is uncertainty over false positives. IP blocklists are useful but imperfect. They vary in coverage, geography, update speed and appeal quality. They can miss malicious activity while still creating false-positive risk. That imperfection matters economically. An innocent holder may spend money proving innocence to systems that do not disclose their data. A contaminated holder may discover that absence from public lists does not mean absence from private judgement. Diligence and repair both operate through incomplete observation.
The fifth cost is coordination among parties. The registered holder may control the registry account. The operating provider may control servers. A lessee may control customers. A reseller may own the commercial relationship. An upstream may receive complaints. The customer may be the one harmed. Delisting requires these parties to produce a coherent story. If they disagree about who caused the issue, who pays or who may speak for the block, the reputation system sees confusion and remains cautious.
Delisting is therefore not an after-sales nuisance. It is a cost centre that should appear in transaction economics. A buyer should ask who pays for remediation if inherited history appears. A lessor should ask how the user must cooperate with cleanup and what happens if that user's customers create new listings. A public-sector buyer should ask whether the provider has delisting procedures and replacement capacity. A lender should ask whether address-supported revenue is exposed to unmodelled reputation repair.
The registry lesson is modest. A registry should not promise to delist what it does not control. But it can make the proof of current recognition easier, faster and more credible. It can preserve record history, publish current contacts, support accurate reverse-DNS delegation, distinguish disputes from routine changes and encourage responsible downstream evidence. Delisting belongs outside the registry. The evidence needed for delisting often begins inside it.
Movement transfers memory even when control is clear
Scarce addresses move through sales, transfers, leases, assignments, hosting plans, reseller chains and internal reorganisations. Each movement can move reputation in two directions. Bad history can travel from the prior user to the next user. New bad behaviour can travel back from a temporary user or customer to the holder. That is why address-reputation contamination matters even when the legal or registry-control question is already answered.
A transfer is the cleaner example. A buyer receives recognised control and may believe the past should stop mattering. External systems may disagree. They may continue to associate the block with an old ASN, old hosting brand, old botnet, old geolocation, old customer category or old law-enforcement case. The buyer then pays for inherited remediation. If the seller did not disclose the history, the buyer may claim it was misled. If the seller genuinely did not know, both parties may learn that public checks were insufficient.
A lease is more complicated because reputation can rebound. The holder keeps the registered relationship while another party uses the addresses. If that user sells to risky customers, ignores abuse, runs poor mail operations or permits anonymous proxy services, the holder's block may become less valuable after the arrangement ends. The user may leave with revenue. The holder keeps the dirty asset. The next buyer or user pays through lower trust. The economic object is the reusable credibility of the address, not merely the right to announce it for a period.
Transfers and leases also create ambiguity windows. During migration, some systems see the old route and some see the new. Reverse DNS may lag. Geolocation may lag. Mail traffic may begin before warm-up is complete. Abuse contacts may still point to the old desk. A private fraud engine may interpret sudden change as suspicious. Attackers exploit ambiguity, but ordinary operators also suffer from it. A reputation plan should be part of the transaction timetable, not an emergency response after customers complain.
The AFRINIC context makes these windows more sensitive because regional-use arguments and institutional recovery questions can affect how counterparties interpret movement. A block moving from a dormant holder to an active hoster may be productive reallocation. It may also trigger suspicion if the authority chain is thin or if the route appears far from the expected region. A temporary commercial use may be a rational scarcity response. It may also create a contamination path if the downstream user is opaque. The market does not need slogans; it needs evidence about what changed and who is responsible now.
The useful discipline is precision. A seller cannot sensibly promise that no private system anywhere has a negative view of the block. It can disclose known blocklist history, known abuse patterns, known law-enforcement correspondence, known hosting categories, known customer complaints, known geolocation disputes and known remediation efforts. A buyer can test the intended use before relying on the range. A lessor can require evidence of clean operation while the addresses are in use. A user can ask whether inherited reputation suits the declared workload.
The registry's narrow role is to make movement legible. It should not set the price or judge every commercial use. But when the recognised holder, operating network, route origin, reverse DNS, contact data and downstream role are aligned or clearly explained, outside systems have a better chance of updating their memory. When movement is hidden, reputation systems assume continuity with the past. In reputation economics, opacity is rarely neutral. It is usually priced as risk.
Segregation is the operating price of trust
The practical response to contamination is segregation. Providers already practise it, sometimes formally and sometimes by instinct. They keep mail-heavy customers away from anonymous hosting. They separate regulated customers from high-churn VPS pools. They reserve known-clean ranges for banks, government portals, health systems and enterprise SaaS. They avoid placing new payments infrastructure next to customers likely to trigger fraud complaints. They treat certain ranges as quarantine until history improves.
Segregation is economically rational because reputation systems often punish groups. If the receiver looks at /24 history, the provider should manage at least at /24 quality. If the receiver looks at ASN reputation, the provider should consider ASN-level customer mix. If mail systems punish sudden high-volume sending, the provider should warm up ranges and keep outbound mail away from generic hosting. If payment vendors distrust proxy traffic, the provider should not mix proxy users with regulated callbacks. Trust needs architecture.
That architecture has costs. It requires more address inventory, better internal records, customer classification, monitoring, abuse response, traffic policy, reverse-DNS discipline, geolocation management and incident review. It also requires the provider to say no to revenue. A customer who pays well but damages a block may not be profitable after reputation cost. A short-term hosting product may look attractive until it contaminates scarce inventory needed for enterprise contracts. The opportunity cost of a dirty customer is higher when clean IPv4 is scarce.
Small operators are disadvantaged. They cannot maintain many trust classes if they have little address space. They cannot easily absorb a contaminated /24. They may not have staff to run continuous reputation monitoring or negotiate with vendors. They may rely on upstream-provided addresses, which creates dependence, or lease space, which creates reputation uncertainty. The economics of reputation therefore reinforce scale. Large operators can diversify reputation risk. Small operators live with concentration.
Public-sector and regulated customers should understand this. The relevant procurement question is not only whether the provider has enough public IPv4. It is whether the provider has address-reputation controls appropriate to the service. Does it know the history of the blocks offered? Does it segregate high-risk customers? Can it replace a range if a private fraud system objects? Does it maintain reverse-DNS and mail discipline? Does it keep evidence of current control? Does it have an escalation path for blocklists and payment vendors? These are continuity questions, not technical luxuries.
For AFRINIC-administered space, segregation also interacts with scarcity. If new allocations are small, and if existing supply moves through transfers and leases, then reputation class becomes a hidden allocator. Clean space goes to customers who can pay for assurance. Questionable space goes to workloads with lower trust demands. Some operators may be priced out of clean ranges. Others may accept contaminated space because it is all they can obtain. That distribution has development consequences even if no one calls it policy.
Segregation should not be confused with discrimination against legitimate but risky categories. Security research, VPNs, hosting, mail, scraping-sensitive services, high-churn development environments and small businesses all need infrastructure. The point is not to ban them. The point is to price and contain the reputation risk they create. A mature address market lets providers match customer risk to address reputation class honestly. An immature one mixes everything, waits for contamination, then argues about blame.
The cleanest economic rule is simple: the customer that creates reputation risk should bear more of the cost, and the holder that profits from that customer should maintain enough controls to protect innocent neighbours. If neither happens, contamination becomes a subsidy from careful users to careless ones.
Registry restraint matters because reputation systems are already punitive
One temptation in a contaminated market is to ask the registry to fix the problem by becoming more aggressive. If abuse history damages innocent users, perhaps the registry should inspect customers, punish holders, block certain uses, judge commercial categories or reclaim space. That instinct is understandable and dangerous.
Reputation systems are already punitive. Mail receivers, fraud vendors, security feeds and upstreams can impose real costs without court action, registry action or even disclosure. A provider can lose deliverability, customer trust and revenue because a private risk calculation changes. The fact that these systems are imperfect does not make them illegitimate; they protect their own users. But it does mean the address ecosystem already contains many mechanisms for punishment and exclusion. Adding broad registry discretion on top can multiply uncertainty.
The registry's comparative advantage is not moral judgement. It is record integrity. It can keep accurate holder data, preserve history, support reverse DNS, enable security publication, process authorised changes, record disputes narrowly, require current contacts and correct demonstrable registration fraud. Those functions help markets separate current responsibility from past contamination. They do not require the registry to become a reputation court for every customer or workload.
AFRINIC's history illustrates the risk of overextension. Address-record manipulation reporting created a legitimate demand for stronger record controls. The Cloud Innovation dispute and surrounding debate showed how questions about use, region and registry authority can escalate into existential institutional conflict. Receivership and election problems showed that the registry itself can become fragile under high-stakes pressure. In such a setting, expanding discretion may feel like restoring order, but it can also increase the prize value of controlling the registry.
A narrow registry lowers the prize. If AFRINIC's role is limited to verifiable records, technical publication, due process and continuity, capturing or influencing it yields less power over commercial outcomes. If its role expands into judging which uses are reputationally acceptable, which customers deserve service or which holders should lose resources because external systems distrust them, then registry control becomes a market weapon. That would not solve reputation contamination. It would add another layer of contamination: institutional fear.
The better response is structured evidence and bounded consequences. If a block has abuse history, the holder should be able to show current controls. If a downstream user caused harm, the holder should identify and contain that user. If a record is false, the registry should correct it. If downstream use is hidden, the registry can require more accurate role information. If a reputation problem belongs to a private blocklist, the registry can support proof of current recognition but should not pretend to order the private party to trust the block.
This restraint benefits victims as well as holders. An innocent operator inheriting dirty space needs evidence that it is different from the prior offender. It does not need a registry that makes every reputation complaint a potential resource dispute. A customer harmed by a contaminated neighbour needs containment and migration. It does not need the whole holder thrown into uncertainty. A public agency needs a traceable escalation path. It does not need an opaque registry fight that interrupts service.
Reputation contamination is a reason to improve market hygiene, not a reason to abandon institutional boundaries. The more punitive the external trust systems become, the more important it is that the registry remain boring, precise and reviewable. AFRINIC's lesson is that a fragile ledger should not seek strength by becoming a gatekeeper over every memory attached to the numbers.
Courts and recovery do not reset external memory
Court orders, receivership and board recovery can repair institutional authority. They can restore decision-making, preserve operations, restart elections, clarify member rights and help a registry resume ordinary functions. They cannot reset address reputation by themselves. The internet's second ledger does not obey corporate restoration.
That distinction matters for AFRINIC. Receivership was described as a way to preserve operations and restore governance. Later elections and board actions signalled a path back toward normal administration, even as litigation and recovery questions continued. These are important for the registry. They tell members whether the institution can process requests, maintain services and make decisions. But a payment-fraud vendor evaluating a prefix does not simply ask whether AFRINIC has a board. A mail receiver does not automatically trust a range because a court-supervised period preserved the registry. A customer does not forget failed callbacks because governance is improving.
Institutional repair helps indirectly. A stable registry can produce better records, faster updates, clearer dispute states and more credible continuity. It can separate old authority problems from current operating facts. It can reduce the general risk premium that counterparties apply to AFRINIC-administered resources. It can make delisting evidence easier. It can reassure buyers that future changes will not be trapped in institutional paralysis. These are real gains.
But reputation systems remember behaviour. If a block was used for spam, the receiver wants evidence that spam has stopped. If a range was associated with botnet traffic, the security vendor wants clean observation over time. If a previous tenant caused payment fraud, the processor wants lower fraud rates and perhaps new customer data. If a public-sector customer saw service failures, it wants a continuity plan. Governance recovery is not a substitute for operational rehabilitation.
This creates a sequencing problem. AFRINIC's recovery may reduce the institutional component of the discount before it reduces block-level reputation costs. A buyer may become more comfortable that the registry can process a transfer, while still discounting particular ranges for old abuse. A lessor may regain confidence in account services, while still treating risky users cautiously. A provider may trust reverse-DNS updates, while still warming up mail traffic for months. Recovery narrows one uncertainty. It does not erase all memory.
The same point applies to legal victories by holders. A court-recognised position can be powerful evidence of authority. It may help prove that a holder has rights in the registry relationship or that a previous registry action was constrained. It does not prove that every address in the portfolio is reputationally clean. Authority and reputation are related but separate. Markets should not treat legal recognition as reputational amnesty, nor should they treat reputation problems as proof of bad title.
The practical lesson is to keep institutional recovery and asset rehabilitation separate in the diligence file. One section should ask whether AFRINIC's current governance and services can support the needed registry actions. Another should ask whether the specific block's reputation history supports the intended customer use. A third should ask whether evidence exists to separate prior use from current control. Combining them creates confusion. A stable registry with a dirty block is still a dirty block. A stressed registry with a clean, well-documented block is not automatically dirty.
AFRINIC's recovery will therefore be measured not only by formal governance, but by whether operators can use the recovered institution to produce credible proof for external trust systems. The route can come up in minutes. Institutional trust takes longer. Address reputation may take longer still.
A clean address market needs remediation evidence, not faith
A mature market in scarce IPv4 cannot assume that every address block is clean. Nor can it treat every historical stain as permanent. It needs a middle discipline: reputation evidence that is specific enough to price, repair and allocate risk.
The first element is pre-transaction diligence. Buyers, users and major customers should test intended uses before closing or deployment. Public blocklist checks, mail tests, geolocation review, passive DNS, malware-hosting history, route-history review, ASN and upstream reputation, prior reverse-DNS patterns, known hosting categories, abuse-ticket review where available, and customer-specific tests for payments or regulated services all have a role. The result should not be a binary clean or dirty label. It should classify intended use: suitable now, suitable after warm-up, suitable only for non-sensitive workloads, unsuitable without remediation or unacceptable for the buyer's purpose.
The second element is disclosure. Sellers and lessors should disclose known reputation issues, prior high-risk customers, unresolved complaints, delisting efforts, geolocation conflicts, law-enforcement notices, botnet associations and periods of suspicious hosting. They should not be expected to know every private judgement in the world. But they should not market a block as clean while withholding known defects. Buyers should disclose intended use because reputation suitability depends on workload.
The third element is remediation evidence. If a block has history, the market should ask what changed. Was the bad customer removed? Did the route origin change? Were reverse-DNS records corrected? Did mail sending stop and restart under controlled volumes? Were abuse contacts updated? Did the holder implement customer vetting? Did relevant lists remove the block? Has clean traffic been observed for a meaningful period? Are neighbouring ranges still dirty? Remediation is a story told with dates, records and behaviour.
The fourth element is commercial allocation of risk. The parties should know who handles inherited reputation defects, who leads delisting, when replacement space is operationally necessary, what tests matter for the declared use, how new contamination is documented and how customer migration will be handled if private systems refuse to clear the range. These arrangements should be tied to evidence, not vague claims about bad reputation. Vague reputation language becomes a dispute. Testable reputation evidence becomes a price.
The fifth element is segmentation. Providers should maintain internal trust classes for address inventory. A range used for high-risk hosting should not be casually resold as a clean financial-services block. A block with successful mail history should be protected from customers likely to damage it. A range returning from temporary use should come back with a file showing routing, reverse DNS, abuse events, customer categories and delisting status. Segmentation converts reputation from folklore into inventory management.
The sixth element is registry support without registry overreach. AFRINIC can help by making current recognition, history, contacts, role information, reverse-DNS authority, dispute status and authorised changes precise. It can preserve historical record transitions so a new operator can prove when control changed. It can encourage holders to maintain downstream responsibility records. It can process legitimate updates predictably so external systems see coherent facts. It should not promise to certify that a block is reputation-clean. That would be false assurance.
The seventh element is market humility. Reputation systems can be stale or unfair. Holders can be evasive. Customers can be innocent. Bad actors can exploit new ranges. Registries can overreach. No single institution sees the whole picture. The answer is not faith in the registry, faith in blocklists, faith in brokers or faith in buyers. The answer is evidence that is narrow, dated, challengeable and tied to the intended use.
In such a market, AFRINIC-administered IPv4 would not become free of reputation risk. No scarce address market can promise that. But the risk would be more accurately allocated. Clean blocks would command cleaner prices. Contaminated blocks would carry discounts matched to use. Innocent successors would have a path to prove change. High-risk customers would pay for the damage they can cause. Public-sector and regulated buyers would know what questions to ask. The registry would remain the record layer, not the reputation court.
That is the economics of address-reputation contamination. IPv4 scarcity has turned address history into capital history. A prefix now carries memory in systems that are outside the registry and often outside the holder's view. AFRINIC matters because its scarcity, record-integrity history and governance stress make the cost of that memory visible. The block may route. The market asks a colder question: who remembers it, who believes the memory, who can change it, and who pays while everyone waits?