Question 1

What is $GUARD and why does ChainGuard have a token?

Accepted Answer

$GUARD is ChainGuard's product-first token that will only launch if it clearly strengthens the ChainGuard product and empowers our community. We follow a product-first philosophy: real usage, revenue, and security before any token. $GUARD will only exist if it provides genuine utility that non-token mechanisms cannot deliver. No hype cycles, no high-FDV/low-float games — just transparent gates, evidence, and accountability.

Question 2

What does 'product-first' mean for $GUARD?

Accepted Answer

Product-first means we build and ship the ChainGuard product first, achieve real usage and sustainable revenue, and only then consider if a token adds genuine value. The default is 'not yet' until every launch gate is green and the community can verify the evidence. We don't launch tokens to fund product development — we launch products, and only consider tokens if they enhance what already works.

Question 3

When will $GUARD launch?

Accepted Answer

There is no launch date. $GUARD will only launch if and when all 10 launch gates are green: live product with audits, meaningful usage/retention, sustainable revenue model, healthy community, governance readiness, compliance approvals, proven utility, responsible economics, ethical distribution, and post-launch transparency. The default is 'not yet' until every requirement is met and verified.

Question 4

Why have $GUARD at all?

Accepted Answer

$GUARD will only exist if it extends ChainGuard product utility or community governance in ways that non-token mechanisms cannot. We evaluate each potential utility against simpler alternatives. If a non-token solution works just as well, we use that instead. $GUARD utilities must prove clear product advantage — not just token speculation or yield farming.

Question 5

How is $GUARD different from other crypto tokens?

Accepted Answer

$GUARD follows a fundamentally different approach: 1) Product-first (product ships before token consideration), 2) Transparent gates (10 launch requirements must all be green), 3) Utility validation (must prove better than non-token alternatives), 4) Community verification (evidence published for community review), 5) No hype cycles (no marketing before product milestones), 6) Sustainable economics (low-FDV, sufficient float, no dependency on price), 7) Radical transparency (public dashboards, unlock calendars, treasury policies). Most tokens launch to fund development — $GUARD only launches if it enhances an already-working product.

Question 6

What are the launch gates for $GUARD?

Accepted Answer

There are 10 launch gates that must all be green: 1) Live product & independent security audits (99.5% uptime, 2+ audits, no P0/P1 issues), 2) Meaningful usage & retention (≥5,000 WAU or ≥500 DAU for 8 weeks OR ≥$25k MRR), 3) Sustainable revenue model (clear pricing, margins, CAC/LTV, 6-12 month runway independent of token), 4) Healthy, verified community (≥10k verified members, 5%+ weekly active, ≥50 recurring contributors), 5) Governance charter & progressive decentralization plan (published, working groups defined, Snapshot live), 6) Compliance & risk approvals (jurisdictional analysis, KYC/AML policy, public risk factors), 7) Proven $GUARD utility (clear product advantage, 2+ utilities require $GUARD, no-token alternative analysis), 8) Responsible economics (draft supply/emissions vetted, sustainable flows, no price dependency), 9) Ethical distribution & liquidity (long-term contribution alignment, ≥20-30% initial float, 4-6 year unlocks), 10) Post-launch transparency & operations (incident response, monthly reports, kill-switch policy). If any gate is red or ambiguous, we pause.

Question 7

Who owns each launch gate?

Accepted Answer

Each launch gate has a functional lead responsible for collecting evidence and publishing it: Gate 0 (Problem & Fit) - Product, Gate 1 (Product Readiness) - Engineering, Gate 2 (Real Usage) - Product/Analytics, Gate 3 (Sustainable Economics) - Finance/RevOps, Gate 4 (Community Health) - Community, Gate 5 (Governance Readiness) - Governance, Gate 6 (Compliance & Risk) - Legal/Risk, Gate 7 (Token Utility Validation) - Product/Economics, Gate 8 (Economic Guardrails) - Tokenomics, Gate 9 (Distribution & Liquidity) - Treasury/Markets, Gate 10 (Launch & Post-Launch) - PMO. Each owner must provide verifiable evidence before their gate is marked green.

Question 8

What happens if a launch gate turns red after being green?

Accepted Answer

If any launch gate turns red or becomes ambiguous after being green, we pause the launch process immediately. The default is 'not to launch' — gates must remain green continuously. If conditions deteriorate (usage drops, revenue model fails, security issues, compliance problems), we halt the launch until the gate is green again. This kill-switch policy ensures we only launch when all conditions are met and maintained.

Question 9

Can the community verify launch gate status?

Accepted Answer

