The Policy Mirror

How AFRINIC’s 2026 Rules Turn the Registry from Ledger into Capital Control

A policy manual is not only a set of rules. It is a confession of institutional imagination.

It tells us what the institution thinks it is.

A narrow registry writes narrow rules. It says: here is the holder of this number resource; here is the public contact; here is the route-object environment; here is the chain of control; here is the conflict state if a dispute exists; here is the security assertion if one has been made. It protects uniqueness. It protects accuracy. It protects interoperability. It protects the ability of independent networks to keep operating without asking permission from a political room.

A sovereign registry writes different rules. It speaks of stewardship. It speaks of regional resources. It speaks of the community as if the community were a legal principal. It speaks of need, conservation, fairness, compliance, proper use, regional eligibility, transfer conditions, abuse handling, support eligibility, revocation, and confiscation. It decides not only who is recorded, but who is allowed to transact, where value may move, which commercial models are morally tolerable, and when an operational asset can be trapped inside an institutional boundary.

That is the real meaning of AFRINIC’s policy framework.

The interesting point is not that AFRINIC has a transfer policy. Every registry needs a transfer mechanism once IPv4 becomes scarce. The interesting point is how the policy is written. The 2026 ratified transfer policy does not merely record transfers. It classifies number resources by origin and region, restricts some resources from leaving the AFRINIC region, requires AFRINIC’s written approval for transfers, refuses to recognise transfers made outside AFRINIC-approved channels, and makes incoming resources subject to AFRINIC’s policy regime. The new abuse-contact policy does not merely require a reachable contact. It creates a compliance duty, periodic verification, escalation, and eventual contractual breach exposure. The older Consolidated Policy Manual supplies the deeper soil: public-resource language, anti-property assumptions, conservation doctrine, non-portability assumptions, purpose-based assignment restrictions, and bottom-up consensus theory.

None of this is accidental. It is the natural result of a registry that forgot it was a ledger.

The registry layer was justified by a small technical problem. Internet number resources must be unique. Different networks must not unknowingly claim the same identifiers. Public records must make troubleshooting possible. Security assertions must be understandable by relying parties. Transfers must be recorded so that the ledger does not lie. That is enough to justify a registry. It is not enough to justify a private institution’s control over the economic use, geographic movement, commercial leasing, transferability, capital treatment, or operational fate of scarce assets.

The moment IPv4 became scarce, the old registry language stopped being harmless. When a resource had no meaningful market value, a registry’s moral vocabulary was cheap. Calling address space a public resource, denying property language, enforcing need, discouraging hoarding, and requiring renumbering sounded like administrative hygiene. Once IPv4 became valuable, financeable, leased, sold, pledged, litigated, and operationally embedded, the same language became an asset-control system.

This is the moment the RIR model crossed the line.

A registry is not a state.

A service region is not a people.

A policy meeting is not a legislature.

A database contact is not a corporate power of attorney.

A community consensus is not ownership.

A registry record describes reality; it does not create it.

AFRINIC’s policy mirror shows the whole system. It shows how a bookkeeper learns to speak like a sovereign. It shows how technical coordination becomes capital control. It shows how “community” becomes a mechanism for laundering mandate. It shows how a private-law registry claims public-resource authority while avoiding public-law accountability. It shows why Running-Code Primacy is no longer a slogan. It is the only disciplined test left.

The question is simple: what does running code actually require?

It requires uniqueness. It requires a reliable record. It requires contactability. It requires fraud control. It requires security metadata. It requires dispute isolation. It requires transfer recording. It requires operational continuity. It does not require a regional embargo on IPv4 capital. It does not require a registry to decide whether a network’s customers are sufficiently local. It does not require forced renumbering when a customer changes provider. It does not require a private registry to decide whether number resources are commodities. It does not require abuse-contact verification to become a revocation pathway. It does not require needs assessment after scarcity has already transformed IPv4 into a market asset. It does not require unregistered use to be called invalid as if the registry were the source of operational truth. It does not require a community room to speak for companies, states, end users, investors, or the Internet as a whole.

The correct policy reform is not to make AFRINIC a better sovereign. The correct reform is to end the sovereignty claim.

This note sets out the policy conflict in full. It then proposes concrete amendments. The amendments are not cosmetic. They are not a request for softer enforcement. They are a different constitutional design for the number-resource layer: thin common rules, local operator autonomy, voluntary adoption, mandatory portability, registry/enforcement separation, and dispute-proof operational continuity.

I. The policy’s first mistake: custody becomes ownership without the word ownership

The older AFRINIC policy framework uses the vocabulary of stewardship. It describes IPv4 allocation and assignment as the management of a “public resource.” It places AFRINIC in the role of custodian. It says registration is necessary to ensure uniqueness and to support troubleshooting. It also says conservation requires actual need, immediate use, and avoidance of stockpiling. It asks the registry to balance the needs of applicants against the interests of the Internet community.

There is a legitimate version of that paragraph.

Uniqueness is legitimate. Registration is legitimate. Contact accuracy is legitimate. Fraud prevention is legitimate. Allocation from an unallocated free pool needed criteria before market transfer became the dominant reality. The problem is not that a registry once required a reason before issuing scarce numbers from an unallocated pool. The problem is that AFRINIC did not clearly separate a free-pool allocation rule from a continuing control theory over resources already in operational use.

That distinction is the legal and economic core.

A state may allocate public land under statutory authority and then define property rights. A private registry is not a state. It cannot borrow public-resource language to create a permanent reversionary interest in assets used by operators, paid for by operators, relied upon by customers, priced by markets, and defended in courts. If the registry wants to say resources are not owned, it must also accept the consequence: it is not the owner either. It may be a recordkeeper. It may be a coordinator of uniqueness. It may be a service provider. It may not be the landlord of the address economy.

AFRINIC’s language tries to have both sides.

It says number resources are not unrestricted property. It says they are administered in trust. It says rights of use are subject to agreement and policy compliance. It says certain resources cannot move out of region. It says unauthorised transfers may be reclaimed. It says abuse-contact non-compliance can become a contractual breach with revocation exposure. It says the registry does not assign monetary value and that number resources are not commodities for speculation. It also says the registry has no broad legal responsibility for the commercial consequences of transfers and that due diligence belongs to the parties.

That combination is economically unstable.

If AFRINIC has the power to block value movement, it affects value. If it affects value, it is exercising economic power. If it exercises economic power, it must carry liability, representation, and procedural discipline proportional to that power. If it refuses liability, it must reduce power. There is no third category in which a private registry can control capital movement while describing itself as a neutral custodian.

This is the first policy amendment required: the policy manual must stop using ownership-like control without ownership-like accountability. It must define the registry function as recordkeeping and coordination, not stewardship over regional capital.

Proposed amendment 1: replace stewardship language with registry-function language

Current defect: The policy framework treats AFRINIC as custodian of a public resource and imports community-balancing language into rules that affect valuable operational assets.

Replacement principle: AFRINIC’s policy authority is limited to registry functions necessary for uniqueness, registry accuracy, security assertions, fraud prevention, transfer recording, and operational continuity.

Proposed text:

AFRINIC’s registry function is to maintain accurate, auditable, and interoperable records of Internet number-resource control for resources administered through the AFRINIC registry system. AFRINIC’s role is limited to protecting uniqueness, maintaining public registry accuracy, supporting routing-adjacent and security-relevant coordination, recording transfers and changes of control, preventing fraud in registry records, and preserving operational continuity. Nothing in this policy shall be interpreted as creating ownership, sovereign authority, territorial title, commercial-control authority, or reversionary economic interest in favour of AFRINIC or any policy community.

This single paragraph would remove the fiction at the source. It would not destroy the registry. It would save it.

A registry that knows it is a registry can be useful. A registry that thinks it is a state becomes dangerous.

II. The conservation doctrine died when the free pool died

Conservation was the great moral argument of the allocation era. It sounded reasonable because it solved a real problem: if a registry has a finite free pool and applicants request resources, there must be a method to decide who receives them. Need-based allocation was one such method. It was never perfect, but it had a technical-administrative rationale: avoid waste while resources were still being issued from a common pool.

That world is gone.

After exhaustion, conservation changes meaning. It no longer allocates a free public pool. It restricts private movement of scarce operational capital. It becomes a control device. It suppresses liquidity. It raises transaction costs. It increases hold-up risk. It creates artificial scarcity in one place while unused or underused resources remain trapped elsewhere. It rewards political navigation over economic deployment. It penalises networks that need flexibility. It creates a grey market because the official channel is too slow, too discretionary, or too ideologically hostile to trade.

Economics is not sentiment. Scarce assets move toward higher-valued use when transfer costs are low and rights are clear. That movement is not immoral. It is how capital stops being dead inventory. When a registry restricts transferability, it does not create fairness. It creates a wedge between the asset’s operational value and its legal usability. The wedge is paid by someone: smaller networks that cannot access supply, operators that cannot monetise idle inventory, customers that pay higher service prices, investors that discount network assets, and states that carry infrastructure risk while a private registry retains administrative veto power.

A conservation rule for unallocated free-pool issuance is one thing. A conservation rule over already allocated IPv4 is another. The first is a queue discipline. The second is capital control.

The policy manual fails to make that distinction with sufficient force. It continues to speak as if stockpiling, reservations, and actual need remain general moral principles across the IPv4 life cycle. The transfer policy repeats the same error by keeping needs assessment and compliance gates inside transfers. It is a category mistake.

A registry can require proof that a transferor controls the block. It can require proof that there is no duplicate registry claim. It can require accurate contact and organisation records. It can require acknowledgement of registry-service terms. It can record disputes. It can refuse to publish a transfer if the source is not the holder of record or if a court or independent adjudicator has frozen the resource. It does not need to ask whether the recipient has a plan that satisfies the registry’s forecast of need. The recipient’s need is revealed by the price it is willing to pay and the operational risk it is willing to bear.

Need assessment after market purchase is not engineering. It is central planning.

The registry does not know the buyer’s future business better than the buyer. It does not bear the buyer’s capital cost. It does not pay the buyer’s customers when deployment fails. It does not finance the buyer’s infrastructure. It does not carry the opportunity cost of a delayed transaction. It therefore should not be the decision-maker.

Proposed amendment 2: split free-pool allocation from market transfer

Current defect: The policy framework uses conservation and need as broad principles, allowing allocation-era logic to contaminate transfer-era reality.

Replacement principle: Need-based criteria may apply only to allocations from an unallocated AFRINIC free pool. They shall not apply to transfers, leases, sub-assignments, mergers, acquisitions, financing arrangements, or changes of operational control involving already allocated resources.

