WAKE

Base has become one of the most active L2 environments in crypto. The pace of token launches, liquidity events, and capital rotation produces more data per hour than any individual operator can read, much less interpret. Existing tools split this problem in two unsatisfying ways: dashboards that show raw data without judgment, and signal services that deliver judgment without showing their work.

Neither serves operators well. Raw data without interpretation forces every operator to re-derive the same insights from scratch. Judgment without underlying data forces operators to trust a black box. The result is that most Base operators end up using Dexscreener, Etherscan, and DefiLlama in parallel browser tabs, mentally cross-referencing dozens of signals to form a working picture of any given token or moment.

WAKE addresses this by being explicit about both layers. Every output the engine produces shows the underlying signals that informed it. Every score has a breakdown. Every flag has a threshold. The judgment is fast and concise, but always traceable back to the data that produced it.

This whitepaper documents the engine's current state, its scoring methodologies, the data sources it draws from, and its token mechanics. It is intended for operators considering WAKE, for ecosystem partners evaluating integration, and for the curious who want to understand what is actually happening behind the terminal.

The intelligence problem on Base is not a lack of data. It is the opposite. Every swap, transfer, liquidity event, and contract deployment is publicly visible. The problem is interpretive bandwidth.

Three specific failures are common in existing tools:

**The trust gap.** Signal providers tell operators what to think but not why. When a token gets flagged as "high risk" by an existing tool, operators have no way to verify the underlying logic. They either trust the source or ignore it. Neither response builds durable confidence.

**The noise gap.** Dashboards show every signal equally. A token with $50 of liquidity and a token with $50,000 of liquidity appear in the same trending feed. Operators must filter manually, which means most signals are wasted.

**The context gap.** Onchain data alone is not enough to interpret a token. A token deployed through a fair-launch protocol like Clanker or Bankr should be evaluated differently than a manually deployed contract with retained ownership. A wallet with three trades is a different entity than a wallet with three thousand. Existing tools treat these equivalently.

WAKE addresses the trust gap by making every score breakdown visible. It addresses the noise gap by computing flags with explicit thresholds, surfaced only when those thresholds are crossed. It addresses the context gap by classifying launch protocols, deployer histories, and wallet behaviors before producing any interpretation.

WAKE is built on a strict separation between data and judgment.

3.1 The Deterministic Layer

The deterministic layer is responsible for gathering, normalizing, and computing signals from public sources. It does not interpret. Its outputs are numbers and categorical flags.

Sources used in this layer include:

- **Dexscreener** for price, liquidity, volume, and social metadata - **GeckoTerminal** for trending pool rankings and aggregate buyer/seller activity - **Etherscan V2** for contract creation transactions, verification status, and transaction histories on Base - **Public Base RPC and contract reads** for ownership, mint status, LP burn verification, and deployment chain inspection - **DefiLlama** for protocol-level TVL and fee data (Traction module) - **DexScreener boosts API** for paid promotion activity

The deterministic layer produces structured outputs: scores in defined ranges (0-20 per criterion, 0-100 aggregate), categorical flags (CONVERGENCE, MANUFACTURED, ORGANIC, NEUTRAL), and severity levels (LOW, MEDIUM, HIGH, CRITICAL) calculated from explicit thresholds.

3.2 The Interpretive Layer

The interpretive layer takes the deterministic outputs and produces concise operator-readable judgment. It is implemented as a server-side engine that receives structured data, generates a brief narrative interpretation, and returns it for display.

The interpretive layer never sees raw API responses. It sees only the normalized data the deterministic layer has prepared. This means the judgment is always grounded in computed signals, and the same input always produces the same interpretation (within caching periods).

Critically, the interpretive layer's outputs are always paired with the underlying numbers in the user interface. An operator reading a WAKE analysis sees the narrative interpretation, the score, the criterion-by-criterion breakdown, the tags, and the underlying data points. Nothing is hidden.

3.3 Caching and Cost Discipline