Yes! All launch gate evidence is published on the $GUARD token page with public dashboards, metrics, audit reports, and verification links. The community can review: usage metrics (WAU/DAU/MRR), security audit reports, community health metrics, governance proposals, compliance memos, utility analyses, economic models, distribution plans, and transparency reports. Nothing is hidden — all evidence is verifiable and publicly accessible.

Question 10

What are the core principles governing $GUARD?

Accepted Answer

Four non-negotiable principles govern $GUARD: 1) Utility > Hype — $GUARD must deliver product capabilities or governance superpowers that non-token mechanics cannot, 2) Community Value First — real users, contributors, and partners benefit post-product (no pre-product extraction), 3) Sustainability & Compliance — economics, treasury, and governance designed for resilient operations and jurisdictional readiness, 4) Radical Transparency — public supply dashboards, unlock calendars, treasury policies, and incident runbooks required. These principles are non-negotiable and cannot be compromised.

Question 11

What does 'Utility > Hype' mean?

Accepted Answer

'Utility > Hype' means $GUARD must provide genuine functional value that cannot be achieved without a token. We reject token launches based on marketing, speculation, or 'community building' alone. Every proposed $GUARD utility must pass a 'no-token alternative' test: if a simpler non-token mechanism works just as well, we use that instead. $GUARD utilities must prove clear product or governance advantage through prototypes, simulations, and real-world testing.

Question 12

What does 'Community Value First' mean?

Accepted Answer

'Community Value First' means real users, contributors, and partners benefit after the product is working, not before. We reject pre-product token extraction where tokens launch to fund development and early investors/speculators profit while the product remains unfinished. With $GUARD, the product ships first, achieves real usage and revenue, and only then do we consider token distribution — prioritizing long-term contributors and real usage over speculation.

Question 13

What does 'Radical Transparency' mean for $GUARD?

Accepted Answer

'Radical Transparency' means all $GUARD information is publicly accessible: supply dashboards showing total supply, circulating supply, and unlock schedules; treasury policies showing how funds are managed and spent; unlock calendars showing exactly when and how much $GUARD unlocks; economic models showing sustainable flows across bull/bear scenarios; incident runbooks showing how we handle problems; monthly transparency reports showing usage, finances (non-sensitive), security updates, and community highlights. Nothing is hidden — everything is verifiable.

Question 14

What utilities will $GUARD provide?

Accepted Answer

$GUARD utilities are still being validated, but potential product utilities include: network access & resource credits that map to real costs, in-app staking as signal (not yield farming), fee rebates or bonding curves tied to verifiable usage, deposits that reserve scarce resources or prevent spam, module marketplace fees that fund maintenance. Potential community & governance utilities include: voting & delegation with anti-whale protections, working-group budgets with clawbacks for non-delivery, retroactive rewards for measurable contributions, progressive decentralization milestones driven by data. All utilities must prove clear ChainGuard product advantage before implementation.

Question 15

How do you validate $GUARD utility?

Accepted Answer

We validate $GUARD utility through: 1) Prototype development — build working prototypes of proposed utilities, 2) Simulation modeling — run economic simulations across bull/bear scenarios, 3) No-token alternative analysis — compare $GUARD utility against simpler non-token mechanisms, 4) User testing — test utilities with real users and measure outcomes, 5) Community review — publish utility proposals for community feedback, 6) Evidence collection — gather data proving utility provides clear product advantage. Only utilities that pass all validation steps will be implemented. We publish all validation results publicly.

Question 16

Will $GUARD have staking or yield farming?

Accepted Answer

If $GUARD staking exists, it will be for reputation, access, or resource reservations — never for yield farming without productive backing. We reject 'stake for yield' mechanics that rely on token price appreciation or perpetual growth narratives. Any staking mechanism must serve a functional purpose (e.g., signaling commitment, reserving resources, gating access) and must be sustainable without depending on $GUARD price performance.

Question 17

Can $GUARD be used for payments?

Accepted Answer

$GUARD token payments may be available in the future if and when the token launches, but only after all product milestones are met and the token provides clear utility to the ChainGuard product. Currently, ChainGuard accepts Stripe (credit/debit cards) and Ethereum (ETH) for payments. We don't assume $GUARD revenue in our base operating plan — the product must be sustainable without token payments.

Question 18

What is $GUARD's tokenomics model?

Accepted Answer