Proposed text:

Need-based allocation criteria apply only to distribution of unallocated resources from an AFRINIC-administered free pool. Once a number resource has been allocated or assigned and is held by a recognised resource holder, subsequent transfer, lease, sub-assignment, financing, operational delegation, merger-related movement, acquisition-related movement, or other change of use shall not be denied on the basis of AFRINIC’s assessment of business need, deployment timing, customer geography, commercial model, pricing, or conservation preference, provided that uniqueness, registry accuracy, proof of control, and applicable dispute-status requirements are satisfied.

This amendment would not create chaos. It would remove a false control point.

The scarcity problem is not solved by freezing assets. It is solved by allowing assets to move.

III. Regionalism as capital control

The 2026 transfer policy reveals the most important conflict. It creates a taxonomy of resources. Some are regional. Some are reserved. Some are legacy. Some are global. Only certain categories may move out of the AFRINIC region. AFRINIC-issued IPv4 is effectively locked within regional transfer conditions. Legacy and inbound transferred resources receive different treatment. Inbound resources can become subject to AFRINIC policy. Certain resources lose legacy status after transfer. All of this is presented as a controlled method of redistribution that protects the remaining AFRINIC pool and reinforces AFRINIC’s role as authoritative registry.

This is not thin technical coordination. It is capital control.

An IP address does not become more or less unique depending on which region uses it. A route does not carry a passport. BGP does not ask whether the holder’s revenue is African, European, Asian, or American. RPKI does not validate a prefix because its customers live inside a service boundary. The Internet is not a customs union.

Regional administration may be convenient for registry service delivery. It is not a title system. The region is an administrative service area, not an economic cage. When AFRINIC says regional classification is not a visible label, not a routing right, and not a day-to-day use restriction, it concedes the point that matters. The classification exists mainly to determine transfer rules. In plain English: the label is used to control movement of value.

That is the policy mirror.

The argument for regional lock-in usually wears the language of African development. It says address resources should remain available to African networks. It says scarcity must not be exported. It says unrestricted transfer would drain the region. This argument sounds compassionate until its economics are examined.

A transfer restriction does not create more addresses. It creates illiquidity. It lowers the value of resources held by African networks because their exit market is restricted. It reduces collateral value. It reduces incentive to discover underused supply. It discourages inbound resources because rational sellers will fear being trapped inside a one-way jurisdiction. It creates a policy discount on AFRINIC-registered resources. It also encourages informal transfers, leasing structures, nominee arrangements, routing without clean registry records, and legal disputes over control.

The region does not become richer because its assets cannot leave. It becomes poorer because its assets cannot be fully priced.

If the policy goal is to help African networks obtain IPv4, the correct tools are market liquidity, transparent transfer recording, financing mechanisms, leasing recognition, anti-fraud rules, open information, and reduced registry transaction costs. A regional embargo does the opposite. It suppresses price discovery and tells capital that once it enters AFRINIC, it may not freely leave. Capital responds predictably: it demands a discount or avoids entry.

This is not ideology. It is asset pricing.

A resource that can be sold globally is worth more than a resource that can only be sold regionally. A resource that can be pledged is worth more than a resource that cannot be pledged. A resource that can be leased openly is worth more than a resource that must be hidden behind policy ambiguity. A resource that can move to a successor registry is worth more than a resource trapped in a failing registry. A resource that is protected from unilateral deregistration is worth more than a resource whose existence depends on a private-law institution’s interpretation of community policy.

The transfer policy therefore imposes a poverty penalty while claiming to protect the poor.

It takes the address assets most likely to be held inside the AFRINIC region and reduces their liquidity. It tells African operators that their holdings are less mobile, less financeable, and less globally marketable than comparable resources elsewhere. It then describes this as stewardship.

This is why regional resource protection fails from first principles. Protection that destroys exit value is not protection. It is lock-in.

Proposed amendment 3: abolish regional outbound embargoes

Current defect: The transfer policy restricts outbound transfer of AFRINIC-issued IPv4 and treats regional classification as a basis for economic movement control.

Replacement principle: Any number resource held by a recognised resource holder should be transferable to any technically compatible registry or successor registration system, subject only to proof of control, uniqueness, registry accuracy, security continuity, and dispute-status safeguards.

Proposed text:

No number resource shall be restricted from transfer on the basis of AFRINIC origin, regional classification, intended region of use, customer geography, purchaser location, seller location, commercial price, or policy preference for regional retention. AFRINIC shall process outbound and inbound transfers for all recognised resource holders where the transferor has demonstrated control, the resource is not subject to an active duplicate-claim or fraud hold, the transferee has provided accurate registry information, and security and registry-continuity records can be updated without impairing uniqueness or interoperability.

A region that wants more Internet infrastructure should make its registry more liquid, more reliable, and less dangerous. It should not build a capital wall around its operators.

IV. The authorised-transfer monopoly

The transfer policy says resources are not transferable unless AFRINIC has expressly approved the transfer in writing. It also says AFRINIC will not recognise transfers outside approved policies and that resources transferred outside policy may need to be returned to the appropriate registries. It requires compliance checks. It includes due diligence. It may require recipients to satisfy AFRINIC policies and agreements. Staff assessment notes that processing can be resource-intensive, that agreements may need revision, and that AFRINIC’s role should be facilitator without legal responsibility.

This is the classic pattern of registry control without registry liability.

A registry must record transfers. That is legitimate. But there is a difference between recording a transfer and authorising the economic transaction. In a proper registry model, the parties transact. The registry verifies control, checks for conflicting claims, updates the record, preserves security continuity, and publishes the result. It may reject a record update for objective reasons. It should not own a discretionary veto over the transaction itself.

The current model reverses the order. The transfer is treated as valid only if the registry approves. That makes the registry the gatekeeper of asset movement. Once the registry is gatekeeper, every delay becomes a tax. Every unclear requirement becomes a risk premium. Every discretionary rejection becomes a hidden expropriation. Every policy ambiguity becomes bargaining power.

This is bad economics and bad registry design.

Transaction-cost economics teaches a simple lesson: when an asset is specific, scarce, and operationally embedded, discretionary approval rights create hold-up. The party controlling the bottleneck can extract value even without formal ownership. It can delay. It can demand more information. It can reinterpret rules. It can attach conditions. It can threaten non-recognition. It can turn uncertainty into submission.

In ordinary commercial markets, this is why property systems prefer clear title, objective recording, and predictable transfer rules. A land registry records title. It does not decide whether the buyer’s planned factory is morally sufficient, unless a separate zoning authority with public-law mandate says so. A securities depository records settlement. It does not decide whether the investor is making a speculative bet, except where a defined regulatory framework applies. A vehicle registry records ownership and safety compliance. It does not decide whether the buyer’s business model improves the region.

AFRINIC wants the power of all three systems and the liability of none.

If AFRINIC only facilitates, it must not veto except on objective registry grounds. If it has discretionary veto power, it cannot disclaim responsibility for commercial consequences. The policy cannot say: we must approve, but we are not responsible; we control recognition, but we do not price value; we can reject transfers, but we do not bear the cost; we can require compliance, but the parties carry due diligence; we can reclaim unauthorised transfers, but we are only custodians.

That is not stewardship. It is asymmetric control.

Proposed amendment 4: convert transfer approval into objective registry recording

Current defect: Transfers require AFRINIC’s prior written approval and unapproved transfers are treated as non-recognised or reclaimable.

Replacement principle: The registry’s role is to record changes of control after objective verification. It may reject only for enumerated registry defects.

Proposed text:

AFRINIC shall not act as an economic authorising body for number-resource transfers. AFRINIC shall record a transfer upon receipt of sufficient evidence that: (a) the transferor is the recognised holder or legally authorised representative of the recognised holder; (b) the resource is uniquely identified; (c) no active duplicate-claim, fraud hold, court order, or independent adjudicative hold prevents record update; (d) the transferee has supplied accurate registry-contact and organisation information; and (e) continuity of associated registry, reverse-DNS, and security records can be preserved or transitioned. AFRINIC may reject or defer a transfer only for one of these enumerated reasons and must provide a written reason, evidence basis, and appeal path within a defined service period.

This amendment restores the registry to its proper role. It does not weaken accuracy. It strengthens it by making formal recording safe, fast, and predictable.

The easiest way to create unregistered transfers is to make registered transfers impossible.

V. Unauthorised transfers should create conflict metadata, not confiscation

The transfer policy’s treatment of unauthorised transfers is especially dangerous. If a transfer occurs outside approved policy, AFRINIC may refuse recognition and require return or reclaim. This treats registry non-recognition as if it were a cure. It is not.

In the real Internet, a transfer can have multiple reality layers. A contract may exist. Payment may have been made. Operational control may have changed. The prefix may be routed by the transferee. Customers may rely on it. A court may have recognised some interest. Another registry or security system may have received related data. The AFRINIC database may not yet reflect the reality. When those layers diverge, the registry has two choices.

It can lie by pretending the registry record is the only reality.

Or it can record the conflict.

Running-Code Primacy requires the second answer. The registry should not erase operational reality because the transaction did not pass through the preferred ritual. It should identify the conflict state, notify affected parties, preserve the last verified record, accept evidence, and route the dispute to a neutral process. The goal is not to reward informal transfers. The goal is to prevent the registry from becoming an executioner.

Calling a resource “invalid” or “reclaimable” because the registry did not approve a transaction does not protect the Internet. It destabilises it. It creates fear. It makes parties hide evidence. It turns the database into a weapon. It may produce duplicate claims, broken reverse-DNS arrangements, broken ROAs, customer outages, and litigation.

A registry should have a conflict-status field before it has a confiscation theory.

This is the difference between a ledger and a throne.

Proposed amendment 5: replace reclaim with dispute-state recording

Current defect: Non-approved transfers may be non-recognised and subject to return or reclaim.

Replacement principle: Where a transfer is alleged outside the registry process, AFRINIC should preserve operational continuity and record dispute metadata rather than confiscating or invalidating resources.

Proposed text:

Where AFRINIC becomes aware of an alleged change of control not yet recorded through the registry process, AFRINIC shall not revoke, reclaim, invalidate, remove, or reassign the resource solely on that basis. AFRINIC shall preserve the last verified registry state, create a public or access-controlled conflict-status record as appropriate, notify known affected parties, invite evidence of control and authorisation, and refer unresolved disputes to an independent adjudicative or court-recognised process. Registry records shall be updated only upon objective proof of control, agreement of the parties, final adjudication, or other defined evidence standard. Operational continuity shall be preserved during the dispute unless a duplicate-use, fraud, security-integrity, or court-ordered exception applies.