Every interpretive layer call is cached. Token analyses cache by contract address. Wallet analyses cache by wallet plus timeframe. Pulse Check analyses cache by token plus hour bucket. When an operator requests an analysis that has already been performed for the same target within the cache window, the cached result is returned at zero cost.

This caching is shared across all operators. The first operator to request analysis on a given token pays the compute cost. Every subsequent operator analyzing the same token receives the cached result instantly and freely. The cache is a network effect that improves with use.

Spend caps are enforced at the server level. Per-feature caps prevent any single module from exhausting the engine's compute budget. A rolling 24-hour cap prevents runaway costs from spam or abuse. When caps are reached, cached analyses remain available; new analyses pause until the window resets.

3.4 Honest Failure Modes

Every WAKE module is designed to degrade gracefully when data sources fail.

Rate limits trigger exponential backoff with retry, then circuit-breaker termination if failures persist. Partial results are returned with explicit "partial" flags rather than crashing. Missing data is scored as neutral (10/20 on the criterion), not as a penalty (0/20). API outages are surfaced in the user interface as status indicators, not hidden as silent zeros.

This discipline matters because the alternative — silent failure that produces wrong numbers — is worse than no data at all. Operators must know what the engine knows and what it does not.

The Token Analysis is the engine's flagship analysis tool. An operator pastes a Base token contract address, the engine assembles a comprehensive data payload, and the interpretive layer produces a 0-100 score with criterion-by-criterion breakdown.

4.1 Data Pipeline

Before any judgment is produced, the engine assembles the following data points:

**Market data (Dexscreener):** - Current price, liquidity, market capitalization, 24-hour volume - 24-hour price change - Pair age (since creation) - Social metadata (linked websites, X handles, Telegram channels)

**Onchain data:** - Contract creation transaction and deployer address - Deployment chain inspection (all contracts involved in the creation transaction) - Launch protocol classification (Bankr/Whetstone, Clanker, direct deploy) - Contract verification status via Etherscan V2 - LP token burn status (for the primary pair) - Total supply - Ownership renouncement status

**Social signal data:** - X handle URL evaluation (handle matches token branding, follower coherence) - Website content fetch (title, meta description, first ~1000 chars of body text) - Social channel inventory (count and platform distribution)

The data pipeline UI shows operators exactly which fields were successfully gathered before any interpretation is run. Missing fields are marked explicitly. This allows operators to verify the engine's working data before requesting analysis.

4.2 Launch Protocol Detection

A specific class of detection that warrants discussion: identifying whether a token was launched through a protocol like Bankr or Clanker, both of which deploy contracts on Base.

The engine performs deployment chain inspection by: 1. Fetching the contract creation transaction via Etherscan V2's `getcontractcreation` endpoint 2. Retrieving the transaction details (from, to, receipt logs) 3. Identifying the initial mint recipient (from the first Transfer event from the zero address) 4. Collecting all contract addresses involved in the creation event

Bankr launches are identified by the presence of the Whetstone Airlock Launch Controller (`0x660eaaedebc968f8f3694354fa8ec0b4c5ba8d12`) in the deployment chain. Clanker launches are identified by matching against the full set of Clanker factory contract addresses, including all historical and current versions (v0.0.0 through v4.1.0).

This classification matters for scoring because protocol-deployed tokens enforce specific guarantees by design — LP burn on graduation, ownership renouncement, and mint disabled — which would otherwise have to be verified independently. The engine scores these tokens accordingly without penalizing them for "no prior deployer history," which is meaningless for protocols that use fresh deployer addresses per launch.

4.3 Scoring Methodology

The Token Analysis produces a 0-100 score across five criteria, each scored 0-20:

**Deployer Quality (0-20)**

For Bankr or Clanker launches, the baseline floor is 16 points. The launch infrastructure provides the deployer signal; "no prior launches" is not a penalty. Adjustments above the floor reflect visible positive track record on related deployments.

