diff --git a/docs/pages/governance/index.mdx b/docs/pages/governance/index.mdx
index 34d819dd..d958b8dd 100644
--- a/docs/pages/governance/index.mdx
+++ b/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)
diff --git a/docs/pages/governance/overview.mdx b/docs/pages/governance/overview.mdx
index 1424eb5b..6459d751 100644
--- a/docs/pages/governance/overview.mdx
+++ b/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)
---
diff --git a/docs/pages/governance/rebrands-and-reorgs.mdx b/docs/pages/governance/rebrands-and-reorgs.mdx
new file mode 100644
index 00000000..d35df091
--- /dev/null
+++ b/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'
+
+
+
+
+# Rebrands & Reorganizations
+
+
+
+
+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
+
+---
+
+
+
diff --git a/utils/fetched-tags.json b/utils/fetched-tags.json
index 94e7693b..11abfd34 100644
--- a/utils/fetched-tags.json
+++ b/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",
diff --git a/vocs.config.tsx b/vocs.config.tsx
index bd89b9ef..3d35402c 100644
--- a/vocs.config.tsx
+++ b/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 },
]
},
{