diff --git a/concepts/allowlist.mdx b/concepts/allowlist.mdx
new file mode 100644
index 0000000..9dcc0ec
--- /dev/null
+++ b/concepts/allowlist.mdx
@@ -0,0 +1,139 @@
+---
+title: "Allowlist"
+description: "Understanding how ChainPatrol identifies and protects legitimate assets"
+---
+
+## Overview
+
+An **allowlist** is a curated list of known, trusted assets that are explicitly recognized as legitimate within ChainPatrol.
+
+<Info>
+Assets added to the allowlist are considered **official or approved** and are treated differently from unknown or suspicious assets during threat detection and analysis.
+</Info>
+
+Allowlisting helps ChainPatrol distinguish between genuine brand-owned content and potential impersonation or abuse.
+
+Unlike blocklists, which focus on malicious content, allowlists define what is **known to be safe**.
+
+## Why We Use an Allowlist at ChainPatrol
+
+Allowlists play a critical role in improving both **detection accuracy** and **signal quality**.
+
+### Dual Purpose
+
+**Exclusion from Detection** - When an asset is allowlisted, it is excluded from automatic threat detection. This prevents legitimate brand-owned assets from being mistakenly flagged as impersonation, reduces false positives, eliminates unnecessary investigations, and improves team efficiency. For example, your official website `example.com` is allowlisted, so it will never be flagged as a phishing site, even if detection rules would normally trigger on brand-related keywords.
+
+**Reference Baseline** - Allowlisted assets are used as reference points when analyzing potentially malicious content. ChainPatrol can compare a suspected phishing page against an allowlisted official website to determine whether branding is being copied, layout is being imitated, content is being duplicated, and visual elements are being stolen. For example, a suspicious site `examp1e.com` is detected. ChainPatrol compares it against your allowlisted `example.com` and identifies 95% visual similarity, identical logo usage, and copied page structure, resulting in high-confidence brand impersonation detection.
+
+This dual role (exclusion from detection and use as a trusted baseline) makes allowlists essential for reliable brand impersonation analysis.
+
+## What Can Be Allowlisted?
+
+In ChainPatrol, **any asset type can be allowlisted**:
+
+- **Domains and URLs** - Official websites and web applications
+- **Social Media Accounts** - Verified brand and employee accounts
+- **Application Pages** - App store listings and hosted content
+- **Development Environments** - Testing, staging, and QA environments
+- **Preview Deployments** - Vercel, Netlify, and other preview URLs
+- **Blockchain Addresses** - Official smart contracts and wallets
+- **Email Addresses** - Official company and team emails
+- **Other Assets** - Any asset legitimately controlled by your organization
+
+Allowlisting is not limited by platform or asset category, as long as the asset is known to be legitimately controlled by the organization or brand.
+
+## What Should and Shouldn't Be Allowlisted?
+
+### Should Be Allowlisted ✅
+
+Assets that are **owned, controlled, or intentionally operated** by the organization or its brands:
+
+**Official Websites** - Primary company website, product websites, documentation sites, support portals, marketing landing pages. Example: `company.com`, `docs.company.com`, `support.company.com`
+
+**Verified Social Media Accounts** - Official Twitter/X accounts, official Discord servers, official Telegram channels, official YouTube channels, verified employee accounts. Example: `@CompanyOfficial`, `discord.gg/company-official`
+
+**Internal Testing Environments** - QA environments, staging servers, internal testing sites, employee development environments. Example: `staging.company.com`, `qa-env.company.com`
+
+**Development and Preview Pages** - Vercel deployments owned by the company, Netlify preview URLs, GitHub Pages for official repositories, CI/CD preview environments. Example: `company-app.vercel.app`, `preview-123.netlify.app`
+
+**Official Blockchain Assets** - Official smart contracts, treasury wallets, multisig addresses, token contracts. Example: `0x1234...` (official token contract)
+
+### Should NOT Be Allowlisted ❌
+
+**Third-Party Content** - Content that is merely tolerated but not controlled by your organization, including partner websites mentioning your brand, news articles about your company, third-party reviews or comparisons, and affiliate or reseller sites. Even if the content is positive or authorized, if you don't control it, don't allowlist it.
+
+**User-Generated Content** - Content created by users, even on your platforms, including user profiles on your platform, community-submitted content, user comments or posts, and customer testimonials on external sites.
+
+**Assets Not Fully Controlled** - Assets where you don't have complete control or ownership, including shared hosting environments, third-party integrations, external widgets or embeds, and temporary or borrowed infrastructure. If there's any doubt about control or ownership, err on the side of caution and don't allowlist.
+
+<Warning>
+**Important:** Allowlisting an asset implicitly signals trust. Because allowlisted assets are excluded from automatic detection, incorrectly allowlisting an asset can reduce visibility into real threats.
+</Warning>
+
+## Risk Handling and Escalation
+
+Allowlisting does not permanently exempt an asset from scrutiny.
+
+If an allowlisted asset shows suspicious behavior or is believed to be compromised, it can still be escalated, investigated, and acted upon.
+
+### Compromise Scenarios
+
+**Account Compromise** - If your official Twitter account is hacked: Asset is allowlisted so automatic detection doesn't flag it, community reports suspicious activity, manual investigation reveals compromise, asset is temporarily removed from allowlist, threat is blocked and reported, after recovery asset is re-allowlisted.
+
+**Domain Hijacking** - If your domain is hijacked or DNS is compromised: Asset is allowlisted so automatic detection doesn't flag it, monitoring detects unusual behavior or content changes, security team investigates, asset is removed from allowlist during incident, malicious content is blocked, after resolution asset is re-allowlisted.
+
+**Infrastructure Breach** - If your hosting infrastructure is compromised: Allowlisted assets start serving malicious content, user reports or automated monitoring detect anomalies, incident response is triggered, affected assets are removed from allowlist, threats are contained and remediated, assets are re-allowlisted after verification.
+
+This ensures that trust is not absolute and that compromised official assets do not become blind spots.
+
+## Granularity of Allowlists
+
+Allowlists in ChainPatrol can be configured at different levels:
+
+**Organization Level** - Assets allowlisted at the organization level are trusted for the entire organization, regardless of which brand they're associated with. Use cases include corporate websites, shared infrastructure, company-wide social accounts, and central authentication systems. Example: `company.com` is allowlisted at the organization level, protecting it for all brands under the organization.
+
+**Brand Level** - Assets allowlisted at the brand level are trusted only for that specific brand within the organization. Use cases include product-specific websites, brand-specific social accounts, individual product infrastructure, and brand-specific campaigns. Example: `product-a.com` is allowlisted for "Product A" brand but not for "Product B" brand.
+
+This flexibility allows teams managing multiple brands to tailor trust appropriately.
+
+### Hierarchy Example
+
+```
+Organization: Acme Corp
+├── Brand: Acme Protocol
+│   ├── acme-protocol.com (Brand-level allowlist)
+│   └── @AcmeProtocol (Brand-level allowlist)
+├── Brand: Acme Wallet
+│   ├── acme-wallet.com (Brand-level allowlist)
+│   └── @AcmeWallet (Brand-level allowlist)
+└── Organization-level allowlist:
+    ├── acme.com (All brands)
+    ├── @AcmeCorp (All brands)
+    └── support@acme.com (All brands)
+```
+
+## Who Can Update the Allowlist?
+
+Allowlist management is restricted to **organization administrators and authorized staff members**.
+
+- **Organization Administrators** - Full control over organization-level and brand-level allowlists
+- **Authorized Staff** - ChainPatrol staff can assist with allowlist management
+- **Limited Access** - Standard users cannot modify allowlists
+- **Audit Trail** - All allowlist changes are logged and tracked
+
+Limiting access helps ensure that allowlists remain accurate, intentional, and aligned with security best practices.
+
+### Best Practices for Allowlist Management
+
+1. **Be Conservative** - Only allowlist assets you definitively control and trust
+2. **Regular Reviews** - Periodically review your allowlist (quarterly recommended) to remove outdated or deprecated assets
+3. **Document Decisions** - Maintain internal documentation of why assets were allowlisted
+4. **Remove Compromised Assets** - Immediately remove any asset suspected of being compromised
+5. **Re-add After Verification** - Only re-allowlist assets after confirming they're secure and under your control
+
+## Key Takeaways
+
+- Allowlisting reduces false positive noise: Adding your official assets filters them from detection sources, letting your team focus review time on actual threats
+- Conservative allowlisting prevents blind spots: Only add assets you definitively control because allowlisted assets that get compromised won't trigger automatic alerts
+- Domain allowlisting uses smart matching: Adding `example.com` automatically trusts all subdomains, reducing maintenance while maintaining protection
+- Allowlist changes require administrator privileges: This restriction prevents accidental or malicious allowlisting that could create security gaps
diff --git a/concepts/asset-scans.mdx b/concepts/asset-scans.mdx
new file mode 100644
index 0000000..520074c
--- /dev/null
+++ b/concepts/asset-scans.mdx
@@ -0,0 +1,135 @@
+---
+title: "Asset Scans"
+description: "Understanding how ChainPatrol evaluates assets at specific points in time"
+---
+
+## Overview
+
+<Info>
+An **asset scan** is a single security check ChainPatrol performs on an asset (like a URL, social profile, app listing, crypto address, or email) at a specific moment in time.
+</Info>
+
+### What It Captures
+
+- **What We Saw** - Visual and content snapshot
+- **Extra Context** - Enrichment data collected
+- **Risk Conclusion** - Risk assessment and scores
+
+### Why It Matters
+
+Asset scans are the building blocks ChainPatrol uses to understand threats over time, update asset status, support reviews and takedowns, and power reporting and analytics.
+
+## Key Characteristics
+
+### Tied to Specific Asset
+
+Every asset scan belongs to exactly one asset and, through that asset, to an organization and optionally a brand.
+
+```
+Organization
+  └── Brand (optional)
+      └── Asset
+          └── Asset Scan
+```
+
+### Time-Bound Snapshot
+
+Each scan has a timestamp and stands on its own. Later scans might see different content, liveness status, risk indicators, and infrastructure. This allows ChainPatrol to track how threats evolve over time.
+
+### Status Tracking
+
+A scan has a simple status reflecting where it is in the checking process:
+
+1. **Pending** - Scan queued but not yet started
+2. **In Progress** - Actively collecting data and running checks
+3. **Completed** - Scan finished successfully with results
+4. **Failed** - Scan encountered errors and couldn't complete
+
+### Contents
+
+**Inputs:** What we were asked to scan (URL, address, profile) and related context (organization, brand, detection source).
+
+**Outputs:** Enrichments (extra data we fetched), labels (risk tags), liveness status, and overall risk score for that point in time.
+
+## What Lives Inside a Scan
+
+### Enrichments (Extra Context)
+
+Structured information gathered during the scan:
+
+**Web Content & Metadata** - Page HTML and text content, title, description, keywords, meta tags and structured data, screenshots and visual captures, form fields and input elements.
+
+**Links Discovered** - Outbound links from the page, redirect chains, external resources loaded, related infrastructure.
+
+**Technical Details** - DNS records and resolution, TLS/SSL certificate information, IP addresses and hosting, server headers and responses, network infrastructure.
+
+**Platform-Specific Details** - Social profile attributes (followers, posts, bio), app store listing information (ratings, reviews, permissions), blockchain data (contract code, transactions), email validation results.
+
+Each enrichment knows where it came from (e.g., "page content", "network", or an external scanner) and whether it succeeded or failed.
+
+### Labels (Findings)
+
+Human-readable tags with scores that categorize risk:
+
+- **Brand Impersonation** - Visual or textual mimicry of your brand
+- **General Phishing** - Credential harvesting or scam patterns
+- **Provider Blocked** - Suspended or blocked by hosting provider
+- **Wallet Drainer** - Malicious wallet connection code
+- **Parked Domain** - Domain reserved but not in use
+- **Typosquatting** - Domain closely resembling legitimate one
+
+These labels are used to group risk into categories like general phishing, brand impersonation, or wallet-related risk.
+
+### Scores and Liveness
+
+A scan tracks two key metrics:
+
+**Risk Score** - A numerical score (typically 0-1) representing the overall risk level at that point in time. Calculated from label scores, rule evaluations, confidence levels, and historical patterns.
+
+**Liveness Status** - Indicates whether the asset is currently accessible:
+- **ALIVE** - Asset is accessible and active
+- **DEAD** - Asset is inaccessible or removed
+- **UNKNOWN** - Status cannot be determined
+
+Reasons tracked include DNS failed, parked domain detected, suspended by provider, 404 not found, and connection timeout.
+
+## How Asset Scans Relate to Other Concepts
+
+**Asset** - The asset is the "thing" (URL, profile, listing, address); scans are the history of what we have seen about that thing. One asset has many scans over time, and scans build a timeline of the asset's behavior. The most recent scan is typically used for current status.
+
+**Threats / Detections** - Threat records (detections) use scan labels and scores as key inputs to decide whether something should be treated as an active threat for your organization.
+
+**Reviews** - When your team reviews a reported asset, they see the most relevant scan results including screenshots, labels and scores, enrichment data, and historical scan timeline to understand why it was flagged and whether it should be allowed, blocked, or escalated.
+
+**Blocklist, Allowlist, Watchlist** - Repeated scan results help decide status: Blocked (assets that consistently look malicious), Allowed (assets that can be treated as safe), and Watchlisted (assets that are sensitive or change frequently).
+
+**Takedowns** - For assets that need to be taken down, scan data provides evidence including screenshots showing malicious content, metadata and technical details, liveness history, and timeline of activity to support outreach to hosting providers, registrars, and platforms.
+
+**Relationships Between Assets** - When scans find links and redirects, they can be connected together to show clusters of related pages or infrastructure, helping identify broader campaigns, map attacker infrastructure, understand threat networks, and coordinate takedowns.
+
+## Examples
+
+### Example 1: Suspicious Login Page
+
+A new login page is found in search results. ChainPatrol scans the page, sees it closely imitates your brand, detects wallet connection requests, and assigns strong phishing and brand-impersonation labels. The scan feeds into a threat record for your organization and appears in your triage queue with high-priority review recommended. High-confidence scans like this often trigger automatic blocking.
+
+### Example 2: Official Site Staying Healthy
+
+Your official website is added as an asset and monitored. Regular scans (daily or weekly) show the asset is alive and consistent, does not trigger risky labels, and maintains a stable risk score near zero. It remains allowed and serves as a "known good" reference used for comparison against suspicious assets.
+
+### Example 3: Impersonating Social Profile
+
+A social profile claiming to be one of your employees is discovered. The profile is scanned for attributes, shows overlapping branding, detects suspicious outreach behavior, and increases impersonation scores. The scan supports team decision-making, provides evidence for escalation, and forms the basis for pursuing takedown with documented proof of impersonation.
+
+## What Asset Scans Are Not
+
+- **Not a Human Report** - Asset scans are system-generated. Reports are created by users or external systems raising issues.
+- **Not a Case** - A scan can be clean or suspicious. A threat or incident record is created only when risk crosses thresholds or a human escalates it.
+- **Not a Configuration** - Scans use your rules, thresholds, and service settings, but they are not where you configure behavior. They are the evidence those settings produce.
+
+## Key Takeaways
+
+- One asset, many scans creates a timeline: Scanning the same URL multiple times shows how threats evolve, when they go live, and when takedowns succeed
+- Selective enrichment balances speed and depth: Basic scans are fast, but when risk signals appear, deeper analysis triggers automatically to gather decisive evidence
+- Liveness tracking enables automated workflows: Knowing when assets change from ALIVE to DEAD lets watchlist monitoring confirm takedown success without manual checking
+- Relationship extraction reveals campaigns: Links and redirects discovered during scans help trace entire threat networks instead of treating each malicious site as isolated
diff --git a/concepts/blocklist.mdx b/concepts/blocklist.mdx
new file mode 100644
index 0000000..b308e9f
--- /dev/null
+++ b/concepts/blocklist.mdx
@@ -0,0 +1,163 @@
+---
+title: "Blocklist"
+description: "Understanding ChainPatrol's threat intelligence database"
+---
+
+## Overview
+
+A blocklist (also known as a denylist) is a database of confirmed malicious entities that should be blocked or flagged to protect users. In the context of web3 security, a blocklist contains verified phishing websites, scam social media accounts, fraudulent crypto addresses, and other malicious assets that pose a threat to users.
+
+<Info>
+ChainPatrol's blocklist functions as a **threat intelligence database** that's continuously updated and distributed in real-time.
+</Info>
+
+Unlike traditional security databases that may update daily or weekly, our blocklist provides immediate updates as threats are confirmed, ensuring protection is deployed within minutes rather than hours or days.
+
+The blocklist serves as the foundation of proactive security. Instead of waiting for users to encounter threats, we identify, verify, and distribute threat intelligence to prevent exposure before it happens.
+
+## Why Do We Use a Blocklist and Why Is It Effective?
+
+### The Problem with Traditional Takedowns
+
+Traditional cybersecurity approaches rely heavily on **takedowns**, requesting hosting providers or domain registrars to remove malicious content. However, this approach has critical limitations:
+
+- **Slow Response Times** - Hours to days for hosting providers and domain takedowns
+- **Incomplete Coverage** - Some providers never respond or operate in non-cooperative jurisdictions
+- **Attack Window** - Scammers can steal funds within minutes of launching a phishing site
+- **Whack-a-Mole** - Attackers quickly spin up new domains or move to different providers
+
+### The Blocklist Advantage
+
+ChainPatrol's blocklist provides **immediate protection** through a "blocklist-first, takedown-second" approach:
+
+1. **Speed** - Assets are blocklisted and distributed within minutes after confirmation
+2. **Universal Coverage** - Protection works regardless of hosting provider, jurisdiction, or whether the malicious content remains online
+3. **Point-of-Access Protection** - Blocks are enforced at the browser, wallet, and network level where users actually interact with threats
+4. **Persistent Protection** - Even if a scammer sets up 100 copycat sites, each one gets blocklisted as soon as it's detected
+
+<Warning>
+In web3, where transactions are irreversible and scams can drain wallets in seconds, **prevention at the point of interaction is critical**.
+</Warning>
+
+### Network Effects
+
+The effectiveness of our blocklist increases exponentially with distribution. One confirmation protects millions of users across browsers, wallets, enterprise networks, and partner organizations.
+
+## Who Contributes to the Blocklist?
+
+ChainPatrol's blocklist is powered by a diverse network of contributors:
+
+### Community Reports
+
+Anyone can report suspicious assets through our public reporting interface. Web3 communities including Discord moderators, Twitter users, and Reddit communities actively report scams targeting their communities. Users who've encountered or fallen victim to scams help us identify active threats.
+
+### Partner Organizations
+
+Organizations using ChainPatrol for brand protection contribute threat intelligence. Wallet providers like MetaMask, Phantom, and Coinbase Wallet share detected threats. Security alliances including SEAL-ISAC, Crypto-ISAC, and other information sharing networks contribute, as do blockchain projects and DAOs monitoring for impersonation attacks.
+
+### Automated Detection
+
+Our AI-powered scanning detection engine continuously monitors using detection rules. We perform real-time monitoring of newly registered domains through Certificate Transparency, automated detection of impersonation accounts and scam posts through social media monitoring, and use honeypots (intentional traps that identify and track attacker infrastructure).
+
+### Expert Review Team
+
+While many sources contribute detections, all blocklist entries are verified by ChainPatrol's security team before being added. This ensures accuracy, minimizes false positives, maintains blocklist quality, and provides human judgment for edge cases. This human-in-the-loop review process is critical for maintaining trust in the blocklist.
+
+## What Is In Scope for Being Added to the Blocklist?
+
+Assets are added to the blocklist when they meet two criteria: **intent** and **confirmation**.
+
+### Intent: Malicious Purpose
+
+Assets must demonstrate clear malicious intent:
+
+- **Phishing** - Sites designed to steal credentials, seed phrases, or private keys
+- **Scams** - Fraudulent schemes (fake airdrops, rug pulls, Ponzi schemes)
+- **Impersonation** - Content falsely claiming to represent legitimate brands
+- **Malware Distribution** - Sites or links that distribute malicious software
+- **Social Engineering** - Content designed to manipulate users into compromising security
+
+### Confirmation: Evidence-Based Verification
+
+Assets must be confirmed as malicious through:
+
+1. Multiple credible reports from independent sources
+2. Evidence of attacks or proof of successful attacks and victim reports
+3. Technical analysis showing malicious code or behavior detected
+4. Pattern matching with clear alignment with known attack techniques
+5. Brand owner confirmation verifying unauthorized use (when applicable)
+
+### Out of Scope
+
+The following are **not** added to the blocklist:
+
+- **Legitimate Criticism** - Negative reviews, critical commentary, or parody (protected speech)
+- **Competitor Content** - Content from legitimate competitors, even if unfavorable
+- **Alleged Scams** - Projects accused of being scams without concrete evidence of malicious activity
+- **Civil Disputes** - Trademark disputes, contract disagreements, or business conflicts (handle through legal channels)
+- **Low-Confidence Detections** - Suspicious but unconfirmed assets (may be monitored, but not blocklisted)
+
+This scope ensures our blocklist maintains high accuracy and focuses on clear, immediate threats to user security.
+
+## What Type of Data Is In Our Blocklist?
+
+ChainPatrol's blocklist includes multiple asset types, each with specific attributes:
+
+### URLs and Domains
+
+Full URLs (specific phishing pages), domains (root domains and subdomains), status (current blocklist status and distribution state), first seen date, blocklist date, and associated data including screenshots, detection rules triggered, and related assets.
+
+### Social Media Accounts
+
+Twitter/X accounts, Telegram groups and channels, Discord servers, YouTube channels, and Facebook pages and groups. Each includes platform-specific identifiers like account handles, user IDs, and channel links.
+
+### Blockchain Addresses
+
+Ethereum addresses (scam contracts, phishing wallets, rug pull contracts), multi-chain support across multiple blockchain networks, contract metadata including code analysis and transaction patterns, and labels indicating scam type (fake airdrop, phishing, Ponzi scheme).
+
+### Email Addresses
+
+Phishing emails used in campaigns, fake customer support email addresses, and associated domains linked to scam operations.
+
+### Other Digital Assets
+
+Mobile apps (fake wallet apps, scam applications), browser extensions (malicious extensions that steal credentials), IPFS hashes (decentralized content hosting phishing pages), and NFT collections (scam NFT projects and counterfeit collections).
+
+### Metadata for All Assets
+
+Every blocklisted asset includes comprehensive metadata: asset type, status (BLOCKED, ALLOWED, PENDING), severity, related assets, detection methods, distribution status, and update history.
+
+## Who Uses Our Blocklist?
+
+ChainPatrol's blocklist protects users across the web3 ecosystem through multiple integration types:
+
+### Browser Security
+
+Google Safe Browsing powers protection in Chrome, Safari, Edge, Firefox, and other browsers. Cloudflare Gateway provides network-level protection for enterprises. Direct integrations support web3-focused browsers. Blocklisted URLs are prevented from loading or show warning pages, protecting users regardless of which website they're visiting.
+
+### Wallet Providers
+
+MetaMask (direct integration via Eth-Phishing-Detect), Phantom (real-time API integration), Coinbase Wallet, Trust Wallet, Rainbow, Ledger, WalletConnect, and additional wallets across the ecosystem. Wallets warn users before connecting to malicious sites or interacting with scam contracts, preventing fund loss at the point of transaction.
+
+### Web3 Applications
+
+Polymarket (content moderation and user protection), Snapshot (governance platform security), NFT marketplaces (filtering scam collections and malicious listings), and DeFi protocols (protecting users from fake interfaces and phishing sites). Applications can automatically filter malicious content and warn users about threats specific to their platform.
+
+### Threat Intelligence
+
+SEAL-ISAC, Crypto-ISAC, Eth-Phishing-Detect (ChainPatrol is a core contributor), and Polkadot Phishing List for cross-chain threat sharing. Our blocklist feeds into the broader security ecosystem, creating a network effect where threats are shared across organizations and platforms.
+
+### Enterprise Security
+
+Security teams protect employees and users, brand protection teams monitor and block impersonation attempts, and custom integrations provide API access for internal security tools and workflows. Organizations can integrate ChainPatrol's threat intelligence into their existing security infrastructure for comprehensive protection.
+
+### Public Access
+
+A public API provides freely accessible blocklist data for developers and security researchers, an SDK offers developer tools for easy integration, and a web dashboard provides a search and lookup interface for manual checks. Anyone can access our blocklist data to build security tools, perform research, or check suspicious assets.
+
+## Key Takeaways
+
+- Immediate protection beats slow removal: Blocklisting provides user protection within minutes, while traditional takedowns can take hours or days (if they succeed at all)
+- Network effects multiply protection value: Each confirmed threat automatically protects users across browsers, wallets, and partner platforms without requiring separate submissions
+- Evidence-based verification prevents false positives: Requiring both malicious intent and confirmation ensures blocklist accuracy while human review catches edge cases
+- Public accessibility enables ecosystem security: Open API access lets any wallet, browser, or security tool integrate blocklist protection without licensing barriers
diff --git a/concepts/brands.mdx b/concepts/brands.mdx
new file mode 100644
index 0000000..6ffc996
--- /dev/null
+++ b/concepts/brands.mdx
@@ -0,0 +1,115 @@
+---
+title: "Brands"
+description: "Understanding brand protection in ChainPatrol"
+---
+
+## Overview
+
+A **brand** represents an identity that ChainPatrol protects.
+
+<Info>
+Brands belong to an **organization**, and a single organization can have **multiple brands**.
+</Info>
+
+## Types of Brands
+
+ChainPatrol supports two types of brands:
+
+### Company Brands
+
+These represent the organization itself or its products. Examples include your primary brand (e.g., "ChainPatrol"), product lines or services, sub-brands created for specific business units, and regional or market-specific brands.
+
+**Use Case:** A Web3 company protecting their main protocol name, their governance token, and their NFT marketplace brand.
+
+### Individual Brands
+
+These represent key people associated with the organization. Examples include CEO, executives, public-facing employees, founders, and brand ambassadors.
+
+**Use Case:** Protecting a CEO who is frequently impersonated on Twitter/X and Telegram by scammers offering fake investment opportunities.
+
+Both company and individual brands can be targeted by impersonation, scams, or fraud, and ChainPatrol protects both.
+
+## What Information Is Stored in a Brand?
+
+Each brand includes several components that help ChainPatrol understand what legitimate content looks like and identify potential threats.
+
+### Brand Terms
+
+Keywords associated with a brand that describe how the brand is commonly referenced online. They include official brand names, variations and abbreviations, product names, nicknames or widely used informal names, and individual names (for personal brands).
+
+Examples for "ChainPatrol": ChainPatrol, Chain Patrol, CP, @chainpatrol, chainpatrol.io
+
+By defining brand terms, ChainPatrol is able to recognize when content is likely related to a specific brand and assess whether that content may be legitimate or potentially impersonating the brand.
+
+### Brand Images
+
+Visual elements that represent the brand, including logos (all variations), official graphics and design elements, profile photos for individuals, brand marks and symbols, and visual identity assets.
+
+These images are used during detection to help identify potential impersonation, for example by matching logos or profile photos against suspicious content that may be attempting to mimic the brand.
+
+### Brand Assets
+
+Known, legitimate assets owned by the brand. These are used to distinguish between real content and potentially harmful impersonation.
+
+A brand asset can be any asset type supported by ChainPatrol: websites (official websites and domains), social media (Twitter, Discord, Telegram profiles), app listings (app store and extension listings), repositories (GitHub and code repositories), channels (Telegram channels and groups), and other properties (any verified online property).
+
+Brand assets serve as a whitelist of what is considered authentic.
+
+## How Brand Information Is Used
+
+ChainPatrol combines brand terms, brand images, and brand assets to understand a brand's identity and accurately assign threats to the correct brand.
+
+### The Attribution Process
+
+1. **Threat Detection** - Suspicious content is detected across the internet
+2. **Brand Matching** - ChainPatrol analyzes the content for brand terms (name, keywords), brand images (logos, visuals), and similarity to brand assets (mimicking official properties)
+3. **Automatic Attribution** - The threat is automatically associated with the relevant brand
+4. **Evaluation & Action** - The threat is properly evaluated and acted upon in the context of that brand
+
+This attribution process happens automatically and at a high level, allowing threats to be categorized without requiring manual intervention in most cases.
+
+### Example Attributions
+
+**Domain Impersonation:** Domain `chainpatr0l-airdrop.com` uses ChainPatrol logo and mimics official website design. It matches brand term "chainpatrol" (with typo), matches brand image (official logo detected), and mimics brand asset (official website structure). Result: Automatically attributed to "ChainPatrol" brand.
+
+**Social Media Impersonation:** Twitter account `@chainpatrol_support` with profile photo using ChainPatrol logo and bio mentioning "Official ChainPatrol Support". Matches brand term, matches brand image, impersonates brand asset. Result: Automatically attributed to "ChainPatrol" brand.
+
+**Executive Impersonation:** Telegram account claims to be CEO with profile photo using CEO's headshot and messages offering investment opportunities. Matches brand term (CEO's name), matches brand image (CEO's photo), impersonates individual brand. Result: Automatically attributed to CEO's individual brand.
+
+### Benefits of Accurate Attribution
+
+- **Clear Visibility** - Organizations have clear visibility into which brands are being impersonated
+- **Frequency Tracking** - Understand how frequently each brand is targeted
+- **Action Association** - See which takedowns or mitigation actions are associated with each brand
+- **Trend Analysis** - Identify patterns and emerging threats per brand
+
+## Brands and Organizations
+
+A single organization may be responsible for managing and protecting multiple brands.
+
+### Common Multi-Brand Scenarios
+
+**Corporate + Product Brands** - A company safeguarding both its corporate identity and several product lines. Example: Main brand "Acme Protocol" plus product brands "Acme Swap", "Acme Wallet", and "Acme DAO".
+
+**Executive Protection** - Protecting individual executives or other public-facing staff members. Example: Main brand "Acme Protocol" plus individual brands "Jane Smith (CEO)", "John Doe (CTO)", and "Sarah Johnson (CMO)".
+
+**Regional or Market Brands** - Maintaining distinct brands used across different markets, languages, or regions. Example: Main brand "Acme Protocol" plus regional brands "Acme Asia", "Acme Europe", and "Acme LATAM".
+
+**Acquired Companies** - Managing brands from acquired companies while maintaining their separate identities. Example: Parent brand "Acme Holdings" plus acquired brands "Beta Protocol" and "Gamma Finance".
+
+ChainPatrol keeps brand information structured and separate to ensure that each brand can be protected individually while still remaining clearly associated with the same organization.
+
+### Organizational Benefits
+
+**Granular Control** - Configure protection settings per brand, track metrics for each brand independently, assign different team members to different brands, customize detection rules by brand.
+
+**Unified View** - See all brands in one dashboard, compare threat volumes across brands, aggregate metrics for reporting, maintain consistent policies across brands.
+
+**Flexible Structure** - Add new brands as you grow, reorganize brands as needed, merge or split brands, maintain historical data.
+
+## Key Takeaways
+
+- Brand structure enables targeted monitoring: Separating your company brand from product brands or executive brands lets you configure different detection rules and thresholds for each
+- Automatic threat attribution provides context: When a threat targets a specific brand, automatic assignment helps prioritize response based on which identity is under attack
+- Terms and images drive detection accuracy: Comprehensive brand definitions with common misspellings and visual assets improve automated detection while reducing false positives
+- Multiple brands under one organization maintain central oversight: Individual brand teams can manage their protection while organization admins retain visibility and control across all brands
diff --git a/concepts/detections.mdx b/concepts/detections.mdx
new file mode 100644
index 0000000..04990bf
--- /dev/null
+++ b/concepts/detections.mdx
@@ -0,0 +1,97 @@
+---
+title: "Detections"
+description: "How ChainPatrol automatically identifies potential security threats"
+---
+
+## Overview
+
+A **detection** is a potential security threat that has been automatically identified by ChainPatrol's monitoring system. When a detection source discovers suspicious content that may be impersonating your brand or attempting to defraud users, it creates a detection record for your security team to review.
+
+Detections represent automated findings from ChainPatrol's continuous monitoring across the internet.
+
+### Components of a Detection
+
+Each detection contains:
+
+- **Asset** - The specific URL, social account, or content identified
+- **Source** - Which detection source discovered it
+- **Score** - Confidence level (0-1) indicating likelihood of being malicious
+- **Reason** - Why it was flagged and which rules triggered
+- **Organization** - Your organization being targeted
+- **Timestamp** - When the threat was first detected
+- **Status** - Current state (reported, under review, awaiting action)
+
+## Detection Lifecycle
+
+1. **Discovery** - A detection source finds content matching your monitoring keywords or patterns. For example, Google Search detects a website containing your brand name plus terms like "airdrop" or "claim tokens".
+
+2. **Asset Processing** - The discovered asset is automatically submitted to ChainPatrol's analysis pipeline, where it creates or retrieves the asset record, validates the asset hasn't already been marked as legitimate (allowed), and checks for duplicate detections.
+
+3. **Scanning & Enrichment** - The asset undergoes comprehensive scanning to gather intelligence including content analysis (webpage screenshots, HTML content, metadata extraction, text and image analysis), network data (DNS records, IP addresses, hosting information, CDN and infrastructure), domain registration (WHOIS data, registration date, registrar information, historical records), platform data (social media profiles, app store information, platform metadata, account details), visual analysis (logo detection, similarity matching, brand element identification, visual fingerprinting), and blockchain data (smart contract analysis, token information, transaction patterns, wallet connections).
+
+4. **Rule Evaluation** - The system executes dozens of detection rules against the enriched asset data. Each rule evaluates specific threat indicators like domain age (newly registered domains < 30 days old), visual similarity (logo or design mimicking your brand), text similarity (URLs or names that closely match yours), threat intelligence (known malicious infrastructure or patterns), and behavioral indicators (wallet drainer code, phishing forms).
+
+5. **Scoring** - Based on rule results, the system calculates a threat score (0-1) representing confidence that the asset is malicious. Rules are grouped by category (Visual Similarity, Threat Intelligence, Domain Age, Text Matching, Behavioral Analysis), each rule has a confidence level (Very Low to Very High), and weighted scores are combined across all triggered rules with organization-specific adjustments applied.
+
+6. **Detection Creation** - A detection record is created in the database with all gathered intelligence.
+
+7. **Auto-Reporting (Optional)** - If your organization has auto-reporting enabled and the detection score exceeds your medium threshold, the system can automatically create a report with the detected asset, mark the asset as blocked, submit takedown requests (if configured), and send notifications to your team.
+
+<Warning>
+**Auto-Reporting Requirements:** Score must meet or exceed your medium threshold, detection source must be enabled, asset must not already be blocked, and asset must not have been previously rejected multiple times.
+</Warning>
+
+## Confidence Levels
+
+Detections are categorized into confidence levels based on your organization's thresholds:
+
+### None (Score 0 to Low Threshold)
+
+Low confidence detections. May be false positives or tangentially related to your brand. Useful for monitoring trends but rarely require action. Examples include generic mention of your brand in unrelated context, weak keyword matches, and minimal similarity indicators.
+
+### Low (Low Threshold to Medium Threshold)
+
+Some indicators suggest a potential threat, but evidence is limited. Requires manual review to confirm. Common scenarios include domain contains your brand name but has legitimate business purpose, social media mentions your brand in neutral context, and weak visual or textual similarity.
+
+### Medium (Medium Threshold to High Threshold)
+
+Strong indicators of malicious intent. Multiple detection rules triggered with reasonable confidence. Common scenarios include new domain with brand name and suspicious keywords, social media account impersonating your brand with stolen logo, and token contract with similar name on blockchain. This is the typical threshold for automatic reporting and blocking.
+
+### High (High Threshold and above)
+
+Very strong evidence of malicious activity. Multiple high-confidence rules triggered. Common scenarios include perfect visual replica of your website, domain nearly identical to yours (typosquatting), known phishing infrastructure, and contains wallet drainer code. High confidence detections require immediate attention and rapid response.
+
+## Understanding Detection Groups
+
+Detections can be grouped together using a **Group ID** to represent related threats discovered from a single source.
+
+### Relationship Extraction
+
+When analyzing an asset, the system may discover additional related threats:
+
+- **Linked URLs** - A phishing page that links to multiple other scam domains
+- **Redirects** - A URL that redirects through several malicious domains
+- **Related Accounts** - Social media posts that mention multiple scam websites
+
+All related detections share the same group ID, making it easy to identify and report entire phishing campaigns at once.
+
+### Campaign Tracking
+
+Group IDs help you identify campaigns (recognize coordinated phishing campaigns), track infrastructure (map relationships between threats), report networks (report entire attack networks simultaneously), and understand tactics (analyze attacker tactics and patterns).
+
+## Deduplication
+
+The system automatically handles duplicate detections to prevent alert fatigue:
+
+**Same Asset, Same Organization** - If the same asset is detected multiple times by the same source for your organization, only one detection record is kept to prevent alert fatigue from repeated discoveries.
+
+**Same Asset, Different Sources** - If multiple detection sources independently find the same threat, separate detection records are created. This helps validate threat confidence (multiple sources agree), understand which sources are most effective, and track how threats spread across platforms.
+
+**Different Assets, Same Campaign** - Related assets in the same attack campaign are linked via group IDs but maintained as separate detections. This allows you to report each asset individually, track takedown progress per asset, and understand campaign scope.
+
+## Key Takeaways
+
+- Detection is the entry point, not the decision: A detection indicates potential threat, but review and approval are required before blocking to prevent false positives
+- Group IDs reveal campaign scope: When one detection links to multiple related assets, you can identify and report entire phishing campaigns instead of blocking sites one at a time
+- Threshold configuration balances coverage and noise: Lower thresholds catch more threats but require more review, while higher thresholds miss edge cases but reduce workload
+- Deduplication across sources increases confidence: When multiple independent detection sources flag the same asset, it provides stronger evidence of malicious intent
diff --git a/concepts/legal-docs.mdx b/concepts/legal-docs.mdx
new file mode 100644
index 0000000..679a01d
--- /dev/null
+++ b/concepts/legal-docs.mdx
@@ -0,0 +1,186 @@
+---
+title: "Legal Docs"
+description: "Understanding legal documentation for takedown requests"
+---
+
+## Overview
+
+**Legal documents** are official documents that prove a company's ownership rights, authorization, or identity when requesting the removal of harmful or fraudulent content.
+
+<Info>
+Many online platforms require verified legal documentation before they will act on a takedown request, especially when dealing with impersonation, trademark misuse, or brand-related abuse.
+</Info>
+
+### Why They're Required
+
+These documents help providers confirm that the takedown request is legitimate and submitted by an authorized party.
+
+- **Verify Identity** - Confirm the requesting party represents the organization
+- **Prove Ownership** - Demonstrate legitimate ownership of brand or trademark
+- **Establish Authority** - Show authorization to request content removal
+
+## Types of Legal Documents
+
+ChainPatrol typically works with the following categories of legal documentation:
+
+### Trademark Registration
+
+Official documentation proving that an organization legally owns a brand name, logo, or trademark.
+
+**When It's Required:**
+- Content is impersonating a brand
+- Misusing protected intellectual property
+- Claiming false association with trademark
+- Using brand elements without authorization
+
+**What It Includes:**
+- Trademark registration number
+- Registration date and jurisdiction
+- Description of protected marks
+- Visual representations (logos, wordmarks)
+- Goods and services covered
+
+**Common Formats:**
+- USPTO registration certificates (United States)
+- EUIPO certificates (European Union)
+- National trademark office documents
+- International (Madrid Protocol) registrations
+
+Providers often require this when content is impersonating a brand or misusing protected intellectual property.
+
+### Letter of Authorization (LOA)
+
+A document in which the brand owner declares that ChainPatrol is authorized to submit takedown requests on their behalf.
+
+**Key Components:**
+- Organization's legal name and details
+- Statement of authorization
+- Specific actions ChainPatrol is authorized to perform
+- Authorized representative's signature
+- Date of authorization
+- Contact information
+
+**Typical Use Cases:**
+- Social media takedowns (especially Twitter/X)
+- App store removal requests
+- Hosting provider complaints
+- General brand protection activities
+
+**Example Statement:**
+> "[Organization Name] hereby authorizes ChainPatrol to submit takedown requests, abuse reports, and content removal requests on our behalf for the purpose of protecting our brand and trademarks from impersonation, fraud, and unauthorized use."
+
+LOAs are typically simpler and faster to obtain than Power of Attorney documents.
+
+### Power of Attorney (POA)
+
+A formal legal authorization allowing ChainPatrol to act for the organization in a broader or more formal capacity.
+
+**Key Differences from LOA:**
+- More formal legal standing
+- Broader scope of authority
+- Often notarized or witnessed
+- Recognized across more jurisdictions
+- Required for high-impact actions
+
+**When It's Required:**
+- Domain suspensions
+- TLD-level takedowns
+- Registrar-level actions
+- High-impact or escalated cases
+- International jurisdictions
+
+**What It Authorizes:**
+- Filing formal legal complaints
+- Representing the organization in takedown proceedings
+- Making binding statements on behalf of the organization
+- Escalating to legal authorities if needed
+
+Some providers require a POA for escalated or high-impact takedowns such as domain suspensions.
+
+### Document Usage Across Platforms
+
+**Website Takedowns** (hosting providers and registrars) typically require trademark registration, LOA or POA, and business registration documents to verify legitimate brand ownership and confirm authorization to request removal.
+
+**Social Media Takedowns** (Twitter/X, Facebook, Instagram) typically require LOA (especially for Twitter/X), trademark registration (for verified impersonation), and government-issued ID (for individual impersonation) to prevent abuse of reporting systems and verify authorized representatives.
+
+**App Store Takedowns** (Google Play, Apple App Store) typically require trademark registration, LOA or POA, and proof of brand ownership to verify app infringement and confirm authorization to request removal.
+
+**TLD-Level Takedowns** (top-level domain registries) typically require POA (formal authorization), trademark registration, and detailed evidence of abuse due to the high-impact nature of entire domain suspension and legal liability considerations.
+
+## What Legal Documents Are Used For
+
+Legal documents are attached to takedown submissions so platforms can verify that:
+
+1. The requesting party truly represents the organization
+2. The brand or trademark is legitimately owned
+3. ChainPatrol has the authority to request removal of the content
+4. The takedown request complies with the provider's legal requirements
+
+<Warning>
+Without these documents, many providers may refuse or delay action on a takedown request.
+</Warning>
+
+## How Legal Documents Are Stored
+
+All legal documentation provided to ChainPatrol is handled with strong security controls.
+
+### Secure Storage
+
+Legal documents are stored in a secure storage bucket designed specifically to protect sensitive files.
+
+**Security measures:**
+- Restricted access (only authorized systems and personnel)
+- Encryption (data encrypted at rest and in transit)
+- Isolated storage (separated from general application data)
+- Access logging (all access attempts are logged)
+- Audit trail (complete history of document usage)
+- Compliance (meets industry security standards)
+
+### Limited Access
+
+Only authorized ChainPatrol systems and personnel can access these documents.
+
+**Who has access:**
+- Takedown specialists (when processing requests)
+- Legal team members (for review and verification)
+- Authorized support staff (for customer assistance)
+- Automated systems (for document attachment during submission)
+
+**Access controls:**
+- Role-based permissions
+- Multi-factor authentication required
+- Access logged and monitored
+- Regular access reviews
+
+Documents are used solely for the purpose of supporting takedown submissions.
+
+### Usage Policy
+
+Legal documents are not directly part of the takedown object. They are applied only during the submission process when a provider requires them.
+
+**How it works:**
+
+1. Takedown request is created for a malicious asset
+2. System determines which provider to contact
+3. System checks if provider requires legal documentation
+4. If required, appropriate documents are automatically attached
+5. Complete takedown request with documentation is submitted
+
+This approach minimizes unnecessary exposure of sensitive documents while ensuring they're available when needed.
+
+## Document Management Best Practices
+
+**Keep Documents Current** - Update POA/LOA documents annually, refresh after organizational changes, update contact information promptly, and renew before expiration dates. Expired or outdated documents can delay takedown processing.
+
+**Maintain Multiple Formats** - Keep documents in PDF (most common), scanned originals, notarized copies (for POA), and translated versions (for international takedowns) since different providers have different requirements.
+
+**Coordinate with Legal Team** - Have legal team review documents, ensure authorized signatories, verify scope of authorization, and confirm compliance with company policies.
+
+**Track Document Usage** - Track which providers accept which documents, note any rejection reasons, update documents based on feedback, and maintain records of successful takedowns.
+
+## Key Takeaways
+
+- Legal documentation gates takedown success: Most providers require proof of ownership and authority before removing content, so having documents ready accelerates response times
+- Different providers demand different documents: Domain registrars typically want trademark registration, social platforms often need POA, and some hosting providers accept LOA
+- Current documents prevent delays: Expired trademarks or outdated authorizations will be rejected, forcing resubmission and extending the time malicious content stays live
+- Security is critical for sensitive documents: Trademark registrations and POAs contain business-critical information, so proper encryption and access controls protect against leaks
diff --git a/concepts/metrics.mdx b/concepts/metrics.mdx
new file mode 100644
index 0000000..8f1fe1e
--- /dev/null
+++ b/concepts/metrics.mdx
@@ -0,0 +1,106 @@
+---
+title: "Metrics"
+description: "Understanding how ChainPatrol measures and reports threat protection"
+---
+
+## Overview
+
+<Info>
+**Metrics** are the high-level numbers and charts ChainPatrol shows to summarize how many threats we're seeing, how many we've blocked or taken down, and how quickly we're responding over a chosen time period.
+</Info>
+
+They are built by aggregating your organization's activity (reports, detections, blocked assets, takedowns) into simple, readable summaries.
+
+### Why It Matters
+
+Metrics help you answer **"Are we protected?"** by showing threat volume, coverage, and response quality to your internal stakeholders and, when enabled, to external audiences via your Security Portal.
+
+## Key Characteristics
+
+### Organization-Specific
+
+Metrics are always calculated for a specific organization and reflect only that organization's reports, threats, and takedown activity. You only see your organization's data with no cross-organization visibility, customized to your brands and assets, reflecting your specific threat landscape.
+
+### Time-Bound
+
+Every metrics view uses a time window (e.g., "last 30 days" or a custom range). Common time periods include last 7 days, last 30 days, last 90 days, and custom date ranges. The same metric (e.g., "New Threats") may look very different depending on the period you select.
+
+### Filterable
+
+Many metrics can be filtered by brand and broken down by:
+
+**Asset Type** - Domains, Twitter/X, Telegram, other platforms
+
+**Threat Category** - Brand impersonation, employee impersonation, general phishing, specific attack types
+
+### Components
+
+**Counts** - Reports received, new threats blocked, threats on watchlist, takedowns filed, takedowns completed
+
+**Breakdowns** - Threats by asset type, threats per brand, detections by source, category distributions
+
+**Timelines and Speed** - Threats blocked per day, takedowns completed per day, median time to takedown, trend analysis
+
+## What Lives Inside Metrics
+
+### Core Volume Metrics
+
+- **Reports** - How many submissions your organization received from users, partners, and integrations
+- **New Threats** - How many assets were blocked as threats (domains, social profiles, Telegram channels, etc.)
+- **Threats Watchlisted** - Threats you're actively watching (takedowns not appropriate or on hold)
+- **Takedowns Filed** - How many takedown requests your organization has initiated
+- **Takedowns Completed** - How many takedown requests have been successfully resolved
+
+### Threat Breakdowns
+
+**By Asset Type:**
+
+- **Domain Threats** - Blocked malicious domains and URLs (phishing websites, fake landing pages, impersonation sites, malicious web applications)
+- **Twitter Threats** - Blocked threats on Twitter/X (impersonation accounts, scam posts, fake support accounts, fraudulent giveaways)
+- **Telegram Threats** - Blocked threats on Telegram (fake support channels, scam groups, impersonation accounts, phishing bots)
+- **Other Threats** - Blocked threats on all other supported surfaces (app stores, other social networks, developer platforms, email addresses, blockchain addresses)
+
+**By Brand:**
+
+Threats blocked per brand inside your organization, showing which brands are targeted more heavily. Use this to identify most-targeted brands, allocate protection resources, track brand-specific campaigns, and compare threat levels across portfolio.
+
+### Time-Series and Speed Metrics
+
+**Threats Blocked Per Day** - Shows how many assets were blocked on each day in the selected range. Helps identify threat spikes, track seasonal patterns, measure detection effectiveness, and spot coordinated campaigns.
+
+**Takedowns Completed Per Day** - Shows how many takedowns reached "completed" status on each day. Helps track takedown velocity, measure provider responsiveness, identify bottlenecks, and monitor team efficiency.
+
+**Median Time to Takedown** - Calculated from when a takedown request is created to when it is first marked completed. Available as overall median, by asset type (domains, social media, etc.), and by threat category (brand vs. employee impersonation). Lower median times indicate faster threat removal and better provider relationships.
+
+## How Metrics Relate to Other Concepts
+
+**Assets and Asset Scans** - When asset scans and reviews lead to an asset being blocked, that asset contributes to metrics such as New Threats, Threats by asset type, and Threats blocked per day. Ongoing scans and liveness updates ensure that metrics reflect the current state of your threat surface.
+
+**Threats / Detections** - Every detection or blocked asset rolls up into counts like new threats, detections by type, and domains blocked. Metrics summarize how much malicious activity is being found and neutralized for your organization over time.
+
+**Reports and Reviews** - Reports raised by your team or users drive the Reports metric. Review outcomes (e.g., approving a threat as real and blocking it) flow into threat and takedown metrics. Shows how well your review process is keeping up with incoming threats.
+
+**Takedowns** - Takedown records power Takedowns Filed, Takedowns Completed, and Median time to takedown per asset type and category. These metrics show how quickly threats are being removed once identified.
+
+**Brands and Services** - Metrics can be filtered by brand to show which brands are most targeted. Enabling services like detection, reviewing, takedowns, and wallet blocking typically increases visibility in metrics (more threats found, blocked, and removed). Higher threat counts don't mean you're less secure; they mean you're detecting more threats that were always there.
+
+## Examples
+
+### Example 1: Quarterly Threat Overview
+
+For executive reporting, you select "Last 90 days" on the Metrics page. The dashboard shows reports received (245), new threats blocked (187), takedowns filed (142), takedowns completed (128), plus charts of threats blocked per day. You share these numbers with leadership to summarize malicious activity detected and action taken. Key insights: 76% of reports resulted in blocked threats, 90% of takedowns were completed, average of 2 threats blocked per day.
+
+### Example 2: Domains vs. Social Threats
+
+For threat landscape analysis, you compare threat counts for the last month: Domain Threats (45, down from 60 last month), Twitter Threats (30, stable), Telegram Threats (55, up from 35 last month), Other Threats (20, stable). You see that domain threats have decreased while Telegram threats have increased, and adjust your monitoring and communication plans accordingly—increase Telegram monitoring frequency, alert community about Telegram scams, investigate why attackers shifted platforms.
+
+### Example 3: Takedown Speed Analysis
+
+For provider performance review, you analyze median time to takedown by asset type: Domains (48 hours), Twitter (24 hours), Telegram (18 hours), App stores (72 hours). Insights: Social platforms respond faster than hosting providers, app stores have longest response times, Telegram is most responsive. Actions: Focus on improving domain takedown speed, investigate app store delays, document Telegram best practices.
+
+## Key Takeaways
+
+- Metrics reveal protection gaps: Tracking detections by channel shows where attackers focus, helping you prioritize monitoring efforts on platforms with highest threat activity
+- Time-based analysis identifies campaign patterns: Sudden spikes in detections often indicate coordinated campaigns, while steady increases suggest growing attacker interest
+- Speed metrics drive operational improvements: Median time to block and takedown completion times help identify bottlenecks in your response process
+- Filtering enables strategic decisions: Breaking down metrics by brand, asset type, or threat category reveals which parts of your organization face the most risk
diff --git a/concepts/organizations.mdx b/concepts/organizations.mdx
new file mode 100644
index 0000000..2bebf0d
--- /dev/null
+++ b/concepts/organizations.mdx
@@ -0,0 +1,134 @@
+---
+title: "Organizations"
+description: "Understanding your workspace in ChainPatrol"
+---
+
+## Overview
+
+Everything you see and do in ChainPatrol happens inside an **Organization**. Think of it as your team's dedicated workspace where you manage your brands, track your assets, and measure how ChainPatrol is protecting you from threats.
+
+<Info>
+An organization is the top-level container for all your security operations, team members, and protected assets in ChainPatrol.
+</Info>
+
+## How ChainPatrol Manages Security for You
+
+ChainPatrol is a **fully managed security product**. This means our team handles the heavy lifting:
+
+- **Day-to-Day Threat Hunting** - Continuous scanning across platforms
+- **Suspicious Activity Review** - Expert analysis of potential threats
+- **Attack Analysis** - Detailed evaluation of threat patterns
+- **Takedown Filing** - Professional requests to providers and platforms
+
+You don't need to become a security expert or dedicate staff to monitor threats around the clock. We do that work for you.
+
+### Your Level of Involvement
+
+That said, you're not locked out of the process. If you want your team to be more hands-on, you can:
+
+- **Invite Members** - Invite team members into your organization's dashboard with customized permissions and roles
+- **Report Threats** - Your team can report threats they discover through the dashboard or integrations
+- **Approve or Decline** - Review and approve specific takedowns or blocklist decisions before they take effect
+- **Connect Tools** - Integrate Slack, Telegram, SSO, and other tools to fit ChainPatrol into your existing workflows
+
+You decide how involved you want to be, from fully hands-off to deeply integrated with your team's operations.
+
+## Brands and Assets
+
+Every organization has one or more **brands** that ChainPatrol protects.
+
+### What is a Brand?
+
+A brand could be your company name, a product line, your executives or key personnel, or a key identity that attackers might try to impersonate.
+
+We use brands to detect **brand impersonation** attacks including lookalike domains, fake social profiles, scam campaigns borrowing your brand's name, and imagery or messaging designed to trick people.
+
+### What are Assets?
+
+In addition to brands, your organization also has **assets**, the digital properties that actually belong to you:
+
+- **Websites** - Domains and web applications
+- **Social Accounts** - Twitter, Discord, Telegram, etc.
+- **App Listings** - App store and extension marketplace listings
+- **Wallet Addresses** - Blockchain addresses and contracts
+- **Email Addresses** - Official company and team emails
+- **Other Properties** - GitHub repos, forums, documentation sites
+
+We track your official assets so we can spot copycats and general phishing pages that mimic your legitimate sites or channels. When we find something suspiciously similar to your assets but not actually yours, it gets flagged for review.
+
+## Services You Can Enable
+
+Each organization can turn individual services on or off depending on what you need. These services control which ChainPatrol features are active for your organization:
+
+### Detection
+
+Enables ChainPatrol's automated scanning across the web, social platforms, app stores, and other sources. When this is turned on, we continuously look for new threats targeting your brands. This is the foundation service (required for all other services).
+
+### Monitoring & Reporting
+
+Activates the systems that collect and organize reports and detections into a single view. This powers your dashboards and ensures you have up-to-date visibility into what's happening. Recommended for all organizations.
+
+### Reviewing
+
+Turns on ChainPatrol's review workflows, where our team validates suspicious assets and decides whether they should be blocked, allowed, watchlisted, or escalated. Recommended for accuracy and quality control.
+
+### Obligatory Organization Admin Approval
+
+Adds a final approval step for specific types of assets. When enabled, you choose which asset categories (like domains, social media, or messaging platforms) require explicit confirmation from an admin in your organization before ChainPatrol's blocklist decisions take effect. If you don't select any specific types, all asset types will require approval. This is optional, for organizations requiring internal oversight.
+
+### Wallet Blocking
+
+Allows approved crypto-related threats to be added to ChainPatrol's global blocklist, which is consumed by partner wallets like Coinbase Wallet and MetaMask to protect their users from known malicious addresses. Essential for Web3 organizations.
+
+### Takedowns
+
+Enables ChainPatrol to file takedown requests with hosting providers, registrars, and platforms on your behalf. When this service is on, we don't just block threats but work to get them removed from the internet entirely. Requires legal documentation (trademark proof, authorized representative details). Recommended for comprehensive protection.
+
+### Automated Takedowns
+
+Speeds up the takedown process for clear-cut cases. Once you've provided the required legal documents (like a Power of Attorney) and your main website URL, ChainPatrol can automatically submit takedown requests for approved threats without waiting for manual back-and-forth on every case. Requires Power of Attorney document, main website URL, and all other services enabled. This is an advanced feature for high-volume threat environments.
+
+Learn more about configuring these services in our [Services Setup guide](/protect-your-brand/services-setup).
+
+## Members, Roles, and Permissions
+
+You control who can access your organization and what they're allowed to do.
+
+### How It Works
+
+1. Invite team members into your organization's dashboard
+2. Assign them roles that determine their access level
+3. Configure specific permissions for what they can do
+4. Retain ultimate control over approvals and sensitive actions
+
+### What Permissions Control
+
+- **Threat Reporting** - Ability to report and submit threats
+- **Blocklist Approvals** - Approve or reject blocklist changes
+- **Settings Management** - Modify organization settings and configuration
+- **Sensitive Information** - View confidential data and reports
+- **Service Control** - Enable or disable organization services
+- **Member Management** - Invite, remove, or modify team members
+
+<Warning>
+This permission system ensures that potentially destructive actions (like turning on Wallet Blocking or Automated Takedowns) only happen with your organization's explicit permission.
+</Warning>
+
+ChainPatrol's staff handle the day-to-day security operations, but you retain ultimate control over approvals, visibility, and how the platform integrates with your team.
+
+## Organization Structure
+
+### Typical Organization Hierarchy
+
+**Single Brand** - Most organizations have a single brand with one company identity, all assets under one brand, and straightforward management. Example: A startup protecting their main product.
+
+**Multiple Brands** - Some organizations manage multiple brands including parent company + subsidiaries, multiple product lines, acquired companies, and regional brands. Example: A holding company protecting multiple portfolio companies.
+
+**Enterprise** - Large enterprises may have multiple brands, hundreds or thousands of assets, complex approval workflows, and multiple teams with different permissions. Example: A Fortune 500 company with global operations.
+
+## Key Takeaways
+
+- Organizations provide centralized visibility across brands: One dashboard shows threat activity for all your brands, products, and executives instead of fragmented monitoring
+- Service toggles let you start simple and expand: Begin with monitoring and manual blocking, then enable automated detection, takedowns, and API access as needs grow
+- Role-based permissions balance access and security: Admins can configure settings and approve blocks, while reporters can submit threats without changing system configuration
+- Managed service means no infrastructure to maintain: ChainPatrol handles detection sources, review workflows, and provider relationships so you focus on decisions, not operations
diff --git a/concepts/reports.mdx b/concepts/reports.mdx
new file mode 100644
index 0000000..2d9ff8d
--- /dev/null
+++ b/concepts/reports.mdx
@@ -0,0 +1,121 @@
+---
+title: "Reports"
+description: "How suspicious or safe activity gets submitted to ChainPatrol for review"
+---
+
+## Overview
+
+A **Report** is how suspicious or safe activity gets submitted to ChainPatrol for review. Each report bundles together one or more assets, like websites, social profiles, or crypto addresses, along with the evidence needed to evaluate them.
+
+<Info>
+When you create a report, you're proposing that specific assets should either be **blocked** (because they're malicious) or **allowed** (because they're safe).
+</Info>
+
+### What a Report Contains
+
+- **Assets** - One or more URLs, profiles, or addresses
+- **Context** - Title and description explaining the threat
+- **Evidence** - Screenshots and supporting materials
+
+## When Reports Get Created
+
+Reports flow into ChainPatrol from multiple sources:
+
+### Manual Submission
+
+Your team or ChainPatrol staff can create reports directly in the dashboard whenever they spot something suspicious. Organization members, ChainPatrol staff, and security team members can create reports for discovered threats, community-reported issues, and proactive monitoring.
+
+### Public Portal
+
+When your organization has a public Security Portal enabled, anyone can submit a report through the public submission form. Reports are automatically flagged as customer reports with no login required. This enables community-powered detection, early threat discovery, and user engagement.
+
+### API Integration
+
+Through the API, integrations or partners can submit threats programmatically for automated monitoring tools, partner integrations, custom workflows, and bulk submissions. See our [API documentation](/external-api/report-create) for integration details.
+
+### Automated Detection
+
+ChainPatrol's systems continuously scan the web, social platforms, and other sources for threats through continuous monitoring, automatic report creation, pre-analyzed evidence, and instant submission. We monitor 50+ platforms 24/7 with real-time detection.
+
+## How Reports Get Reviewed
+
+Every report that comes into your organization is reviewed by ChainPatrol's team.
+
+1. **Evidence Review** - Reviewers examine the evidence, screenshots, and context provided
+2. **Security Checks** - Run automated security scans and analysis on the reported assets
+3. **Decision** - Decide whether each asset should be Blocked (confirmed malicious), Allowed (confirmed legitimate), Watchlisted (monitored for changes), or Escalated (requires additional investigation)
+4. **Action** - Apply the decision and update asset status
+
+### Automatic Review
+
+In some cases, the review happens automatically:
+
+**High Confidence Detection** - When our systems have extremely high confidence that an asset is malicious (known wallet drainer script detected, exact copy of known phishing site, matches multiple high-confidence rules), it's approved immediately without manual validation.
+
+**Trusted Reporter** - When the report comes from someone we've marked as a trusted reporter (verified security researchers, trusted partner organizations, ChainPatrol staff), it's fast-tracked for approval.
+
+### Organization Admin Approval
+
+<Warning>
+If you've enabled **Obligatory Organization Admin Approval** for certain types of assets, there's an extra step.
+</Warning>
+
+Even after ChainPatrol's team approves a report, the changes won't be applied to your blocklist until someone from your organization with admin permissions confirms them:
+
+1. ChainPatrol reviews and approves the report
+2. Report waits for organization admin confirmation
+3. Your admin reviews and approves or rejects
+4. Asset status is updated based on final decision
+
+## Report Status
+
+Reports move through three stages as they're processed:
+
+- **TODO** - The report is waiting in the queue for review
+- **IN_PROGRESS** - ChainPatrol staff or automated systems are actively reviewing it
+- **CLOSED** - The review is complete and decisions have been made on all assets
+
+## Finding Your Reports
+
+The **Reports page** in your dashboard shows all the reports for your organization, whether they're pending review, currently being worked on, or already closed.
+
+You can filter and search by creator, date, asset, and status to track the status of something you reported or follow up on threats flagged by your community.
+
+## How to Submit a Report
+
+Creating a report in ChainPatrol is straightforward:
+
+1. **Click Create Report** - Start by clicking **Create Report** from the dashboard
+
+2. **Add Assets** - Paste in the assets you want to report, one per line: URLs (e.g., `https://fake-metamask.com`), social media profiles (e.g., `@fake_support`), blockchain addresses (e.g., `0x123...`), or any other asset type ChainPatrol monitors. The system automatically figures out what kind of asset each one is.
+
+3. **Add Context** - Provide a title summarizing what you're reporting and a description explaining why these assets are suspicious, how you found them, and any relevant details.
+
+4. **Upload Evidence** - Upload screenshots of malicious content, user reports or messages, social media posts, or any supporting documentation. Visual evidence helps reviewers quickly understand what's going on and speeds up the review process.
+
+5. **Submit** - Hit Submit and your report goes into the review queue
+
+### What Happens Next
+
+**Immediately** - Report enters TODO status, you receive confirmation, report appears in your dashboard, and ChainPatrol team is notified.
+
+**During Review** - Status changes to IN_PROGRESS, assets are scanned and analyzed, evidence is evaluated, and decisions are made.
+
+**After Review** - Status changes to CLOSED, asset statuses are updated, you're notified of the outcome, and actions are taken (blocking, allowing, etc.).
+
+## Report Best Practices
+
+**Provide Clear Context** - Include how you discovered the threat, why you believe it's malicious, any user reports or complaints, and timeline of when it appeared.
+
+**Include Visual Evidence** - Capture the full page or profile, specific malicious elements, user-facing content, and screenshots before it gets taken down.
+
+**Report Promptly** - The sooner you report a threat, the sooner it can be blocked, providing faster protection for users and less time for scammers to operate.
+
+**Group Related Assets** - If multiple assets are part of the same campaign, report them together so reviewers see the full picture for more efficient review and coordinated response.
+
+## Key Takeaways
+
+- Multi-asset reports capture campaign scope: Grouping related threats in one report helps reviewers understand attack patterns and makes blocking entire campaigns more efficient
+- Context accelerates review decisions: Reports with screenshots, explanations, and evidence of harm move through review faster than bare URLs with no context
+- Three submission methods serve different needs: Manual reports for ad-hoc discoveries, API reports for automated detection systems, and portal reports for community submissions
+- Report status tracks progress without micromanagement: TODO, IN_PROGRESS, and CLOSED states provide visibility while letting the security team work without constant updates
diff --git a/concepts/reviews.mdx b/concepts/reviews.mdx
new file mode 100644
index 0000000..b73dfe9
--- /dev/null
+++ b/concepts/reviews.mdx
@@ -0,0 +1,161 @@
+---
+title: "Reviews"
+description: "How ChainPatrol evaluates and makes decisions on reported threats"
+---
+
+## Overview
+
+A **review** is a decision made on a **proposal** to either block or allow a reported asset. When someone reports a potentially malicious website, social media account, or other digital asset, ChainPatrol creates a proposal that requires review before taking action.
+
+<Info>
+Think of a review as the approval or rejection of a recommendation to block a threat.
+</Info>
+
+### Components of a Review
+
+Each review consists of:
+
+- **Decision** - Approve, reject, skip, or escalate
+- **Label** - Type of threat (e.g., phishing, brand impersonation)
+- **Comment** - Optional reasoning explanation
+- **Reviewer** - Who made the decision
+- **Timestamp** - When the review was made
+
+## Who Can Review?
+
+### ChainPatrol Staff
+
+Our security analysts who review reports for all customers. They can review all reports, create, read, and delete reviews, apply expert threat analysis, and handle complex cases.
+
+### Trusted Reporters
+
+Verified security researchers and partners who have demonstrated expertise in threat identification. They can submit high-confidence reports, receive auto-approval for trusted submissions, create and read reviews, and fast-track threat blocking.
+
+### Customer Administrators
+
+Admins and owners of customer organizations who can review reports for their own brand. They can review reports for their organization, approve or reject proposals, have final say on blocklist decisions, and override escalations.
+
+### Automated System
+
+Our automation system that can auto-approve certain high-confidence threats. It provides instant review of clear threats, threat score calculation, pattern recognition, and 24/7 operation.
+
+## Review Actions
+
+There are four types of review decisions:
+
+### Approve
+
+Confirms that the reported asset is malicious and should be blocked. The asset is added to ChainPatrol's blocklist, distributed to integrated platforms, takedown process is initiated (if enabled), and the organization is notified. Use when there's clear evidence of malicious activity, high confidence in threat assessment, and asset matches known attack patterns.
+
+### Reject
+
+Indicates the reported asset is legitimate and should not be blocked. Common reasons include the asset is actually official (false positive), the threat has already been removed, insufficient evidence of malicious activity, or misidentification. The proposal is closed and the asset remains unblocked.
+
+### Skip
+
+Reviewer cannot make a definitive decision yet. This keeps the proposal in a pending state for another reviewer to examine. Common reasons include insufficient evidence to confirm or deny the threat, need for additional context or investigation, waiting for asset to load or become accessible, or requires more specialized expertise.
+
+### Escalate
+
+Passes the review decision to another party for final judgment.
+
+**Escalate to Customer** - Requests the brand owner to review and decide. Used when staff reviewers are uncertain, asset type requires customer approval, or content is ambiguous. The customer team receives notifications (Slack/Discord) and the proposal stays pending until customer decides.
+
+**Escalate to Team** - Passes to senior ChainPatrol analysts. Used when customer administrators are uncertain, complex cases require expert review, or there are multiple conflicting signals. Routes to senior security analysts for in-depth analysis and final decision.
+
+## Automated Review
+
+The ChainPatrol automation system automatically reviews proposals under specific conditions:
+
+### Auto-Approval Criteria
+
+A proposal is automatically approved when:
+
+1. **Trusted Reporter Submissions** - Reports from trusted reporters are auto-approved if they don't trigger legitimacy warnings
+2. **High Threat Score** - Reports with sufficiently high threat scores are auto-approved if no legitimacy checks indicate the asset is legitimate, the organization doesn't require customer approval, and there's no active dispute on the report
+
+### Auto-Skip Criteria
+
+A proposal is automatically skipped (sent for manual review) when:
+
+- High-confidence rules indicate the asset appears legitimate
+- The threat score is below the auto-approval threshold
+- Organization settings require manual approval from their team
+- Someone has disputed the report
+- Too many auto-approvals in a short time period
+
+### Threat Scoring
+
+The automation system calculates a threat score by analyzing multiple factors.
+
+**Brand Impersonation** signals include visual similarity to known brands, logo matching, name and text similarity, domain typosquatting, and profile impersonation (score range 0.0 - 1.0+).
+
+**General Phishing** indicators include credential harvesting forms, suspicious URL patterns, malicious links, social engineering tactics, and wallet connection scams (score range 0.0 - 1.0+).
+
+**Score Calculation** - The system combines scores from different detection categories. Multiple detections across categories increase confidence while preventing artificial score inflation.
+
+## Evidence Reviewed
+
+When making a review decision, reviewers examine multiple types of evidence:
+
+**Detection Rules** - ChainPatrol runs automated detection rules that check for brand impersonation (logos, names, visual similarity), phishing indicators (credential forms, suspicious URLs), legitimacy signals (official certificates, verified accounts, trusted hosting), and blockchain threats (fake wallet connections, transaction scams).
+
+**Asset Scans** - Screenshots and HTML snapshots showing visual appearance of the website or profile, page content and text, forms and input fields, external links and resources, and network requests and behavior.
+
+**Report Context** - Information from the person who submitted the report including description of the threat, reporter's identity and trust level, attachments and supporting evidence, report source (form, API, integration), and timeline of discovery.
+
+**Historical Data** - Past activity related to the asset including previous reports of the same or similar assets, takedown history, related threats from the same infrastructure, and pattern analysis across campaigns.
+
+## How to Revert a Review
+
+Reviewers can revert their review decisions within **5 minutes** of submission. This safety window allows you to undo a mistaken approval or rejection.
+
+1. Navigate to the report page containing your review
+2. Look for the "Need to revert the change?" section
+3. Click the revert button while the timer is still active
+4. The review will be deleted and the proposal will return to pending status
+
+<Note>
+**Superusers** can revert reviews at any time, but standard reviewers are limited to the 5-minute window.
+</Note>
+
+## When Reviews Are Escalated
+
+Reviews can be escalated in two directions:
+
+**Staff reviewers** can escalate to customer when uncertain, escalate to team when complex, or make a direct decision when clear.
+
+**Customer admins** can escalate to team when uncertain or make a direct decision when clear.
+
+### Resolving Escalations
+
+**Customer Escalations** - The proposal stays pending until customer admin reviews it. Customer approval or rejection finalizes the decision. Notifications are sent via Slack/Discord, and superusers can override if needed.
+
+**Team Escalations** - Routes to senior ChainPatrol analysts. In-depth investigation is performed. Expert decision is made and customer is notified of outcome.
+
+## Why Human Review vs. Automation?
+
+ChainPatrol uses a **hybrid approach** combining automation with human expertise:
+
+**When Automation Works Best** - Clear-cut phishing with high threat scores and strong evidence, reports from trusted sources (verified security researchers), repeat patterns similar to previously confirmed threats, and high confidence where multiple detection rules agree.
+
+**When Human Review is Required** - Asset shows signs of being official (legitimacy signals), unclear or conflicting evidence (low confidence), unusual patterns that don't fit standard rules (edge cases), organizations that require manual approval (customer preference), and when someone claims the report is incorrect (disputes).
+
+This approach ensures we block real threats quickly while maintaining accuracy and giving brands control over their security decisions.
+
+## Review Permissions
+
+| Role | Create Reviews | Read Reviews | Delete Reviews | Special Abilities |
+|------|----------------|--------------|----------------|-------------------|
+| **Staff (Non-Customer)** | ✅ | ✅ | ✅ | Review all reports |
+| **Trusted Reporters** | ✅ | ✅ | ❌ | Auto-approval eligible |
+| **Customer Admins** | ✅ | ✅ | ❌ | Review own org only |
+| **Superusers** | ✅ | ✅ | ✅ | Override escalations, bypass time limits |
+| **Reporters/Standard Users** | ❌ | ✅ | ❌ | View only |
+
+## Key Takeaways
+
+- Four decision types prevent deadlock: Unlike binary approve/reject systems, Skip and Escalate ensure unclear threats get proper attention without forcing premature decisions
+- Trusted reporters enable fast response: Pre-verified security researchers can submit high-confidence reports that bypass standard review, accelerating protection for known threats
+- Five-minute revert window catches mistakes: This safety buffer lets reviewers undo accidental decisions before changes propagate, balancing speed with accuracy
+- Escalation paths preserve expertise: Customer escalations leverage brand context for ambiguous cases, while team escalations route complex threats to senior analysts
diff --git a/concepts/security-portal.mdx b/concepts/security-portal.mdx
new file mode 100644
index 0000000..6e0b50b
--- /dev/null
+++ b/concepts/security-portal.mdx
@@ -0,0 +1,119 @@
+---
+title: "Security Portal"
+description: "Understanding your organization's public-facing threat reporting page"
+---
+
+## Overview
+
+The **Security Portal** is your organization's public-facing page where people outside your team can report suspicious activity directly to ChainPatrol.
+
+<Info>
+It's a branded landing page that shows your organization's name and gives anyone with the link an easy way to submit threats they've encountered, whether that's a phishing site, a fake social profile, or a malicious app pretending to be yours.
+</Info>
+
+When the Security Portal is enabled, it can also display:
+
+- **Public Reports** - Show what threats have been reported and what action was taken
+- **Public Metrics** - Display high-level statistics about threats detected and addressed
+
+This gives your community and stakeholders transparency into how actively threats are being detected and addressed for your organization.
+
+## Who Uses It?
+
+The Security Portal is designed for **your community**:
+
+### External Users
+
+**Users and Customers** - People who use your products or services and encounter suspicious content. They report phishing sites, fake social media accounts, scam messages claiming to be from your brand, and suspicious apps or extensions.
+
+**Community Members** - Discord moderators, Telegram admins, and active community participants who report impersonation in community channels, scam posts targeting your community, fake support accounts, and coordinated attack campaigns.
+
+**Partners** - Business partners, affiliates, and ecosystem participants who report threats affecting shared users, cross-brand impersonation, supply chain threats, and industry-wide campaigns.
+
+**Security Researchers** - Independent researchers and white-hat hackers who report newly discovered threats, sophisticated attack patterns, zero-day phishing campaigns, and technical vulnerabilities.
+
+Instead of requiring them to have an account or go through complicated channels, they can simply visit your Security Portal and submit a report in a few clicks.
+
+### Internal Team
+
+You can also use it internally to give your team a quick, always-available way to report threats without logging into the full ChainPatrol dashboard. Benefits include no login required, faster submission for quick reports, mobile-friendly interface, and a bookmarkable URL you can share with non-technical team members.
+
+## Where Can You Find It?
+
+Your Security Portal lives at a unique URL based on your organization's slug.
+
+**Example:** If your organization is `acme`, your Security Portal would be at `chainpatrol.io/acme`
+
+To locate your portal URL:
+
+1. Go to **Settings → Security Portal** in your dashboard
+2. Look for the "Security Portal URL" card
+3. Click the link to copy your unique URL and share it with your community
+
+Add your Security Portal URL to your website footer, documentation, and community resources so users know where to report threats.
+
+## Where Can You Configure It?
+
+You configure the Security Portal in **Settings → Security Portal** within your organization's dashboard.
+
+### Visibility
+
+Controls who can access the portal:
+
+- **Disabled** - The portal isn't accessible to anyone. Portal returns 404 error and no one can submit reports via portal.
+- **Private** - Only members of your organization can see it. Requires ChainPatrol login and is good for internal testing.
+- **Public** - Anyone with the link can access it. No authentication required for maximum community engagement.
+
+### Public Reports
+
+A toggle that determines whether non-authenticated users can view the reports submitted to your organization.
+
+When enabled, people visiting your Security Portal can see what's been reported, what action has been taken, and it demonstrates active threat monitoring while building community trust.
+
+What's displayed includes report title and description, assets reported (URLs, accounts, etc.), status (pending, in progress, closed), date submitted, and action taken. Internal comments, reviewer identities, and sensitive investigation details are NOT displayed.
+
+<Warning>
+Consider your transparency goals and privacy requirements before enabling public reports.
+</Warning>
+
+### Public Metrics
+
+A toggle that displays high-level threat statistics on your Security Portal.
+
+Metrics displayed include threats blocked, takedowns filed, takedowns completed, reports received, threats by asset type, and recent activity trends. This demonstrates that your organization takes security seriously without exposing sensitive details.
+
+## Why Does It Exist?
+
+The Security Portal serves two primary purposes:
+
+### Community-Powered Protection
+
+When users encounter a phishing site or a fake profile impersonating you, they often want to report it but don't know how. Common barriers include no clear reporting channel, complicated submission process, requiring account creation, and being unclear if reports are acted upon.
+
+The Security Portal gives them a simple, trusted place to submit that information directly to ChainPatrol with easy submission (no account required), a clear process, a trusted branded channel, and visible impact showing reports lead to action.
+
+### Transparency & Trust
+
+By enabling public reports and metrics, you can demonstrate active security monitoring to stakeholders, regulators, and your user base. Board members see active threat monitoring, investors understand security investment, partners verify protection measures, and auditors review security processes. This builds trust and demonstrates that your organization takes security seriously.
+
+## Where Do Community Reports Go?
+
+When someone submits a report through your Security Portal, it flows into your organization's **Reports** page in the ChainPatrol dashboard, just like any other report.
+
+The report processing flow works as follows:
+
+1. User submits report via Security Portal
+2. Report appears in your organization's Reports page
+3. ChainPatrol's team evaluates the evidence and runs security checks
+4. Determines whether reported assets should be blocked, allowed, or escalated
+5. If "Obligatory Organization Admin Approval" is enabled, your team confirms the action
+6. Asset status is updated and distributed to blocklist
+
+From there, the report goes through the same review process as any other submission.
+
+## Key Takeaways
+
+- Community reporting acts as an early warning system: Users often encounter threats before your internal team, so a public security portal captures intelligence from the front lines
+- No-account submission lowers barriers: Requiring registration dramatically reduces report volume, so public portals accept submissions without login to maximize threat discovery
+- Transparency builds trust with your community: Publishing metrics and showing how you respond to reports demonstrates active protection and encourages continued reporting
+- Portal reports flow through the same rigorous review: Public submissions get the same expert analysis as internal detections, ensuring quality while maintaining speed
diff --git a/concepts/takedowns.mdx b/concepts/takedowns.mdx
new file mode 100644
index 0000000..36c8a63
--- /dev/null
+++ b/concepts/takedowns.mdx
@@ -0,0 +1,91 @@
+---
+title: "Takedowns"
+description: "Understanding how ChainPatrol removes malicious content from the internet"
+---
+
+## Overview
+
+A **takedown** is a formal request asking an online platform to remove harmful, fraudulent, or unauthorized content.
+
+<Info>
+This request is sent to the organization responsible for hosting or displaying that content, such as a hosting provider, domain registrar, social media platform, app store, or TLD registry.
+</Info>
+
+## Why Takedowns Matter
+
+Takedowns are an essential tool for protecting brands and users online. They help remove content that:
+
+- Impersonates legitimate organizations
+- Misleads or scams users
+- Abuses a brand's trademarks
+- Spreads harmful information
+- Distributes fraudulent or malicious applications
+- Hosts phishing pages or fake login portals
+
+## Where Takedowns Are Sent
+
+Because digital threats appear across many parts of the internet, takedowns may be sent to a wide range of platforms:
+
+### Websites
+
+**Hosting Providers** - Organizations that host website content (AWS, Cloudflare, Vercel, shared hosting companies, VPS and dedicated server providers).
+
+**Domain Registrars** - Companies that register and manage domain names (GoDaddy, Namecheap, Google Domains, country-specific registrars, reseller networks).
+
+**TLD Registries** - Organizations managing top-level domains (.com, .xyz, etc.) like Verisign (.com, .net), Public Interest Registry (.org), and country-code registries. Response time varies widely.
+
+### Social Media
+
+Twitter/X, Facebook, Instagram, YouTube, Telegram, Discord, Reddit, TikTok, and more. What gets removed includes impersonation accounts, scam posts and messages, fake support channels, and fraudulent giveaways.
+
+### App Stores
+
+Google Play, Apple App Store, Chrome Web Store, Firefox Add-ons, Microsoft Store. What gets removed includes fake wallet applications, malicious browser extensions, impersonation apps, and fraudulent utilities.
+
+### Decentralized Platforms
+
+IPFS (InterPlanetary File System) - Harmful content can be stored in a distributed way across IPFS nodes. Takedown targets include IPFS gateway operators, pinning services, and node operators hosting malicious content. Gateway blocking is the most effective approach since the decentralized nature makes complete removal difficult.
+
+## The Purpose of Takedowns
+
+Regardless of the platform, the purpose of a takedown is the same: **to remove dangerous or unauthorized content quickly, securely, and effectively.**
+
+### Takedowns vs. Blocklisting
+
+**Takedowns** provide complete removal from the internet. Content is permanently removed, attackers lose their infrastructure, future victims are prevented from accessing, and enforcement action is demonstrated. However, takedowns take time (hours to days), some providers don't respond, attackers can quickly create new sites, and there are jurisdiction and legal challenges. Best for long-term threat elimination, persistent campaigns, and high-profile impersonation.
+
+**Blocklisting** provides immediate protection at point of access. Protection is instant (15-30 minutes), works regardless of hosting provider, protects users even if content stays online, and offers universal coverage across platforms. However, content remains online, requires integration with security tools, and may not prevent all access methods. Best for immediate threat mitigation, rapid response scenarios, and protecting users before takedown completes.
+
+<Check>
+**ChainPatrol's approach:** "Blocklist-first, takedown-second" provides immediate protection while working toward permanent removal.
+</Check>
+
+## Takedown Lifecycle
+
+1. **TODO** - Takedown has been created and is waiting to be processed
+2. **IN PROGRESS** - ChainPatrol is actively working on the takedown: submitting to appropriate provider, monitoring the request, following up as needed
+3. **COMPLETED** - The provider removed the harmful content
+
+### Alternative Outcomes
+
+- **CANCELED** - Takedown stopped (e.g., content invalid or unnecessary)
+- **PENDING RETRACTION** - Identified as false positive, marked for retraction
+- **RETRACTION SENT** - Formal retraction request submitted to provider
+- **RETRACTED** - Provider confirmed retraction, takedown reversed
+
+## What Makes Takedowns Effective
+
+**Legal Documentation** - Effective takedowns require Power of Attorney (POA) authorizing action, trademark registration documents, clear evidence of abuse or impersonation, and authorized representative details. ChainPatrol handles all legal documentation and submission on your behalf.
+
+**Provider Relationships** - We maintain relationships with providers across the ecosystem with known abuse contact information, established reporting procedures, track record of successful takedowns, and understanding of each provider's requirements.
+
+**Persistent Follow-Up** - We don't just submit and forget. We perform regular status checks, follow-up communications, escalation when needed, and alternative approaches if initial request fails.
+
+**Evidence Collection** - Each takedown includes screenshots of malicious content, technical metadata (hosting, DNS, etc.), timeline of activity, and user reports and impact evidence.
+
+## Key Takeaways
+
+- Takedowns provide permanent removal while blocklists provide immediate protection: Use both together to protect users instantly via blocklists while working toward complete threat elimination through takedowns
+- Automatic retraction prevents wrongful removals: When false positives are identified, retraction requests go to providers quickly to halt or reverse takedowns before legitimate content is removed
+- Provider-specific formatting increases success rates: Different platforms have different submission requirements, and using the correct format for each provider improves response times and removal rates
+- Lifecycle tracking enables data-driven decisions: Complete visibility from TODO to COMPLETED helps identify which providers respond fastest and which threats are hardest to remove
diff --git a/concepts/watchlist.mdx b/concepts/watchlist.mdx
new file mode 100644
index 0000000..9bddad7
--- /dev/null
+++ b/concepts/watchlist.mdx
@@ -0,0 +1,127 @@
+---
+title: "Watchlist"
+description: "Understanding how ChainPatrol monitors assets for future action"
+---
+
+## Overview
+
+The watchlist is a set of assets that we monitor to see if we can action on them further in the future.
+
+<Info>
+Think of the watchlist as a "middle ground" between blocking and allowing: assets that need continued observation before a final decision can be made.
+</Info>
+
+## Why Would We Need to Watchlist Something?
+
+Assets are added to the watchlist for two primary reasons:
+
+### Inconclusive Evidence
+
+Sometimes when we process an asset to see if it's malicious, we don't find enough red flags to block the asset, but we also don't find enough green flags to allow the asset.
+
+**The Gray Area:**
+
+- **Not Enough to Block** - Insufficient evidence of malicious intent, weak or ambiguous threat indicators, could be legitimate but suspicious
+- **Not Enough to Allow** - Asset isn't clearly official or trusted, some concerning patterns detected, uncertainty about legitimacy
+
+In this situation, if we suspect that the asset may become malicious in the future, we keep tabs on the asset to see if it changes.
+
+We can act and remove the asset from the watchlist when it becomes clearly malicious, becomes clearly legitimate, or changes status (goes offline, gets suspended, or undergoes significant changes).
+
+**Common Scenarios:**
+
+**Parking Page** - Domain is registered but shows only a parking page. The domain name is suspicious (contains brand name + "airdrop") but there's no active content to analyze yet. We monitor when content appears and what type of content is added.
+
+**Dead Asset** - Website or profile is currently offline. The URL structure suggests brand impersonation but we can't analyze content that doesn't exist. We monitor when it comes back online and what content appears.
+
+**Ambiguous Content** - Asset has some concerning elements but unclear intent. Uses brand-related keywords but purpose is unclear, design has some similarities but not exact copy. We monitor content changes over time and addition of phishing forms or wallet drainers.
+
+### Monitoring for Takedowns
+
+When we start the takedown process, we want to make sure that we keep tabs on the asset in order to determine when the takedown has been completed.
+
+We place every asset onto the watchlist when the takedown is in progress. This enables automated monitoring (continuous scanning to detect when asset goes offline), completion detection (automatically mark takedown as complete when asset is inaccessible), resource efficiency (no manual checking required for takedown status), and faster response (immediate notification when takedown succeeds).
+
+**The Takedown Monitoring Flow:**
+
+1. Takedown request submitted to hosting provider or platform
+2. Asset automatically added to watchlist for monitoring
+3. Asset is scanned periodically to check liveness status
+4. Asset goes offline, gets suspended, or becomes inaccessible
+5. Takedown marked as complete, asset removed from watchlist
+
+**What We Monitor:**
+
+- **Liveness Status** - Is the asset still accessible, HTTP status codes, DNS resolution failures, server responses
+- **Provider Actions** - "Suspended by provider" messages, account termination notices, content removal confirmations, domain suspension indicators
+- **Content Changes** - Malicious content removed, page replaced with error message, redirect to different content, complete site removal
+
+This allows us to monitor the asset and see if it goes offline, at which point we can take the asset off of the watchlist.
+
+## Who Would Watchlist Something?
+
+Watchlisting can be done either manually or automatically:
+
+### Manual Watchlisting
+
+When an analyst reviews a reported asset and encounters inconclusive evidence, they can manually add it to the watchlist. Decision factors include threat indicators present but not conclusive, asset appears suspicious but needs more time to develop, waiting for asset to become accessible, and need to observe behavior over time.
+
+Who can do this: ChainPatrol security analysts, customer administrators (for their organization), and trusted reviewers.
+
+### Automatic Watchlisting
+
+Every asset is automatically added to the watchlist when a takedown is initiated. Triggers include takedown request submitted, takedown status changes to "IN_PROGRESS", and asset needs monitoring for completion. No manual intervention required: system automatically adds to watchlist, monitoring begins immediately, and removal happens automatically when offline.
+
+## How the Watchlist Works
+
+### Monitoring Frequency
+
+Assets on the watchlist are scanned at different frequencies based on how long they've been monitored and their current status:
+
+**UNKNOWN/ALLOWED Assets** (more frequent monitoring for uncertain assets):
+
+| Time on Watchlist | Scan Frequency |
+|-------------------|----------------|
+| < 6 hours | Hourly |
+| < 24 hours | Every 2 hours |
+| < 2 days | Every 4 hours |
+| < 7 days | Every 6 hours |
+| < 2 weeks | Every 12 hours |
+| < 1 month | Daily |
+| < 2 months | Every 2 days |
+| > 2 months | Every 4 days |
+
+Frequent early scans catch rapid changes; frequency decreases if asset remains stable.
+
+**BLOCKED Assets** (less frequent monitoring):
+
+| Time on Watchlist | Scan Frequency |
+|-------------------|----------------|
+| < 6 hours | Every 3 hours |
+| < 24 hours | Every 6 hours |
+| < 2 days | Every 12 hours |
+| < 7 days | Every 18 hours |
+| < 2 weeks | Every 36 hours |
+| < 1 month | Every 3 days |
+| < 2 months | Every 6 days |
+| > 2 months | Every 12 days |
+
+Blocked assets are already protected, so monitoring focuses on confirming takedown success.
+
+### Removal from Watchlist
+
+Assets are automatically removed from the watchlist when:
+
+- **Status Changes to ALLOWED** - Asset confirmed as legitimate
+- **Asset Comes Online** - Previously dead asset becomes accessible (pushed to review queue)
+- **30 Days in UNKNOWN** - Decay factor removes long-term uncertain assets
+- **Takedown Success** - Asset goes offline during takedown
+- **Provider Suspension** - Hosting provider suspends the asset
+- **Manual Removal** - Analyst decides monitoring is no longer needed
+
+## Key Takeaways
+
+- Watchlist solves the gray area problem: When you suspect an asset might be malicious but lack evidence to block, watchlisting lets you monitor for changes without premature action
+- Automatic takedown monitoring saves manual work: Every takedown automatically adds the asset to watchlist, eliminating the need to manually check if content has been removed
+- Adaptive frequency optimizes resources: Recent additions scan frequently to catch rapid changes, while stable assets scan less often to avoid wasting resources on unlikely updates
+- 30-day decay prevents bloat: Assets that stay UNKNOWN for a month without becoming malicious are automatically removed, keeping monitoring focused on active threats
diff --git a/getting-started/how-it-works/asset-scans.mdx b/getting-started/how-it-works/asset-scans.mdx
new file mode 100644
index 0000000..531d0ca
--- /dev/null
+++ b/getting-started/how-it-works/asset-scans.mdx
@@ -0,0 +1,112 @@
+---
+title: "Asset Scans"
+description: "How ChainPatrol automatically evaluates and monitors potential threats across the web"
+---
+
+## Overview
+
+An **asset scan** is an automated security check ChainPatrol runs on an online surface that could be used in a scam, like a website, a social profile, an app-store listing, or a crypto address. Each scan records what we observed at a specific moment in time and evaluates risk using a mix of detection rules and AI signals.
+
+<Info>
+Asset scans solve a simple problem: the internet changes constantly, attackers iterate fast, and manual review doesn't scale. Scans let us monitor large volumes of assets, catch newly emerging threats, and track whether risky content is still live.
+</Info>
+
+## What We Scan
+
+ChainPatrol supports many asset types across the digital landscape:
+
+- **Web Properties** - URLs and hosted pages (including redirect chains and landing pages)
+- **Social & Content Profiles** - Twitter/X, Telegram, YouTube, Reddit, Medium, Farcaster, and more
+- **App Listings & Extensions** - Google Play, Apple App Store, Mozilla Add-ons, and other marketplaces
+- **Crypto Addresses** - Normalized contract/address identifiers (e.g., CAIP-2 style) with chain context
+
+## Asset vs. Asset Scan
+
+Understanding the difference is key to how our monitoring works:
+
+**Asset** - An asset is the thing itself: a URL, handle, listing, or address. Example: `https://fake-metamask.com`
+
+**Asset Scan** - An asset scan is a time-stamped snapshot of that asset. The same asset may be scanned many times, and scans form a timeline of changes. Example: Scan #1 (Jan 1), Scan #2 (Jan 3), Scan #3 (Jan 5)
+
+Multiple scans of the same asset create a historical timeline, allowing us to track changes, detect when threats go live or are taken down, and monitor asset behavior over time.
+
+## When Scans Run
+
+Scans are triggered in three main ways:
+
+**Automatically** - Scans run when ChainPatrol detection sources surface something relevant, when an asset is added (e.g., via report, onboarding, or API ingestion), and during watchlist monitoring where assets are rescanned on a schedule that adapts over time (more frequent early on, less frequent as an asset stays stable, blocked assets scanned less often to reduce noise).
+
+**On Demand** - Manual or API-triggered scans occur when a team member triggers a rescan from the UI or when your systems submit assets via API.
+
+**Ongoing Liveness Checks** - For certain platform-hosted assets (e.g., specific site builders or marketplaces), ChainPatrol periodically re-checks whether a previously-blocked asset is still reachable.
+
+## How Scans Work
+
+Our scanning process follows a systematic approach to evaluate threats efficiently and accurately:
+
+1. **Normalize and Prepare** - We normalize the input (e.g., resolve canonical URLs or identifiers), create a scan record, and run a first pass of checks that don't require external enrichment.
+
+2. **Enrich with Context** - Depending on asset type, we collect relevant data:
+
+   **Web URL / Page Enrichments:**
+   - HTTP fetch results (status, redirects, extracted links, basic metadata like title and description)
+   - Optional browser capture (screenshot and DOM signals when available)
+   - Network and registration context (DNS, TLS, WHOIS/RDAP when enabled)
+
+   **Platform/API Enrichments:**
+   - Profile and listing details (descriptions, author and publisher fields, follower and engagement signals)
+
+   <Tip>
+   Some enrichments run only when earlier signals suggest elevated risk to keep scans efficient.
+   </Tip>
+
+3. **Security Analysis** - We evaluate the asset using rules and AI/ML signals for patterns like phishing, impersonation, and scam mechanics. This includes both content-based and visual/behavioral indicators when available.
+
+4. **Labels, Scores, and Liveness** - Each scan is tagged with labels and produces scores for prioritization:
+
+   **Common Labels:**
+   - Captcha detected
+   - Parked domain
+   - Provider suspended
+   - Brand impersonation
+   - Wallet drainer detected
+
+   **Liveness Status:**
+   - **ALIVE** - Asset is active and accessible
+   - **DEAD** - Asset is no longer reachable
+   - **UNKNOWN** - Inconclusive (not "safe")
+
+5. **Relationship Discovery** - For supported web and social surfaces, scans can extract outbound links and redirects to help you trace related infrastructure and uncover threat networks.
+
+## How Scan Results Are Used
+
+- **Triage and Review** - Scans provide evidence (metadata, redirects, links, screenshots) so reviewers can decide to block, allow, investigate further, or initiate takedowns
+- **Detections & Automation** - High-risk scans feed detection workflows and monitoring pipelines; actions vary by configuration and policy
+- **Monitoring Hygiene** - Watchlist and liveness workflows keep your monitoring set current and highlight meaningful changes over time
+
+## What You See in the Product
+
+Our platform provides comprehensive visibility into scan results and asset history:
+
+**Per-Asset Timeline** - A complete history of scans for each asset, including liveness status changes, notable changes in content or behavior, risk score evolution, and label additions/removals.
+
+**Scan Detail Views** - Deep dive into individual scans with evidence artifacts (screenshots, metadata), applied labels and their sources, scoring signals and rule matches, and enrichment data (redirects, links, network info).
+
+**Org/Brand Dashboards** - High-level overview showing recent activity and new threats, top-risk assets requiring attention, monitoring coverage across platforms, and trend analysis over time.
+
+**Reporting & Metrics** - Actionable insights including scan volume and frequency, detection speed metrics, number of risky assets still live, and takedown success rates.
+## Scan Efficiency & Scale
+
+- **Smart Scheduling** - Adaptive scan frequency based on asset risk and stability
+- **Selective Enrichment** - Deep analysis triggered only when risk signals warrant it
+- **Parallel Processing** - Multiple assets scanned simultaneously for faster coverage
+- **Historical Context** - Timeline-based analysis to detect behavioral changes
+
+Our scanning infrastructure processes thousands of assets daily, providing real-time threat intelligence while maintaining accuracy and minimizing false positives.
+
+## Key Takeaways
+
+- One asset, many scans: The same URL can be scanned multiple times to create a timeline showing how threats evolve or when they're taken down
+- Selective enrichment saves resources: Deep analysis only triggers when initial signals suggest elevated risk, keeping scans fast for low-risk assets
+- Liveness tracking enables automation: Knowing when an asset goes from ALIVE to DEAD lets us automatically confirm successful takedowns
+- Relationship discovery reveals campaigns: Extracting links and redirects from scans helps you trace entire threat networks instead of blocking sites one at a time
diff --git a/getting-started/how-it-works/blocklist.mdx b/getting-started/how-it-works/blocklist.mdx
new file mode 100644
index 0000000..dc9cbbd
--- /dev/null
+++ b/getting-started/how-it-works/blocklist.mdx
@@ -0,0 +1,165 @@
+---
+title: "Blocklist"
+description: "Real-time, community-powered database of confirmed phishing sites and malicious assets"
+---
+
+## Overview
+
+ChainPatrol's Blocklist is a real-time, community-powered database of confirmed phishing sites, scams, and malicious assets that protects users across the web3 ecosystem.
+
+The ChainPatrol Blocklist is a continuously updated list of hundreds of thousands of malicious websites, social media accounts, and blockchain addresses that have been confirmed as threats through our expert review process. When an asset is added to the blocklist, it's automatically distributed to our network of security integrations to protect users in real-time.
+
+### Key Features
+
+- **Global Coverage** - Combines threat intelligence from organizations across the ecosystem
+- **Rapid Response** - Assets blocklisted and distributed within minutes after confirmation
+- **Freely Accessible** - Available via public API to maximize distribution and protection
+- **Wide Integration** - Automatically distributed to wallets, browsers, and security tools
+
+<Info>
+Traditional takedown processes take hours or days. ChainPatrol provides protection within minutes.
+</Info>
+
+## How Assets Get Blocklisted
+
+Assets are added to the blocklist through a rigorous review process:
+
+1. **Detection** - Potential threats are identified through automated detection, community reports, or partner submissions
+2. **Analysis** - Our AI-powered scanning engine analyzes assets using 50+ detection rules
+3. **Review** - A BLOCK proposal is created and reviewed by our security team
+4. **Approval** - After review approval, the asset status changes to BLOCKED
+5. **Distribution** - The blocked asset is automatically submitted to our integration partners
+
+Only assets that pass through this review and approval process are added to the blocklist.
+
+## Blocklist Integrations
+
+ChainPatrol's blocklist is integrated with wallets, browsers, and security platforms:
+
+### Browser Security
+
+- **Google Safe Browsing** - Protects Chrome, Safari, Edge, and Firefox users
+- **Cloudflare Gateway** - Network-level protection for enterprises
+
+### Wallet Providers
+
+Major integrations include:
+
+- **MetaMask** - Direct integration via Eth-Phishing-Detect
+- **Phantom** - Real-time API integration
+- **Coinbase Wallet** - Via multiple blocklist sources
+- **Rainbow Wallet** - Via WalletConnect and direct APIs
+- **Trust Wallet** - Via multiple blocklist sources
+- **Ledger Live** - Via blocklist APIs
+- **WalletConnect** - Real-time API protecting connected wallets
+
+And additional wallet providers across the ecosystem.
+
+### Threat Intelligence
+
+- **SEAL-ISAC** - Security Alliance's information sharing network
+- **Crypto-ISAC** - Cryptocurrency industry threat sharing
+- **Eth-Phishing-Detect** - Ethereum ecosystem blocklist (ChainPatrol is a core contributor)
+- **Polkadot Phishing List** - Cross-chain with Polkadot ecosystem
+
+### Applications & Services
+
+- **Polymarket** - Content moderation API
+- **Snapshot** - Governance platform protection
+- **Enterprise Custom** - Custom integrations for enterprise customers
+
+## Accessing the Blocklist
+
+### Web Dashboard
+
+Your organization's blocklist page shows all assets that have been added to the blocklist by your team:
+
+1. Access the **Blocklist** section in your organization dashboard
+2. View assets filtered by type, date, and status
+3. Search for specific assets or domains
+4. Export blocklist data as a CSV file for reporting purposes
+
+### API Access
+
+The blocklist is publicly accessible via our API and SDK.
+
+- [API Documentation](/external-api/overview) - Learn how to access the blocklist via REST API
+- [SDK Documentation](/sdk/overview) - Use our JavaScript SDK for easy integration
+
+## False Positives
+
+We take false positives seriously. If you believe an asset has been incorrectly blocklisted:
+
+### For Asset Owners
+
+If your legitimate website or asset has been blocklisted:
+
+1. **Submit a Dispute** - Visit [chainpatrol.com/dispute](https://chainpatrol.com/dispute) to submit a dispute
+2. **Provide Evidence** - Include documentation proving your asset is legitimate (business registration, domain age and history, verified social media accounts, SSL certificates, other legitimacy indicators)
+3. **Review Process** - Our team will review your dispute within 24 hours
+4. **Resolution** - If approved, your asset will be removed from the blocklist and marked as ALLOWED
+
+### For ChainPatrol Users
+
+If you've reported an asset that turns out to be legitimate:
+
+1. Find the asset's report in your dashboard
+2. Create an ALLOW proposal with your reasoning
+3. Our team will review and update the status if appropriate
+
+When an asset is removed from the blocklist, the update is distributed to all integration partners within the same rapid timeframe.
+
+## Blocklist Distribution
+
+When an asset is blocklisted, it's automatically distributed to multiple platforms:
+
+- **Google Safe Browsing** - All asset types eligible for browser protection
+- **SEAL-ISAC** - URLs hosted on 50+ hosting providers (Vercel, Cloudflare, AWS, etc.)
+- **Crypto-ISAC** - All URL and domain assets
+- **Eth-Phishing-Detect** - Ethereum-related phishing sites
+- **Polkadot Phishing** - Cross-network phishing domains
+- **Direct Partners** - Real-time API updates to wallet providers
+
+Distribution happens automatically through our integration workflows. There's no manual step required.
+
+<Tip>
+In the case of a false positive, we will submit retraction requests for ChainPatrol's submissions to these partners.
+</Tip>
+
+## Why Distribution Matters
+
+Traditional cybersecurity relies on **takedowns**, requesting hosting providers or domain registrars to remove malicious content.
+
+### Traditional Takedown Timeline
+
+- **Hosting Providers** - Hours to days for takedown
+- **Domain Registrars** - Often longer response times
+- **No Response** - Some providers never respond
+
+### ChainPatrol's Blocklist Approach
+
+ChainPatrol provides immediate protection by:
+
+- **Browser & Wallet Blocking** - Block access at the browser and wallet level
+- **Always-On Protection** - Protect users even if the site remains online
+- **Universal Coverage** - Works across all hosting providers and jurisdictions
+- **Rapid Response** - Users protected in minutes, not days
+
+This "blocklist-first, takedown-second" approach means users are protected within minutes, not days.
+
+## Blocklist vs. Takedown Comparison
+
+| Aspect | ChainPatrol Blocklist | Traditional Takedown |
+|--------|----------------------|---------------------|
+| **Response Time** | Minutes | Hours to days (or never) |
+| **Coverage** | Multiple integrations | Single hosting provider |
+| **User Protection** | Immediate | Delayed until removal |
+| **Jurisdiction** | Global | Provider-dependent |
+| **Success Rate** | Consistent distribution | Varies by provider |
+
+## Key Takeaways
+
+- Blocklist provides immediate protection while takedowns are processed: Users are protected within minutes via wallet and browser integrations, even as takedown requests work through slower provider channels
+- Distribution multiplies your protection reach: A single blocked asset automatically protects users across browsers, wallets, and platforms without separate submissions
+- False positive handling is fast and coordinated: Retractions propagate through the same distribution channels as blocks, ensuring corrections reach all integrated platforms
+- Public API enables ecosystem-wide protection: Making the blocklist freely accessible means any wallet, browser, or security tool can integrate and protect their users
diff --git a/getting-started/how-it-works/detection-sources.mdx b/getting-started/how-it-works/detection-sources.mdx
new file mode 100644
index 0000000..5060bad
--- /dev/null
+++ b/getting-started/how-it-works/detection-sources.mdx
@@ -0,0 +1,165 @@
+---
+title: "Detection Sources"
+description: "Automated monitoring systems that continuously scan the internet for threats to your brand"
+---
+
+## Overview
+
+Detection sources are automated monitoring systems that continuously scan the internet for potential threats to your brand. Each source monitors a specific platform or data stream, searching for suspicious assets that may be impersonating your organization or attempting to defraud your users.
+
+## How Detection Sources Work
+
+Detection sources operate on automated schedules, running searches across various platforms using your organization's **included terms** (brand names, products, keywords you want to monitor) and **excluded terms** (legitimate domains you want to filter out). When a source finds a potential threat, it automatically submits the asset for analysis through ChainPatrol's threat detection pipeline.
+
+### The Detection Flow
+
+1. **Scheduled Execution** - Each detection source runs on a predefined schedule (e.g., every 15 minutes, hourly, daily)
+2. **Platform Scanning** - The source searches its platform (ex. Twitter, Google Ads, Reddit) using your organization's keywords and monitoring rules
+3. **Asset Discovery** - Matching results are collected as potential threats
+4. **Automatic Processing** - Discovered assets are automatically submitted to the threat detection system
+5. **Enrichment & Analysis** - Assets are scanned, enriched with additional data, and evaluated by the rules engine
+6. **Threat Scoring** - A threat score is calculated based on multiple detection rules
+7. **Action Taken** - If the score exceeds your organization's detection thresholds, the threat can be automatically reported or flagged for review
+
+## Available Detection Sources
+
+<Info>
+ChainPatrol supports **28 different detection sources** across multiple categories
+</Info>
+
+### Search Engines
+
+Monitor search results for phishing sites and scam pages:
+
+- **Google Search** - Scans Google search results
+- **Bing Search** - Monitors Bing search results
+- **Yahoo Search** - Tracks Yahoo search results
+- **DuckDuckGo Search** - Monitors DuckDuckGo search results
+- **Google Ads Search** - Monitors Google Ads for malicious content
+
+### Social Media
+
+Track social media for impersonation accounts and fraudulent posts:
+
+**Twitter/X Monitoring:**
+- Twitter Post Search - Searches Twitter posts for threats
+- Twitter User Search - Monitors Twitter user profiles
+- Twitter Profile Monitoring - Tracks replies on posts from specific Twitter profiles
+
+**Reddit Monitoring:**
+- Reddit Subreddit Search - Searches for Reddit communities by name
+
+**YouTube Monitoring:**
+- YouTube Search - Searches YouTube videos and channels
+
+**Medium Monitoring:**
+- Medium Tag RSS - Monitors Medium articles by tags
+
+**Telegram Monitoring:**
+- Telegram Channels Search - Searches for Telegram channels
+- Telegram User Search - Searches for Telegram user accounts
+
+**TikTok Monitoring:**
+- TikTok Video Search - Searches TikTok videos
+- TikTok User Search - Searches TikTok user profiles
+
+### App Stores
+
+Monitor mobile app stores and browser extension marketplaces:
+
+- **Google Play** - Monitors Google Play Store apps
+- **Apple App Store** - Tracks iOS App Store applications
+- **Mozilla Add-ons** - Monitors Firefox browser extensions
+
+### Web3 & Blockchain
+
+Specialized sources for cryptocurrency and blockchain threats:
+
+- **DexScreener Search** - Monitors DeFi protocols and tokens for impersonation
+
+### Specialized Sources
+
+Additional monitoring capabilities for comprehensive protection:
+
+- **URLScan** - Leverages URLScan.io's database to find threats
+- **DNS Twist** - Detects typosquatting domains using homoglyph analysis
+- **Certstream** - Monitors certificate transparency logs for newly issued TLS/SSL certificates
+- **Guestbook** - Monitors community guestbook submissions
+- **Blocked IP Scan** - Scans for assets hosted on known malicious IPs
+- **Asset Check** - Re-checks existing assets for status changes
+- **External** - Handles external threat submissions via API
+
+## Source Configuration
+
+Each detection source can be customized with:
+
+- **Status Options** - Enable or disable sources
+- **Scope Settings** - Organization or global level
+- **Schedule Configuration** - Custom timing and frequency
+
+### Status Options
+
+- **Enabled** - Source runs automatically on schedule
+- **Disabled** - Source does not run
+
+### Scope Settings
+
+Detection sources can operate at two levels:
+
+**Organization Level** - Uses your specific keywords and monitoring settings
+
+**Global Level** - Runs system-wide monitoring for all organizations
+
+### Schedule Configuration
+
+Sources run on automated schedules that vary by:
+
+- **Organization Priority** - Higher priority organizations get more frequent scans
+- **Source Type** - Different sources have different default intervals based on their data freshness and rate limits
+
+<Tip>
+**Custom Schedules:** You can override default schedules with custom cron expressions for fine-tuned control over when each source runs.
+</Tip>
+
+## Best Practices
+
+### Setting Up Detection Sources
+
+1. **Start with core sources** - Enable search engines and social media sources first
+2. **Configure included terms** - Add all your brand names, product names, and common misspellings
+3. **Set excluded terms** - Add your legitimate domains to reduce false positives
+4. **Adjust thresholds** - Set appropriate auto-reporting thresholds based on your risk tolerance
+5. **Monitor results** - Review initial detections to fine-tune your configuration
+
+### Optimizing Detection Coverage
+
+- **Use Multiple Sources** - Different sources catch different types of threats
+- **Monitor App Stores** - Essential if you have mobile applications
+- **Add Official Assets** - Add official Twitter assets to monitor replies
+- **Regular Reviews** - Periodically review and adjust your configuration
+
+### Managing False Positives
+
+- **Refine Excluded Terms** - Add legitimate mentions to your excluded terms list to filter out false positives
+- **Adjust Similarity Thresholds** - Fine-tune keyword similarity thresholds for token monitoring
+- **Use Evaluate Status** - Manually review results before enabling automatic actions
+- **Review Rules Dashboard** - Identify rules that generate false positives and adjust accordingly
+
+## Performance Considerations
+
+### Rate Limits
+
+Each detection source respects platform-specific rate limits. The system automatically handles rate limiting by adjusting request timing, batching operations where possible, and logging when limits are reached. Rate limiting ensures compliance with platform APIs while maintaining consistent monitoring coverage.
+
+### Resource Usage
+
+Detection sources are optimized for efficiency. Results are processed in batches to avoid overwhelming the system, duplicate assets are automatically filtered out, sources run in parallel when possible, and failed detections are logged but don't block other sources.
+
+Our infrastructure is designed to handle high-volume monitoring without impacting detection speed or accuracy.
+
+## Key Takeaways
+
+- Start broad, then refine: Enable core sources first (search engines and social media), then expand to specialized sources based on where your threats appear
+- Quality over quantity: Well-configured included and excluded terms on fewer sources beats poorly configured monitoring across all platforms
+- Different sources catch different threats: A domain might not show in Google Search but appear in Certstream, so layer your coverage for comprehensive protection
+- Auto-reporting works best after calibration: Review initial detections manually to fine-tune your thresholds before enabling automatic blocking
diff --git a/getting-started/how-it-works/how-we-use-ai.mdx b/getting-started/how-it-works/how-we-use-ai.mdx
new file mode 100644
index 0000000..749867b
--- /dev/null
+++ b/getting-started/how-it-works/how-we-use-ai.mdx
@@ -0,0 +1,125 @@
+---
+title: "How We Use AI"
+description: "Learn how ChainPatrol's AI-powered detection engine protects your brand from Web3 threats in real-time"
+---
+
+## Overview
+
+In Web3, threats move fast. Phishing sites can be spun up in minutes, targeting your community before traditional security measures can respond. That's why we built an AI-first detection engine that identifies and neutralizes threats within seconds, not hours.
+
+<Info>
+Our approach combines the speed of automation with the precision of human expertise, ensuring your brand stays protected around the clock.
+</Info>
+
+## The ChainPatrol Detection Mix
+
+We've engineered the optimal balance between speed and accuracy:
+
+| Detection Type | How It Works |
+| --- | --- |
+| **Fully Automated**  | Threats that meet all AI confidence thresholds are blocked instantly |
+| **Human Review**  | Edge cases are flagged for immediate analyst review |
+
+<Note>
+**Why this matters:** Multiple AI and rule-based thresholds must pass before any action is taken. This layered approach prevents false positives while ensuring legitimate threats are caught quickly.
+</Note>
+
+## How Our AI Detects Threats
+
+ChainPatrol uses a multi-layered AI approach, combining multiple detection methods for comprehensive threat protection.
+
+### Content Analysis
+
+Our AI analyzes text content across platforms to identify threats:
+
+- **Language Pattern Detection** - Identifies phishing language, scam indicators, and social engineering tactics in posts, messages, and web content
+- **Context Understanding** - Recognizes subtle impersonation attempts and fraudulent claims that might fool traditional filters
+- **Multi-Platform Monitoring** - Analyzes content across social media, websites, messaging apps, and more
+
+### Visual Detection
+
+Phishing sites often look identical to legitimate ones. Our visual AI catches them:
+
+- **Visual Similarity Analysis** - Compares page appearance against your legitimate sites to catch pixel-perfect impersonation attempts
+- **Structural Pattern Matching** - Examines page structure, code patterns, and layouts to identify known phishing templates, even when visuals differ
+- **Real-Time Scanning** - Continuously monitors suspicious URLs for visual indicators of threats
+
+### Web3-Specialized Detection
+
+Our models are trained specifically for Web3 threats:
+
+- Trained on hundreds of thousands of real threat examples from across the ecosystem
+- Continuously updated with new attack patterns as they emerge
+- Fine-tuned for Web3-specific threats like wallet drainers, fake airdrops, and impersonation scams
+
+## How Detection Works
+
+Here's what happens when a potential threat is identified:
+
+1. **Discovery** - Our engine monitors 50+ platforms 24/7
+2. **Analysis** - Multiple AI models analyze the threat independently
+3. **Scoring** - Our decision engine aggregates confidence scores
+4. **Action** - High-confidence threats are blocked; edge cases go to analysts
+5. **Distribution** - Confirmed threats are pushed to all integrated platforms
+
+### The Decision Process
+
+At the core of our system is a sophisticated decision engine that:
+
+- **Multi-Signal Aggregation** - Combines outputs from all detection methods
+- **Confidence-Based Scoring** - Weighs evidence to determine threat likelihood
+- **Cross-Reference Validation** - Checks against known threat databases and patterns
+- **Instant Decisions** - Makes final determinations in seconds
+
+No single signal is enough on its own. Multiple independent checks must pass before a threat is actioned, helping maintain accuracy while preserving speed.
+
+## Platform Coverage
+
+Our AI monitors threats across 50+ platforms, and we can add new integrations within days.
+
+**Core Detection Types:** URLs & Domains, Web Pages, Wallet Addresses, Phone Numbers, Email Addresses, Forms & Surveys
+
+**Social & Communication:** Discord, Twitter/X, Telegram, LinkedIn, YouTube, Reddit, TikTok, Instagram, Threads, Medium, WhatsApp, Facebook, Snapchat, Substack
+
+**App Stores & Extensions:** Google Play, Apple App Store, Chrome Web Store, Firefox Add-ons, ChatGPT Plugins, Microsoft Store, Opera Extensions
+
+**Web3 Platforms:** OpenSea, ENS, IPFS, Farcaster, Blur, Magic Eden, DeBank, Bluesky, Primal, DeSo
+
+**Need coverage for a platform we don't list?** Contact us. New integrations can be added within days.
+
+## Real-Time Threat Distribution
+
+When our AI detects a threat, it doesn't just sit in a database. We push it directly to the platforms your users rely on:
+
+### Browser Protection
+
+**Google Safe Browsing** - Our integration means threats are blocked in Chrome, Edge, and Safari, reaching billions of users worldwide.
+
+### Wallet Protection
+
+Direct integrations with leading wallets provide real-time warnings at the point of transaction:
+
+- **MetaMask** - Core integration partner protecting millions of users
+- **Phantom** - Protecting the Solana ecosystem
+- **WalletConnect** - Real-time threat prevention
+- **20+ More Wallets** - Comprehensive ecosystem coverage
+
+
+**The result:** Threats detected by ChainPatrol are blocked across the entire Web3 ecosystem within seconds.
+
+## Continuous Learning & Improvement
+
+Our AI gets smarter every day through:
+
+**Human-in-the-Loop Training** - Every analyst decision feeds back into our AI. When our team reviews edge cases, that knowledge improves future detection accuracy.
+
+**Threat Intelligence Networks** - We're active contributors to major threat intelligence communities, giving us early access to emerging threats and allowing us to share our detections with the broader security ecosystem.
+
+**Expanding Datasets** - Our threat database grows daily with new examples, ensuring our AI stays ahead of evolving attack techniques.
+
+## Key Takeaways
+
+- Speed without sacrifice: Automated detection handles high-confidence threats instantly while human review prevents false positives on edge cases
+- Layered protection is stronger: Multiple AI signals must agree before action is taken, which prevents both missed threats and wrongly blocked assets
+- Training on Web3-specific threats matters: Generic phishing detection misses wallet drainers and fake airdrop patterns that our specialized models catch
+- Direct integrations multiply impact: A single detection can protect users across browsers, wallets, and platforms within seconds of confirmation
diff --git a/getting-started/how-it-works/review.mdx b/getting-started/how-it-works/review.mdx
new file mode 100644
index 0000000..1966f93
--- /dev/null
+++ b/getting-started/how-it-works/review.mdx
@@ -0,0 +1,104 @@
+---
+title: "Review"
+description: "How ChainPatrol evaluates and approves threat status changes through automated and human review"
+---
+
+## Overview
+
+In order to block malicious threats or allow official assets, we use the Review process. To change an Asset's status (from `UNKNOWN` to `BLOCKED`/`ALLOWED`, or in special cases between `BLOCKED` and `ALLOWED`), we create a **Proposal**.
+
+<Info>
+Each Proposal is evaluated by either human reviewers or our automation, who can make one of four decisions: **Approve**, **Reject**, **Skip**, or **Escalate**.
+</Info>
+
+### Proposal Decisions
+
+- **Approve** - Accepts the Asset's status change and closes the Proposal
+- **Reject** - Denies the status change and closes the Proposal
+- **Skip** - Keeps Proposal pending when there's insufficient evidence
+- **Escalate** - Sends to senior team members or customer for additional review
+
+Only **Approve** and **Reject** decisions close out the Proposal. **Skip** and **Escalate** keep the Proposal in `PENDING` status for further evaluation.
+
+## Automation
+
+Our automated review system handles high-confidence threat detections, allowing human analysts to focus on edge cases and complex decisions.
+
+### When Do We Perform Automated Review?
+
+Automated review is enabled when specific conditions are met:
+
+**Organization Requirements** - Reviewing automation only activates for organizations with an active subscription status (Active, Trial, or Prospect).
+
+**Asset Information Requirements** - Automation requires sufficient data about the Asset. Some platforms currently lack adequate information gathering capabilities. Platforms requiring human review include Facebook, Instagram, and TikTok due to limited automated data collection.
+
+**Proposal Type Restrictions** - Automated review only handles Proposals to set an Asset to `BLOCKED` status. Proposals to set Assets to `ALLOWED` or `UNKNOWN` status are not automated.
+
+### How Does Automated Review Make a Decision?
+
+Our automated review system calculates a **risk score** to determine whether an asset should be approved as malicious.
+
+1. **Rule Execution** - During an Asset Scan, multiple detection rules are executed against the asset
+2. **Score Calculation** - The risk score is a weighted sum of all individual scores from each successful rule execution
+3. **Threshold Evaluation** - The final risk score is compared against our approval threshold
+4. **Decision** - Assets meeting the threshold are automatically approved; others are escalated for human review
+
+### Legitimacy Rules
+
+<Warning>
+**Special Case:** Legitimacy Rules can override automatic approval, even with high risk scores.
+</Warning>
+
+Legitimacy Rules are special detection rules that identify when an asset is **not malicious**. If a Legitimacy Rule with "Very High" confidence passes, automation will **not** automatically approve the Proposal, regardless of the Risk Score.
+
+**Example:** An asset might have a high risk score, but if it matches a Very High confidence Legitimacy Rule (e.g., verified official domain), the Proposal will be escalated for human review instead of being auto-blocked.
+
+### Automatically Approving the Proposal
+
+For a Proposal to be automatically approved, **all** of the following must be true:
+
+**Required Conditions:**
+- Asset must not already be `ALLOWED`
+- Organization must have Reviewing enabled and not be inactive
+- Proposal must be for blocking the Asset (not for allowing)
+- No Legitimacy Rules of "Very High" confidence have passed
+
+**Approval Triggers (at least one must be true):**
+- High Risk Score - the overall Risk Score of the Asset meets our confidence threshold
+- Trusted Reporter - the Asset was part of a Report created by a Trusted Reporter
+
+## Human Review
+
+Humans are essential for making decisions about Proposals that fall outside automated approval criteria.
+
+Since automation only handles Proposals to block Assets with high confidence scores, human analysts evaluate all other cases.
+
+### When Humans Are Involved
+
+- **Lower Confidence Blocks** - Proposals to Block an Asset that doesn't meet the automated threshold
+- **Allow Proposals** - All Proposals to Allow an Asset
+- **Unknown Status** - Proposals to set an Asset to Unknown
+
+### Human Review Process
+
+1. **Proposal Assignment** - Proposals are routed to appropriate analysts based on expertise and workload
+2. **Evidence Review** - Analysts examine scan results, screenshots, metadata, and context
+3. **Decision Making** - Using established criteria and guidelines, analysts make Approve/Reject/Skip/Escalate decisions
+4. **Quality Assurance** - Decisions feed back into our AI models to improve future automation accuracy
+
+### What Analysts Use to Make Decisions
+
+**Asset Scan Results** - Screenshots and visual evidence, page content and metadata, network and infrastructure data, historical scan timeline.
+
+**Detection Rules** - Which rules triggered and their confidence levels, rule weights and scoring breakdown, legitimacy rule results.
+
+**Context & Intelligence** - Related assets and infrastructure, reporter information and history, brand-specific guidelines, recent threat patterns.
+
+**Organization Settings** - Custom detection thresholds, allowlist and blocklist entries, brand protection priorities.
+
+## Key Takeaways
+
+- Legitimacy rules protect you from overblocking: If a Very High confidence legitimacy rule passes, the proposal goes to human review regardless of risk score
+- Escalate unclear cases strategically: Use "Skip" when you need more information, "Escalate to Team" for expertise, and "Escalate to Customer" when brand context matters
+- Automation learns from humans: Every manual review decision feeds back into the system, improving future automatic detection accuracy
+- The four-decision model prevents deadlock: Unlike binary approve/reject systems, Skip and Escalate ensure unclear threats get proper attention without forcing premature decisions
diff --git a/getting-started/how-it-works/takedown.mdx b/getting-started/how-it-works/takedown.mdx
new file mode 100644
index 0000000..15afa24
--- /dev/null
+++ b/getting-started/how-it-works/takedown.mdx
@@ -0,0 +1,176 @@
+---
+title: "Takedown"
+description: "How ChainPatrol removes malicious content through coordinated takedown requests"
+---
+
+## Overview
+
+A takedown is the process of requesting that a platform, host, or provider remove harmful content. This page explains how takedowns move through their lifecycle in ChainPatrol, how they’re submitted and monitored, and how retractions work when an asset is identified as legitimate.
+
+## Takedown Lifecycle
+
+Every takedown follows a clear lifecycle inside ChainPatrol:
+
+1. **TODO** - A takedown has been created and is waiting to be processed
+2. **IN PROGRESS** - ChainPatrol is actively working on the takedown (submitting it to the appropriate provider and monitoring the request)
+3. **COMPLETED** - The provider removed the harmful content
+
+### Alternative Outcomes
+
+- **CANCELED** - The takedown was stopped (e.g., content turned out to be invalid or unnecessary)
+- **PENDING RETRACTION** - Identified as false positive, marked for retraction but not yet sent to provider
+- **RETRACTION SENT** - Formal retraction request submitted to provider to halt or reverse the takedown
+- **RETRACTED** - Provider confirmed retraction, takedown fully stopped or reversed
+
+## How ChainPatrol Processes a Takedown
+
+### Creation of a Takedown
+
+<Info>
+A takedown is automatically created for every asset that is blocked, provided that the organization has the **Takedowns service enabled**.
+</Info>
+
+Each takedown is directly linked to the blocked asset and contains all essential context required for further action:
+
+- **Asset Reference** - URL, social profile, IPFS hash, or app listing
+- **Supporting Evidence** - Explanation of why the asset was classified as harmful
+- **Provider Information** - Platform or host responsible for the content
+
+After creation, the takedown is placed into the **TODO** state, indicating that it has been generated and is ready to be reviewed and processed.
+
+### Assigning a Provider
+
+ChainPatrol determines which platform, hosting company, registrar, or channel is responsible for the content.
+
+**Hosting & Domains:**
+- Hosting providers (AWS, Cloudflare, Vercel, etc.)
+- Domain registrars (GoDaddy, Namecheap, etc.)
+- TLD registries (for top-level domains like `.com`, `.xyz`, etc.)
+
+**Social Media:**
+Twitter/X, Facebook, Instagram, YouTube, Telegram, Discord, Reddit
+
+**App Stores:**
+Google Play Store, Apple App Store, Browser extension marketplaces
+
+**Distributed Storage:**
+IPFS gateways and pinning services, decentralized hosting platforms
+
+We maintain an up-to-date record of **100+ abuse contacts** for both submission of takedowns and retraction of requests made in error.
+
+### Submitting the Takedown
+
+ChainPatrol prepares and submits the takedown request to the appropriate provider responsible for hosting or distributing the malicious content.
+
+**What's Included in a Submission:**
+
+- **Clear Explanation** - Detailed description of why the content is considered harmful, including evidence and context
+- **Legal Documentation** - Supporting legal documents required to justify the removal (when applicable)
+- **Provider-Specific Format** - Submissions use each provider's preferred reporting channel to ensure highest likelihood of success
+
+Once submitted, the takedown transitions into the **IN PROGRESS** state.
+
+**Full Transparency:** Customers have real-time visibility including status updates and provider responses. Copies of provider communications are surfaced directly in the takedown events timeline.
+
+### Monitoring
+
+After submission, ChainPatrol continuously monitors the takedown to track its progress and outcome:
+
+- **Content Verification** - Verifying whether targeted content has been removed
+- **Provider Responses** - Reviewing and interpreting responses from the provider
+- **Escalation** - Automatically retrying or escalating when needed
+
+The takedown remains active until a final outcome is reached. Continuous monitoring helps ensure takedowns are not prematurely closed.
+
+### Final Outcome
+
+A takedown ends in one of the following states:
+
+**COMPLETED** - The provider removed the content. Examples include websites becoming inaccessible, social media profiles or messages being removed, Telegram channels being shut down, IPFS content becoming unavailable via gateways, and scam apps being delisted.
+
+**CANCELED** - The takedown request cannot proceed. Reasons include invalid content, missing required documentation, and asset no longer meets takedown criteria.
+
+**RETRACTED** - The takedown was formally withdrawn after submission. Typically because asset identified as false positive, content determined to be legitimate, or organization requested retraction.
+
+All outcomes are logged clearly and shown to customers for transparency.
+
+## Takedown Retraction
+
+A **takedown retraction** is the formal process of stopping or reversing a takedown request after it has already been submitted to a provider.
+
+<Warning>
+Retractions ensure that legitimate content is not removed incorrectly and that providers are notified as quickly as possible when an issue is identified.
+</Warning>
+
+### When Retractions Occur
+
+A retraction is typically initiated when ChainPatrol determines that the original takedown was created in error:
+
+- **False Positive** - Asset was incorrectly classified as harmful
+- **Legitimate Content** - Further investigation shows content is authorized
+- **Customer Request** - Organization identifies the asset as legitimate
+
+### Retraction Process
+
+1. **Identification** - Asset is identified as legitimate or false positive
+2. **PENDING RETRACTION** - Takedown marked for retraction but request not yet sent
+3. **RETRACTION SENT** - Formal request submitted to provider to halt or reverse the takedown
+4. **RETRACTED** - Provider confirms takedown stopped or reversed
+
+Takedown retractions are handled with the same level of care, structure, and transparency as takedown submissions.
+
+## Types of Takedowns
+
+ChainPatrol supports multiple takedown categories, each with a clear expected outcome:
+
+**Website Takedowns** - Targets hosting providers, domain registrars, and TLD registries. Outcome: The website becomes inaccessible or the domain is suspended. Examples include phishing sites hosted on cloud providers, malicious domains registered through registrars, and typosquatting domains.
+
+**Social Media Takedowns** - Platforms include X/Twitter, Facebook, Instagram, YouTube, Telegram, Discord, Reddit. Outcome: The impersonating profile, channel, post, or video is removed or suspended. Examples include fake brand accounts, impersonation profiles, scam posts and videos, and malicious Telegram channels.
+
+**App Store Takedowns** - Targets mobile app platforms and extension marketplaces. Outcome: Fraudulent apps are removed from the marketplace. Examples include fake wallet apps, malicious browser extensions, and impersonation applications.
+
+**IPFS Takedowns** - Targets IPFS gateway operators or pinning services. Outcome: The malicious IPFS content is unpinned or becomes inaccessible through common gateways. Examples include phishing sites hosted on IPFS and malicious content distributed via decentralized storage.
+
+## Customer Visibility & Status Updates
+
+Inside ChainPatrol, customers have clear visibility into each takedown:
+
+- **Current State** - Real-time status: TODO, IN PROGRESS, COMPLETED, CANCELED, or retraction states
+- **Timestamps** - Complete timeline of all major actions and state changes
+- **Provider Responses** - Full copies of emails and communications from providers
+- **Evidence of Removal** - Confirmation when content has been successfully removed
+
+This gives customers a full understanding of progress and outcomes throughout the entire takedown lifecycle.
+
+## Security & Compliance
+
+ChainPatrol ensures that all takedown-related data is handled securely and responsibly:
+
+- **Secure Storage** - Legal documents stored using secure systems and access controls
+- **Limited Sharing** - Data only shared with providers when explicitly required
+- **Industry Standards** - Following best practices to protect customer data
+- **Confidentiality** - Maintaining strict confidentiality throughout the process
+
+## Frequently Asked Questions
+
+**How do I know if my takedown was successful?**
+The takedown will move to the **COMPLETED** state, and you'll see confirmation from the provider in the takedown timeline.
+
+**Why did my takedown take longer than expected?**
+Response times vary across platforms. Some act quickly, while others require legal documentation or take several days to respond. Hosting providers and domain registrars have different response times, and some platforms may take longer than others.
+
+**What happens if the content appears again?**
+If previously removed content reappears, the existing takedown is **reactivated** by returning to the **TODO** state. ChainPatrol will then act on it again, re-filing requests until the content is completely taken down.
+
+**Can ChainPatrol guarantee removal?**
+No provider guarantees removal in all cases, but ChainPatrol works to maximize success through consistent, accurate submissions and continuous monitoring. Our success rates vary by provider but are typically very high for legitimate threats.
+
+**What documentation do I need to provide?**
+Most takedowns require legal documents such as Letter of Authorization, Power of Attorney, Trademark registration, and Business registration documents. Requirements vary by provider and will be communicated during onboarding.
+
+## Key Takeaways
+
+- Takedowns happen automatically after blocking: Every blocked asset with Takedowns enabled gets a takedown request without manual intervention
+- Watchlist monitoring confirms success: Assets are watchlisted during takedowns so we automatically detect when they go offline
+- Retractions protect against false positives: If an asset is identified as legitimate after a takedown starts, we send formal retraction requests to prevent wrongful removal
+- Provider-specific formatting increases success: Different platforms require different submission formats, and we handle this automatically to maximize removal rates
diff --git a/getting-started/how-it-works/watchlist.mdx b/getting-started/how-it-works/watchlist.mdx
new file mode 100644
index 0000000..82eeb2b
--- /dev/null
+++ b/getting-started/how-it-works/watchlist.mdx
@@ -0,0 +1,140 @@
+---
+title: "Watchlist"
+description: "How ChainPatrol monitors assets to detect when they become malicious or go offline"
+---
+
+## Overview
+
+The watchlist is a set of assets that are not blocked or allowed, but are **actively monitored**. We watchlist assets for two main reasons:
+
+- **Review Process** - Monitoring assets to determine if they become malicious
+- **Takedown Process** - Monitoring assets to determine if they go offline
+
+### When Assets Leave the Watchlist
+
+We remove assets from the watchlist for three reasons:
+
+- **Asset Allowed** - Asset status changed to ALLOWED
+- **Comes Back Online** - Previously dead asset becomes accessible again
+- **Offline Too Long** - Asset has been offline for more than 30 days
+
+<Info>
+For more details about the watchlist concept, see our [Concepts documentation](/concepts/watchlist).
+</Info>
+
+## Placing Assets onto the Watchlist
+
+### Review Process
+
+During the review flow, an analyst can choose to put an asset onto the watchlist. This is typically done for two scenarios:
+
+**Parking Page** - The domain is reserved but has no active content. The URL indicates potential brand impersonation, but there's not enough evidence yet to perform a takedown. We monitor to see if malicious content appears. Example: `metamask-airdrop.com` shows a domain parking page, but the name suggests future malicious use.
+
+**Dead Asset** - The asset is currently offline or inaccessible. The URL structure suggests brand impersonation, but we can't analyze content that doesn't exist yet. We monitor to detect when it comes online. Example: `uniswap-claim.xyz` returns a 404 error, but the domain name is suspicious.
+
+### Takedown Process
+
+When we file a takedown, we automatically place the asset being taken down onto the watchlist.
+
+1. **Takedown Filed** - Takedown request submitted to the appropriate provider
+2. **Asset Watchlisted** - Asset automatically added to watchlist for monitoring
+3. **Automated Monitoring** - Regular scans check if the asset goes offline
+4. **Automatic Completion** - If asset goes offline, takedown is marked as complete automatically
+
+This automation allows us to confirm successful takedowns without manual verification, speeding up the entire process.
+
+### Watchlist Eligibility
+
+Only specific asset types can be placed on the watchlist due to our ability to monitor them consistently in an automated fashion:
+
+- **URL** - Web addresses and domains
+- **Page** - Specific web pages
+- **Email** - Email addresses
+- **Twitter** - Twitter/X accounts
+- **Telegram** - Telegram channels and users
+
+Asset types not on this list are monitored by our human staff for takedown confirmation instead of automated watchlist monitoring.
+
+## What Happens When Assets Are on the Watchlist
+
+When an asset is on the watchlist, we monitor it by running asset scans periodically to determine if there is any change in behavior:
+
+- **Status Changes** - Monitoring HTTP status codes and accessibility
+- **Content Changes** - Detecting modifications to page content
+- **Infrastructure Changes** - Tracking DNS record and hosting changes
+
+We also run checks to determine if we should keep the asset on the watchlist or remove it because it's unlikely to become malicious.
+
+<Tip>
+**Adaptive Frequency:** Assets recently added to the watchlist are scanned more frequently. As time passes without changes, scan frequency decreases to optimize resources.
+</Tip>
+
+## Scan Frequency
+
+We cycle through the watchlist each minute, checking about **150 assets at a time**. Scan frequency depends on how long the asset has been on the watchlist and its current status.
+
+### UNKNOWN / ALLOWED Assets
+
+Assets that are not yet blocked are scanned more frequently:
+
+| Time on Watchlist | Scan Frequency |
+|-------------------|----------------|
+| < 6 hours | Hourly |
+| < 24 hours | Every 2 hours |
+| < 2 days | Every 4 hours |
+| < 7 days | Every 6 hours |
+| < 2 weeks | Every 12 hours |
+| < 1 month | Daily |
+| < 2 months | Every 2 days |
+| > 2 months | Every 4 days |
+
+### BLOCKED Assets
+
+Blocked assets are scanned less frequently since they're already protected:
+
+| Time on Watchlist | Scan Frequency |
+|-------------------|----------------|
+| < 6 hours | Every 3 hours |
+| < 24 hours | Every 6 hours |
+| < 2 days | Every 12 hours |
+| < 7 days | Every 18 hours |
+| < 2 weeks | Every 36 hours |
+| < 1 month | Every 3 days |
+| < 2 months | Every 6 days |
+| > 2 months | Every 12 days |
+
+**Why the difference?** UNKNOWN and ALLOWED assets need closer monitoring to catch when they become malicious. BLOCKED assets are already protected, so we primarily monitor to confirm takedown success.
+
+## Removing Assets from the Watchlist
+
+Assets are automatically removed from the watchlist under specific conditions:
+
+### Asset Becomes ALLOWED
+
+If an asset's status changes from `BLOCKED` or `UNKNOWN` to `ALLOWED`, we immediately remove it from the watchlist. Allowed assets are verified as legitimate and don't require monitoring.
+
+### Asset Comes Online
+
+If an asset's liveness status changes from `DEAD` to `ALIVE` or `UNKNOWN`, we remove it from the watchlist. The asset is pushed back into the review queue where a human analyst will evaluate whether it's malicious.
+
+### Decay Factor
+
+**UNKNOWN Assets - 30 Day Limit** - If an asset is in `UNKNOWN` status, we remove it from the watchlist after 30 days. If an asset hasn't become malicious after a month, it's unlikely to pose a threat.
+
+**Takedown Success** - If the asset was watchlisted during the takedown process and the takedown is in `IN_PROGRESS` state, when the asset goes offline or the takedown provider suspends the asset, it's removed from the watchlist since the takedown was successful.
+
+**Manual Removal** - An analyst can manually remove an asset from the watchlist if they determine it's no longer necessary to monitor.
+
+## Best Practices
+
+- **Use for Suspicious Domains** - Watchlist domains with suspicious names but no active content yet
+- **Monitor Takedowns** - Let the watchlist automatically confirm takedown success
+- **Review Regularly** - Periodically review long-term watchlist items to ensure they're still relevant
+- **Trust the Automation** - The adaptive scan frequency optimizes monitoring without manual intervention
+
+## Key Takeaways
+
+- Watchlist is for the gray area: Use it when you suspect an asset might be malicious but don't have enough evidence to block yet
+- Automatic takedown monitoring saves time: Every takedown automatically watchlists the asset to detect when it goes offline, eliminating manual checking
+- Adaptive frequency optimizes resources: Recent additions scan hourly while stable assets scan less often, so you catch changes quickly without wasting scans
+- 30-day decay prevents watchlist bloat: UNKNOWN assets that haven't become malicious after a month are automatically removed, keeping your monitoring focused
diff --git a/getting-started/what-we-do/brand-impersonation.mdx b/getting-started/what-we-do/brand-impersonation.mdx
new file mode 100644
index 0000000..2e0adf8
--- /dev/null
+++ b/getting-started/what-we-do/brand-impersonation.mdx
@@ -0,0 +1,85 @@
+---
+title: "Brand Impersonation"
+description: "Understanding brand impersonation attacks and how to protect against them"
+---
+
+## Overview
+
+Brand impersonation is a broad category of abuse where malicious actors **pretend to be a legitimate brand or someone associated with it** in order to deceive users, steal assets, spread disinformation, or damage trust.
+
+<Warning>
+Brand impersonation is commonly used to steal money, credentials, or sensitive information, distribute malware, manipulate public perception, or damage a brand's reputation.
+</Warning>
+
+These attacks often span multiple platforms and combine technical methods with social engineering. Brand impersonation can occur across websites, social media platforms, advertising networks, search engines, email and messaging apps, and Web3 and blockchain ecosystems.
+
+## Types of Impersonation
+
+### 1. Brand Impersonation
+
+Attackers pose directly as the official company or product. This usually involves copying branding elements such as logos, names, visual identity, and messaging to create fake websites, social media profiles, advertisements, or applications.
+
+**Impact:** Because these assets are designed to look authentic, users often cannot distinguish them from legitimate channels. This type of impersonation directly undermines brand trust and frequently leads to financial fraud or credential theft.
+
+### 2. Employee Impersonation
+
+Employee impersonation occurs when attackers pretend to be real employees, executives, founders, or other public representatives of a company. These impersonators often leverage the perceived authority of the role to pressure victims or bypass skepticism.
+
+**Impact:** This form of impersonation is particularly dangerous because it can be used for targeted social engineering attacks, internal fraud, or high-value scams where credibility is critical.
+
+### 3. Customer Support Impersonation
+
+Customer support impersonation focuses on exploiting users who are already seeking help. Attackers present themselves as official support agents and engage victims through replies, direct messages, or emails.
+
+**Impact:** This technique is commonly used to steal login credentials, recovery phrases, or wallet access, especially in crypto and fintech environments where support interactions are frequent and time-sensitive.
+
+### 4. Partnership Impersonation
+
+Partnership impersonation involves false claims of collaboration, endorsement, or integration with another trusted brand or organization. Attackers rely on the perceived legitimacy of a partnership to gain credibility.
+
+**Impact:** This type of impersonation is often used in scam announcements, fake landing pages, or social media campaigns and can damage both the impersonated brand and the falsely claimed partner.
+
+## Common Technologies & Techniques Used
+
+<Note>
+Brand impersonation campaigns typically rely on a combination of technical and behavioral techniques rather than a single method.
+</Note>
+
+**Deepfakes** - Deepfake technology is increasingly used to generate convincing audio, video, or images of executives or public figures, enabling fake announcements, investment scams, or social engineering attacks that appear highly authentic.
+
+**Bot Attacks** - Bot-driven attacks are commonly used to create and manage large numbers of fake accounts, amplify malicious content, and artificially boost engagement. This makes impersonation campaigns appear legitimate and widely supported.
+
+**Replies and Comment Hijacking** - Reply and comment hijacking is another frequent technique, where attackers post malicious replies under legitimate brand content. These replies often pose as support or official guidance and exploit the visibility and trust of the original post.
+
+**Typosquatting** - Typosquatting remains a foundational method, involving the registration of domains that closely resemble official brand domains. These domains are typically used for phishing, malware delivery, or credential harvesting.
+
+**Advertising Abuse** - Advertising abuse, particularly through search ads, allows attackers to place impersonation content above legitimate results. Users often assume ads are verified, which makes this channel especially effective for deception.
+
+**Fake NFT Mints** - In Web3 ecosystems, fake NFT mints and blockchain-related scams are prevalent. These attacks often combine impersonated announcements, cloned websites, and malicious smart contracts designed to drain wallets.
+
+**Disinformation** - Disinformation campaigns may not always involve direct scams but are still a form of impersonation when false information is attributed to a brand or its representatives. These campaigns aim to manipulate perception, create confusion, or erode trust.
+
+**SEO Spam** - SEO spam involves generating large volumes of low-quality pages optimized for brand-related keywords. These pages redirect users to malicious destinations and are difficult to combat due to their scale.
+
+**Account Compromise** - Account compromise occurs when legitimate brand or employee accounts are taken over and then used to distribute scams or malicious content. Because the account was originally authentic, detection is significantly harder. In more advanced cases, attackers may compromise DNS or hosting infrastructure, allowing them to redirect traffic from legitimate domains to malicious content without altering the visible URL.
+
+## What Can You Do About Brand Impersonation?
+
+While brand impersonation cannot be fully eliminated, its impact can be significantly reduced through proactive measures.
+
+1. **Define Official Assets** - Clearly define and publicly communicate which assets are official. This includes domains, social media accounts, communication channels, applications, and, where applicable, blockchain addresses or smart contracts. Making this information easy to find helps users verify authenticity.
+
+2. **Enable Community Reporting** - Community involvement plays a critical role in early detection. Users often encounter impersonation before internal teams do, so providing clear reporting paths and responding visibly to reports helps shorten the damage window and builds trust.
+
+3. **Educate Your Users** - Education is equally important. By teaching users what official representatives will and will not do, and by highlighting common scam patterns, organizations can reduce the effectiveness of impersonation even when attacks occur.
+
+4. **Partner with Security Vendors** - For brands with a large digital footprint or high-risk exposure, working with specialized security vendors is often necessary. These vendors provide continuous monitoring, automated detection, coordinated takedowns, and cross-platform visibility that is difficult to achieve internally.
+
+ChainPatrol provides monitoring, detection, and takedown services for Web3 organizations. If you'd like to learn more, you can [schedule a demo](https://cal.com/chainpatrol).
+
+## Key Takeaways
+
+- Impersonation is multi-platform by nature: Attackers rarely stick to one channel, so protection requires monitoring websites, social media, ads, and apps simultaneously
+- Community reporting acts as an early warning system: Users often spot impersonation before internal teams because they interact with your brand across more channels
+- Official asset lists reduce confusion: Publicly documenting your legitimate domains, accounts, and contracts helps users verify authenticity and report fakes
+- Compromised accounts are harder to detect: When attackers take over real accounts instead of creating fake ones, standard verification methods fail and response time becomes critical
diff --git a/getting-started/what-we-do/general-phishing.mdx b/getting-started/what-we-do/general-phishing.mdx
new file mode 100644
index 0000000..66ff00b
--- /dev/null
+++ b/getting-started/what-we-do/general-phishing.mdx
@@ -0,0 +1,99 @@
+---
+title: "General Phishing"
+description: "Understanding phishing attacks and common attack vectors in Web3"
+---
+
+## Overview
+
+Phishing is a malicious attack that involves someone pretending to be a legitimate actor. Phishing comes in many forms, but the ultimate goal is to gain the trust of the end user and steal their information.
+
+This includes passwords, credit card numbers, or even a user's two factor authentication codes. In the context of Web3, common attack vectors aim to steal a user's seed phrase for their wallet, or simply all of the contents of their wallets.
+
+## Types of Phishing Attack Vectors
+
+### Wallet Drainers
+
+Wallet drainers are a tool that scammers use to quickly steal all of the funds from a user's wallet without them knowing.
+
+**How it works:**
+
+1. A scammer sets up a fake site that looks very similar to a legitimate one, like the homepage of a wallet, or a fake airdrop that looks like it's advertising a legitimate token
+2. The user is prompted to connect their wallet to the website
+3. Once connected, the user is prompted to sign a transaction that is described in vague terms or lies about its intentions
+4. By agreeing, the user signs a broad smart contract that gives the scammer permission for unlimited token withdrawal on the victim's wallet
+5. The scammer scans the user's wallet to find any tokens, NFTs, or other valuable assets, and transfers them to their wallet
+6. The stolen assets are disseminated to multiple wallets to make tracking more difficult
+
+### Seed Recovery Phrase Theft
+
+Seed recovery phrase theft is when a scammer tries to get the seed recovery phrase of a user by pretending to need it for a legitimate purpose.
+
+**Important:** Users should never share their seed recovery phrase with anyone, as it will grant complete access to their wallet and all of their tokens to any actor who has it.
+
+**Common tactics:**
+
+- Fake airdrops that promise large rewards
+- "Doubling" scams that claim to multiply the amount of a specific token
+- Requests to type in the full seed recovery phrase to claim rewards
+
+Once the user types in their seed recovery phrase, the attacker will use it to lock the victim out of their assets, and disseminate them to multiple other wallets to make tracking the stolen assets more difficult.
+
+### Social Engineering
+
+Social engineering involves gaining a user's trust so that they voluntarily provide confidential details to an attacker.
+
+**In the context of Web3:**
+
+Social engineering may involve fake tech support for a wallet responding to requests about being unable to access funds. Attackers gain trust by seeming legitimate through conversations over email or phone. Once sufficient trust is built, they will ask for seed phrases or request the user to connect their wallet to a wallet drainer.
+
+**Warning signs:**
+
+- Unsolicited contact from "support" representatives
+- Requests for sensitive information like seed phrases
+- Pressure to act quickly or urgently
+- Communication through unofficial channels
+
+### Malware Distribution
+
+Malware distribution involves a user downloading or otherwise obtaining a malicious program on their system.
+
+**Common disguises:**
+
+These programs often masquerade as legitimate software. For example:
+- A browser extension that looks like an official wallet extension
+- Fake wallet applications
+- Compromised software updates
+
+Once installed, the malware will use one of the aforementioned techniques to steal a user's information, including seed phrases, private keys, or direct wallet access.
+
+### Developer Key Compromise
+
+Developer key compromise occurs when a developer's private keys for accessing sensitive information are obtained by attackers.
+
+**The danger:**
+
+This allows the attacker to:
+- Impersonate the developer
+- Access systems the developer works on
+- Inject malicious code into legitimate programs
+
+This is particularly dangerous because it allows attackers to infiltrate legitimate services and have a widespread impact across an entire user base. Users trust the legitimate application, making them more vulnerable to attacks that originate from compromised developer accounts.
+
+## Protecting Yourself from Phishing
+
+<Tip>
+**Key principle:** Legitimate projects will never ask for your seed phrase, private keys, or request you to sign suspicious transactions.
+</Tip>
+
+Always verify:
+- Website URLs carefully before connecting your wallet
+- The authenticity of support representatives
+- Browser extensions and applications before installation
+- Transaction details before signing anything
+
+## Key Takeaways
+
+- Wallet drainers exploit transaction approval flows: Unlike traditional phishing that steals passwords, wallet drainers trick users into signing legitimate-looking transactions that grant unlimited withdrawal permissions
+- Seed phrases are the master key: A compromised seed phrase gives attackers complete and permanent control, which is why legitimate projects never ask for them under any circumstances
+- Social engineering bypasses technical protections: Even with security tools in place, attackers who build trust through fake support interactions can convince users to voluntarily disable protections
+- Developer key compromise has cascading impact: When attacker gains access to a developer's keys, they can inject malicious code into trusted applications that affect thousands of users simultaneously
diff --git a/getting-started/what-we-do/introduction.mdx b/getting-started/what-we-do/introduction.mdx
new file mode 100644
index 0000000..c183c0d
--- /dev/null
+++ b/getting-started/what-we-do/introduction.mdx
@@ -0,0 +1,69 @@
+---
+title: "Introduction"
+description: "Protecting Web3 Communities from Phishing and Impersonation Attacks"
+---
+
+## Overview
+
+In the rapidly evolving Web3 landscape, malicious actors are constantly targeting crypto users through sophisticated phishing attacks, fake domains, and social media impersonation. These threats not only put your community's assets at risk but can also severely damage your brand's reputation and erode user trust.
+
+## Enterprise-Grade Protection for Leading Web3 Organizations
+
+Today, ChainPatrol serves as the trusted security partner for some of the most prominent names in the blockchain industry, including Consensys, Sui, Arbitrum, ZkSync, Curve Finance, Starknet, and Polymarket.
+
+These organizations rely on us to safeguard their communities from online impersonation and phishing attacks 24/7.
+
+## Real-Time Protection Through Wallet Integration
+
+At the core of our solution is a **continuously updated blocklist** of malicious domains, directly integrated into leading crypto wallets.
+
+<Info>
+**Protected Wallets:** MetaMask, Coinbase Wallet, Phantom, and many more leading wallets
+</Info>
+
+When users attempt to interact with a flagged malicious site, they receive an immediate warning, preventing potential losses before they happen. This proactive approach provides an essential layer of security that protects users at the point of transaction.
+
+## Comprehensive Detection and Rapid Response
+
+Our advanced detection system continuously monitors the digital landscape to identify scams impersonating your company across multiple channels:
+
+- **Domains** - We scan for lookalike domains and phishing sites using your brand
+- **Twitter/X** - Automated monitoring for fake accounts impersonating your official channels
+- **Discord** - Detection of malicious servers and impersonator accounts targeting your community
+- **Other Social Platforms** - Comprehensive coverage across the social media ecosystem
+
+### Our Three-Step Response Process
+
+When a threat is detected, our response is swift and decisive:
+
+1. **Immediate Protection** - Malicious sites are blocked across our Wallet Network within minutes of detection, preventing your users from interacting with them
+2. **Complete Takedown** - We don't stop at blocking. Our team proceeds with full takedown procedures, working to permanently remove fraudulent domains and social media accounts
+3. **Ongoing Monitoring** - Continuous surveillance ensures new threats are identified and neutralized as they emerge
+
+## The Cost of Inaction
+
+<Warning>
+Every day that phishing attacks go unaddressed, your community members are at risk of losing funds, and your brand reputation suffers.
+</Warning>
+
+Traditional security measures often react too slowly, allowing scammers to victimize multiple users before threats are contained.
+
+## See ChainPatrol in Action
+
+We'd love to show you how ChainPatrol can protect your organization and community. In a brief demo, we'll walk you through:
+
+- **Real-Time Detection** - See our detection capabilities in action
+- **Wallet Integration** - How we protect users at the point of interaction
+- **Rapid Response** - Our takedown process and response times
+- **Reporting & Analytics** - Stay informed of threats targeting your brand
+
+If you'd like to see ChainPatrol in action, you can [book a demo](https://cal.com/chainpatrol).
+
+Don't let phishing attacks compromise your community's security and your brand's reputation.
+
+## Key Takeaways
+
+- Wallet integration provides point-of-transaction protection: Unlike email security or website warnings that users might miss, wallet integrations prevent interactions with malicious sites at the moment of connection
+- Blocklist-first approach eliminates the waiting game: Users are protected within minutes through blocklist distribution while takedown requests work through slower provider channels
+- Multi-channel monitoring catches threats early: Attackers spread campaigns across domains, social media, and ads simultaneously, so protection requires monitoring all channels at once
+- Community protection multiplies individual security: When one organization's threat is blocked, all wallet users benefit from the updated blocklist regardless of which brand was targeted
diff --git a/guides/api-keys.mdx b/guides/api-keys.mdx
new file mode 100644
index 0000000..fa66e37
--- /dev/null
+++ b/guides/api-keys.mdx
@@ -0,0 +1,8 @@
+---
+title: "API Keys"
+description: "How to generate and manage API keys"
+---
+
+# API Keys
+
+[Content to be added]
diff --git a/guides/communicating-with-chainpatrol.mdx b/guides/communicating-with-chainpatrol.mdx
new file mode 100644
index 0000000..a53b73f
--- /dev/null
+++ b/guides/communicating-with-chainpatrol.mdx
@@ -0,0 +1,8 @@
+---
+title: "Communicating With ChainPatrol"
+description: "Best practices for communicating with the ChainPatrol team"
+---
+
+# Communicating With ChainPatrol
+
+[Content to be added]
diff --git a/guides/enabling-disabling-services.mdx b/guides/enabling-disabling-services.mdx
new file mode 100644
index 0000000..05c6e3b
--- /dev/null
+++ b/guides/enabling-disabling-services.mdx
@@ -0,0 +1,8 @@
+---
+title: "Enabling/Disabling Services"
+description: "How to enable and disable ChainPatrol services"
+---
+
+# Enabling/Disabling Services
+
+[Content to be added]
diff --git a/guides/false-positives.mdx b/guides/false-positives.mdx
new file mode 100644
index 0000000..cc6582d
--- /dev/null
+++ b/guides/false-positives.mdx
@@ -0,0 +1,8 @@
+---
+title: "False Positives"
+description: "How to handle and report false positives"
+---
+
+# False Positives
+
+[Content to be added]
diff --git a/guides/gathering-allowlist.mdx b/guides/gathering-allowlist.mdx
new file mode 100644
index 0000000..34ed6bb
--- /dev/null
+++ b/guides/gathering-allowlist.mdx
@@ -0,0 +1,8 @@
+---
+title: "Gathering Allowlist"
+description: "How to build and maintain your allowlist"
+---
+
+# Gathering Allowlist
+
+[Content to be added]
diff --git a/guides/public-reports.mdx b/guides/public-reports.mdx
new file mode 100644
index 0000000..9ca52e4
--- /dev/null
+++ b/guides/public-reports.mdx
@@ -0,0 +1,8 @@
+---
+title: "Public Reports"
+description: "How to work with public reports"
+---
+
+# Public Reports
+
+[Content to be added]
diff --git a/guides/setting-up-brands.mdx b/guides/setting-up-brands.mdx
new file mode 100644
index 0000000..7c6053e
--- /dev/null
+++ b/guides/setting-up-brands.mdx
@@ -0,0 +1,8 @@
+---
+title: "Setting Up Brands"
+description: "How to configure brands in ChainPatrol"
+---
+
+# Setting Up Brands
+
+[Content to be added]
diff --git a/guides/sso.mdx b/guides/sso.mdx
new file mode 100644
index 0000000..96369fb
--- /dev/null
+++ b/guides/sso.mdx
@@ -0,0 +1,8 @@
+---
+title: "SSO"
+description: "How to set up Single Sign-On"
+---
+
+# SSO
+
+[Content to be added]
diff --git a/guides/unflagging-your-assets.mdx b/guides/unflagging-your-assets.mdx
new file mode 100644
index 0000000..72df2b5
--- /dev/null
+++ b/guides/unflagging-your-assets.mdx
@@ -0,0 +1,8 @@
+---
+title: "Unflagging Your Assets"
+description: "How to unflag incorrectly flagged assets"
+---
+
+# Unflagging Your Assets
+
+[Content to be added]
diff --git a/integration/canary-tokens.mdx b/integration/canary-tokens.mdx
new file mode 100644
index 0000000..bdc52ac
--- /dev/null
+++ b/integration/canary-tokens.mdx
@@ -0,0 +1,88 @@
+---
+icon: dove
+title: Canary Tokens
+description: Use Canary Tokens to notify ChainPatrol when your website is cloned and have them blocked immediately
+---
+
+## What is a Canary Token?
+
+Canary Tokens are a free, open-source tool that helps you discover when bad actors access your data. They can be used to detect unauthorized access to your website, documents, or other sensitive information.
+
+You can read more on the [Canary Tokens website](https://docs.canarytokens.org/guide/).
+
+## Cloned Website Tokens
+
+Cloned Website Tokens are a type of Canary Token that can be used to detect when your website is cloned. They work by embedding a unique token into your website that is invisible to your users. When a bad actor clones your website, they will also clone the token. When the token is accessed, you will be notified and ChainPatrol will proceed to block and takedown the malicious cloned site.
+
+You can read more about Cloned Website Tokens on the [Canary Tokens website](https://docs.canarytokens.org/guide/cloned-web-token.html).
+
+## Setup Instructions
+
+<Steps>
+  <Step title="Create a new Canary Token">
+    Go to the [Canary Tokens Nest](https://canarytokens.org/nest/) and select the `JS cloned website` from the list.
+
+    Fill the fields with the information below:
+
+    | Field | Value |
+    | :---- |:----- |
+    | Domain of protected website | `<YOUR DOMAIN>` |
+    | Mail me here when the alert fires | `<YOUR EMAIL>` |
+    | Remind me of this when the alert fires | Any note you'd like (ex. `Token for <YOUR DOMAIN>`) |
+
+    Next, click **Add Webhook Notification**, and fill in the following information:
+
+    | Field | Value |
+    | :---- |:----- |
+    | Notify me here when the alert fires | `https://app.chainpatrol.io/api/v2/canary/webhook` |
+
+    It should look something like this when you are done:
+
+    ![Canary Generation](/images/canary.png)
+
+    Click **Create Canarytoken**.
+
+  </Step>
+  <Step title="Navigate to Manage Token">
+    After the token is created, you will see the modal with the token information.
+
+    ![Canary Success](/images/canary-success.png)
+
+    Click **Manage Canarytoken** to navigate to the token's page.
+
+    > **Note:** You should save this current page's URL for future reference.
+  </Step>
+  <Step title="Add the token to ChainPatrol">    
+
+    After clicking the button, you will be redirected to the token's page. This is a uniquely generated URL containing the token that you can come back to see the history of the your Canary Token.
+
+    Example: `https://canarytokens.org/nest/manage/<NEST_ID>/<TOKEN_ID>`
+
+    Next, go to your ChainPatrol dashboard and go to **Settings** > **Canary Tokens**.
+    
+    ![Canary Token ID](/images/organization-canary-tokens.png)
+
+    In order for ChainPatrol to automatically detect cloned websites, **create new token, and paste the token ID from your token's page**.
+
+    After creating the token, you will see the token in the list. You can delete or edit the token at any time.
+
+    At this point, our webhook will start receiving alerts when the token is accessed.
+
+    ![Added Canary Token](/images/organization-added-canary-token.png)
+  </Step>
+  <Step title="Add the generated JavaScript snippet to your website">
+    Finally, to complete the setup of the Canary Token, you need to add the generated JavaScript snippet to the domain that you indicated earlier.
+    
+    1. Toggle ON the **"Obfuscate this script"** option and copy the generated code.
+    2. Paste the code into your website's HTML code, preferably in the `<head>` tag on the homepage.
+    
+    > **Note:** We recommend turning OFF **Email Alerts**, since they may include localhost URLs and other false positives. We will handle the alerts via webhook.
+  </Step>
+</Steps>
+
+## What happens when a cloned website is detected?
+
+When your website is cloned, we will create a new report in your ChainPatrol dashboard.
+ChainPatrol will proceed to block and takedown the malicious cloned site.
+
+![Canary Report](/images/canary-report.png)
diff --git a/integration/discord.mdx b/integration/discord.mdx
new file mode 100644
index 0000000..8af1936
--- /dev/null
+++ b/integration/discord.mdx
@@ -0,0 +1,196 @@
+---
+icon: discord
+title: Discord Bot
+sidebarTitle: Discord
+description: A Discord bot that can be used submit scam reports to ChainPatrol
+---
+
+<Frame>![ChainPatrol Discord Bot](/images/discord-bot.png)</Frame>
+
+If you have a **Discord server**, you can use the [ChainPatrol Discord bot](https://chainpatrol.com/bot)
+to let your server members submit scam reports to **ChainPatrol**. The bot will generate new
+reports that get sent to your admin dashboard for review.
+
+## Setup
+
+<Tip>
+  If you have a dedicated `scam-reports` channel, we recommend pinning a message
+  in this channel and directing your server members to use the bot there for
+  easy reporting
+</Tip>
+
+### Install the bot
+
+To add the bot to your server, you need to be an admin of the server. Then, you
+can use the following link to add the bot:
+
+[🚀 Add ChainPatrol to your server](https://chainpatrol.com/bot/install)
+
+Next, you need to configure the bot to send reports to your admin dashboard on ChainPatrol. Right now,
+this is can be done by reaching out to us [via email](mailto:support@chainpatrol.io?subject=%5BDiscord%20Bot%5D%20Setup%20integration%20with%20ChainPatrol&body=Hi,%20I%20would%20like%20to%20link%20the%20Discord%20bot%20to%20my%20ChainPatrol%20account%20as%20described%20here:%20https://chainpatrol.io/docs/general/discord-bot.%0A%0AThanks!)
+and letting us know that you want to add the bot to your server. We will create an organization
+for you on ChainPatrol and you can then use the `/setup connect` slash command to link your Discord server
+to your organization on ChainPatrol.
+
+To check that the bot is working, you can use the `/setup status` command to see if the bot is
+connected to your ChainPatrol organization.
+
+## Features
+
+### Scam Reports
+
+The bot allows server members to submit scam reports directly to ChainPatrol.
+
+#### Usage
+
+Once the bot is added to your server, you can use the following commands:
+
+- `/report <url>` - Submit a scam report for the given URL
+- `/check <url>` - Check if the given URL is a scam
+
+#### Example
+
+Here is an example of how to use the bot to submit a scam report:
+
+![Example of using the ChainPatrol Discord bot](/images/discord-bot-prompt.png)
+![Loading of the ChainPatrol Discord bot](/images/discord-bot-loading.png)
+![Success of the ChainPatrol Discord bot](/images/discord-bot-success.png)
+
+### Reports Feed
+
+You can create a feed channel of all reports to your organization. This feature allows you to see all scam reports submitted through the bot in a dedicated channel.
+
+#### Setup
+
+1. Create a new channel on your Discord server and name it something like `chainpatrol-reports`
+2. Use the following command to link the channel to your ChainPatrol organization:
+   ```
+   /setup feed <channel>
+   ```
+3. Follow the instructions in the bot's response to link the channel to your ChainPatrol organization
+
+![Image showing the Discord bot's response to the setup feed command](/images/discord-bot-feed-setup.png)
+
+You can check that the feed is connected correctly by running the `/setup status` command. If the
+feed is connected correctly, you should see the channel name in the bot's response.
+
+![Image showing the Discord bot's response to the setup status command after setting up the feed](/images/discord-bot-feed-status.png)
+
+As a final test, you can try submitting a test scam report using the `/report` command. You should see a message
+in the feed channel with the scam report shortly after submitting.
+
+![Example of the feed channel](/images/discord-bot-feed.png)
+
+### Link Monitoring
+
+ChainPatrol can monitor your Discord channels for suspicious links and automatically take action when they are detected. This feature helps protect your community from scams and malicious content.
+
+#### Setup
+
+To enable link monitoring in a channel:
+
+1. Navigate to the channel you want to monitor
+2. Run the `/setup linkmonitoring` command
+3. Confirm the setup when prompted
+
+<Tip>
+  Only server administrators or users with "Manage Server" permissions can
+  enable link monitoring
+</Tip>
+
+#### How it Works
+
+Once enabled, ChainPatrol will:
+
+1. Monitor all messages in the configured channel for URLs
+2. Check each URL against ChainPatrol's comprehensive blocklist, which includes:
+   - Known scam websites
+   - Phishing attempts
+   - Malicious domains
+   - Other security threats reported to ChainPatrol
+3. Take action based on your server's configuration when suspicious links are detected
+
+<Tip>
+  The blocklist is continuously updated with new threats reported by the
+  ChainPatrol community and security researchers. You can [search through our
+  blocklist](https://app.chainpatrol.io/search) to see what threats we're
+  protecting against.
+</Tip>
+
+#### Response Actions
+
+When a suspicious link is detected, ChainPatrol can be configured to:
+
+- **React with 🚨** - Adds a warning reaction to the message
+- **Delete the message** - Automatically removes the message
+- **Notify moderators** - Sends an alert to your moderator channel
+
+<Tip>
+  The response action is configured by your server administrator through the
+  ChainPatrol dashboard
+</Tip>
+
+#### Example
+
+Here's what happens when a suspicious link is detected:
+
+![Example of link monitoring in action](/images/discord-bot-link-monitoring.png)
+
+## Common Issues
+
+<Frame>![no-response](/images/discord-application-no-response.png)</Frame>
+
+### Custom Elevated Permissions
+
+- Bot role may need elevated permission to interact with private channels
+
+- If you are adding the bot to a channel that is not normally visible to `@everyone`, then you will need to
+  Slash commands not visible to Discord members
+
+  <CardGroup cols={2}>
+    <Card title="Private Channel Permissions" icon="square-1">
+      <Frame>![Kebab Menu](/images/discord-private-channel.png)</Frame>
+    </Card>
+    <Card title="Adding ChainPatrol Bot" icon="square-2">
+      <Frame>![Report Modal](/images/discord-select-app.png)</Frame>
+    </Card>
+  </CardGroup>
+
+- Embed links permissions are required for your reports feed
+
+  <Frame>![channel embeds](/images/discord-channel-embed-links.png)</Frame>
+
+- Make application commands available to users
+  - Server members will not be able to use the ChainPatrol bot commands if they do not have access to application commands
+    <Frame>
+      ![application commands](/images/discord-application-comands.png)
+    </Frame>
+
+## Debugging Tips
+
+### View Server As Role
+
+- You can right click the ChainPatrol role in server settings to see the server as the bot role
+
+  <Frame>![view as role](/images/discord-view-as-role.png)</Frame>
+
+<Tip>
+  Trying to access a feature in an inaccessible part of the server will lead to
+  an error. Make sure the bot's permissions can see and interact with what you
+  are debugging.
+
+Check out [Discord's Role Management 101](https://support.discord.com/hc/en-us/articles/214836687-Role-Management-101) Article for additional help!
+
+</Tip>
+
+## Privacy
+
+The bot does not collect any personal information. It only collects the URL and
+the Discord ID for the user that submitted the report (in case a moderator needs
+more information about why the URL is a scam). The bot does not store any information
+about the server it is added to.
+
+## Source Code
+
+The source code for the bot is available on GitHub:
+[chainpatrol/discord-bot](https://github.com/chainPatrol/discord-bot)
diff --git a/integration/github.mdx b/integration/github.mdx
index 89ea4c2..d42e79f 100644
--- a/integration/github.mdx
+++ b/integration/github.mdx
@@ -1,6 +1,6 @@
 ---
 icon: github
-title: GitHub Integration
+title: GitHub
 description: Connect your GitHub repositories to ChainPatrol to protect your community from scam links and malicious content
 ---
 
diff --git a/integration/intercom.mdx b/integration/intercom.mdx
index a233aa7..666890d 100644
--- a/integration/intercom.mdx
+++ b/integration/intercom.mdx
@@ -1,6 +1,6 @@
 ---
 icon: square
-title: Intercom Integration
+title: Intercom
 description: Connect your Intercom workspace to ChainPatrol to report suspicious URLs and protect against phishing
 ---
 
diff --git a/integration/slack.mdx b/integration/slack.mdx
new file mode 100644
index 0000000..a47bede
--- /dev/null
+++ b/integration/slack.mdx
@@ -0,0 +1,198 @@
+---
+icon: slack
+title: Slack Bot
+sidebarTitle: Slack
+description: A Slack bot that can be used to submit scam reports to ChainPatrol
+---
+
+If you have a **Slack workspace**, you can use the ChainPatrol Slack Bot to let your workspace members submit scam reports to **ChainPatrol**. The bot will generate new reports that get sent to your admin dashboard for review.
+
+## Setup
+
+### Bot Installation
+
+<Steps>
+  <Step title="Go to the Admin Dashboard">
+    Start by opening your dashboard on the [ChainPatrol app](https://app.chainpatrol.io/).
+
+    <Frame>![Step 1 - Dashboard](/images/dashboard-navbar.png)</Frame>
+
+  </Step>
+  <Step title="Go to Organization Settings">
+    In the navbar, select **Settings** to go to your **Organization Settings** page.
+
+    <Frame>![Step 2 - Organization Settings](/images/organization-settings.png)</Frame>
+
+  </Step>
+  <Step title="Go to Integrations Tab">
+    Once you are in the organization settings, navigate to the **Integrations** tab. This section contains options for the Slack bot as well as other integrations.
+
+    <Frame>![Step 3 - Integrations Tab](/images/settings-integrations.png)</Frame>
+
+  </Step>
+  <Step title="Complete Slack OAuth">
+
+    In the Integrations tab, you will find an option to **Add to Slack**. Click this button, then you will be redirected to the Slack authorization page. Click **Allow**.
+
+    <Frame>![Step 4 - Add Bot](/images/slack-integration-authorization.png)</Frame>
+    <Tip>
+    Remember to select the correct workspace at the top right of the authorization page.
+    </Tip>
+
+  </Step>
+  
+</Steps>
+
+<Warning>
+  **Important**: Please avoid using organization-level installs for the
+  ChainPatrol Slack Bot. Organization-level and enterprise installs can cause
+  issues with the bot's functionality and may not properly integrate with your
+  ChainPatrol dashboard. Always use workspace-level installations to ensure
+  proper operation.
+</Warning>
+
+## Confirmation and Finalization
+
+The ChainPatrol Slack Bot should appear in your listed apps along with other allowed workspace apps.
+
+<Frame>![Slack Apps](/images/slack-apps.png)</Frame>
+
+### Adding ChainPatrol Bot To Your Reporting Channel
+
+<Warning>
+  Remember to add the slack bot to the reporting channel! By default, the
+  ChainPatrol bot does not automatically read and join existing channels for
+  privacy.
+</Warning>
+
+<CardGroup cols={3}>
+  <Card title="Channel You Want To Take Report From" icon="square-1">
+    <Frame>![Kebab Menu](/images/slack-channel-details.png)</Frame>
+  </Card>
+  <Card title="Integrations" icon="square-2">
+    <Frame>![Report Modal](/images/slack-add-bot.png)</Frame>
+  </Card>
+  <Card title="Add ChainPatrol" icon="square-3">
+    <Frame>![Report Modal](/images/slack-select-bot.png)</Frame>
+  </Card>
+</CardGroup>
+
+### Link Organization
+
+<Warning>
+  This step needs to be done with help from ChainPatrol staff in order for the
+  Slack Bot to work properly.
+</Warning>
+
+**Please send ChainPatrol staff your workspace's Slack Team ID so that we can finish the automated pipeline.**
+
+- Follow [Slack's documentation](https://slack.com/intl/en-gb/help/articles/221769328-Locate-your-Slack-URL-or-ID#free,-pro-and-business+-subscriptions-2) to locate your Team ID.
+
+<Tip>
+  Slack refers to the Team ID as "workspace or org ID".
+
+`https://app.slack.com/client/TXXXXXXX/CXXXXXXX`
+
+In the above URL, the Team ID is the slug that begins with `T`.
+
+</Tip>
+
+## Usage
+
+Once the bot is added to your workspace and you have **sent ChainPatrol your Team ID**, you can use the following actions:
+
+### Slash Commands
+
+- `/chainpatrol <url>` - Submit a scam report for the given URL
+
+### Shortcut Actions
+
+For a given message, click on the kebab menu and then select the `Create Report` option.
+
+<CardGroup cols={2}>
+  <Card title="Kebab Menu" icon="square-1">
+    <Frame>![Kebab Menu](/images/slack-kebab.png)</Frame>
+  </Card>
+  <Card title="Report Modal" icon="square-2">
+    <Frame>![Report Modal](/images/report-modal.png)</Frame>
+  </Card>
+</CardGroup>
+
+## Threats Feed Configuration
+
+In addition to submitting reports, the ChainPatrol Slack Bot can also send automated notifications about threats and reports to your Slack channels. This creates a real-time threats feed that keeps your team informed about security activity.
+
+<Frame>![Blocklist Update Example](/images/blocklist-update.png)</Frame>
+
+### Setting Up Notification Settings
+
+<Steps>
+  <Step title="Create and Configure Notification Channel">
+    Create a dedicated channel in your Slack workspace for receiving ChainPatrol threat notifications. This channel will serve as your organization's security feed for real-time threat intelligence.
+
+    <Frame>![Add Bot to Channel](/images/add-to-channel.png)</Frame>
+
+    <Warning>
+      **Important**: You must add the ChainPatrol bot to this channel for notifications to work properly. The bot cannot automatically join channels for privacy and security reasons.
+    </Warning>
+
+  </Step>
+  <Step title="Provide Channel Information to ChainPatrol">
+    Contact ChainPatrol staff with your notification channel's Channel ID to complete the integration setup. The Channel ID is a unique identifier that begins with "C" and can be found in your channel's details.
+
+    <Tip>
+      To find your Channel ID, right-click on the channel name and select "View channel details" or check the URL when viewing the channel in your browser.
+    </Tip>
+
+  </Step>
+  <Step title="Access Integration Settings">
+    Navigate to your ChainPatrol dashboard and go to **Settings** > **Integrations** to configure your notification preferences.
+  </Step>
+  <Step title="Configure Notification Preferences">
+    Within the Integrations tab, locate the **Notification Settings** section to customize which types of security alerts your team receives.
+
+    <Frame>![Notification Settings](/images/notification-settings.png)</Frame>
+
+  </Step>
+  <Step title="Select Notification Types">
+    Choose which notifications you want to receive for your organization's reports and monitored assets. Each option serves different security monitoring needs as detailed below.
+  </Step>
+</Steps>
+
+### Notification Options
+
+<CardGroup cols={1}>
+  <Card title="New Reports for Blocked Assets" icon="shield-exclamation">
+    Receive notifications when new reports are created for assets that are
+    already on your blocklist. This helps you track ongoing threats and see when
+    community members are encountering known malicious content.
+  </Card>
+  <Card title="New Reports for Allowed Assets" icon="shield-check">
+    Receive notifications when new reports are created for assets that are
+    currently on your allowlist. This can help identify potential false
+    positives or assets that may need review if they're receiving multiple
+    reports.
+  </Card>
+  <Card title="Assets Added to Blocklist" icon="shield-slash">
+    Receive notifications when assets are confirmed as threats and added to the
+    blocklist. **This is the most critical notification type** - when you see
+    this alert, it means ChainPatrol's systems have confirmed a threat and are
+    actively working to process it for takedown and blocklist distribution.
+  </Card>
+</CardGroup>
+
+<Tip>
+  **Recommended Configuration**: We recommend enabling all three notification
+  types for comprehensive threat monitoring. However, if you want to focus on
+  the most critical alerts, option 3 (Assets Added to Blocklist) provides
+  notifications specifically for confirmed threats rather than just reports.
+</Tip>
+
+<Warning>
+  Notification settings only take effect if you have Discord or Slack reporting
+  feeds enabled through the bot integration.
+</Warning>
+
+## Privacy
+
+The bot does not collect any personal information. It only collects the URL and the Slack ID of the user that submitted the report (in case a moderator needs more information about why the URL is a scam). The bot does not store any sensitive information about the workspace it is added to.
diff --git a/integration/telegram.mdx b/integration/telegram.mdx
new file mode 100644
index 0000000..9885914
--- /dev/null
+++ b/integration/telegram.mdx
@@ -0,0 +1,102 @@
+---
+icon: telegram
+title: Telegram Bot
+sidebarTitle: Telegram
+description: A Telegram bot that can be used to submit scam reports to ChainPatrol
+---
+
+If you have a **Telegram group**, you can use the ChainPatrol Telegram Bot to let your group members submit scam reports to **ChainPatrol**. The bot will generate new reports that get sent to your admin dashboard for review.
+
+## Setup
+
+### Bot Installation
+
+<Steps>
+  <Step title="Add the Bot to Your Group Chat">
+    <Warning>
+      **Beware of impersonators!** The official ChainPatrol Telegram bot is `@ChainPatrol_Bot`. If you see any other bot claiming to be the ChainPatrol bot, please report it to us.
+    </Warning>
+    Start by adding the ChainPatrol Telegram Bot to your group chat. You can find the bot by searching for its username in Telegram.
+
+    <Frame>![Step 1 - Add Bot](/images/telegram-bot-add.png)</Frame>
+
+  </Step>
+
+  <Step title="Commands">
+    Once the bot is added to your group chat, use the `/help` command to see the available commands.
+
+    <Frame>![Step 2 - Setup Connect](/images/telegram-commands.png)</Frame>
+
+  </Step>
+</Steps>
+
+### Bot Configuration
+
+<Frame>![Confirmation Message](/images/telegram-setupstatus.png)</Frame>
+
+<Steps>
+  <Step title="Go to the Bot Settings">
+
+    Visit your [ChainPatrol Dashboard](https://app.chainpatrol.io/admin) and go to the **settings** page.
+
+    <Tip>
+      If you don't have a ChainPatrol account and want to protect your community, reach out to us directly!
+    </Tip>
+    <Frame>![Step 1 - Add Bot](/images/telegram-bot-settings.png)</Frame>
+
+  </Step>
+  <Step title="Go to Integrations">
+    Go to the **Integrations** on the left sidebar.
+    <Frame>![Step 2 - Integrations](/images/telegram-bot-integrations.png)</Frame>
+
+  </Step>
+  <Step title="Add the group details">
+    Click on "Add New Telegram Group" and configure the group details.
+
+    <Frame>![Step 2 - Add details](/images/telegram-bot-integration-details.png)</Frame>
+
+  </Step>
+</Steps>
+
+## Usage
+
+<Tip>
+
+Use the `/setupconnect` command to confirm the connection between your group and ChainPatrol.
+
+</Tip>
+
+Once the bot is added to your group and the connection process is complete, you can use the following commands:
+
+### Commands
+
+- `/report <url> <description>` - Submit a scam report for the given URL with a brief description of why it's suspicious
+- `/check <url>` - Check if a URL is on the block list
+- `/setupstatus` - Find out if this chat group is associated with an organization
+- `/setupconnect` - Generates the URL to link Telegram group to organization
+- `/help` - Display a list of available commands and their descriptions
+
+## Features
+
+### Auto-Link Monitoring
+
+The ChainPatrol Telegram Bot automatically monitors all links shared in your group chat. This feature provides an additional layer of protection for your community:
+
+- **Real-time Scanning**: Every link posted in the group is instantly checked against ChainPatrol's extensive database of known scams and malicious URLs.
+- **Automatic Alerts**: If a potentially harmful link is detected, the bot immediately notifies the group, warning members about the potential risk.
+- **Proactive Protection**: This feature helps prevent scams before they can affect your community members, even if no moderators are actively monitoring the group.
+
+<Frame>
+  ![Auto-Link Monitoring](/images/telegram-auto-link-monitoring.png)
+</Frame>
+
+## Privacy
+
+The bot does not collect any personal information. It only collects the URL and the Telegram ID of the user that submitted the report (in case a moderator needs more information about why the URL is a scam). The bot does not store any sensitive information about the group it is added to.
+
+<Tip>
+
+The ChainPatrol Telegram bot is like any group user. You can adjust permissions
+according to your group's needs.
+
+</Tip>
diff --git a/integration/vercel.mdx b/integration/vercel.mdx
index 76d6188..b3e6d0a 100644
--- a/integration/vercel.mdx
+++ b/integration/vercel.mdx
@@ -1,6 +1,6 @@
 ---
 icon: triangle
-title: Vercel Integration
+title: Vercel
 description: Connect your Vercel team to ChainPatrol to protect your deployments from impersonation
 ---
 
diff --git a/mint.json b/mint.json
index f6b88c6..9707c5d 100644
--- a/mint.json
+++ b/mint.json
@@ -58,6 +58,10 @@
     }
   ],
   "tabs": [
+    {
+      "name": "Integrations",
+      "url": "integration"
+    },
     {
       "name": "API Reference",
       "url": "external-api"
@@ -74,40 +78,83 @@
   "navigation": [
     {
       "group": "Getting Started",
-      "pages": ["introduction"]
+      "pages": [
+        {
+          "group": "What do we do?",
+          "pages": [
+            "getting-started/what-we-do/introduction",
+            "getting-started/what-we-do/brand-impersonation",
+            "getting-started/what-we-do/general-phishing"
+          ]
+        },
+        {
+          "group": "How it works",
+          "pages": [
+            "getting-started/how-it-works/how-we-use-ai",
+            "getting-started/how-it-works/detection-sources",
+            "getting-started/how-it-works/asset-scans",
+            "getting-started/how-it-works/review",
+            "getting-started/how-it-works/blocklist",
+            "getting-started/how-it-works/takedown",
+            "getting-started/how-it-works/watchlist"
+          ]
+        },
+        {
+          "group": "How do I get started?",
+          "pages": [
+            "protect-your-brand/onboarding-requirements",
+            "protect-your-brand/who-should-be-involved",
+            "protect-your-brand/services-setup",
+            "protect-your-brand/ongoing-communication"
+          ]
+        }
+      ]
     },
-
     {
-      "group": "General",
+      "group": "Concepts",
       "pages": [
-        "general/how-it-works",
-        "general/api-key",
-        "general/concepts",
-        "general/false-positives"
+        "concepts/organizations",
+        "concepts/brands",
+        "concepts/reports",
+        "concepts/reviews",
+        "concepts/detections",
+        "concepts/asset-scans",
+        "concepts/blocklist",
+        "concepts/allowlist",
+        "concepts/watchlist",
+        "concepts/takedowns",
+        "concepts/legal-docs",
+        "concepts/metrics",
+        "concepts/security-portal"
       ]
     },
     {
-      "group": "Integration",
+      "group": "Integrations",
       "pages": [
-        "integration/guide",
-        "integration/check-vs-list",
-        "integration/proxy",
-        "integration/webhooks",
-        "integration/zapier",
+        "integration/discord",
+        "integration/telegram",
+        "integration/slack",
         "integration/vercel",
         "integration/intercom",
         "integration/github",
-        "security-integration/canary-tokens",
-        "security-integration/submit-assets-for-scanning"
+        "integration/canary-tokens",
+        "integration/webhooks",
+        "integration/zapier"
       ]
     },
     {
-      "group": "Bots",
-      "pages": ["bots/discord-bot", "bots/slack-bot", "bots/telegram-bot"]
-    },
-    {
-      "group": "Extensions",
-      "pages": ["extensions/chrome-extension"]
+      "group": "Guides",
+      "pages": [
+        "guides/api-keys",
+        "guides/enabling-disabling-services",
+        "guides/gathering-allowlist",
+        "guides/setting-up-brands",
+        "guides/false-positives",
+        "guides/public-reports",
+        "guides/sso",
+        "guides/unflagging-your-assets",
+        "guides/communicating-with-chainpatrol"
+      ]
     },
     {
       "group": "External API",
@@ -255,7 +302,23 @@
     },
     {
       "source": "/general/discord-bot",
-      "destination": "/bots/discord-bot"
+      "destination": "/integration/discord"
+    },
+    {
+      "source": "/bots/discord-bot",
+      "destination": "/integration/discord"
+    },
+    {
+      "source": "/bots/telegram-bot",
+      "destination": "/integration/telegram"
+    },
+    {
+      "source": "/bots/slack-bot",
+      "destination": "/integration/slack"
+    },
+    {
+      "source": "/security-integration/canary-tokens",
+      "destination": "/integration/canary-tokens"
     },
     {
       "source": "/api",
@@ -267,15 +330,15 @@
     },
     {
       "source": "/bots/slack",
-      "destination": "/bots/slack-bot"
+      "destination": "/integration/slack"
     },
     {
       "source": "/bots/discord",
-      "destination": "/bots/discord-bot"
+      "destination": "/integration/discord"
     },
     {
       "source": "/bots/telegram",
-      "destination": "/bots/telegram-bot"
+      "destination": "/integration/telegram"
     }
   ],
   "backgroundImage": "/background.png",
diff --git a/protect-your-brand/onboarding-requirements.mdx b/protect-your-brand/onboarding-requirements.mdx
new file mode 100644
index 0000000..c86d17a
--- /dev/null
+++ b/protect-your-brand/onboarding-requirements.mdx
@@ -0,0 +1,410 @@
+---
+title: "Onboarding Requirements"
+description: "Information ChainPatrol needs to protect your organization from threats"
+---
+
+This guide explains the information ChainPatrol needs during onboarding and how to keep your organization's data up to date for effective threat protection.
+
+## Overview
+
+ChainPatrol protects your organization by monitoring for threats impersonating your brands, assets, and employees. To do this effectively, we need accurate and comprehensive information about:
+
+<CardGroup cols={3}>
+  <Card title="Assets" icon="link">
+    All digital properties you own or manage
+  </Card>
+  
+  <Card title="Brand Identity" icon="palette">
+    Logos, trademarks, and brand terms
+  </Card>
+  
+  <Card title="Legal Authorization" icon="scale-balanced">
+    Documents that allow us to take action on your behalf
+  </Card>
+</CardGroup>
+
+<Info>
+Keeping this information current ensures we can quickly identify and respond to threats while avoiding false positives.
+</Info>
+
+## What Information We Collect
+
+### Assets
+
+We need to know about all digital properties associated with your organization:
+
+<Tabs>
+  <Tab title="Domains" icon="globe">
+    - Websites and web applications
+    - Subdomains and development environments
+    - Landing pages and marketing sites
+    - Documentation and support portals
+  </Tab>
+  
+  <Tab title="Social Media" icon="share-nodes">
+    - Twitter/X handles
+    - Discord servers
+    - Telegram channels and groups
+    - LinkedIn company pages
+    - YouTube channels
+    - Other platform accounts
+  </Tab>
+  
+  <Tab title="Email & Communication" icon="envelope">
+    - Official company email addresses
+    - Employee email addresses
+    - Support and contact emails
+    - Newsletter addresses
+  </Tab>
+  
+  <Tab title="Blockchain" icon="link">
+    - Wallet addresses
+    - Smart contracts
+    - ENS names
+    - On-chain identities
+    - Token contracts
+  </Tab>
+  
+  <Tab title="Applications" icon="mobile">
+    - iOS applications
+    - Android applications
+    - Chrome extensions
+    - Firefox add-ons
+    - Safari extensions
+  </Tab>
+  
+  <Tab title="Other Properties" icon="folder">
+    - GitHub repositories
+    - Documentation sites
+    - Community forums
+    - Developer portals
+    - API endpoints
+  </Tab>
+</Tabs>
+
+<Warning>
+**Important:** When something is added to your organization, we **automatically allowlist it** so it doesn't get accidentally blocked or taken down by our systems.
+</Warning>
+
+### Brand Images and Visual Identity
+
+We collect visual assets to help identify brand impersonation attempts:
+
+<AccordionGroup>
+  <Accordion title="Logos" icon="image">
+    - Primary logo (all formats)
+    - Secondary logo variations
+    - Wordmarks and text-only versions
+    - Monochrome versions
+    - Icon-only versions
+  </Accordion>
+  
+  <Accordion title="Brand Colors" icon="palette">
+    - Primary color palette
+    - Secondary colors
+    - Hex codes and RGB values
+    - Color usage guidelines
+  </Accordion>
+  
+  <Accordion title="Design Assets" icon="paintbrush">
+    - Icons and symbols
+    - Patterns and textures
+    - Typography and fonts
+    - Other brand elements
+  </Accordion>
+</AccordionGroup>
+
+### Brand Terms and Trademarks
+
+We monitor for unauthorized use of your:
+
+<CardGroup cols={2}>
+  <Card title="Registered Trademarks" icon="trademark">
+    All marks registered with trademark offices
+  </Card>
+  
+  <Card title="Product Names" icon="box">
+    Official names of your products and services
+  </Card>
+  
+  <Card title="Taglines & Slogans" icon="quote-left">
+    Marketing phrases associated with your brand
+  </Card>
+  
+  <Card title="Common Misspellings" icon="spell-check">
+    Variations that scammers might use
+  </Card>
+</CardGroup>
+
+### Legal Documents
+
+Before we can perform takedowns on your behalf, we need:
+
+<Steps>
+  <Step title="Power of Attorney (POA)">
+    Authorizes ChainPatrol to perform takedowns in a narrow, specific capacity
+  </Step>
+  
+  <Step title="Letter of Authorization (LOA)">
+    Required specifically for Twitter/X takedowns
+  </Step>
+  
+  <Step title="Supporting Documentation">
+    Trademark certificates and business registration documents
+  </Step>
+</Steps>
+
+<Warning>
+These documents are **required before we can enable takedown services** for your organization.
+</Warning>
+
+## Managing Your Organization's Assets
+
+### Organization Assets Settings Page
+
+You can add, remove, or modify assets directly from your organization's settings:
+
+<Steps>
+  <Step title="Navigate to Settings">
+    Go to **Settings** > **Organization Assets**
+  </Step>
+  
+  <Step title="Add Assets">
+    Click **Add Asset** to include new properties
+  </Step>
+  
+  <Step title="Remove Assets">
+    Select assets and click **Remove** to delete outdated entries
+  </Step>
+  
+  <Step title="Search and Filter">
+    Use the search and filter tools to find specific assets
+  </Step>
+  
+  <Step title="Organize">
+    Group assets to help organize by priority or type
+  </Step>
+</Steps>
+
+### API Management
+
+For organizations with many assets or frequent updates, you can manage assets programmatically using our API:
+
+<CardGroup cols={3}>
+  <Card title="API Documentation" icon="book" href="/external-api/overview">
+    Complete endpoint documentation
+  </Card>
+  
+  <Card title="Generate API Keys" icon="key">
+    Create keys in Settings > API Keys
+  </Card>
+  
+  <Card title="Batch Operations" icon="layer-group">
+    Add or remove multiple assets in a single request
+  </Card>
+</CardGroup>
+
+<Tip>
+See our [API Integration Guide](/integration/guide) for detailed instructions on programmatic asset management.
+</Tip>
+
+## The Onboarding Process
+
+### Customer Information Sheet (CIS)
+
+During onboarding, you'll receive a **Customer Information Sheet** to fill out. This comprehensive form captures all the information listed above.
+
+<Warning>
+**Best Practice:** Don't fill out the CIS alone. Share it with teams across your organization.
+</Warning>
+
+#### Teams to Involve
+
+<AccordionGroup>
+  <Accordion title="Marketing" icon="bullhorn">
+    - Brand campaigns and initiatives
+    - Social media accounts
+    - Creative assets and materials
+    - Marketing domains and landing pages
+  </Accordion>
+  
+  <Accordion title="Engineering" icon="code">
+    - Infrastructure domains
+    - GitHub repositories
+    - Developer tools and APIs
+    - Staging and testing environments
+  </Accordion>
+  
+  <Accordion title="Product" icon="box">
+    - Product names and features
+    - Beta programs
+    - Feature launches
+    - Product documentation
+  </Accordion>
+  
+  <Accordion title="Legal" icon="scale-balanced">
+    - Trademark registrations
+    - Official documentation
+    - Power of Attorney
+    - Business registration
+  </Accordion>
+  
+  <Accordion title="Community" icon="users">
+    - Discord servers
+    - Telegram groups
+    - Community forums
+    - Ambassador programs
+  </Accordion>
+</AccordionGroup>
+
+<Note>
+Sometimes teams "squat" domains or social media handles for future use that leadership may not know about. A comprehensive internal review prevents these assets from being misidentified as threats.
+</Note>
+
+### Ongoing Allowlist Updates
+
+We don't just collect information once. ChainPatrol conducts **frequent allowlist gathering throughout the year** to:
+
+<CardGroup cols={2}>
+  <Card title="Capture Growth" icon="arrow-up">
+    New assets as your organization grows
+  </Card>
+  
+  <Card title="Remove Deprecated" icon="trash">
+    Outdated or retired properties
+  </Card>
+  
+  <Card title="Update Materials" icon="arrows-rotate">
+    Brand materials after refreshes
+  </Card>
+  
+  <Card title="Add Team Members" icon="user-plus">
+    New employees and team members
+  </Card>
+</CardGroup>
+
+<Info>
+You'll be notified when it's time for an allowlist review, typically quarterly or after major organizational changes.
+</Info>
+
+## Document Security and Privacy
+
+Your legal documents and sensitive information are handled with strict security measures:
+
+<CardGroup cols={2}>
+  <Card title="Private Cloud Storage" icon="cloud-lock">
+    All documents stored in encrypted, access-controlled cloud storage
+  </Card>
+  
+  <Card title="Limited Access" icon="user-lock">
+    Only authorized takedown staff and support can retrieve documents
+  </Card>
+  
+  <Card title="Audit Trails" icon="list-check">
+    All document access is logged and monitored
+  </Card>
+  
+  <Card title="Compliance" icon="shield-check">
+    Following industry-standard security practices
+  </Card>
+</CardGroup>
+
+## Frequently Asked Questions
+
+<AccordionGroup>
+  <Accordion title="What happens when someone leaves your company?" icon="user-minus">
+    You should remove their email address and any personal accounts from your organization's asset list. This can be done through the Settings page or API.
+    
+    <Tip>
+    We recommend integrating asset management with your employee offboarding process.
+    </Tip>
+  </Accordion>
+  
+  <Accordion title="What happens when you rebrand?" icon="paintbrush">
+    Contact us immediately when planning a rebrand. We'll work with you to:
+    
+    1. Add new brand assets to your allowlist
+    2. Update visual identity materials
+    3. Keep old brand assets protected during the transition period
+    4. Eventually remove outdated assets after the transition is complete
+    
+    <Info>
+    Rebrand transitions typically require 30-90 days where both old and new assets are protected.
+    </Info>
+  </Accordion>
+  
+  <Accordion title="What happens when you get acquired or acquire a new brand?" icon="building">
+    **For acquisitions you make:**
+    - Add the acquired brand as a sub-brand in your organization
+    - Include all their assets in your allowlist
+    - Keep existing POA/LOA documents for the acquired entity
+    
+    **For being acquired:**
+    - Work with your new parent company to transfer ChainPatrol services
+    - Legal documents may need to be updated to reflect the new ownership structure
+    - Contact [support@chainpatrol.io](mailto:support@chainpatrol.io) to coordinate the transition
+  </Accordion>
+  
+  <Accordion title="What happens if one of your assets gets compromised?" icon="triangle-exclamation">
+    If an asset you own is compromised (hacked, stolen credentials, etc.):
+    
+    <Steps>
+      <Step title="Immediately Notify ChainPatrol">
+        Email [support@chainpatrol.io](mailto:support@chainpatrol.io) or use your dedicated Slack channel
+      </Step>
+      
+      <Step title="Remove from Allowlist">
+        Remove the compromised asset so we can take action against it
+      </Step>
+      
+      <Step title="Report the Compromise">
+        Report through our platform so we can track and monitor the threat
+      </Step>
+      
+      <Step title="Re-add After Recovery">
+        Re-add the asset once you've regained control and secured it
+      </Step>
+    </Steps>
+    
+    <Check>
+    We can respond quickly to compromised assets once notified, often taking them down within hours.
+    </Check>
+  </Accordion>
+  
+  <Accordion title="Can I manage multiple brands or subsidiaries?" icon="sitemap">
+    Yes! Organizations can have multiple brands, each with their own:
+    
+    - Asset lists
+    - Brand identity materials
+    - Protected terms
+    
+    This is common for holding companies, investment firms, or organizations with multiple product lines.
+  </Accordion>
+  
+  <Accordion title="How often should I review my asset list?" icon="calendar-check">
+    We recommend reviewing your assets:
+    
+    - **Quarterly**: Regular check-ins to catch gradual changes
+    - **After launches**: New products, campaigns, or initiatives
+    - **After reorganizations**: Mergers, acquisitions, or restructuring
+    - **When prompted**: We'll notify you when it's time for a scheduled review
+  </Accordion>
+  
+  <Accordion title="If I'm unsure whether something should be included?" icon="circle-question">
+    **When in doubt, include it.** It's better to have too many assets in your allowlist than to miss something.
+    
+    <Tip>
+    Our team can help you refine your list during onboarding and ongoing reviews.
+    </Tip>
+  </Accordion>
+</AccordionGroup>
+
+---
+
+<Card
+  title="Ready to Get Started?"
+  icon="rocket"
+  href="https://cal.com/chainpatrol"
+>
+  Schedule an onboarding call to begin protecting your organization
+</Card>
diff --git a/protect-your-brand/ongoing-communication.mdx b/protect-your-brand/ongoing-communication.mdx
new file mode 100644
index 0000000..92e4645
--- /dev/null
+++ b/protect-your-brand/ongoing-communication.mdx
@@ -0,0 +1,400 @@
+---
+title: "Ongoing Communication"
+description: "How to stay connected with ChainPatrol for effective brand protection"
+---
+
+Effective brand protection requires clear, ongoing communication between your organization and ChainPatrol. This guide outlines the channels, processes, and best practices for staying connected.
+
+## Communication Channels
+
+We use multiple channels to stay in touch with our customers:
+
+<CardGroup cols={3}>
+  <Card title="Telegram Group" icon="telegram">
+    Direct group messaging for quick updates and discussions
+  </Card>
+  
+  <Card title="Slack Connect" icon="slack">
+    Dedicated channels for enterprise customers
+  </Card>
+  
+  <Card title="Email" icon="envelope">
+    Formal communications via support@chainpatrol.io and dispute@chainpatrol.io
+  </Card>
+</CardGroup>
+
+<Info>
+Each channel serves different purposes. Use Telegram/Slack for quick questions and real-time updates, and email for formal requests or documentation.
+</Info>
+
+## Reporting Threats
+
+### Can customers report threats directly to us?
+
+Yes! Customers can report threats through multiple channels:
+
+<Tabs>
+  <Tab title="Telegram" icon="telegram">
+    **Direct Group Reporting**
+    
+    Share threats directly in your dedicated Telegram group for immediate visibility.
+    
+    **Best for:**
+    - Quick threat reports
+    - Screenshots and URLs
+    - Real-time discussions
+    - Urgent threats requiring immediate attention
+  </Tab>
+  
+  <Tab title="Slack" icon="slack">
+    **Slack Connect Channel**
+    
+    Post threats in your Slack Connect channel for team collaboration.
+    
+    **Best for:**
+    - Enterprise workflows
+    - Team coordination
+    - Documented threat history
+    - Integration with internal tools
+  </Tab>
+  
+  <Tab title="Bot Integrations" icon="robot">
+    **Automated Bot Reporting**
+    
+    Use our automated bot integrations to streamline reporting without leaving your workflow.
+    
+    **Benefits:**
+    - Automated threat submission
+    - Consistent formatting
+    - Faster processing
+    - Reduced manual work
+    
+    <Tip>
+    Ask your point of contact for setup instructions to enable bot integrations.
+    </Tip>
+  </Tab>
+</Tabs>
+
+## Major Events
+
+If your organization has upcoming launches, announcements, or major events, communication is critical:
+
+<Steps>
+  <Step title="Share Event Details in Advance">
+    Notify us as soon as you have event details to share
+  </Step>
+  
+  <Step title="We Prepare Resources">
+    This allows us to dedicate extra monitoring resources and prepare response plans
+  </Step>
+  
+  <Step title="Enhanced Protection">
+    We can detect and take action on threats faster during your critical moments
+  </Step>
+</Steps>
+
+<Warning>
+**Why this matters:** Phishing attacks are often timed to coincide with your activities. Product launches, token sales, airdrops, and major announcements are prime targets for scammers.
+</Warning>
+
+### What to Share
+
+<AccordionGroup>
+  <Accordion title="Event Type & Date" icon="calendar">
+    - Product launches
+    - Token sales or airdrops
+    - Partnership announcements
+    - Rebrands or major updates
+    - Conference appearances
+  </Accordion>
+  
+  <Accordion title="Expected Impact" icon="chart-line">
+    - Anticipated traffic volume
+    - Social media campaign details
+    - Press coverage expectations
+    - Community engagement plans
+  </Accordion>
+  
+  <Accordion title="New Assets" icon="link">
+    - Landing pages or microsites
+    - New social media accounts
+    - Campaign-specific domains
+    - Promotional materials
+  </Accordion>
+  
+  <Accordion title="Timing & Duration" icon="clock">
+    - Event start and end dates
+    - Peak activity windows
+    - Geographic focus areas
+  </Accordion>
+</AccordionGroup>
+
+<Check>
+**Better prepared, better protected:** The earlier we know, the faster we can detect and take action on threats.
+</Check>
+
+## Organization Assets
+
+### Keeping Your Asset List Current
+
+We need an up-to-date list of your organization's assets to protect them effectively.
+
+<CardGroup cols={3}>
+  <Card title="Regular Updates" icon="arrows-rotate">
+    Review and update your asset list periodically (at least quarterly)
+  </Card>
+  
+  <Card title="New Assets" icon="plus">
+    Notify us immediately when you launch new domains, social accounts, or other assets
+  </Card>
+  
+  <Card title="How to Update" icon="gear">
+    Contact your point of contact or use the ChainPatrol dashboard
+  </Card>
+</CardGroup>
+
+<Info>
+The more complete your asset list, the better we can protect your brand and avoid false positives.
+</Info>
+
+### When to Update Your Assets
+
+<Tabs>
+  <Tab title="Immediate Updates" icon="bolt">
+    **Notify us immediately for:**
+    - New domain registrations
+    - New social media accounts
+    - New mobile applications
+    - New blockchain addresses
+    - New team member accounts
+    - Acquired brands or companies
+  </Tab>
+  
+  <Tab title="Regular Reviews" icon="calendar-check">
+    **Schedule quarterly reviews for:**
+    - Deprecated assets to remove
+    - Temporary campaign assets
+    - Employee turnover updates
+    - Rebranded assets
+    - Changed contact information
+  </Tab>
+  
+  <Tab title="Event-Driven Updates" icon="calendar-days">
+    **Update before major events:**
+    - Product launches
+    - Marketing campaigns
+    - Partnership announcements
+    - Organizational changes
+  </Tab>
+</Tabs>
+
+## Threat Snapshots
+
+### What are threat snapshots?
+
+Threat snapshots are point-in-time records of detected threats targeting your organization.
+
+<CardGroup cols={2}>
+  <Card title="Complete View" icon="camera">
+    A comprehensive record of the threat at the moment of detection
+  </Card>
+  
+  <Card title="Visual Evidence" icon="image">
+    Screenshots and archived content
+  </Card>
+  
+  <Card title="Technical Details" icon="server">
+    Domains, IPs, and hosting information
+  </Card>
+  
+  <Card title="Action Timeline" icon="timeline">
+    When detected and when action was taken
+  </Card>
+</CardGroup>
+
+### What data do they contain?
+
+Each snapshot includes comprehensive information:
+
+<AccordionGroup>
+  <Accordion title="Visual Evidence" icon="image">
+    - Screenshots of the malicious content
+    - Archived copies of web pages
+    - Social media post captures
+    - Visual similarity analysis
+  </Accordion>
+  
+  <Accordion title="Technical Metadata" icon="code">
+    - Domain information (WHOIS, DNS records)
+    - Hosting details (provider, IP addresses)
+    - Infrastructure data (CDN, nameservers)
+    - SSL certificate information
+  </Accordion>
+  
+  <Accordion title="Detection Details" icon="magnifying-glass">
+    - When the threat was first detected
+    - Which detection rules triggered
+    - Confidence scores and risk levels
+    - AI analysis results
+  </Accordion>
+  
+  <Accordion title="Action History" icon="list-check">
+    - Takedown requests submitted
+    - Provider responses received
+    - Status updates and timeline
+    - Final resolution outcome
+  </Accordion>
+</AccordionGroup>
+
+<Tip>
+Threat snapshots are available in your ChainPatrol dashboard and can be exported for internal reporting or compliance purposes.
+</Tip>
+
+## Customer Feedback Meetings
+
+We schedule regular feedback sessions to ensure we're meeting your needs.
+
+### What We Discuss
+
+<Tabs>
+  <Tab title="Threat Activity" icon="chart-line">
+    **Review recent threats:**
+    - Volume and trends
+    - Attack patterns
+    - High-severity incidents
+    - Response effectiveness
+  </Tab>
+  
+  <Tab title="Detection Accuracy" icon="bullseye">
+    **Evaluate performance:**
+    - False positive rates
+    - Missed threats
+    - Detection speed
+    - Coverage gaps
+  </Tab>
+  
+  <Tab title="Service Feedback" icon="comments">
+    **Share your experience:**
+    - What's working well
+    - Pain points or challenges
+    - Communication effectiveness
+    - Documentation needs
+  </Tab>
+  
+  <Tab title="Feature Requests" icon="lightbulb">
+    **Discuss improvements:**
+    - New integrations
+    - Custom workflows
+    - Reporting enhancements
+    - Platform features
+  </Tab>
+</Tabs>
+
+<Info>
+Your ChainPatrol representative will coordinate scheduling for these meetings, typically held quarterly or as needed.
+</Info>
+
+## Your Points of Contact
+
+### Dedicated Support Team
+
+Meet your ChainPatrol team members and their areas of expertise:
+
+<AccordionGroup>
+  <Accordion title="Michael - Bot Engineer & Customer Support" icon="robot">
+    **Areas of expertise:**
+    - Bot integrations and technical support
+    - Day-to-day customer inquiries
+    - Automated reporting setup
+    - Integration troubleshooting
+    
+    **When to contact Michael:**
+    - Setting up bot integrations
+    - Technical support questions
+    - General customer inquiries
+    - Integration issues
+  </Accordion>
+  
+  <Accordion title="Dave - Customer Success Lead" icon="user-tie">
+    **Areas of expertise:**
+    - Strategic partnership and account management
+    - Service optimization and feedback
+    - Onboarding and training
+    - Long-term success planning
+    
+    **When to contact Dave:**
+    - Strategic discussions
+    - Service optimization
+    - Feedback and feature requests
+    - Account management questions
+  </Accordion>
+  
+  <Accordion title="Maksym - Founding Engineer" icon="code">
+    **Areas of expertise:**
+    - Technical concerns about application stability
+    - Canary tokens integration support
+    - Advanced technical implementations
+    - Platform architecture questions
+    
+    **When to contact Maksym:**
+    - Application stability issues
+    - Canary token integrations
+    - Complex technical implementations
+    - Platform architecture discussions
+  </Accordion>
+</AccordionGroup>
+
+<Tip>
+Reach out to your designated contact for any questions or concerns. If you're unsure who to contact, start with your primary point of contact and they'll route you appropriately.
+</Tip>
+
+## Best Practices for Communication
+
+<CardGroup cols={2}>
+  <Card title="Be Proactive" icon="comments">
+    Don't wait for issues to escalate—reach out early and often
+  </Card>
+  
+  <Card title="Provide Context" icon="file-lines">
+    Include relevant details, screenshots, and URLs when reporting threats
+  </Card>
+  
+  <Card title="Use Appropriate Channels" icon="signs-post">
+    Match urgency to channel (Telegram for urgent, email for formal)
+  </Card>
+  
+  <Card title="Keep Assets Updated" icon="arrows-rotate">
+    Regularly review and update your organization's asset list
+  </Card>
+  
+  <Card title="Share Event Plans" icon="calendar">
+    Give advance notice of launches and major announcements
+  </Card>
+  
+  <Card title="Attend Feedback Meetings" icon="handshake">
+    Participate in regular check-ins to optimize service
+  </Card>
+</CardGroup>
+
+---
+
+## Quick Reference
+
+| Need | Channel | Contact |
+|------|---------|---------|
+| **Urgent threat report** | Telegram/Slack | Your dedicated group/channel |
+| **Bot integration setup** | Email/Telegram | Michael |
+| **Strategic discussion** | Email/Slack | Dave |
+| **Technical issue** | Email/Telegram | Maksym |
+| **Formal request** | Email | support@chainpatrol.io |
+| **Dispute submission** | Email | dispute@chainpatrol.io |
+
+---
+
+<Card
+  title="Need to Get in Touch?"
+  icon="envelope"
+  href="mailto:support@chainpatrol.io"
+>
+  Contact us at support@chainpatrol.io or reach out through your dedicated communication channel
+</Card>
diff --git a/protect-your-brand/services-setup.mdx b/protect-your-brand/services-setup.mdx
new file mode 100644
index 0000000..67126e9
--- /dev/null
+++ b/protect-your-brand/services-setup.mdx
@@ -0,0 +1,478 @@
+---
+title: "Services Setup"
+description: "Configure ChainPatrol security services for your organization"
+---
+
+ChainPatrol offers multiple security services that can be configured based on your organization's needs. Each service can be enabled independently and requires specific permissions and approvals before activation.
+
+<Info>
+**Where to find Services:** Navigate to your organization settings → Services
+</Info>
+
+## Available Services
+
+<CardGroup cols={3}>
+  <Card title="Detection" icon="magnifying-glass" color="#3b82f6">
+    Automated scanning for threats
+  </Card>
+  
+  <Card title="Monitoring & Reporting" icon="eye" color="#8b5cf6">
+    Continuous threat intelligence
+  </Card>
+  
+  <Card title="Reviewing" icon="clipboard-check" color="#10b981">
+    Expert threat validation
+  </Card>
+  
+  <Card title="Admin Approval" icon="user-shield" color="#f59e0b">
+    Internal approval workflow
+  </Card>
+  
+  <Card title="Wallet Blocking" icon="wallet" color="#ef4444">
+    Real-time wallet protection
+  </Card>
+  
+  <Card title="Takedowns" icon="power-off" color="#ec4899">
+    Professional threat removal
+  </Card>
+  
+  <Card title="Automated Takedowns" icon="bolt" color="#dc2626">
+    Instant takedown submission
+  </Card>
+</CardGroup>
+
+## Detection
+
+<Tabs>
+  <Tab title="What It Does" icon="info">
+    The Detection service automatically scans various sources across the internet to identify potentially malicious assets targeting your brand or organization. This includes monitoring domain registrations, social media platforms, and other channels where threats commonly appear.
+  </Tab>
+  
+  <Tab title="Who Needs It" icon="users">
+    **Ideal for:**
+    - Organizations that want proactive monitoring for brand impersonation
+    - Teams looking to identify threats before they reach end users
+    - Companies with significant online presence susceptible to phishing attacks
+  </Tab>
+  
+  <Tab title="When to Enable" icon="calendar">
+    **Prerequisites:**
+    - Complete your organization profile
+    - Define your tracked assets (domains, social media handles, brand identifiers)
+    - Ensure your team is ready to receive detection alerts
+  </Tab>
+  
+  <Tab title="Requirements" icon="list-check">
+    **Required Approvals:**
+    - Organization Owner approval (if requested by a member)
+    - ChainPatrol staff review for initial setup
+    
+    **Required Legal Docs:**
+    - None
+  </Tab>
+</Tabs>
+
+---
+
+## Monitoring & Reporting
+
+<Tabs>
+  <Tab title="What It Does" icon="info">
+    This service continuously monitors the web for new threats to your brand, including phishing sites, scams, and impersonation attempts. When potential threats are detected, they're automatically reported to ChainPatrol's review system for validation and action.
+  </Tab>
+  
+  <Tab title="Who Needs It" icon="users">
+    **Ideal for:**
+    - Organizations requiring comprehensive brand protection
+    - Security teams needing continuous threat intelligence
+    - Companies that want to stay ahead of emerging scams and phishing campaigns
+  </Tab>
+  
+  <Tab title="When to Enable" icon="calendar">
+    **Prerequisites:**
+    - Enable the Detection service first
+    - Have dedicated resources to handle threat notifications
+    - Establish your organization's threat response workflow
+  </Tab>
+  
+  <Tab title="Requirements" icon="list-check">
+    **Required Approvals:**
+    - Organization Owner approval (if requested by a member)
+    
+    **Required Legal Docs:**
+    - None
+  </Tab>
+</Tabs>
+
+---
+
+## Reviewing
+
+<Tabs>
+  <Tab title="What It Does" icon="info">
+    The Reviewing service ensures that ChainPatrol's security experts manually review all detected threats for your organization. This adds a layer of human validation to confirm threats are genuine and not false positives.
+  </Tab>
+  
+  <Tab title="Who Needs It" icon="users">
+    **Ideal for:**
+    - Organizations that prioritize accuracy over speed
+    - Companies concerned about false positives
+    - Teams new to threat detection who want expert validation
+  </Tab>
+  
+  <Tab title="When to Enable" icon="calendar">
+    **Prerequisites:**
+    - Can be enabled immediately, alongside Detection and Monitoring services
+    - Enable when you want ChainPatrol experts to validate all threats before action
+  </Tab>
+  
+  <Tab title="Requirements" icon="list-check">
+    **Required Approvals:**
+    - Organization Owner approval (if requested by a member)
+    
+    **Required Legal Docs:**
+    - None
+  </Tab>
+</Tabs>
+
+---
+
+## Obligatory Organization Admin Approval
+
+<Tabs>
+  <Tab title="What It Does" icon="info">
+    This service requires your organization's administrators to review and approve all threats validated by ChainPatrol staff before they're added to your organization's blocklist. You can configure which types of assets (social media, domains, wallets, etc.) require this approval.
+  </Tab>
+  
+  <Tab title="Who Needs It" icon="users">
+    **Ideal for:**
+    - Organizations with strict internal compliance requirements
+    - Companies that want final oversight on all blocked content
+    - Teams with industry-specific regulations requiring manual approval
+    - Organizations that prefer to have control over what gets blocked
+  </Tab>
+  
+  <Tab title="When to Enable" icon="calendar">
+    **Prerequisites:**
+    - Enable after Reviewing service
+    - Have designated administrators available to review proposals regularly
+    - Enable before Wallet Blocking if you want approval control
+  </Tab>
+  
+  <Tab title="Requirements" icon="list-check">
+    **Required Approvals:**
+    - None (can be configured directly by organization admins)
+    
+    **Required Legal Docs:**
+    - None
+  </Tab>
+  
+  <Tab title="Configuration" icon="gear">
+    **Configuration Options:**
+    - Enable/disable the approval requirement
+    - Select specific asset types that require approval:
+      - Domains
+      - Social media accounts
+      - Messaging apps
+      - Crypto addresses
+      - And more
+    
+    <Note>
+    If no specific types are selected, all asset types will require approval
+    </Note>
+  </Tab>
+</Tabs>
+
+---
+
+## Wallet Blocking
+
+<Tabs>
+  <Tab title="What It Does" icon="info">
+    Approved threats are added to ChainPatrol's global blocklist, which is consumed by major cryptocurrency wallets and platforms, including Coinbase, MetaMask, and others. This prevents users from interacting with malicious addresses, domains, or contracts in real-time.
+  </Tab>
+  
+  <Tab title="Who Needs It" icon="users">
+    **Ideal for:**
+    - Cryptocurrency projects and protocols
+    - DeFi platforms
+    - NFT projects
+    - Web3 organizations
+    - Any company whose users interact with blockchain wallets
+  </Tab>
+  
+  <Tab title="When to Enable" icon="calendar">
+    **Prerequisites:**
+    <Steps>
+      <Step title="Complete Organization Profile">
+        Ensure all organization details are accurate
+      </Step>
+      
+      <Step title="Configure Tracked Assets">
+        Set up all assets you want to protect
+      </Step>
+      
+      <Step title="Enable Core Services">
+        Detection, Monitoring, and Reviewing must be active
+      </Step>
+      
+      <Step title="Verify Configuration">
+        Confirm organization assets and tracked asset scans are correct
+      </Step>
+    </Steps>
+  </Tab>
+  
+  <Tab title="Requirements" icon="list-check">
+    **Required Approvals:**
+    - Organization Owner approval (required)
+    - Acknowledgment that organization assets and tracked assets are correctly configured
+    
+    **Required Legal Docs:**
+    - None
+    
+    <Warning>
+    **Important:** Enabling Wallet Blocking has immediate impact on end-users. Organizations must verify their asset configuration is accurate before enabling this service.
+    </Warning>
+  </Tab>
+</Tabs>
+
+---
+
+## Takedowns
+
+<Tabs>
+  <Tab title="What It Does" icon="info">
+    For approved threats, ChainPatrol submits professional takedown requests to hosting providers, domain registrars, and platform administrators on your behalf. Our team handles the entire takedown process, including follow-ups and documentation.
+  </Tab>
+  
+  <Tab title="Who Needs It" icon="users">
+    **Ideal for:**
+    - Organizations that want active threat removal, not just detection
+    - Companies lacking in-house expertise for filing takedown requests
+    - Teams that need to enforce intellectual property and trademark protection
+    - Brands experiencing high volumes of impersonation or phishing
+  </Tab>
+  
+  <Tab title="When to Enable" icon="calendar">
+    **Prerequisites:**
+    - Enable Detection, Monitoring, and Reviewing services
+    - Verify your organization has proper brand protection policies in place
+    - Be ready for ChainPatrol to represent your organization in takedown communications
+  </Tab>
+  
+  <Tab title="Requirements" icon="list-check">
+    **Required Approvals:**
+    - Organization Owner approval (if requested by a member)
+    - ChainPatrol legal review
+    
+    **Required Legal Docs:**
+    - Proof of trademark or brand ownership
+    - Organization contact information
+    - Authorized representative details
+  </Tab>
+</Tabs>
+
+---
+
+## Automated Takedowns
+
+<Tabs>
+  <Tab title="What It Does" icon="info">
+    Takedown requests are submitted automatically to hosting providers immediately after a threat is approved by ChainPatrol staff (and your organization, if Obligatory Organization Admin Approval is enabled). This provides the fastest possible response time for threat removal.
+  </Tab>
+  
+  <Tab title="Who Needs It" icon="users">
+    **Ideal for:**
+    - Organizations experiencing high volumes of threats requiring rapid response
+    - Companies with mature threat detection processes
+    - Teams that trust ChainPatrol's review process completely
+    - Brands in high-risk industries (cryptocurrency, finance, e-commerce)
+  </Tab>
+  
+  <Tab title="When to Enable" icon="calendar">
+    **Prerequisites:**
+    <Steps>
+      <Step title="Enable All Other Services">
+        All services must be enabled and functioning properly
+      </Step>
+      
+      <Step title="Upload Power of Attorney">
+        Valid POA document must be uploaded
+      </Step>
+      
+      <Step title="Configure Website URL">
+        Organization's main website URL must be set
+      </Step>
+      
+      <Step title="Validate Detection">
+        Have confidence in the accuracy of your threat detection
+      </Step>
+    </Steps>
+  </Tab>
+  
+  <Tab title="Requirements" icon="list-check">
+    **Required Approvals:**
+    - Organization Owner approval (required)
+    - ChainPatrol legal team approval
+    
+    **Required Legal Docs:**
+    - **Power of Attorney (POA) document** - Authorizes ChainPatrol to submit takedown requests on your behalf
+    - Main website URL for your organization
+    - Trademark registration documents
+    - Authorized signatory information
+    
+    <Warning>
+    **Important:** Automated Takedowns cannot be enabled without these prerequisites. The service will remain disabled until both the POA document and website URL are provided.
+    </Warning>
+  </Tab>
+</Tabs>
+
+---
+
+## Approval Process
+
+### Service Enable Request Flow
+
+<Steps>
+  <Step title="Request Submission">
+    **Organization Members and Staff:**
+    - Submit a request to enable the service
+    - Organization Owners receive an email notification
+    - Request appears as "Pending" in the Services page
+    - No changes take effect until approved
+  </Step>
+  
+  <Step title="Owner Approval">
+    **Organization Owners:**
+    - Can enable services immediately without approval
+    - Can approve pending requests from team members
+    - Receive email notifications for all service change requests
+  </Step>
+  
+  <Step title="ChainPatrol Review">
+    **For certain services:**
+    - Some services require ChainPatrol staff verification
+    - Legal team reviews documentation for Takedowns and Automated Takedowns
+    - Security team validates configuration for Wallet Blocking
+  </Step>
+</Steps>
+
+### Disabling Services
+
+<CardGroup cols={2}>
+  <Card title="Owner Actions" icon="user-shield">
+    Organization Owners can disable any service at any time
+  </Card>
+  
+  <Card title="Member Requests" icon="users">
+    Members with OrganizationServices:update permission can request to disable services
+  </Card>
+  
+  <Card title="Immediate Effect" icon="bolt">
+    Disabling services takes effect immediately for the requesting owner
+  </Card>
+  
+  <Card title="Data Preservation" icon="database">
+    Service data and history are preserved when disabled
+  </Card>
+</CardGroup>
+
+---
+
+## Legal Requirements
+
+### Required Documentation by Service
+
+| Service | Documents Required | When Needed |
+|---------|-------------------|-------------|
+| Detection | None | - |
+| Monitoring & Reporting | None | - |
+| Reviewing | None | - |
+| Obligatory Organization Admin Approval | None | - |
+| Wallet Blocking | None (but verification required) | - |
+| Takedowns | Trademark proof, Authorized representative details | Before enabling |
+| Automated Takedowns | Power of Attorney, Trademark registration, Main website URL | Before enabling |
+
+### Power of Attorney Requirements
+
+For Automated Takedowns, your Power of Attorney document must:
+
+<AccordionGroup>
+  <Accordion title="Authorization Scope" icon="scale-balanced">
+    Specifically authorize ChainPatrol to submit takedown requests on your organization's behalf
+  </Accordion>
+  
+  <Accordion title="Signature Requirements" icon="signature">
+    Be signed by an authorized representative of your organization
+  </Accordion>
+  
+  <Accordion title="Organization Details" icon="building">
+    Include your organization's legal name and contact information
+  </Accordion>
+  
+  <Accordion title="Validity Period" icon="calendar">
+    Be dated within the last 12 months (recommended)
+  </Accordion>
+  
+  <Accordion title="File Format" icon="file-pdf">
+    Be uploaded in PDF format to your organization settings
+  </Accordion>
+</AccordionGroup>
+
+<Tip>
+**How to upload:** Navigate to Organization Settings → Documents → Upload Power of Attorney
+</Tip>
+
+### Trademark Documentation
+
+For both Takedowns and Automated Takedowns:
+
+<CardGroup cols={2}>
+  <Card title="Registration Numbers" icon="hashtag">
+    Provide trademark registration numbers or pending applications
+  </Card>
+  
+  <Card title="Jurisdictions" icon="globe">
+    Include jurisdictions where trademarks are registered
+  </Card>
+  
+  <Card title="Ownership Proof" icon="certificate">
+    Demonstrate clear ownership of brand assets
+  </Card>
+  
+  <Card title="Commercial Use" icon="store">
+    Provide evidence of legitimate use in commerce
+  </Card>
+</CardGroup>
+
+---
+
+## Service Dependencies
+
+```mermaid
+flowchart TD
+    Detection[Detection] --> Monitoring[Monitoring & Reporting]
+    Monitoring --> Reviewing[Reviewing]
+    Reviewing --> AdminApproval[Admin Approval<br/>Optional]
+    Reviewing --> WalletBlocking[Wallet Blocking]
+    Reviewing --> Takedowns[Takedowns]
+    Takedowns --> AutoTakedowns[Automated Takedowns]
+    
+    style Detection fill:#3b82f6
+    style Monitoring fill:#8b5cf6
+    style Reviewing fill:#10b981
+    style AdminApproval fill:#f59e0b
+    style WalletBlocking fill:#ef4444
+    style Takedowns fill:#ec4899
+    style AutoTakedowns fill:#dc2626
+```
+
+---
+
+<Card
+  title="Configure Your Services"
+  icon="gear"
+  href="https://app.chainpatrol.io"
+>
+  Log in to your dashboard to enable and configure services for your organization
+</Card>
diff --git a/protect-your-brand/who-should-be-involved.mdx b/protect-your-brand/who-should-be-involved.mdx
new file mode 100644
index 0000000..8e588cf
--- /dev/null
+++ b/protect-your-brand/who-should-be-involved.mdx
@@ -0,0 +1,418 @@
+---
+title: "Who Should Be Involved in Brand Protection"
+description: "Key stakeholders and team members essential for effective brand protection"
+---
+
+Effective brand protection requires collaboration across your organization. This guide identifies the key stakeholders who should be involved and explains their unique contributions to your security program.
+
+## Key Stakeholders
+
+### Knowledge Owners
+
+These team members have the most profound understanding of your brand, its legitimate presence, and authorized activities.
+
+<AccordionGroup>
+  <Accordion title="Founders and C-Suite Executives" icon="user-tie">
+    **Why they're critical:** Founders and executives have the complete picture of your company's strategic direction, partnerships, and official communications.
+    
+    **What they contribute:**
+    - Know all official company accounts across platforms
+    - Understand authorized partnerships and affiliate relationships
+    - Can quickly identify unauthorized use of company branding
+    - Make final decisions on brand protection policies and budgets
+    - Approve official responses to brand impersonation incidents
+    
+    **When to involve them:**
+    <CardGroup cols={2}>
+      <Card title="Program Setup" icon="rocket">
+        Initial brand protection program setup
+      </Card>
+      
+      <Card title="High-Severity Incidents" icon="triangle-exclamation">
+        Incidents affecting company reputation
+      </Card>
+      
+      <Card title="Strategic Decisions" icon="chart-line">
+        Brand protection investments and policies
+      </Card>
+      
+      <Card title="Executive Impersonation" icon="user-shield">
+        CEO fraud or executive social media impersonation
+      </Card>
+    </CardGroup>
+  </Accordion>
+  
+  <Accordion title="Marketing Teams" icon="bullhorn">
+    **Why they're critical:** Marketing teams create and manage most of your brand's public-facing presence.
+    
+    **What they contribute:**
+    - Maintain comprehensive lists of all official social media accounts
+    - Know current and past marketing campaigns that scammers might impersonate
+    - Understand your brand's visual identity, messaging, and voice
+    - Track influencers, ambassadors, and partners authorized to represent your brand
+    - Identify subtle brand guideline violations that others might miss
+    
+    **When to involve them:**
+    <Steps>
+      <Step title="Brand Monitoring Setup">
+        Setting up brand monitoring configurations
+      </Step>
+      
+      <Step title="Threat Review">
+        Reviewing potential impersonation threats
+      </Step>
+      
+      <Step title="Content Legitimacy">
+        Determining if promotional content is legitimate
+      </Step>
+      
+      <Step title="Response Templates">
+        Creating response templates for brand abuse cases
+      </Step>
+      
+      <Step title="Training">
+        Training other teams on brand guidelines
+      </Step>
+    </Steps>
+  </Accordion>
+  
+  <Accordion title="Security Teams" icon="shield-halved">
+    **Why they're critical:** Security teams bring technical expertise and incident response capabilities.
+    
+    **What they contribute:**
+    - Understand phishing tactics and social engineering techniques
+    - Can assess technical sophistication of threats
+    - Know your organization's security tools and infrastructure
+    - Have established incident response procedures
+    - Connect brand protection to broader security strategy
+    
+    **When to involve them:**
+    - Initial system setup and security configuration
+    - Evaluating high-risk threats
+    - Incidents involving credential theft or data breaches
+    - Integration with existing security tools and workflows
+    - Security awareness training programs
+  </Accordion>
+  
+  <Accordion title="Development Teams" icon="code">
+    **Why they're critical:** Developers understand your technical infrastructure and can help identify technical impersonation.
+    
+    **What they contribute:**
+    - Know all legitimate domains, subdomains, and APIs
+    - Understand your application's technical fingerprint
+    - Can identify fake apps, cloned websites, and API abuse
+    - Implement technical integrations with brand protection tools
+    - Develop custom detection rules or automation
+    
+    **When to involve them:**
+    <CardGroup cols={2}>
+      <Card title="Asset Identification" icon="link">
+        Identifying all legitimate technical assets
+      </Card>
+      
+      <Card title="API Integration" icon="plug">
+        Setting up API integrations and webhooks
+      </Card>
+      
+      <Card title="Custom Rules" icon="code">
+        Creating custom detection rules for technical threats
+      </Card>
+      
+      <Card title="Technical Threats" icon="bug">
+        Reviewing threats targeting developer communities
+      </Card>
+    </CardGroup>
+  </Accordion>
+</AccordionGroup>
+
+## Threat Reporters
+
+These team members are your eyes and ears, often the first to spot brand abuse in the wild.
+
+<Tabs>
+  <Tab title="Community Members" icon="users">
+    **Why they're critical:** Your community often encounters scams before your internal teams do.
+    
+    **What they contribute:**
+    - First-hand experience with phishing attempts targeting your users
+    - Real-time visibility into social media impersonation
+    - Ground-level perspective on what threats actually affect users
+    - Authentic feedback on potential false positives
+    
+    **How to enable them:**
+    <Steps>
+      <Step title="Easy Reporting">
+        Provide easy reporting mechanisms (dedicated email, web form, Discord channel)
+      </Step>
+      
+      <Step title="Clear Guidelines">
+        Create clear guidelines for what to report
+      </Step>
+      
+      <Step title="Acknowledge Reports">
+        Acknowledge and thank community reporters
+      </Step>
+      
+      <Step title="Share Updates">
+        Share general updates about brand protection efforts (without sensitive details)
+      </Step>
+      
+      <Step title="Reward Program">
+        Consider a bug bounty or reward program for security reports
+      </Step>
+    </Steps>
+  </Tab>
+  
+  <Tab title="Brand Ambassadors" icon="star">
+    **Why they're critical:** Ambassadors have large followings and are frequent impersonation targets.
+    
+    **What they contribute:**
+    - Report impersonation of their own accounts that reference your brand
+    - Identify scams targeting your community through their channels
+    - Help educate their followers about legitimate brand communications
+    - Amplify official security warnings
+    
+    **How to enable them:**
+    <CardGroup cols={2}>
+      <Card title="Scam Pattern Training" icon="graduation-cap">
+        Brief them on common scam patterns targeting your community
+      </Card>
+      
+      <Card title="Direct Contact" icon="phone">
+        Give them a direct contact for urgent reports
+      </Card>
+      
+      <Card title="Official Statements" icon="file-lines">
+        Provide them with official statements they can share
+      </Card>
+      
+      <Card title="Monitor Impersonation" icon="eye">
+        Monitor for impersonation of their accounts related to your brand
+      </Card>
+    </CardGroup>
+  </Tab>
+  
+  <Tab title="SOC Analysts" icon="desktop">
+    **Why they're critical:** If you have a Security Operations Center (SOC), analysts monitor threats 24/7.
+    
+    **What they contribute:**
+    - Continuous monitoring of security alerts and threat feeds
+    - Triage and prioritize brand protection alerts
+    - First-line analysis of potential threats
+    - Escalate high-priority incidents to appropriate teams
+    - Document and track incident patterns
+    
+    **How to enable them:**
+    - Integrate ChainPatrol alerts into existing SOC tools (SIEM, ticketing systems)
+    - Provide clear escalation procedures and runbooks
+    - Define severity levels and response SLAs
+    - Give access to brand protection dashboards
+    - Include brand protection metrics in SOC reporting
+  </Tab>
+  
+  <Tab title="Customer Support" icon="headset">
+    **Why they're critical:** Support teams interact directly with customers who may have fallen victim to scams.
+    
+    **What they contribute:**
+    - Receive direct reports from users who encountered scams
+    - Identify patterns in customer complaints about suspicious communications
+    - Gather detailed information about scam tactics from victims
+    - Provide immediate assistance to affected customers
+    - Reduce impact by quickly identifying and escalating threats
+    
+    **How to enable them:**
+    <AccordionGroup>
+      <Accordion title="Training" icon="graduation-cap">
+        Train them to recognize and document phishing reports
+      </Accordion>
+      
+      <Accordion title="Response Templates" icon="file-lines">
+        Create templates for customer responses about security incidents
+      </Accordion>
+      
+      <Accordion title="Escalation Process" icon="arrow-up">
+        Give them a clear process to escalate brand abuse reports
+      </Accordion>
+      
+      <Accordion title="Post-Incident Reviews" icon="magnifying-glass">
+        Include them in post-incident reviews to improve response
+      </Accordion>
+      
+      <Accordion title="Threat Updates" icon="bell">
+        Provide regular updates on active threats to watch for
+      </Accordion>
+    </AccordionGroup>
+  </Tab>
+  
+  <Tab title="Communications & PR" icon="newspaper">
+    **Why they're critical:** Comms teams manage public messaging during and after security incidents.
+    
+    **What they contribute:**
+    - Craft official statements about brand impersonation incidents
+    - Coordinate public warnings about active scams
+    - Monitor social media and news for brand mentions related to scams
+    - Manage reputation during high-profile incidents
+    - Interface with media during major security events
+    
+    **When to involve them:**
+    - Widespread scams affecting many users
+    - Incidents gaining media attention
+    - Coordinated takedown efforts that should be publicized
+    - Creating proactive security awareness campaigns
+    - Responding to public questions about brand security
+  </Tab>
+</Tabs>
+
+## Technical Implementation
+
+These team members handle the integration and technical setup of brand protection tools.
+
+<CardGroup cols={3}>
+  <Card title="IT Teams" icon="server">
+    Handle infrastructure and access
+  </Card>
+  
+  <Card title="Engineering Teams" icon="code">
+    Build custom integrations
+  </Card>
+  
+  <Card title="Support Operations" icon="gears">
+    Manage support tool workflows
+  </Card>
+</CardGroup>
+
+<AccordionGroup>
+  <Accordion title="IT Teams" icon="server">
+    **Why they're critical:** IT teams manage your organization's technology infrastructure and access controls.
+    
+    **What they contribute:**
+    - Provision access to brand protection tools for appropriate staff
+    - Integrate tools with existing IT infrastructure
+    - Manage SSO and authentication for security platforms
+    - Ensure compliance with IT security policies
+    - Handle technical troubleshooting and vendor coordination
+    
+    **When to involve them:**
+    <Tabs>
+      <Tab title="Setup" icon="rocket">
+        - Initial tool procurement and setup
+        - User access management and permissions
+        - SSO configuration and integration
+      </Tab>
+      
+      <Tab title="Operations" icon="gears">
+        - Network and firewall configuration for tool access
+        - Regular access reviews and audits
+        - Technical troubleshooting
+      </Tab>
+    </Tabs>
+  </Accordion>
+  
+  <Accordion title="Engineering Teams" icon="code">
+    **Why they're critical:** Engineers can build custom integrations and automation.
+    
+    **What they contribute:**
+    - Develop custom integrations using brand protection APIs
+    - Build internal dashboards combining multiple data sources
+    - Create automated workflows for threat response
+    - Develop custom detection logic for your specific use case
+    - Implement webhook handlers for real-time alerts
+    
+    **When to involve them:**
+    <CardGroup cols={2}>
+      <Card title="Custom Integrations" icon="plug">
+        Building integrations with internal tools
+      </Card>
+      
+      <Card title="Automation" icon="robot">
+        Automating repetitive brand protection tasks
+      </Card>
+      
+      <Card title="Custom Reporting" icon="chart-bar">
+        Creating custom reporting or dashboards
+      </Card>
+      
+      <Card title="Detection Rules" icon="filter">
+        Developing organization-specific detection rules
+      </Card>
+    </CardGroup>
+  </Accordion>
+  
+  <Accordion title="Customer Support Operations/Engineering" icon="gears">
+    **Why they're critical:** Support operations teams manage support tools and workflows.
+    
+    **What they contribute:**
+    - Integrate brand protection alerts into support ticketing systems
+    - Configure routing rules for security-related support tickets
+    - Build custom views and reports for support teams
+    - Train support staff on new tools and processes
+    - Optimize support workflows for efficiency
+    
+    **When to involve them:**
+    - Integrating with support platforms (Zendesk, Intercom, etc.)
+    - Creating macros and templates for common responses
+    - Setting up automated ticket routing and tagging
+    - Building support team dashboards
+    - Training support staff on technical tools
+  </Accordion>
+</AccordionGroup>
+
+## Building Your Brand Protection Team
+
+<Info>
+You don't need all of these roles to get started. Start with the knowledge owners and threat reporters, then expand to technical implementation as your program matures.
+</Info>
+
+### Minimum Viable Team
+
+For most organizations, start with:
+
+<Steps>
+  <Step title="Executive Sponsor">
+    One C-suite or senior leader to champion the program
+  </Step>
+  
+  <Step title="Marketing Representative">
+    Someone who knows all official brand assets
+  </Step>
+  
+  <Step title="Security Contact">
+    A security team member to handle technical threats
+  </Step>
+  
+  <Step title="Community Manager">
+    Someone to coordinate community reporting
+  </Step>
+</Steps>
+
+### Scaling Your Team
+
+As your program grows, add:
+
+<CardGroup cols={2}>
+  <Card title="Dedicated Analyst" icon="user">
+    Full-time role for threat monitoring and response
+  </Card>
+  
+  <Card title="Engineering Support" icon="code">
+    Developer time for custom integrations
+  </Card>
+  
+  <Card title="Support Training" icon="graduation-cap">
+    Train support team on security reporting
+  </Card>
+  
+  <Card title="PR Coordination" icon="newspaper">
+    Communications team for public incidents
+  </Card>
+</CardGroup>
+
+---
+
+<Card
+  title="Need Help Building Your Team?"
+  icon="users"
+  href="https://cal.com/chainpatrol"
+>
+  Schedule a consultation to discuss the right team structure for your organization
+</Card>