What causes IPv4 deals to stall after the first agreement

IPv4 deals usually stall after the first agreement because agreeing on price is only the commercial beginning—not operational completion.

A buyer and seller may agree on a block and price within hours, but the transaction can still be delayed by unclear ownership, incomplete documents, mismatched Regional Internet Registry requirements, recipient eligibility, reputation concerns, payment conditions, or missing routing authorization.

The most common causes are:

• The seller’s authority over the IPv4 block has not been fully verified.
• The buyer is not ready to receive resources under the relevant RIR’s rules.
• Legal names, registry records, and transaction documents do not match.
• The parties disagree about escrow, fees, taxes, or payment-release conditions.
• Address reputation problems appear during due diligence.
• A transfer restriction or policy issue is discovered late.
• No one owns the process from commercial agreement through registry completion.
• Routing, RPKI, WHOIS, geolocation, and handover requirements were not defined.

Successful IPv4 transactions require a structured execution process connecting commercial agreement, due diligence, registry approval, settlement, and operational handover.

Why an agreement is not the same as an executable IPv4 deal

When two parties agree on an IPv4 price, they have usually settled only a few commercial points:

• The address block
• The price per address or total consideration
• Whether the transaction is a purchase or lease
• A general target date

That agreement is important, but it does not establish that the resource can be transferred, routed, leased, or used as intended.

IPv4 addresses are administered through the global Regional Internet Registry system. Transfers are governed by the applicable policies and processes of ARIN, RIPE NCC, APNIC, AFRINIC, or LACNIC. The relevant registry must be able to recognize the parties, validate the resource, and record the transaction where a registry transfer is required.

Operational usability also depends on more than registration. A block may require a Letter of Authority, a valid Route Origin Authorization, correct WHOIS information, reverse DNS coordination, geolocation updates, and a clean handover between networks.

This gap between “we agree” and “the block is usable” is where IPv4 transactions commonly stall.

i.LEASE was built around execution as well as market access. The marketplace supports IPv4 buying, selling, leasing, registry coordination, settlement, and lifecycle workflows rather than treating the initial match as the end of the transaction.

1. The seller’s authority is unclear

One of the earliest—and most serious—causes of delay is uncertainty over whether the seller has the authority to transfer or lease the IPv4 block.

The organization offering the addresses may use a different legal name from the organization shown in the registry. The person negotiating the transaction may not have documented signing authority. Inherited or legacy resources may have an incomplete organizational history. Corporate mergers and name changes may not have been reflected in registry records.

Questions that must be resolved include:

• Which legal entity holds the resource?
• Does that entity still exist?
• Does the registry record match its current name?
• Is the person signing authorized to represent it?
• Is the block subject to another agreement?
• Has the resource already been leased, pledged, or offered elsewhere?
• Can the seller provide the required corporate and registry documents?

A price agreement reached before these questions are answered may create the appearance of progress without producing an executable transaction.

How to prevent this delay

Seller verification should begin before—or at least alongside—commercial negotiation. The transaction workflow should validate registry records, corporate identity, signing authority, and the resource’s chain of control.

The seller should also disclose any active routing arrangements, leases, liens, disputes, or third-party rights affecting the block.

2. The buyer is not ready under RIR policy

A buyer may be commercially ready but not registry-ready.

Each RIR operates under its own community-developed policies and procedures. Requirements can vary based on the registry, the type of transfer, the organizations involved, the resource’s history, and whether the transaction is intra-regional or inter-RIR.

For example:

• ARIN’s Number Resource Policy Manual contains the policies governing transfers involving ARIN-administered resources.
• RIPE Resource Transfer Policies define the conditions applicable to transfers in the RIPE NCC system.
• APNIC’s resource policies cover transfers within its service region and compatible inter-RIR transfers.
• LACNIC’s transfer process requires the participating organizations to satisfy defined conditions.

A buyer may need an active registry account, completed organizational verification, appropriate agreements, fee payments, or evidence required under the applicable policy.

If these steps begin only after the commercial agreement, the deal may pause while the buyer creates accounts, submits documents, corrects corporate information, or responds to registry questions.

How to prevent this delay

Before finalizing the transaction, confirm:

• The receiving organization’s RIR account is active.
• Its legal information is current.
• Required agreements and fees have been completed.
• The proposed transfer path is allowed.
• Any applicable recipient qualification has been addressed.
• Both RIRs support the transaction if it is inter-regional.

RIR readiness should be treated as a closing condition, not a post-agreement administrative task.

3. The parties selected the wrong transfer path

IPv4 resources can have different registration histories and policy conditions. A block may be legacy space, provider-aggregatable space, provider-independent space, or part of a larger allocation. It may also have been transferred previously.

The parties can lose time if they assume a transaction qualifies for a particular process without checking:

• The block’s current RIR
• The registered resource holder
• The minimum transferable prefix size
• Any applicable holding period
• Whether a partial block can be transferred
• Whether the receiving RIR is compatible
• Whether the resource must be divided before transfer
• Whether outstanding registry issues must be resolved first

