VibeCheck Product and Token Utility Whitepaper

Product Purpose

Modern websites often combine human design, generated code, site builders, AI-written copy, and later manual edits. Once deployed, the public site usually does not preserve a complete development history. Crypto project review adds another problem: token metadata, project imagery, social identity, and website implementation often live in separate places. VibeCheck brings those public signals into a single inspection workflow.

VibeCheck is intended to answer a narrow question responsibly: what observable signals suggest that AI or an AI-enabled builder contributed to this website or project asset? The answer is presented with evidence, confidence, and limitations. It is not a binary declaration of human or machine authorship.

Design Principles

Intended Users

• Developers and agencies comparing implementation patterns across public websites.
• Founders and researchers studying adoption of AI-enabled website builders.
• Crypto users reviewing the public identity of a Solana token project before making their own decision.
• Project teams that want an explainable report about the signals visible in their public assets.

Non Goals

VibeCheck is not a vulnerability scanner, smart-contract audit, fraud detector, identity verification service, or investment rating. It does not guarantee that a project is safe, legitimate, original, or profitable.

The product uses a common inspection pipeline. Inputs are validated, public content is collected within strict limits, specialized engines extract signals, and a scoring layer produces an explainable report. Website Scanner and CA Inspector share this pipeline but use different inputs and access rules.

VibeCheck System Overview

Public inputs pass through safety controls before evidence is scored and reported.

Report Structure

• Input and scan type, including the normalized URL or contract address.
• AI likelihood and confidence when the scan supports those fields.
• Possible builder, framework, hosting, and technology indicators.
• Evidence items with a plain-language explanation and a strength rating.
• Limitations, missing sources, scan timestamp, and engine version.

Result Language

Basic Scan

A Basic Scan accepts a public HTTP or HTTPS URL and analyzes the homepage. Each connected wallet receives one Basic Scan during each rolling 24-hour period. The report includes a basic AI likelihood estimate, a possible builder, detected technologies, the strongest evidence items, and limitations.

Premium Scan

A Premium Scan uses one scan credit and performs a deeper inspection. The intended launch configuration analyzes the homepage and up to four additional pages on the same origin, subject to availability and safety limits. It expands builder fingerprinting, technology detection, visual analysis, and evidence coverage.

Website Signals

• Generator metadata, public builder badges, and explicit platform markers.
• HTML comments, script and stylesheet paths, asset domains, and bundle strings.
• Framework, hosting, deployment, and structured data indicators.
• Repeated component, layout, and copy patterns used as supporting evidence only.
• Image provenance or media indicators when the public asset provides usable data.

Website Scanner Limits

A public deployment can hide or remove its original source, generator metadata, repository history, and build process. A human can use AI for only part of a site, and an AI-generated starting point can be heavily rewritten. The Website Scanner therefore estimates likelihood from the available evidence and never labels a site definitively human-made.

CA Inspector accepts a public Solana contract address and builds a project-level report from the public information associated with that address. At launch, the feature is free and does not consume Website Scanner credits.

CA Inspector Flow

One public Solana address produces a combined project inspection.

Inspection Steps

1. Validate the submitted Solana address and request public on-chain token metadata.
2. Retrieve referenced public metadata when it is available and safe to access.
3. Evaluate the token image for signals associated with AI-generated imagery.
4. Evaluate the linked X profile picture when a public image is available.
5. Run a Website Scanner inspection when the metadata includes a public website.
6. Combine the results with source availability, confidence, evidence, and limitations.

CA Inspector Output

• Token name, symbol, public metadata fields, and referenced links when available.
• AI-generation signal estimates for the token image and linked X profile picture.
• Website builder and vibe-coding signals for the linked public site.
• A record of missing, inaccessible, or invalid sources so the report does not imply complete coverage.

CA Inspector Boundaries

CA Inspector does not audit token code, liquidity, holder concentration, transfer restrictions, authorities, or trading risk unless those capabilities are separately implemented and disclosed. A favorable media or website result is not evidence that a token is safe. It is not a smart-contract audit, fraud detector, safety rating, or investment recommendation.

Evidence Hierarchy

A high score should require either direct evidence or several independent technical signals. Heuristic appearance alone should not produce a high-confidence result. Conflicting signals lower confidence and appear in the limitations section.

Scoring Process