This amendment would make the registry more truthful. It would also reduce litigation, because parties would no longer need emergency court action to stop the registry from turning a database ambiguity into an existential threat.

VI. Legacy status and the import trap

The transfer policy distinguishes legacy resources, regional resources, reserved resources, and global resources. It allows some legacy resources to move more freely. But it also creates a trap: inbound resources may become subject to AFRINIC policies; legacy status can be lost; recipients may need to sign AFRINIC agreements; transfers may drag assets into a policy environment they did not choose.

This is bad design.

The policy should encourage inbound liquidity. AFRINIC-region networks need access to IPv4 supply. If the registry tells sellers and buyers that imported resources may lose legacy protections, become subject to new compliance burdens, or face future outbound restrictions, rational parties will demand a discount or avoid AFRINIC. That makes African networks worse off.

An inbound resource should not be treated as prey.

The registry’s interest in inbound transfers is simple: ensure uniqueness, ensure accurate record, ensure security continuity, ensure reachable contacts, ensure no duplicate claim. It does not need to strip legacy status. It does not need to convert the block into a fully controlled regional object. It does not need to impose retroactive policy theories. It needs to keep the database honest.

Imported capital must be allowed to leave. Otherwise it will not enter.

That principle is elementary. A country that wants foreign capital does not begin by announcing that exit is prohibited. A registry that wants inbound IPv4 should not do the same. The problem is worse for IP addresses because the asset is globally interoperable. The network can route globally whether the registry approves or not. If registry rules are too hostile, the market will route around the registry. The database becomes less authoritative, not more.

Proposed amendment 6: preserve inbound status and outbound freedom

Current defect: Inbound resources may lose status or become trapped inside AFRINIC’s policy regime.

Replacement principle: Imported resources should retain their status unless the holder voluntarily opts into a different status, and all resources should remain transferable out.

Proposed text:

A number resource transferred into the AFRINIC registry system shall retain its pre-transfer legacy or equivalent status unless the recognised holder expressly elects otherwise in a separate written instrument. Acceptance of AFRINIC registry-publication services shall not by itself convert legacy or equivalent resources into AFRINIC-issued regional resources, create AFRINIC ownership or reversionary control, or restrict future outbound transfer. The holder may use AFRINIC registry, reverse-DNS, RPKI, and contact-publication services under narrowly defined service terms without surrendering pre-existing transferability, legal status, or ownership-like reliance interests.

This amendment aligns incentives. It tells global holders that AFRINIC is a registry service provider, not an asset trap.

That is how a region attracts resources.

VII. The abuse-contact policy: the thin rule and the thick rule

The abuse-contact policy contains a legitimate kernel. Every number resource should have a reachable abuse contact. The public database is less useful if no one knows where to send operational reports. A contact object is a registry record. Validating that the mailbox exists is within the registry function. Requiring that the contact be attached to relevant objects is within the registry function.

The problem begins when contactability becomes compliance jurisdiction.

The policy says the abuse mailbox must be valid, monitored, and actively managed. It requires that the contact be unrestricted through WHOIS, APIs, and future services. It allows AFRINIC to validate at creation, update, periodically, and whenever AFRINIC sees fit. It allows failures and fraudulent behaviour to be reported to AFRINIC. It says support service may be offered only to members who comply. Staff assessment says non-compliance can be a breach of the RSA and persistent non-compliance may lead to revocation.

This is too much.

A registry may verify that an address accepts mail. It may verify that a holder maintains a contact object. It may flag non-responsive contact data. It may publish validation status. It may refuse to certify the contact as valid. It may ask for correction. But it should not transform abuse handling into a revocation lever.

There are several reasons.

First, abuse is not a registry-native category. Spam, malware, phishing, copyright complaints, fraud, defamation, harassment, scanning, botnet traffic, and contractual abuse reports are not the same thing. They involve different laws, facts, jurisdictions, evidence standards, and remedies. The registry cannot become the universal intake point for Internet wrongs.

Second, mailbox monitoring is not the same as legal responsibility. A holder may receive reports and reject them. It may require a form. It may prioritise reports according to internal risk. It may need to protect customer privacy. It may be a transit provider with no direct customer relationship to the actor alleged to have caused harm. It may receive automated garbage, extortion emails, forged complaints, competitive harassment, or state-pressure requests. A registry cannot infer misconduct from non-response.

Third, “whenever AFRINIC sees fit” is not a rule. It is discretion. Discretion over a contact object becomes dangerous when connected to RSA breach and revocation. The registry should not have an open-ended trigger to create default risk.

Fourth, revocation for abuse-contact failure is disproportionate. The failure to maintain a mailbox can be corrected. It does not create duplicate numbering. It does not break uniqueness. It does not by itself create a routing-security failure. It may reduce the database’s usefulness. That warrants a data-quality flag and corrective process, not the death penalty.

Fifth, the policy’s own history shows the problem. Before ratification, adoption of the older abuse-contact mechanism was extremely low. Low adoption at that scale does not prove that thousands of operators are malicious. It proves that the policy did not match operational incentives. When a rule has near-zero adoption, the right institutional response is not to bolt it onto revocation. The right response is to reduce it to the minimum useful requirement: one reachable contact, objective validation, no operational-liability expansion.

A thin abuse-contact rule is good. A thick abuse-enforcement rule is mandate laundering.

Proposed amendment 7: limit abuse contact to directory accuracy

Current defect: The abuse-contact policy expands from contact publication into operational compliance and possible revocation.

Replacement principle: Abuse-contact rules should be limited to registry-directory accuracy and objective reachability.

Proposed text:

Each registered number resource shall reference an abuse-contact record containing at least one electronic contact method capable of receiving ordinary abuse-related notices. AFRINIC may verify the technical reachability of the contact method through objective automated means. Verification shall be limited to confirming deliverability or receipt capability and shall not assess the substance, adequacy, speed, legal sufficiency, or outcome of the resource holder’s abuse-handling process. Failure to maintain a reachable abuse contact may result in a registry data-quality flag, notice to the holder, and temporary limitation of registry-update requests unrelated to correction of the contact data. Such failure shall not by itself constitute grounds for resource revocation, deregistration, RPKI invalidation, reverse-DNS removal, transfer denial, or termination of registry recognition.

This amendment preserves the useful part and kills the dangerous part.

The registry should publish the door. It should not police what happens inside the building.

VIII. Contact verification must be predictable

The abuse-contact policy allows periodic validation and validation whenever AFRINIC sees fit. It also allows the Board to amend validation periods. This is structurally wrong.

A validation regime must be objective. It must have defined triggers. It must be proportionate to the risk. It must avoid false positives. It must avoid using automated failures as legal defaults. It must recognise that email systems fail for ordinary reasons: spam filters, DNS errors, temporary outages, greylisting, provider failures, staff turnover, merger integration, and security controls. It must not create a path where a temporary email issue becomes an institutional weapon.

The correct design is simple.

Validate at creation. Validate after the holder changes the contact. Validate after objective evidence of bounce or failure. Validate periodically, but not so frequently that the registry creates unnecessary burden. Publish the validation status. Give a cure period. Allow multiple contacts. Allow APIs. Allow authenticated holder dashboards. Preserve all registry services necessary to correct the problem. Never connect the issue to revocation without independent adjudication and proof of deliberate abandonment or fraud.

A registry must not use support denial to block compliance. If a holder is non-compliant because a contact is broken, the registry must still provide the support needed to fix it. A policy that says support service may only be offered to compliant members can become circular: you cannot receive support because you are non-compliant; you cannot become compliant because support is restricted. That is not governance. It is a trap.

Proposed amendment 8: objective validation and cure periods

Current defect: Validation may occur whenever AFRINIC sees fit and non-compliance can escalate into severe consequences.

Replacement principle: Validation must be objective, predictable, and curable.

Proposed text:

AFRINIC may validate an abuse-contact record only: (a) upon creation; (b) upon holder-initiated update; (c) after an objective automated bounce or delivery failure; (d) after credible evidence that the contact method no longer exists; or (e) during a scheduled validation cycle not more frequent than once per twelve months unless the holder opts into more frequent validation. Validation failure shall trigger written notice to all registered administrative contacts, a minimum thirty-day cure period, and a second validation attempt. During the cure period AFRINIC shall maintain all registry services necessary to correct the record. Repeated failure may be recorded as a data-quality flag but shall not affect the holder’s recognised control of the number resource absent independent adjudication of fraud, abandonment, or duplicate claim.

This is enough. Anything more belongs to law enforcement, courts, customers, providers, and contracts, not the number registry.

IX. Non-portability is the original lock-in

The Consolidated Policy Manual’s older assignment logic still carries the memory of a world where addresses were bound to providers and renumbering was treated as a normal exit condition. Provider-aggregatable space was non-portable. If a customer changed providers, the address space should be returned and the network renumbered. Provider-independent space was discouraged as routing-costly. Sub-assignments from PI were restricted.

This was once defended as aggregation discipline. In the modern IPv4 economy, it is also a lock-in doctrine.

Forced renumbering is not a minor administrative inconvenience. It can be expensive, risky, and sometimes operationally impossible. It can affect firewalls, customer equipment, ACLs, DNS records, geolocation systems, reputation systems, vendor contracts, embedded devices, monitoring systems, and regulatory records. It creates switching costs. It favours incumbent providers. It reduces customer bargaining power. It turns address dependence into commercial capture.

A registry that takes Running-Code Primacy seriously should treat portability as a hard right. The routing table is not free, and deaggregation has costs. But the answer is not to deny portability by default. The answer is to price, publish, and manage routing externalities without using the registry as a commercial lock-in device.

The Internet did not become valuable because every operational reality could be made tidy in a policy manual. It became valuable because independent networks could interoperate. Portability is part of independence.

A number resource that cannot move is not a resource. It is a leash.

Proposed amendment 9: make portability default

Current defect: Older assignment language treats provider-dependent resources as non-portable and implies renumbering upon provider change.

Replacement principle: Portability should be the default status of all number resources where uniqueness and registry accuracy can be preserved.

Proposed text:

All registered number resources shall be portable by default unless a resource holder has expressly accepted a narrowly defined, time-limited, and contractually separate non-portability condition in exchange for a specified registry or provider service. A change of upstream provider, customer relationship, commercial arrangement, geography of use, or operational delegation shall not require return or renumbering of a number resource where the recognised holder or lawful transferee can maintain accurate registry records and preserve uniqueness. Any aggregation-related concern shall be addressed through routing-policy transparency and operational coordination, not through registry denial of portability.