A deal involving the wrong legal entity or transfer category may need to be restructured after negotiation has already finished.

How to prevent this delay

Build a transfer-path assessment into pre-transaction due diligence. It should identify the source registry, destination registry, policy route, documentation requirements, known restrictions, and expected handoffs.

4. Corporate and registry records do not match

Small discrepancies can cause large delays.

A company may trade under one name while its certificate of incorporation, registry account, bank account, and contract use different versions of that name. Its registered address may be outdated. A merger may have occurred without the resource records being updated. Authorized contacts may have left the business.

Common mismatches include:

• Legal name versus trading name
• Old versus current registered address
• Parent company versus subsidiary
• Seller name versus registry holder
• Contract signatory versus authorized corporate representative
• Receiving entity versus paying entity
• Registry account email versus current company domain

These inconsistencies can trigger additional reviews by the registry, escrow provider, financial institution, or legal teams.

How to prevent this delay

Create a single transaction identity record for each party. Confirm that the same legal names and supporting details appear consistently across:

• The purchase or lease agreement
• Registry records
• Corporate documents
• Escrow instructions
• Invoices
• Bank information
• Transfer requests
• Authorization documents

Where different entities must participate, their roles should be explicitly documented.

5. Due diligence begins too late

Some IPv4 deals stall because technical and legal due diligence starts only after the parties agree on price.

At that point, the buyer may discover:

• Reputation or blocklist concerns
• Unexpected route announcements
• Incorrect or stale registry records
• Conflicting origin AS information
• Active downstream assignments
• Previous abuse activity
• A fragmented or disputed ownership history
• Existing leases that have not ended
• Geolocation inconsistent with the intended deployment

Not every issue makes a block unusable, but each issue may require investigation, remediation, a change in price, or a different closing structure.

How to prevent this delay

Due diligence should be staged.

A preliminary screen can take place before the offer. Full verification can then be completed before funds become releasable. The parties should also agree on what constitutes an acceptable result.

The i.LEASE marketplace is designed around pre-vetted listings and transaction safeguards. Its current marketplace framework includes reputation screening, ownership-continuity checks, routing legitimacy validation, RPKI controls, and escrow protection.

6. Address reputation changes the buyer’s risk assessment

An IPv4 block’s operational value depends partly on how third-party networks and security systems perceive it.

If a block is associated with spam, malware, proxy abuse, fraud, scanning, or other unwanted activity, the buyer may face:

• Rejected email
• Additional CAPTCHAs
• Blocked customer traffic
• Incorrect fraud scores
• Restricted access to online platforms
• Higher support costs
• Delayed deployment

A buyer may pause a deal if reputation results differ from what was expected. Sellers may dispute the relevance or timing of a listing, and both parties may disagree over who must complete remediation.

How to prevent this delay

The agreement should define:

• Which reputation sources will be checked
• When the checks occur
• What findings are considered material
• Whether remediation is required before closing
• Who is responsible for remediation
• Whether the buyer may reject or reprice the block
• How post-transfer reputation issues will be handled

A block being absent from one public list does not prove universal acceptance. Reputation assessment should use multiple sources and combine automated checks with operational judgment.

7. Payment and escrow terms remain unresolved

“We agree on the price” does not necessarily mean “we agree on settlement.”

Deals often slow down when the parties have not settled:

• Who selects and pays for escrow
• Which currency will be used
• Whether bank charges are deducted
• How taxes or withholding are handled
• What evidence triggers the release of funds
• Whether payment is tied to registry approval or operational handover
• What happens if the registry rejects or delays the transfer
• How long either party may wait before terminating
• Whether funds are released in one payment or stages

Sellers may want payment before surrendering control. Buyers may want the registry transfer completed before releasing payment. A poorly defined sequence leaves both sides exposed.

How to prevent this delay

The closing instructions should specify a clear delivery-versus-payment sequence.

For example:

1. The parties complete verification and sign the transaction documents.

2. The buyer deposits cleared funds into escrow.

3. The seller initiates the agreed registry process.

4. The registry confirms completion.

5. Required operational deliverables are provided.

6. The parties confirm that the release conditions have been met.

7. Escrow releases the funds.

The precise sequence should reflect the transaction and the applicable registry process. No party should have to infer the release conditions after funds are committed.

8. The Letter of Authority is incomplete or delayed

In a lease or pre-transfer routing arrangement, the network operator may require a Letter of Authority before announcing the prefix.

An LOA can fail operational review if it contains:

• The wrong prefix
• An incorrect ASN
• A legal entity that does not match the resource holder
• No clear authorization period
• An unauthorized signature
• Missing contact information
• Language that does not authorize the intended activity

A commercial lease can therefore be signed while the customer remains unable to route the addresses.

How to prevent this delay

Define the LOA format and required information before signing. Verify the exact prefix, originating ASN, holder identity, authorized network, effective date, and termination conditions.

Where possible, use a controlled workflow that generates authorization from verified transaction data rather than creating each LOA manually.

9. RPKI and routing responsibilities are not assigned

Even after the registry and payment steps are progressing, deployment can stall because no one knows who must authorize the route.