$GUARD tokenomics follow responsible economics principles: total supply capped or bounded inflation with purpose, target emissions runway of 6-8 years (no front-loaded giveaways), initial circulating supply ≥20-30% (avoid high-FDV/low-float), smooth predictable unlocks (frequent small unlocks, public calendar, no mega-unlocks), distribution aligned with long-term contribution (50-65% community/users/contributors, 10-15% team with 4-year vest, 15-20% investors with 3-4 year vest, 5-10% liquidity/market ops), no reliance on $GUARD price appreciation in core value proposition. All tokenomics are published transparently before launch.

Question 19

What is 'low-FDV, sufficient float' and why does it matter?

Accepted Answer

'Low-FDV, sufficient float' means: 1) Initial circulating supply ≥20-30% of total supply (avoiding high fully-diluted valuation with tiny float), 2) Realistic unlock schedules (4-6 year unlocks, no cliff-day overhangs), 3) Insider selling policies (cooling-off periods, pre-announced windows, executives on delayed schedules), 4) No artificial scarcity games. This prevents the common crypto problem where tokens launch with high valuations but tiny float, leading to price manipulation and insider dumps. $GUARD prioritizes fair distribution and sustainable economics over hype-driven valuations.

Question 20

Will there be an airdrop for $GUARD?

Accepted Answer

If any $GUARD distribution happens, it will prioritize long-term contributors and real usage — details will be published transparently. We reject airdrops that reward speculation, sybil attacks, or short-term engagement. Any distribution will be based on: measurable contributions (code, docs, support, ecosystem modules), real product usage (verified usage patterns, not just sign-ups), community participation (quality contributions, not just activity), long-term commitment (sustained engagement over time). Distribution plans will be published well in advance for community review.

Question 21

How will $GUARD be distributed?

Accepted Answer

$GUARD distribution will align with long-term contribution: 50-65% to community, users, contributors, and ecosystem (mix of treasury, grants, retro rewards), 10-15% to team including future hires (≥4-year vest with 1-year cliff, linear monthly thereafter), 15-20% to investors/partners (≥3-4 year vest, aligned with milestones), 5-10% to liquidity/market ops/reserves (strict transparency). Distribution prioritizes contributors and users over investors and insiders. All distribution plans are published transparently before launch.

Question 22

What is the $GUARD unlock schedule?

Accepted Answer

$GUARD unlock schedule follows responsible economics: initial circulating supply ≥20-30%, smooth predictable unlocks (frequent small unlocks, not mega-unlocks), public unlock calendar (exact dates and amounts published), 4-6 year unlock period (no cliff-day overhangs), insider selling policies (cooling-off periods, pre-announced windows). The unlock schedule is published before launch and updated monthly. No surprises, no hidden unlocks, no insider advantages.

Question 23

How will $GUARD governance work?

Accepted Answer

$GUARD governance follows progressive decentralization: Phase A (pre-$GUARD) — off-chain signaling (Snapshot), contributor program, small budgets controlled by core team. Phase B (early $GUARD) — $GUARD voting with safeguards (delegation, reputation overlays, quorum/slashing for spam, circuit breakers). Phase C (mature) — independent foundation or council with clear mandates, budget caps, audits, annual elections. Governance powers scale with product maturity and contributor readiness. Governance charter and progressive decentralization plan are published before launch.

Question 24

What is progressive decentralization?

Accepted Answer

Progressive decentralization means governance powers increase gradually as the product matures and the community demonstrates readiness. We don't launch with full decentralization immediately — that often leads to governance attacks, spam, or poor decisions. Instead, we start with off-chain signaling and small budgets, then gradually increase on-chain governance powers as the community proves capable. This protects the product while building toward true decentralization over time.

Question 25

Will $GUARD holders control ChainGuard?

Accepted Answer

Eventually, yes — but governance powers scale with product maturity. Initially, $GUARD governance focuses on token-related decisions (distribution, utility proposals, treasury management). Product decisions remain with the core team until the community demonstrates governance readiness. Over time, governance powers expand to include product direction, feature prioritization, and strategic decisions. The progressive decentralization plan outlines exactly how and when governance powers transfer to the community.

Question 26

Is $GUARD compliant with regulations?

Accepted Answer

Compliance is a launch gate requirement. Before $GUARD launches, we complete: jurisdictional analysis (decision memo on token classification and distribution constraints), KYC/AML policy (defined for any claim/airdrop if applicable), public risk factors (market, technical, regulatory risks documented), legal counsel review (independent legal counsel prior to any token issuance). We design with jurisdictional and regulatory considerations from day one. Compliance requirements vary by jurisdiction — we publish our compliance approach transparently.

Question 27

What are the risks of $GUARD?

Accepted Answer