The registry’s job is not to make provider exit painful.

X. Purpose-based assignments and the myth of proper use

The policy manual defines assignments as resources given for specific purposes documented by specific organisations and not sub-assigned to other parties. This is another allocation-era idea that becomes dangerous after scarcity.

Purpose-based assignment tries to freeze an expected use at the time of issuance. But real networks change. Companies merge. Customers move. Products fail. Markets shift. Data centres close. Transit relationships change. IPv4 scarcity creates new business models. Leasing emerges. Financing emerges. Address-management businesses emerge. Cloud providers and hosting providers need flexible delegation. Security companies need temporary use. Enterprises restructure. A rule that says the original purpose remains the basis of legitimacy becomes a trap for every normal business evolution.

The registry can require that the holder be identifiable. It can require contact data. It can require that sub-delegations be recorded at an appropriate level. It can require that responsibility for abuse contact and security assertions be clear. It can require that resource control not be fraudulent. It does not need to decide whether a new use is faithful to the original purpose.

Purpose enforcement is not a technical invariant. It is moral nostalgia.

The practical effect is to suppress leasing and sub-assignment. That suppression does not stop leasing. It pushes it into contractual structures that the registry cannot see clearly. The database becomes less accurate. Operators become less candid. The registry then cites inaccuracy as reason for more control. This is the spiral of enforcement creep.

The solution is to recognise operational delegation openly. Let the holder record lessees, customers, delegated contacts, route-security relationships, and time-limited control claims. Create better data fields. Do not pretend the market does not exist.

A registry record that admits leasing is more accurate than a registry policy that condemns leasing and then loses visibility into it.

Proposed amendment 10: recognise operational delegation and leasing

Current defect: Purpose-based assignment language and anti-subassignment restrictions treat commercial delegation as suspicious.

Replacement principle: Leasing, sub-assignment, customer delegation, and operational control arrangements should be recognised as local operator decisions where registry accuracy and uniqueness are preserved.

Proposed text:

A resource holder may lease, sub-assign, delegate, finance, pledge, route, sponsor, or otherwise make operational or commercial arrangements concerning number resources, provided that the recognised holder remains identifiable, registry records remain accurate at the appropriate level, abuse-contact and administrative-contact responsibilities are clear, and no duplicate claim or fraud is created. AFRINIC shall provide registry mechanisms to record delegated operational contacts, time-limited control relationships, lessee or customer contact data where voluntarily supplied or legally required, routing-authorisation relationships, and conflict status. AFRINIC shall not deny registry recognition solely because a resource is used through leasing, sub-assignment, third-party customer deployment, financing, or other lawful commercial arrangement.

This is not radical. It is merely truthful.

The Internet already contains these arrangements. The database should not be the last place where reality is allowed to appear.

XI. “Unregistered resources are invalid” is the wrong sentence

The policy manual says resources must be registered and implies that unregistered resources are invalid. This is understandable as administrative discipline, but the sentence is conceptually dangerous.

Invalid in what sense?

A registry can say a record is not authoritative in its database. It can say a holder has failed to provide required data. It can say a route object is missing. It can say reverse-DNS delegation is not provided. It can say RPKI services are not available. It can say the registry cannot validate a contact. But it cannot make packets stop moving by declaration. It cannot erase contractual rights. It cannot erase reliance. It cannot erase a court order. It cannot erase the reality that a block is routed, used, paid for, and depended upon.

When a registry calls unregistered resources invalid, it tempts itself into a metaphysical claim. The registry record becomes reality. That is backwards.

The correct statement is that registration is necessary for authoritative registry publication. It is not the sole source of operational existence. When registry and running code diverge, the registry should investigate, mark, reconcile, and correct. It should not declare reality invalid.

This matters because a database that claims metaphysical supremacy becomes brittle. If the record is wrong, the institution must defend the fiction. If the institution defends the fiction, operators lose trust. If operators lose trust, they stop updating records. If they stop updating records, the registry becomes less accurate. If the registry becomes less accurate, it demands more authority. The loop repeats.

The registry should be humble because humility makes it more authoritative.

Proposed amendment 11: replace invalidity with authority status

Current defect: Policy language suggests unregistered resources are invalid.

Replacement principle: Registration determines authoritative registry status, not metaphysical validity of operational use.

Proposed text:

Registration in the AFRINIC database establishes the authoritative AFRINIC registry record for the relevant number resource. Failure to register or update a record may affect the reliability of AFRINIC registry services, public contactability, reverse-DNS delegation, security-service eligibility, or transfer processing. Such failure shall not by itself invalidate operational use, extinguish recognised holder interests, authorise confiscation, or permit reassignment unless an independent adjudicative process or enumerated fraud, duplicate-claim, abandonment, or security-integrity condition is satisfied.

This amendment is a small textual change with large institutional consequences. It puts the registry back under reality.

XII. Community process cannot bear asset governance

AFRINIC’s policy manual describes a bottom-up process in which policy decisions determine the rules by which AFRINIC manages and administers number resources. It values participation, openness, and consensus. For a thin technical coordination layer, that process can work. For high-value asset governance, it cannot.

This is not an attack on participation. It is a category distinction.

Open technical discussion can help identify operational problems. It can improve protocol-adjacent practices. It can reveal implementation costs. It can build voluntary norms. It can publish recommendations. But it cannot convert a mailing list, meeting room, or consensus call into legal authority over companies’ assets. The people in the room are not necessarily directors, officers, shareholders, creditors, customers, governments, investors, or end users. They are participants. Participation is not representation.

The problem becomes acute when policies affect revocation, transferability, leasing, capital value, regional movement, sanctions exposure, registry fees, route-security validity, and operational continuity. At that point, the policy is not merely a technical norm. It is economic governance. Economic governance requires mandate, legal authority, liability, due process, representation, and appeal.

The RIR system tries to avoid that by saying it is bottom-up. Bottom-up from whom? A person using a mailing list is not the principal of every network in the region. An employee attending a meeting may not have authority to bind the company. A consultant may speak loudly without bearing any operational downside. A government observer may represent state interests but not operators. An operator may represent its own network but not the continent. A registry employee may participate in process while the registry later enforces the result. This mixture may generate useful discussion. It cannot manufacture sovereignty.

A room is not a mandate.

The policy process must therefore be narrowed. It should only produce rules within the registry function. If a proposed rule affects existing resource-holder rights, transferability, commercial use, revocation risk, or capital value, it must either be opt-in, limited to future free-pool issuance, or approved through a legally representative mechanism that binds affected principals. Even then, it must satisfy the running-code test.

The first question for every policy proposal should be: what invariant does this protect?

If the answer is uniqueness, accuracy, security integrity, fraud prevention, contactability, transfer recording, or operational continuity, the proposal may belong in the common layer.

If the answer is fairness, community preference, regional development, anti-speculation, commercial morality, conservation after exhaustion, or proper use, the proposal belongs outside the registry mandate unless adopted voluntarily by affected operators.

Proposed amendment 12: add a policy-scope test

Current defect: The PDP can produce broad resource-governance rules without a hard scope boundary tied to running-code invariants.

Replacement principle: Every policy must identify the technical invariant it protects and prove proportionality.

Proposed text:

No policy proposal shall be advanced, adopted, implemented, or applied unless it identifies the specific registry-function invariant it protects. Recognised invariants are: uniqueness of number-resource registration; accuracy of registry records; prevention of fraud in registry records; public contactability; routing-adjacent coordination; security-assertion integrity; transfer and change-of-control recording; dispute-state recording; and operational continuity. A proposal whose primary effect is to regulate commercial model, pricing, leasing, customer geography, regional retention, capital movement, speculation, moral use, political preference, or resource-holder business strategy shall be outside the mandatory policy scope unless adopted voluntarily by each affected resource holder or required by binding law through a competent public authority.

This would force intellectual honesty. It would end mandate laundering at the procedural level.

XIII. Retroactivity is the hidden confiscation

The RIR model often treats policy as if it floats above time. A policy is adopted today; resources issued yesterday become subject to it tomorrow. That assumption is intolerable once resources are valuable assets.

Retroactivity is not a technical necessity. It is a power claim.

A registry may need to correct fraud. It may need to resolve duplicate claims. It may need to update security standards for voluntary services. It may need to comply with court orders. But it should not impose new economic restrictions on existing resources merely because a policy room adopted a new view. That destroys reliance.

Reliance is not a sentimental concept. It is the basis of capital formation. Operators invest because they believe the rules will not be rewritten after the investment is sunk. Customers sign contracts because they believe service inputs will remain stable. Lenders lend because collateral is not at the mercy of discretionary reinterpretation. Buyers buy because transferability is not a trap. Sellers sell because title will be recorded. If a registry can retroactively redefine use, transfer, compliance, or revocation risk, every rational actor discounts the asset.

That discount is not theoretical. It appears in prices, transaction delays, legal costs, insurance costs, financing terms, and reduced network investment.

AFRINIC’s policy framework needs an explicit anti-retroactivity clause.

Proposed amendment 13: anti-retroactivity and reliance protection

Current defect: Policies may be applied to existing resources without a strong reliance-protection rule.

Replacement principle: New policies should apply prospectively unless they protect an enumerated technical invariant and use the least disruptive remedy.

Proposed text:

No policy adopted after the date of a resource holder’s allocation, assignment, transfer, or recognised acquisition shall retroactively reduce transferability, portability, operational use, commercial delegation, leasing ability, financing ability, registry-service eligibility, or recognised control of that resource unless: (a) the policy addresses fraud in registry records, duplicate claims, security-integrity failure, or demonstrable threat to uniqueness; (b) the policy uses the least disruptive remedy sufficient to protect the invariant; (c) affected holders receive notice, evidence, cure period, and independent appeal; and (d) operational continuity is preserved during review. Policy changes affecting economic rights shall apply prospectively or by voluntary opt-in.

This is the minimum needed once IPv4 is capital.

A system that cannot protect reliance cannot govern assets.

XIV. Revocation must be structurally separated from registry administration

The most dangerous power in the registry system is revocation. Not because it is always used. Because its existence changes behaviour. A holder who knows the registry can revoke will hesitate to challenge the registry. It will avoid unpopular positions. It will avoid candid disclosure of leasing. It will treat policy ambiguity as existential risk. It will pay fees it disputes. It will accept process defects. It will internalise fear.

That is not coordination. It is domination.

