Summary

  • IPv4 transfers in the RIPE NCC region are not simultaneous exchanges. Buyer funds, RIPE Database recognition, RPKI and reverse-DNS control, routing acceptance and commercial cleanup move at different speeds.
  • Escrow is useful because it reduces first-mover risk, but it can hold funds only against defined conditions. It cannot make RIPE NCC approve a request, verify every corporate authority chain, clean routing reputation or adjudicate every post-closing dispute.
  • The strongest release anchor is registry completion: RIPE-807 treats transfer completion as an update to registration records, while the original holder remains responsible until that transfer to the receiving side is completed.
  • Commercial completion is wider than registry recognition. A buyer may still need ROAs, reverse-DNS delegation, routing registry updates, abuse-contact changes, route-reputation cleanup and seller cooperation after the RIPE Database has changed.
  • Banking review, EU sanctions screening, KYC, beneficial-owner checks, correspondent-bank delays and currency controls are settlement timing risks. They matter, but they are only one layer in a larger non-simultaneous exchange.
  • Non-permanent transfers and leasing-like arrangements intensify the problem because responsibility may shift out and back, while payment and operational control may follow private service terms rather than a simple sale.
  • RIPE NCC should not supervise purchase money, choose escrow providers or validate commercial value. Its better role is disciplined evidence: clear authority checks, accurate registration boundaries, visible transfer facts and no confusion between registry recognition and private payment finality.
  • A mature RIPE-region settlement grammar would use staged release, authority evidence, long-stop dates, fault-based refund terms, technical holdbacks, fraud reserves, post-transfer cooperation clauses and documented evidence boundaries.

The closing room has three clocks

In the closing room for a RIPE-region IPv4 transfer, the word "done" does too much work. The buyer's finance team may say the money is ready, subject to the escrow provider's release instruction. The seller may say the transfer agreement has been signed by an authorized director and the request can be submitted. Counsel may say the contractual conditions are mostly satisfied. A broker, if one is involved, may say the commercial spread has closed and the deal should move before another buyer appears. Network engineers ask a different question: when can the receiving network create valid ROAs, control reverse DNS, announce the block without being filtered, clean stale route records and persuade customers that the addresses are usable?

All of them are describing real settlement events. None is enough by itself. Money in escrow is not registry recognition. A signed transfer agreement is not a public RIPE Database update. A RIPE NCC ticket is not payment finality. A changed registry record is not proof that old ROAs have been removed, reverse DNS has moved, reputation has been repaired, or every upstream will accept the route. IPv4 settlement is difficult because these events are related but not simultaneous.

That non-simultaneity is the heart of settlement trust. IPv4 has become a scarce production input for hosting, cloud services, access networks, enterprise migrations, payment systems, security tooling and customer connectivity. The RIPE NCC service region covers Europe, the Middle East and parts of Central Asia, where telecom groups, public bodies, universities, hosting companies, legacy holders and smaller operators sit under different banking rails, company-law regimes and sanctions exposures. A buyer may be ready to wire euros today, yet a correspondent bank may pause the payment tomorrow. A seller may be ready to sign, yet a registry authority question may require fresh company papers. RIPE NCC may complete a registration update, yet the operational handover may still take days.

The transaction-cost question is not whether counterparties are honest in the abstract. It is how the parties can reduce the cost of trusting one another while waiting for several institutions to act in sequence. A bank reviews funds. A company registry or notary helps prove authority. RIPE NCC evaluates a transfer request under applicable policy and procedure. The RIPE Database becomes the public record surface. RPKI, reverse DNS and routing registries shape operational use. Reputation systems, abuse desks and upstream filters test whether the transferred address range is commercially clean. Each layer is necessary, and no single layer controls the others.

Escrow appears because someone must move first, but nobody wants to move entirely first. The buyer fears paying for a transfer that RIPE NCC does not recognize or that the seller cannot deliver technically. The seller fears submitting registry paperwork, exposing internal evidence or handing over operational control without payment assurance. The escrow provider wants a release condition it can verify without becoming an Internet court. The registry wants documentary evidence, not a mandate to supervise commercial settlement. The economic design problem is to choose milestones that let each institution do its narrow job without pretending that narrow job settles the whole bargain.

The cleanest analysis starts by separating three clocks. The payment clock measures when funds are committed, cleared, held, blocked, released or returned. The registry clock measures when RIPE NCC receives the request, reviews documents, applies restrictions, screens against sanctions lists and updates the registration record. The technical clock measures when operational control becomes real enough for the buyer to use the range: ROAs, reverse DNS, routing registry entries, abuse contacts, customer notices, provider filters and reputation remediation. Settlement trust is the discipline of tying money to the right points on those clocks.

Registry completion is the anchor, not the whole settlement

RIPE's current resource-transfer policy gives the market a crucial factual anchor. RIPE-807, published in October 2023, states that transfers must be reflected in the RIPE Database, that transfers can be permanent or non-permanent, that the original holder remains responsible until transfer to the receiving side is completed, and that RIPE NCC completes the transfer by updating registration records. That is not a commercial theory; it is a factual exhibit about the public registry event. The policy tells settlement parties where the strongest externally visible milestone sits.