For direct deploys, scoring depends on visible signals: verified contract and LP burned scores 12-15, partial verification scores 8-12, neither verified nor LP burned scores 0-7.

For unknown classifications (detection failed), the score is 10 (neutral).

**Liquidity Health (0-20)**

Scored by liquidity in USD. Above $50,000 scores 16-20. Between $25,000 and $50,000 scores 13-16. Below $5,000 scores 0-6. Missing liquidity data scores 10 neutral.

**Contract Safety (0-20)**

For Bankr or Clanker launches, the baseline floor is 16. These protocols deploy prebuilt audited contracts with safe ERC20 patterns. Direct deploys score based on verification and LP burn status individually.

**Market Signals (0-20)**

Computed from volume-to-liquidity ratio and price action. Healthy ratios with reasonable price movement score 14-18. Extreme dump patterns or dead volume score 0-6.

**Social Signals (0-20)**

Evaluates X handle quality (handle matches branding), website coherence (fetched content suggests a real project rather than a generic template), and channel inventory. Strong socials score 16-20. No socials linked scores 4-8 — meaningfully below average but not catastrophic, since many fair-launch tokens are deliberately anonymous.

When a token is part of a verified ecosystem partner program (currently Aeon Framework), a small honest bonus of 3-5 points is added to social_signals, capped at 20. The bonus is shown explicitly in the breakdown as "+3 ecosystem bonus" so operators can see why the score includes it. This is not a hidden inflation. It reflects that ecosystem membership is genuine social signal.

4.4 Output Format

The Token Analysis returns: - An overall 0-100 score, color-coded by tier - The five criterion breakdowns - A set of tags drawn from a controlled vocabulary (e.g., CLANKER_LAUNCH, BANKR_LAUNCH, VERIFIED, LP_BURNED, RUG_RISK, STRONG_DEPLOYER, WEBSITE_LEGITIMATE) - A 3-5 sentence narrative analysis ending with "NFA." (Not Financial Advice) - The address, the deployment chain inspection result, and links to Dexscreener and Basescan

The analysis is cached permanently per contract address. Every operator analyzing the same token after the first sees the cached result. The cache is one of the engine's primary cost-efficiency mechanisms.

The Exit Detector monitors specific tokens for signature distribution patterns that have historically preceded significant price declines. It does not predict the future. It identifies present-tense patterns and surfaces them with explicit threshold transparency.

5.1 Flag Types

The Exit Detector monitors seven distinct flag types, each with a defined trigger threshold and severity calculation:

**DEPLOYER_DUMP** — The deployer wallet sells more than the configured threshold percentage of supply in a single transaction. Default threshold: 0.5% of supply. Severity is calculated by magnitude: a 5%+ sale is CRITICAL, 2-5% is HIGH, 1-2% is MEDIUM, below 1% is LOW.

**SNIPER_EXIT** — More than 25% of identified sniper cohort wallets exit within a 60-minute window. Sniper cohorts are identified as wallets that bought within the first 5 blocks of token deployment. Severity scales with the percentage of the cohort exiting.

**TOP_10_DISTRIBUTION** — Aggregate balance reduction across top 10 holders exceeds the configured threshold over a 24-hour window. Default threshold: 5% aggregate reduction. CRITICAL at 15%+, HIGH at 8%+, MEDIUM at 5%+.

**LP_REMOVAL** — More than the threshold percentage of LP tokens are moved from the LP holder address. Default threshold: 10% movement. CRITICAL at 50%+ LP removed, HIGH at 25%+, MEDIUM at 10%+.

**BRIDGE_OUT** — More than the threshold percentage of supply is bridged off Base. Default threshold: 0.25% of supply over 24 hours. CRITICAL at 1%+, HIGH at 0.5%+, MEDIUM at 0.25%+.

**LARGE_SELL** — Any single transaction sells more than the configured threshold of supply. Default threshold: 1% of supply per transaction. HIGH at 5%+, MEDIUM at 2-5%, LOW at 1-2%.