1. Normalize the input and collect permitted public sources.
2. Run deterministic fingerprint rules and record every matched rule.
3. Run supporting media or pattern classifiers where applicable.
4. Apply source reliability, signal strength, and conflict adjustments.
5. Map the combined result to a likelihood range and confidence label.
6. Generate a report that lists evidence and limitations beside the result.

Calibration and Versioning

The scoring engine should be versioned. Each release should be tested against known builder examples, manually created sites, mixed-origin sites, and altered deployments. VibeCheck should track false-positive disputes, false negatives found through verified provenance, and accuracy changes when builder signatures evolve. Public reports should record the engine version so results can be interpreted in context.

Corrections

Site and project owners should be able to submit provenance evidence or report an incorrect association. Corrections should update the fingerprint registry only after review. The product should preserve a distinction between user-supplied claims and independently verified evidence.

Application Components

Scan Lifecycle

1. Receive an authenticated or rate-limited request.
2. Normalize and validate the URL or contract address.
3. Apply network safety checks before every fetch and redirect.
4. Collect public content within time, size, and page limits.
5. Run extraction and analysis engines.
6. Create a versioned report and charge a credit only when the premium scan is accepted for processing under the published policy.

Operational Reliability

The production service should use structured logs, request identifiers, scan status transitions, retry limits, and explicit failure messages. A partial result must identify which sources failed. The service should not convert a missing source into a negative finding.

URL Fetching Controls

• Allow only public HTTP and HTTPS targets.
• Block loopback, private, link-local, and other non-public IPv4 and IPv6 ranges.
• Reject embedded credentials, unsupported protocols, and disallowed ports.
• Resolve and revalidate every redirect destination before continuing.
• Use strict redirect, time, response-size, and page-count limits.
• Apply rate limits by wallet, account, IP risk signals, and service capacity.

Wallet and Payment Controls

Premium credits must be issued only after server-side verification of the Solana transaction. Verification should confirm transaction finality, the official $VIBE mint, the treasury destination, the paying wallet, the transferred raw amount after token decimals, and the uniqueness of the transaction signature. Credit issuance and purchase recording should be atomic to prevent double crediting.

Application and Data Controls

• Keep API credentials and RPC keys in server-side secret storage.
• Treat the browser as untrusted and repeat critical authorization checks on the server.
• Use row-level policies so users can access only their own private scan and purchase records.
• Expose only selected fields when a user creates a public share link.
• Record rule and engine versions to support incident review and reproducibility.

Abuse Considerations

The service must discourage bulk scraping, harassment, and attempts to scan internal systems. Rate limits, blocked target classes, source caps, and account controls protect both the service and third-party sites. Public reports should describe technical evidence without accusing an owner of deception or misconduct.

Access and Scan Credit Model

Three access paths serve quick checks, deeper reports, and token project inspection.

Basic Website Access

Each connected wallet receives one Basic Website Scan per rolling 24-hour period. Wallet-based limits reduce casual abuse but do not eliminate multi-wallet behavior. Additional risk controls may be used when necessary, provided they are applied consistently and disclosed in the product terms.

Premium Credits

The launch scan pack contains 10 premium credits for 1,000,000 $VIBE. A premium scan consumes one credit. Credits represent service access and do not represent ownership, revenue share, or a claim on treasury assets. The product should display the exact token amount, number of credits, and receiving address before a wallet signs a payment.

CA Inspector Access

CA Inspector is free at launch and does not consume scan credits. Its rate limits may differ from Website Scanner limits because it depends on public Solana and linked metadata sources. Any future pricing change should be announced before it takes effect.

Credit Policy

• Credits should be deducted through a single server-controlled transaction.
• A failed scan should follow a published refund or restoration policy based on when processing failed.
• Purchased credits should not expire unless an expiration rule is disclosed before purchase.
• Pricing changes should not reduce credits already recorded in a user account.

Current Utility

$VIBE is the access token for premium VibeCheck scans. Its defined launch utility is limited and concrete: users may transfer the published amount of $VIBE to receive premium scan credits. The token does not provide equity, ownership, profit rights, guaranteed access to future products, or governance rights unless a later specification explicitly adds those rights.

Utility Lifecycle

1. The user connects a supported Solana wallet.
2. The application shows the official mint, treasury destination, token amount, and credits to be issued.
3. The user approves the transfer in the wallet.
4. The server verifies the finalized transaction and rejects a reused signature.
5. The database records the purchase and adds 10 premium scan credits atomically.
6. The user spends one credit for each completed premium Website Scan under the published credit policy.

