Is Your Domain Truly Secure? My Experience Raises Serious Questions.

SpaceshipSpaceship
Watch

wongtaichiew

Established Member
Impact
0
After nearly 10 years of ownership, my domain malaysia.build was removed without my consent. In my experience, the registrar and the registry have provided contradictory reasons, leaving me with no clear answers. This isn't just about a domain loss; it’s a personal account of navigating a system where clear communication was lacking.

I’ve put all the details online to create a public record. To see the full story and evidence, please search on Google for "malaysia.build domain loss".

I need advice from the community. Thanks.
 
Last edited:
0
•••
The views expressed on this page by users and staff are their own, not those of NamePros.
GoDaddyGoDaddy
This is a pretty simple one.

It should not have been registered to you in the first place.

In all of the new TLDs, country names are required by ICANN to be reserved and unregistrable. The name should have been blocked from registration.

Sometimes, mistakes have happened with implementation of this policy, and names have indeed been accidentally registered.

It's nobody's specific job to make sure that policy is followed, but once in a while it will show up when ICANN audits a registry. When that happens, they require the name to be de-registered and put back on reserved status.

Here is the link to the ICANN policy which explains that you should not have been able to register the name in the first place:

https://www.icann.org/en/contracted...es/reserved-names/country-and-territory-names

Specification 5, Section 4 of the New gTLD Registry Agreement requires reservation of the country and territory names (including their IDN variants, where applicable) contained in the following internationally recognized lists. The links below are provided for reference and are not intended to alter the identified lists. Registry operators must reserve the names from the lists below and refer to the instructions on this webpage for the release of any country or territory name at the second-level.


  1. The short form (in English) of all country and territory names contained on the ISO 3166-1 list, as updated from time to time, including the European Union, which is exceptionally reserved on the ISO3166-1 list, and its scope extended in August 1999 to any application needing to represent the name European Union: http://www.iso.org/iso/iso-3166-1_decoding_table.html; https://www.iso.org/obp/ui/
  2. The United Nations Group of Experts on Geographical Names, Technical Reference Manual for the Standardization of Geographical Names, Part III Names of Countries of the World: http://unstats.un.org/unsd/geoinfo/UNGEGN/docs/pubs/UNGEGN tech ref manual_m87_combined.pdf [PDF, 3.5 MB]
  3. The list of United Nations member states in 6 official United Nations languages prepared by the Working Group on Country Names of the United Nations Conference on the Standardization of Geographical Names: http://unstats.un.org/unsd/geoinfo/UNGEGN/docs/10th-uncsgn-docs/econf/E_CONF.101_25_UNGEGN WG Country Names Document.pdf [PDF, 925 KB]

Is "Malaysia" on the list? Yes it is:

Screenshot 2025-09-12 at 12.32.19 PM.png



That's what happened. There is absolutely no way on earth you are going to get this domain name restored to you.

On your site, you mention:

According to Namecheap’s response, malaysia.build was described as being in a ‘reserved’ status by the .BUILD Registry (June 21, 2025).

Enom’s email conveyed that the removal was attributed to an ICANN request


You then go on to characterize these as 'conflicting accounts'. No, they are the same thing. The ICANN Spec 5 policy requires the name to be reserved.

In fact, this was explained to you in the emails you posted to your site:

https://loss.co/complete-email-trail/#7141049

This email is to inform you that we have been requested by ICANN to remove / Block the domain malaysia.build from registration due to it violating Spec 5 of our Registry agreement.

The registry told you exactly why this name was removed and put back on reserved status, where it should have been in the first place.

The problem is that you did not understand the explanation, and did not look up Specification 5 of the registry agreement.

If you remain confused, please look at the link above to the ICANN Specification 5 "country name" policy, which is required to be implemented by all new gTLD registries - including .build.

Pursuing this matter will be a waste of time, because the ICANN policy will not allow the .build registry to restore this domain name to you without the express consent of the government of Malaysia.

As an experiment, try this:

1. Pick any of the hundreds of new gTLDs.

2. Check if "Malaysia" is registered in it.

3. Go and try to register Malaysia in that new gTLD.

What you will find out is that (a) the name is not registered, and (b) you cannot register it. Someone at ICANN noticed that Malaysia .build had been registered, informed the registry, and the registry put it back on unregistrable/reserved status.
 
Last edited:
44
•••
Screenshot 2025-09-12 at 12.47.02 PM.png


Screenshot 2025-09-12 at 12.47.08 PM.png

Screenshot 2025-09-12 at 12.48.19 PM.png


Screenshot 2025-09-12 at 12.48.40 PM.png
 
5
•••
Here's one from 2017:

https://www.namepros.com/threads/unitedkingdom-science-deleted.1011202/

Yesterday namecheap send me mail and said me that they deleted unitedkingdom.science from my account, because ''During a recent compliance review, the domain name was identified as domain name which is prohibited from being registered by ICANN, pursuant to paragraphs 4 and 5 of Specification 5 of the Registry Agreement.''
 
Last edited:
7
•••
Hello,

Thank you for the detailed and well-researched reply, and for providing the link to the ICANN policies. I appreciate you clarifying the technical basis for the "reserved names" rule. When I successfully registered malaysia.build in 2014, I totally didn't know that, the domain malaysia.build should have been reserved. I am just a regular registrant. Should I know all about how the domain system being operated?

However, my complaint is not about the existence of the policy, but about the flawed and non-transparent process by which it was enforced.

My primary concern is the direct contradiction in the accounts I've received. You mention that the registry's explanation is the same as ICANN's policy, but it is not. The registry (the .Build registry)'s email to upstream provider (eNom) stated: "We have been requested by ICANN to remove / Block the domain..." This implies a specific instruction from ICANN.

On email dated 13 August 2025, ICANN Contractual Compliance informed me:

“Beyond the terms and exceptions explicitly provided by the RA and ICANN Consensus Policies, the ICANN organization has no contractual authority to instruct a registry operator to release a reserved name.”

On email dated 10 September 2025, ICANN Contractual Compliance further stated:

“ICANN Contractual Compliance has no authority, contractual or otherwise, to serve as an appellate body or otherwise exempt Registry Operators from compliance with certain requirements.”

Contradiction:

These statements cannot all be correct. Either:

a) ICANN did instruct the registry → which exceeds the contractual authority ICANN described,

or

b) ICANN did not instruct the registry → in which case the registry misrepresented ICANN’s authority in registrar communications.

Now, can you see the problem?

My issue is that a decade-old domain was removed based on what appears to be a direct request, without any notification or communication to me, the registrant.

