Running-Code Primacy: The Patch Needed to Preserve the Internet’s Original Design

The seven preceding Heng.lu notes in this sequence are:

1. Note:52 On When Registry Power Detaches from Liability: Why the Present RIR Coordination Model Cannot Survive in Its Current Form
2. Note:53 On Internet Number Resources Are Not Political Property
3. Note:56 On Regional Internet Registries’ Thick Governance Turns Uniqueness into Double Extraction
4. Note:58 From Double Extraction to Sovereignty Inversion: How Nations Lose Sovereign Control to RIRs for US$100
5. Note:59 The Poverty Penalty: How the RIR Model Taxes the Poor While Calling It Equality
6. Note:61 Running-Code Betrayal: How the RIR System Turned Consensus Against the Technical Community
7. Note:62 Mandate Laundering: From RIR Fantasy to Transition Architecture

The previous seven essays were not a reform programme for the Regional Internet Registries.

They were an autopsy.

They traced the same institutional pathology through different layers: liability detached from consequence; number resources relabelled as political property; uniqueness turned into double extraction; sovereignty inverted; poverty taxed in the name of equality; consensus turned against the networks it was meant to serve; and finally mandate laundered until a clerk began to sound like a sovereign. The sequence matters because the failure was not one bad board, one bad registry, one lawsuit, or one uncomfortable market event. It was a system defect appearing in different clothes. CircleID’s author page now shows that sequence clearly, including Running-Code Betrayal and Mandate Laundering. (circleid.com)

This essay is not about making RIRs better governors.

It is about explaining why the present registry order cannot be the endpoint, and why the least disruptive repair is a supplement to the Internet’s original technical design.

That supplement is Running-Code Primacy.

The need for it is no longer theoretical. In a recent CircleID exchange, John Curran gave the strongest form of the incumbent case. His argument is that the RIR system’s authority is not merely a by-product of narrow technical coordination, but the result of a historical chain: the White Paper, ICANN, the ASO, ICP-2, the IANA stewardship transition, and continuing private-sector multistakeholder governance. He states that the RIR system’s authority is the result of operating within the private-sector multistakeholder model the U.S. Government directed. (circleid.com)

That argument is useful because it makes the dispute visible.

The question is no longer whether historical delegation existed. Of course it did. The question is whether a historically delegated coordination function can later enlarge itself into a standing governance mandate through the same process machinery it controls. The incumbent answer is yes: delegation, recognition, institutional continuity, and community procedure become a self-renewing mandate.

The answer required by the Internet’s original technical design is no.

The original Internet tradition was narrower, harder, and better. RFC 3935 says the IETF’s goal is “to make the Internet work better”; it grounds the work in technical competence, real-world implementation, and “rough consensus and running code.” It also states that when the IETF is not responsible for a protocol or function, it does not attempt to exert control over it. (rfc-editor.org) RFC 7282 repeats David Clark’s old line: “We reject: kings, presidents and voting” and “We believe in: rough consensus and running code.” (rfc-editor.org) RFC 9592 makes the anti-sovereign point still plainer: the IETF does not run, control, or patrol the Internet, and is not “the protocol police.” (rfc-editor.org)

That tradition never meant documents were magic. It meant documents mattered when they helped systems run. It meant process was tolerated because it served deployment. It meant a room was useful only when it disciplined itself around operational reality.

The registry layer borrowed that legitimacy.

It never fully accepted that discipline.

That is the missing patch.

What Running-Code Primacy Means

Running-Code Primacy means that Internet coordination systems must be interpreted narrowly by reference to the minimum technical function that running networks originally justified.

The number-resource layer exists to protect running systems: uniqueness, interoperability, routing-adjacent continuity, security assertions, proof of control, and the minimum common semantics needed for independent networks to work together.

It does not exist to manufacture political authority.

It does not exist to police commercial morality.

It does not exist to convert service geography into title.

It does not exist to turn a mailing list into a legislature.

It does not exist to let a private registry make already-running network assets disappear because its internal policy theory changes.

A registry is not a state.

A database contact is not a corporate power of attorney.

A service region is not a people.

A policy room is not a legislature.

A registry record may describe operational reality. It does not create it.

This is not conservatism. Running-Code Primacy does not say that deployed systems can never change. It says institutional power over change must not be justified by historical delegation, circular recognition, or ritual procedure. It must be justified by deterministic rules that operators can verify locally and by adoption in running systems.

The correct order is: initial specification, distributed ledger state, local validation, running implementation, voluntary adoption, compatibility set, then documentation.

The wrong order is: policy room, declaration, claimed obligation, compliance label, forced operational compliance.

The RIR system failed because it increasingly chose the second order.

The key correction is this: after the initial specification, there is no continuing institution to petition. No committee decides whether non-adoption is a violation. No registry declares a participant invalid merely because it refuses a later change. There is only code, ledger state, validation, adoption, compatibility, local rejection, fork, and selective interoperation.

An operator that refuses a later change does not break the Internet. It may remain in an older compatibility set. It may fork. It may disconnect. It may fail to interoperate with participants that have adopted incompatible rules. But it cannot break the interoperability of others who continue to run mutually compatible code.

The design intuition is the same one that makes distributed ledgers useful: no standing institution is needed to decide ordinary validity. Participants validate state transitions locally under deterministic rules. Invalid state is not punished by an institution. It is ignored by participants that do not accept it.

That is the essential patch missing from number-resource coordination.

The Design Failure Was Present From the Beginning

The first RIR design assumed a low-value world.

Number resources looked technical, abundant, clerical, and low-conflict. In that world, informality seemed efficient. Open mailing lists seemed representative. Contact-based administration seemed adequate. Limited-liability contracts seemed harmless. A regional registry could look like an address book.

IPv4 scarcity destroyed that premise.

IPv4 addresses became scarce, transferable, financeable, leased, capitalized, litigated, sanctioned, and embedded in live networks. The registry layer no longer sat above clerical entries. It sat above productive infrastructure. It sat above asset value. It sat above customer continuity, cloud deployment, telecom operations, national connectivity, court orders, and capital allocation.

The institutional form did not contract to match that new risk.

It expanded.

The result is a system that still speaks the language of technical coordination while exercising the effects of infrastructure governance. It asks operators to treat registry process as neutral while registry decisions affect commercial destiny. It calls its participants “community” while many of those who bear the consequence never gave clean legal representation to the people in the room.

NRS states the structural problem plainly: Internet number registries were designed as technical coordination bodies, but once IPv4 scarcity turned addresses into valuable assets, registry discretion became economic power; when coordination systems control capital, centralization becomes structural risk, and decentralization becomes systems engineering rather than ideology. NRS also states the opposite design direction: one Internet, open and autonomous infrastructure, and decentralized governance with minimum human participation at its core. (nrs.help)