**COORDINATED_EXIT** — Two or more of the above flags fire within a 15-minute window. Severity is always CRITICAL when this fires, because the conjunction itself is the signal.

5.2 Transparency Panel

When an operator selects a monitored token, the Exit Detector displays a status panel showing:

- Which of the seven flag types are being actively monitored - The currently-configured threshold for each - The number of triggers detected for each flag type - Last scan timestamp, next scan ETA, and scan interval - Transaction depth checked per scan - Consecutive successful scans - Failure count over the past 24 hours

This panel is the engine's commitment to legibility. An operator can see exactly what the detector is doing, at what cadence, with what thresholds. No flag fires for an unstated reason. No threshold changes silently.

5.3 Per-Flag Detail

When a flag fires, clicking it expands to show:

- The wallet involved (with rank in holder list) - The specific action (size, direction, counterparty if relevant) - The size in USD and as a percentage of supply - The assigned severity and the reasoning for that severity - A direct link to the transaction on Basescan

The interpretive layer generates a brief explanation when a flag fires, providing context about what the pattern historically means without claiming predictive certainty.

The DEX Radar tracks paid DexScreener listings as a leading indicator of where teams are deploying promotional capital. Unlike trending — which can be partially gamed by paid boosts — DEX Radar surfaces the underlying paid activity directly.

6.1 Methodology

The DEX Radar polls DexScreener's enhanced token info endpoints to detect when a token transitions from no paid profile to a paid listing. This transition is the signal: it indicates a team has made a financial commitment to visibility, which often (though not always) precedes more aggressive marketing campaigns.

The radar tracks: - The transition timestamp (when the paid listing first appeared) - The token's market metrics at transition (price, liquidity, volume) - The token's market metrics now (showing change since transition) - The deployer address and launch protocol classification

6.2 Filtering Discipline

Not every paid listing is a meaningful signal. Many are noise from low-effort teams paying for visibility on tokens that never gain traction. The radar applies filters before surfacing tokens:

- Minimum liquidity threshold (configurable) - Minimum time-since-launch threshold (filters out same-day-launch-and-pay patterns) - Exclusion of tokens already in the operator's dismissed list

These filters reduce false positive volume. Operators can adjust them.

6.3 Cross-References

DEX Radar entries cross-link to Token Analysis analysis. An operator who sees a token transition to paid listing on DEX Radar can click directly into Token Analysis to get the full engine analysis for that token. The two modules share the same cache, so an analysis from either path is reused by the other.

Pulse Check is the engine's convergence detector. It measures two distinct attention signals on Base tokens and identifies when they align, diverge, or signal manufactured hype.

7.1 The Two Signals

**Organic attention** is measured via GeckoTerminal's trending pools endpoint. The signal aggregates: - Trending rank (position in GeckoTerminal's algorithm) - Buyer-to-seller ratio (24h) - Total transaction count (24h) - Price momentum

The organic score (0-100) reflects how much *real* market interest a token is generating. Real here means actions, not advertisements — humans clicking, trading, and engaging at a measurable rate.

**Paid attention** is measured via DexScreener's boost APIs. The signal aggregates: - Boost intensity (the `totalAmount` field, calibrated to observed ranges) - Boost rank (position in the Base-filtered boost leaderboard) - Presence in the boost economy (a meaningful signal in itself because Base is uncommonly boosted)

The paid score (0-100) reflects how much *promotional capital* is being deployed for the token.

7.2 Flag Classification

Convergence between the two signals produces four categorical outcomes:

**CONVERGENCE** — Both organic and paid signals are high (≥60). This represents a moment where real interest and paid amplification are reinforcing each other. Historically rare and worth attention.

**MANUFACTURED** — Paid is high (≥60) while organic is low (<40). This is the red flag pattern: a team is spending on visibility but humans are not responding. Often precedes failed campaigns or distributing-while-promoting behavior.

