Chirp is a safety-first Telegram trading bot for Robinhood Chain. It removes the practical barriers that keep everyday users off new chains — wallet apps that do not support the network, manual RPC configuration that fails, DEX front-ends that assume expertise — by making a Telegram chat the entire trading interface. Every buy is preceded by an automated on-chain safety report; every trade routes across Uniswap V2 and V3 for the best executable price; positions can be protected with automatic stop-loss, take-profit and rug-radar auto-exit orders, and entries scheduled with limit "buy the dip" orders. Chirp is loudly custodial (a convenience wallet with disclosed trade-offs, caps and controls), deliberately hostile to market manipulation (no bundling, no sniping, no wash trading — enforced server-side), and funded by a single transparent trading fee that will buy back and burn the $CHIRP token from launch day onward.
Robinhood Chain is an Arbitrum-technology L2 with a fair-markets ethos and near-zero fees. Reaching it as an ordinary user is, today, unreasonably hard: mainstream wallet apps do not list the chain, adding it manually often fails outright, and only after that hurdle can a user even reach a DEX front-end. Most people give up before their first trade.
Chirp's thesis: the messenger already installed on every phone is a better wallet front-end than a wallet app that doesn't know the chain exists. A Telegram bot can create the wallet, watch for deposits, bridge funds from Ethereum, screen the token, quote the trade, execute it, and message you when your stop-loss fires — with zero configuration.
The second half of the thesis is discipline: trading bots historically compete on speed and aggression (snipers, bundlers, multi-wallet fan-outs). Chirp competes on trust — it refuses to build the manipulation features and says so publicly.
| Component | Role |
|---|---|
| Telegram bot (@ChirpTradeBot) | Entire user interface: onboarding, trading, wallets, orders, withdrawals |
| Trading engine | Uniswap V2 + V3 quoting, best-price routing, execution, fee skim |
| Safety report | Pre-trade on-chain screening (Section 4) |
| Keystore | Encrypted-at-rest private keys; PIN-gated sensitive actions (Section 5) |
| Order scanner | 20-second loop evaluating the order suite — stop-loss / take-profit / auto-exit / limit-buy (Section 7) |
| Bridge module | One-tap Ethereum L1 → Robinhood Chain deposits via the canonical bridge |
| Admin console | Operator-only monitoring + kill switch; loopback-bound, 2FA |
| chirptrade.app | Public site: live stats, documentation, $CHIRP tokenomics |
All contract interactions verify themselves at runtime: the V3 router and quoter must prove they belong to the expected Uniswap deployment (factory() cross-check) and the L1 bridge inbox must prove its identity (bridge() cross-check) before funds move. A configuration typo fails loudly instead of trading through a stranger's contract.
Every quote is computed across Uniswap V2 (constant-product pair), Uniswap V3 (concentrated liquidity, all fee tiers — deepest WETH pool selected by actual depth), and Uniswap V4 (singleton pools, native ETH, discovered per token from on-chain Initialize events). The trade executes on whichever venue returns more output. This defeats an entire class of traps: a dust V2 pool can't shadow deep V3 liquidity, and V4 spam pools with absurd fees lose the quote contest to the genuine pool automatically.
V4 hook policy: V4 pools may attach hooks — arbitrary code that can tax, block or redirect swaps. Chirp routes only through hookless pools or hooks on a reviewed allowlist (currently the verified LaunchHood launchpad hook); pools with unreviewed hooks are refused with the reason stated. Notably, hookless is not treated as automatically safe — best-quote routing is what defeats hookless fee-trap pools.
Before any buy, Chirp screens the token on-chain and via the block explorer:
| Check | Signal |
|---|---|
| Source verification | Contract source published and verified on Blockscout |
| Proxy / clone follow | Minimal-proxy clones (EIP-1167, all variants) and upgradeable proxies (EIP-1967 / OpenZeppelin) hold no logic of their own — they delegatecall a separate implementation. Chirp resolves the implementation and verifies that, so a clone is judged by its real code, not an empty shell, and a malicious proxy cannot hide behaviour in code the report never reads. Upgradeable proxies are flagged (the owner can swap the code); clones of recognised launchpads (Doppler, LaunchHood, Fledge) surface as a provenance signal |
| Pool venue + depth | V2, V3 or V4; WETH actually held by the pool; thin/low-liquidity warnings |
| LP burned / locked | V2: % of LP tokens at the dead address. V3: position NFTs owned by the dead address — or by a source-reviewed fees-only locker (e.g. FledgeFeeLocker, which structurally cannot withdraw principal) — are locked forever; Chirp enumerates them and reports the locked share of active liquidity. V4: liquidity ownership is traced through PoolManager events to position NFTs — liquidity held by the dead address or by a source-reviewed fees-only locker (e.g. LaunchHoodLocker) reports as locked; EOA-held liquidity gets an evidence-based pullable warning |
| Pool health | Swap recency ("no trades in the last 30 min" warning), estimated 24h ETH volume (low-volume warning), and pool fee — V4 fee-trap pools charging >1% per swap are flagged |
| Round-trip cost | The report quotes buying 0.01 ETH and instantly selling it back; a low return % (pool fees + price impact) is warned. Honest limit: quoters do pool math, so a token-level transfer tax can still hide — full round-trip simulation remains on the roadmap |
| Deployer bag | Deployer's remaining share of supply |
| Supply allocation | Where the minted supply actually sits: % in the liquidity pool(s) (V2 pair, V3 pool, or the V4 PoolManager balance), % burned (dead-address balances), % still with the deployer, and % loose in other wallets and contracts — so a launch that burned or airdropped half its supply reads differently from one whose entire supply hangs over the pool. A supply-overhang warning fires when the pool holds under 5% of the unburned supply — the fraction of dumpable tokens the pool could actually absorb. Honest limit: burns done by reducing totalSupply are already out of the denominator, so only dead-address burns are visible as "burned" |
| Honeypot check | Router/quoter must be able to quote a SELL |
| Launch-snipe detection | Chirp reads the pool's earliest swaps and measures how much of supply a few wallets net-accumulated (buys minus sells, so flip/sandwich bots that exit net ~0 are not counted) in the first blocks after the launch trade. A launch quietly grabbed by a handful of insiders is exit liquidity regardless of how clean the contract is, so it is flagged SNIPED and caps the transparency grade at ≤ C — this is precisely what lets "launched via Fledge" trust the contract without blindly trusting the distribution. Routers, position managers and the pool itself are excluded so an aggregated/multi-hop buy can never be mistaken for a single sniper. Logs-only and cached (launch data is immutable) |
| Bundle detection | The fragmentation counter to snipe detection. A sniper can split a grab across many wallets so no single one looks large — defeating per-wallet caps and naive top-holder concentration alike. Chirp groups a launch's early buyers by their shared funder (the wallet that sent each its first ETH, normal or internal tx) and treats a co-funded group as one actor, folding the cluster's combined share into the concentration score — so a bundle fragmented across a dozen wallets is scored as the single whale it is, and a large one caps the grade like a snipe. CEX/bridge/faucet hot wallets fund thousands of unrelated users, so a funder with high fan-out is excluded (not treated as a bundler). Best-effort by nature — on-chain funder data is patchy, so a missing funder degrades to no cluster, never a fabricated one; high-precision, and blind bundles funded through invisible paths are the known recall gap |
| Fledge registry | Tokens launched via the Fledge stack carry verifiable guarantees (fixed supply, immutable tax cap) |
| Airdrop quarantine | Unsolicited tokens are collapsed to a single muted count and get no trade buttons. A held token is trusted only by provenance — you bought it through Chirp, or it is a canonical asset — never by a market listing: a mass scam airdrop can carry a real exchange rate, so "listed" is not trust. A scam airdrop must not be legitimised by the UI |
| Ticker impersonation | A token wearing a well-known asset's ticker (tokenized equities and majors — GME, AAPL, DOGE…) that is not the canonical/issuer contract is a classic impersonation vector: the real one lives at a different address. Chirp adds a verify-the-contract advisory, and an unverified token wearing a famous ticker — the textbook impersonation setup — has its transparency grade capped at ≤ C. The genuine tokenized asset is verified, so it is exempt from the penalty and receives only the neutral verify note — the real equity is never punished for its own name |
| Pool landscape | When a token has liquidity in more than one pool, the report states that Chirp routes the single deepest ETH pool and how many other pools it ignores — so a user cross-referencing an aggregator that lists lookalike or decoy pools (a same-ticker clone, or a pair against a fake asset) gets a plain reconciliation instead of a false alarm. This complements the best-output routing engine above, which already refuses to let a shallow decoy pool shadow the genuine one |
| Socials presence (claims-vs-chain, step 1) | Every report marks the project's public footprint from DexScreener: whether it carries a paid Enhanced Token Info profile and which of website / X / Telegram it actually lists. Doctrine: socials can only ever add caution — presence is a neutral, unscored line (a polished profile, a blue check and followers are all trivially bought; rewarding them would rank the best-marketed scams first), while a token listing no links at all earns a mild caution: an anonymous team making no public claims anyone can cross-check. Link URLs are deployer-controlled and are never rendered clickable. This is the first step of claims-vs-chain: subsequent steps read what the project's own site claims (renounced, LP locked, fair launch, zero tax) and contradict it deterministically with what the chain proves — a project lying about its safety on its own website is itself a strong signal |
| Transparency scorecard | A composite 0–100 score + letter grade (A–D) over four weighted components — provenance (launched via a known stack such as Fledge), safety (the checks above), holder concentration (largest non-pool wallets' share of supply), and momentum (recent activity) — shown with a per-component breakdown. It is a quality/transparency signal, explicitly not a buy recommendation: the safety checks still gate every buy, canonical assets are exempted, and weights/thresholds are tunable without redeploy. The concentration measure excludes only recognised infrastructure — liquidity pools, the pool manager, routers, the token contract, burn addresses and reviewed lockers — so deep liquidity is never mistaken for whale control; but an unrecognised contract holding a large share DOES count, because a token can park the majority of supply in one unnamed contract and otherwise look perfectly distributed (a large one is flagged "verify what it is — airdrop/team/vesting/lock?" and a controlling ≥40% share caps the grade). A launch flagged by launch-snipe detection (above) caps this grade at ≤ C regardless of the component sum — a compromised distribution vetoes an otherwise-clean score |
The report is best-effort information, not a guarantee: a token passing every check can still lose value.
Chirp is a custodial convenience wallet, loudly disclosed — the same model as every Telegram trading bot, stated rather than hidden.
| Control | Design |
|---|---|
| Key storage | Private keys encrypted at rest; master key isolated, never in backups |
| Key export | Available from day one, PIN-gated — never a lock-in |
| PIN | Account-level, scrypt-hashed, 5-attempt lockout; key-proven reset (any wallet's exported key proves ownership) |
| Withdrawals | One-tap to the saved address; any other address requires the PIN per send. All withdrawals time-delayed, cancellable in chat, and messaged |
| Deposit caps | Warn at 0.1 ETH, hard cap 0.5 ETH per ACCOUNT during beta — the worst case stays survivable |
| Doctrine | "Lunch money in Chirp, savings in a wallet whose keys only you hold" |
Trades do not require the PIN: the user is present when they happen, or has explicitly armed an automatic order — auto-sell or limit buy (Section 7) — and is messaged the moment it fires.
Up to 5 named wallets per Telegram account, switched manually like any wallet app. Each wallet is its own book: balances, trade history, cost basis and PNL never mix. One security perimeter per human: a single PIN and a single withdrawal address cover the account.
Multi-wallet is portfolio segmentation, never coordination — enforced server-side:
| Constraint | Rule |
|---|---|
| No cross-wallet features | No bulk buys, no mirrored trades, no rotation — every trade is one wallet, one tap |
| Same-token cooldown | A wallet cannot buy a token a sibling wallet bought within 60 minutes (kills launch-bundle optics; a genuine long-term split can wait an hour) |
| Wash-guard | Buying what a sibling just sold — or selling what a sibling just bought — is refused within 30 minutes |
| Account-level cap | The beta deposit cap sums across all wallets |
A single 20-second scanner drives Chirp's whole order suite: sell-side protection (stop-loss, take-profit, trailing stop, and the rug-radar auto-exit of Section 11) and a buy-side limit order. All order kinds belong to the wallet that armed them, survive restarts, and hold (never silently cancel) when the operator pauses trading.
Each position can carry one stop-loss and one take-profit, each selling a chosen portion of the holding (25%, 50% or 100%). A full (100%) fill cancels the sibling order; a partial fill leaves the sibling active to protect or harvest the remainder.
Sell orders do not trigger on a marginal price — thin pools make marginal prices lie. The trigger compares estimated proceeds of the exact portion being sold (sell quote, price impact included — a 25% chunk has less impact than a full exit) against that portion's cost basis at arm time:
A trailing stop is a stop whose reference is not the entry but a high-water mark: the scanner tracks the best price-per-token seen since arming (a balance-invariant measure, so a manual partial sell cannot false-trigger it) and fires when the price pulls back by the armed distance from that high. The high-water only ratchets up, never down — locking in gains as the price rises, without a fixed target. It sells the full position and uses the same escalating exit as a stop-loss.
A missed take-profit is still there next tick; a missed stop-loss is worth less every tick. Therefore: take-profits execute with tight slippage (3%), while stop-losses (fixed and trailing) walk an escalating slippage ladder (3% → 10% → 25%) across attempts — a bad fill beats no fill. After 10 failed attempts the order is marked failed and the user is told explicitly that the position was NOT sold.
A limit buy arms a target — a percentage drop from the price at arm time — and a fixed amount of ETH to spend. The scanner symmetrically applies the proceeds-based philosophy to the buy side: it takes a fresh buy quote at the real ETH size each tick and fires when that quote returns at least the target number of tokens (the price has fallen far enough that the same ETH now buys the target quantity), not when a marginal price crosses a line.
Two safeguards make it doctrine-consistent. First, safety is re-verified at fire time: a token can turn into a honeypot between arming and triggering, so before spending anything the scanner re-runs the full safety report and refuses and cancels the order if a blocker has appeared — a dip is never a reason to buy a token that has since become unsafe. Second, the order is funds-safe: if the wallet no longer holds the ETH, it waits rather than failing, so it can never disrupt the user's other activity. Fills use a moderate fixed slippage (5%).
A one-tap discipline tool on the sell menu: it sells exactly enough of a winning position to recover the original ETH stake (cost basis), leaving the rest to ride as risk-free "house money". The portion is derived from the position's cost basis and a full-size sell quote — and because a smaller sale carries less price impact than the full exit, the executed portion recovers a hair more than the stake, erring toward the user definitely getting their initial back. It refuses when the position is at or below the stake (nothing to bank without locking a loss) and requires a Chirp buy history for the cost basis. No prediction — just de-risking a winner.
AMM orders are best-effort, not guaranteed prices. If the operator pauses trading, orders hold (they are never silently cancelled). During beta the bot runs on non-redundant infrastructure; downtime can miss triggers — disclosed at arm time, resolved by the production migration (Section 12).
The trade fee is 1.25%, split two ways (referral program ACTIVE since 2026-07-18; the structure was pre-announced before anyone traded under it):
| Slice | Rate | Destination |
|---|---|---|
| Protocol fee | 0.85%–1.0% | Beta: $CHIRP launch war chest (audit, liquidity, marketing), accruing as ETH. From $CHIRP launch day: 100% → trustless BuybackBurn contract |
| Referral fee | 0.25%–0.40% | Paid in ETH, on-chain, per trade, forever to the wallet of whoever invited the trader. No referrer → joins the protocol flow |
Everyone pays the same 1.25% total; a referral link never costs the referee anything extra, and the referral slice only ever redistributes within that frozen total (from the protocol slice) — it is never added on top. Referral tiers (LIVE 2026-07-27): a referrer's slice scales with the cumulative ETH volume their invitees trade — 0.25% at the base, up to 0.40% at the top tier — so the referrer's cut grows and the protocol's shrinks, while the trader's total never moves. Tiers are single-level: you earn only from the trades of people you invited, never from their invitees. Referral attribution happens once, at first contact (t.me/ChirpTradeBot?start=ref_<code>), is never self-assignable, and every payout is a public on-chain transaction. Group mode uses the same attribution: whoever adds Chirp to a Telegram group is auto-enrolled as the referrer for members who onboard via that group's reports (the private-trade link carries the owner's code), earning the same slice on the same single-level terms — a group owner earns from their community's trading, paid on-chain, with a wallet the only requirement to collect. Each user's invite link, current tier and lifetime earnings are shown by the bot's /referral command; shared PNL cards carry the sharer's invite link automatically.
$CHIRP does not exist yet. No contract address has been published; anything sold as $CHIRP today is counterfeit. The official address will appear only on chirptrade.app and @ChirpTradeApp.
| Property | Value |
|---|---|
| Ticker / standard | $CHIRP — ERC-20, Robinhood Chain |
| Total supply | 1,000,000 — fixed, no mint after deploy |
| Transfer tax | None |
| Launch standard | Verified source, fixed supply, LP burned |
| Value mechanism | Chirp trading fees → buy-back & burn |
| Bucket | Share | Treatment |
|---|---|---|
| Liquidity (fair launch) | 40% | Seeds Uniswap, LP burned |
| CEX & additional DEX LP | 12% | Usage-gated: released only when actually deployed, each disclosed |
| Staking rewards | 17% | Finite pool, decaying over 4 years (Y1 40 / Y2 30 / Y3 20 / Y4 10) |
| Treasury / ecosystem | 14% | 3-year linear vest, on-chain lock |
| Team | 10% | 1-year cliff then linear, fully vested year 4 |
| Community / marketing | 7% | 18-month linear vest |
Every non-liquidity bucket is locked, vested or usage-gated on-chain and publicly verifiable. No owner key can pull tokens early.
Trade → 1% fee → trustless buyback contract (no owner, no key; ETH in can only become burned tokens) → market-buy $CHIRP → dead address. More trading, more burns, scarcer $CHIRP.
$CHIRP launches first — traders need an easy way to buy before developers need another launchpad. When the Fledge launchpad's $FLEDGE token launches later, a CHIRP/FLEDGE pool pairs the ecosystems and buyback routing links the two flywheels (mechanics to be finalised and disclosed before Phase 3).
What Chirp will never build, as a permanent, written boundary:
The safety report detects these patterns in other tokens; Chirp does not sell both the disease and the cure.
Roadmap items are never removed — completed items are ticked and stay, so this section doubles as a public record of what was promised and delivered.
/leaderboard). Only a truncated wallet address + profit is ever shown; never a Telegram identity/scan a token for the full safety report right there in the group; trading stays private — a 🔒 button opens a 1:1 chat to buy from your own wallet. Chirp never shows anyone's wallet, balance or keys in a shared chat (a strict privacy boundary stops every custody command in groups). Whoever adds the bot earns referral fees from members who onboard through it — auto-enrolled, paid on-chain, and single-level onlyElfDev — Founder & Developer
Python/backend developer with experience in blockchain systems, trading bots and DeFi infrastructure. Builder of the Fledge launchpad stack for Robinhood Chain and Aster Pilot, a live algorithmic trading system.
Contact: support@chirptrade.app · X: @ChirpTradeApp · Telegram: @ChirpTradeBot