How to draft a domain assignment agreement for a .app domain

How to draft a domain assignment agreement for a .app domain. UDRP and ccTLD domain recovery and defense across .app. Email the firm to assess your case.

A software startup agrees to buy the .app domain that matches its product name. The seller wants payment on delivery; the buyer wants the domain before releasing funds. Without a properly drafted assignment agreement and a structured escrow, neither party has a safe path forward. The question is how to close that gap cleanly – and what a well-constructed agreement must cover to protect both sides.

To draft a domain assignment agreement for a .app domain, the parties must document the transfer of registrant rights in writing, confirm chain of title, run a prior-dispute search, and hold funds in escrow until the registrar confirms the gaining-registrar transfer is complete. The .app zone is a restricted generic top-level domain operated under ICANN's gTLD framework, which means UDRP dispute history on the domain is searchable and must be cleared before closing. A standard assignment agreement covers representations as to ownership, absence of encumbrances, escrow mechanics, and the post-transfer notification protocol.

This page covers the structure of a .app domain assignment agreement, the due-diligence checks that protect the buyer, the escrow model that protects both parties, the UDRP risk window, and how COGNOMEN structures these transactions.

What is a .app domain assignment, and why does the zone matter?

A domain assignment transfers the registrant-of-record rights in a specific domain name from a seller (the outgoing registrant) to a buyer (the incoming registrant), with the registrar executing the change in the WHOIS/RDDS record after the transfer is authorized. The .app zone is not simply a vanity extension. Google Registry operates .app as a restricted, HTTPS-mandatory gTLD under an ICANN Registry Agreement, which means the domain will only resolve in browsers if the destination server presents a valid TLS certificate. That technical constraint shapes the assignment: the agreement should confirm that the seller has not embedded SSL-linked services that the buyer cannot immediately replicate post-transfer.

Because .app is a gTLD, the UDRP applies. Any brand owner who believes a .app domain was registered in bad faith can bring a UDRP complaint before WIPO or the Forum – even after the domain changes hands. An assignment does not extinguish that exposure. If the incoming registrant acquires a domain that a third party could still challenge, it inherits the dispute risk. This is why chain-of-title and prior-dispute review are not optional steps; they are the foundation of a safe .app acquisition.

We regularly advise buyers who discovered – after agreeing a price but before signing – that the target .app domain had been the subject of a prior UDRP complaint that was withdrawn rather than decided. A withdrawal without a decision leaves the complainant free to refile. Catching that fact before transfer is far less expensive than defending after.

How do you confirm clean title before drafting the agreement?

Clean title on a .app domain means three things: the seller is the registered holder of record, no third party has a contractual or legal claim over the domain, and no dispute proceeding – UDRP, URS, or court – is pending or recently concluded against it. The buyer's counsel should verify all three before any money changes hands.

