FAQ: draft a domain assignment agreement for a .app domain

What does it mean to draft a domain assignment agreement for a .app domain?

Drafting a domain assignment agreement for a .app domain is the process of preparing a legal instrument that transfers all registrant rights – and only those rights – in a named .app domain from the current holder (the assignor) to a new holder (the assignee), for agreed consideration.

The agreement does several things at once. It identifies the domain precisely (the full string, the registrar, and the current WHOIS/RDDS record). It sets out the purchase price or other consideration. It includes representations by the assignor that the domain is free from liens, competing claims, active UDRP proceedings, and any registrar lock triggered by an unresolved dispute. And it specifies the mechanics of the actual registrar-level transfer – the authorization code (EPP/auth-info), the timing of push or pull, and the escrow structure that protects the buyer's funds until the registrar confirms the change of registrant.

.app domains carry one structural feature worth noting at the drafting stage. The .app registry requires HTTPS for any active site. That is a technical registry policy, not a trademark or contractual point, but the agreement should allocate responsibility for compliance after transfer. The buyer takes the domain as-is on the technical side; the agreement should say so expressly.

A domain assignment is also the moment to settle the chain of title. If the assignor acquired the domain from a third party, the agreement should attach or reference that prior transfer record. A clean chain matters if anyone later challenges the registrant's legitimacy under the UDRP. A panel reviewing a complaint filed after a sale will look at the entire history of the registration, not just the current holder's conduct.

How long does it take to draft a domain assignment agreement for a .app domain?

Drafting a straightforward .app domain assignment agreement typically takes a few business days once the parties have agreed on price and both sides have provided their identifying information and registrar details.

The actual drafting phase – producing the instrument, the schedules, and any escrow instructions – is rarely the bottleneck. What lengthens the process is the pre-drafting work: verifying the WHOIS/RDDS record, searching WIPO's public case database for prior UDRP proceedings against the domain, confirming the domain is not subject to a registrar lock or a pending transfer prohibition, and checking the assignor's authority to assign if the current registrant is a company rather than an individual.

If escrow is used – which is standard practice for any non-trivial transaction – the escrow platform must also be selected and funded before the registrar transfer is initiated. A reputable escrow service runs its own verification steps. Budget an additional two to five business days for that layer.

Contested or complex transactions add time. A domain with prior UDRP proceedings, disputed ownership between co-founders, or an assignor operating through a privacy shield that has not yet been lifted will require additional diligence. We regularly advise buyers who discover mid-process that the assignor is not the true beneficiary – resolving that before signing is far less costly than resolving it after transfer.

For a read on whether a .app domain you are buying or selling has a clean dispute history, reach us at info@cognomenlaw.com.

What does it cost to draft a domain assignment agreement for a .app domain at WIPO?

Drafting a domain assignment agreement does not involve WIPO directly. WIPO is the principal dispute-resolution provider for UDRP proceedings; it does not draft, file, or administer private transfer agreements.

WIPO becomes relevant in two connected contexts. First, if a prior UDRP complaint was filed against the .app domain, WIPO's public database will contain the record – and that record is part of the due diligence a buyer must conduct before signing an assignment. Second, if a dispute arises after the assignment – for example, a brand owner files a UDRP complaint against the new registrant – WIPO would administer that proceeding. The WIPO filing fee for a single-domain UDRP complaint is USD 1,500 for a single-member panel, separate from any legal fees.

The cost of drafting the assignment agreement itself is a legal fee. Market rates for a straightforward single-domain .app assignment are typically in a range comparable to other specialist transactional work – see the guidance on our domain transactions service page for an overview of how those engagements are structured. COGNOMEN publishes fee guidance rather than hiding it, because transparent pricing is how a specialist boutique earns trust in a market that often obscures costs.

The escrow fee is a third and separate cost. Reputable escrow platforms charge a percentage of the transaction value, subject to a minimum. That cost is typically shared between buyer and seller or allocated in the agreement.

What evidence is needed to draft a domain assignment agreement for a .app domain?

The core evidence needed before and during drafting falls into four categories: title evidence, dispute history, registrar status, and party authority.

Title evidence means the current WHOIS/RDDS record showing the registrant of record, the registrar, and the expiry date. If the domain was previously transferred, the assignor should produce documentation of that prior acquisition – a prior assignment agreement, a registrar confirmation email, or a bill of sale.

Dispute history means a search of WIPO's public case database and the Forum's public records for any UDRP proceedings naming this domain. A result in the complainant's favor – a transfer or cancellation order – means the current registrant received the domain after a dispute resolved it against a prior holder. That is not automatically a problem, but it requires a specific analysis: was the transfer to the current assignor clean, and does the current registration itself stand on independent legitimate grounds? We have seen buyers unknowingly acquire tainted domains whose prior dispute history made them vulnerable to a renewed complaint.