No RIR should hold unilateral deregistration power over operationally embedded resources except for narrow, provable running-code invariants: duplicate assignment, fraud in registration, security-integrity failure, explicit abandonment, or a binding independent decision. Even then, the remedy should be proportionate. The first remedy should be correction. The second should be conflict marking. The third should be suspension of a non-essential service. Actual deregistration should be rare, adjudicated, and continuity-preserving.

A registry cannot be recordkeeper, complainant, investigator, judge, and executioner.

This is one of the central lessons of AFRINIC. The dispute did not reveal that a member can paralyse a registry. It revealed that a registry with broad revocation theory can threaten operational assets and then discover that courts, creditors, members, and states do not accept its self-image. The resulting institutional crisis was not an argument for more registry sovereignty. It was evidence that registry sovereignty was never legitimate.

The policy manual should contain a hard revocation firewall.

Proposed amendment 14: revocation firewall

Current defect: Policy and contractual compliance failures can create pathways toward deregistration or revocation beyond narrow technical necessity.

Replacement principle: Revocation must be exceptional, independently reviewable, and limited to enumerated technical or legal conditions.

Proposed text:

AFRINIC shall not revoke, deregister, reclaim, reassign, remove reverse-DNS delegation, terminate RPKI publication, or otherwise impair operational registry recognition of a number resource except under one of the following conditions: (a) final independent adjudication or binding court order; (b) proven fraud in the registry record materially affecting control of the resource; (c) active duplicate registration or duplicate assignment that cannot be resolved by less disruptive correction; (d) explicit written abandonment by the recognised holder; (e) security-integrity emergency where temporary action is necessary to prevent imminent harm to the registry system itself and is reviewed independently within a defined short period; or (f) non-payment of narrowly defined registry-service fees after notice, cure period, independent review, and preservation of a minimum continuity record. No commercial-use, leasing, customer-location, transfer-pricing, abuse-handling, need-assessment, regional-retention, or policy-participation issue shall by itself constitute grounds for revocation.

Without such a firewall, every policy becomes a weapon.

XV. Liability must follow power

A private registry cannot exercise public-infrastructure power while capping responsibility like a minor service bureau. This is the liability problem at the core of the RIR system.

The economic rule is simple: the party with control must bear the cost of wrongful control, or the control must be removed. If AFRINIC can block a transfer worth millions, it cannot say its liability is administrative. If it can deny outbound movement, it cannot say it does not affect market value. If it can treat non-compliance as breach leading to revocation, it cannot say resource value is speculative and outside its responsibility. If it can condition support, it cannot say the member’s loss is external.

Power without liability creates moral hazard. The registry internalises the benefits of discretion: fees, relevance, political authority, institutional prestige, bargaining power. It externalises the costs: lost transactions, legal fees, network disruption, customer harm, asset impairment, financing discount, state infrastructure risk. That is a governance-rent equilibrium.

The cure is either liability or less power. There is no institutional magic.

I prefer less power. A registry should not become an insurer of every network transaction. It should not become a public utility regulator. It should not become a court. The better answer is to narrow its authority so that liability exposure becomes manageable. But where the registry retains discretionary adverse power, liability must rise.

Proposed amendment 15: liability-power symmetry

Current defect: Registry discretion can affect asset value while the institution disclaims corresponding responsibility.

Replacement principle: Any discretionary adverse action must carry proportional liability, or the discretion must be replaced by objective rules.

Proposed text:

Any AFRINIC discretionary decision that delays, rejects, reverses, suspends, impairs, or conditions a resource holder’s transfer, portability, registry recognition, reverse-DNS delegation, RPKI publication, or recognised operational control shall be subject to documented reasons, evidence disclosure, independent appeal, defined service periods, and liability for direct losses caused by bad faith, gross negligence, reckless disregard of policy limits, or action outside enumerated registry authority. Where AFRINIC does not accept such liability, the relevant decision shall be limited to objective verification criteria and shall not include discretionary economic, commercial, regional, or policy-compliance judgment.

This amendment forces the institution to choose.

Either be a narrow registry with low liability, or be a powerful decision-maker with real liability. The current model wants both. That is precisely why it fails.

XVI. The registry continuity fallacy

The most common defence of AFRINIC-style control is continuity. The registry must remain stable. The region must not lose registry services. The database must remain authoritative. Therefore, the institution must be protected.

This argument confuses two things: continuity of registry function and continuity of registry power.

The registry function matters. Number-resource uniqueness matters. Public records matter. Reverse-DNS delegation matters. RPKI continuity matters. Transfer records matter. Contact records matter. Historical data matters. Audit logs matter. Dispute records matter.

The corporation’s power is different. Its board, fee model, policy machinery, litigation posture, enforcement theory, and transfer ideology are not identical to the registry function. They can change. They can be replaced. They can fail. They can be bypassed. The Internet should not collapse because a private corporation is badly governed or legally conflicted.

The future architecture must therefore specify failover. This should not be treated as an emergency improvisation. It should be a normal design requirement.

Every resource holder should have a right to export its registry state. Every registry should maintain versioned, auditable, independently escrowed records. Every resource should have a continuity path if the registry becomes insolvent, captured, paralysed, sanctioned, technically compromised, or legally unable to operate. Every dispute should be isolated so that it does not freeze regional service. Every RPKI and reverse-DNS dependency should have succession rules. Every resource should be portable to a qualified successor registry or decentralised registration system.

This is not anti-registry. It is pro-continuity.

The current RIR system has treated RIR continuity as institutional immortality. That is backwards. The best way to preserve registry continuity is to make any one registry replaceable.

Proposed amendment 16: portability and failover as registry rights

Current defect: AFRINIC policy does not provide a hard resource-holder right to registry portability or failover.

Replacement principle: Portability and failover are minimum architecture for an indispensable registry function.

Proposed text:

Each recognised resource holder has a right to obtain, at reasonable intervals and upon material registry-risk events, an authenticated export of its registry state, including resource records, holder identity, contact objects, transfer history, delegation data, reverse-DNS data, RPKI-related metadata where applicable, dispute-status records, and audit logs reasonably necessary for continuity. AFRINIC shall participate in an independently escrowed, versioned, and auditable registry-continuity system. If AFRINIC becomes unable or unwilling to provide essential registry services, or if an independent continuity trigger is satisfied, resource holders may port registry administration of their resources to a qualified successor registry or recognised decentralised registration mechanism without loss of uniqueness, transferability, or operational recognition.

This is the minimum serious answer to registry failure.

Without portability, the registry is not a service. It is a hostage point.

XVII. RPKI and security assertions must not become enforcement weapons

RPKI is security infrastructure. It should not be converted into policy enforcement.

A registry that controls RPKI publication can create a new form of coercion. It may not revoke the resource directly. It may instead impair the security assertion. In a world where networks rely on route-origin validation, that can be operationally severe. Therefore, any policy reform must treat RPKI and registry-security services as continuity-critical, not discretionary compliance rewards.

The rule should be clear: if a holder is recognised, its security assertions should continue unless the assertion is fraudulent, technically invalid, subject to court order, or creates a security-integrity emergency. RPKI should validate control, not obedience.

A holder’s disagreement with a policy should not make its routes less secure. A broken abuse mailbox should not invalidate a ROA. A transfer dispute should create conflict metadata, not silent security breakage. A fee dispute should not become route-origin punishment without due process and continuity safeguards.

Security systems lose legitimacy when used for governance fights.

Proposed amendment 17: security-service neutrality

Current defect: Policy frameworks often leave room for registry services, including security-related services, to become compliance levers.

Replacement principle: Security assertions should track recognised control and technical validity, not policy obedience.

Proposed text:

AFRINIC shall operate RPKI, reverse-DNS, and related security or delegation services as registry-continuity services tied to recognised control and technical validity. AFRINIC shall not suspend, remove, invalidate, or refuse such services as leverage for commercial-use disputes, transfer-policy disagreements, abuse-handling complaints, regional-use concerns, fee disputes without independent review, or non-technical policy disagreements. Adverse security-service action shall be limited to fraud, duplicate claim, technical invalidity, explicit holder request, binding court or independent adjudicative order, or narrowly defined security-integrity emergency subject to rapid independent review.

This amendment prevents the next layer of mandate laundering.

When a security tool becomes an enforcement tool, security loses trust.

XVIII. The proper transfer test

A correct transfer policy can be written on one page.

The registry needs to know the source has control. It needs to know the destination exists. It needs accurate records. It needs to preserve uniqueness. It needs to update reverse-DNS and security metadata. It needs to handle disputes. It needs to interoperate with other registries. It needs service-level deadlines. It needs appeal. It needs audit.

Everything else is ideology.

Here is the transfer test that should replace the current framework:

1. Identify the resource.
2. Verify the current recognised holder or authorised representative.
3. Verify that no active duplicate-claim, fraud hold, court order, or independent adjudicative hold prevents update.
4. Receive transfer instrument or equivalent evidence of change of control.
5. Receive accurate transferee records.
6. Preserve or transition reverse-DNS and RPKI records.
7. Publish transfer or conflict status within a defined period.
8. Allow appeal if rejected.
9. Keep audit logs.
10. Do not judge price, geography, business model, speculation, need, leasing, or regional morality.

That is sufficient.

It is also better for AFRINIC. A registry that processes transfers quickly and neutrally becomes more authoritative. A registry that blocks transfers becomes less authoritative because the market finds other ways to transact.

The goal is not to stop transfers outside the database. The goal is to make the database the safest place to record them.

Proposed amendment 18: a complete replacement transfer section

Proposed text:

Transferability. All recognised number resources are transferable unless subject to a defined temporary hold for duplicate claim, proven registry fraud, binding court order, independent adjudicative order, or explicit written holder restriction voluntarily accepted at the time of acquisition.

Scope. Transfers may be intra-registry, inter-registry, inter-successor-registry, merger-related, acquisition-related, financing-related, legacy-related, partial, full, permanent, or time-limited where technically recordable.

Registry role. AFRINIC records transfers. It does not approve business transactions, set price, judge business need, determine proper commercial use, enforce regional retention, or regulate speculation.

Objective requirements. AFRINIC shall record a transfer when the transferor has shown recognised control or legal authority, the resource is uniquely identified, the transferee has provided accurate registry information, and necessary continuity records can be updated.

Prohibited grounds of denial. AFRINIC shall not deny a transfer because of recipient geography, source geography, customer geography, intended routing location, purchase price, leasing intention, financing use, absence of registry-assessed need, regional-retention preference, or disagreement with lawful commercial model.