The current registrant-of-record appears in the publicly accessible RDDS (the successor to WHOIS under ICANN's registration data policy). Where privacy or proxy registration is in use, the seller must confirm in writing that it is the underlying registrant and authorize the registrar to reveal the true registrant name for verification. The assignment agreement should include a representation and warranty to that effect, with a condition precedent that the buyer receives written confirmation from the registrar before funds are released from escrow.

The prior-dispute check uses WIPO's publicly accessible case database and the Forum's equivalent. Both are searchable by domain name. A domain that has been the subject of a prior UDRP filing – whether decided in the respondent's favor, dismissed, transferred, cancelled, or withdrawn – carries a traceable dispute history. The agreement should include a seller representation that no UDRP, URS, or equivalent proceeding is pending, and that none has been decided against the seller's interest within a defined lookback period. In our practice we typically negotiate a two-year lookback on prior adverse decisions as a condition of signing.

Trademark encumbrance is the third check. A third party holding a trademark registration that is confusingly similar to the domain retains the right to file a UDRP complaint after the assignment closes, if the element of bad faith can still be established at the time of the original registration. The buyer should commission a trademark search in the relevant classes and geographies before executing the assignment. If the domain incorporates a third-party brand, the price should reflect the residual dispute risk – or the acquisition should not proceed.

To assess the dispute risk on a .app domain before you agree terms, contact info@cognomenlaw.com.

What must a .app domain assignment agreement contain?

A well-drafted .app domain assignment agreement is a short but precise commercial document. It is not a standard trademark assignment; the subject matter is a registrant-record right governed by the registrar's terms of service and ICANN's policies, not a statutory IP right. The following elements are mandatory.

• Identification of the domain and the parties. The agreement names the exact domain (the full string including the .app extension), the outgoing registrant (with registrar account confirmation), and the incoming registrant (with the registrar account that will receive the transfer).
• Representations and warranties. The seller warrants that it is the sole registered holder; that the domain is free of liens, pledges, and contractual restrictions on transfer; that no UDRP, URS, court, or other dispute proceeding is pending or threatened; and that the registration is not in a registrar lock status other than the standard registrar lock that will be released for transfer.
• Consideration and payment mechanics. The agreement states the purchase price, the currency, and whether payment is direct, deferred, or held in escrow. For any acquisition above a nominal threshold, escrow is the only commercially reasonable structure.
• Transfer mechanics and timeline. The agreement specifies which party initiates the transfer (typically the seller generating an authorization code), the gaining registrar, and the deadline for the seller to provide the authorization code after escrow is funded. It should also state what happens if the transfer fails at the registry level – which does occur when a .app domain is in a transfer-prohibited status.
• Condition to closing: registrar confirmation. Funds should not be released from escrow until the gaining registrar confirms that the domain appears under the buyer's account. A "transfer confirmed" trigger – not a "transfer initiated" trigger – protects the buyer.
• Post-transfer obligations. The seller should cooperate with any registrar verification, provide supplemental authorization if the registry requires it, and refrain from interfering with the registration for a defined period after transfer.
• Governing law and dispute resolution. The parties agree on the law governing the contract (commonly chosen by reference to the parties' respective jurisdictions) and on the mechanism for resolving any breach of the agreement itself – noting that the UDRP cannot resolve contractual disputes between buyer and seller; it only addresses registrant legitimacy as between a complainant and the respondent of record.

How does escrow work in a .app domain acquisition?

Domain escrow holds the purchase price in a neutral third-party account while the transfer of the domain from seller to buyer is completed. The escrow agent releases funds to the seller only after the buyer confirms that the domain has appeared under the correct registrar account – or after a defined verification period expires without objection. This structure is the standard for domain transactions above any material threshold, and it protects both parties: the seller knows funds are committed, and the buyer knows it will not pay before delivery.

For a .app domain, the escrow instruction letter must account for the zone's HTTPS requirement. If the seller's domain is resolving on an active site, the transfer will briefly interrupt service while the new registrant configures its TLS environment. The escrow instruction should specify who bears that interruption risk and whether the seller is required to provide handover documentation for the existing SSL configuration.

In a recent transaction we structured (a .app domain for a software-as-a-service product, spring 2025), the seller had the domain pointed at an active web application. The escrow instruction included a staged handover: DNS control transferred first, the SSL certificate was migrated, and only after the buyer confirmed successful browser resolution did the final funds tranche release. That sequencing avoided what could have been a multi-day resolution failure in the buyer's production environment.

Where the parties are in different jurisdictions, the escrow agent should be acceptable to both sides and, ideally, subject to regulatory oversight in a recognized financial jurisdiction. The escrow agreement itself is a separate instrument from the domain assignment agreement, though the two should be cross-referenced and their conditions synchronized.

To structure escrow and the assignment agreement for a .app domain acquisition, email info@cognomenlaw.com.

What UDRP risk does the buyer of a .app domain inherit?

The UDRP's bad-faith elements are assessed by reference to the original registration event – not the most recent assignment. This is the single most important risk point for a .app domain buyer. If a third party can establish that the domain was registered in bad faith by an earlier registrant, the current holder – even an innocent purchaser for value – can lose the domain through a UDRP proceeding.

Panels have consistently held that a bad-faith registration does not become a good-faith registration simply because the domain changed hands. The critical question is whether the original registration was abusive. A buyer who acquires a domain without checking the registration history may find itself defending a UDRP complaint it did nothing to invite. The cost of a UDRP defense – the WIPO single-member filing fee begins at USD 1,500 for a new complaint, plus legal fees on both sides – can far exceed the cost of a pre-acquisition due-diligence review.

The UDRP does recognize Paragraph 4(c) safe harbors: a registrant with a bona fide commercial offering predating notice of the dispute, a party commonly known by the domain name, or a party making legitimate noncommercial use has a defense. A buyer who intends to develop an application under the .app name should document that intent – business plans, developer agreements, trademark filings – from the moment of acquisition, so that the safe-harbor record begins building immediately. We advise buyers to treat that documentation as part of the closing deliverables, not an afterthought.

What if the seller received a UDRP complaint that was settled or withdrawn before a decision? The buyer inherits the domain's history. A complainant who withdrew for strategic reasons retains the right to refile under the UDRP, and a new registrant is a new respondent. The assignment agreement should include a seller indemnity for any claim arising from the domain's pre-assignment registration history, capped at the purchase price, with a defined survival period.

How does the .app zone compare to other gTLDs and ccTLDs for assignment purposes?

The right route depends on the zone, the parties' risk tolerance, and the volume of the transaction. For .app specifically, the UDRP governs dispute risk, and the domain is functionally indistinguishable from a .com in terms of legal process – but the technical HTTPS requirement creates a drafting variable that a pure .com assignment does not.

A .com domain assignment follows the same structural model: representations, escrow, transfer mechanics, and prior-dispute check. The WIPO and Forum filing fees for a complaint are identical across all UDRP-covered gTLDs. The difference is that .com is an unrestricted zone and .app is operated under a registry agreement that can change the technical conditions of resolution. A buyer acquiring a .app domain should confirm that the domain's DNS configuration will continue to meet the zone's HTTPS requirement after transfer.

For a ccTLD such as .uk (Nominet DRS) or .eu (EURid/ADR.eu), the assignment is structurally similar but the dispute procedure governing pre-transfer risk differs. The Nominet DRS uses an "abusive registration" test – registered or used abusively, a lower bar than the UDRP's cumulative "registered and used in bad faith" – which means the due-diligence lookback on a .uk domain should assess use history, not just registration intent. The .eu ADR.eu procedure has its own eligibility requirements (an EU/EEA nexus for the registrant). Those zone-specific rules affect what the seller warrants and what the buyer checks.

Where a domain portfolio spans multiple zones – a .app and a matching .co or .io, for example – each domain should be covered by a separate assignment schedule within the master agreement, because each zone has its own transfer mechanics and dispute exposure. Bundling multiple zones into one bare assignment without zone-specific representations is a common drafting error that creates ambiguity if a post-transfer dispute arises in one zone but not another.

If the domain involved in a dispute is not susceptible to resolution by arbitration – because, for example, the agreement itself is contested or the seller is in breach – the parties may need to pursue court action. Court anticybersquatting litigation is handled with local litigation counsel in the relevant jurisdiction and is the appropriate route when contractual remedies are at issue rather than registrant legitimacy.

What evidence decides whether the assignment is safe to complete?

The decision to proceed with a .app domain assignment rests on four evidence points that counsel should verify before advising the buyer to sign. First, the RDDS record should match the seller's stated identity, and the registrar should confirm (in response to a formal request or through the authorization code process) that the account holder is the party to the agreement. Second, the WIPO and Forum case databases should show no pending proceeding and no adverse decision within the lookback period. Third, a trademark clearinghouse or watch-service search should identify any third-party trademark registration that is identical or confusingly similar to the domain string. Fourth, the registration creation date should be reviewed: a domain registered very recently before the offer to sell – particularly where the domain incorporates a recognizable brand – is a risk signal that should be specifically addressed in the representations.

In a recent due-diligence matter (a .app domain for a fintech product name, autumn 2024), we identified a prior UDRP complaint that had been filed, then withdrawn the day before the response deadline, with no decision issued. The domain had then been sold twice before reaching our client. The seller in that transaction had no knowledge of the prior complaint. Our client renegotiated the price to reflect the residual risk and secured an indemnity. Without the prior-dispute search, the buyer would have acquired not only the domain but the full exposure of that unresolved history.

Where the domain incorporates a descriptive or generic term rather than a brand, the risk profile is different. Generic strings have a lower UDRP exposure because the complainant must establish that the domain is confusingly similar to a specific trademark – not merely to a common word. But even generic .app domains should be checked, because a previously registered domain may have been used in a way that attracted trademark claims that were resolved by deletion rather than transfer.

Related at COGNOMEN

• Domain purchase, sale, and portfolio brand-protection services at COGNOMEN
• Pre-acquisition due diligence for domain transactions, including .biz and gTLDs
• FAQ: ccTLD transfer remedies and what they mean for buyers and sellers