Rebrands and reorgs

docs/pages/governance/index.mdx

@@ -16,3 +16,4 @@ title: "Governance"
 - [Risk Management](/governance/risk-management)
 - [Security Metrics & KPIs](/governance/security-metrics-kpis)
 - [Security Council Best Practices](/governance/council-best-practices)
+- [Rebrands & Reorganizations](/governance/rebrands-and-reorgs)

docs/pages/governance/overview.mdx

@@ -26,6 +26,7 @@ governance in your project.
 2. [Risk Management](/governance/risk-management)
 3. [Security Metrics and KPIs](/governance/security-metrics-kpis)
 4. [Security Council Best Practices](/governance/council-best-practices)
+5. [Rebrands & Reorgs](/governance/rebrands-and-reorgs)
 
 ---
 

docs/pages/governance/rebrands-and-reorgs.mdx

@@ -0,0 +1,197 @@
+---
+title: "Rebrands & Reorganizations"
+# SEO meta description: 140-160 chars. Start with the framework/topic name, include
+# searchable terms (tool names, attack types, standards), use action verbs.
+description: "Recommendations and case studies on how to handle rebrands, acquisitions, and winding down of companies and protocols"
+tags:
+  - Operations & Strategy
+  - Community & Marketing
+contributors:
+  - role: wrote
+    users: [umar-ahmed]
+  - role: reviewed
+    users: []
+  - role: fact-checked
+    users: []
+---
+
+import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components'
+
+<TagProvider>
+<TagFilter />
+
+# Rebrands & Reorganizations
+
+<TagList tags={frontmatter.tags} />
+<AttributionList contributors={frontmatter.contributors} />
+
+Rebrands, acquisitions, and company shutdowns are prime hunting grounds for scammers and
+can create genuine safety risks for community members during the transition and many
+months afterwards. Having a clear plan and consistent communication strategy can keep
+community members safe.
+
+## Practical guidance
+
+### Communication & Transparency
+
+- Announce transitions early and through every official channel simultaneously.
+- Establish a single, canonical source of truth (e.g., an official blog post or governance proposal)
+and link to it everywhere.
+- Transition posts should be authored by a reputable voice in the organization so that users know
+it is an official decision.
+- Use language consistent with your previous posts so community members can verify messaging isn't
+coming from a new author.
+- During rebrands especially, clearly state which old domains, social accounts, and contracts are
+being deprecated and which new ones are canonical.
+- Prepare your community by warning them that scammers will spin up fake migration sites, fake token
+swaps, and impersonation accounts
+
+### Keep Old Accounts
+
+- **Domains**: Renew them, even if the project is over. It’s cheap, and it blocks attackers.
+- **Social Media Handles**: Keep them. Add a link to the new account in the bio. Or contact support
+to request a username change while transferring the old handle to a new account you control.
+- **Discord Vanity URL**: Vanity URLs are unlocked on boosted servers at level 3. As soon as you stop 
+paying for nitro boosts for your server, scammers will likely snipe it and create a fake Discord server with a 
+drainer verification bot.
+- **X.com Handle Marketplace**: In Fall 2025, X.com launched a new [handles marketplace](https://handles.x.com/) in Beta. This is a service
+that allows you to purchase usernames on X. However, there are [many conditions](https://legal.x.com/en/x-handle-transfer-agreement.html#:~:text=3c.%20Maintaining%20Your%20Access%20To%20A%20Transferred%20Handle) placed on these handles
+in order to maintain access including an ongoing X Premium subscription. If you don't maintain these requirements,
+the handle will be reclaimed and available for others to purchase.
+
+### Notify Partners, Aggregators, and Security Providers
+
+- Tell platforms like DefiLlama to mark the project as deprecated or link to the new brand.
+- Notify SEAL that the dapps are intentionally going offline so that future blocks
+on the domains can be performed swiftly.
+
+### Archive Important Knowledge
+
+- Publish important content to IPFS or Internet Archive to make sure that knowledge is not lost
+when you stop paying hosting and server bills.
+- Audit external links and point users to mirrors and alternatives.
+
+### Post-Transition Monitoring
+
+- After any transition, actively monitor for scam domains, fake social accounts, and phishing campaigns
+that exploit the change.
+- Report and take down impersonators quickly.
+- Keep a dedicated support channel open for confused users for at least several months after the transition completes.
+
+## Why is it Important
+
+When decentralized projects announce rebrands, acquisitions, or shut down, it creates an opportunity for attackers
+to weaponize established brands and their infrastructure for scams.
+
+### Inherited Reputation
+
+While sites go offline and domains expire, the reputation that is linked to these assets online remains for quite some time.
+
+### DNS
+
+DNS is used for more than just pointing to a web server:
+
+- MX records point to email servers and ability to send email messages to community
+- TXT records are used to verify ownership of a domain and social accounts
+
+### Confusion Is the Primary Weapon
+
+During normal operations, community members have mental models for what's legitimate. They know the domain, the 
+Twitter handle, the contract addresses. A rebrand or acquisition shatters all of that at once. When everything is 
+"supposed to" look different, people lose their ability to distinguish real changes from fake ones.
+
+### Urgency Is Built In
+
+Transitions naturally create time pressure. "Migrate your tokens before the deadline." "Claim your airdrop for the new token." 
+"Update your wallet connection to the new protocol." Attackers don't even need to manufacture urgency, the legitimate project 
+is already doing it for them. They just mirror the real messaging with a malicious link swapped in.
+
+### Bull vs. Bear Market
+
+Shutdowns and acquisitions often coincide with market trends. During the bear market, when most users are not paying attention
+is exactly when projects announce their shut downs and transitions. By the time markets swing back in the other direction and 
+"retail users" regain their interest in the projects that they engaged with before, many users have forgotten which assets they own 
+and who the authoritative sources of information are. This makes it easy for attackers to exploit and impersonate authoritative figures.
+
+### Authority Structures Are Disrupted
+
+During acquisitions, community members may not know who's in charge anymore. New team members appear, old ones leave, 
+communication channels shift. This makes impersonation trivially easy since nobody knows what the "new" team sounds like yet, 
+so a fake account claiming to be the new community lead is hard to distinguish from a real one.
+
+### The User Base Is Pre-Qualified
+
+Wind-downs and migrations tell attackers exactly who holds assets and is motivated to act. A phishing campaign targeting 
+"all holders of token X who need to migrate" is far more effective than a generic scam, because the targets are real, 
+financially exposed, and expecting to take action.
+
+### Emotional Vulnerability
+
+Wind-downs especially create frustration, fear, and desperation. People who are worried about losing their money or are 
+frustrated with the projects new direction are more likely to act impulsively, click suspicious links, and skip verification steps. 
+
+### Information Asymmetry
+
+During these transitions, insiders know details that the community doesn't yet. Attackers exploit this gap by "leaking" fake insider 
+information — fake migration addresses, fake acquisition terms, fake deadlines — and people believe it because they know real 
+information is being withheld or rolled out gradually.
+
+## Common pitfalls & examples
+
+### MakerDAO → Sky Rebrand (September 2024)
+
+During the rebrand of MakerDAO to Sky, the old Twitter account handle @MakerDAO was changed and left available. Another user registered
+the username and began posting memes. It did not help that there were many questions in the community about the abrupt nature of the rebrand
+and confusion about the conversion of MKR governance tokens to SKY.
+
+The main mistake made by Sky was that they did not keep ownership of their original handle during the migration.
+
+https://x.com/ForesightNewsEN/status/1829080229622808850
+
+### FTX Collapse & Bankruptcy (November 2022)
+
+In the weeks and months following the FTX collapse and ongoing bankruptcy proceedings, several impersonation and phishing attacks
+were seen targeting former customers:
+
+- Emails saying "You have been identified as an eligible client to begin withdrawing digital assets from your FTX account" with a fake
+claims page.
+- SIM-swapping attacks targeting leaked customer data that was improperly obtained from a data breach of the claims administrator Kroll.
+- Advance-Fee Fraud where victims are instructed to pay a commission, legal fee, or tax upfront to expedite the release of their frozen crypto assets.
+
+https://finance.yahoo.com/news/ftx-customers-hit-withdrawal-phishing-064440389.html?guccounter=1
+
+### OpenClaw / ClawdBot Rebrand (January 2026)
+
+When OpenClaw received a trademark notice about its original name, the team went through a rebrand. During the brief window between 
+releasing old social media handles and claiming new ones, scammers seized the abandoned accounts on X.com and GitHub. Attackers stole the 
+identity and launched a fake Solana-based token called $CLAWD that reached $16 million in market cap before crashing 90%. 
+
+The core mistake was simple: they released old handles before securing new ones, creating a window attackers were ready to exploit.
+
+https://www.malwarebytes.com/blog/threat-intel/2026/01/clawdbots-rename-to-moltbot-sparks-impersonation-campaign
+
+
+## Best Practices
+
+1. Announce transitions early and simultaneously across all official channels, establishing a single canonical source of truth.
+2. Warn your community in advance that scammers will exploit the transition, and teach them how to verify legitimate communications.
+3. Keep old accounts, domains, and channels active with redirect notices rather than abandoning them to hijackers.
+4. Publish new contract addresses and official links well in advance through multiple verified channels.
+5. Never manufacture urgency. Provide long grace periods for migrations and withdrawals, extend well beyond announced end dates.
+6. Be explicit about what happens to treasury funds, user data, and any information transferring to an acquirer.
+7. Run major transitions through governance and give the community a voice, even if the project isn't fully decentralized.
+8. Rotate keys, revoke deprecated contract permissions, and audit access credentials as part of every transition.
+9. Archive all documentation, governance decisions, and community discussions publicly and permanently.
+10. Monitor aggressively for scam domains, fake social accounts, and phishing campaigns after every transition.
+11. Maintain a dedicated support channel for confused users for at least several months after the transition completes.
+
+## Additional Resources
+
+- https://www.coinspect.com/blog/zombie-dapps/
+- https://x.com/0xngmi/status/2022300978427396233?s=20
+- https://x.com/Defi_Scribbler/status/2040051531223814163?s=20
+
+---
+
+</TagProvider>
+<ContributeFooter />

utils/fetched-tags.json

@@ -431,6 +431,10 @@
       "Operations & Strategy",
       "Legal & Compliance"
     ],
+    "/governance/rebrands-and-reorgs": [
+      "Operations & Strategy",
+      "Community & Marketing"
+    ],
     "/governance/risk-management": [
       "Operations & Strategy",
       "Legal & Compliance"
@@ -1269,45 +1273,45 @@
     ]
   },
   "sectionMappings": {
-    "Community Management": "community-management",
+    "AI Security": "ai-security",
     "Awareness": "awareness",
-    "Operational Security": "opsec",
-    "OpSec Core Concepts": "opsec",
-    "While Traveling": "opsec",
-    "Wallet Security": "wallet-security",
-    "Signing & Verification": "wallet-security",
-    "Multisig for Protocols": "multisig-for-protocols",
-    "Multisig Administration": "multisig-for-protocols",
-    "Operational Runbooks": "multisig-for-protocols",
-    "For Signers": "multisig-for-protocols",
+    "Community Management": "community-management",
+    "DevSecOps": "devsecops",
+    "Isolation & Sandboxing": "devsecops",
+    "DPRK IT Workers": "dprk-it-workers",
+    "Encryption": "encryption",
+    "ENS": "ens",
     "External Security Reviews": "external-security-reviews",
     "Smart Contract Audits": "external-security-reviews",
-    "Vulnerability Disclosure": "vulnerability-disclosure",
-    "Infrastructure": "infrastructure",
-    "Domain & DNS Security": "infrastructure",
-    "Monitoring": "monitoring",
     "Front-End/Web Application": "front-end-web-app",
+    "Governance": "governance",
+    "Identity and Access Management IAM": "iam",
     "Incident Management": "incident-management",
     "Playbooks": "incident-management",
     "Incident Response Template": "incident-management",
     "Templates": "incident-management",
     "Runbooks": "incident-management",
-    "Threat Modeling": "threat-modeling",
-    "DPRK IT Workers": "dprk-it-workers",
-    "Governance": "governance",
-    "DevSecOps": "devsecops",
-    "Isolation & Sandboxing": "devsecops",
+    "Infrastructure": "infrastructure",
+    "Domain & DNS Security": "infrastructure",
+    "Monitoring": "monitoring",
+    "Multisig for Protocols": "multisig-for-protocols",
+    "Multisig Administration": "multisig-for-protocols",
+    "Operational Runbooks": "multisig-for-protocols",
+    "For Signers": "multisig-for-protocols",
+    "Operational Security": "opsec",
+    "OpSec Core Concepts": "opsec",
+    "While Traveling": "opsec",
     "Privacy": "privacy",
-    "Supply Chain": "supply-chain",
-    "Security Automation": "security-automation",
-    "Identity and Access Management IAM": "iam",
+    "Safe Harbor": "safe-harbor",
     "Secure Software Development": "secure-software-development",
+    "Security Automation": "security-automation",
     "Security Testing": "security-testing",
-    "AI Security": "ai-security",
-    "ENS": "ens",
-    "Safe Harbor": "safe-harbor",
-    "Encryption": "encryption",
+    "Supply Chain": "supply-chain",
+    "Threat Modeling": "threat-modeling",
     "Treasury Operations": "treasury-operations",
+    "Vulnerability Disclosure": "vulnerability-disclosure",
+    "Wallet Security": "wallet-security",
+    "Signing & Verification": "wallet-security",
     "Guides": "guides",
     "Account Management": "guides",
     "Endpoint Security": "guides",

vocs.config.tsx

@@ -190,6 +190,7 @@ const config = {
             { text: 'Risk Management', link: '/governance/risk-management', dev: true },
             { text: 'Security Metrics and KPIs', link: '/governance/security-metrics-kpis', dev: true },
             { text: 'Security Council Best Practices', link: '/governance/council-best-practices', dev: true },
+            { text: 'Rebrands & Reorgs', link: '/governance/rebrands-and-reorgs', dev: true },
           ]
         },
         {