That milestone matters because private paperwork cannot create registry finality by itself. A buyer may have a purchase agreement, board minutes from the seller, a payment instruction and a letter from a broker. Those documents may be persuasive, even necessary. They are not the RIPE Database. Until the registration record has changed, the market lacks the public state that tells other networks, auditors, banks and later counterparties whom the registry recognizes for the relevant address range. A transfer that never reaches that public state may still produce litigation, but it has not delivered the central registry result the buyer expected.

The anchor should not be misunderstood. Registry completion does not certify that the price was fair, that money was safely received, that the buyer's bank cannot claw back a payment, that old routing history is benign, that a seller's warranty covers every hidden issue, or that no court will later hear a dispute. A registration update is a powerful public event precisely because it is narrow. It says that RIPE NCC has changed the relevant registration record. It does not transform RIPE NCC into a payment supervisor, credit insurer, fraud tribunal or post-closing network integrator.

The distinction is economically important. If a release condition is too early, the buyer carries excessive delivery risk. If it is too late, the seller finances risks that it no longer controls. Registry completion sits in the middle. It is later than mere signature, funding, ticket creation or document submission. It is earlier than full operational comfort. That makes it the natural main-release trigger for many transactions, provided that the agreement deals separately with any technical holdback and post-transfer cooperation.

A typical main-release structure can therefore be simple without being naive. The buyer funds escrow after authority evidence and a signed transfer agreement are in place. The seller submits the request through the appropriate RIPE NCC-facing channel. RIPE NCC reviews the file, applies relevant policy restrictions, requests missing documents and checks sanctions exposure. When the registration record is updated to reflect the receiving side, the escrow provider releases the main tranche. A smaller reserve remains for defined technical tasks that the seller still controls or must cooperate in completing.

That structure reduces the cost of disagreement. The buyer cannot easily claim that the central settlement event did not occur if the public record changed and the agreement defined that event as the main release condition. The seller cannot demand main release merely because the parties signed or RIPE NCC opened a file. The escrow provider does not need to judge routing quality, block reputation or commercial wisdom to release most of the consideration. The public record supplies a narrow, verifiable event around which private money can move.

The danger lies in vague words such as "approval", "completion" or "delivery" when they are not defined. Approval may mean that RIPE NCC has accepted the documents, that a policy issue has been resolved, that a sanctions check did not block the request, or that the registration record has actually changed. Delivery may mean signature, submission, public record movement, routeability, reverse-DNS control or all of them. The settlement contract should not ask a custodian of funds to infer meaning from commercial mood. It should state which evidence releases which tranche.

Escrow can hold funds, not make the ledger speak

Escrow is sometimes treated as a container for trust. That view is too generous. A neutral custodian can hold funds, accept release instructions, verify specified evidence, pause on a dispute notice and return money if a defined condition fails. It cannot make the RIPE NCC approve a transfer. It cannot repair weak authority evidence. It cannot persuade a bank to clear a payment. It cannot create a valid ROA, delegate reverse DNS, clean a blacklist entry or settle a later lawsuit. Escrow is a tool for sequencing performance, not a substitute for the institutions that create the underlying facts.

The limitation is not a defect. It is the reason escrow can work. If the custodian were asked to decide whether the buyer had received full economic value from an address range, it would have to judge registry evidence, corporate law, routing telemetry, RPKI state, reverse-DNS data, customer acceptance, bank risk, abuse history and contractual warranties. That would make the custodian expensive, slow and unpredictable. Good escrow instructions are narrower. They ask the provider to release or hold money when specified evidence appears.

In a RIPE-region IPv4 transfer, the main evidence categories are relatively clear. Identity evidence establishes who the parties are. Authority evidence establishes who can sign and submit for the registered holder or sponsoring relationship. Policy evidence shows that the range is transferable and not blocked by a 24-month restriction, voluntary transfer lock or other policy constraint. Registry evidence shows the status of the RIPE NCC request and the registration update. Payment evidence shows cleared funds and bank acceptance. Technical evidence shows that agreed post-transfer steps have occurred, such as seller withdrawal of old ROAs, buyer creation of new ROAs, reverse-DNS delegation changes and removal of stale routing records controlled by the seller.

Escrow instructions should map those evidence categories to separate release consequences. A small deposit may become non-refundable after the buyer passes a defined funding deadline and the seller has produced initial authority documents. A larger tranche may remain locked until the RIPE Database update is visible or confirmed by RIPE NCC communication. A technical holdback may be released after the seller completes defined transition duties. A fraud reserve may survive for a short period where the chain of authority is unusually old or complex. A refund provision may apply if the registry refuses completion for reasons assigned to the seller's lack of authority. A different remedy may apply if refusal results from the buyer's failure to meet recipient conditions or provide documents.

The custodian should not be asked to hold registry authority. It should not control the seller's RIPE NCC account, pretend to be the registered holder, issue market assurances that go beyond the file, or maintain a private ledger of who "really" owns a range. A private escrow provider that becomes the place where market actors look for resource finality would be drifting into shadow-registry territory. The same is true if a broker claims that its internal closing notice is as good as RIPE Database recognition. Private coordination can help; it cannot replace the public record.

