DEALFLOWIST / WHITEPAPER · V1.0

The intelligence layer for early onchain dealflow.

Dealflowist is building an evidence-first discovery, research and execution layer for early crypto projects — starting on Robinhood Chain.

RADAR · DISCOVERY ENGINEDLFW · PROTOCOL TOKENPROTOCOL ECONOMICS V1

Discovery · Research · Market structure · Future execution

No presale. No VC allocation. No founder premine.

Read the thesis Protocol economics Follow on X ↗

Independent project. Not affiliated with or endorsed by Robinhood.

01 / Thesis / the discovery problem

Most discovery starts too late.

Conventional discovery and ranking systems are built on quantities that only exist after a market has already formed: traded volume, social attention, established liquidity depth, follower counts and wallet activity that is already visible to everyone querying the same public indexes. These are lagging measurements. By construction, they rank what the market has already noticed.

Dealflowist starts earlier. It treats the first observable evidence of a project — the deployment, the pool, the first swap, the first commit, the first credible follower — as a sourcing problem rather than a ranking problem. The objective is not to score popularity faster, but to observe and structure evidence at the point where it first exists onchain and offchain, and to record it immutably at that moment.

Conventional discovery

—Traded volume
—Social attention
—Established liquidity
—Known wallets

Radar

›Pool creation
›First swaps
›Launch microstructure
›Developer traces
›Wallet provenance
›Early social graphs
›Testnet → mainnet signals

02 / Core doctrine

Discovery ≠ Conviction ≠ Execution.

Three distinct questions are frequently collapsed into one score. Dealflowist separates them, because each answers a different thing and each fails differently.

Discovery

Something worth investigating has been observed. It is a claim about attention, not quality.

Conviction

Independent evidence has accumulated across multiple families of signal that do not share a single source of error.

Execution clearance

Security, liquidity, admin and execution conditions are acceptable enough to allow an execution path to exist.

Separating the three has a practical consequence. Missing evidence lowers confidence without hiding a discovery: a project with no repository, no verified source and no wallet history is not removed from research — it is displayed with the uncertainty it actually carries.

Symmetrically, a blocking security flag can prevent execution without erasing the underlying project from research. The record of what was observed, and when, remains intact regardless of whether an execution path is ever opened.

03 / Radar signal stack

Eight independent families of evidence.

Radar collects evidence in parallel across eight modules. Each module is recorded separately with its own timestamp and confidence. No single signal decides the outcome.

Onchain discovery

Continuous observation of new contracts, deployments and pool creation events at the moment they land onchain.

DEX / first-minute microstructure

First swaps, trade cadence, buyer dispersion and the shape of the opening minutes of a market.

Liquidity & market structure

Depth, pool composition, lock and ownership state, and how liquidity behaves under real flow.

Supply / admin controls

Mint authority, upgradeability, blacklist and fee switches, and concentration of controlling addresses.

Developer & GitHub activity

Repository existence, commit cadence, contributor continuity and whether code matches the claimed product.

Security evidence

Automated contract analysis and known-pattern checks recorded as evidence, never as an assurance of safety.

Wallet provenance

Point-in-time history of the wallets appearing earliest, and what they have previously been early to.

Early scout / social graph

Immutable snapshots of who followed, mentioned or interacted with a project before it was widely visible.

04 / Research states

A lifecycle, not a verdict.

Detected→Under Review→Verified Project→Trade Cleared→High Conviction

Risk BlockedOrthogonal state

Detected: Candidate discovered; insufficient proof to justify further weight.
Under Review: Enough evidence has accumulated to justify deeper research.
Verified Project: Real product or project evidence corroborated across sources.
Trade Cleared: No blocking automated security flags detected. Never a guarantee of safety.
High Conviction: Strong weighted evidence across product, builders, code, onchain activity and ecosystem fit.
Risk Blocked: The project remains visible in research; execution clearance is withheld.

No state describes a project as safe.

05 / Early graph / scout reputation

Who consistently arrives before everyone else?