Furthermore, my case highlights a failure of oversight. If this policy was so critical, why was the domain allowed to be registered, renewed, and actively used for nearly ten years? This incident, in my experience, is an example of a registrant being penalized for a procedural error made by the contracted parties.

The lack of any notice or due process is the core of my issue. A decade of good-faith ownership, investment, and development was simply erased.

The circumstances of this removal are critical:

  1. Nearly a Decade of Ownership: I registered malaysia.build and maintained active control of the domain for almost ten years, with continuous development and investment throughout that period.
  2. Active and Paid: Auto-renewal enabled. The domain was fully paid for and valid through April 29, 2024, meaning it still had nearly 5 months (the domain was removed from my namecheap account on Dec 05 2023) before it reached its expiry date, clearly indicating my intent for continuous ownership.
  3. No EPP Code (per registrar records): Namecheap confirmed in writing (Date: Mon, Jul 14, 2025 at 3:20 PM): “No, according to our logs, the EPP code was not requested.” Under ICANN Transfer Policy §2.1.1, an EPP code is normally part of the transfer process. From my perspective, I was not able to identify evidence that this step occurred in my case
  4. No Prior Notice (from my perspective): I first learned of the domain transfer after it had already occurred. To the best of my knowledge, I did not receive advance notification from Namecheap, Enom (upstream provider), or the .BUILD Registry about any impending action, such as a restriction, policy violation, or reservation status.
My purpose is not just to get the domain back, but to raise awareness about the systemic lack of accountability in the domain ecosystem. The full story is much more complex than a simple policy violation.

Thank you to everyone who has read and replied to my post. Your insight and perspectives are greatly appreciated.

I encourage any and all feedback, whether it's a counter-argument or a shared experience. Please feel free to contribute to the discussion.
 
Last edited:
0
•••
Dear John,

I reread your points, especially the part about the country-name experiment, and I'd like to offer a counter-argument that I believe is crucial. Thank you for bringing up that part.

While most country-name domains are reserved and unregistrable, the evidence suggests that the enforcement of this policy is not uniform.

Evidence:

Country-name domains such as peru.travel and greece.travel continue to operate. This can be verified by visiting the domain names or checking their historical Whois data.

Relevance:

The apparent differences in enforcement raise significant questions about the uniform treatment of registrants across new gTLDs that are subject to the same agreements.

My Questions:

  1. If domains like peru.travel and greece.travel remain active, why was malaysia.build treated differently?
  2. Could perceived differences in enforcement across new gTLDs be a cause for concern regarding fairness and equal treatment?

Other domain extensions that allow for the use of country names include:

germany.info
spain.info
brazil.org
france.org
australia.org
japan.org
canada.com
russia.com
india.com
argentina.com
brazil.net

Thank you to everyone who has read and replied to my post. Your insight and perspectives are greatly appreciated.
 
0
•••
1. The reservation rule does not apply to TLDs before the 2014 round. Yes, there are plenty of country names in the older TLDs.

2. Country names CAN be released in 2014 round TLDs if certain conditions are met.

But, more importantly, you are misreading what ICANN compliance said.

ICANN said they do not have the authority to instruct a registrar to RELEASE a reserved name. You were telling ICANN you wanted the name back. ICANN was telling you they cannot tell the registry to give you the name back.

ICANN does have the ability to tell the registry it needs to de-register and reserve a required reserved name. In fact, you were told that ICANN had instructed the registry to put the name on reserve.

That is not at all inconsistent with the fact that ICANN told you they cannot instruct the registry to RELEASE the name to you.

You don’t seem to understand that ICANN was telling you they cannot EXEMPT the registry from the rule. That doesn’t mean they cannot affirmatively endorse the rule.

And there is nothing in the registry-ICANN contract that has anything to do with the length of time they have been out of compliance with the rule.

what is it you believe would get you the name back? Suing the registry and ICANN? They don’t owe you anything.
 
3
•••
what is it you believe would get you the name back? Suing the registry and ICANN? They don’t owe you anything.
I don't think there is any way the registrant will get the domain back, but there is an interesting question about what losses the OP incurs as a result of registry or registrar errors leading them to build on a domain that is later taken back.

In losing a domain you can lose associated email addresses, links to site stop working, business may suffer loss of traffic and reputation, loss of any goodwill or recognition built up in a brand.

I recall reading of a case in the UK where a builder built the house on the wrong plot of land - turns out the landowner was able to keep the house at no cost.

Godaddy and probably most other registrars have stuff in their ToS allowing them to cancel a domain at any time for any reason or no reason at all. Interesting point for comparison if anyone cares to look into it, or maybe someone already has on here?
 
2
•••
Dear John,

Thank you for the detailed and thoughtful reply, I appreciate you taking the time to share your perspective.

You asked me to try a very compelling experiment: to try to register a country name in any new gTLD, and you stated that it would be impossible due to the reservation rule. I accept that this is generally true.

However, when presented with evidence that contradicts this—domains like peru.travel and greece.travel—you changed your argument to state that the rule "does not apply to TLDs before the 2014 round." This is a significant contradiction. You cannot argue that the rule is absolute and then, when faced with evidence to the contrary, claim that it has exceptions. This highlights the very inconsistency in the system that I am concerned about.

Allocation Contradicts Reserved Status

Your reply also touches on a core question I have asked ICANN to answer: how could a domain that was supposedly "always reserved" be lawfully allocated in 2014 and continuously used for nearly a decade? A 3,287-day enforcement delay contradicts ICANN’s principles of predictability and raises fundamental questions:
  1. Was the name on the Reserved Names List in 2014? If so, why was it allocated? If not, why is enforcement applied retroactively?
  2. Does a nearly decade-long delay constitute a waiver of enforcement rights?
I have very solid proof to back up everything I have said in my correspondence.

Responsibility for Losses

You stated in your reply, "what is it you believe would get you the name back? Suing the registry and ICANN? They don’t owe you anything."

While my primary goal is not a financial settlement, I believe all parties involved are responsible for the losses incurred. Based on my extensive documentation, I hold the following parties accountable for the unauthorized removal of my domain name, malaysia.build.

  1. The .BUILD Registry: For the initial failure to reserve the domain in 2014 and for its subsequent, unannounced removal in 2023.
  2. Enom (Upstream Provider): For its role in the transfer process and for its communication stating the domain was removed by the registry.
  3. Namecheap (Registrar): For the failure to provide proper notice and due process, as well as the documented trail of deflection.
  4. ICANN: For its failure of oversight, allowing the domain to be registered and active for nearly a decade, and for the conflicting and non-transparent communications regarding the reason for the deletion.