Escrow should also avoid promising technical certainty that no private provider can deliver. A route accepted by several vantage points today may be filtered tomorrow by a network using stricter RPKI validation or stale reputation data. Reverse DNS may look correct in one query path and lag in another. Reputation systems may be private, inconsistent and slow to update. The parties can define measurable tasks, but they cannot outsource all Internet acceptance to the escrow provider. The contract must distinguish tasks the seller controls, tasks the buyer controls, and residual risks that are priced but not conditions to main release.

This modest view of escrow is harder to sell than the comforting version. It does not promise perfect safety. It says, instead, that settlement trust comes from allocating each risk to the party or institution able to reduce it at lowest cost. That is the institutional-economics core of the matter: escrow is valuable when it lowers first-mover risk without taking over jobs it cannot perform.

Buyer payment risk and seller delivery risk are not mirror images

The buyer and seller often describe each other as mirror-image risks. The buyer says it may pay and receive nothing. The seller says it may deliver and receive nothing. Both fears are real, but they are not symmetrical. Money can usually be observed with relative clarity once cleared into escrow. Delivery is layered. A seller may deliver signature, submit documents, answer RIPE NCC questions, enable registry completion, remove old ROAs, update or delete stale route records, delegate reverse DNS and cooperate with customer migration. Each of those is a different form of performance.

Buyer payment risk starts before funds reach the custodian. A buyer may promise to wire but fail internal approval. A bank may reject the payment because the buyer, the seller, the geography, the bank chain or the transaction narrative triggers review. A correspondent bank may hold funds while it asks for source-of-funds evidence, beneficial-owner detail or sanctions comfort. A currency-control rule may require paperwork before money leaves the buyer's jurisdiction. Even after escrow receives funds, release may be challenged if the payment was fraudulent, unauthorized, made from a compromised account or later attacked by an insolvency office.

Seller delivery risk is more complex because it is not one act. The seller may be the registered holder but lack a current director who can sign under company records. The holder may have changed name or merged, requiring fresh evidence before RIPE NCC can accept the file. The range may be inside a 24-month transfer restriction for scarce resources, or under a voluntary transfer lock. Provider Independent space may require a sponsoring relationship for the receiving side if the recipient is not a RIPE NCC member. Legacy resources may be handled on a best-effort basis and require clear proof of legitimate holding. Each fact changes the probability and timing of registry completion.

The two risks also have different time horizons. Payment risk may peak at funding and release. Delivery risk persists through registry recognition and, for some tasks, after it. A seller that has already received most of the purchase price may still need to cooperate in reverse-DNS transition or withdraw old route authority. A buyer that has received the registration update may still need the seller's help to resolve a reputation issue with a network that remembers the prior operator. Conversely, a seller that has completed the registry handover should not remain unpaid because the buyer's new upstream is slow to change filters.

This is why all-or-nothing settlement is inefficient. If the buyer pays only after every technical and reputation issue is resolved, the seller bears risks outside its control. If the seller receives all money on signature or filing, the buyer bears registry and operational risk. Staging payment creates better incentives. It pays the seller for controllable progress and protects the buyer against failures that would defeat the central purpose of the transaction.

A workable structure might release nothing before authority evidence is complete, a modest amount after both sides sign and the buyer funds, most funds after RIPE Database recognition, and a final reserve after defined technical tasks. It may also include fault-based remedies. If RIPE NCC refuses the transfer because the seller cannot prove authority, the buyer should not lose the funded amount. If RIPE NCC refuses because the buyer cannot provide required recipient evidence, the seller should not carry the whole delay cost. If a bank blocks payment because of the buyer's own source-of-funds problem, that is different from a freeze triggered by a sanctions false positive concerning the seller. Settlement trust requires these distinctions before the crisis appears.

The deeper point is that scarce IPv4 changes the bargaining psychology. Because supply is limited, a buyer under pressure may accept weak conditions to secure a block. Because demand is real, a seller may demand early release. The contract should resist that pressure. Scarcity makes disciplined sequencing more important, not less, because the losses from a failed exchange are larger and the temptation to hurry is stronger.

Authority proof is the first settlement asset

Before an IPv4 transfer can be settled safely, the parties need to know who can speak for the registered holder. This sounds like paperwork, but it is the first settlement asset. Without authority proof, escrow is holding money against a promise that may not bind the right legal person. A buyer can fund; a seller can sign; a broker can introduce; none of that helps if the signatory lacks power to deliver the registry result.

RIPE NCC's transfer pages make the authority issue visible. Transfer requests in the service region can only be submitted by the offering LIR or the sponsoring LIR of the offering End User. A transfer agreement must be signed by representatives legally authorized to act for the relevant organization. Recent registration documents from national authorities are required for legal persons; natural persons face identity-document verification through a third party. Required-document guidance also speaks to company directors, authorized persons, legal successors and official documents supporting mergers or acquisitions. Legacy-transfer guidance adds the practical point that, if someone other than the person shown in company papers signs, supporting documents such as a power of attorney may be needed.

