In this article
A domain transaction looks deceptively simple on paper: buyer pays, seller pushes the auth code, registrar accepts the transfer, and proceeds flow out. In practice, the gap between "the agreement was signed" and "the domain is sitting in the buyer's account" can stretch from a few days to several weeks — and when that gap creates real commercial damage, a dispute is almost inevitable.
Late-transfer disputes are among the most common and most poorly documented problems in the domain brokerage market. They are also among the most avoidable, if the parties and their advisors understand exactly what causes the delay, who bears the contractual exposure, and how to structure a clean settlement before the situation escalates to arbitration or litigation. This article walks through each of those questions in order.
Why domain transfers run late: the full taxonomy of causes
Before you can assign responsibility or calculate damage, you need to understand which category of delay you are actually dealing with. They are not equally excusable, and they do not carry the same legal weight.
The ICANN 60-day lock
ICANN's 60-day transfer rule is the policy that stops a generic top-level domain such as a .com, .net, or .org from being transferred to a different registrar for 60 days after one of three events: a fresh registration, a previous inter-registrar transfer, or a change to the registrant contact.
This lock is absolute for the registration and prior-transfer scenarios — no registrar can override it, and no exceptions exist regardless of circumstances. When a buyer's counsel, settlement agent, or escrow officer has not confirmed which scenario is in play before closing, the shock of a 60-day wait is entirely self-inflicted. The responsible professional move is to check the WHOIS record and registration date before drafting the transfer timeline into the purchase agreement.
The 60-day transfer lock after a registrant change is an ICANN security measure designed to prevent domain hijacking. When registrant information changes, there is a risk that the change could be unauthorized or fraudulent. The lock period gives the previous registrant time to detect and report any unauthorized changes before a domain can be transferred away.
Critically, for the Change of Registrant lock, many registrars let you opt out of the 60-day transfer lock when you update the registrant, so choosing that option if a transfer is planned soon is essential. Failing to exercise that opt-out — when it was available — is a procedural error attributable to whoever controlled the registrant-change workflow.
The registrar-lock (clientTransferProhibited)
Separate from the ICANN policy lock is the registrar's own security lock. Two distinct lock mechanisms protect domains: the registrar lock you can toggle manually, and the ICANN-mandated 60-day lock that cannot be bypassed under most circumstances. The registrar lock — sometimes visible in WHOIS as clientTransferProhibited — must be removed by the seller before the receiving registrar can accept the transfer. Forgetting this step, or doing it in the wrong sequence, can add several business days to a closing.
Auth code delays and verification bottlenecks
Once the lock is cleared, the seller generates an auth code (also called an EPP code or transfer authorization code) and sends it to the buyer or escrow service. Both parties must fulfill their respective responsibilities — the seller providing the necessary authorization codes for the transfer and the buyer making timely payments as agreed. If either side stalls on their obligation, the timeline slips.
Auth code issues are a common source of disputes because they are ambiguous: was the code sent late, sent to the wrong email, delivered and lost in spam filters, or withheld deliberately? The answer matters enormously for damage attribution.
Receiving-registrar processing time
Even after the auth code is submitted, most registrars run an internal compliance check and notify the gaining-registrar contact to confirm the transfer. The industry standard window for completion runs three to seven business days from authorization. The transaction process takes three to seven business days: buyer payment → seller transfer → buyer verification → payment release. Delays inside this window are generally neutral — neither party caused them — but they can still produce commercial damage if the buyer was expecting to launch a website, redirect traffic, or execute a downstream deal.
Inspection period and acceptance delays
The inspection period — typically three to seven days — is the time the buyer has to verify the domain was transferred correctly, functions properly, and meets agreed-upon specifications. During this period, the buyer can reject the domain if issues are found. If the buyer doesn't reject or accept, Escrow.com automatically releases payment after WHOIS confirms successful transfer. A buyer who drags their feet on confirming receipt can create a secondary dispute with the seller, who is waiting on payment release.
Reading the purchase agreement: what it should say, and what it usually says
Payment and domain transfer timing must be clearly defined and may involve a registrar or third-party escrow. This is what the standard guidance says. In practice, a significant number of domain purchase agreements fail to specify:
- A hard transfer deadline (not just "promptly" or "within a reasonable time")
- The consequence of missing that deadline — whether it triggers a price adjustment, a refund right, or a damages claim
- Which party bears the cost of delay caused by ICANN lock scenarios, especially when those scenarios were knowable at signing
- How the settlement is disbursed once a dispute is resolved, and who receives what share
Due to the unique and specific nature of internet domain names, the parties agree that in the event a breach of the agreement results in a failed attempt to transfer control of the purchase object from seller to buyer, the aggrieved party shall have the right to demand specific performance in lieu of monetary damages. This language — drawn from a widely used domain marketplace agreement — reflects a real practical truth: a domain's value is so specific that forcing the transfer is often more valuable than a cash award. But when the delay is partial rather than a complete failure, specific performance does not fully address the buyer's loss.
A well-drafted agreement will consider a clause specifying mediation, arbitration, or jurisdiction for legal disputes. Without that clause, you are left deciding forum after the relationship has already soured.
Calculating the loss: what damages are actually on the table
Dispute resolution in domain transactions routinely founders on the question of damages because the parties start with incompatible theories. Here is how to think about it rigorously.
Direct economic loss
The cleanest head of damage is identifiable revenue that was contractually committed and demonstrably lost because the domain did not transfer on time. Examples:
- A buyer who had a signed advertising deal contingent on launching the site on a specific date, which was missed entirely because the domain sat locked for six additional weeks
- A seller whose downstream transaction (for example, a trademark licensing agreement) required evidence of domain ownership by a specified date and fell through when that evidence could not be produced
These losses are real but require contemporaneous documentation. An email thread showing the commercial deadline is worth far more in negotiation than a retroactive declaration that "we lost business."
Carrying costs
If the transfer was supposed to close in, say, Week 2 but actually closed in Week 8, the buyer may have been paying parking or forwarding fees, maintaining placeholder infrastructure, or carrying the cost of a substitute domain. These are quantifiable and typically uncontested.
Interest and opportunity cost
Some domain purchase agreements include an interest provision for late transfer, similar to late-payment clauses in real estate. Even where the agreement is silent, a delayed transfer that involved payment being tendered on time — meaning the buyer performed their obligation — is analogous to a deposit sitting idle. Presenting an interest calculation on the withheld value, at a defensible commercial rate, is a standard opening position.
Consequential damages — the hard problem
Consequential or special damages — lost profits, brand value deterioration, competitive harm from a competitor occupying the domain during the gap — are the most contentious category. Essential components of a domain sale agreement include the identity of the parties, purchase price, warranties, and transfer process. Due diligence, escrow services, and dispute resolution clauses can help ensure legal protection and reduce risk. If there is no consequential-damages clause, courts and arbitrators apply varying standards to whether such claims survive at all. Parties who want to preserve the right to claim consequential damages — or to exclude that exposure — must address it before closing, not after.
Concrete scenarios and how they resolve
Scenario 1: Seller updates WHOIS, does not opt out of the lock, transfer is delayed 60 days — $80,000 USD (~AUD $124,000) deal
Buyer paid into escrow on Day 1. Seller updated their registrant email three days later for unrelated administrative reasons and did not opt out of the resulting 60-day lock. Transfer is blocked.
Who caused it: The seller, through an avoidable procedural failure.
Reasonable resolution framework: The seller cannot transfer the asset they agreed to deliver on the contracted timeline. The buyer is entitled to: (a) retain all rights under the purchase agreement without re-negotiation, and (b) present a documented claim for direct losses attributable to the delay. Because specific performance remains available — the domain will transfer when the lock expires — the dispute reduces to quantifying damage, not rescinding the deal. A broker or settlement agent facilitating this resolution will typically document a price adjustment credit equal to the demonstrated loss, applied against the seller's proceeds at disbursement.
Scenario 2: Auth code was sent to the wrong email — $220,000 USD (~AUD $340,000) deal
Seller sent the auth code to an old email address the buyer had provided at the start of negotiations but had since updated. The buyer did not receive the code. Six days passed with both parties assuming the other was delayed. The domain transfer window on the auth code expired. A new code had to be generated.
Who caused it: Ambiguous — there is a shared-responsibility argument. The seller sent the code in good faith; the buyer had not formally updated their contact details in writing within the escrow workflow.
Reasonable resolution framework: Split-responsibility adjustments. Because neither party's conduct rises to a clear breach, the practical outcome is often a negotiated reduction — both parties absorb a share of any carrying cost, and the agreement proceeds at the original price. The settlement agent documents the agreed split in writing before disbursement.
Scenario 3: ICANN 60-day lock was undisclosed — $45,000 USD (~AUD $69,500) deal
Seller listed a domain that had transferred to their account 45 days before the listing. Both broker and buyer assumed a standard three-to-seven day transfer. The lock period had not expired at the time of purchase. Transfer was delayed 15 additional days.
Who caused it: The seller had constructive knowledge of the prior transfer and the resulting lock. Failing to disclose it is a material omission. The broker who did not run a pre-closing WHOIS check also bears some process responsibility.
Reasonable resolution framework: Seller bears the direct carrying costs. If the broker failed a disclosed obligation to conduct pre-closing due diligence, the broker may share liability for documented losses. This is exactly the scenario where a clear disbursement protocol matters: when the eventual payment is released, it must be reduced by the agreed adjustment, and that reduced amount must reach the right parties instantly and in the right proportions. The longer the post-resolution disbursement takes, the more the dispute festers.
The role of the settlement professional in disputed domain closings
Settlement agents, closing attorneys, and domain escrow officers occupy a critical position in late-transfer disputes. In cases where disputes arise during the transaction, escrow services can provide support and guidance for resolution. They can mediate between buyer and seller to resolve issues related to payment, transfer procedures, or contract terms.
Escrow services provide a secure environment for transactions, ensure compliance with contractual obligations, offer dispute resolution support, handle complex transaction requirements, and build trust among participants in the domain marketplace.
What escrow and settlement services do exceptionally well is hold and protect value during the dispute period. Escrow holds funds until dispute resolves, protecting both parties from loss while working toward fair resolution. What they are structurally less equipped for is simultaneous, final disbursement at the moment of resolution — distributing funds to buyer, seller, broker, and any co-brokers or advisors in one atomic action the instant the parties sign off.
The standard disbursement workflow — where settlement agents send separate wires, wait for confirmations, and manage exceptions manually — introduces its own latency into a process where both parties are already frustrated. When a dispute has been resolved on paper and the parties have signed off, any further delay in getting the money out is unnecessary friction. It reopens questions that were just closed.
Structuring the resolution: the mechanics of a clean settlement
A properly structured settlement of a late-transfer domain dispute has three components: a documented damage finding, an agreed adjustment, and an execution mechanism that is faster and more certain than the original closing.
Step 1: Document the cause in writing
Before any adjustment is calculated, the parties — ideally through their attorneys or the settlement agent — should jointly document what caused the delay, which party bore responsibility, and whether any third-party (registrar, broker, prior transferee) also contributed. This is not optional. Without a documented cause, the settlement is just a number that either party can later characterize as a concession on price rather than a settlement of a separate claim.
Step 2: Agree on the adjustment structure
The adjustment should be expressed as a specific dollar amount or a percentage reduction applied to the seller's proceeds. If a co-broker's commission is also affected — for example, where the broker's fee is calculated on the net proceeds after the adjustment — the agreement should specify exactly how the commission base changes. If either seller or buyer has engaged a third party in connection with the transaction, including but not limited to a broker, the party who retained such third party is solely responsible for the third party's fees and/or commissions. Disputes within disputes — where buyer, seller, and broker are arguing simultaneously about their respective shares — are far more expensive to resolve than the underlying late-transfer claim. Nail down every outgoing payment in the settlement document before anyone moves money.
Step 3: Execute with finality
This is where the mechanics of disbursement matter most. A settlement that requires four separate wire transfers — one to the seller, one to the sell-side broker, one to a co-broker, one as a carrying-cost reimbursement to the buyer — has four opportunities to fail, four settlement dates that may differ by days, and four separate confirmations that need to arrive before anyone is truly closed. That process re-introduces exactly the kind of timing uncertainty the parties just spent weeks fighting over.
The cleaner alternative is to route the entire settlement amount through a single payment that distributes to every party simultaneously, at preset shares, with no sequential dependency and no intermediate custody. This is precisely what shaka.deal is built for: one incoming transaction on Ethereum, preset proportional shares, and simultaneous payout to every named party in the same block. The settlement agent or attorney sets the distribution parameters — seller amount, broker commission, any co-broker share, buyer reimbursement credit — before the transaction is initiated. When the payment arrives, everyone receives their portion at once. There is no "I sent your wire, please confirm receipt" loop. The transaction is final on-chain and visible to all parties immediately.
For a settlement involving USD $80,000 (~AUD $124,000) flowing to four parties across two countries, that difference in execution quality is not a minor convenience — it is the thing that determines whether the resolution actually feels resolved.
Preventing the dispute the next time
The professionals who see these disputes most often are also the ones best positioned to prevent them. Here are the changes that make the biggest practical difference:
Build a pre-closing checklist that includes a WHOIS pull. Before any domain purchase agreement is finalized with a hard transfer date, check the registration date, the date of most recent transfer, and the date of any recent registrant change. The right sequence keeps an acquisition moving: confirm which trigger is running before you buy, take the transfer move first and the registrant edit second, and use the opt-out only where the registrar offers it. If any of those dates is less than 60 days old, the transfer timeline in the agreement must reflect reality — not optimism.
Specify the transfer deadline as a calendar date, not a relative period. "Within five business days of receipt of payment" is vague in three different ways. "On or before October 14, 2026" is not. If the deadline is missed, there is no ambiguity about whether it was missed.
Include a liquidated-damages clause for delayed transfer. A pre-agreed daily carry amount — modest, proportionate to the deal size — removes the need to litigate actual losses in the event of a delay. Both parties know the exposure before they sign, which also creates a healthy incentive for the seller to keep the transfer timeline clean.
Specify the disbursement mechanism in advance. The purchase agreement should name the closing method, the disbursement sequence, and any co-payees (brokers, advisors, co-sellers). If a dispute arises and an adjustment is later agreed, having a pre-agreed disbursement architecture means the settlement payment can be executed cleanly rather than improvised under pressure.
Use settlement infrastructure that matches the certainty you are trying to create. As the digital landscape continues to evolve, the role of escrow services in domain name transactions remains vital, offering the necessary security and reliability that these high-stake transactions demand. Escrow handles the custody and verification function well. The final distribution function — routing multiple simultaneous payments to multiple parties at the moment of release — is where onchain payment routing like shaka.deal adds material value on top of the escrow layer, not instead of it. The escrow confirms everything is in order; shaka.deal executes the disbursement instantly, to every party, in one transaction.
What finality actually means in a settlement
There is a meaningful difference between a settlement that is agreed and a settlement that is complete. Agreements exist on paper; completion requires money to have moved irreversibly to the right accounts. In traditional wire-based closings, the gap between agreement and completion can be hours or days. Confirmations get lost. Banks have cut-off times. International wires queue. During that gap, the agreement is notionally final but practically open — any party could raise a new grievance, claim they haven't received anything yet, or dispute the math of what they received.
Onchain settlement closes that gap. When a payment routes through shaka.deal, every party's allocation is determined by the preset parameters at the moment of transaction initiation. The payment executes and distributes in a single on-chain action. There is nothing to confirm, nothing to follow up, no intermediate state where one party has been paid and another hasn't. That is not a feature that benefits any one party in the deal — it benefits the settlement professional, because it makes their resolution permanent the moment they execute it.
For disputes that were messy getting here, that kind of clean exit is worth designing for.
Summary
Late domain transfers are usually caused by one of four things, and each has a different implication for who bears the resulting damage.
| Cause | Typical delay | Who bears the damage |
|---|---|---|
| ICANN 60-day lock, foreseeable and not planned for | Up to 60 days | The seller or their advisors, when the lock was knowable at signing |
| Registrar security lock the seller forgot to remove | Several business days | The seller |
| Auth code workflow failure | Depends on when the failure is noticed | Ambiguous, often shared |
| Registrar processing delay | Three to seven business days | Nobody's fault |
Settling the dispute requires three things done in sequence: document the cause, agree on the adjustment, and execute the disbursement cleanly. The third step is where most settled disputes go wrong — sequential, multi-party wire disbursements re-introduce timing risk and uncertainty into a situation that the parties thought they had resolved.
The settlement professionals who handle these deals — escrow officers, closing attorneys, domain brokers, OTC trading desks — already bring the expertise in verification, documentation, and mediation. Adding a disbursement layer that routes the full settlement amount to all parties simultaneously, in one final on-chain transaction, completes the picture. That is the service stack that makes a late-transfer dispute genuinely over rather than just nominally resolved.