A Route Origin Authorization allows an address-space holder to state which autonomous system may originate a prefix. The current technical profile is defined in IETF RFC 9582.

Problems arise when:

• No ROA exists.
• The ROA names the previous ASN.
• The permitted maximum prefix length is unsuitable.
• The old authorization is removed too early.
• The new authorization is created too late.
• The seller, buyer, registry contact, and network operator each assume someone else owns the task.

A completed commercial transaction does not guarantee that the prefix will be globally accepted when announced.

How to prevent this delay

Create a routing handover plan that specifies:

• The intended origin ASN
• Required prefix lengths
• Who creates or modifies the ROA
• When the new ROA becomes visible
• When the old route is withdrawn
• How route validity and propagation will be checked
• Who can authorize emergency changes

RPKI, BGP, LOA, and registry steps should form a coordinated sequence.

10. Nobody owns the end-to-end transaction

A fragmented process is one of the most common underlying causes of delay.

The broker may believe its role ended when the parties agreed on price. The lawyers may focus only on the contract. The registry teams may wait for correct submissions. The network engineers may not be involved until the planned deployment date. Finance may not understand the escrow conditions.

Every participant completes a portion of the work, but nobody controls the full dependency chain.

How to prevent this delay

Assign one transaction owner responsible for maintaining:

• The parties and authorized contacts
• The agreed block and commercial terms
• Due-diligence status
• Required documents
• RIR readiness
• Contract status
• Escrow funding
• Transfer submission
• Registry questions
• ROA and routing actions
• Operational handover
• Final settlement

A shared closing checklist and clear deadlines turn ad hoc follow-up into an executable workflow.

Where IPv4 transactions commonly stall

Transaction stage	Frequent cause of delay	Preventive control
Initial verification	Seller does not match the registry holder	Verify identity, authority, and resource records
Due diligence	Reputation, routing, or chain-of-control issues	Screen the block before final commitment
Contracting	Legal entity or delivery terms are unclear	Use consistent identities and defined conditions
RIR preparation	Buyer account or qualification is incomplete	Confirm recipient readiness early
Escrow	Release conditions are disputed	Agree on settlement instructions before funding
Transfer	Incorrect documents or policy route	Build an RIR-specific transfer plan
Routing	Missing LOA or invalid ROA	Prepare authorization and routing in advance
Handover	WHOIS, rDNS, or geolocation is unfinished	Include operational delivery requirements
Completion	No one confirms all conditions	Use a named transaction owner and checklist

How i.LEASE helps move IPv4 deals from agreement to execution

i.LEASE is a global marketplace for IPv4 buying, selling, and leasing. Its model connects discovery and commercial matching with the operational steps required to make address space usable.

The platform’s current transaction framework includes:

• Pre-vetted marketplace listings
• Resource and ownership verification
• Reputation screening
• Structured auctions and listings
• Escrow-based transaction protection
• RIR-aligned transfer coordination
• Automated LOA support
• RPKI and routing support
• Lifecycle workflows after the initial agreement

This matters because an IPv4 deal is successful only when the agreed outcome has been delivered. For a purchase, that generally means the approved transfer and settlement have occurred. For a lease, it means the customer has the documented authority and technical capability to deploy the block under the agreed terms.

Organizations can explore the i.LEASE marketplace or create an account to begin sourcing or monetizing IPv4 resources.

IPv4 pre-agreement checklist

Before agreeing on price, buyers and sellers should confirm:

• The exact IPv4 prefix and block size
• The current RIR
• The registered resource holder
• The seller’s authority
• Whether the transaction is a sale or lease
• The intended receiving entity
• Whether the transfer path is permitted
• Buyer and seller registry readiness
• Preliminary reputation results
• Current route and ROA status
• Any active lease or third-party use
• The proposed escrow structure
• Who will pay registry, escrow, and banking fees
• The target deployment and closing dates
• The person responsible for execution

IPv4 post-agreement checklist

After commercial agreement, the transaction owner should track:

• Signed term sheet or agreement
• Verified corporate documents
• Confirmed registry accounts
• Full resource due diligence
• Final reputation review
• Escrow instructions and funding
• Registry submission
• Responses to RIR requests
• Transfer approval
• LOA delivery where applicable
• ROA creation or modification
• BGP announcement and validation
• WHOIS and contact updates
• Reverse DNS delegation
• Geolocation correction
• Settlement confirmation
• Archived closing records

Final takeaway

IPv4 deals do not usually stall because the buyer and seller cannot agree on a number. They stall because the parties treat price agreement as the transaction’s finish line.

In reality, the agreement is only the point at which execution begins.

Ownership, corporate identity, RIR policy, recipient readiness, reputation, escrow, routing authorization, and operational handover must all align. If those workstreams are addressed sequentially and informally, delays are likely. If they are verified early and managed through a structured workflow, the transaction becomes more predictable.

That is the difference between an IPv4 marketplace that merely introduces parties and one designed to support execution.

Visit i.LEASE to explore verified IPv4 sourcing, leasing, selling, and transaction workflows.

Frequent Asked Questions