For settlement, those details are not administrative scenery. They determine whether funds should be put at risk and whether a release condition is meaningful. A buyer should not accept "the seller signed" without knowing whether the seller is the registered holder, the sponsoring LIR, a successor, a parent company, a subsidiary, an administrator, a liquidator or a service provider with no transfer authority. A seller should not expose its registry file to a buyer whose own authority or funding is uncertain. An escrow provider should not be asked to decide company-law disputes from incomplete papers after money is already at stake.

Old address ranges often carry corporate history. A block may sit under a name used before a merger. A network may have moved inside a group without a clean public record. A university unit may have become a foundation. A hosting business may have sold customers but retained registration. A dissolved entity may still appear in historical data. A legacy holder may never have had the same service relationship as a modern member. These histories are common in a region where networks were built before IPv4 scarcity turned registration into a valuable settlement surface.

The right response is not suspicion for its own sake. It is early evidence. The pre-funding file should show the registered holder, the account or sponsorship route through which the request will be submitted, the legal person signing, the signatory's authority, any name-change or succession documents, and any transfer restriction that could block completion. Where the chain is long, the agreement should state which gaps must be closed before funding and which can be handled as conditions to later release. The buyer should know whether it is paying for a clean current holder or a complex authority story with a higher delay risk.

Fraud risk sits exactly here. A compromised mailbox, an old contact, a forged authorization letter or a fake power of attorney can make a transaction look complete until the true holder appears. Escrow reduces payment exposure only if it refuses to treat thin authority as enough. The custodian need not become a corporate-law specialist, but the release script can require documentary confirmation from counsel, current company registry extracts, notarized authority, registry-facing confirmation or other defined evidence before funds leave.

Authority proof also reduces clawback risk. If a seller later enters insolvency, a receiver or creditor may examine whether the transaction was authorized, fairly documented and completed in the ordinary course. A clean authority record does not immunize the buyer, but it improves the evidentiary posture. Weak authority evidence turns a payment dispute into a title dispute, a registry dispute and a technical dependency all at once. In settlement economics, that is the expensive failure mode.

Banking friction is a settlement delay, not the whole story

The RIPE NCC region is unusually exposed to banking friction because it spans many jurisdictions and economic realities. A Dutch seller, a Gulf buyer, a Central Asian operator, a sanctioned-risk geography, a European bank, a U.S. correspondent rail and a specialist escrow provider can all sit inside one transaction. The money may be legitimate and the transfer valid, yet the payment clock can slow for reasons outside the registry's control.

KYC and sanctions review are real. RIPE NCC's public transfer guidance says that, once supporting documentation has been received, it evaluates the request under applicable policies and procedures and checks against the EU sanctions list; if either side is found to be under sanctions, the transfer will not be approved. Banks have their own duties. They may ask who beneficially owns the buyer, who owns the seller, what the payment is for, why an address range has such value, whether the range has a sanctioned connection, whether any broker fee is being paid, whether funds are borrowed, and whether documents match the names on the registry file.

This layer should not be minimized. A payment that cannot clear cannot settle, even if the registry file is strong. A buyer whose bank will not release funds may hold the seller in limbo. A seller whose receiving bank refuses the payment after release may face another delay. A correspondent bank can freeze or return funds at precisely the moment RIPE NCC recognition is ready. Currency-control rules can require local approvals, invoices, tax certificates or central-bank documents. The escrow provider may have its own jurisdictional limits and may refuse to hold funds connected to certain countries or industries.

But banking friction should not swallow the analysis. Settlement trust in IPv4 is not just cross-border compliance. A fully cleared payment still leaves registry, authority and technical risks. A sanctions clearance does not prove a signer had authority. A bank's comfort with source of funds does not make the address range routeable. A KYC file does not create ROAs or reverse DNS. Compliance is a delay and risk layer, not the whole transaction.

The practical solution is to treat banking review as one clock among several. Before signing, the parties should identify currency, escrow jurisdiction, expected bank chain, required invoices or purchase descriptions, beneficial-owner evidence, sanctions-screening documentation and refund mechanics if the bank rejects funds. The buyer should fund early enough that bank review does not collide with a registry completion deadline. The seller should provide payment-receiving details that match its legal identity. The escrow instructions should say what happens if funds are frozen, returned, partially received or challenged.

Fault allocation matters. If a buyer cannot pass its own bank's review, the seller should not be locked indefinitely. If a seller's sanctions exposure prevents approval or payment, the buyer should not lose the deposit absent a clearly agreed risk allocation. If both sides pass but a correspondent bank delays for reasons neither controls, the agreement may extend deadlines up to a defined long-stop date. If currency controls make release impossible without a local approval, the contract should say which side must obtain it and by when.

Clawback risk is a separate banking problem. Escrow providers often prefer wire transfers because they are harder to reverse than card payments or some electronic methods, but fraud, insolvency and mistaken-payment claims can still arise. A buyer may fund from an account later alleged to be unauthorized. A seller may receive release shortly before insolvency. A lender may claim security over proceeds. The escrow provider's terms will not eliminate these risks. A high-value transfer may need representations about source of funds, authority to pay, absence of insolvency filings, no undisclosed security claim and no pending payment challenge.

