PROJECT OVERVIEW

New assets appear faster than anyone can check them

Emerging on-chain ecosystems create new tokens and markets faster than users can investigate them by hand. A user may see a token with liquidity, volume and social buzz, with no reliable way to understand the contract or market structure behind it.

Discovery is not verification

Seeing a token on a trading screen does not tell you the contract is safe, that selling works, that liquidity is under control, or that the deployer has a clean record. Discovery tools are built to find activity. DexProof adds evidence and context to that activity.

Risk information is scattered

Contract behavior usually has to be checked separately from market data. Liquidity ownership is hard to trace across multiple DEXs. Wallet and deployer history is disconnected from the token on screen. Old verdicts and past behavior disappear as new launches replace them. RWA infrastructure can look structurally identical to scam infrastructure, which creates false alarms without a trusted reference. Getting from discovery to verification to execution today takes several different tools.

AI needs real evidence underneath

An AI interface can explain complex blockchain information, but an AI model should never be the source of truth for a security verdict. DexProof keeps the evidence and verdict engine separate from the conversational AI. The AI explains and investigates evidence produced by the engine; it does not produce verdicts.

Evidence before opinion

The system inspects many dimensions of a token and its market instead of trusting any single signal. Depending on what data is available, the analysis can cover contract behavior, sellability, liquidity custody, holder concentration, who holds admin control, deployer history, funding trail, market activity and other risk signals.

Real-wallet sell simulation

The scanner tests supported sell routes in a wallet context instead of trusting what the contract claims about itself. It reports the routes and conditions it tested. Transfer blocks, taxes and execution failures can differ by route or wallet. An unavailable test stays unknown and never proves a token can be sold.

Liquidity analysis

DexProof inspects who actually controls liquidity across the DEXs on the chain, instead of assuming the most visible pool tells the full story.

Published methodology

The methodology is public. Findings retain their subjects, measurements and evidence, so users can inspect the basis for a conclusion.

Categorical interpretation

The R2 categorical policy is implemented behind a receipt-writing switch that is off by default. In that policy, ordinary findings carry danger, caution or none. The tier follows the worst effect and named critical rules. Warnings do not pile up. Coverage is reported separately and can limit publication. The earlier receipt writer remains the default until an explicit cutover. It records methodology version 2.0.1.

Handling incomplete information

When evidence cannot be read, or some scoped checks cannot be checked reliably, DexProof says so instead of quietly assuming the best. A conclusion based on partial data is labeled as partial. An unanswered question is never published as a clean bill of health.

Why the Ledger matters

• ▪It keeps the history of what DexProof concluded, and when.
• ▪It creates accountability around methodology versions and evidence.
• ▪It lets users revisit earlier assessments instead of relying on screenshots.
• ▪It builds the base for independently verifiable historical intelligence.
• ▪It can become an API-accessible reputation and research dataset.

Night Market

The Night Market removes the need to monitor many launchpad pages and browser tabs. DexProof aggregates launch activity and surfaces launches that cross defined traction conditions, ranked by their progress.

The Night Market is live today. Its coverage grows as more launchpads are integrated and explorer data becomes more reliable.

Two different launch mechanisms

The aggregated launch interface covers two launch mechanisms that users often treat as the same thing.

Type 1: Bonding-curve launches

Some platforms use a true bonding curve: the asset stays on its curve until it reaches a graduation condition, then migrates to a DEX. Live examples on Robinhood Chain include Flap.sh, RobinFun and Pons V2, whose curves graduate into Uniswap V4 pools. These assets have no tradable DEX pair before graduation, so normal DEX discovery misses them completely.

Type 2: Direct DEX listing

Other platforms skip the curve and create a tradable DEX pair at launch. Live examples include Party, which lists directly on Sushi with launch liquidity locked, and CashCat, which lists into Uniswap V4 pools governed by a custom hook. These assets show up in DEX discovery, but they are a different launch architecture with different risks.

The DexProof approach

DexProof aggregates both types instead of only showing assets that already have a normal DEX pair.

For bonding-curve launches, the feed ranks launches by curve progress and traction. The design target is to surface a launch once it crosses 50% of curve progress, which is enough traction to separate real projects from dust. While the ecosystem is young and launch flow is still building, DexProof runs a lower surface threshold (currently 5% of curve progress) so the feed stays useful during this early period. The threshold will be raised to the 50% design target as launchpad coverage and activity grow.

Once a launch has a DEX pool, graduated or listed directly, it can be bought through the DexProof swap without leaving the platform. Tokens still on a bonding curve are not routed until they graduate.