Dealflowist records immutable point-in-time observations: who followed a project account at a given block or timestamp, which wallets transacted in the opening minutes, and which addresses interacted with a contract before it was widely indexed. These records are written once and never rewritten, which makes hindsight impossible.

Over many projects, the system learns which accounts and wallets repeatedly appear early on projects that later accumulate independent evidence of substance. Reputation is therefore derived from repeated, verifiable earliness — not from follower count, perceived influence, or paid placement of any kind.

Illustrative sequence · conceptual, not performance data

T+00:00Contract deployedFirst observation recorded
T+00:04Liquidity pool createdMarket structure captured
T+00:06First swapsEarly wallet set snapshotted
T+02:11Scout follow observedPoint-in-time edge written
T+18:40Repository activityDeveloper evidence attached

06 / Product architecture

Intelligence first, execution downstream.

RADAR→RESEARCH→LAUNCHPAD→EXECUTION SURFACES

Dealflowist

One evidence pipeline; each surface consumes the layer above it.

01RADAR

Discovery, Flash, project passports, wallets, scouts and alerts. The sourcing engine that everything else depends on.

02RESEARCH

Conviction scoring, the evidence ledger, security analysis and market-structure review, built on top of Radar output.

03LAUNCHPAD

A planned curated downstream surface for launches, only after a project independently qualifies through research. Placement is never pay-to-rank.

04EXECUTION SURFACES

Planned self-custodial execution paths, exposed only where an execution route has been explicitly cleared and is technically available.

DLFW · access & participation layer

DLFW sits alongside this stack as an access and participation layer, not as the final step of the product. The intelligence layer is the product; the token coordinates access to it and routes protocol economics.

Intelligence comes first. Monetization is downstream of useful intelligence.

Launchpad placement is not pay-to-rank. A project cannot purchase visibility, ordering or clearance at any layer of the stack.

07 / Protocol economics V1

DLFW — Fair-launch architecture.

DLFW is a fixed-supply token intended to launch entirely into the public market. There is no presale, no venture allocation and no premine of any kind — no founder, team or treasury tranche is created before the market opens. Initial circulating supply and valuation are discovered by the fair-launch curve and the market, not set by a private allocation table.

TokenDealflowist (DLFW)

Fixed supply1,000,000,000 DLFW

Preferred launch pathPons V2 fair launch on Robinhood Chain

Public / fair launch100%

Presale0%

VC allocation0%

Founder premine0%

Team premine0%

Treasury premine0%

Hidden private allocationNone

The creator and founder can only acquire DLFW by buying publicly with their own funds, under exactly the same market rules as anyone else. Any such purchase should be disclosed.

Liquidity is intended to be created by the fair-launch mechanism itself and locked at graduation according to the selected live Pons V2 launch configuration. Pons V2 is described here as the preferred launch infrastructure, not as a partnership.

Ordinary wallet-to-wallet DLFW transfers are not intended to carry a Dealflowist tax.

Revenue comes from activity, not from allocating a founder bag before the market opens.

Holding DLFW does not confer equity, debt, legal ownership, or a contractual claim on company revenue. No price, valuation or return is stated or implied anywhere in this document.

08 / Founding Circle

Pre-registration without custody, allocation or price.

Before launch, supporters may connect a wallet and sign a free message indicating interest. The flow is non-custodial: no funds are collected, no token allocation is reserved, and no launch price is guaranteed. At launch, everyone buys through the public fair launch under the same market rules.

Qualification

A wallet becomes a Founding Supporter if it was pre-registered before launch and later holds a qualifying DLFW balance for a minimum qualification period. The exact threshold will be finalized and published before activation.

Benefits

Temporary Founding Beta access, an early product feedback channel, and early feature access where applicable. The badge itself carries no financial reward.

Non-custodial by design

Registration is a signed message only. Dealflowist never takes custody of supporter funds at any point in this process.

No manufactured scarcity

If only a small number of wallets pre-register, that is simply what it is. Dealflowist does not fabricate scarcity or social proof.

09 / Trading fee policy