This is where transaction-cost economics becomes practical. Every additional document delays closing. Every missing document increases dispute cost. The efficient file is not infinite; it is targeted. It collects the evidence needed to keep the payment clock from derailing the registry clock, while accepting that no private file can remove all residual risk.

Release milestones should be conditional, not theatrical

Many failed closings are caused by ceremonial milestones. The parties celebrate signature. They celebrate escrow funding. They celebrate the opening of a RIPE NCC request. They celebrate an encouraging email. They celebrate a route test. Then a delay appears and the release condition turns out to be unclear. Settlement design should replace ceremony with conditional milestones that have defined consequences.

The first milestone is pre-funding readiness. Before the buyer puts meaningful funds at risk, the seller should have produced enough evidence to show that it can submit the request and has authority to sign. The buyer should have shown enough financial and identity evidence to justify the seller's cooperation. The parties should know whether the resources are subject to a 24-month transfer restriction, a voluntary transfer lock, a sponsorship requirement, a legacy complication or a business-structure update. If any of these is uncertain, the agreement should mark it as a condition, not bury it in optimistic recitals.

The second milestone is funded escrow. Cleared funds create seller confidence and reduce the temptation to hold back cooperation. Funding should not automatically release the seller from all duties. It should trigger the registry-facing step: submission by the offering LIR or sponsoring LIR, delivery of signed transfer agreement, identity evidence and authority documents, and response to RIPE NCC questions. If the buyer funds late, the long-stop date may extend or the seller may gain termination rights. If the seller fails to submit after funding, the buyer should have refund rights and possibly cost recovery.

The third milestone is registry submission and active review. A ticket or request is useful because it starts a measurable period, but it is not settlement finality. The instructions can require status certificates every few business days, disclosure of non-confidential requests for further information, and a duty to respond quickly to RIPE NCC. They can pause the clock if RIPE NCC asks for documents outside either party's immediate control. They can impose consequences if one side goes silent. The point is to prevent review time from becoming hold-up time.

The fourth milestone is approval or record update, depending on how the parties define the release trigger. For most transactions, the safer main trigger is a completed RIPE Database update reflecting the receiving side. If an earlier approval event is used, the agreement should say exactly what remains undone, who controls it, how much money is released, and what happens if the record never changes. Early partial release may be rational if the remaining step is controlled by the buyer, such as signing a required agreement or paying a fee. It is dangerous when the remaining step is the public registry event itself.

The fifth milestone is technical handover. It should be limited to tasks the seller can actually perform or support. Examples include withdrawing or modifying old ROAs under the seller's control, providing information needed for the buyer to create ROAs, updating or deleting stale routing records, changing reverse-DNS delegation where the seller controls the current state, updating abuse contacts, and giving reasonable cooperation with upstream or customer notices. The buyer should not hold a large reserve because its own network team is late or because a third-party blocklist is slow to respond. A smaller holdback with precise tasks is more efficient.

The sixth milestone is a short dispute window. Fraud, authority challenges, payment clawbacks and route-reputation surprises can surface after the public record changes. The answer is not to hold the whole consideration for months. It is to reserve a defined amount for defined claims, with evidence standards and expiry. A reserve that never expires is not escrow; it is a private veto. A release that leaves no remedy for known residual duties is under-protection. The balance lies in limited duration, specific evidence and fault-based allocation.

Conditional milestones also reduce opportunism. A buyer cannot use vague dissatisfaction to delay full release after registry completion. A seller cannot use mere submission to demand payment before the buyer has the public record. Both sides know which clock matters at each stage. The transaction becomes a sequence rather than a battle over adjectives.

RPKI, ROAs and reverse DNS are settlement surfaces

Technical handover is often treated as a post-closing nuisance. In IPv4 settlement, it is a core value layer. A buyer does not pay for a number range as decoration. It pays for a usable recognized position in the Internet's routing and naming systems. Registry recognition is necessary for that position, but operational control must follow.

RPKI is the most visible example. The RIPE NCC describes RPKI as a security framework that helps network operators make more informed and secure routing decisions, with ROAs used for BGP origin validation. In practice, a transferred range can encounter trouble if old ROAs remain, if maxLength values are wrong, if the buyer creates ROAs too late, or if route announcements appear invalid to networks that enforce origin validation. A main payment release should not wait for every network to converge, but the seller's controllable RPKI duties should be written down.

The same applies to reverse DNS. RIPE NCC registers reverse delegations and says the RIPE Database is used as the management database for producing DNS zones. Reverse DNS delegations allow number-to-name mapping under in-addr.arpa for IPv4. For many networks this is not decorative. Mail systems, security tools, hosting customers, abuse desks, enterprise allowlists and operational diagnostics can depend on stable reverse naming. A buyer that receives registry recognition but cannot move reverse DNS may face customer-impacting friction. A seller that has no control over the buyer's nameservers should not be blamed for the buyer's delay. Again, the solution is not a vague promise; it is a task list.