The costs and damages associated with this loss include:
  1. Domain Name Valuation
  2. Platform Development Costs: The malaysia.build domain was the cornerstone of a fully functioning and monetizable real estate platform, not a dormant asset. I have video proof showing all features of the platform, which was developed over 30 months, are functional. You can see a live demo of the project at malaysia.sibu.design
  3. Lost Profit
  4. Business Disruption
  5. Reputational Damage
  6. Strategic Market Position Loss
  7. Marketing & Branding Loss
  8. Dispute Resolution Cost
  9. Potential Punitive Damages
The case remains open, and I will share any new developments as they come. Thank you all for your continued support.
 
0
•••
That's tough, man.

Clear, consistent communication between registrar, registry, and registrant should always be the standard.🤝
 
0
•••
Thank you, John, Carob and Nicenic, for your contributions to this discussion. Your replies mean a lot to me and help me feel like I’m not alone in this.

The lack of clear, consistent responses and the silence from all parties—Namecheap, Enom, and the .BUILD Registry—have left me with no clear path forward. Despite my consistent follow-ups and clear requests, the information I've received contains contradictions and does not provide the accountability I am seeking.

Responses From Namecheap, Enom, And The .BUILD Registry​


Namecheap’s Responses Often Referred Questions to Third Parties

Despite multiple follow-ups over the course of more than a month, Namecheap provided only one clear answer: the EPP code was not requested. All other questions were met with vague responses, repeatedly referring inquiries to the upstream provider or the Registry. From my perspective, I did not observe escalation or any clear acceptance of responsibility in the responses I received.

Namecheap’s Reply on Key Questions (Date: Mon, Jul 14, 2025 at 3:20 PM)

From: Namecheap Domains Support Team Date: Mon, Jul 14, 2025 at 3:20 PM To: [My Email Address]

Hello,

Thank you for getting back to us.

What exactly happened to the domain? > Unfortunately, it seems that the domain was transferred from your account. At this point, we cannot specify what exactly happened, we are waiting for the reply from the Registry and our upstream provider.

Was it transferred — and if so, by whom?
> Most likely, it was transferred. However, we cannot tell who initiated the transfer. Only Registry operates the domain names and can check the history, status, including past and present ownership details and changes over time. That is why we are waiting for their reply.

Was an EPP code issued or used?
> No, according to our logs, the EPP code was not requested.

On what authority was the domain placed in “reserved” status at the registry?
> We are clarifying this point with the Registry. Once we have any news from them, we will address this question.

What concrete actions has Namecheap taken internally to investigate or escalate this, beyond contacting the registry and upstream provider? > We have checked our logs and correspondence with the Registry. Unfortunately, we received no notices from the Registry. So, we are waiting for their clarifications.

If this delay continues indefinitely, and the registry remains unresponsive, what is Namecheap’s plan?
> We are not currently considering this possibility as we expect to receive the updates from the Registry and upstream provider in the foreseeable future. However, as soon as we have some news from them, we will be able to answer this question more specifically.

Will Namecheap formally escalate this matter to ICANN? > We are not considering this option at the moment, because we need information from upstream provider and Registry first and foremost.

At what point does Namecheap accept responsibility as the registrar of record at the time of the incident? > Once we have some news from the Registry and upstream provider, we will understand the picture and then we will be able to clarify who is responsible for this. However, we would like to emphasize that as the Registrar, we do not transfer domains for customers.

Moreover, according to our logs, the EPP code was not requested, so we cannot say what specifically happened, which is why we are waiting for the response from the upstream provider and Registry.

Most importantly, can Namecheap confirm that it will accept full financial responsibility for the losses incurred due to the unauthorized loss of malaysia.build and the prolonged delay in resolving the issue?
> We cannot confirm this without understanding the full situation. We will consider this once we have more information.

Please rest assured that we are constantly monitoring this case. We will provide you with all the details and decisions as soon as we clarify everything with the corresponding Registry.

Your understanding is highly appreciated.

-------

As of today, despite my complaint with ICANN and my communications with Namecheap, I personally have not received what I would consider a clear explanation or resolution regarding the domain’s removal. Namecheap’s own email responses have confirmed that no EPP code was requested, yet they have provided conflicting statements regarding the transfer process, leaving me without what I would consider a clear resolution or understanding of how responsibility was determined in this case.

Here is a timeline of their shifting explanations and lack of action:

Initial Delays (June 12 – July 13, 2025):
  • “Regrettably, we find ourselves in need of additional time to thoroughly review your case.” (Date: Thu, Jun 12, 2025 at 3:01 AM)
  • “We need some more time for additional investigation.” (Date: Fri, Jun 13, 2025 at 3:42 PM)
  • “To our deepest regret, we are still investigating this issue and will update you as soon as possible.” (Date: Tue, Jun 17, 2025 at 5:13 PM)
  • “We are still working on the issue. We are monitoring the case and will contact you as soon as we have any information.” (Date: Thu, Jun 19, 2025 at 3:26 PM)
  • “We are currently in contact with our upstream provider and Registry and waiting for further updates.” (Date: Sat, Jun 21, 2025 at 3:42 PM)
  • “Unfortunately, we do not yet have exact details regarding why the domain was removed. Right now, we are still waiting for updates from our upstream provider and the Registry.” (Date: Thu, Jul 3, 2025 at 4:21 AM)
  • “…we’ll notify you immediately the moment we receive any update.” (Date: Mon, Jul 7, 2025 at 12:52 AM)
  • “To our regret, there are still no updates regarding the domain.” (Date: Fri, Jul 11, 2025 at 11:59 PM)
  • “Unfortunately, a time estimate cannot be provided, but as soon as there are any news we will let you know.” (Date: Sat, Jul 12, 2025 at 2:09 AM)
  • “As soon as we receive any updates or further information from them, we will let you know immediately.” (Date: Sat, Jul 12, 2025 at 2:39 PM)
  • “…but the investigation may take some time. We’ll share any updates or new information with you as soon as we receive it.” (Date: Sat, Jul 12, 2025 at 4:16 PM)
  • “Thus, we are just waiting for the information about the domain status.” (Date: Sun, Jul 13, 2025 at 3:02 AM)