Time limit. AFRINIC shall record or issue an evidence-based rejection within ten business days for ordinary transfers and twenty business days for inter-registry transfers, excluding time during which the applicant fails to provide specifically requested objective evidence.

Rejection. A rejection must identify the enumerated criterion not satisfied, the evidence relied upon, the cure available, and the appeal path.

Appeal. A rejected transfer may be appealed to an independent review body with authority to order registry recording.

Dispute status. Where competing claims exist, AFRINIC shall record conflict status and preserve operational continuity until resolution.

No loss of status. Legacy or equivalent status shall not be lost by transfer unless the holder expressly opts in.

Audit. AFRINIC shall maintain audit logs sufficient to verify timing, evidence, staff action, and record changes.

This is a policy that an operator, investor, court, and engineer can understand.

That is the standard.

XIX. Abuse contact: a complete replacement section

The abuse-contact policy should also be rewritten in one clean section. It should be useful but bounded.

Proposed amendment 19: a complete replacement abuse-contact section

Proposed text:

Purpose. The purpose of abuse-contact registration is to improve public contactability for operational and abuse-related notices associated with number resources. This section governs registry-directory accuracy only.

Requirement. Each registered inetnum, inet6num, and aut-num object shall reference at least one abuse-contact object or inherit one from a parent object where appropriate.

Content. The abuse-contact object shall contain at least one electronic contact method capable of receiving ordinary notices.

Validation. AFRINIC may validate deliverability or receipt capability through objective automated means at creation, update, objective bounce event, credible evidence of non-existence, or scheduled annual cycle.

Limits. AFRINIC shall not evaluate the substance, speed, adequacy, legal sufficiency, or outcome of the holder’s abuse-handling process. AFRINIC shall not require the holder to accept attachments, avoid forms, respond in a particular language, investigate reports, disclose customer information, or take action against users except where required by applicable law or independent order.

Failure. Validation failure triggers notice, cure period, and public or internal data-quality flag. It does not by itself affect recognised control of the number resource.

Cure. AFRINIC shall provide reasonable registry access and support necessary to correct the abuse-contact record during any non-compliance period.

Prohibited sanctions. Abuse-contact failure alone shall not justify revocation, deregistration, transfer denial, RPKI suspension, reverse-DNS removal, or reassignment.

Escalation. Fraudulent contact data may be referred to the general registry-fraud process, which must include evidence, notice, cure, independent review, and operational-continuity protection.

Publication. AFRINIC may publish validation status and last validation date in the registry record, subject to privacy, security, and anti-harassment safeguards.

This keeps the contact function and removes the enforcement creep.

The registry remains useful. It stops pretending to be the abuse police.

XX. Policy development must include affected-principal safeguards

The PDP needs a structural amendment. Open process is not enough. It must be disciplined by scope, impact, and affected-principal protection.

A policy that changes the data format of a contact object is not the same as a policy that changes transferability. A policy that defines a route-security field is not the same as a policy that restricts outbound IPv4 movement. A policy that allocates future free-pool resources is not the same as a policy that imposes new conditions on existing resources. The PDP must recognise these categories.

Here is the minimum classification:

Class A: registry-mechanics policy. Data fields, formats, publication methods, technical validation, audit standards, and other rules that do not impair existing holder interests.

Class B: free-pool allocation policy. Criteria for future distribution of unallocated resources, if any remain.

Class C: holder-impact policy. Rules that affect transferability, portability, commercial use, fees, services, revocation risk, security services, dispute status, or recognised control of existing resources.

Class A can use ordinary PDP consensus. Class B can use ordinary PDP consensus for future issuance, because applicants can choose whether to apply. Class C cannot rely on ordinary open consensus. It must require legal notice to affected holders, impact assessment, opt-in or prospective application, independent review, and a supermajority of affected legal resource holders if mandatory application is proposed.

This does not make policy impossible. It prevents a room from governing assets it does not own.

Proposed amendment 20: policy classification and affected-holder consent

Current defect: The PDP does not sufficiently distinguish technical registry rules from economic governance.

Replacement principle: Higher-impact policies require higher legitimacy.

Proposed text:

Policy proposals shall be classified before discussion as Class A registry-mechanics, Class B future free-pool allocation, or Class C existing-holder impact. A Class C proposal is any proposal that may materially affect existing resource holders’ transferability, portability, leasing, commercial use, financing, fees, service continuity, security-service access, revocation exposure, or recognised control. Class C proposals shall require direct notice to affected holders, publication of an economic and operational impact assessment, legal-authority analysis, anti-retroactivity analysis, and independent review. Mandatory application to existing resources shall require either voluntary opt-in by affected holders, binding public-law authority, or approval by a defined supermajority of affected legal resource holders voting as principals, not merely participants.

This amendment restores the difference between discussion and delegation.

The policy room may advise. It may not confiscate by consensus.

XXI. Fees must be tied to registry function, not institutional ambition

AFRINIC’s policy conflict is not only about transfers and abuse contacts. It is also about cost structure. The broader RIR model uses mandatory membership and resource fees to fund institutions whose activities extend beyond the minimal registry function. Once resources are scarce assets and registry services are indispensable, fees become a tax on continuity.

A registry may charge for registry services. It may recover reasonable costs. It may fund security, audit, publication, support, and continuity infrastructure. But it should not use compulsory fees to fund political advocacy, institutional expansion, community theatre, international status efforts, or enforcement machinery unrelated to running-code invariants.

The economic principle is cost causation. Users should pay for the costs their registry use causes. They should not pay monopoly rents because they cannot leave. If portability exists, fees become disciplined. If portability does not exist, fees become extraction.

The fee policy should therefore be rewritten around minimal registry services and exit rights.

Proposed amendment 21: fee-function separation

Current defect: Registry fees can support broad institutional activity rather than narrow registry service.

Replacement principle: Mandatory fees must be tied to objective registry-service cost and portability rights.

Proposed text:

Mandatory fees charged as a condition of registry recognition shall be limited to reasonable cost recovery for registry-record maintenance, publication, security-service operation, audit, continuity escrow, transfer recording, contact validation, and holder support directly necessary to those functions. AFRINIC shall separately account for policy advocacy, community events, institutional representation, discretionary enforcement, litigation strategy, and non-registry activities. A resource holder shall not be required to fund non-registry activities as a condition of maintaining recognised control of number resources. Where a holder elects a qualified successor registry or portability mechanism, AFRINIC shall provide export and transition services at cost-based fees.

This would expose the real cost of registry service.

A database should not cost like a government.

XXII. The policy should recognise asset reality without pretending to create property

The RIR system fears property language because property reduces discretion. If number resources are property-like assets, the registry cannot behave as owner. If holders have ownership-like reliance, revocation becomes difficult. If transferability is recognised, anti-speculation morality loses force. If IPv4 is capital, registry policy becomes economically consequential and legally contestable.

So the system says number resources are not property.

This is too crude.

The registry does not need to decide the entire metaphysics of property. Different jurisdictions may treat number resources differently. Courts may classify them according to bankruptcy, contract, tax, collateral, tort, injunction, or statutory rules. Markets may price them. Operators may rely on them. Lenders may discount or accept them. The registry should not declare that they are property in every legal sense. But it also should not deny ownership-like interests in order to preserve its own discretion.

The correct policy language is asset-neutral and court-compatible.

It should say: number resources are operational identifiers recorded in a registry; holders may have contractual, statutory, equitable, beneficial, possessory, reliance-based, or other legal or economic interests under applicable law; AFRINIC does not adjudicate those interests except for registry-record purposes; AFRINIC’s record does not extinguish rights determined by competent law; transfer and control records should track lawful and operational reality.

That is enough.

Proposed amendment 22: asset-neutral recognition

Current defect: Anti-property language is used to support registry discretion and deny market reality.

Replacement principle: Policy should recognise legal and economic interests without claiming that AFRINIC creates or owns them.

Proposed text:

Number resources are operational Internet identifiers recorded for uniqueness and coordination. AFRINIC does not create sovereign title in number resources and does not adjudicate all legal interests that may arise under applicable law. Resource holders may possess contractual, statutory, equitable, beneficial, reliance-based, security, transfer, or other legal or economic interests as recognised by applicable law, contract, market practice, court order, or operational reliance. AFRINIC registry records shall seek to reflect recognised control and relevant conflict status without denying, extinguishing, or overriding legal interests beyond AFRINIC’s limited registry function.

This language is more accurate than both extremes. It denies AFRINIC ownership. It avoids universal property claims. It lets law, markets, and operations do their work.

XXIII. The policy should remove anti-speculation morality

The 2026 overview says AFRINIC does not assign monetary value and that number resources are not commodities for speculation. This is not a technical statement. It is moral economics. It should not be in a registry policy.

Speculation is not the opposite of infrastructure. It is one mechanism by which markets price future scarcity. Some speculation is harmful when it involves fraud, manipulation, monopoly abuse, or deception. Those are legal categories. But buying an underused scarce asset because one believes it will be more valuable later is not a registry problem. It may increase liquidity. It may reveal price. It may move resources toward future high-valued use. It may finance holders who otherwise sit on dead inventory. It may create inventory for leasing markets.

A registry that condemns speculation while controlling transferability is not neutral. It is choosing one allocation ideology over another. That choice is outside its mandate.

The correct test is not whether a transaction is speculative. The correct test is whether the registry can preserve uniqueness, accuracy, security continuity, and proof of control.

Proposed amendment 23: remove anti-speculation language

Current defect: Policy materials invoke anti-commodity or anti-speculation language to justify restrictions.

Replacement principle: The registry should not judge investment motives.

Proposed text:

AFRINIC shall not deny, delay, condition, or stigmatise a registry transaction on the basis that a number resource has monetary value, is leased, is financed, is held for future use, is acquired for investment purposes, is pledged as collateral, or is transferred for consideration. AFRINIC’s policy assessment shall be limited to registry-function invariants: uniqueness, accuracy, proof of control, fraud prevention, security continuity, contactability, and dispute status.

This amendment removes moral theatre from the registry.

Packets do not care whether the holder has an investment thesis.

XXIV. The policy should treat geography as operational metadata, not authority

Geography matters in some contexts. Legal compliance may depend on jurisdiction. Tax may depend on location. Customer service may depend on market. Data-centre deployment may matter. Governments may regulate networks within their territory. But registry geography is not ownership geography.

The AFRINIC region is a service boundary. It is not a title boundary. It is not a moral boundary. It is not a constitutional people. It does not transform IP addresses into regional property. It does not give a private registry authority to decide where capital may move.