That is the real issue. The registry layer was never patched for the moment when a coordination table became an asset gate.

Running-Code Primacy is that patch.

It is not a better-RIR doctrine.

It is a post-RIR discipline.

The Three Rules of the Patch

The constructive grammar is the revised Note 64: Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption for Internet Coordination Systems: Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption.

The names remain unchanged. The logic must be precise.

Minimum Initial Specification means the common layer contains only deterministic, locally verifiable rules needed for uniqueness, interoperability, proof of control, shared safety and security. It does not contain business-model preferences, pricing theories, regional political sentiment, discretionary enforcement powers, or institutional mission expansion.

Localized Future Decision does not mean that an institution decides which future decisions are local. That would already reintroduce the authority layer. It means the initial specification does the limiting work in advance. After deployment, ordinary future choices remain with participants running code. A participant may adopt, refuse, fork, disconnect, or interoperate selectively. No participant can alter the interoperability of others that continue to run mutually compatible rules.

Voluntary Adoption means later change becomes real only through implementation, validation, deployment, and use. Publication is not reality. Recommendation is not reality. Incumbent recognition is not reality. Non-adoption creates no invalid status. A participant that does not adopt a later change remains in its existing compatibility set. A participant that emits state invalid under another participant’s deterministic rules may be locally ignored. The effect is compatibility selection, not institutional punishment.

These three rules do not rehabilitate registry sovereignty.

They prevent it from reappearing under a new name.

APNIC: The Legal Structure Was the Risk

APNIC shows the first failure: the minimum was never specified hard enough at the beginning.

This is not a code-of-conduct story. It is not an etiquette story. It is not a story about whether a critic was polite enough to an incumbent institution.

It is a legal-structure story.

In March 2023, LARUS published a legal review warning that APNIC’s governance structure created risk not merely for one company in Brisbane, but for Internet governance across the Asia-Pacific region. The review said APNIC’s Director General had ultimate legal power to close APNIC and remove the elected Executive Council, and that urgent governance amendments were needed. It also stated that the structure raised questions about the security of Internet governance for more than one billion Asia-Pacific Internet users. (larus.net)

The first attachment, the ASIC company extract, supplies the corporate baseline. APNIC Pty Ltd was listed as an Australian proprietary company limited by shares, registered in Queensland. Paul Byron Wilson was listed as director and secretary. The share information showed one ordinary share issued, and Paul Byron Wilson listed as the member holding that share. (larus.net)

That is not a normal way to house a critical regional Internet coordination function.

The second attachment, Dr Peter Felter’s legal opinion, drew the governance conclusion. It described the public-facing APNIC structure — members, elections, Executive Council, Director-General and Secretariat — as a special committee resting on Article 9.3 of the Articles of Association of APNIC Pty Ltd. It stated that APNIC Pty Ltd had been a proprietary company controlled through one director, one shareholder and one secretary, all the same person, for 25 years. (larus.net)

That distinction matters.

The public community-facing institution was not the final legal container. It was an edifice built on a private company structure.

The legal opinion then explained why the distinction matters. APNIC’s by-laws were stated to be subject to the Articles and to the powers of the corporation and its directors, officers and members. On that reading, the public APNIC structure could be altered by director resolution of APNIC Pty Ltd; the opinion described APNIC as, in effect, a department of APNIC Pty Ltd. (larus.net)

The opinion’s most damaging point was not that APNIC was technically illegal. It was that legality and propriety are not the same thing. The opinion argued that the trust arrangement did not solve the problem because the Executive Council’s powers still derived from the director’s resolution establishing the special committee. It also noted that APNIC Pty Ltd was a private stock company whose structure and objects did not resemble the nonstock nonprofit model that most people would associate with a regional public-interest registry. (larus.net)

That is the first design failure in its cleanest form.

A region-scale number coordination system should not depend on a structure that requires lawyers to explain why a single-share proprietary company, a special committee, a deed of trust, and an elected council somehow combine into legitimate control of the Asia-Pacific number registry.

A critical coordination layer should be legible from the outside.

It should not require trust in documents behind documents.

It should not require members to discover, after years of institutional dependence, that the elected layer may not be the ultimate legal layer.

It should not give the appearance of member governance while leaving formal power somewhere else.

This is why Minimum Initial Specification must include distributed validity, not institutional trust. Not because a future institution needs better governance. Because a future post-RIR system must avoid needing that institution at all.

The common layer should not depend on a proprietary company’s hidden control structure. It should define deterministic validation rules, proof-of-control state, state-transition rules, conflict rules, ledger replication, exit paths, fork paths, and compatibility sets. If APNIC disappears, captures itself, changes legal posture, or refuses to recognize a valid state, the running network should not depend on APNIC’s continued recognition to know who controls which number resources.

The registry should not be the source of validity.

The distributed ledger state, validated under the initial specification, should be.

ARIN: Policy Met Asset Reality

ARIN shows the second failure: legal and market reality can outrun registry theory.

The decisive event was the Nortel/Microsoft transaction. When Nortel filed for bankruptcy, its 666,624 IPv4 addresses became valuable assets in the proceeding. The addresses were sold to Microsoft for $7.5 million. ARIN intervened on the theory that the addresses were not property and could not be sold free and clear of registry policy. Industry Canada supported that view. The bankruptcy court rejected it; Microsoft later signed a legacy agreement; and the practical result was clear: registry policy could not remain the only source of reality once courts and markets treated number resources as assets. (btw.media)

The important lesson is not that ARIN was uniquely defective.

The lesson is that the registry layer had entered a new category.

A registry record is valuable because operators, courts, buyers, sellers, creditors, and networks rely on it. It does not become authoritative by denying that reliance. It remains useful only if it tracks legal, market, and operational reality closely enough to be trusted.

Once IPv4 became scarce, registry process became a market interface. Transfer rules, need assessments, recognition delays and regional restrictions stopped being clerical details. They became asset frictions. Public analysis now describes a fragmented RIR rulebook in which five regional systems govern a market trading at roughly $18–$45 per address, with conflicting rules capable of stranding assets, delaying mergers, and forcing separate corporate structures simply to hold number blocks. (btw.media)

That is not neutral coordination.

It is a regulatory effect without regulatory accountability.

ARIN proves why Voluntary Adoption matters. Registry policy remains credible only while it describes what actors actually implement, trade, finance, litigate and rely upon. It becomes dangerous when publication is treated as enough to manufacture reality.

A registry that refuses reality does not become sovereign.

It becomes a stale database.