Conflicting Information, Shifting Explanations and Responsibility (July 13 – July 14, 2025):
  • Regarding the transfer: Namecheap stated on July 13, 2025: “Yes, the transfer out was processed from our database on 12/4/2023.” Yet, in the same communication, they admitted, “we cannot clarify who exactly requested/ initiated it. This point is under investigation.” (Date: Sun, Jul 13, 2025 at 3:02 AM) Later, on July 14, 2025, they stated, “No, according to our logs, the EPP code was not requested.” (Date: Mon, Jul 14, 2025 at 3:20 PM)
  • Regarding responsibility: On July 12, 2025, Namecheap replied “We are currently investigating how and why the malaysia.build domain was transfered with our Upstream provider, currently we do not know how the transfer occurred in this case.” (Date: Sat, Jul 12, 2025 at 2:09 AM) On July 13, 2025, Namecheap claimed, “only Registry operates the domain names and can check the history… Thus, we are just waiting for the information about the domain status.” This directed inquiries about domain history and status to the Registry. (Date: Sun, Jul 13, 2025 at 3:02 AM)
  • Inability to Revert: Namecheap confirmed, “It is possible to cancel a domain transfer, but only if it’s still in a pending state. Since the case was processed back in 2023, we cannot revert it.” This highlights their inability to rectify an issue that occurred under their management. (Date: Sun, Jul 13, 2025 at 3:02 AM)
  • Contradiction on EPP: On July 13, 2025, Namecheap stated, “Based on our logs, we have not detected any requests for EPP codes.” This directly conflicts with their previous statement of a “transfer out was processed from our database.” (Date: Sun, Jul 13, 2025 at 4:35 PM)
  • Shifting Accountability: In several responses, Namecheap pointed to its upstream provider (Enom) and the .BUILD Registry as responsible parties, ie, “Please rest assured that as soon as we received your request, we submitted it to our upstream provider. Since then, we’ve been closely monitoring the progress, which, unfortunately, is still pending on their end.” (Date: Mon, Jul 7, 2025 at 12:52 AM) Enom replied once, stating that the registry executed the removal. The .BUILD Registry, although copied in every email, has remained silent to date.
  • Regarding financial/reputational impact: “Regarding the concerns about potential financial and reputational impact, we are actively exploring all available options. However, we first need to receive a response from the registry to determine the appropriate next steps.” (Date: Sun, Jul 13, 2025 at 4:35 PM).
  • Acknowledgment of Losses: On July 13, 2025, Namecheap stated: “Your business means a lot to us. We completely agree that this may cause losses to your company.” This is a direct acknowledgment of the financial impact. (Date: Sun, Jul 13, 2025 at 10:29 PM)
  • Non-Committal on Financial Responsibility: Despite acknowledging potential losses and being directly asked about financial responsibility, Namecheap consistently provided vague and indefinite answers. For instance, on July 14, 2025, when asked “can Namecheap confirm that it will accept full financial responsibility...?“, their reply was, “We cannot confirm this without understanding the full situation. We will consider this once we have more information.” (Date: Mon, Jul 14, 2025 at 3:20 PM). Earlier, on July 14, 2025, they stated, “depending on the final outcome of the ongoing investigation, we will be carefully reviewing all circumstances involved, including those that may warrant further consideration regarding the compensation on our side.” (Date: Mon, Jul 14, 2025 at 1:51 AM). Namecheap consistently stated they could not confirm financial responsibility without more information.
Final Denial & Redirection (July 15, 2025):
  • “The responsible party in this case is the .Build Registry. Only the Registry can provide answers to your questions or determine whether your domain can be restored or re-registered. We recommend reaching out to them directly to pursue this matter further.” (Date: Tue, Jul 15, 2025 at 11:09 AM)
  • “If you have any further questions, please do not hesitate to contact our Legal team directly at Namecheap's legal email address.” (Date: Tue, Jul 15, 2025 at 3:57 PM)
  • “As such, Namecheap was not involved in and is not responsible for the transfer.” — Namecheap Legal Department (Date: Tue, Jul 15, 2025 at 1:51 PM)
  • Premature Closure: On Date: Tue, Jul 15, 2025 at 11:09 AM, Namecheap stated, “This email will be closed now,” ending the thread without any resolution, explanation, or acknowledgment of responsibility.
  • When I challenged “Namecheap was not involved in and is not responsible for the transfer” on Date: Wed, Jul 16, 2025 at 9:40 PM, requesting clarification on how they could disclaim responsibility as the registrar of record, I received no further response. Subsequently, Namecheap has ceased all direct email replies.
To me, Namecheap’s explanations appeared inconsistent at times, as their emails mentioned both a ‘transfer out’ and that no EPP code was requested. According to their internal records, a “transfer out” of the domain occurred, yet they have also stated that they had “no involvement” and that no EPP code was requested. This apparent contradiction raises questions, in my view, about the transfer process and Namecheap’s role and responsibilities as the registrar of record at the time.

I registered and paid for the domain through Namecheap and had no direct relationship with the .BUILD Registry. To my mind as a registrant, I expected that my auto-renewal status would keep the domain secure unless I was directly required to take action. The circumstances surrounding the transfer left me uncertain about how registrar practices are applied in such cases.

The financial impact I’ve experienced is tangible and significant — including development costs, delays to launching the platform, lost business opportunities, and reputational setbacks. These losses arose because I unexpectedly lost access to malaysia.build, even though the domain was fully paid and valid during its active registration period. From my point of view, this sudden loss disrupted a project that had been under development for years and created serious financial consequences.

From my perspective, the combination of delays, limited responses, and silence raised questions for me about how customer service and communication are handled in such situations. Based on the evidence, the domain disappeared under Namecheap’s management as registrar of record.

-------

Direct Communication with Upstream Provider (Enom) Reveals Registry Action

Due to Namecheap’s persistent delays and vague excuses about awaiting answers from their upstream provider (Enom) and the .BUILD Registry, and having struggled with this issue for over a month, I was compelled to contact Enom directly. The reply received from Enom on Mon, Jul 14, 2025 at 10:49 PM provides crucial clarity:

From: Compliance Support Date: Mon, Jul 14, 2025 at 10:49 PM To: [My Email Address]

Hello,

We received the following from the .build Registry regarding this domain (malaysia.build) on December 1, 2023.

“Dear Registar partner,

This email is to inform you that we have been requested by ICANN to remove / Block the domain malaysia.build from registration due to it violating Spec 5 of our Registry agreement. Thank you for your assistance in this matter.

Sincerely, <redacted> Founder / CEO .build <redacted> about.build”

You will need to contact the registry directly for any answers to these questions, as this action was taken by them directly. This is also why we have no record of the transfer, or distribution of an Auth Code for transfer, as the action was performed solely at the Registry level.

Thank You, Enom, a Tucows Company 96 Mowat Avenue Toronto ON M6K 3M1 Canada

-------

The Registry’s Silence: No Answers from .BUILD