Why aggregation matters

The goal is not to list every token on the chain. The goal is a signal-to-noise layer: find meaningful launches, rank them by real traction, connect each asset to DexProof intelligence, and eventually allow execution without sending users through five different apps.

RWA trading

The RWA Registry is live as an information and verification layer, and verified stock tokens now trade through the DexProof swap. Before a stock token is quoted, the swap checks on chain whether its issuer has paused it, so users go from verification and research to execution inside DexProof.

The product path: Verify → Research → Trade.

Current model: Bring Your Own Key

The current beta lets users plug in their own compatible AI API key. Model usage stays under the user's own provider account, and DexProof provides the intelligence interface without paying the model bill.

What the AI is intended to do

• ▪Explain a token's Verdict in more depth.
• ▪Answer questions about the evidence behind a verdict.
• ▪Investigate contract and wallet relationships.
• ▪Analyze RWA structures and related assets.
• ▪Answer broader questions about coins and on-chain infrastructure.
• ▪Help users explore information across DexProof products.

Future monetization

DexProof plans to offer DexProof-managed AI access for users who do not want to bring their own keys, built around subscriptions, usage credits or both. Over time the AI layer is meant to support multiple specialists and tool-driven workflows, not one generic chatbot.

MCP and external agents

DexProof's internal AI tooling already runs on an MCP-style tool registry in production. External access, meaning DexProof intelligence exposed to third-party AI agents and platforms through MCP and similar interfaces, is planned. This extends distribution from human users to software agents that need structured blockchain intelligence, while verdicts, evidence and methodology stay owned by the deterministic engine.

Telegram

A Telegram bot is planned as a future distribution channel: a lightweight way to call the scanner on demand, free of charge. Scope and design are still being planned.

Core concept

Users take a Yes/No position on whether a token will reach a set price or market-cap condition at a set date and time.

Example: "Will the market cap of a specified token be above $50 million at 8:00 PM UTC on a defined date?"

Market lifecycle

1. 1.A creator defines a prediction and its settlement rules.
2. 2.Users take positions on the outcomes.
3. 3.When the market closes, positions are locked.
4. 4.At the target time, an oracle fetches the agreed market data.
5. 5.The isolated market contract decides the winning outcome.
6. 6.Fees are charged according to the market's configuration.
7. 7.The rest of the pool is paid to the winning side.

Creator economy

Creators can build and promote markets to their own communities, linking out to X, Telegram, Discord or other community destinations. Creators get an economic reason to make useful, engaging markets, and DexProof gets a distribution channel.

Fee model

Creator and platform fees are each configurable from 0% up to 5%, for a combined maximum of 10% when both are at maximum. Markets can also carry a creation fee of up to 0.001 ETH per market, set by configuration. The exact fees on a given market therefore depend on its creator and platform configuration; the remainder goes to winning participants.

Isolated contracts

Each prediction market runs in its own isolated contract, so a problem in one market does not automatically expose the others.

Manipulation controls

Prediction markets create an obvious incentive to push the underlying asset around settlement time. RobinBets therefore requires guardrails on eligible assets, data sources, settlement rules, liquidity and other market parameters. The goal is to reduce manipulation, not to assume an oracle alone solves it.

Oracle design

Settlement uses predefined external market-data sources and oracle infrastructure. The final implementation needs fixed source selection, timestamp rules, fallback logic and protection against abnormal or manipulated data.

The DexProof swap

The swap is live. It trades through the same Uniswap V2, V3 and V4 pools as everyone else, through Uniswap's own router, and adds a set of checks around each trade:

• ▪Tested before you sign. Every trade is run on chain as a simulation from the user's own wallet before the swap can be signed. It measures what the user would actually receive, and that the router kept nothing.
• ▪Security inside the swap. A quick check of the contract's owner, pause and proxy settings runs on review. If the token has been scanned, its verdict and findings sit beside the trade.
• ▪A reason, not an error. When no route exists, the swap reads the token's main pools on chain and says why, for example that liquidity was pulled while other sites still list it.
• ▪Hidden costs surfaced. Pools charging far above the usual 1% fee have that fee counted as price impact, and large losses need an explicit confirmation.

Swaps are non-custodial: the trade is sent from the user's own wallet.

Launchpad token trading

Tokens that have reached a DEX pool trade through the same swap, so the user keeps the intelligence context of the asset being traded. Coverage of more launch mechanisms is in development.

RWA trading

Verified stock tokens trade through the same swap. Trading is an extension of the registry, not a separate product cut off from verification.

The user flow