A disclosed maximum all-in fee of 3.00%.

Dealflowist targets a maximum all-in trading fee of 3.00% on the canonical DLFW market, excluding any temporary anti-snipe mechanics imposed by the launch infrastructure at the moment of launch.

The exact creator fee is set only after reading the live Pons V2 launch configuration, such that the Pons base fee plus the DLFW creator fee is at most 300 bps. If a suitable live launch configuration cannot satisfy that policy, Dealflowist should not launch under that configuration.

The creator fee is intended to be fixed at launch under the chosen infrastructure, and not silently increased afterwards. The fee is disclosed, not hidden.

Fee policy constraint

Pons base fee + DLFW creator fee ≤ 300 bps (3.00% all-in)

This is not a fee-on-transfer ERC-20 mechanic. The preferred Pons route keeps the economics at the launch and pool layer rather than taxing ordinary wallet-to-wallet transfers.

10 / Dealflowist Revenue Router

60 / 20 / 10 / 10.

All net Dealflowist protocol revenue routed to the canonical Revenue Router is allocated across four buckets. This split applies to the Dealflowist share of creator and protocol economics, and is the target routing policy for future product revenue streams where technically and legally feasible.

60%

Radar Rewards Vault

Funds holder rewards in external assets, subject to eligibility, liquidity, research and legal gates.

20%

Dealflowist Treasury / operations

RPC and indexing, infrastructure, data, security, engineering, operations, compliance and legal review, and reserves.

10%

Founder

Transparent compensation tied to protocol and product revenue instead of a premine.

10%

Community & Prize Vault

Research and scout bounties, bug bounties, builder and community challenges and performance-based programs. No fixed-dollar prize pool is promised; the vault accumulates only with actual revenue.

Community & Prize Vault programs are performance- and contribution-based, never games of chance.

The founder earns when Dealflowist earns.

11 / Radar Rewards Vault

Rewards in external assets, gated by execution reality.

The Radar Rewards Vault receives 60% of routed net protocol revenue and is designed to distribute rewards in external assets to eligible DLFW holders. Reward epochs target a weekly cadence. No yield or return is promised, and no outcome is guaranteed.

Eligibility is based on an average, time-weighted DLFW balance across the epoch; the threshold is to be finalized and published before activation. There is no single end-of-epoch snapshot; accounting is designed to be time-weighted and manipulation-resistant. Technical, system, treasury and pool addresses are excluded.

Rewards are intended to be claimable in kind rather than automatically dusted to every wallet, with a target claim window of 90 days. Treatment of unclaimed rewards will be disclosed in the final contract documentation.

VAULT ALLOCATION TARGET

70%

Radar Sleeve

Buys up to five qualifying early crypto projects selected by Radar — fewer, or none, if fewer pass the required research, security and execution gates.

20%

RWA Sleeve

Eligible tokenized real-world assets or other permitted structured assets available on Robinhood Chain, only where transfer and eligibility rules permit.

10%

Reserve

WETH, USDG or a comparable reserve asset, including any allocation that was not executed.

The Radar 5 concept names the shape of the sleeve, not a quota: the system is never forced to buy exactly five assets. If a selected token is too illiquid, unsafe to execute, unsupported, or would exceed the configured market-impact or liquidity limit, no purchase is forced and the allocation remains in reserve.

Radar conviction does not override execution constraints.

Shadow mode first

Before any real-money holder distribution, the system runs in shadow mode: weekly selections and their outcomes are recorded immutably and tracked over time. Losing selections are never deleted. Real rewards begin only after security, legal and revenue gates are satisfied.

RWA SLEEVE

RWA exposure is part of the rewards diversification design, not part of the core product thesis. The sleeve uses whichever eligible onchain or tokenized assets are technically and legally transferable to the eligible holder set at the time.

Assets carrying transfer, KYC or eligibility restrictions may be excluded, or held in reserve, rather than distributed to ineligible wallets. Dealflowist does not need, and does not claim, any third-party relationship or agreement for this sleeve.