Routing registry records create another handover surface. A transferred prefix may have historical route records tied to an old origin AS, route-set references, maintainer permissions or provider filters. Some of this state may sit in the RIPE Database; some may sit in other routing registries or provider systems. A seller may be able to delete or amend entries it controls. A buyer may need to create new entries and persuade upstream providers to refresh filters. A settlement reserve should distinguish between these duties rather than treating "routeability" as a single condition.

Abuse contacts and operational mailboxes also matter. The receiving side should not inherit a range whose public contact surface still points to the seller, a retired mailbox or an intermediary that will not respond. Conversely, the seller should not remain the public target for abuse reports after registry completion unless a transition period has been agreed. Updating contact surfaces is a low-cost way to reduce post-closing confusion, and it belongs in the technical handover checklist.

Route reputation is more difficult because it is not centrally controlled. An IPv4 range may carry history from spam, malware, bulletproof hosting, VPN services, compromised customers, open proxies or simply a prior operator that generated many complaints. Some reputation systems respond quickly to new stewardship; others are opaque. The seller may know more than the buyer about the history. The buyer may be better placed to remediate after it controls the range. Escrow can support reputation disclosure and a short cooperation period, but it cannot guarantee that every private list will clean the range.

A practical technical holdback should therefore use verbs that map to control: withdraw, create, delegate, update, delete, provide, notify, cooperate. It should avoid impossible promises such as "ensure global acceptance" or "make the range clean". The former depends on thousands of networks; the latter depends on systems that may not disclose their criteria. Settlement trust improves when the technical layer is taken seriously, but only if the conditions are measurable enough to enforce.

The broader lesson is that the technical clock cannot be ignored just because the registry clock has ticked. RIPE Database recognition gives the buyer the public registry position. RPKI, reverse DNS, routing registry updates and reputation cleanup turn that position into operational value. The main release can sit on registry completion; the technical reserve should sit on the few remaining actions that are specific, important and within the seller's reach.

Non-permanent transfers and leasing-like arrangements blur the exit

RIPE-807 recognizes that transfers can be permanent or non-permanent. It also states that, in a temporary transfer, the original holder re-assumes responsibility when the resource is returned. That small policy sentence carries large settlement consequences. A permanent sale has one main direction: the receiving side becomes the recognized holder, and commercial completion follows the transition. A non-permanent transfer, lease-like service or routed-use arrangement has two directions: control moves out, and later it must come back or be reconciled.

The market often uses several labels for this gray zone. Some arrangements are true non-permanent transfers reflected in the RIPE Database for a defined period. Some are service agreements in which the registered holder remains in place while another network uses routed space. Some are commercial leases, sub-allocations, managed-address packages, bring-your-own-IP support deals or hosting agreements that look economically similar but differ in registry treatment. The settlement problem is that money may be paid like rent, registry recognition may or may not move, and operational control may sit with the customer, provider or holder at different moments.

This is not a moral argument about leasing. It is a risk-allocation argument. Temporary use can be economically useful. Operators may need address capacity for migrations, events, cloud deployments, testing, customer growth or a phased transition to IPv6. Holders may have spare capacity but not want to dispose of it permanently. A short-term arrangement can move a scarce input toward current use. The trouble begins when the parties are unclear about which layer has moved.

If a non-permanent transfer is reflected in the registry, escrow should address both start and return. The receiving side pays for use after the registry update, but the original holder needs confidence that the range will be returned at the agreed time, that technical state will not be left polluted, and that abuse or reputation damage will not be dumped back without remedy. The receiving side needs confidence that it will get registry recognition for the period, usable technical control, and no early recall except under defined default or legal events. The payment release conditions should therefore include commencement and reversion milestones.

If the arrangement is lease-like without a registry transfer, the settlement logic changes. The buyer is not buying registry recognition. It is paying for service, routing support or delegated operational use. Escrow cannot use RIPE Database holder change as the main trigger because there may be none. The release condition must instead depend on service activation: route authorization, reverse-DNS delegation, agreed contact surfaces, upstream acceptance, usable capacity and documented responsibility for abuse handling. The party paying should understand that it is buying a contractual service, not public holder recognition.

Ambiguity creates institutional risk for RIPE NCC. If private contracts make control look like ownership while the registry record says something else, disputes may later arrive at the registry disguised as ordinary updates. A lessee may claim practical control. A holder may claim continuing authority. A broker may describe a service deal as a transfer. An abuse desk may not know whom to contact. A bank may treat recurring rent as purchase consideration. The registry cannot police every private service contract, but it can insist that its record not be misrepresented.

Settlement documents should therefore state the boundary. Is the arrangement a permanent transfer, a non-permanent transfer reflected in the RIPE Database, or a service arrangement with no holder change? Who remains responsible under RIPE policy during the term? Who creates ROAs? Who controls reverse DNS? Who receives abuse reports? What happens on sanctions change, non-payment, route abuse, insolvency, or failure to return? Which evidence releases payment at start, during the term and at exit?

Non-permanent arrangements make escrow more valuable but less simple. A one-time closing becomes a term structure. Funds may be released monthly, held as a damage reserve, or tied to return of clean technical state. That is a different bargain from a sale. The market should say so plainly.