Public risk factors are documented before launch, including: market risks (volatility, liquidity, regulatory changes), technical risks (smart contract vulnerabilities, network issues, key management), regulatory risks (jurisdictional changes, classification changes, enforcement actions), operational risks (team changes, infrastructure failures, security breaches), economic risks (tokenomics failures, unsustainable emissions, price dependency). All risks are published transparently — nothing is hidden. We maintain kill-switch policies to pause or cancel launch if risks become unacceptable.

Question 28

Can $GUARD be considered a security?

Accepted Answer

Token classification is determined through jurisdictional analysis with legal counsel. We design $GUARD to provide genuine utility (product access, governance, resource reservations) rather than investment returns. However, token classification varies by jurisdiction and can change over time. We publish our legal analysis and classification decision transparently. If $GUARD is classified as a security in any jurisdiction, we comply with applicable regulations or restrict distribution in that jurisdiction.

Question 29

How transparent is $GUARD?

Accepted Answer

$GUARD follows radical transparency: public supply dashboards (real-time supply, float, unlocks), unlock calendars (exact dates and amounts), treasury policies (how funds are managed, spent, and diversified), monthly transparency reports (usage metrics, finances non-sensitive, security updates, community highlights), on-chain dashboards (all $GUARD flows, grants, distributions), incident runbooks (how we handle problems), economic models (sustainable flows, simulations). Nothing is hidden — everything is verifiable and publicly accessible from day one.

Question 30

Where can I track $GUARD launch gate progress?

Accepted Answer

Launch gate progress is tracked on the $GUARD token page with: gate status indicators (green/yellow/red), evidence links (audit reports, metrics dashboards, compliance memos), owner information (who owns each gate), verification links (how to verify evidence), community review sections (where community can comment). All gate evidence is published publicly — you can verify each requirement yourself. Gate status updates monthly or when significant changes occur.

Question 31

How can I hold ChainGuard accountable for $GUARD?

Accepted Answer

You can hold us accountable by: reviewing launch gate evidence (verify each requirement yourself), tracking transparency reports (monthly updates on progress), participating in community discussions (provide feedback on proposals), monitoring public dashboards (supply, unlocks, treasury), reporting issues (if you find problems, report them), voting in governance (when governance is live). We publish all evidence publicly — if we can't prove a gate is green, it's not green. The community can verify everything.

Question 32

How can I contribute to ChainGuard and potentially earn $GUARD?

Accepted Answer

You can contribute by: shipping product features (code contributions, bug fixes, improvements), writing documentation (guides, tutorials, API docs), providing support (help users, answer questions, moderate community), building ecosystem modules (integrations, tools, extensions), participating in governance (proposals, discussions, voting when live), contributing to security (bug reports, audits, security research). Contributions are tracked on public leaderboards. Long-term contributors and real usage are prioritized for any future $GUARD distribution.

Question 33

Do I need to contribute to get $GUARD?

Accepted Answer

Contribution is not required, but it's the primary way to potentially earn $GUARD if and when distribution happens. We prioritize long-term contributors and real usage over speculation or airdrop farming. However, $GUARD may also be available through: product usage (if $GUARD utilities require holding/spending), governance participation (if voting requires $GUARD), marketplace activities (if module marketplace uses $GUARD). Distribution plans will be published transparently before launch — nothing is guaranteed, but contribution is the most reliable path.

Question 34

How are contributions tracked?

Accepted Answer

Contributions are tracked on public leaderboards showing: code contributions (GitHub commits, PRs, issues), documentation contributions (docs written, tutorials created), support contributions (questions answered, issues resolved), ecosystem contributions (modules built, integrations created), community contributions (discussions, proposals, moderation), security contributions (bug reports, audits, research). Leaderboards are public and verifiable — you can see exactly who contributed what and when. Long-term sustained contributions are weighted more than one-time contributions.

Question 35

How does $GUARD compare to other crypto tokens?

Accepted Answer

$GUARD differs fundamentally: 1) Product-first (product ships before token, not token to fund product), 2) Transparent gates (10 requirements must all be green, publicly verifiable), 3) Utility validation (must prove better than non-token alternatives), 4) Sustainable economics (low-FDV, sufficient float, no price dependency), 5) Radical transparency (public dashboards, unlock calendars, treasury policies), 6) Community verification (evidence published for review), 7) Kill-switch policy (can cancel launch if conditions deteriorate). Most tokens launch to fund development or reward early investors — $GUARD only launches if it enhances an already-working product.

Question 36

Why not just use existing tokens or stablecoins?

Accepted Answer