A resource may be registered in one region, routed globally, used by multinational customers, leased to another market, announced through multiple ASNs, or moved after acquisition. None of this threatens uniqueness. Some of it may matter for contact data or legal metadata. It does not justify transfer prohibition.

Proposed amendment 24: geography-neutral registry records

Current defect: Regional labels are used to restrict economic movement.

Replacement principle: Geography may be recorded where useful but not used as a transferability barrier.

Proposed text:

AFRINIC may record service-region, holder-location, administrative-contact location, or voluntarily supplied operational-location metadata where useful for registry services or legal compliance. Such metadata shall not determine ownership, title, recognised control, transferability, portability, commercial-use legitimacy, leasing legitimacy, or right to registry continuity. Routing location, customer geography, revenue geography, incorporation jurisdiction, or intended region of use shall not be grounds for denial of registry recognition or transfer.

The Internet is global because identifiers are not land.

A registry that forgets this becomes a border post.

XXV. The policy should define independent review before the crisis

Appeal mechanisms are often designed after conflict begins. That is too late. A registry that can affect asset value must have independent review embedded in the policy itself.

Independence means more than a staff reconsideration. It means the reviewer is not the same institution that made the decision, does not depend on the same internal policy incentives, can order correction, and can act quickly enough to preserve operational value. For urgent cases, interim relief must exist. For registry-state disputes, the default should be preservation of last verified operational state.

The review body does not need to become a global court. It needs to handle registry-function disputes: record updates, transfer denials, conflict status, abuse-contact flags, revocation attempts, security-service interruptions, portability requests, and continuity triggers. Legal disputes can still go to courts. The review body can defer to courts where needed. Its role is to prevent the registry from acting as unilateral executioner.

Proposed amendment 25: independent registry review

Current defect: Registry decisions with asset impact lack sufficiently independent, rapid, and binding review.

Replacement principle: Any adverse registry action requires independent review and interim continuity.

Proposed text:

AFRINIC shall establish or participate in an independent registry-review mechanism for adverse actions affecting transfer, portability, recognised control, conflict status, registry publication, reverse-DNS delegation, RPKI service, revocation, reclaim, or service denial. The review mechanism shall have authority to issue interim continuity orders, require preservation of last verified registry state, compel publication of conflict metadata, order registry correction, and award cost consequences where policy limits are exceeded. AFRINIC shall not implement irreversible adverse action until review is complete unless a narrowly defined security-integrity emergency exists and is reviewed within a defined short period.

This amendment is institutional hygiene.

A registry that fears review should not hold power.

XXVI. The policy should adopt dispute isolation

The RIR system has a bad habit of allowing one dispute to threaten the whole institution. That is a design failure. Disputes should be isolated.

If a holder has a transfer dispute, the region should not lose registry services. If the registry has a governance dispute, holders should not lose continuity. If a board election fails, RPKI should not fail. If a court case freezes an account, database publication should continue. If one resource has competing claims, unrelated resources should not be affected. If one contact object is invalid, the block should not disappear. If one policy is challenged, the registry should not collapse.

Dispute isolation is a core running-code principle. The Internet is resilient because failures are contained. Registry governance should follow the same architecture.

Proposed amendment 26: dispute-isolation rule

Current defect: Policy does not sufficiently isolate disputes from registry continuity.

Replacement principle: Disputes must be recorded and contained, not allowed to impair unrelated resources or services.

Proposed text:

AFRINIC shall isolate registry disputes to the smallest affected resource, record, service, or holder. A dispute concerning one resource shall not impair unrelated resources of the same holder absent specific evidence and independent review. A dispute concerning a holder shall not impair regional registry services. A governance, financial, litigation, board, staff, or policy dispute within AFRINIC shall not impair holder access to essential registry records, transfer processing, reverse-DNS continuity, RPKI continuity, or registry-state export. Where uncertainty exists, AFRINIC shall preserve last verified operational state and record conflict metadata.

This is how technical systems survive. Governance should learn from them.

XXVII. The correct policy architecture

The amendments above can be summarised as a new architecture.

The common layer should contain only:

• identifier uniqueness;
• registry accuracy;
• proof of recognised control;
• public and operational contactability;
• fraud prevention in registry records;
• transfer and portability recording;
• reverse-DNS and security-service continuity;
• dispute-status metadata;
• audit logs;
• independent review;
• failover and registry-state export.

The local operator layer should decide:

• leasing;
• sub-assignment;
• customer geography;
• routing strategy;
• business model;
• financing;
• asset holding;
• pricing;
• infrastructure deployment;
• abuse-handling procedure;
• local legal compliance;
• customer contracts;
• operational risk allocation.

The adoption layer should decide:

• whether new technical norms are implemented;
• whether enhanced data fields are voluntarily used;
• whether a holder opts into a higher service tier;
• whether a holder joins a portability or decentralised registry mechanism;
• whether markets recognise a new record type;
• whether courts treat a registry record as sufficient evidence;
• whether operators route according to published security assertions.

This is Note 64 applied to AFRINIC policy.

Minimum Initial Specification keeps the common layer thin. Localized Future Decision keeps business and operational consequences where they belong. Voluntary Adoption prevents a policy room from declaring a future reality into existence.

The AFRINIC policy framework violates all three when it uses regional stewardship, need, anti-property language, transfer approval, legacy conversion, abuse-contact escalation, purpose restrictions, and non-portability to expand the registry’s authority.

The cure is not more accountability rhetoric. The cure is less central power.

XXVIII. A consolidated amendment package

To make this practical, the full reform package should be submitted as a single policy set. Piecemeal amendment lets the old sovereignty claim survive in another section. The package should contain the following parts.

1. Registry Function and Scope Policy

Adopt the registry-function definition. Remove or subordinate public-resource custody language. Define AFRINIC’s mandatory policy authority only by running-code invariants.

2. Anti-Retroactivity and Reliance Policy

Protect existing resources from new restrictions on transferability, portability, leasing, commercial use, and recognised control unless narrow technical exceptions apply.

3. Transfer Recording Policy

Replace approval with objective recording. Abolish regional outbound embargoes. Preserve legacy status. Remove needs assessment. Provide deadlines, reasons, audit, and appeal.

4. Portability and Failover Policy

Create holder right to registry-state export, successor registry portability, escrowed records, and continuity triggers.

5. Operational Delegation and Leasing Recognition Policy

Recognise leasing, sub-assignment, financing, and delegation as registrable realities, not violations.

6. Abuse Contact Directory Policy

Limit abuse-contact rules to deliverability and directory accuracy. Remove revocation and broad enforcement consequences.

7. Revocation Firewall Policy

Limit adverse action to fraud, duplicate claim, court order, independent adjudication, abandonment, and security-integrity emergencies.

8. Independent Registry Review Policy

Create binding review for adverse registry actions and interim continuity orders.

9. Fee-Function Separation Policy

Tie mandatory fees to registry-service cost and separate non-registry activities.

10. PDP Scope and Affected-Principal Policy

Classify policy proposals and require stronger legitimacy for existing-holder impact.

This package would not be a request for AFRINIC to become a better sovereign. It would be a legal and technical demotion. That is the point.

The registry should be useful precisely because it is limited.

XXIX. Anticipating the counterarguments

The first counterargument will be that unrestricted transfers will drain Africa of IPv4 resources.

This is wrong. Restricting transfer does not create supply. It lowers the value of African-held resources and discourages inbound supply. A region that wants more IPv4 should increase liquidity, legal certainty, and financing channels. If African networks need resources, they will compete for them. If they cannot afford them, the answer is financing, leasing, shared infrastructure, market transparency, and perhaps public subsidy by actual public authorities. It is not a private registry’s regional capital control.

The second counterargument will be that abuse will increase if the registry cannot revoke.

This confuses contactability with enforcement. Abuse problems should be handled by network operators, customers, providers, courts, law enforcement, security communities, and contracts. The registry can publish contacts and record control. It cannot become a universal abuse court. Revocation is a crude remedy that can harm innocent customers, create collateral damage, and invite political pressure. A contact flag is proportionate. Confiscation is not.

The third counterargument will be that bottom-up consensus gives legitimacy.

Consensus among participants can guide technical norms. It cannot create legal authority over absent principals. The more economically consequential the rule, the less a casual consensus call can carry it. The policy room may speak for itself. It does not speak for every holder’s balance sheet.

The fourth counterargument will be that number resources are not property.

Even if they are not property in some absolute sense, AFRINIC still is not the owner. Denying property does not create registry sovereignty. The correct policy is asset-neutral: record control, preserve legal claims, defer to competent law, and stop using anti-property language as a power source.

The fifth counterargument will be that AFRINIC needs authority to preserve accurate records.

The opposite is true. Overbroad authority makes records less accurate because operators hide reality. Narrow, safe, fast recording makes operators disclose reality. If the database is useful and non-punitive, the market will use it. If it is dangerous, the market will route around it.

The sixth counterargument will be that portability and successor registries fragment the Internet.

Portability prevents fragmentation. A system with no failover is fragile. A system in which registry state can be exported, verified, and continued is more resilient. The risk is not replacement. The risk is monopoly without escape.

The seventh counterargument will be that these reforms are too radical.

They are only radical if one assumes a registry is a sovereign. If one assumes a registry is a ledger, they are ordinary.

XXX. What AFRINIC’s 2026 policies really prove

The 2026 policies prove that AFRINIC’s institutional instinct has not changed. It still sees the registry as a gate. It still treats regional control as legitimate. It still treats transfer as permission. It still treats number resources as administered objects rather than operator assets. It still imports community-policy authority into commercial reality. It still wants to reinforce the registry’s authoritative role rather than make the registry replaceable.

The abuse-contact policy proves a softer version of the same error. It begins with a valid registry need and then attaches compliance escalation. That is how enforcement creep works. No one announces tyranny. They announce data quality.

The transfer policy proves the harder version. It converts registry categories into movement rights. That is how capital control works. No one announces expropriation. They announce stewardship.

The old policy manual supplies the vocabulary. Public resource. Conservation. Need. Non-property. Non-portability. Specific purpose. Community. Custodian. These words were once treated as harmless. They are not harmless when attached to scarce assets.

This is why AFRINIC is not an isolated problem. It is the clearest mirror.

The RIR system began as a set of clerks for low-value identifiers. It became a set of private-law chokepoints over scarce capital. It never rebuilt its legal mandate, liability model, representation theory, portability architecture, or failover design. It still relies on the emotional memory of the early Internet: rough consensus, public resource, community, stewardship. Those words cannot carry the modern load.

IPv4 changed the system. The policy language did not.

