Summary

  • On 26 August 2008, a federal court ordered eNom to return solidhost.com to Solid Host and directed Namecheap, Inc. to cooperate. As the court’s later order records, eNom restored technical control that day; Namecheap disclosed the privacy customer’s identity to counsel on 4 September. Restoration and disclosure were separate remedies, exercised by different actors on different dates.
  • The May 2009 ruling did not decide that the alleged theft occurred or that Namecheap was liable. It rejected a direct Anti-cybersquatting Consumer Protection Act claim for lack of mark-specific bad-faith intent, but allowed contributory-cybersquatting and downstream-contract theories to survive a motion to dismiss. Later Ninth Circuit decisions sharply limited both routes: Balsam v. Tucows held that the Registrar Accreditation Agreement did not itself give private claimants enforceable third-party rights, and Petronas v. GoDaddy.com held that the ACPA did not create contributory-cybersquatting liability.
  • The case remains institutionally important because Namecheap was alleged to have occupied three positions at once: displayed registrant, custodian of the customer’s identity and intermediary capable of helping reverse the loss of control. A workable theft-notice regime should attach obligations to those capabilities, preserve evidence before it disappears, use reversible holds before irreversible disclosure or transfer, and produce one reasoned decision binding the reseller and sponsoring registrar.

Two remedies, nine days apart

On 26 August 2008, a federal court ordered eNom to return solidhost.com to Solid Host, directed Namecheap to cooperate, and made Namecheap the fallback transferor if eNom did not act. eNom restored control of the domain that same day. Namecheap disclosed the privacy customer’s identity to Solid Host’s counsel on 4 September. Those events, set out in the Central District of California’s May 2009 order, did not form one remedy. The first changed who could operate the name. The second revealed whom the privacy service had been shielding. They occurred nine days apart, through different powers, after different forms of compulsion.

That sequence is the most useful entry point into the dispute because the word “disclosure” can make the case sound like a privacy controversy whose decisive question was whether a provider should identify a customer. Identity mattered. It could support pleading, service, recovery and accountability. It did not put the domain back into Solid Host’s hands. The technical remedy came from an order directed at the registrar-facing control point. eNom, not the disclosure itself, changed the operational state.

The distinction also prevents the opposite error: treating Namecheap as irrelevant because it was not alleged to be the sponsoring registrar for solidhost.com. According to the complaint as recounted by the court, Namecheap’s WhoisGuard service appeared in the public registration record, held the customer information behind that record, communicated with the person controlling the name and could cooperate in a transfer. The court did not accept that the labels “reseller” and “privacy service” ended the inquiry.

It asked what functions Namecheap was alleged to perform and whether those functions placed it outside the core registrar conduct protected by statutory safe harbours.

The official court archive preserves the proceeding as a case of institutional overlap rather than a clean two-party ownership dispute. Solid Host claimed the name had been taken. An unidentified user claimed a legitimate purchase. Namecheap stood between the claimant and the user. eNom stood between the reseller layer and the registry. ICANN’s accreditation contract supplied language about registered holders who license use to others, but the contract also denied third parties an enforcement right. In this record, the federal court was the institution able to issue an order that the relevant private actors were compelled to obey.

The strongest governance question is therefore not whether every privacy service must unmask every customer when accused. It is whether an intermediary can aggregate the visible title, the hidden identity and a path to technical restoration, yet treat each function as someone else’s responsibility when a sworn theft notice arrives. Solid Host tried to make that aggregation legally consequential. The district court allowed parts of the attempt to proceed, but it did so at an interlocutory stage, on pleaded allegations, before the Ninth Circuit narrowed the available doctrines.

The alleged hijack and the status quo it created

The underlying facts remained allegations, not trial findings. The May 2009 order said Solid Host, a Netherlands-based hosting company, alleged that it had used solidhost.com in its business and that the name had been registered through eNom. On 4 August 2008, according to the complaint, an unidentified person obtained the login name and password for the relevant eNom account, moved the domain into another eNom account and changed the domain-name-system settings so that visitors reached a page under the unidentified person’s control. Solid Host’s owner was then unable to alter the name’s internet-protocol settings.