Discover → Scan → Review evidence → Trade.

Core scanner as a public good

Keeping the core scan free is deliberate. The scanner serves the whole ecosystem by making risk information accessible. Monetization sits on optional services and financial infrastructure built on top of that intelligence.

AI monetization

The AI layer earns through subscriptions, usage credits and access to DexProof-provided model capacity. Users who prefer their own keys keep using BYOK.

Transaction monetization

Trading and prediction markets create usage-based revenue. Unlike a pure analytics business, DexProof can earn when users move from analysis to action.

External distribution

MCP, APIs and direct integrations let other products and agents consume DexProof intelligence as infrastructure, spreading revenue beyond direct end-user subscriptions.

Potential utility

• ▪Access and utility across premium DexProof features.
• ▪AI and agent-related usage mechanisms.
• ▪Potential access to advanced services or platform tiers.
• ▪Future ecosystem incentives.

Revenue-based token alignment

DexProof intends to consider allocating up to 50% of eligible platform revenue toward a mix of token buyback-and-burn and/or future staking-based revenue distribution, subject to feasibility and the final economic design.

Where buybacks happen, acquired tokens may be permanently removed from circulation by sending them to a designated irrecoverable address. The intended effect is to tie a portion of platform usage to token supply reduction. No increase in token price or market value is promised or guaranteed.

Potential staking

Staking-based revenue distribution is a possible future mechanism, not a guaranteed entitlement. If introduced, it would be subject to the economics, technical implementation and legal considerations at that time.

Transparency

DexProof intends to publish reports for buybacks, burns and any revenue-distribution mechanism it implements, so token-related activity can be audited rather than taken on trust.

Platform snapshot

Status by area

Completed / live foundation

Core Verdict scanner; evidence-backed assessment methodology; historical Ledger; wallet and deployer intelligence; Night Market; aggregated launchpad with live bonding-curve and direct-listing coverage; Ecosystem; Trusted RWA registry; Robin Knight BYOK beta.

Next development priorities

Expand launchpad aggregation and data coverage; finish wrapper-based trading infrastructure; advance Ledger on-chain anchoring; build paid AI access and usage-credit architecture; open MCP access to external agents; grow AI distribution, including the Telegram scanner bot; build RobinBets prediction-market infrastructure.

Later-stage expansion

Verdict and intelligence APIs; broader B2B integrations; more premium services; ROBINCALLS token launch and finalized token utility; possible buyback/burn implementation; possible staking-based revenue distribution; expansion to additional EVM chains.

Smart-contract risk

Trading wrappers, prediction markets and future token mechanisms carry smart-contract risk. These systems need isolated contract design, testing, monitoring and, where appropriate, independent audits before production use.

Oracle and data-source risk

Automated settlement and market intelligence depend on external data. Source selection, timestamp rules, fallbacks and anomaly handling are critical.

Market manipulation

Meme-coin markets can be thin and highly volatile. Prediction markets add an incentive to push prices around settlement. Eligibility criteria, liquidity thresholds, settlement windows and other guardrails are required.

False positives and false negatives

No automated scanner is perfect. DexProof leans on evidence, a published methodology, stated limitations and version history without presenting a verdict as a guarantee. Published verdicts can be contested directly through the DexProof Telegram community: a contest triggers a code-level review, corrections are published in the methodology, and a rescan settles the record. A wrong honeypot mark is removed after verification.

Adversarial adaptation

Scammers adapt. Once a detection pattern is public, contracts can be written to dodge it, and any fixed list of checks decays over time. DexProof treats its methodology as a living, versioned system: checks are added and tightened continuously, old verdicts stay tied to the version that produced them, and the Ledger keeps what was known at the time instead of quietly upgrading the past.

AI risk

AI explanations can be incomplete or wrong. The architecture limits the AI's role by grounding it in DexProof evidence and methodology. Users should still verify important claims.

Third-party infrastructure

Explorer APIs, DEX data, RPC infrastructure and other external services can fail or disagree. Data-source reliability is an ongoing development dependency.

Regulatory uncertainty

Trading, token mechanisms, prediction markets, staking and revenue distribution carry different legal implications in different jurisdictions. Final implementations should be reviewed with qualified legal counsel before launch.

Token risk

The ROBINCALLS token is deployed on Robinhood Chain. Its economics, liquidity, utility and market behavior are uncertain. No value increase is guaranteed.

Ecosystem concentration

The initial focus on Robinhood Chain creates a concentrated dependency on the growth of that one ecosystem. Multi-chain expansion is a future option, not a current assumption.