**ORGANIC** — Organic is high (≥60) while paid is low (<20). This is grassroots trending. The signal is that the token is gaining attention without paid amplification, suggesting genuine momentum.

**NEUTRAL** — Everything else. Most tokens, most of the time, are NEUTRAL. The product value of Pulse Check comes precisely from the rarity of the other three flags.

7.3 Cost Discipline

The deterministic layer (signal computation, flag classification, leaderboard ranking) runs continuously at zero compute cost — only free APIs and arithmetic. Refresh cadence is approximately every three minutes.

The interpretive layer (engine summary per token) is opt-in. An operator clicks "CHECK_PULSE_SCORE" on a specific token to receive a brief narrative interpretation. Cached per token plus hour bucket, so the second click on the same token in the same hour returns instantly at no cost.

This separation is deliberate. The deterministic layer is the product, available immediately and constantly. The interpretive layer is the deep dive, available on demand without forcing every operator to pay for narrative on every token in the feed.

7.4 Visibility of Boost Market Context

Pulse Check exposes the broader boost market context in its status bar. Operators see at a glance: how many Base tokens are currently in the global boost lists, what the total observed boost activity is across all chains, and when the boost data was last refreshed.

This matters because Base is uncommonly boosted relative to chains like Solana. Operators who do not know this would interpret "all tokens show low paid scores" as a broken module. The status context makes the reality visible.

Traction is the engine's protocol-level intelligence layer, ranking Base protocols by both TVL and fees. Unlike token-level modules, Traction operates at the protocol level: it surfaces which protocols on Base are accumulating capital, which are generating fee revenue, and how those two metrics relate.

8.1 Data Source

Traction draws from DefiLlama's public API:

- `https://api.llama.fi/protocols` — full protocol list with TVL and chain breakdowns - `https://api.llama.fi/overview/fees/base` — fees per protocol on Base - `https://api.llama.fi/overview/dexs/base` — DEX volume data on Base

All endpoints are free and require no API key. DefiLlama is the canonical source for protocol-level metrics in DeFi and is used by virtually every DeFi analytics tool.

8.2 Methodology

Traction filters DefiLlama's protocol list to those with Base presence, then computes two rankings:

**TVL Ranking** — Protocols ranked by current Base TVL in USD. The leaderboard shows the top protocols with TVL, recent change percentages (24h, 7d, 30d), and category classifications.

**Fees Ranking** — Protocols ranked by 24-hour fees generated on Base. The leaderboard shows fee volumes, fee-to-TVL ratios, and how this compares to historical baselines.

**Combined Traction Score** — A composite ranking that weighs both metrics. Protocols accumulating capital *and* generating fees rank higher than those with only one or the other. The score is deterministic and reproducible: same data in, same ranking out.

8.3 Cross-Module Integration

Traction will cross-reference with other modules:

- A protocol with high Traction may have an associated token. That token can be analyzed in Token Analysis directly from the Traction view. - Protocols showing rapid TVL inflow may be picked up by DEX Radar if their associated tokens are being paid-promoted. - The Pulse Check module's organic signal will be enriched by Traction context — a token tied to a high-Traction protocol carries different weight than an unaffiliated token.

8.4 Refresh and Caching

DefiLlama updates protocol-level metrics on roughly hourly cadence. Traction refreshes at the same cadence, with caching at the chain-snapshot level (one row per protocol per hour bucket). Operators see live data without forcing redundant API calls.

9.1 Distribution

- **Total Supply:** 100,000,000,000 $WAKE (100B, fixed) - **Private Sale:** 0% - **Pre-Sale:** 0% - **Tax (buy/sell):** 0% - **Launch Method:** Fair launch via Virtuals

The contract is immutable, ownership is renounced, mint is disabled, and liquidity is locked on the Virtuals launch infrastructure.

9.2 Access Tiers

Operator access to WAKE modules is gated by $WAKE holdings:

- **Tier 1:** 100,000,000 $WAKE (0.1% of supply) — DEX Radar access - **Tier 2:** 300,000,000 $WAKE (0.3% of supply) — Tier 1 plus Pulse Check and Traction - **Tier 3:** 600,000,000 $WAKE (0.6% of supply) — Tier 2 plus Token Analysis, Skeptic, and Exit Detector

Token thresholds are enforced server-side. Holdings are checked at session start and periodically during use.

9.3 Fee Economy

$WAKE was deployed through Bankr on Whetstone's Airlock infrastructure, which uses Uniswap V4 hooks to capture LP fees on the token's primary pool. A portion of fees generated by swap activity is directed to the creator-configured wallet per the Whetstone Airlock fee distribution mechanics. This is the same fee model used by all Bankr-launched tokens.

Fees from secondary pools (V2, V3, or other DEXes if liquidity emerges there) are not captured by the Whetstone hook and would not flow to the creator wallet. The fee economy is concentrated in the primary V4 pool.

The engine ships in cohorts. Each cohort adds capacity, refines existing modules based on operator feedback, and unlocks the next set of features.

**Cohort 01** (current) — Beta launch with Token Analysis, Exit Detector, DEX Radar, and Pulse Check. Limited access via beta password. Spend caps enforced; per-operator allocation observed.

**Cohort 02** — Traction module ships. Wallet PnL and Wallet Tracker move from locked state to operational. Per-tier access enforcement transitions from manual to onchain $WAKE holding checks.

**Cohort 03** — Cross-module intelligence layer. The engine begins surfacing patterns visible only when multiple modules are combined: tokens that appear simultaneously in DEX Radar (paid attention) and Pulse Check CONVERGENCE (organic attention) with rising Traction (protocol activity) become highest-priority signals.

**Cohort 04+** — Partner ecosystem dashboards. The architecture established with the Aeon Framework ecosystem partnership generalizes to additional Base ecosystems. Each partner ecosystem gets a curated dashboard with the same engine quality. Partner-driven analyses count separately in the engine's spend tracking and may operate under different access models.

The roadmap is illustrative, not contractual. Features ship when they meet quality thresholds and operator usage justifies them. Features that fail validation in beta will be reworked or removed rather than shipped broken.

This section is deliberately strong. Operators should read it.

11.1 $WAKE Is a Utility Token

$WAKE is a utility token that grants access to the WAKE intelligence terminal. It is not an investment, a security, a derivative, a fund interest, or a claim on any project's revenue, assets, or profits. Holding $WAKE entitles the holder only to access the corresponding tier of WAKE's terminal modules.

The token has no inherent value beyond this access. Its market price is determined entirely by buyer and seller behavior on Base DEXes. WAKE's developers make no representations about future price, future demand, or future utility of the token. Markets may price the token at zero. Markets may price the token at any number. This is the nature of an open market for a utility token.

11.2 The Engine Is Not Financial Advice

Every analysis produced by WAKE ends with "NFA." (Not Financial Advice). This is not boilerplate. It is the most important statement the engine makes about itself.

The engine analyzes data and produces interpretations. It does not predict prices. It does not recommend trades. It does not endorse projects. It does not warrant accuracy. Operators reading WAKE analyses are responsible for their own financial decisions and their own due diligence. WAKE is an input to that process, not a replacement for it.

A high WAKE score does not mean a token will go up. A low WAKE score does not mean a token will go down. A clean Exit Detector report does not mean a token is safe. A CONVERGENCE flag on Pulse Check does not mean an entry is profitable. The engine's outputs are observations about present-state data. They are not predictions. They are not advice.

11.3 Data Sources Can Fail

Every module depends on external data sources: Dexscreener, GeckoTerminal, Etherscan V2, DefiLlama, public Base RPC, and others. These services can be slow, rate-limited, partially correct, or wrong. WAKE attempts to surface these failure modes to operators (status indicators, partial result flags, freshness timestamps), but operators must understand that any analysis is only as accurate as the underlying data.