In a Running-Code Primacy design, the lesson is sharper still. Courts and markets do not need an incumbent registry to decide whether value exists. Operators do not need a committee to know whether a block routes. Participants need deterministic rules that allow proof of control, conflict resolution, ledger-visible state transitions, and compatibility. The old registry may publish a view. A software client may display a view. A ledger explorer may display a view. None is the source of validity.

There is no registry to move to.

There is no registry to ask.

There is only a distributed state that participants validate, accept, reject, fork from, or interoperate with.

AFRINIC: When Registry Theory Threatened Running Assets

AFRINIC is the central case because it stripped the problem down to its essentials.

The wrong story is that a troublesome member paralysed a regional registry.

That is the incumbent morality play.

The structural story is different. AFRINIC tried to convert commercial use, customer geography, leasing, member relationship and internal policy interpretation into a claimed power to deregister already-running number resources. Once that claim was made, the conflict could no longer remain a policy-room disagreement. It became a test of whether a private registry could use regional rhetoric and policy silence to threaten operationally embedded assets.

The facts do not require theatrical inflation. Public reporting described the AFRINIC dispute as a simple commercial dispute over IP addresses that became the largest Internet-governance story in Africa. It also reported that Cloud Innovation had often been painted as the villain, while later documentary material pointed to destructive forces inside AFRINIC itself and to litigation being delayed, prolonged and continued by AFRINIC representatives at AFRINIC’s cost. (btw.media)

That matters because it reverses the usual story.

Litigation did not create the structural failure.

Litigation exposed it.

The relevant failure was already present when a private registry treated absence of express permission as a basis for coercive control. Leasing was not a threat to uniqueness. Customer geography was not a duplicate assignment. Commercial use was not a routing-security failure. A business model disliked by a registry was not a global invariant.

Yet the registry claim placed these issues inside a revocation frame.

That is the moment when coordination becomes governance.

Reporting records that AFRINIC sent Cloud Innovation a letter in March 2021 alleging policy breaches and threatening membership termination; that in July 2021 the Supreme Court of Mauritius prohibited AFRINIC from terminating Cloud Innovation’s membership; and that a further attempt by AFRINIC to cancel membership was blocked in December 2021. (btw.media) That sequence is not a story of a registry calmly protecting the Internet. It is a story of registry authority meeting ordinary law.

Nor was the broader institutional breakdown caused by too little registry power. The deeper problem was lock-in. If one registry holds monopoly recognition over valuable live assets, every internal failure becomes an Internet-continuity risk. If members cannot leave the recognition system, registry failure becomes hostage power.

A registry may correct demonstrable registration fraud in its own records.

It may prevent duplicate assignment while the registry model still exists.

It may maintain security assertions while participants still rely on it.

But those are transitional functions of an old architecture.

In a post-RIR architecture, those functions are not performed by a registry. They are encoded into distributed ledger state, proof-of-control rules, conflict rules, and locally verifiable transitions.

A private body should not turn leasing into regional treason.

It should not turn customer geography into a revocation trigger.

It should not treat commercial disagreement as technical invalidity.

It should not convert asset continuity into permission.

AFRINIC proves the need for Localized Future Decision correctly understood. There is no central body deciding that a future commercial decision “belongs locally”. Rather, the initial specification must ensure that these decisions never enter the common layer in the first place. Leasing, customer geography, commercial use, pricing, financing, customer mix and deployment strategy remain outside deterministic validity rules unless they directly affect uniqueness, security, proof of control or interoperability.

An operator cannot break other operators’ interoperability by leasing addresses.

An operator cannot break other operators’ interoperability by serving customers outside a historical registry region.

An operator cannot break other operators’ interoperability by using a business model that a registry dislikes.

At most, an operator can fail to satisfy deterministic rules that other participants run. In that case, other participants locally reject the invalid state. There is no punishment layer. There is no compliance court. There is no regional sovereign.

That line is not ideological.

It is operational.

The Proxy Problem Is Not a Detail

The AFRINIC election controversy made a second defect visible: representation.

NRS states its representational basis in direct legal terms. It says listed members entrusted NRS to represent them in RIR governance matters and that each listed member provided a power of attorney. (nrs.help) During the AFRINIC election dispute, NRS asked members to report if their names appeared on voter registers or if votes were recorded without their participation, and said such factual reporting would be handled through lawful channels. (nrs.help)

That matters because it shows the difference between legal representation and community rhetoric.

The RIR system often collapses several categories into one: corporate representative, database contact, technical contact, employee, consultant, proxy holder, policy participant, mailing-list regular. These are not the same thing.

A database contact can help administer records.

A power of attorney can authorize representation if valid and within scope.

A policy participant can contribute expertise.

A mailing-list speaker can state an opinion.

None of these automatically becomes a legal principal for every company, customer, state, creditor, lender, buyer, lessee or network that bears the consequence of a registry decision.

This distinction can be ignored only while the common layer stays thin. Once the registry claims power over revocation, transfer, leasing, market access, sanctions treatment, asset continuity or national infrastructure risk, representation becomes constitutional.

A room is not a mandate.

A mailing list is not a people.

A contact record is not a corporate power of attorney.

A service region is not a sovereign constituency.

This is not procedural fastidiousness.

It is the difference between coordination and rule.

A Running-Code Primacy system avoids this trap by reducing the number of decisions that require representation at all. If validity is deterministic and local, there is less to vote on. If future change is voluntary, there is no need to decide whether a non-adopter is in bad standing. If state is represented on a distributed ledger, there is no need to beg an incumbent registry to recognize one’s continued existence. If compatibility sets are explicit, participants know whom they can interoperate with without asking a political room.

The best governance problem is the one the system design removes.

RIPE NCC and LACNIC: The Club and the Choke Point

RIPE NCC and LACNIC do not prove that some RIRs are more civilised than others. They prove that the RIR model has two enforcement layers beyond the technical function: the club and the choke point.

The club decides who is respectable. The choke point decides whose registry status can move.

RIPE NCC’s refusal to accept LARUS sponsorship for RIPE 90 showed the club layer plainly. A member offered sponsorship. The registry-side ecosystem rejected it because of an unrelated dispute in another region. That was not a routing-security decision. It was not a uniqueness decision. It was not a deterministic validation rule. It was private blacklisting through conference access. LACNIC also refused my sponsorship. Different region, same instinct: the registry club protects itself by controlling rooms, visibility, sponsorship, reputation and social legitimacy.

That is not community. It is gatekeeping.

The sanctions layer is worse because it shows the central choke point in legal form. RIPE NCC states that, because it is based in the Netherlands, it must comply with EU sanctions; when sanctions apply, it freezes registration in the RIPE Database, blocks acquisition and transfer, and may treat cases as frozen when a party cannot provide sufficient documentation. It also screens OFAC lists because banking relationships affect payments. (RIPE NCC sanctions transparency)