Despite Namecheap’s (and subsequently Enom’s) insistence on directing inquiries to the .BUILD Registry, repeated attempts to contact the Registry directly (Date: Wed, Jul 9, 2025 at 8:59 PM), including online form submissions, have yielded no reply to date. This further highlights an important issue, leaving me uncertain about the extent of transparency and communication among the parties involved.

-------

Based on all of this, I've already filed a formal complaint with ICANN on July 11, 2025.

Despite having taken this step, I would greatly appreciate any advice you have on what steps I can take next. What would you do in my situation?

Thank you to everyone who has read and replied to my post. Your insight and perspectives are greatly appreciated.

I don't think there is any way the registrant will get the domain back, but there is an interesting question about what losses the OP incurs as a result of registry or registrar errors leading them to build on a domain that is later taken back.

In losing a domain you can lose associated email addresses, links to site stop working, business may suffer loss of traffic and reputation, loss of any goodwill or recognition built up in a brand.

I recall reading of a case in the UK where a builder built the house on the wrong plot of land - turns out the landowner was able to keep the house at no cost.

Godaddy and probably most other registrars have stuff in their ToS allowing them to cancel a domain at any time for any reason or no reason at all. Interesting point for comparison if anyone cares to look into it, or maybe someone already has on here?

That's tough, man.

Clear, consistent communication between registrar, registry, and registrant should always be the standard.🤝
 
0
•••
Subject: Adding Key Points on the Malaysia.Build Situation

Hi John,

Thank you for your insightful comments. I appreciate your clarity on ICANN’s compliance role.

Again, I must stress that I am just a regular registrant. Am I supposed to know all about how the domain system being operated?

I’d like to add a few key points for consideration:

  1. Ease of Compliance: The ISO 3166-1 country list—including "Malaysia"—is publicly available and easily accessible within seconds. It is difficult to understand how a professional registry, bound by ICANN contract, could fail to correctly implement this basic requirement during the TLD launch.
  2. Accountability for Accepted Revenue: As a lawful registrant, I fulfilled all financial obligations for nearly a decade. All involved parties—the registrar, upstream provider, registry, and even ICANN through its mandatory $0.18 fee per domain year (10 years) —accepted these renewal payments and derived revenue from them. This financial history validated the registration in practice. The subsequent removal, while based on a pre-existing policy, happened without prior notice or offer of compensation for a valuable asset.
The accessibility of this list is such that anyone with internet access can obtain a complete, authoritative country list in seconds through a simple search. While you mentioned that "sometimes mistakes have happened with implementation of this policy," when the necessary information is so readily available to everyone, such a fundamental error should not be deemed an excusable or acceptable "mistake."

This situation created a significant imbalance: the entire burden of a registry's longstanding oversight fell solely on me, the registrant, with no process for recourse. This case highlights a systemic issue where a registrant's good-faith investment is not met with commensurate accountability from the contracted parties.

I believe this underscores the need for better registrant protections and more transparent processes when registry errors cause harm. I welcome your perspective on these aspects.

Best regards,
TC Wong



1. The reservation rule does not apply to TLDs before the 2014 round. Yes, there are plenty of country names in the older TLDs.

2. Country names CAN be released in 2014 round TLDs if certain conditions are met.

But, more importantly, you are misreading what ICANN compliance said.

ICANN said they do not have the authority to instruct a registrar to RELEASE a reserved name. You were telling ICANN you wanted the name back. ICANN was telling you they cannot tell the registry to give you the name back.

ICANN does have the ability to tell the registry it needs to de-register and reserve a required reserved name. In fact, you were told that ICANN had instructed the registry to put the name on reserve.

That is not at all inconsistent with the fact that ICANN told you they cannot instruct the registry to RELEASE the name to you.

You don’t seem to understand that ICANN was telling you they cannot EXEMPT the registry from the rule. That doesn’t mean they cannot affirmatively endorse the rule.

And there is nothing in the registry-ICANN contract that has anything to do with the length of time they have been out of compliance with the rule.

what is it you believe would get you the name back? Suing the registry and ICANN? They don’t owe you anything.
 
0
•••
You asked me to try a very compelling experiment: to try to register a country name in any new gTLD, and you stated that it would be impossible due to the reservation rule. I accept that this is generally true.

However, when presented with evidence that contradicts this—domains like peru.travel and greece.travel—you changed your argument to state that the rule "does not apply to TLDs before the 2014 round." This is a significant contradiction. You cannot argue that the rule is absolute and then, when faced with evidence to the contrary, claim that it has exceptions. This highlights the very inconsistency in the system that I am concerned about.


No. Read what I wrote the first time:

"In all of the new TLDs, country names are required by ICANN to be reserved and unregistrable."

The first time, I said "In all of the new TLDs". You then looked at older TLDs, like .travel, which was part of the limited 2007 round of "sponsored" TLDs. You also then came up with examples in the original gTLDs.

Since you obviously didn't understand what I was saying, or you did not understand that .travel was not part of the new gTLD round, I rephrased it by specifying the 2014 round.

That is not a contradiction. That is simply dealing with the fact that you don't understand when .travel was added to the root.

I was trying to be polite, by re-phrasing the part you didn't understand, since people get upset that I'm not as friendly as the AI chatbots they are used to dealing with.

New policies typically apply to TLDs going forward. For example, ICANN requires the names of other TLDs to be reserved in each new TLD. Now, obviously, you will find travel.com, but you won't find com.travel. That kind of rule is only applied from the time it is made to any future TLDs.

The country code reservation rule was made for the 2014 new TLD round it applies to the 2014 round new TLDs. .travel is not an "exception", because it was not one of the new TLDs.

And, more to the point, your problem is with .build, which is one of the 2014 new TLDs.

As noted at the policy link I provided you:

https://www.icann.org/en/contracted...es/reserved-names/country-and-territory-names

Specification 5, Section 4 of the New gTLD Registry Agreement requires reservation of the country and territory names

Do you see where it says "New gTLD Registry Agreement"? That refers to the 2014 round new gTLDs. .travel was not even a gTLD when it was launched with the other "sponsored" or sTLDs in 2007 which had significant restrictions on registration eligibility. The purpose of that round was to try adding a few TLDs which had membership requirements. I believe those were eliminated a few years ago for .travel, but it is not one of the TLDs to which the rule applies.

The reason for the rule which, again, does not apply to the older TLDs was that several governments were upset that other people not only had country names in .com and other TLDs, but these governments were unable to obtain the domain names through the UDRP. Consequently the ICANN Government Advisory Committee - which consists of government representatives - insisted on this rule. If ICANN told the registry, "Oh, you made a mistake and we are going to let some guy have Malaysia.build" then ICANN would face a difficult problem answering to the GAC.

