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

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

A seller hands over a .cloud domain. Money moves. Then counsel discovers the registration has a prior UDRP dispute on record, an undisclosed lien, or a chain-of-title gap that could unwind the deal. The buyer now holds a name it cannot fully use – and may not be able to keep. Drafting the assignment agreement correctly is the only document-level protection against that outcome.

To draft a domain assignment agreement for a .cloud domain, the parties must address three interlocking issues: chain-of-title integrity, the .cloud registry's transfer mechanics administered under WIPO's procedures, and escrow structure. The .cloud zone operates under gTLD rules, so UDRP disputes and WIPO's filing-fee schedule apply if a dispute arises post-transfer. A well-drafted agreement resolves those issues in the document itself, before any money changes hands.

This page covers each element – the legal test, the evidence required, the structure of the document, the due diligence that must precede signing, and the realistic next steps for a .cloud transaction.

What makes a .cloud domain assignment different from other gTLD transfers?

The .cloud zone is a new gTLD, accredited under ICANN's standard registry-registrar agreement and subject to the UDRP in exactly the same way as a .com. That single fact has significant consequences for assignment drafting. Any UDRP complaint filed after the transfer date runs against the new registrant – the buyer – not the seller. If the domain was registered in bad faith before the sale, that registration history travels with the name.

New gTLDs also carry a layer of registry-level restrictions that legacy zones do not always impose. The .cloud registry may maintain its own eligibility requirements, reserved-name lists, and premium domain categories. An assignment agreement that ignores those provisions can be validly signed between two parties and yet be void against the registry if it purports to transfer a name the registry treats as non-transferable or reserved.

What should the parties check before drafting? Registry policy on transfer eligibility, any premium pricing tier attached to the name, and whether the domain is in a redemption grace period or pending-delete status at the time of signing. Each of those conditions requires a specific representation in the agreement itself.

In our practice, we regularly advise buyers who have received a domain assignment only to find the seller never triggered the registrar's formal authorization code (auth-code) process. The name was never pushed to the buyer's account, the seller disappeared, and the agreement provided no enforcement mechanism. Drafting to cover the mechanics of the transfer – not merely the economics – is the entire difference between a document that works and one that does not.

What legal test governs a .cloud domain in a UDRP dispute – and why does that shape the agreement?

Under the UDRP, a complainant seeking to reclaim a .cloud domain must satisfy all three elements of Paragraph 4(a): confusing similarity to a trademark, no legitimate interest in the registrant, and registration and use in bad faith. The assignment agreement must protect the buyer against the risk that a third-party complainant meets all three elements against the history the domain carries.

The critical point is the conjunctive standard: both registration and use must be in bad faith. If the original registrant registered abusively but the buyer acquired in clean commercial arms-length dealing, a panel evaluating the post-transfer position must still assess whether bad faith attached at registration. Panels have consistently held that a subsequent legitimate transfer does not automatically cure a domain's registration history. A buyer who inherits an abusively registered .cloud name may still face a successful complaint.

The assignment agreement is therefore where the parties allocate that risk. Representations and warranties about prior UDRP history, trademark searches, and dispute-free status are not boilerplate – they are the contractual mechanism that gives the buyer recourse against the seller if a post-transfer challenge succeeds.

For a read on whether the three UDRP elements apply to a .cloud domain you are considering acquiring, reach us at info@cognomenlaw.com.

How should the chain-of-title check be structured before drafting the agreement?

Chain-of-title due diligence for a .cloud domain has four components: WHOIS/RDDS history, prior UDRP and URS dispute records, trademark conflict analysis, and registrar-level account verification. Each feeds directly into the representations and warranty schedule of the final agreement.

WHOIS/RDDS history reveals whether the domain has changed hands multiple times, whether prior registrants used it for parking, pay-per-click, or suspicious redirects, and whether the registration date predates or postdates the trademark that most closely matches the string. In the .cloud zone, registration dates are verifiable through ICANN's registration data access protocol. Gaps between publicly recorded registrant changes and the seller's claimed ownership period must be explained in the agreement or treated as a warranty breach.

Prior UDRP and URS records are searchable through the published decisions database maintained by each WIPO and the Forum. A domain that was the subject of a UDRP complaint – even one the registrant defended successfully – carries a documented dispute history. A name that survived a complaint on a narrow procedural ground, or one where the complainant withdrew at the last moment, is not the same risk profile as a name that has never been challenged. The agreement should require the seller to warrant the absence of any prior proceedings, pending claims, or correspondence asserting trademark rights in the string.