That is not a criticism of RIPE NCC for obeying law. A Dutch entity must obey Dutch and EU law. The problem is architecture: why should one Dutch private entity be the central recognition point for number-resource mobility across many countries, operators and legal systems?

Sanctions can bind a bank. Sanctions can bind a Dutch entity. Sanctions can bind a counterparty that chooses not to transact. They should not become a global technical validity condition for everyone else.

That is the design failure.

The same centrality that lets a club exclude a critic also lets a jurisdiction freeze registry mobility. One is social enforcement. The other is legal enforcement. Both work only because the registry sits where validity should not sit.

This links directly to the three principles.

Minimum Initial Specification: club respectability, sponsorship eligibility, regional politics, sanctions classification and reputation must never enter the common layer. The common layer should contain only deterministic rules for uniqueness, proof of control, conflict handling, state transition and security.

Localized Future Decision: legal risk, counterparty choice, sponsorship, commercial trust and sanctions exposure belong to the actors who bear them. A Dutch entity may refuse a transaction. A bank may refuse payment. A counterparty may refuse dealing. None of that should become universal registry truth.

Voluntary Adoption: participants accept counterparties by running code, validating state and choosing whom to interoperate with. Non-adoption is not misconduct. Local refusal is not global invalidity. A club’s refusal should not erase valid state. A sanctions duty should constrain the actor subject to it, not rewrite the world’s number-resource ledger.

This is why distributed ledger design is necessary. In a post-RIR system, ordinary validity is not decided by RIPE NCC, LACNIC, a sanctions desk, a meeting committee or a sponsor office. Participants validate state locally. Counterparties accept or reject voluntarily. Forks are visible. Compatibility sets are explicit. The central registry disappears as the source of truth.

The fix is not better etiquette.

The fix is not a more transparent sanctions queue.

The fix is to remove validity from both the club and the choke point.

Distributed state. Local validation. Voluntary counterparty acceptance. No registry as source of validity.

The NRO Letter: Upward Escape

The most serious evidence is not AFRINIC’s attempted overreach.

It is the system’s collective response.

In 2022, the Number Resource Organization wrote to the Government of Mauritius. The letter described the NRO as the coordinating body for the world’s RIRs and said the RIRs manage number resources in their respective regions. It stated that all five registries perform the function of administering number resources under rules adopted regionally or global policies adopted unanimously. (nro.net)

The same letter criticized Cloud Innovation’s litigation, said more than 25 lawsuits had been filed, complained of court orders that froze AFRINIC’s accounts and stopped elections, and stated that AFRINIC had repeatedly asked Mauritius to recognize it as an international organization. The NRO urged the government to take steps to preserve AFRINIC’s independence and Internet stability in Africa. (nro.net)

That is the most revealing document in the whole story.

When a private registry collided with ordinary courts, the system’s reflex was not to narrow the mandate.

It was not to remove registry lock-in.

It was not to separate recordkeeping from enforcement.

It was not to define distributed validation.

It was not to ask whether unilateral deregistration power over running assets had been illegitimate from the beginning.

The reflex was upward escape.

A private coordination body cannot be technical when it wants discretion, community-based when it wants legitimacy, contractual when it wants fees, non-property when it wants to avoid ownership liability, and quasi-international when it wants insulation from courts.

That package is not governance.

It is mandate laundering at system level.

If RIRs want public-law privilege, they must accept public-law accountability. If they want private-law flexibility, they must accept private-law litigation. What they cannot rationally demand is private discretion, public-infrastructure importance, low liability, weak representation, monopoly status, and quasi-diplomatic insulation at the same time.

That is the disaster path.

Running-Code Primacy rejects it.

When a registry meets legal resistance, it must not escape upward into immunity. The architecture must contract downward into the narrow running-code function that justified it.

Less sovereignty.

No registry as source of validity.

Less enforcement.

More distributed validation.

ICP-2 Revision Is Not Enough

The present system knows something has broken.

ICANN’s public-comment page for the second draft of the RIR Governance Document says the proposal would set rules and criteria for recognizing new RIRs, operating obligations and requirements of RIRs, and derecognition rules; if adopted, it would supersede ICP-2. The same page says the process was initiated after the NRO asked the ASO to propose updates to provide the RIR system with greater accountability to the Internet community. (icann.org)

That may be necessary as a continuity measure.

It is not sufficient as a legitimacy theory.

Recognition and derecognition rules answer a late question: when has a registry failed badly enough to be removed?

The earlier question is more important: why should a registry be powerful enough to fail catastrophically in the first place?

A successor to ICP-2 that merely hardens recognition, audit, handoff and derecognition may improve institutional hygiene while preserving the category error. It still assumes that the RIR is the primary sovereign form of number-resource coordination.

Running-Code Primacy asks a different set of questions.

How does the Internet continue if an RIR collapses?

How do number-resource claims remain verifiable without incumbent permission?

How does uniqueness survive without monopoly discretion?

How are records prevented from becoming enforcement weapons?

How are commercial decisions kept outside deterministic validity unless a true global invariant is at risk?

How does coordination remain usable with no authoritative registry at all?

How does an operator validate ordinary state without asking a standing body for status?

How does refusal avoid becoming a violation label?

These are not reform questions.

They are post-RIR questions.

Why This Is the Patch to the Original Design

The issue is not whether one likes or dislikes the incumbent registries.

The issue is whether the number-resource layer still follows the design discipline that made the Internet work: minimum common rules, local validation, voluntary adoption, and running code.

Running-Code Primacy is not a public-relations strategy and not an institutional compromise. It is the technical repair implied by the original design. If the Internet was built to reject kings, presidents, and voting as sources of technical truth, then the number-resource layer cannot recreate those forms through registry process, historical delegation, or community theatre.

Consensus alone can be ritualized. Running code alone can be subordinated if the registry layer sits upstream of recognition. The missing rule is interpretive and architectural: where institutional process conflicts with the minimum technical function that running systems require, running code has priority; and where later change is proposed, it becomes real only through voluntary adoption by participants running validation rules.

That is how the original design is preserved, not abandoned.

The Internet mattered because it became the first global communications system that did not require prior permission from a single sovereign, ministry, church, corporation, or gatekeeper. If that achievement is still worth defending, the registry layer cannot become the exception that swallows the rule.

A system built to avoid kings cannot allow a bookkeeper to audition for one.

The patch restores the original hierarchy: code first, operators first, deterministic validation first, distributed state first; institutions, if any remain during transition, only as non-authoritative artifacts, never as sources of validity.