That's why ICANN told you they don't have the ability to tell a registry to release one of the reserved country names, or to exempt a registry from the rule.

The domain name was registered to you by mistake. It was a mistake that went on a long time because, frankly, nobody cares about a lot of these TLDs. Both the registrar and registry agreements provide them with zero liability for revoking domain names to correct mistakes. It doesn't matter how long you had the domain name and it doesn't matter how much AI-generated legal nonsense you can come up with.

In any event, I am not going to have a conversation with your AI chatbot. You can do fine with that on your own.

Bottom line - you are not gettting this domain name back under any circumstances, and you are not getting compensation for consequential losses.
 
Last edited:
3
•••
Dear John,

I find your condescending tone and ad hominem attacks, particularly your reference to "AI chatbots," to be a peculiar and unprofessional way to engage in a discussion about domain governance. My questions are my own, born from my experience and research. To suggest they are not is simply a way to avoid answering them. I am not a lawyer, but my arguments are grounded in common sense principles of fairness and accountability, which seem to be missing from your explanation.

1. The Mistake and Its Consequences

You might be correct that the domain was registered due to a registry error. But your characterization of the outcome is where your argument fails. This was not a mistake caught and corrected in 2014. The registry (the .BUILD registry), the registrar (Namecheap), its upstream provider (eNom), and ICANN (via a mandatory fee for registration and renewal) all accepted my payments and validated this registration through nearly a decade of renewals. They all profited from this "mistake." The correction of this error a decade later was executed in the worst possible way: without any notice, without any appeal process, and without any offer of transition or restitution. This is not about "zero liability"; it is about a fundamental breach of the duty of care and good faith owed to a registrant.

2. The True Cost of the "Mistake"

You claim the length of time doesn't matter, but it is the central issue. This "mistake" has cost me an unaccountable amount in damages, including:
  • Over 30 months of time and effort to develop a multi-platform real estate project.
  • Significant financial investment in web development, design, and content creation.
  • Lost profits and the complete destruction of a business asset.
  • Reputational damage with my clients and partners.
3. The Central Contradiction

My primary problem is with ICANN's contradictory role in this matter. The registry (the .BUILD registry) explicitly told my registrar's upstream provider, eNom, that they were "requested by ICANN to remove / Block the domain." However, ICANN Contractual Compliance has explicitly told me it has "no contractual authority to instruct a registry operator."

Let me give you a legal analogy, since that is your area of expertise. It's like a client of yours tells you, "The judge personally called me and told me to hand over the title to my house." (My registrar's upstream provider was told that ICANN requested my domain be removed.) When you speak to the judge, they say, "I have no authority to issue such an order, and I never did." (ICANN told me they have no contractual authority to order the removal of a domain.)

The judge is telling you they have no authority to order the client to give up their property, but the opposing party is insisting the order came directly from the judge. This is not a simple miscommunication; it is a fundamental contradiction about who has the authority to act.

4. On Your Professionalism and the Use of AI

As an Intellectual Property Attorney specializing in Patents, Copyrights, Trademarks, and Domain Name Issues, I am surprised by your unprofessional and dismissive tone. It is hypocritical to criticize my use of AI to articulate my case clearly when, in the legal and corporate worlds, AI is used daily for research, document review, and drafting.

Given that you work in an era defined by technological advancement, do you honestly not use AI systems in your daily life or work?

Let me give you another example from your own profession: a lawyer, who has built a successful practice over ten years, relies on a law library for all their research. The library discovers that a key case it provided a decade ago was fundamentally flawed due to a cataloging error (like the .BUILD registry failing to reserve country names). The library then silently removes all of the lawyer's research on that case (like my domain being silently deleted). When the lawyer complains, the library says, "You trusted our system, but we have no liability for our mistake. You should have checked our internal cataloging system yourself to ensure the case was valid."

As a lawyer, would you ever consider giving such a client the same advice that you have given me? Would you advise them to simply accept their massive loss and move on?

5. An Unfair Burden on Ordinary Registrants


You claim it doesn't matter how long I had the domain name. If you were in my shoes, having invested over 30 months of your life and a significant amount of money to develop a project, would you just sit quietly and accept it all being erased because you are required to follow ICANN's terms? As an ordinary registrant, I had no knowledge of reserved names under Specification 5, GAC consultation processes, or ICANN’s audit compliance mechanisms. When I searched and registered the domain, it was a simple, good-faith transaction. Why am I penalized for trusting the systems of ICANN’s contracted parties?

6. The Case for Common Sense

Advising someone to apply common sense over "dead" rules is fundamentally a call for fairness and logic in a situation where a rigid system has failed. Rules are meant to provide a predictable framework for order, but when a rule is outdated, wasn't properly applied, or leads to an absurd outcome, following it blindly can be illogical and unjust.

In your situation, a "dead rule" (the ICANN country list) was never properly implemented by the registry. For a decade, all parties, including ICANN, validated your domain registration by accepting your payments. The fact that the domain was eventually taken away due to a "mistake" from years ago, without any notice or restitution, defies all common sense.

"Dead rules" are dangerous because they allow a system to be used as an excuse for an unjust outcome. They provide a simple, technical justification for avoiding responsibility. When the .BUILD registry says "we made a mistake," and ICANN says, "we have no authority," they're hiding behind a rigid system to avoid accountability for a clear and preventable error.

Your argument is that the spirit of the law—fairness, transparency, and consistency—should take precedence, especially when the letter of the law was ignored for ten years. You are not asking for an exception to the rule; you are pointing out that the rule's failure to be properly enforced created an unfair situation that common sense demands be rectified.

7. The .travel TLD and Systemic Trust

I acknowledge that .travel was launched in a different round. My reference to it was not to claim it was an "exception" to the 2012 policy, but to illustrate a broader principle: that consistent enforcement of fundamental rules is a bedrock of a stable and trustworthy DNS. The existence of country names in other TLDs, whether old or new, creates a perception of arbitrary and selective enforcement that undermines registrant trust. This is a valid point about systemic governance, not a misunderstanding of TLD rounds.

This is not "AI-generated nonsense." This is a registrant who entered into a good-faith, paid contract for a service, upheld their end of the bargain for a decade, and was then met with a silent deletion, a wall of silence from the responsible parties, and now, a defense of that process.

My escalation is not about emotionally "getting the domain back." It is about demanding that ICANN and its contracted parties operate with procedural integrity, transparency, and consistency. The current handling of this case—from the registry's action to ICANN's contradictory explanations—fails that test entirely.

Best regards,
TC Wong
 
0
•••
:banghead:
 