Fraud, disputes and clawbacks travel through time

Settlement risk does not end when the RIPE Database changes. Some risks arrive after the apparent close. A payment may be challenged. A company may enter insolvency. A former director may claim the signer lacked authority. A creditor may allege that proceeds should have been paid elsewhere. A sanctioned-beneficial-owner issue may be discovered late. A buyer may find that the address range is stuck on private filtering lists. A seller may discover that the buyer's use has damaged reputation before a temporary return. These events travel through time, crossing the line that ordinary closing language treats as final.

Fraud risk is the starkest case. A fraudulent transfer of a scarce address range can involve forged documents, compromised registry credentials, false company papers, hijacked mailboxes, dishonest insiders or a chain of private introductions that conceal the true holder. Escrow does not cure fraud if it releases before authority is tested. Nor can it guarantee safety if the forged file is sophisticated. What it can do is create a delay between funding and release, require independent authority evidence, preserve documents, and define a short fraud reserve where the history is unusually complex.

Clawback risk is less dramatic but common in high-value transactions. If the seller receives payment shortly before insolvency, an insolvency office may examine whether the transaction was at undervalue, preferential, unauthorized or outside ordinary course. If the buyer funded from borrowed money, a lender may have conditions that affect release. If payment came from an account later alleged to be compromised, the escrow provider may face competing claims. The registry update will not answer these money questions. The contract must assign them through representations, indemnities, reserves and evidence duties.

Dispute notices are another pressure point. Many escrow agreements allow a party to freeze release by serving a dispute notice. That can be necessary, but it can also become a veto. A buyer may allege a vague technical defect to delay payment after registry completion. A seller may allege buyer breach to capture a deposit before the registry has acted. The solution is not to eliminate dispute rights. It is to define what kind of notice pauses which tranche, what evidence must accompany it, how long the pause lasts, and when the dispute must move to court, arbitration or mutual instruction.

The transaction should also distinguish pre-closing and post-closing claims. Before registry completion, a failure of authority or transferability may justify a full refund. After registry completion, a technical defect controlled by the seller may justify use of a holdback, not reversal of the whole payment. A route-reputation issue disclosed before closing may be priced into the deal; an undisclosed issue known to the seller may trigger warranty claims. A buyer's own misuse after closing should not become a reason to hold seller funds. Time matters because control changes over time.

Temporary arrangements need even sharper timing rules. If the receiving side uses a range for six months and damages reputation, the original holder's loss may appear only when the range returns. A reserve may need to survive beyond the use period. If the original holder recalls early without cause, the receiving side may lose customers. A reserve or service-credit mechanism may protect it. Non-permanent settlement is not just a smaller sale. It is a continuing risk relationship.

Good settlement design therefore includes a dispute map: fraud, authority failure, sanctions block, payment failure, registry refusal, technical non-cooperation, reputation breach, return failure and force majeure should not all trigger the same remedy. They should trigger different holds, refunds, releases, reserves or claims according to fault and control. This is more drafting work at the start, but less destruction at the end.

RIPE NCC should keep the evidence boundary clear

The temptation to ask RIPE NCC to solve settlement risk is understandable. It is the regional registry. Its database update is the central public event. Its transfer pages require documents, authority evidence and sanctions screening. Its policy distinguishes permanent and non-permanent transfers. Its published statistics make approved changes visible. If the registry is so central, why not ask it to supervise the payment side too?

The answer is institutional specialization. RIPE NCC is not a bank, escrow provider, price regulator, credit insurer, fraud court or broker licensing body. Its role is to maintain accurate registration records under community-developed policy and its own procedures. It can check that the request is submitted through the right channel, that required documents are present, that signatories have apparent authority under supplied evidence, that transfer restrictions do not block the request, that sanctions screening does not prohibit approval, and that the registration record is updated when conditions are satisfied. That is already a heavy responsibility.

If RIPE NCC were to supervise purchase money, it would inherit risks it cannot efficiently control. It would have to judge whether funds are good, whether escrow terms are fair, whether a holdback is appropriate, whether price reflects hidden reputation, whether a bank delay is excusable, whether a buyer's refund demand is tactical, whether a seller's technical performance is adequate, and whether a clawback threat should block registry recognition. These are commercial and legal questions, not registry-record questions. Loading them onto the registry would make transfers slower, more politicized and less predictable.

The better boundary is disciplined evidence without payment supervision. RIPE NCC should be clear about what its acceptance, approval and record update mean, and what they do not mean. A registry update means the registration record has been changed. It does not mean payment has cleared, escrow should release all reserves, technical handover is complete, reputation is clean, or private warranties are true. Conversely, private payment completion does not mean the registry record should move without the required evidence. Each side of the boundary protects the other.

This boundary also protects smaller operators. If registry transfer became tied to complex payment supervision, only large buyers with sophisticated counsel and favored escrow providers would manage the process easily. Smaller networks would face higher transaction costs and longer uncertainty. A clear registry evidence standard, separate from private settlement terms, lets the market design payment arrangements while keeping the public record reliable.