What Post-RIR Coordination Requires

Post-RIR coordination does not mean chaos.

It means the common layer becomes thinner, more objective, more deterministic, and more distributed than the present RIR monopoly.

There is no registry to move to.

There is no new registry to crown.

There is no replacement priesthood.

There is a distributed ledger of number-resource state, with deterministic validation rules, proof-of-control mechanisms, conflict handling, compatibility sets, state-transition history, and local verification by participants.

The common layer should preserve identifier uniqueness, proof of control, transfer state, delegation state, routing-adjacent security assertions, auditability, conflict metadata, and fork visibility.

The operator layer should control commercial use, leasing, customer geography, routing practice, financing, counterparty selection, and non-invariant business rules.

The adoption layer should determine what becomes real. A coordination rule matters only if operators can implement it, counterparties can accept it, markets can rely on it, courts can understand it, and interoperability is preserved without making incumbent recognition the sole source of reality.

The enforcement layer must not be merged with the state layer. A distributed ledger may record state. It may validate transitions. It may expose conflicts. It may make proof portable. It must not become prosecutor, judge, sanctioning authority, market regulator, commercial moralist, and asset custodian at once.

Most importantly, portability must be understood correctly.

In a distributed-ledger world, portability does not mean moving from one registry to another registry. That is still registry thinking. There is no registry to move to. The holder’s proof of control, state history, and transfer capability are not trapped inside an incumbent database. They exist in a shared verifiable state that participants validate locally and counterparties accept voluntarily.

Without that, every registry is a lock-in point.

With it, the registry disappears as a source of validity.

Post-RIR coordination therefore needs four design properties.

First, deterministic validity. A participant should know whether a state transition, proof, delegation, transfer, or assertion is valid by applying the specification locally.

Second, compatibility sets. If participants adopt different future rules, the system should describe the compatibility boundary clearly rather than treating dissent as misconduct.

Third, distributed proof of control. A holder should not “move” its resources to another registry; it should demonstrate control through ledger-valid state that any counterparty can verify without incumbent blessing.

Fourth, fork visibility. If rule sets diverge, the divergence should be explicit. Participants decide which compatibility set to run and which counterparties to accept. A fork may isolate participants. It does not give one side institutional power to erase the other.

That is not an argument for five better monopolies.

It is an argument against monopoly as the source of validity.

Why the Failure Path Is Predictable

If nothing changes, the failure path is clear.

First, more disputes will move from policy rooms into courts. Scarce assets attract legal scrutiny. Courts will be asked to freeze accounts, preserve records, block improper elections, appoint receivers, recognize transfers, or determine who may act for a registry.

Second, states will stop treating RIRs as harmless technical associations. Numbering continuity touches national connectivity, sanctions, law enforcement, telecom resilience, cloud infrastructure, and economic security. No state will forever accept a foreign private registry shell as the unexamined upstream point of national communications continuity.

Third, operators will route around registry authority where possible. If registry records become political, unsafe, unrepresentative, or detached from asset reality, operators will rely on private contracts, litigation-backed transfers, alternative attestations, national recognition, or de facto routing reality.

Fourth, ICANN and the NRO layer will be tempted to centralize. That would produce a thicker version of the same problem unless the mandate itself is narrowed.

Fifth, governments will be tempted to nationalize. That would be predictable and dangerous. If private registries claim quasi-sovereign authority without public accountability, states will eventually reclaim sovereignty. The result could be fragmentation, retaliation, conflicting registries, and political routing pressure.

The Internet does not fail only when packets stop moving.

It also fails when the institutions describing who may use identifiers lose the trust of the operators who move the packets.

A distributed ledger does not solve every political problem. It does something more important: it removes the standing registry as the ordinary source of validity. That narrows the attack surface. It reduces institutional hostage power. It turns future disagreement into compatibility selection rather than administrative war.

The Question Changes

The old system asks: who has the mandate?

That is the wrong question.

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

Does this rule protect uniqueness?

Does it preserve interoperability?

Does it correct demonstrable registration fraud through deterministic evidence?

Does it protect routing-adjacent security?

Does it maintain proof-of-control accuracy?

Does it enable local validation?

Does it remove dependence on one incumbent?

Does it describe adopted reality, or declare unadopted obligation?

Can a participant refuse it without being assigned invalid status?

Can a participant verify ordinary validity without asking a registry for status?

Can a counterparty accept or reject state voluntarily?

Can a fork happen without one side being erased by an institution?

If the answer is not tied to deterministic running-code necessity, the power should not sit in the common layer.

That is Running-Code Primacy.

For Discussion

This proposal is for discussion. It is not a final settlement.

The next step should be a serious Internet-Draft or BCP-style document defining Running-Code Primacy for Internet coordination systems, beginning with number resources. The draft should not ask how to rehabilitate RIR monopoly. It should ask how to build post-RIR coordination through distributed ledger state, deterministic validation, voluntary adoption, counterparty acceptance, and explicit compatibility sets.

It should be tested by operators, lawyers, economists, protocol engineers, routing-security experts, market participants, governments, and critics.

The draft should ask hard questions.

What are the global invariants?

Which validation rules are deterministic?

Which state transitions must be globally visible?

Which old registry powers are historical residue?

Which decisions belong to operators?

Which decisions require no representation because they should never enter the common layer?

What is the refusal path?

What is the fork path?

What is the local rejection path?

How does a holder prove control without an incumbent registry?

How does a counterparty verify state without a registry?

Can the Internet continue if an RIR collapses?

Can number resources remain unique without incumbent permission?

Can a participant validate ordinary state without a standing institution?

Can a policy process distinguish a running-code invariant from institutional appetite?

Can the old registry layer disappear without losing verifiable state?

Can a record describe reality without becoming sovereign over it?

Anyone interested can contact me through LinkedIn. Serious researchers, technical authors, institutions, or policy experts who want to help turn this into a first Internet-Draft and eventually an RFC or BCP discussion, if the community finds it useful, should contact me. LARUS Foundation and I are willing to support and fund serious research in this direction.

The RIR system’s first design failed because it never asked what running code actually required.

It asked who could speak in the room.

The next system must reverse that order.

Not mandate laundering.

Not running-code betrayal.

Running-Code Primacy.

Appendix: Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption for Internet Coordination Systems

Note 64

Abstract

This document describes a design pattern for Internet coordination systems whose purpose is to provide shared technical reference points without creating a continuing authority above the participants who run the system. It defines three linked principles: Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption.

Under this model, the Initial Specification defines only the deterministic, locally verifiable rules required for uniqueness, interoperability, proof of control, shared safety, and security. After the Initial Specification, future changes are not approved by a central body. They are adopted, ignored, forked, or abandoned by participants running code.