The alleged intruder did not merely hide. The complaint, as recounted by the court, said the person offered to sell the domain back for $12,000 by wire transfer. That allegation mattered to the asserted cybersquatting theory because it supplied a possible profit motive tied to the name. It also created an urgent continuity problem. The longer control remained elsewhere, the longer the business’s address, customer traffic and reputation remained exposed to another operator’s choices. A domain theft dispute is therefore not only about title. It is about which side bears the operational loss while institutions decide whose story is true.

Solid Host’s counsel contacted Namecheap on 8 August and asked for the customer’s identity and assistance restoring the domain. The order recounts that Namecheap’s counsel asked for evidence, that Solid Host supplied material including a sworn declaration from its owner, and that Namecheap contacted the customer. The customer reportedly asserted that the domain had been bought legitimately. Solid Host denied any sale. Namecheap then said it would remain neutral and declined to disclose the identity voluntarily.

Neutrality in that setting was not the absence of a decision. It preserved the condition produced by the disputed account move. That may have been defensible as a caution against private adjudication on incomplete evidence. It was still a choice about who retained the benefit of the status quo. When a service has no power to alter that status quo, neutrality may simply describe incapacity. When it can communicate with the customer, preserve logs, impose an account hold, supply information under a lawful process or cooperate with the sponsoring registrar, neutrality describes how those powers will be used or withheld.

The public record does not include Namecheap’s complete internal evidence file. It does not show every document Solid Host supplied, every check performed against account history, or the customer’s full response. It does not establish whether a transfer hold was technically or contractually available before the court acted. It also does not show whether the customer received a meaningful pre-disclosure opportunity to contest the evidence. Those absences are not minor. They prevent a retrospective conclusion that Namecheap should have accepted Solid Host’s account on 8 August.

The institutional criticism is narrower: the available process left the claimant without a reasoned, binding determination and left the reseller and registrar able to occupy separate procedural compartments until a court consolidated them.

Solid Host sought that consolidation through an ex parte application for a temporary restraining order. The court granted relief on 26 August. Its order required eNom to transfer the domain back, told Namecheap to cooperate and required Namecheap to make the transfer if eNom failed. eNom acted the same day. Namecheap supplied the customer identity on 4 September. A stipulated preliminary injunction followed in January 2009. By the time the district court considered Namecheap’s motion to dismiss in May, the immediate continuity crisis had been resolved, but the legal allocation of responsibility had not.

This chronology places the remedies in their proper order. The court first stopped the operational harm by compelling action at the technical control point. Disclosure followed and supported the claimant’s ability to identify the alleged wrongdoer. Solid Host did not, according to the order, amend its complaint to substitute the disclosed person. The public record does not explain why. That choice reinforces the need to avoid treating disclosure as an end in itself. A revealed name can be useful without producing recovery, adjudication or restoration. Accountability requires a path from information to a binding consequence.

Six positions in one control chain

The dispute becomes clearer when the domain ecosystem is treated as a chain of distinct positions rather than a single “registrar” relationship.

Solid Host occupied the position of asserted beneficial owner and historical operator. It claimed a prior entitlement to the name, possessed evidence about its business use and account history, and could seek emergency judicial relief. After the alleged account move, however, it lacked practical control. Its evidence could support a claim; it could not by itself update the domain’s authoritative settings.

The unidentified user occupied the position of immediate beneficial controller. On the allegations, that person controlled the account to which the domain had been moved and could point the name to a different destination. The user also possessed the information needed to explain the transfer as either a purchase or a theft. Yet the public registration record did not display that identity. The privacy arrangement separated practical use from public attribution.

eNom occupied the registry-facing registrar position for this domain. That role carried the most direct technical leverage. A sponsoring registrar can submit changes through the registry channel, maintain the registrar account and implement a court-ordered transfer. The decisive observed outcome is uncomplicated: when the temporary restraining order issued, eNom restored the domain on the same day. That does not prove eNom had caused or negligently permitted the disputed move. It does show that eNom was the actor able to execute the immediate technical remedy.