12 / Product revenue stack

The creator fee is one source, not the business.

Dealflowist is designed as a product business rather than a token-volume business. The token creator fee is a single line in a broader revenue stack. Each source below is planned or future, and subject to security, legal and product gates.

Planned integration

SCOPL referral / partner revenue

Eligible referral or partner revenue for pools SCOPL supports, through its public API. Dealflowist does not intend to add an extra market-order fee purely to force monetization.

0% interface fee at V1

Spot execution inside Dealflowist

Users remain self-custodial. The default V1 goal is to keep execution inside the research workflow without adding avoidable friction, not to tax it.

Planned · subject to gates

Perps via external venues

Established external venues only, using eligible affiliate, referral or integration revenue where permitted. No in-house leverage or liquidation engine at V1.

Planned product tiers

Radar Pro / API / advanced data

Deeper history, professional alerts, richer wallet and scout graphs, plus APIs, exports and automation as future paid tiers.

Planned · subject to gates

Launchpad / builder infrastructure

Available only after a project independently qualifies through research. Any launch or service fee pays for infrastructure, never for ranking. No pay-to-rank.

Planned where useful

Builder / data tooling & integrations

Tooling, data access and integrations for builders where they genuinely extend the intelligence layer.

Future net revenue streams are intended to feed the same 60 / 20 / 10 / 10 Revenue Router where feasible, with the exact legal and accounting treatment disclosed before activation.

Radar must remain valuable even if a user never touches the token or an execution surface.

13 / External execution boundary

What SCOPL integration would and would not cover.

Dealflowist plans to call SCOPL’s public API as an external execution provider for supported Uniswap V3 and V4 markets and other pools SCOPL explicitly supports. This is a planned API integration, not a partnership, and no agreement is implied.

Supported

›Pools SCOPL explicitly supports via its public API
›Supported post-launch markets returning a valid route
›UI exposes “Set limit order” only when a valid route exists

Not supported

—Pons V2 tokens still on their bonding curve
—Any market where the external API returns no valid route
—Fabricated compatibility — the UI states limit orders are unavailable

To be explicit: while a Pons V2 launch remains on its bonding curve, it is not routable through SCOPL limit-order execution. SCOPL functionality is shown only for other compatible pools and supported post-launch markets where its API returns a valid route.

14 / Governance & control

Minimal privilege, disclosed control.

01No DAO at launch.
02Operator and treasury controls through a disclosed Safe-style multisig with a timelock where technically relevant.
03Privileged control is minimized wherever the design allows.
04Core economics that can be immutable should be immutable or strongly constrained.
05Any future governance scope will be limited and separately specified.

Holding DLFW does not currently confer equity, debt, legal ownership, or a contractual claim on company revenue.

15 / Founding Beta

Temporary access, then open research.

Access threshold

To be published

Access period

To be announced

After the beta

Open access

Founding Beta is a temporary access window. Its duration and access threshold are operationally defined and published before activation. After it ends, the core Radar research product is intended to become open access.

Wallet eligibility is verified server-side against onchain balances; a signed message proves control of the wallet and access is granted only after that verification. Token holding is an access criterion, not a promise of profit.

16 / Economic flywheel

Each loop should make the next observation better.

This is the intended product flywheel. It describes how the system is designed to compound, not a guaranteed financial outcome.

01Earlier discovery
02Better structured evidence
03More useful research
04More qualified user activity
05Downstream product revenue
06More data, infrastructure and research capacity
07Better Radar

Loop returns to earlier discovery.

Revenue should fund the intelligence layer that creates the revenue opportunity in the first place.

17 / Initial network focus

Starting with Robinhood Chain.

Discovery quality degrades when coverage is spread thin. Every chain has its own deployment patterns, router topology, liquidity conventions and participant behaviour, and a signal that is meaningful on one network is frequently noise on another. Beginning with a single emerging network lets the system be calibrated against real market-specific structure rather than generic heuristics.