2
•••
4. On Your Professionalism and the Use of AI

As an Intellectual Property Attorney specializing in Patents, Copyrights, Trademarks, and Domain Name Issues, I am surprised by your unprofessional and dismissive tone. It is hypocritical to criticize my use of AI to articulate my case clearly when, in the legal and corporate worlds, AI is used daily for research, document review, and drafting.

Given that you work in an era defined by technological advancement, do you honestly not use AI systems in your daily life or work?

Let me give you another example from your own profession: a lawyer, who has built a successful practice over ten years, relies on a law library for all their research. The library discovers that a key case it provided a decade ago was fundamentally flawed due to a cataloging error (like the .BUILD registry failing to reserve country names). The library then silently removes all of the lawyer's research on that case (like my domain being silently deleted). When the lawyer complains, the library says, "You trusted our system, but we have no liability for our mistake. You should have checked our internal cataloging system yourself to ensure the case was valid."

As a lawyer, would you ever consider giving such a client the same advice that you have given me? Would you advise them to simply accept their massive loss and move on?

I'm not John so I can't speak for John but as someone who tries to be helpful on the internet I have strong opinions on this topic that I will take any opportunity to write about.

If you cannot be bothered to take the time to type out a message, how can you expect someone else who is volunteering their time to read it?

Good communication respects the limited time of others. Good communication is concise not verbose. Good communication is 100 meaningful words, not 1000 filler words. When there is zero cost to generating 10, 100, 1,000 or even 10,000 words with ChatGPT, people like yourself are happy churning out endless diatribes that are a slog to read.

A decade ago, the only way to post a 1,000 word diatribe was to sit at your keyboard and suffer through typing every word. And because nobody wants to spend their time typing out a 1,000 word diatribe, they wrote a 100 word missive instead. And everyone was happy. And if someone did get 500 words into a diatribe, they had probably realised that they needed to cool off and take a break and start again. And very rarely when someone was a little crazy and did write and post a 1,000 word diatribe... it was at least filled with personality and humanity that provided a window into a real person's mind.

Did you even read every word you've posted?

Reconsider this thread from the ground up. You owned the domain malaysia.build, it has been taken away from you. You are fortunate enough to have the attention of one of the world's foremost experts on domain name protection and recovery for free. As one of the world's foremost experts, John's time is very limited and valuable. You want to get the best advice. Do you... take up his time with thousands of empty words to read, or do you use as few words as possible, so that he has more time to respond?

If you're not confident with English, or just can't be bothered to type a lot, there is a very simple solution that will make everyone happy: write your posts as a series of condensed bullet points that add information or ask clarifying questions. Write less not more.

And if you absolutely must use ChatGPT, at least do the decent thing and ask it to generate a concise response. As anyone who reads a lot on the internet, phrases like "This is not about "zero liability"; it is about a fundamental breach of the duty of care and good faith owed to a registrant." are so painful to read because they are such awful ChatGPT-isms.

Personally, I wish ChatGPT posts were banned from the internet. Using AI to research or flesh out your own ideas or critique your own writing is one thing. Using it to generate endless text that you force upon others is another thing entirely. I'd pick a post filled with broken English over a post of ChatGPT every single time.

I spent 20 minutes typing this 500 word response, that's a high price I paid, and that's why I feel comfortable asking you to read it. Or, as ChatGPT would say...

this is not about "using AI"; it is about a fundamentally inconsiderate approach to communicating with others.

1757951534111.png
 
8
•••
Hello shr.ink,

Thank you for your reply and your willingness to engage. I also want to take a moment to thank John again for his earlier replies.

My case is so rare that no AI system can generate the specific content for me and finding a similar precedent has been impossible. If you know of one, please share it, as it would be invaluable to my research.

My arguments are born from my experience and research, not AI. I admit my English is not strong as it's not my native language, and my primary use for AI is to polish my writing to ensure my points are clear. This is done out of respect for the reader's time, not a lack of effort.

I appreciate your point about John's expertise and limited time, but everyone's time is valuable. I hope John will find the time to address the substance of my arguments #14.

I must respectfully disagree with your desire to ban AI posts. My use of AI is not about generating endless content; it is about overcoming a language barrier to make my complex case clear and concise. By using this tool, I can write 100 meaningful words instead of 1000 words of "broken English," which would be a far bigger slog to read.

Your logic that effort spent equals value is flawed. It's like a lawyer refusing to use a computer to write a brief, preferring to use a quill and parchment simply to show how hard they worked. Using a better tool to produce a clearer, more effective result is a sign of intelligence and respect for the reader's time. The goal is to be understood, and AI helps me achieve that.

I hope this clarifies my approach, and I remain open to further discussion on the substantive issues raised.

Best regards,
TC Wong

I'm not John so I can't speak for John but as someone who tries to be helpful on the internet I have strong opinions on this topic that I will take any opportunity to write about.

If you cannot be bothered to take the time to type out a message, how can you expect someone else who is volunteering their time to read it?

Good communication respects the limited time of others. Good communication is concise not verbose. Good communication is 100 meaningful words, not 1000 filler words. When there is zero cost to generating 10, 100, 1,000 or even 10,000 words with ChatGPT, people like yourself are happy churning out endless diatribes that are a slog to read.

A decade ago, the only way to post a 1,000 word diatribe was to sit at your keyboard and suffer through typing every word. And because nobody wants to spend their time typing out a 1,000 word diatribe, they wrote a 100 word missive instead. And everyone was happy. And if someone did get 500 words into a diatribe, they had probably realised that they needed to cool off and take a break and start again. And very rarely when someone was a little crazy and did write and post a 1,000 word diatribe... it was at least filled with personality and humanity that provided a window into a real person's mind.

Did you even read every word you've posted?

Reconsider this thread from the ground up. You owned the domain malaysia.build, it has been taken away from you. You are fortunate enough to have the attention of one of the world's foremost experts on domain name protection and recovery for free. As one of the world's foremost experts, John's time is very limited and valuable. You want to get the best advice. Do you... take up his time with thousands of empty words to read, or do you use as few words as possible, so that he has more time to respond?

If you're not confident with English, or just can't be bothered to type a lot, there is a very simple solution that will make everyone happy: write your posts as a series of condensed bullet points that add information or ask clarifying questions. Write less not more.

And if you absolutely must use ChatGPT, at least do the decent thing and ask it to generate a concise response. As anyone who reads a lot on the internet, phrases like "This is not about "zero liability"; it is about a fundamental breach of the duty of care and good faith owed to a registrant." are so painful to read because they are such awful ChatGPT-isms.