Namecheap occupied a more complicated position. The complaint did not allege that it was acting as the accredited registrar for solidhost.com. It alleged that Namecheap’s WhoisGuard service appeared as the registered owner or registrant, licensed the domain’s use to the customer and substituted its own contact details in the public record. Namecheap also knew the customer’s identity, could relay communications, evaluated Solid Host’s evidence and was made a fallback transferor in the court’s order. These capacities did not equal eNom’s registrar control. They did place Namecheap inside the incident-response chain.

WhoisGuard, as described in the pleadings, was not merely a blank screen over a database field. The arrangement allegedly made the service the holder of record while the customer exercised use. That legal form matters because a holder of record can carry contractual responsibilities that do not attach to a simple communications relay. It also matters economically. A service that sells anonymity can attract customers because outsiders cannot immediately connect a domain to the beneficial user.

The same design creates a predictable class of disputes in which the service becomes the only readily identifiable intermediary capable of reaching the user.

ICANN occupied the rule-setting and accreditation position, but not the position of private adjudicator in this incident. Its Registrar Accreditation Agreement set terms between ICANN and accredited registrars and required certain provisions in registrar-customer agreements. That architecture could influence how a proxy holder’s responsibility was written downstream. It did not give Solid Host an automatic private remedy against Namecheap or eNom. The distinction later became explicit in the Ninth Circuit.

The federal court occupied the coercive position. Solid Host could participate in the private notice process by sending declarations and arguments. Namecheap could review them and relay them. eNom could possess technical capability. None of those facts alone created an enforceable result for the claimant. The court combined legal authority with a specified remedy and named the actors obliged to implement it. It converted a contested allegation into a temporary command without finally deciding the merits.

These six positions—asserted owner, beneficial controller, sponsoring registrar, displayed registrant and identity custodian, accreditation rule-maker, and court—show why generic language about “the provider” obscures responsibility. Each actor held a different object of control: evidence, account access, registry commands, identity data, contractual standards or legal compulsion. The case’s central institutional problem arose because those objects did not line up with a single decision process.

Why the displayed registrant position mattered

Public registration data did not reveal the beneficial user, but it did identify a responsible-facing entity. That is the point of tension. A privacy service may describe its public details as a shield against spam, harassment or unwanted exposure. To an outside claimant, however, the displayed registrant is also the address at which notice lands. The service benefits from being trusted as the substitute face of the registration. It cannot make that substitution meaningful for privacy and meaningless for accountability at the same time.

That proposition does not imply that the displayed name is the beneficial owner for every legal purpose. Proxy and privacy arrangements deliberately divide those concepts. Nor does it imply that the service must resolve contested ownership from a claimant’s affidavit. It means, as an institutional design choice, that the displayed position should carry defined procedural responsibilities: receive and route notice, preserve relevant evidence, reach the customer, identify the correct technical decision-maker, avoid facilitating onward transfer while a credible theft claim is assessed, and explain what threshold governs further action.

The May 2009 order did not itself establish that full list as a legal duty.

The district court’s analysis turned in part on this functional distinction. Namecheap invoked the ACPA’s protections for registrars and other registration authorities. The court accepted that Congress had limited liability for ordinary registration and maintenance functions. It did not accept a blanket immunity for every service an accredited registrar might provide. The order treated eNom as the registrar for the domain and Namecheap as an anonymity provider alleged to have become the registrant of record. The legal question therefore depended on the capacity in which Namecheap acted, not merely on whether Namecheap held accreditation somewhere in its business.

This capacity-based approach is institutionally important. Large intermediaries often operate through several legal roles at once: registrar, reseller, hosting provider, privacy service, marketplace, payment processor or abuse contact. Liability and remedial power can change with the role. A rule that follows the corporate label lets an organisation import immunity from one function into another. A rule that follows the act asks what the organisation controlled in the disputed transaction.

The contemporaneous Finnegan analysis identified this as the novel feature of the ruling: the court did not extend registrar protection automatically to conduct beyond basic registration, and it entertained contributory liability where the provider allegedly exercised unusual control. That account is useful as a contemporaneous reading, but the primary limit remains the order itself. The court was deciding whether pleaded theories could continue, not announcing a final rule that privacy services are liable whenever their customers are accused.