The intended design pattern is a distributed ledger of valid state, or an equivalent distributed verifiable-state mechanism, not a registry hierarchy. There is no standing registry that decides ordinary validity. Participants validate state locally, accept counterparties voluntarily, and decide which compatibility sets they run.

Non-adoption is not a violation. A participant that does not adopt a later change remains in its existing compatibility set. A participant that emits state not valid under the deterministic rules accepted by another participant may be locally ignored by that participant. The effect is compatibility selection, fork, isolation, or selective interoperation, not institutional punishment.

This document does not define a wire protocol. It specifies a Best Current Practice for the design of protocols, identifier systems, distributed ledgers, and coordination mechanisms that must not become permanent governance institutions.

1.Introduction

Many Internet systems begin with a narrow technical purpose: to allow independent actors to interoperate by sharing a common reference point, identifier space, validation rule, ledger state, or proof-of-control record. Over time, such systems often accumulate authority that was not required for initial interoperability.

This usually happens in three steps.

First, future questions are placed into the founding layer before they are technically necessary.

Second, choices that should be made by participants running their own systems become dependent on recognition, interpretation, or status decisions by a continuing body.

Third, publication, registration, recommendation, or procedural approval is treated as sufficient to create operational obligation, even where participants have not adopted the change in running systems.

The result is a brittle system. A technical reference layer becomes a governance layer. A recordkeeper becomes a gatekeeper. A coordination artifact becomes a source of future control.

This document proposes a different design discipline:

• Minimum Initial Specification: specify only the deterministic common rules required for baseline interoperability, uniqueness, proof of control, shared safety, and security.
• Localized Future Decision: after the Initial Specification, keep future choices with participants running code. A participant may adopt, refuse, fork, disconnect, or interoperate selectively. No participant can alter the interoperability of other participants that continue to run mutually compatible rules.
• Voluntary Adoption: make later change real only through implementation, operation, validation, and adoption by participants running code.

These principles are related. A system that specifies too much at the beginning pre-loads future control into the common layer. A system that leaves a continuing recognition layer allows authority to reappear after deployment. A system that treats publication as reality converts documentation into command.

The design intuition is simple: validity must be determined by deterministic rules that participants can verify locally against shared state. A participant may adopt a later change, refuse it, fork, disconnect, or interoperate selectively. It may at most remove itself from a compatibility set. It cannot, by refusing a change, break the interoperability of other participants that continue to run mutually compatible code.

This is the general lesson of distributed ledger design: consensus rules are enforced by participants who run validation code and decide which state they accept, not by an institution standing above them.

2. Scope

This document applies to Internet coordination systems, including but not limited to identifier systems, naming and numbering frameworks, protocol-extension mechanisms, proof-of-control systems, portability systems, distributed ledgers, and other architectures in which independent actors rely on a common technical reference point.

This document does not argue against common rules. It argues that common rules should be deterministic, minimal, locally verifiable, and limited to what the system actually needs in order to run.

This document does not require any specific distributed ledger implementation. It requires a design property: participants should be able to determine validity by applying the Initial Specification locally to shared or replicable state, without asking a standing authority for permission or status.

3.Conventions and Definitions

3.1. Requirements Language

The capitalized requirement terms in this document are to be interpreted in the sense defined by BCP 14, specifically RFC 2119 and RFC 8174.

3.2. Terminology

Initial Specification:
The set of rules, data structures, formats, invariants, validation procedures, state-transition rules, and conflict rules required for first deployment of a system.

Common Layer:
The minimum shared rule set or reference structure required for independent participants to interoperate. The common layer is not an institution. It is the technical substance that participants implement and verify.

Distributed Ledger:
A replicated or otherwise distributed record of state transitions that allows participants to verify ordinary validity without relying on a standing registry, committee, or other authority. The term does not require any particular consensus algorithm or implementation.

Deterministic Validation Rule:
A rule that allows a participant to decide, by local computation or local verification, whether a state, record, transition, assertion, or message is valid under a specified rule set.

Global Invariant:
A property that must remain common within a compatibility set in order to preserve uniqueness, baseline interoperability, proof-of-control integrity, shared safety, or security.

Participant:
An operator, implementation, node, network, organization, or other actor that runs, verifies, deploys, or relies on the system.

Compatibility Set:
A group of participants whose implemented validation rules allow them to interoperate. A later change may create a new compatibility set if some participants adopt it and others do not.

Adoption:
Actual implementation, deployment, validation, and use by participants running the system.

Counterparty Acceptance:
A participant’s voluntary decision to accept, transact with, interoperate with, or rely on another participant’s state under the validation rules it runs.

Non-Adoption:
A participant’s choice not to implement or use a proposed change. Non-adoption does not create invalid status. It only means the participant has not joined the compatibility set created by that change.

Local Rejection:
A participant’s local decision to ignore, reject, or not interoperate with a state, message, record, or transition that is invalid or incompatible under the validation rules it runs.

Fork:
A divergence in validation rules or operational practice that creates two or more compatibility sets.

Coordination Artifact:
A document, recommendation, implementation note, profile, reference implementation, ledger explorer, mirror, or other artifact that helps participants coordinate. A coordination artifact does not create binding operational reality unless participants adopt it in running systems.

4. Problem Statement

Designers often try to reduce future uncertainty by writing too much into the founding layer or by leaving a continuing body to interpret future questions. This appears prudent. It is often dangerous.

Over-specification at the founding layer has three costs.

First, it moves future choices into a common layer where change is harder and where capture has greater effect.

Second, it creates ambiguity between technical validity and institutional recognition.

Third, it encourages a body that maintains records, publishes documents, or convenes participants to treat those acts as authority over future reality.

The same problem appears after deployment. If a system requires a continuing body to approve change, determine status, or interpret ordinary operation, the system has created a post-founding control layer. That layer may begin as administration. It can become governance. It can then become a choke point.

The design goal of this document is not better institutional discretion. The design goal is to avoid the need for that discretion.

A well-designed Internet coordination system should define deterministic, locally verifiable validity rules at the start; represent valid state in distributed or otherwise replicable form; leave non-invariant choices outside the common layer; and allow later changes to become real only when participants voluntarily adopt them in running systems.

5. Principle 1: Minimum Initial Specification

5.1. Statement

An Initial Specification SHOULD define only the minimum deterministic common rules required for baseline interoperability, uniqueness, proof of control, shared safety, and security.

5.2. Requirements

A design using this principle:

1. MUST identify its Global Invariants explicitly.
2. MUST define deterministic validation rules for each Global Invariant.
3. MUST define how valid state is represented, replicated, verified, and updated.
4. MUST NOT place a rule in the Initial Specification unless the rule is required to preserve a stated Global Invariant or to enable first deployment.
5. MUST separate validation rules from policy preferences, business arrangements, institutional roles, governance aspirations, and discretionary judgment.
6. MUST allow participants to verify ordinary validity locally without asking any institution, registry, committee, policy body, or other authority.
7. SHOULD define data structures, signatures, proofs, state-transition rules, conflict rules, or other mechanisms necessary for local verification.
8. SHOULD define extension signalling, versioning, compatibility labelling, or fork identification where future variation is foreseeable.
9. MUST ensure that required coordination artifacts are portable, auditable, reproducible, and replaceable.
10. SHOULD prefer objective machine-verifiable conditions over subjective merit judgment.
11. MUST NOT make future institutional recognition the only path by which a valid state can be known, recorded, or used.

5.3. Design Implications

Minimum Initial Specification does not mean vague specification. It means strict specification of only what must be common.

A system still needs enough common structure to run. The discipline is to distinguish between:

• what must be common for uniqueness, interoperability, proof of control, shared safety, and security; and
• what can remain outside the common layer because it concerns operator preference, business practice, counterparty choice, deployment timing, or later adoption choice.

A design that cannot state its Global Invariants and deterministic validation rules clearly should assume that it has specified too much discretion and too little verifiable substance.

6.Principle 2: Localized Future Decision

6.1. Statement

After the Initial Specification, Future Decisions SHOULD remain local to participants running code. A Future Decision becomes effective only for the compatibility set whose participants adopt it. No continuing authority is required to approve it, and non-adoption does not create invalid status.

6.2. Requirements

A design using this principle:

1. MUST NOT require participants to obtain permission from an incumbent institution, registry, committee, board, policy body, or other authority for choices that do not alter the deterministic validation rules of the compatibility set they participate in.
2. MUST NOT create a standing body whose recognition is the only path by which a later change can become operationally real.
3. MUST distinguish validity under the Initial Specification from compatibility with a later optional change.
4. MUST NOT treat non-adoption of a later change as invalidity.
5. MUST allow participants to remain in an existing compatibility set when they do not adopt a later change.
6. MUST allow participants to join a new compatibility set by adopting new validation rules or operational profiles.
7. MUST allow participants to locally reject states, records, transitions, or messages that are invalid or incompatible under the validation rules they run.
8. MUST allow participants to choose counterparties voluntarily according to the validation rules and compatibility sets they accept.
9. MUST NOT authorize any institution, registry, committee, policy body, or other actor to declare a participant invalid merely because it refused a later change.
10. SHOULD make forks, versions, profiles, or compatibility sets explicit so that participants know which rules they are running and which other participants they can interoperate with.
11. SHOULD avoid any design in which an incumbent recordkeeper can prevent otherwise valid participants from continuing to interoperate.

6.3. Design Implications

Localized Future Decision does not mean that a central authority allocates future decisions to local actors. It means the system is designed so that, after the Initial Specification, ordinary future choices do not need such allocation.

The Initial Specification does the limiting work in advance. It defines the minimum invariants required for uniqueness, interoperability, proof of control, shared safety, and security. Everything else remains outside the common layer.

Future change is not approved centrally. It is adopted, ignored, forked, or abandoned by participants running code.

A participant that refuses a change may remain outside the compatibility set created by that change. It may disconnect itself from others. It may continue in an older compatibility set. It may fork. It may interoperate selectively. But it cannot break the interoperability of other participants who continue to run mutually compatible rules.

The effect of invalid or incompatible state is local rejection, not punishment. No one needs to decide that a participant is in bad standing. A participant running compatible validation rules simply does not accept the invalid or incompatible state.

7. Principle 3: Voluntary Adoption

7.1. Statement

Changes in an Internet coordination system SHOULD become operationally real through implementation, validation, deployment, counterparty acceptance, and adoption by participants, not through publication or declaration alone.

7.2. Requirements

A design using this principle:

1. MUST NOT treat publication, recommendation, meeting approval, or procedural approval as sufficient to create universal operational obligation.
2. MUST allow new rules, extensions, profiles, or procedures to be deployed incrementally by participants that choose to run them.
3. MUST allow participants to refuse a later change without acquiring invalid status, so long as their own state transitions satisfy the deterministic validation rules of their compatibility set.
4. MUST allow participants to continue using an older compatibility set where the Initial Specification permits such continuity.
5. MUST allow participants running one compatibility set to locally reject or ignore state from another compatibility set where the rules are incompatible.
6. SHOULD define adoption paths for major changes, including version signalling, compatibility labelling, transition guidance, and test vectors.
7. SHOULD define refusal paths for major changes, including how non-adopting participants continue operation, identify their compatibility set, and avoid ambiguous interoperation.
8. MUST ensure that required coordination artifacts can be exited, mirrored, reimplemented, or replaced without impossible transition cost.
9. SHOULD have records, recommendations, and coordination artifacts describe adopted reality rather than declare unadopted future reality into existence.
10. MUST avoid designing a system in which the only way for a change to become real is prior recognition by an incumbent body.

7.3. Design Implications

Voluntary Adoption is the operational test of whether a change is useful, tolerable, and compatible with real deployment.

A proposal is not reality. A recommendation is not reality. A document is not reality. Reality appears when participants implement, validate, deploy, accept counterparties, and rely on the change.

Non-adoption creates no status of violation. It creates only a fact: the participant has not joined the compatibility set created by the change.

This does not eliminate standards processes, documentation, implementation notes, explorers, mirrors, or review. It limits their claim. They may help participants coordinate. They may publish reference material. They may describe adoption. They may recommend. They may not, by declaration alone, make unadopted future reality binding on participants who do not run it.

8.Relationship Among the Three Principles

The three principles are mutually reinforcing and are not effective in isolation.

Minimum Initial Specification ensures that the common layer contains deterministic validation rules rather than discretionary authority.

Localized Future Decision ensures that future choices remain with participants running code rather than being recaptured by a central approval layer.

Voluntary Adoption ensures that later change must survive contact with implementation, verification, counterparty acceptance, and use.

A system that adopts only one or two of these principles may reproduce the same centralization by other means.

• Minimum Initial Specification without Localized Future Decision may still allow authority to accumulate after deployment.
• Localized Future Decision without Minimum Initial Specification may produce ambiguity, because participants cannot locally determine validity.
• Voluntary Adoption without deterministic validation may produce confusion, because participants cannot distinguish compatible variation from invalid state.
• Deterministic validation without distributed state may still leave participants dependent on a privileged recordkeeper.
• Distributed state without fork visibility may hide disagreement until operational failure.
• Distributed state without voluntary counterparty acceptance may recreate coercion through another interface.