Personally, I wish ChatGPT posts were banned from the internet. Using AI to research or flesh out your own ideas or critique your own writing is one thing. Using it to generate endless text that you force upon others is another thing entirely. I'd pick a post filled with broken English over a post of ChatGPT every single time.

I spent 20 minutes typing this 500 word response, that's a high price I paid, and that's why I feel comfortable asking you to read it. Or, as ChatGPT would say...

this is not about "using AI"; it is about a fundamentally inconsiderate approach to communicating with others.

Show attachment 283363
 
0
•••
Dear John,

After doing further research, I realize that you are correct about your statement:

> “In all of the new TLDs, country names are required by ICANN to be reserved and unregistrable.”

I did not fully understand the distinction between older TLDs like .travel and the new gTLDs from the 2012/2014 round such as .build. As an ordinary registrant, there was simply no way I would have known the depth of these rules, so I greatly appreciate your clarification.

I also want to sincerely apologize for some of my earlier wording, where I used terms like “unprofessional.” That was inappropriate. Please forgive me — at the time I was under great frustration, especially since all of the replies from the registry (has remained entirely silent throughout, despite being copied in all related communications), registrar, and ICANN were so unfavorable to my case. I now understand that my frustration should not have been directed at you personally, and I thank you for taking the time to explain.

That said, I would still be grateful if you could clarify one part of your reply, if you are willing to share your expertise:

> “The domain name was registered to you by mistake. It was a mistake that went on a long time because, frankly, nobody cares about a lot of these TLDs. Both the registrar and registry agreements provide them with zero liability for revoking domain names to correct mistakes. It doesn’t matter how long you had the domain name and it doesn’t matter how much AI-generated legal nonsense you can come up with.”

This part is difficult for me to reconcile with my experience and the issues I raised earlier in post #14:

1. The Mistake and Its Consequences

2. The True Cost of the “Mistake”

3. The Central Contradiction

4. On Professionalism and the Use of AI

5. An Unfair Burden on Ordinary Registrants

6. The Case for Common Sense

If you are open to it, I would deeply appreciate your further clarification on how your statement aligns with these points. I fully respect your time and your choice whether or not to continue this discussion, but your expertise is valuable in helping me understand the contractual and legal framework.

Thank you again for your clarification and for engaging with me despite my earlier frustrations.

Best regards,

TC Wong




No. Read what I wrote the first time:

"In all of the new TLDs, country names are required by ICANN to be reserved and unregistrable."

The first time, I said "In all of the new TLDs". You then looked at older TLDs, like .travel, which was part of the limited 2007 round of "sponsored" TLDs. You also then came up with examples in the original gTLDs.

Since you obviously didn't understand what I was saying, or you did not understand that .travel was not part of the new gTLD round, I rephrased it by specifying the 2014 round.

That is not a contradiction. That is simply dealing with the fact that you don't understand when .travel was added to the root.

...
 
0
•••
UPDATE (Nov 5, 2025): I just filed a formal complaint with Malaysia’s GAC Representative (MCMC)


1. EXECUTIVE SUMMARY
  • Domain: malaysia.build
  • Owned: Lawfully since Apr 29, 2014 (10 renewals)
  • Deleted: Dec 20235 months before paid expiry (Apr 2024)
  • How: No EPP code, no notice, no appeal
  • ICANN Case: #01448650 — nearly 150 days, all channels dead silent
2. CORE FAILURES (ALL DOCUMENTED)

A. "Specification 5" Defense is Implausible

  • Registered via ICANN-accredited channels — renewed 10x
  • If "Malaysia" was reserved, why did their system allow it in 2014?
  • MH370 (Mar 2014) + 1MDB (2015+) = "oversight" for a G20 nation is not credible
B. Due Process Violations
  • No EPP code (violates ICANN Transfer Policy)
  • Zero prior notice in 9+ years
  • Deleted despite valid payment
C. Institutional Evasion
  1. ICANN Compliance: "No authority" ↔ Registry: "Deleted at ICANN's request"
  2. "Oct 2023 Audit" cited only after 61 daysno proof
  3. Ombudsman catch-22: "Can't investigate until Compliance concludes" → Compliance refuses to conclude
  4. Namecheap, Enom, .BUILD Registry: All ceased communication after formal 48-hour demands
3. REQUESTED FROM MCMC / GAC
  1. Inquire with ICANN
  2. Raise at next GAC meeting
  3. Advocate for domain restoration + policy fix

This is not just my domain — it’s a precedent: Any domainer’s nearly 10-year asset can vanish without notice.

Has this happened to you?
Any advice for GAC escalation?

All correspondence public
— no speculation, just facts.

Wong Tai Chiew
 
0
•••
For 15 years, I was Namecheap's loyal "whale" – 600 domains at peak, 1,100+ transactions, $1,160 high orders, $15,442/year renewals. Black Friday / Cyber Monday was my highlight – stacking deals, bulk renewals.

Then they crossed the line: Deleted my paid malaysia.build (5 months left, auto-renew on) without EPP code, notice, or explanation. Circular "upstream" blame, then legal shutdown, then 169 days of silence.

Updated my site today with the receipts: "Ironically, the Thanksgiving weekend I once anticipated ACTIVELY for Namecheap’s biggest promotions has now become a permanent memorial to their betrayal."

From excited customer to this. They took my money, then abandoned me. Full verifiable breakdown:

  • $1,160 order screenshot
  • Revenue math: 450 .co @ $28.99 + 150 .com @ $15.98 = $15,442/year
  • Evidence trail + emails
See it all: https://loss.co/the-calculated-betrayal-how-namecheap-abandoned-a-15000-year-client/

The fix? The Wong Clause – reform to protect us all: https://wongclause.com

@Namecheap – 169 days is enough. Restore + compensate, or this becomes the precedent.

Thoughts? Anyone else crossed by them?

[Attach: $1,160 screenshot, memorial line highlight, revenue math image, loss.co homepage with Translate + menu]
 

Attachments

  • $1160-order-proof.png
    $1160-order-proof.png
    147.6 KB · Views: 41
  • $15442.50-revenue-math.png
    $15442.50-revenue-math.png
    170.2 KB · Views: 40
  • global-tanslate-feature.png
    global-tanslate-feature.png
    230.4 KB · Views: 48
  • permanent-memorial-statement.png
    permanent-memorial-statement.png
    579.5 KB · Views: 56
0
•••
Appraise.net

We're social

Escrow.com
Spaceship
Rexus Domain
CryptoExchange.com
Catchy
CatchDoms
DomainEasy — Zero Commission
DomDB
  • The sidebar remains visible by scrolling at a speed relative to the page’s height.
Back