The practical difference between a privacy contact and a proxy registrant should also be kept in view. A relay that publishes alternate contact details but leaves the customer as legal registrant may hold less formal authority than an entity that becomes the holder of record and licenses use back. The 2008 pleadings alleged the latter arrangement. That allegation was essential to the attempt to attach responsibility. Present provider structures may allocate the roles differently, and present descriptions cannot be projected backward as proof of the 2008 contract.

What the May 2009 order actually decided

The district court’s 19 May 2009 order denied Namecheap’s motion to dismiss, but its reasoning did not validate every theory Solid Host advanced. It separated direct statutory liability, contributory liability and contract. Each route had a different legal object and a different weakness.

Direct ACPA liability failed at the pleading stage

As the district court set out the statutory test, the Anti-cybersquatting Consumer Protection Act imposes direct liability on a person who, with a bad-faith intent to profit from another’s mark, registers, traffics in or uses a domain name that is identical or confusingly similar to the protected mark. Solid Host alleged that the unidentified user had taken the name and sought payment. It also tried to impose direct liability on Namecheap.

The court rejected that direct theory because the required intent is not generic bad faith. It is a bad-faith intent to profit from the goodwill of the mark. The complaint alleged that Namecheap earned money from its anonymity service and had refused to disclose the customer. It did not adequately allege that Namecheap intended to exploit Solid Host’s mark or to profit from the mark’s goodwill. A service fee for privacy was not enough. This distinction prevents a provider’s commercial relationship with an alleged wrongdoer from being treated automatically as the provider’s own cybersquatting.

The failed direct claim matters because it marks the limit of role aggregation. Appearing as registrant and holding identity data did not make Namecheap the alleged thief. Direct ACPA liability still required Namecheap’s own mark-specific intent. Institutional proximity to an abuse event is not the same as substantive participation in the underlying wrong.

Contributory cybersquatting survived, provisionally

Solid Host’s more ambitious theory was contributory cybersquatting. The statute did not expressly state such a cause of action. The district court nevertheless drew on contributory trademark principles and asked whether Namecheap had knowledge of the alleged violation and sufficient control over the instrumentality used to commit it.

The order treated control as more than the bare ability to register a name. On the allegations, Namecheap was the listed registrant, could monitor the customer relationship, held identifying information and had a role in transferring the domain. The court considered those facts enough to distinguish an ordinary registrar that passively processes names from an intermediary exercising greater control over the challenged instrumentality.

Knowledge was harder. The court did not say that any accusation creates liability or a duty to unmask. A demand from a trademark claimant ordinarily supplies only one side’s position. Providers cannot safely transfer domains whenever a complainant asserts ownership; doing so would expose legitimate registrants to a cheap form of private seizure. The court therefore spoke in terms of exceptional circumstances and sufficient evidence.

It reasoned that a service provider might have a duty to investigate when presented with evidence strong enough to make the alleged violation apparent, with the scope of inquiry constrained by how difficult verification would be.

At the motion-to-dismiss stage, Solid Host’s allegation that it had supplied a sworn declaration and corroborating material was enough to continue. It was not a finding that the evidence actually proved theft, that Namecheap’s investigation was deficient or that the unidentified user’s purchase claim was false. Those questions required a fuller record. The public file identified in the court archive does not supply a final trial adjudication resolving them.

The distinction between notice and knowledge is central. Notice is an input: a message arrived. Knowledge is a legal conclusion about what the recipient understood or should have understood after considering credible evidence. A notice system can be transparent about receiving complaints yet offer no accountable method for converting evidence into a reasoned decision. Solid Host’s theory tried to make the failure to cross that gap legally consequential where the intermediary allegedly had unusual control.

The contract theory survived only through a downstream agreement

Solid Host also relied on language associated with ICANN’s Registrar Accreditation Agreement. The clause quoted by the district court tracks ICANN’s 17 May 2001 RAA, the accreditation agreement in force during the 2008 events. Section 3.7.7 required an accredited registrar to include specified terms in its agreement with each registered name holder. Section 3.7.7.3 addressed a holder that licensed use of a name to another person: the holder remained the registered holder of record and accepted liability for harm caused by wrongful use unless it promptly disclosed the licensee’s identity to a party providing reasonable evidence of actionable harm.