Trademark conflict analysis means running the .cloud string through at least the major trademark databases – principally the USPTO and EUIPO registers – to identify any live registrations that could form the basis of a future UDRP complaint. This is not the same as the seller's own trademark search. It is the buyer's independent assessment of third-party risk.

Registrar-level account verification confirms that the seller is the registrant of record, that the domain is not locked by a registrar hold or UDRP lock, and that no transfer prohibition is active. A domain under a UDRP lock – typically imposed after a complaint is filed – cannot be transferred until the proceeding concludes. Attempting to transfer a locked domain is both technically impossible and a registrar policy violation.

In a recent matter involving a .cloud domain in the technology sector (spring 2025), we identified a prior UDRP complaint that had been withdrawn before panel appointment. The complaint was not disclosed in the initial heads-of-terms. The discovery during due diligence allowed the buyer to renegotiate the price and obtain an indemnity before any agreement was signed.

What clauses must the assignment agreement itself contain?

A well-structured .cloud domain assignment agreement contains at minimum seven operative provisions: (1) identification of the domain and registrar; (2) representations on chain-of-title, prior disputes, and trademark conflicts; (3) transfer mechanics and the auth-code delivery obligation; (4) escrow structure and release conditions; (5) post-transfer cooperation obligations; (6) indemnity for pre-transfer conduct; and (7) governing law and dispute resolution.

The identification clause must state the full domain name including the .cloud extension, the current registrar, the WHOIS-recorded registrant, and the expiry date. If the domain is in a premium tier with a higher renewal price, that fact must be stated. A buyer who acquires a domain without knowing the renewal premium is an unpleasant discovery at year two.

The representations clause is where the seller warrants: no prior UDRP or URS proceedings; no pending third-party trademark claims; no registrar holds or locks; accurate WHOIS data; and full authority to transfer. Each representation should survive closing. A representation that expires at transfer is worthless the moment a UDRP complaint arrives six months later.

The transfer mechanics clause must specify who initiates the registrar's transfer process, the deadline for auth-code delivery, and what happens if the transfer fails technically. It should also address what constitutes completion – typically, the domain appearing in the buyer's registrar account – rather than simply the seller's initiation of the push.

The escrow clause is the economic engine of a domain transaction. Funds are held by a neutral escrow provider until the domain appears in the buyer's account and any agreed hold period has elapsed. For a .cloud name, the standard ICANN transfer lock period after a registrar change is 60 days. The escrow structure should account for that period if the parties are also contemplating a registrar migration.

The indemnity clause is where the seller accepts liability for conduct prior to the transfer date. If a UDRP complaint is filed naming the buyer as respondent on the basis of the seller's prior bad-faith conduct, the indemnity entitles the buyer to claim defense costs and, if a transfer order is made against the buyer, the value of the domain.

How does escrow work in practice for a .cloud transaction – and what can go wrong?

Domain escrow is straightforward in structure: the buyer deposits funds with an escrow provider; the seller delivers the auth-code; the registrar transfer is initiated; upon confirmed receipt by the buyer, funds are released. In practice, the process carries three common failure points that a well-drafted agreement addresses in advance.

First, the transfer window. ICANN's standard transfer policy allows a domain to be transferred between registrars only after certain locking conditions are satisfied. A domain registered or transferred within the preceding 60 days cannot be pushed again. If the seller acquired the .cloud name shortly before the transaction, the buyer's timeline shifts accordingly. The agreement should state what happens to the escrowed funds if a mandatory lock period delays transfer beyond the anticipated closing date.

Second, the registry downtime risk. New gTLD registries, including .cloud, do occasionally undergo scheduled or unscheduled maintenance that interrupts transfer processing. The agreement should provide for a reasonable extension period and specify who bears the risk of a technical failure outside either party's control.

Third, the registrar account compromise. If either party's registrar account is compromised between signing and transfer, the domain may be redirected or transferred to a third party. This is the domain theft scenario. The agreement should require both parties to maintain account security measures and specify the recourse path – including registrar escalation, ICANN Compliance, and if necessary, the recovery procedures for stolen domains – if a redirect occurs before closing.

To weigh the escrow and transfer structure for your .cloud transaction, email info@cognomenlaw.com.

What happens if a UDRP complaint arrives after the assignment is signed?