We evaluate every proposed $GUARD utility against existing alternatives (ETH, stablecoins, existing governance tokens). If existing tokens work just as well, we use those instead. $GUARD only makes sense if it provides unique utility that existing tokens cannot: ChainGuard-specific product access, ChainGuard governance, ChainGuard resource reservations, ChainGuard ecosystem rewards. We publish 'no-token alternative' analyses showing why $GUARD is needed vs. simpler mechanisms. If we can't prove $GUARD is better, we don't launch it.

Question 37

What if $GUARD never launches?

Accepted Answer

That's perfectly acceptable — and responsible. The default is 'not to launch' until all gates are green. If utilities are weak, conditions deteriorate, or we can't prove $GUARD adds value, we won't launch it. The product works without $GUARD — we don't need a token to operate. If $GUARD never launches, ChainGuard continues operating normally with Stripe and ETH payments. A token is optional, not required. We're committed to doing the right thing, even if that means not launching a token.

Question 38

What blockchain will $GUARD launch on?

Accepted Answer

Blockchain selection is part of the launch gate requirements (Gate 9: Distribution & Liquidity). We'll evaluate: Ethereum mainnet (maximum security, highest costs), Layer 2 solutions (Base, Arbitrum, Optimism, Polygon — lower costs, good security), alternative chains (if they provide better economics or features). Selection criteria include: security, decentralization, costs, ecosystem compatibility, regulatory considerations. The chosen blockchain(s) will be announced well in advance with justification for the decision.

Question 39

Will $GUARD be an ERC-20 token?

Accepted Answer

Token standard selection depends on the chosen blockchain and required features. If launching on Ethereum or EVM-compatible chains, ERC-20 is likely. However, we'll evaluate: ERC-20 (standard fungible token), ERC-1400 (security token standard if needed), custom standards (if unique features required), multi-chain deployment (if launching on multiple chains). Token standard selection is part of Gate 8 (Economic Guardrails) and will be published with technical specifications before launch.

Question 40

How will $GUARD integrate with ChainGuard products?

Accepted Answer

$GUARD integration depends on validated utilities. Potential integrations include: Vault operations (if $GUARD required for advanced features), Identity system (if $GUARD used for attestation or verification), OAuth authentication (if $GUARD used for access control), Mobile app (if $GUARD used for 2FA or device binding), Dashboard (if $GUARD used for governance or rewards). All integrations are validated through prototypes and user testing before implementation. Integration plans are published transparently.

Question 41

What is the roadmap for $GUARD?

Accepted Answer

The roadmap has three phases: Today — Ship ChainGuard product, grow verified usage, publish monthly transparency reports. Next — Prototype $GUARD utilities, run simulations, publish 'no-token' alternative analyses, validate utilities with real users. Later — If all gates are green, publish detailed $GUARD launch plan well in advance (timeline, distribution, utilities, economics, governance). There is no fixed timeline — we move to the next phase only when current phase milestones are met. The roadmap is updated monthly in transparency reports.

Question 42

How long until $GUARD launches?

Accepted Answer

There is no timeline. $GUARD launches only when all 10 gates are green and the community can verify the evidence. This could be months, years, or never — it depends on product success, community growth, utility validation, and compliance readiness. We don't set artificial deadlines or rush to launch. Quality and sustainability matter more than speed. We publish monthly updates on gate progress, but we won't launch until everything is ready.

Question 43

What happens after $GUARD launches?

Accepted Answer

Post-launch operations include: monthly transparency reports (usage, finances, security, community), on-chain dashboards (supply, unlocks, treasury, grants), governance activation (progressive decentralization begins), utility rollout (validated utilities go live), community programs (contributor rewards, governance participation), incident response (handling problems, security issues, market events), continuous validation (ensuring utilities remain valuable, economics remain sustainable). Post-launch operations are defined in Gate 10 and executed transparently.

$GUARD, Wenn und Falls Es Hilft

Launch-Gates (müssen alle grün sein)

Kernprinzipien

Utility > Hype

Community-Wert zuerst

Nachhaltigkeit & Compliance

Radikale Transparenz

$GUARD Utility Muss ChainGuard Dienen

Produkt-Utilities

Community & Governance

Weg zu $GUARD

Phase 1: Produktgrundlage

Phase 2: Echte Nutzung & Umsatz

Phase 3: Community & Governance

Phase 4: Compliance & Utility-Validierung

Phase 5: Ökonomisches Design & Verteilung

Phase 6: Pre-Launch-Vorbereitung

Phase 7: Launch & Progressive Dezentralisierung

Verfolge die Gates. Halte uns zur Rechenschaft.