What the Utility Does Not Promise

Product demand may create demand for service access, but VibeCheck makes no statement that token value will increase. The whitepaper does not define price support, yield, dividends, buybacks, burns, staking returns, or revenue sharing. Those mechanisms should not be inferred from the scan credit model.

Pricing Changes

The 1,000,000 $VIBE scan pack is a launch configuration. Token price volatility and service costs may require later adjustment. Any change should be versioned, announced in advance, displayed before payment, and applied prospectively.

Published and Unpublished Parameters

Required Treasury Disclosures

Before broad token-based access is promoted, VibeCheck should publish the official mint address, treasury address, signer structure, authority status, and policy for tokens received through scan packs. If treasury funds support hosting, model inference, development, audits, liquidity, or other activities, the policy should distinguish those uses and explain the approval process.

Change Management

The operator currently controls product and pricing parameters. Token ownership does not imply a vote. Material changes to scan pricing, credit quantities, report scope, treasury routing, or token rights should receive a dated specification update and an effective date. Existing credits should remain valid under the terms shown when they were issued unless the user agrees otherwise.

Data Scope

VibeCheck is designed for public data. Website scans should fetch only public pages. CA Inspector should use public Solana metadata and public linked images or sites. The product should not request private keys, seed phrases, website credentials, or access to private repositories.

Data Minimization

A production deployment may need to store the normalized input, result, evidence, timestamps, engine version, wallet address for allowances, credit balance, and transaction signature for purchase verification. The service should avoid retaining raw fetched content longer than operationally necessary and should publish a retention and deletion policy.

Responsible Result Presentation

• Describe results as likelihoods and signals rather than accusations.
• Show the strongest contrary evidence and missing sources when relevant.
• Provide a correction channel for site and project owners.
• Do not rank projects by safety or investment quality without a separately defined and validated methodology.
• Prevent public share pages from exposing private account, wallet, or purchase information beyond what the user deliberately shares.

Third Party Services

Some reports depend on Solana RPC providers, website hosts, public X images, and other external services. Their availability, terms, and response formats can change. VibeCheck should identify unavailable sources rather than silently substituting a conclusion.

Detection Is Not Provenance

Reliable provenance normally requires signed metadata, source history, repository access, builder attestations, or other first-party evidence. VibeCheck usually sees the public output instead. Its reports should help users investigate, not replace provenance.

CA Inspector Is Not Due Diligence

CA Inspector does not determine whether a token contract is safe, whether liquidity can be withdrawn, whether holders are concentrated, or whether a project team is genuine. Users who trade tokens need separate contract, market, ownership, and legal review.

Current Product Scope

• Public Website Scanner with one basic allowance per connected wallet every 24 hours.
• Premium Website Scanner credits purchased with $VIBE under the launch scan pack configuration.
• CA Inspector for public Solana metadata, token and X image AI signals, and linked website vibe checks.

Near Term Priorities

• Expand and version the builder fingerprint registry.
• Publish calibration results and improve confidence explanations.
• Add scan provenance fields, engine versions, and source availability summaries.
• Implement owner correction and evidence submission workflows.
• Publish treasury, token parameter, privacy, and failed-scan credit policies.

Later Product Options

• Historical report comparison to show how a public project changes over time.
• API access for developers and research teams.
• Community-submitted fingerprints with review, versioning, and abuse controls.
• Additional project metadata modules only after their scope and limitations are documented.

The roadmap intentionally does not assign delivery dates. Features should be announced as committed only after the required data sources, security review, and operating capacity are confirmed.

VibeCheck should publish targets only after a baseline period produces enough data to set meaningful thresholds. A high scan count alone is not a quality measure. Accuracy, evidence coverage, reliability, and correction handling matter more.

VibeCheck provides an explainable inspection layer for public websites and Solana token project assets. The Website Scanner looks for builder, technology, and AI-assistance signals. CA Inspector connects public token metadata, project imagery, and the linked website in one report. Both products keep uncertainty visible and avoid treating appearance as proof.

$VIBE has a defined product role through premium Website Scanner credits. The launch configuration offers 10 premium credits for 1,000,000 $VIBE, while CA Inspector remains free and consumes no credits. This utility does not imply investment rights or future value.

The next disclosure obligations are concrete: publish the official mint and treasury details, define supply and allocation, document failed-scan credit handling, release methodology benchmarks, and maintain a correction process. Completing those items will make the product and token model easier to evaluate on their actual operation.