That mismatch is the crisis.

XXXI. Running-Code Primacy as the policy test

Running-Code Primacy gives a hard test for every clause.

Does this clause protect uniqueness?

Does it improve registry accuracy?

Does it prevent fraud in records?

Does it preserve security assertions?

Does it make transfers more accurately recorded?

Does it isolate disputes?

Does it preserve operational continuity?

Does it provide portability and failover?

If yes, it may belong in the mandatory registry layer.

If not, it must be local, voluntary, contractual, market-based, or public-law. It must not be smuggled into the registry policy manual.

Under that test, many AFRINIC rules fail. Regional outbound restrictions fail. Needs assessment for transfers fails. Anti-speculation language fails. Legacy-status stripping fails. Purpose-based assignment enforcement fails. Forced non-portability fails. Abuse-contact revocation fails. “Whenever AFRINIC sees fit” validation fails. Community-balancing over existing assets fails. Unauthorised-transfer reclaim fails. Broad policy-compliance revocation fails.

Some rules pass. Uniqueness passes. Accurate contacts pass. Fraud control passes. Transfer recording passes. Security continuity passes. Public registry data passes. Audit passes. Independent review passes. Dispute metadata passes. Failover passes.

This is not anti-policy. It is policy discipline.

A system that cannot tell these categories apart should not govern number resources.

XXXII. The implementation sequence

A serious reform needs staging.

Immediate: moratorium on non-technical adverse action

AFRINIC should immediately suspend any revocation, reclaim, transfer denial, RPKI impairment, reverse-DNS removal, or registry-recognition impairment based solely on commercial use, leasing, customer geography, lack of need, transfer pricing, regional retention, abuse-response substance, or policy disagreement. Only fraud, duplicate claim, security-integrity emergency, court order, abandonment, or independent decision should justify adverse action.

Within 90 days: abuse-contact correction

Replace the abuse-contact policy with the directory-accuracy model. Keep mandatory contact records. Remove revocation linkage. Limit validation to objective deliverability. Add cure periods and data-quality flags.

Within 120 days: transfer-processing interim rule

Adopt objective transfer recording while the full transfer policy is rewritten. Remove outbound regional embargoes. Publish service-level deadlines. Publish rejection reasons. Create interim appeal.

Within 180 days: PDP scope amendment

Add the policy-scope test and classify proposals. Require impact analysis for existing-holder impact.

Within 270 days: portability and failover design

Publish a registry-state export format, escrow procedure, continuity trigger list, successor registry qualification criteria, and RPKI/reverse-DNS succession plan.

Within 12 months: full registry-function rewrite

Replace the old stewardship and conservation architecture with the narrow registry-function model. Remove non-portability defaults, purpose-based enforcement, anti-property overreach, and anti-speculation language.

Within 18 months: independent review body

Operationalise independent review with emergency interim relief and authority to order registry correction.

This sequence matters. If the transfer policy is rewritten without revocation reform, the registry remains dangerous. If abuse contact is fixed without PDP scope reform, enforcement creep returns. If portability is designed without anti-retroactivity, holders remain exposed. If liability is discussed without narrowing power, the institution will resist. The package must be coherent.

XXXIII. The deeper economic point

The economics of IPv4 are not complicated. The politics are.

IPv4 is scarce. It is useful. It enables revenue. It is embedded in operational systems. It can be leased. It can be transferred. It can be financed. It can be lost through registry action. It is therefore a capital asset, whether the registry likes the phrase or not.

Once an input becomes capital, governance of that input changes. The system needs clear rights, low transaction costs, reliable records, predictable enforcement, neutral transfer, dispute resolution, and liability symmetry. If those elements are missing, capital is discounted. The discount is not paid by abstract speculators. It is paid by networks, customers, and regions.

AFRINIC’s policy choices increase the discount.

Regional lock-in reduces exit value. Needs assessment increases transaction risk. Written approval creates delay. Legacy-status loss reduces inbound supply. Reclaim language increases confiscation risk. Abuse-contact revocation creates operational tail risk. Non-portability increases switching costs. Anti-property rhetoric reduces financing value. Community-policy authority increases legal uncertainty. Lack of failover increases institutional risk. Weak liability increases counterparty risk.

Every one of these becomes a cost of capital.

A rational buyer prices it. A lender prices it. A lessee prices it. An insurer prices it. A customer indirectly pays it. A region suffers it.

This is why the rhetoric of fairness is backwards. A policy that makes assets less liquid does not help poor networks. It harms them. Rich networks can hire lawyers, use brokers, structure around restrictions, buy elsewhere, or absorb delays. Poor networks need clear rules, liquid supply, predictable prices, and low transaction costs. They are the first victims of registry discretion.

The poverty penalty is not caused by markets. It is caused by bad market design.

A good registry would lower transaction costs. AFRINIC’s policy raises them.

A good registry would make resources financeable. AFRINIC’s policy makes them conditionally usable.

A good registry would attract inbound supply. AFRINIC’s policy risks trapping it.

A good registry would record reality. AFRINIC’s policy threatens reality for not asking permission.

That is the economic indictment.

XXXIV. The institutional choice

AFRINIC now has a choice, although it may not yet see it.

It can remain a sovereignty project. It can continue to speak of stewardship, regional resource protection, community control, non-property, conservation, and policy compliance. It can continue to treat transfers as permissions and contacts as enforcement hooks. It can continue to imagine that the registry record creates reality. It can continue to rely on institutional solidarity from the RIR system. It can continue to seek protection from ordinary legal consequences.

That path leads to less authority, not more.

Operators will route around it. Markets will discount it. Courts will question it. Governments will eventually notice that a private registry claims infrastructure power without public-law accountability. Investors will price the risk. Members will treat the registry as adversary. Alternative registration systems will become attractive. The more the registry insists on sovereignty, the more it proves the need for replacement.

Or AFRINIC can become a narrow registry again.

It can protect uniqueness. It can publish accurate records. It can process transfers neutrally. It can recognise leasing. It can preserve contacts. It can maintain RPKI and reverse-DNS continuity. It can provide audit. It can support portability. It can build failover. It can accept independent review. It can reduce mandatory fees to registry function. It can let markets, courts, operators, and customers handle the matters that do not belong to the registry.

That path would make AFRINIC more useful and less powerful.

Useful is enough.

A registry should want to be indispensable because it is trusted, not because exit is impossible.

XXXV. Conclusion: the ledger must defeat the throne

The AFRINIC policy framework is not merely a local administrative document. It is a mirror of the RIR system’s first design failure.

The system never answered the basic question. What does running code actually require from the number-resource layer?

Instead, it built rooms. It built rituals. It built words. Community. Stewardship. Public resource. Region. Conservation. Need. Consensus. Trust. Bottom-up. Then IPv4 became capital. The words did not shrink. They expanded. The registry stopped being a ledger and auditioned for sovereignty.

That is why the 2026 policies matter. They show the old instinct in current form. Transfer policy becomes capital control. Abuse-contact policy becomes enforcement creep. The policy manual becomes a constitutional text for private registry power.

The fix is not to ask AFRINIC to be a kinder sovereign. The fix is to end the sovereignty claim.

The policy modifications are concrete:

• define AFRINIC as a registry-function operator, not custodian of regional capital;
• limit mandatory policy to running-code invariants;
• abolish regional outbound transfer embargoes;
• replace transfer approval with objective transfer recording;
• preserve legacy status and inbound/outbound portability;
• recognise leasing, sub-assignment, financing, and operational delegation;
• remove need assessment from transfers;
• remove anti-speculation morality;
• replace unregistered-invalid language with authority-status language;
• limit abuse-contact rules to directory accuracy;
• remove revocation consequences for contact failure;
• create a revocation firewall;
• protect reliance through anti-retroactivity;
• separate registry administration from enforcement;
• create independent review;
• require registry-state export, failover, and portability;
• tie fees to actual registry function;
• classify policies by impact and require affected-principal legitimacy.

These are not reforms to make the RIR a better ruler. They are amendments to make the ruler unnecessary.

The Internet does not need a regional sovereign over identifiers. It needs a truthful ledger that independent networks can rely on.

The registry may record. It may coordinate. It may protect uniqueness. It may preserve security assertions. It may publish conflicts. It may help transfers become legible. It may keep the address book accurate.

It may not turn geography into title.

It may not turn community into ownership.

It may not turn contacts into obedience.

It may not turn transfer into permission.

It may not turn scarcity into institutional rent.

It may not turn running networks into hostages.

A registry is not a state.

A policy room is not a legislature.

A service region is not a people.

A database is not a throne.

The ledger must defeat the throne.

That is the meaning of Running-Code Primacy applied to AFRINIC policy.

Not mandate laundering.

Not running-code betrayal.

Running-Code Primacy.

Source notes

1. AFRINIC, Consolidated Policy Manual, version 1.6, published 17 November 2020. Relevant provisions include the policy-development description, IPv4 goals, registration requirements, assignment and portability concepts, IPv6 anti-property language, and special-resource restrictions. https://afrinic.net/policy/manual
2. AFRINIC, “Overview of Ratified Policies — 04 February 2026”, covering AFPUB-2020-GEN-006-DRAFT03 and AFPUB-2018-GEN-001-DRAFT07. https://afrinic.net/policy/overview/ratified-04-02-2026
3. AFRINIC, Number Resources Transfer Policy, AFPUB-2020-GEN-006-DRAFT03, ratified 04 February 2026. https://afrinic.net/policy/proposals/2020-gen-006-d3
4. AFRINIC, Abuse Contact Policy Update, AFPUB-2018-GEN-001-DRAFT07, ratified 04 February 2026. https://afrinic.net/policy/proposals/2018-gen-001-d7
5. Lu Heng, “Running-Code Betrayal: How the RIR System Turned Consensus Against the Technical Community”, Note 61. https://heng.lu/running-code-betrayal-how-the-rir-system-turned-consensus-against-the-technical-community/
6. Lu Heng, “Mandate Laundering: From RIR Fantasy to Transition Architecture”, Note 62. https://heng.lu/mandate-laundering-from-rir-fantasy-to-transition-architecture/
7. Lu Heng, “Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption for Internet Coordination Systems”, Note 64. https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
8. Lu Heng, “The Stability Fallacy: What the RIR System Calls Stability, Operators Experience as Risk”, Note 69. https://heng.lu/the-stability-fallacy-in-the-rir-argument/
9. Lu Heng, “The Registry Continuity Fallacy”, Note 70. https://heng.lu/the-registry-continuity-fallacy-protect-the-ledger-not-the-gatekeeper/