A UDRP complaint filed after a .cloud domain has been transferred names the new registrant – the buyer – as the respondent. The respondent has 20 days to file a response once the case commences. If no response is filed, the panel decides on the complaint alone, and default substantially increases the risk of a transfer order being issued.

The buyer's first step is to assess the complaint against all three UDRP elements. Is the complainant's trademark similar to the .cloud string? Does the buyer have a documented legitimate interest? Was the registration – including the seller's registration history – in bad faith at the time of original registration? That last question is where the assignment agreement's indemnity and warranty provisions become operative. If the answer to the third element depends on what the seller did, the seller must be put on notice immediately and required to cooperate with the defense under the agreement's post-transfer cooperation clause.

Panels have also found reverse domain name hijacking (RDNH) – a finding that the complaint was brought in bad faith to deprive a legitimate registrant – where a complainant filed against a clean commercial acquirer with no realistic prospect of satisfying all three elements. An RDNH finding carries no monetary penalty but is a published reputational adverse finding against the complainant. A well-documented acquisition history, properly recorded in the agreement, strengthens the respondent's position in seeking such a finding.

In a further matter we handled (a .cloud string in the SaaS vertical, autumn 2024), a buyer who had acquired a .cloud domain through an undocumented private transaction faced a UDRP complaint less than three months post-transfer. Because no written assignment existed, the buyer could not demonstrate the date of acquisition, the commercial purpose, or the price paid. The complaint was not resolved on a finding of RDNH. That outcome would have been different with a documented, dated, and properly structured assignment agreement in place.

When should you use court action rather than relying on the assignment agreement alone?

The UDRP provides transfer and cancellation. It does not award damages, costs, or injunctions. If a dispute over a .cloud domain assignment escalates beyond those remedies – for example, if the seller refuses to deliver the auth-code after receiving payment, or if a third party's bad-faith registration caused economic loss – the UDRP is not the right tool. Court action, handled with local litigation counsel in the relevant jurisdiction, is the only path to monetary recovery or injunctive enforcement of the assignment agreement itself.

The decision matrix here is straightforward. If the domain is still with the seller and needs to move, the assignment mechanics – escrow release, registrar escalation, ICANN Compliance – are the first resort. If a third party has interfered with the transfer, registrar escalation and, if necessary, a domain theft recovery procedure are the next step. If economic loss has occurred and the counterparty is identifiable, court action in the appropriate jurisdiction is the final path. UDRP applies when a third-party trademark holder files a complaint against the registrant post-transfer. Those are different situations, and the response must match the situation.

For a .cloud domain where the buyer suspects the seller was itself a bad-faith registrant who manufactured the transaction to launder a tainted name, a court action may be the most direct route to rescission and recovery of the purchase price. That route also preserves the possibility of claiming damages for the registration's downstream consequences, which the UDRP cannot reach.

What is the realistic cost structure for a .cloud domain assignment?

The cost of drafting and executing a .cloud domain assignment agreement depends on the complexity of the due diligence, the value of the domain, and whether any dispute arises post-transfer. In legal-fee terms, a straightforward assignment for a domain with a clean dispute history and a single registrar involves drafting, due diligence, and escrow coordination. A domain with prior dispute history, multiple registrar changes, or a contested transfer requires significantly more work.

If a UDRP complaint is filed post-transfer, the forum filing fee at WIPO begins at USD 1,500 for a single-member panel covering one to five domains. The respondent's legal fees for defending a complaint typically fall in a range comparable to a complainant's fees for filing one. Those costs are separate from any escrow or assignment legal fees.

A post-transfer complaint that the buyer must defend alone – because no indemnity was obtained from the seller – means the buyer bears both the defense cost and the risk of losing the domain. That combination is the financial case for getting the assignment agreement right before closing. COGNOMEN publishes transparent fee ranges for domain transactions and dispute representation; we do not quote "price on request" for standard services.

For a cross-zone transaction – a buyer acquiring both a .cloud domain and a related .com, .eu, or .uk name in the same deal – the assignment agreement must address each zone separately. The .eu zone, administered through EURid, has its own eligibility rules and ADR.eu dispute procedure. The .uk zone, administered by Nominet, runs its own DRS with a distinct "abusive registration" test. A single omnibus assignment agreement that treats all zones identically without addressing each registry's rules is a document that will fail at the specific point it is most needed.

Related at COGNOMEN

• Domain transactions, due diligence, and portfolio brand protection services
• Brand protection monitoring and post-transfer dispute exposure analysis
• ccTLD transfer remedy procedures and cross-zone assignment considerations