Registrar status means confirming the domain is not locked at the registrar level due to an active dispute, a court order, or a recent transfer (the standard 60-day transfer lock after a change of registrar). A locked domain cannot be transferred, and a purchase agreement signed while the domain is locked will stall at the implementation stage.

Party authority means confirming the assignor has legal authority to transfer. If the registrant is a corporation, the signatory must be authorized. If the domain is held in the name of a privacy service, the beneficial owner must surface and provide the authorization code directly.

Can I draft a domain assignment agreement for a .app domain for more than one domain at once?

Yes. A single assignment agreement can cover multiple .app domains – or multiple domains across different zones – in one instrument, provided the structure reflects the practical and legal differences between each name.

A multi-domain agreement uses schedules. Each domain is listed as a separate schedule item with its own registrar, expiry date, and WHOIS/RDDS record. The representations and warranties in the body of the agreement apply to each domain in the schedule individually, so a title defect or registrar lock affecting one domain does not automatically invalidate the transfer of the others. That granularity matters if due diligence uncovers a problem with a subset of the portfolio.

Multi-domain transactions also raise pricing and allocation questions. If the parties agree on a lump sum for the portfolio, the agreement should apportion value across individual domains – both for tax purposes and for the calculation of any partial refund if a specific domain cannot be transferred due to a lock or competing claim.

One logistical point: each .app domain requires its own authorization code from the current registrar. Those codes are time-limited. In a portfolio transaction, the sequence and timing of the registrar transfers must be coordinated, and the escrow structure must account for the possibility that some transfers complete faster than others. We routinely coordinate multi-domain .app transactions and structure the escrow release so it triggers only when a defined threshold of domains – typically all, or a specified minimum – has transferred successfully.

If the portfolio includes domains in zones other than .app, the cross-zone analysis matters. A .app domain and a matching .com or .uk domain may each carry its own dispute history, and the assignment agreement should treat each zone's title record separately. For ccTLD domains – for example, a matching .uk name – the applicable dispute procedure and registry rules differ from the UDRP that governs .app. See our note on recovering lapsed domains for context on how a domain's registration history can affect a subsequent owner.

What are the possible outcomes when you draft a domain assignment agreement for a .app domain?

Drafting a domain assignment agreement is a process that can reach several distinct outcomes depending on what due diligence reveals and how the transaction is structured.

The intended outcome is a clean transfer: the assignee becomes the registrant of record at the .app registrar, the consideration passes through escrow, and both parties have a documented chain of title for any future dispute or sale. That outcome is achievable in most transactions where due diligence confirms clean title.

A second possible outcome is a conditional transfer: due diligence identifies a resolvable issue – an expiring domain, a stale privacy shield, or a minor registrar lock – and the agreement is structured with a condition precedent that must be satisfied before the transfer proceeds. The buyer is protected by the escrow hold; the seller is protected by a clear timeline and a mechanism for the condition to be lifted.

A third outcome is renegotiation or withdrawal. If due diligence reveals an active UDRP proceeding, a prior adverse UDRP decision against the current registrant's use of the name, or evidence that the assignor does not hold clear title, a buyer acting on informed advice will either renegotiate the price to reflect the risk or walk away. In a recent matter (a .app portfolio transaction, early 2026), we identified a prior UDRP complaint – filed but settled before a decision – that had not been disclosed by the assignor. The buyer adjusted the purchase price and obtained a specific indemnity covering any future proceedings arising from the prior registrant's conduct.

A fourth outcome affects the post-assignment period. Even a cleanly transferred .app domain can attract a UDRP complaint after the sale if a brand owner believes the current registrant is using it in bad faith. A well-drafted assignment agreement does not prevent that risk – no document can – but it equips the new registrant with the evidence of good-faith acquisition that Paragraph 4(c) of the UDRP recognizes as a safe harbor. For context on how passive holding disputes have played out in contested registrations, see our case study on passive holding disputes.

What is the difference between a domain assignment and a UDRP transfer order?

A domain assignment agreement is a private contract between a willing buyer and a willing seller. A UDRP transfer order is a mandatory direction issued by a panel to a registrar following a dispute proceeding. The two routes produce the same technical result – a change of registrant – but they operate on entirely different legal bases and carry different chain-of-title implications.

A private assignment transfers registrant rights by agreement. The assignee can document the transaction, the price paid, and the representations made about title. That documentation is the foundation of any legitimate-interest argument the new registrant would need to raise if a future complaint is filed.

A UDRP transfer order does not create a private-law contract. It directs the registrar to transfer the domain to the complainant because the panel found bad faith and no legitimate interest on the respondent's side. The complainant receives the domain by operation of the Policy, not by purchase. That distinction matters in subsequent transactions: a domain transferred by UDRP order carries a public record of the prior dispute, and any buyer of that domain should scrutinize whether the original registration issue has been fully resolved or whether a residual claim could be raised against the current use.