The clause’s architecture matters more than the loose proposition that ICANN “required disclosure.” It required the registrar to place language in a downstream registration agreement. The 2001 text referred to the licensee’s identity; a later RAA added current contact information. The district court analysed the earlier formulation and the alleged eNom–Namecheap agreement, not a general power for any claimant to compel disclosure directly from the accreditation contract.

Solid Host first tried to treat the RAA itself as a contract enforceable by injured third parties. The court rejected that route. Section 5.10 of the 2001 RAA denied third-party-beneficiary rights under the accreditation agreement. The licensing provision was also nested inside a requirement that the registrar place terms in a separate registration agreement. It was not, by itself, a promise from ICANN or the registrar to every potential claimant.

The court nevertheless allowed a narrower contract theory to survive. Solid Host alleged that the separate agreement between eNom and Namecheap incorporated the licensing-and-disclosure provision and that people harmed by a customer’s wrongful use were intended beneficiaries of that promise. That downstream agreement was not before the court on the motion. Taking the allegations as true, the judge found it premature to dismiss the possibility that Solid Host could enforce the separate contractual term.

This was not a final holding that Solid Host was a third-party beneficiary. The relevant contract had not been examined, its integration and intent had not been established, and no final judgment resolved the issue. The difference is decisive: the RAA could require a registrar to write a term into another contract without giving an outsider a cause of action under the RAA. Any private remedy depended on the language and intended beneficiaries of the downstream agreement.

The state-law claim followed the surviving theories

Solid Host’s unfair-competition claim under California law survived because the complaint still alleged unlawful conduct through the contributory and contract theories. It did not create an independent factual finding. Its viability was derivative at that stage. The district court’s overall denial of the motion therefore meant that litigation could continue, not that Namecheap had been adjudged responsible for the alleged hijack.

The May order is best understood as a map of possible responsibility under uncertain facts. Direct ACPA liability required Namecheap’s own bad-faith intent and failed. Contributory liability depended on control plus knowledge and survived provisionally. Contract liability could not arise from the RAA as a private right, but might arise from a separate agreement. The court left those latter routes open long enough for evidence to matter.

The Ninth Circuit narrowed the surviving routes

Two later Ninth Circuit decisions changed how much of the district court’s reasoning could be carried forward. One constrained private reliance on the RAA’s disclosure language. The other rejected contributory cybersquatting under the ACPA altogether.

Balsam: contract language without a private RAA remedy

In Balsam v. Tucows, the claimant had obtained a $1.125 million default judgment against Angeles Technology after alleging receipt of 1,125 unlawful commercial emails, but he could not collect. The public registration database had initially identified Angeles; after Angeles apparently opted into Tucows’s Contact Privacy feature, Balsam said he could no longer locate Angeles or identify the operator behind the domain. He demanded that Tucows disclose the operator or pay the judgment and argued that he could enforce the RAA’s licensing provision as a third-party beneficiary.

The Ninth Circuit affirmed dismissal. It read the RAA as a whole: Section 3.7.7 required the registrar to put certain provisions into a separate agreement with the registrant, while Section 5.10 denied third-party-beneficiary rights under the RAA itself. The licensing clause therefore did not create a free-standing promise enforceable by every person claiming actionable harm.

The appellate court’s treatment did not erase the distinction drawn in Solid Host. It reinforced it. The direct RAA theory failed; a claim based on a separate registrar–registrant or registrar–reseller agreement would have to stand on that agreement’s own language and governing law. In Solid Host, the downstream contract was alleged but absent from the motion record. The research gap remains: the public decisional record does not supply a final adjudication that Solid Host was an intended beneficiary of that agreement.

Balsam demonstrates the difference between a formal rule and an enforceable remedy. A contract can contain language that appears to allocate responsibility for wrongful use. ICANN can require registrars to include that language downstream. Neither fact gives an outsider standing to sue under the accreditation agreement when the same instrument denies third-party rights. Transparency about the rule does not answer who may invoke it, in which forum, against which party and for what relief.