Together, the principles produce a system in which the common layer is thin, validity is locally verifiable, future change is voluntary, state is distributed, and no standing institution is needed to decide ordinary operation.

9. Recommended Design Pattern

9.1. Deterministic Distributed Common Layer

The common layer SHOULD be limited to:

• stable identifier semantics;
• deterministic validity rules;
• conflict-resolution rules necessary to preserve uniqueness;
• proof-of-control mechanisms;
• state-transition rules;
• wire-level or protocol-level interoperability requirements;
• shared security invariants;
• portable and auditable state formats;
• distributed or replicated state visibility;
• extension signalling and compatibility-set identification.

The common layer SHOULD NOT contain:

• business-model rules;
• pricing rules;
• regional political preferences;
• eligibility ideology unrelated to technical invariants;
• discretionary enforcement powers;
• subjective merit assessments;
• institutional mission expansion;
• any rule whose primary function is to preserve the authority of an incumbent body.

9.2. Operator Decision Surface

The following SHOULD remain outside the common layer unless they directly alter a stated Global Invariant:

• deployment timing;
• commercial use;
• customer geography;
• leasing, financing, or transfer arrangements;
• local eligibility preference;
• operational sequencing;
• routing practice not required for shared validity;
• business model;
• organizational structure;
• voluntary migration timing;
• optional profiles or extensions;
• counterparty choice.

Participants MAY adopt different choices in these areas. Those choices may produce different compatibility sets, business relationships, peering arrangements, or operational communities. They do not create invalidity unless they violate deterministic validation rules in a compatibility set.

9.3. Adoption Loop

Where feasible, the preferred order for material system change is:

1. proposal;
2. implementation;
3. test vectors or deterministic verification method;
4. limited deployment by willing participants;
5. observation of interoperability and security effects;
6. compatibility-set labelling;
7. documentation or recommendation describing adopted reality.

A coordination artifact SHOULD follow adoption rather than attempt to preempt it.

9.4. Fork, Local Rejection, and Counterparty Acceptance

A conforming design SHOULD treat fork, local rejection, and counterparty acceptance as normal design requirements rather than failures.

The system SHOULD define how a participant can:

• continue in an older compatibility set;
• adopt a newer compatibility set;
• fork into a different compatibility set;
• verify state without relying on an incumbent recordkeeper;
• accept counterparties voluntarily;
• reject invalid or incompatible state locally;
• interoperate selectively where compatibility permits.

A system that cannot be forked, locally verified, or selectively accepted without destroying valid operation has probably hidden governance power inside its recordkeeping function.

10.Applicability and Limits

This design pattern is particularly applicable where:

• the system is multi-actor and multi-jurisdictional;
• independent deployment matters;
• the coordination layer is intended to remain thin;
• future variation is likely but cannot be predicted in detail;
• lock-in would create governance risk;
• validity can be made deterministic or locally verifiable;
• distributed state can reduce institutional capture risk.

It may be less directly applicable where:

• a single administrative domain is the intended architecture;
• strong real-time coupling requires uniform behavior at all times;
• life-safety concerns require immediate global uniformity;
• validity cannot be locally verified by any practical mechanism.

Even in such cases, designers SHOULD still minimize the common layer and avoid discretionary future control wherever possible.

11.Non-Goals

This document does not:

• prohibit all coordination;
• require any specific distributed ledger implementation;
• guarantee consensus;
• guarantee political neutrality;
• require all participants to adopt every later change;
• treat refusal to adopt as invalidity;
• legitimize incompatible local behavior while claiming compatibility;
• eliminate the need for security-critical common rules.

12. Security Considerations

A thinner coordination layer can reduce capture risk, lower the blast radius of institutional error, and improve replaceability. However, increased local discretion and distributed state can also create inconsistent security posture, downgrade paths, fragmentation pressure, ambiguous compatibility claims, unsafe forks, ledger-state disputes, and counterfeit proof attempts.

Designers applying this document MUST therefore specify security invariants explicitly. In particular:

• authentication and authorization requirements that are required for shared validity MUST be deterministic and locally verifiable;
• proof-of-control mechanisms MUST resist forgery, replay, and unauthorized transfer;
• version negotiation and extension handling MUST avoid silent downgrade where security is affected;
• refusal, fork, and replacement paths MUST be analyzed for abuse and denial-of-service risk;
• compatibility labels SHOULD be clear enough to prevent accidental interoperation across incompatible rule sets;
• distributed state SHOULD be auditable and reproducible enough to detect inconsistent views;
• local variation MUST NOT be allowed to falsely claim compatibility with a rule set it does not satisfy.

The existence of security exceptions does not justify a general permission layer. It justifies only deterministic security rules necessary to preserve the stated Global Invariants.

13. IANA Considerations

This document has no IANA actions.

14. References

14.1. Normative References

• RFC 2119 — Bradner, S., Key words for use in RFCs to Indicate Requirement Levels, BCP 14, RFC 2119.
• RFC 8174 — Leiba, B., Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words, BCP 14, RFC 8174.

14.2. Informative References

• RFC 6709 — Carpenter, B. and B. Aboba, Design Considerations for Protocol Extensions, RFC 6709.
• RFC 7282 — Resnick, P., On Consensus and Humming in the IETF, RFC 7282.

Appendix A. Design Checklist

A design that claims conformance to this document SHOULD be able to answer the following questions clearly:

1. What are the Global Invariants?
2. Which deterministic validation rules preserve those Global Invariants?
3. Which rules in the Initial Specification are strictly necessary for first deployment?
4. How is valid state represented and verified?
5. Is state distributed, replicated, or otherwise independently verifiable?
6. Which future questions are intentionally left outside the common layer?
7. Which future choices can be made by participants without altering the compatibility set they are in?
8. How does a participant adopt a later change?
9. How does a participant refuse a later change without being assigned invalid status?
10. How are compatibility sets labelled or discovered?
11. How does local rejection work when state is invalid or incompatible under the rules a participant runs?
12. What is the fork path?
13. How does a holder prove control without an incumbent recordkeeper?
14. How does a counterparty verify state without a registry?
15. Can participants verify ordinary validity without relying on an incumbent recordkeeper?
16. Do records and coordination artifacts describe adopted reality, or do they attempt to declare unadopted future reality into existence?
17. Has the system minimized the number of decisions embedded in the common layer?
18. Has the system avoided any continuing authority that determines ordinary participant status?
19. Can participants accept or reject counterparties voluntarily?
20. Can the system continue if every incumbent registry disappears?

Author’s Address

1. Lu
   [TBD]