Dealflowist therefore focuses initially on Robinhood Chain: a smaller, newer surface where first-observation latency matters most, where the full set of deployments is still tractable to observe end to end, and where evidence models can be validated before coverage is broadened to additional networks.

Dealflowist is an independent project. It is not affiliated with, sponsored by, or endorsed by Robinhood.

18 / Operating principles

The constraints the system is built under.

01Evidence over narrative.
02Point-in-time data over hindsight.
03Missing data is uncertainty, not invisibility.
04Risk can block execution without censoring discovery.
05Radar conviction does not override execution constraints.
06No pay-to-rank.

Find information earlier. Structure it better. Make uncertainty visible.

19 / Roadmap

Sequenced by gates, not by dates.

Phase 01

Radar Core

Ultra-early discovery: DEX deployments, first swaps, launch microstructure, project identity and continuous developer, security and onchain evidence capture.

Gate: signal before surface

Phase 02

Intelligence Graphs

Wallet provenance, the scout graph, outcome learning and project passports built from immutable point-in-time observations.

Gate: evidence depth before interpretation

Phase 03

Public Product & Founding Circle

Public product reliability, monitoring and research UX, plus non-custodial Founding Circle registration by wallet signature.

Gate: reliability before reach

Phase 04

Fair-Launch Readiness

Pons V2 fair-launch readiness on Robinhood Chain: live launch configuration verification, contract and revenue-router rehearsal, and security review.

Gate: verified configuration before launch

Phase 05

DLFW Public Fair Launch & Founding Beta

Public fair launch under the selected live configuration, followed by temporary Founding Beta access for qualifying wallets.

Gate: same rules for everyone

Phase 06

Radar Rewards — Shadow Mode

Immutable weekly selections and outcome tracking with no real-money holder distributions. Losing selections are never deleted.

Gate: track record before rewards

Phase 07

Radar Rewards — Live

Real reward epochs only after revenue, security and legal gates are individually satisfied.

Gate: clearance before distribution

Phase 08

External Execution Routes

Planned SCOPL public-API integration for the markets it supports, plus other external execution routes where a valid route exists.

Gate: valid route before exposure

Phase 09

Product Revenue Surfaces

Radar Pro and API tiers, perps referral integrations with established external venues, and Launchpad/builder infrastructure — each cleared individually.

Gate: cleared surface by surface

Phase 10

Expansion

Broader data and chain coverage only once Robinhood Chain calibration is reliable enough to generalize.

Gate: calibration before coverage

Phases advance on readiness. No dates are implied and no outcomes are promised.

20 / Sustainability / capital allocation

Where treasury revenue goes.

The treasury bucket of the Revenue Router funds the operating base of the intelligence layer. This is an operating philosophy rather than a legal commitment.

Infrastructure

RPC, indexing, storage and the pipelines that keep observation continuous.

Research & security tooling

Analysis capability, monitoring and the tooling research depends on.

Product engineering

The surfaces that make structured evidence usable.

Data acquisition & enrichment

Broader, deeper and better-verified inputs into the evidence layer.

Compliance, legal & security review

External review where a surface or jurisdiction requires it.

Reserves

Continuity and reliability of the product through variable conditions.

Revenue is useful only if it increases the quality, reliability or reach of the intelligence product.

21 / External launch dependencies

What depends on the live environment.

The economics above are the canonical V1 policy. A small number of parameters can only be fixed by reading the live launch and integration environment at the time.

01The exact live Pons V2 launch configuration and its base fee.
02The exact DLFW creator fee required to keep the all-in fee at or below 3.00%.
03Live SCOPL supported-market coverage at the time of integration.
04Actual availability and transfer eligibility of tokenized RWAs on Robinhood Chain.

Each of these is resolved against the live environment and disclosed. None of them changes the fair-launch architecture, the fee ceiling or the routing split.

Radar discovers. Dealflowist executes.

The market can only rank what it can see. Dealflowist is being built to see earlier.

Dealflowist is designed to turn earlier evidence into better decisions, and better decisions into a sustainable intelligence product.

Follow @dealflowistxyz ↗