Petronas: no contributory-cybersquatting cause of action under the ACPA

The doctrinal blow to the contributory theory came in Petronas v. GoDaddy.com. The case reached the Ninth Circuit after summary judgment and limited discovery concerning GoDaddy’s domain-forwarding service. Petronas appealed only the contributory-cybersquatting issue.

The Ninth Circuit held that the ACPA did not create a cause of action for contributory cybersquatting. It reasoned that Congress had enacted a distinct statutory cause of action with specified elements and had not added secondary liability. The court declined to derive an “exceptional circumstances” test from traditional trademark doctrine. It also warned that requiring neutral service providers to infer a customer’s subjective bad-faith intent from competing claims would create false positives and pressure intermediaries to disable lawful registrations.

The opinion cited the Solid Host line of district-court reasoning and rejected it as a basis for ACPA liability. In the Ninth Circuit, the May 2009 contributory theory therefore no longer supplies a viable ACPA cause of action. That later holding should not be rewritten backward into the district court’s procedural posture: in May 2009, the district judge allowed the theory to proceed under then-unsettled law. By December 2013, the circuit had said the statute did not authorise it.

Petronas was also narrower than a general immunity judgment. It did not hold that registrars, resellers or privacy services can never face direct ACPA liability, ordinary trademark claims, contract claims, state-law claims or duties created by a court order. It held that the ACPA itself did not support contributory cybersquatting. Its procedural setting—an appeal from summary judgment involving forwarding services—also differed from Solid Host’s motion-to-dismiss dispute over a proxy registrant and alleged theft notice.

Together, Balsam and Petronas leave a more confined institutional lesson. The RAA’s disclosure language is not a private cause of action. The ACPA does not supply contributory liability in the Ninth Circuit. Responsibility must therefore be located elsewhere: in a provider’s own direct conduct and intent, a separately enforceable contract, another applicable legal claim, a registrar policy that creates a usable process, or an order from a competent court. The fact that an intermediary occupies the control chain remains operationally important even when the broadest legal theories fail.

WHOIS legibility was not accountability

The public registration record performed one useful function in August 2008: it gave Solid Host a visible entity to contact. That was legibility. It did not reveal the person exercising beneficial control, establish whether the transfer was authorised, compel the provider to preserve evidence, or create a right to restoration.

The distinction matters beyond this case because debates about public registration data often collapse several purposes into one. Publication can make a domain’s formal contact visible. Accuracy rules can require data to be maintained. Relay systems can let outsiders send messages. Disclosure mechanisms can reveal non-public data under stated conditions. None of those mechanisms, standing alone, decides a contested entitlement or guarantees a remedy.

In Solid Host, the displayed record may even have increased institutional dependence on the intermediary. Because WhoisGuard allegedly appeared as holder of record, outsiders could not bypass it to reach the customer. The service became the gate through which notice, identity and possibly transfer cooperation had to pass. That gatekeeping role created leverage but not necessarily a legally enforceable duty to use it in Solid Host’s preferred way.

The court order supplied what WHOIS did not: authority, a named implementer and a specific operational command. It told eNom to restore the domain, required Namecheap’s cooperation and created a fallback. The order also bounded the relief. It did not finally adjudicate damages or declare the alleged theft proved. Judicial review was effective here because it produced an enforceable interim remedy at the control point, not merely because a judge could inspect the provider’s process.

The case therefore separates four institutional concepts. Participation meant Solid Host could submit evidence and Namecheap could contact its customer. Transparency meant the public record showed a proxy and the court later described the parties’ positions. Accountability required a decision-maker to give reasons and bear responsibility for the result. Remedy meant an actor with authority could change the domain’s technical state. Only the last stopped the immediate continuity loss.

A present policy comparator, not a reconstruction of 2008