When data is missing or stale, the engine scores conservatively (neutral 10/20 rather than penalty 0/20), but operators should still treat such analyses as lower-confidence.

11.4 The Engine Improves Through Use

Some of the engine's signals improve with more analyses (the shared cache, the accumulated history of analyzed tokens, the deployer reputation calibration). This means early operators may see analyses that are technically correct but lack some context that later operators will benefit from. This is a feature of the network effect, but it is also a limitation operators should know about.

11.5 Smart Contract and Custodial Risk

WAKE's terminal does not custody operator funds. Operators interact with the terminal as a read-only intelligence layer. However, the $WAKE token contract, the Base network itself, the Bankr/Whetstone infrastructure on which the token is deployed, and the integrations WAKE makes with external services all carry technical risk. These risks are inherent to operating in a permissionless onchain environment.

11.6 No Guarantee of Service

WAKE is operated by a small team. Service may be interrupted, modified, or discontinued. Modules may be paused or removed. Access tiers may be adjusted. Spend caps may be reached, causing temporary feature disablement. The terminal is provided as-is, with no service-level guarantees beyond best effort.

For operators and partners interested in the technical underpinnings:

**Networks and tooling:** - Base (Layer 2 on Ethereum) — primary network - Etherscan V2 unified API (`chainid=8453` for Base) - Virtuals — fair-launch infrastructure used by $WAKE - Clanker — alternate fair-launch protocol detected and supported in scoring

**Data sources:** - Dexscreener API — `https://api.dexscreener.com/latest/dex/` - DexScreener Boosts API — `https://api.dexscreener.com/token-boosts/` - GeckoTerminal API — `https://api.geckoterminal.com/api/v2/` - DefiLlama API — `https://api.llama.fi/` - Public Base RPC and custom RPC endpoints (as configured)

**Standards referenced:** - ERC-20 (token standard) - Uniswap V3 and V4 (LP and pool architecture) - EIP-7621 (token standard authored by team)

**Engine infrastructure:** - Server-side analysis runs on Supabase Edge Functions - Caching layer in Supabase Postgres - Spend tracking in dedicated audit tables - All API keys are server-side; no keys are exposed in the browser

**Bankr / Whetstone Airlock** — Fair-launch infrastructure on Base. Deploys ERC-20 tokens with LP burn on graduation and ownership renouncement enforced by protocol.

**Clanker** — Alternative fair-launch protocol on Base. Deploys tokens through a series of factory contracts; multiple versions exist (v0 through v4.1).

**CONVERGENCE / MANUFACTURED / ORGANIC / NEUTRAL** — Pulse Check flag categories indicating the relationship between organic and paid attention signals.

**Deployer chain inspection** — The process of examining a token's contract creation transaction to identify all contracts and addresses involved in deployment, used to classify launch protocols.

**Engine analysis** — Output of the interpretive layer; a narrative interpretation of deterministic signals, scored on a 0-100 scale with criterion breakdown.

**Flag (Exit Detector)** — A condition that fires when a token's onchain activity matches a specific distribution pattern (e.g., DEPLOYER_DUMP, LP_REMOVAL). Each flag has explicit thresholds and severity levels.

**NFA** — Not Financial Advice. Every WAKE analysis ends with this disclaimer because every WAKE analysis is an observation about data, not a recommendation about action.

**Operator** — A user of the WAKE intelligence terminal. The terminology reflects the engine's positioning as a professional tool rather than a consumer product.

**TVL** — Total Value Locked. The USD value of all assets deposited in a protocol's smart contracts. Reported by DefiLlama, used by Traction.

**$WAKE** — The utility token granting tiered access to the WAKE terminal. Deployed on Base via Bankr/Whetstone Airlock infrastructure.

---

*This document describes WAKE as of May 2026. Modules, scoring methodologies, and access tiers may evolve. Operators should treat this whitepaper as a snapshot rather than a contract.*

*NFA.*