There is still room for RIPE NCC to improve settlement trust without holding money. It can keep transfer guidance precise about required documents, authority expectations, sanctions treatment, transfer restrictions, voluntary locks and non-permanent status. It can publish timely transfer statistics with enough detail to let the market see registry-recognized movement. It can avoid language that might let private actors market a mere request as registry completion. It can make clear that reverse DNS, RPKI and database-maintenance steps are operational surfaces the parties should plan for, while not promising commercial quality.

The registry can also keep confidentiality boundaries clear. During review, one side may want proof that the other side is responding to RIPE NCC. RIPE NCC cannot turn private files into a shared data room. Private contracts should handle that through status certifications and cooperation duties. The registry should not become the messenger for private distrust. Its evidence boundary is strongest when it is predictable: required documents in, policy and procedure applied, public record changed if the request succeeds, published transfer facts visible afterward.

This is not an argument for a passive registry. It is an argument for a bounded one. Settlement trust requires RIPE NCC to be reliable in its own lane and resistant to pressure to occupy every other lane.

A settlement grammar for the RIPE region

The RIPE-region market needs a more precise settlement grammar because the old language of closing is too blunt for scarce IPv4. A good grammar would name each stage: authority readiness, funded escrow, registry submission, active review, registry completion, technical handover, reputation remediation, reserve expiry and, for non-permanent arrangements, return. It would state which evidence proves each stage and which money consequence follows.

The first rule is that authority comes before capital is put at serious risk. The seller's registered position, sponsorship route, company papers, signatory authority and any succession history should be collected early. If the file depends on a merger, acquisition, name change, dissolved entity or legacy status, the buyer should know that before funding. If a voluntary transfer lock or 24-month restriction could apply, it should be checked before the parties behave as if closing is routine. A discount is not a substitute for authority; it is only compensation for priced uncertainty.

The second rule is that escrow funding should trigger obligations, not relief. Once the buyer funds, the seller must submit and cooperate. Once the seller submits, the buyer must respond to recipient-side requirements and keep funds available. Both sides should provide status updates without demanding that RIPE NCC disclose confidential details. Long-stop dates should distinguish delay caused by the buyer, delay caused by the seller, delay caused by banking review, and delay caused by registry processing. One deadline cannot fairly handle all causes.

The third rule is that the main release should normally sit on registry completion, not on signature, funding, filing or mood. The public registration update is the strongest settlement anchor because it is the event the rest of the market can see. If the parties release earlier, they should say they are taking that risk and explain what remains undone. If they release later, they should define the residual tasks and keep the holdback proportionate. The point is not rigidity; it is awareness.

The fourth rule is that technical handover should be separated from commercial finality. ROA transition, reverse-DNS delegation, routing registry cleanup, abuse-contact changes and seller cooperation are important enough to document. They are not always important enough to block the main price. A defined holdback, short deadline and measurable task list will usually be better than a vague condition requiring the buyer to be satisfied with routeability. Satisfaction is a poor release standard when scarce resources and cash pressure are involved.

The fifth rule is that reputation should be disclosed, priced and reserved only where evidence is strong. An IPv4 range's past use can matter enormously, especially for mail, hosting, payments and security platforms. Yet reputation is not a single public register. The seller should disclose known material issues. The buyer should perform its own checks. The agreement can include warranties and cooperation duties. Escrow should not become a global reputation judge.

The sixth rule is that non-permanent transfers and lease-like services need their own terms. If RIPE Database recognition moves temporarily, the arrangement must address both outward transfer and return. If recognition does not move, the buyer is paying for service and operational use, not registry holder status. Payment conditions should reflect that distinction. So should abuse, ROA, reverse-DNS and return duties. Ambiguity is expensive because it lets each side imagine a different bargain.

The final rule is that RIPE NCC's boundary should be respected. The registry should not supervise payment, choose winners among escrow providers, validate prices or promise operational cleanliness. It should maintain clear evidence requirements and accurate public records. Private parties should build settlement structures around that public record without confusing it with total commercial completion. In institutional terms, the market works best when each layer does the job it can verify.

IPv4 scarcity will not disappear because IPv6 exists. The transition remains uneven, and many networks still need IPv4 capacity to serve customers, maintain legacy systems, interconnect with older infrastructure or avoid dependence on larger providers. That means transfers, non-permanent arrangements and leasing-like services will continue to carry real economic value. The more valuable the resource, the more damaging a failed settlement becomes.

Escrow is not a cure for scarcity. It is a way to move through scarcity without making one side trust too much too soon. The RIPE-region market does not need a registry that becomes a payment supervisor, nor a private escrow layer that becomes a hidden registry. It needs a disciplined sequence: prove authority, clear funds, submit properly, wait for registry recognition, release most money on the public record, finish technical handover, keep a bounded reserve for the few risks that truly remain, and let each institution stop at the edge of its evidence.

That may sound prosaic compared with debates about IPv4 prices, broker conduct or global Internet governance. It is also where trust is made or lost. A market for scarce network identifiers depends not only on who wants addresses, but on whether payment, recognition and operational control can be made to converge without pretending they are the same event. Settlement trust is the quiet infrastructure that lets that convergence happen.