Current provider documents show how Namecheap, Inc. now describes its process, but they cannot establish what happened internally in 2008. Namecheap’s court-order and subpoena policy, last revised 23 April 2026 and reviewed for this article on 31 July 2026, says the company generally does not release customer or account information except in limited circumstances or when required by applicable law and properly served process. It says Namecheap may assess service, request supporting documents, notify customers in some circumstances and challenge a demand. It also disclaims the creation of third-party rights.

The same policy says requests for non-public registrant information are evaluated under applicable ICANN, registry and privacy-law requirements. It describes “Withheld for Privacy” as a separate Icelandic provider that is not given Namecheap customer or registrant information and does not control the domain, its content or associated services; the policy directs requests to Namecheap. Namecheap also states that, except in special circumstances at its discretion, it will not decide third-party ownership disputes and regards a competent court as the proper forum.

The current domain-privacy documentation says eligible customers receive anonymised public contact details and a unique email address through which messages can be filtered and forwarded. It identifies Withheld for Privacy as the service provider. These are the provider’s present descriptions, not an independent audit and not evidence of the 2008 WhoisGuard arrangement.

The comparison is nevertheless revealing. The 2008 complaint alleged that the privacy service itself became the registered holder, knew the customer and could participate in restoration. The 2026 policy description separates the public privacy provider from customer-data custody and domain control. That design can clarify which entity should receive legal process, but it can also lengthen the path a claimant must follow. Responsibility has not disappeared; it has been distributed.

A distributed model works only when the hand-offs are explicit. The public-facing service must reliably route notices. The reseller must preserve customer and account evidence. The sponsoring registrar must be able to impose holds and execute orders. Each actor must know who owns the incident, and the customer must receive a fair opportunity to respond where notice would not create further harm. Otherwise, separation becomes a method of procedural deflection: each entity truthfully says that another one holds the missing capability, while no single decision binds the chain.

Current policy also illustrates the limits of access. A claimant can submit a request and supporting documents. A company can review them. A court can issue process. None of those steps guarantees disclosure. The provider retains legal objections; the customer may contest; privacy law may restrict release. That is appropriate for legitimate users whose identities could expose them to retaliation or fraud. It reinforces the need to distinguish a right to ask from a right to receive and a disclosure decision from a restoration decision.

A theft-notice protocol built around reversible control

The counterfactual for Solid Host is not a rule requiring immediate transfer whenever a complainant files a declaration. Such a rule would turn privacy and registrar systems into private repossession services. The better counterfactual is a time-stamped process that preserves options while evidence is freshest and makes the reseller and sponsoring registrar answer through one incident record.

1. Start the clock and preserve the record. A claimant alleging account takeover should receive an incident identifier and a precise list of required information. At the same moment, the reseller and sponsoring registrar should preserve authentication logs, account-move records, registrar transfer records, DNS and nameserver changes, contact-data changes, billing events, support messages, IP-session data, two-factor-authentication events and relevant customer communications. Preservation should occur before the merits are decided. Lost logs are an irreversible failure; retaining them temporarily is usually reversible and reviewable.

2. Authenticate the claimant without treating authentication as ownership. The provider should test access to historical email addresses, billing records, prior support tickets, registry history and other account artefacts. Passing those checks establishes that the claimant has a relationship to the prior account. It does not conclusively prove that no sale or authorised transfer occurred. The distinction keeps identity verification from becoming a silent title judgment.

3. Relay the notice and create a short answer window. The current controller should receive the allegation and a protected summary of the evidence, with a short period to supply a purchase agreement, payment trail, authorisation or other explanation. Notice can be delayed where there is a credible risk of evidence destruction or onward transfer, but that exception should be documented. The public record in Solid Host does not show the full answer opportunity the customer received; a protocol should make that step auditable.

4. Impose a narrow no-transfer hold. Where objective indicators support possible account takeover—a recent credential reset followed by an internal account move, abrupt nameserver changes, inconsistent billing, a resale demand or a mismatch with historical contacts—the registrar should prevent further registrar or account transfers for a short, defined period. The hold should not hand the domain to the complainant or necessarily alter the existing DNS. Its purpose is to stop dissipation while preserving the contested state. It should expire unless renewed by a reasoned decision or legal order.

5. Produce one reasoned decision across the reseller–registrar boundary. A designated incident lead should gather the evidence once and issue a written outcome binding both the reseller and sponsoring registrar: restore, maintain the hold pending adjudication, release the hold, or seek additional evidence. The decision should state which facts were accepted, which remained disputed, what contractual or policy threshold applied and what review route exists. Separate organisations may retain separate legal identities, but a customer or claimant should not receive incompatible answers about the same control event.

6. Separate protected identity disclosure from technical restoration. Identity may be disclosed to verified counsel, a court, an agreed neutral or another protected recipient when the applicable threshold is met. Public disclosure should not be the default. Restoration should be decided on evidence about control and entitlement, not on whether the claimant has learned the customer’s name. Solid Host demonstrates why the two tracks must remain separate: eNom restored the domain on 26 August; Namecheap disclosed the identity on 4 September.

7. Escalate irreversible steps to an authority able to bind the chain. A permanent transfer and an identity disclosure can both cause harms that cannot be fully undone. When the evidence remains genuinely contested, the protocol should preserve the domain and the logs while directing the parties to a court or agreed adjudicator. Emergency orders should identify the sponsoring registrar, reseller, privacy provider and any registry actor necessary for implementation. The Solid Host order was effective because it named eNom as the first implementer, required Namecheap’s cooperation and supplied a fallback.

8. Close with an audit trail and limited review. The incident file should record timestamps, evidence received, customer notices, holds, decisions, disclosures and implementation. Review should test whether the stated policy was followed, whether relevant evidence was ignored, and whether the remedy matched the decision. Review should not become an indefinite suspension that leaves the domain unusable. Continuity requires deadlines as much as procedural fairness requires reasons.

This protocol assigns duties to capabilities. The public-facing proxy receives and relays. The identity custodian preserves and, where authorised, discloses. The sponsoring registrar freezes or restores. A neutral authority decides hard entitlement disputes. A single incident lead prevents the chain from fragmenting. No actor is made responsible merely because it is nearby; each is responsible for the object it controls.

The economics support that allocation. Privacy services and resellers can lower registration friction and earn revenue from volume. Theft investigations are costly, irregular and adversarial. Without a binding process, each provider has an incentive to minimise its own investigation and refer the complainant elsewhere, while the claimant bears the cost of locating the correct party and obtaining an order. A time-stamped protocol internalises some of that cost into the service design that creates the opacity. It also protects legitimate customers by replacing improvised disclosure with defined thresholds and a reviewable record.

What the record cannot establish

The limits of the public record are part of the case, not an inconvenience to be smoothed over. The district court recounted allegations for purposes of a motion to dismiss. It did not make a final trial finding that the 4 August account move occurred exactly as pleaded, that the unidentified person lacked a valid purchase, or that Namecheap knowingly assisted cybersquatting.

The record available through the Central District of California archive does not reveal Namecheap’s complete internal evidence file, the precise technical logs available in August 2008, or the customer’s full pre-disclosure opportunity to answer. It does not explain why Solid Host did not substitute the disclosed person as a defendant. It does not provide a final judgment on the alleged eNom–Namecheap contract or establish that Solid Host was an intended third-party beneficiary.

Those gaps prevent a verdict about the providers’ ultimate liability. They do not prevent analysis of the control chain. The observed facts are narrower and firmer: the court issued an emergency order; eNom restored control the same day; Namecheap disclosed identity later; the district court treated Namecheap’s alleged proxy role as legally distinct from eNom’s registrar role; and later appellate decisions foreclosed the broad RAA and contributory-ACPA paths.

The bounded conclusion is therefore institutional. A privacy intermediary does not acquire a general duty to expose customers merely because a claimant sends sworn notice. But when the intermediary appears as registrant, holds the beneficial user’s identity, evaluates the evidence and can cooperate in restoring the name, it has entered the control chain. Its duties should follow those powers: preserve, relay, hold where justified, decide with reasons, disclose through a protected route when authorised, and coordinate with the sponsoring registrar.

The upstream registrar cannot absorb every responsibility simply because it executes the registry command. Nor can the privacy provider disclaim every responsibility simply because it does not.