Feedpad field manual

Feedpad is a browser extension that turns any post on X into a token on Robinhood Chain in about twenty seconds. Hover a post, press Launch this, and a side panel opens already filled from the post: name, ticker, image, description. The origin — the author's handle and the post ID — is locked and written on-chain with the token.

One post can only ever be launched once. The account that wrote the post earns a share of every trade on the resulting token, whether or not they know about it yet. Every token launched through Feedpad carries a link back to feedpad.press in its permanent metadata, which every chart aggregator renders.

Chain

Robinhood Chain (EVM, chainId 4663)

Surface

Chrome extension, Manifest V3, injected into x.com

Token

$FEED — access tiers, not a claim on anything

Domain

feedpad.press

Official channels

X @feedpadRH · GitHub feedpadRH · these docs

• Scroll the timeline. A post is going off.
• Hover it. A small Launch this appears in the post's action row — on hover only, never a permanent element.
• Press. The side panel opens, pre-filled. Touch two fields, set an opening buy.
• Launch. One transaction to the launchpad factory. Fixed supply, bonding curve, tradable from block one.
• Back on the timeline the post wears a badge with its market. That post is now claimed.

The launch button is live from the moment the panel opens. Auto-fill runs in three tiers — a heuristic that is instant and offline, optional ranked suggestions in the background, and full manual editing — and nothing in the enrichment path may block the press. The image is copied to permanent storage in parallel with editing so a slow upload never costs a launch.

The launchpad stores a metadata block with every token. Feedpad fills each field on purpose. Two of them do the heavy lifting: the website field, which every aggregator renders as a button, and the X field, which points at the origin post.

name

from the post

symbol

launcher's choice

logo

post media, copied to permanent storage

description

"Launched from @author's post · Feedpad"

socials.website

feedpad.press/t/<postID> — the billboard

socials.x

the origin post URL — the provenance

creatorFeeRecipient

the fee splitter contract

creatorTax

1–5%, chosen at press, immutable

salt

ground for a house address suffix

launchToken(
  params {
    name, symbol, logo, description,
    socials { twitter, website, … },
    creatorFeeRecipient   // the splitter
    creatorTaxBps         // 100–500, immutable
    buybackEnabled
    expectedEconomics     // re-read immediately before send
    salt                  // suffix grinding, tiered
  },
  launchConfigId,
  pairToken               // native, NOT the wrapped form
) payable                 // launch fee + opening buy

// The overload that accepts an exemption array is never called.

A product rule, enforced honestly — not a chain rule dressed up as one.

• The registry maps post ID → token. First launch wins, ordered by block number.
• The claim is externally verifiable: the post ID is written into the token's own on-chain metadata.
• The extension refuses a second launch on a claimed post and shows the existing token instead.
• Someone can still deploy the same idea directly on the pad. They get no badge, no billboard, no registry entry, no author split. The lock holds because our lane is the good one.
• Quote-posts and reposts resolve to the original post ID. A viral quote cannot relaunch a claimed idea.

The launchpad taxes the first seconds of every token's life: currently three seconds, starting at 99% and decaying to the normal fee. Only the pad's team can change that. We cannot, and we do not ask.

without exemption list

everyone faces the tax — Feedpad calls this

with an exemption list

named wallets skip it — Feedpad never calls this

• The launcher's opening buy happens inside the launch transaction — the one privileged buy, and it belongs to whoever pressed.
• No pre-approved wallet list is ever passed. There is no insider lane because the call shape has no parameter for one.
• Anyone can verify this per token: read the launch transaction and check which form of the call was used.

Every token launched through Feedpad carries a creator tax chosen by the launcher between 1% and 5%, defaulting to 2%. The launchpad caps this at 10% and it is immutable once set. The tax is paid to one address, so that address is a splitter contract.

Launcher

50% — pressed the button

Author

30% — wrote the post

Protocol

20% — falls to 15 / 10 / 0% by $FEED tier; the discount goes to the launcher

The launcher and author slices never shrink. We only ever discount our own cut, and the discount goes to the launcher.

Authors can CLAIM their balance after verifying handle ownership, DISAVOW a token (their slice routes to buyback and the token is flagged on every Feedpad surface), or ADOPT it publicly. Unclaimed balances route to buyback after 90 days, and the countdown is shown on the token page from day one.

does:
  ✓ receive creator tax for one token
  ✓ hold immutable split shares set at registration
  ✓ let each party pull their own accrued balance
  ✓ expose the origin post ID as a public field
  ✓ route the author slice to buyback on disavow or 90-day lapse

does not:
  ✕ custody anyone's trading capital
  ✕ hold user deposits of any kind
  ✕ have an admin withdraw path over launcher or author slices
  ✕ have an upgrade proxy

A contract that never holds principal cannot lose principal. The splitter only ever touches fee revenue that has already been earned.

Supply

1,000,000,000

Distribution

100% fair launch on the chain's launchpad

Team allocation

none

Presale

none

Vesting

not applicable — there is nothing to vest

Exemption list at launch

none passed — same rule as every token pressed with Feedpad

SCROLL · hold 0

protocol 20% · Unlimited launches · Post badges + token pages · Buy and sell from the panel

PRESS · hold 0.25%

protocol 15% · UNCLAIMED markers on the timeline · Momentum alerts

EDITOR · hold 1%

protocol 10% · Address suffix grinding · Verified press badge · Front-page submission

DESK · hold 3%

protocol 0% · Protocol takes 0% — you keep the full split · Bulk claim across every token you pressed · New surfaces the day they ship

• Never: It is not a claim on revenue.
• Never: It is not required to launch, buy or sell.
• Never: It does not change the launcher's or the author's slice — only ours.

• Sink: 25% of the protocol slice buys back continuously
• Sink: 100% of author fees unclaimed past 90 days
• Sink: 100% of disavowed author slices, permanently
• Sink: Tier thresholds hold supply off the market while a hunter is active
• Sink: Suffix-grinding rights are consumed per launch

The private key never leaves the wallet. The extension builds calldata and hands it over; it never holds funds and never asks the user to sign anything they cannot read. Every write path is on-chain first and database second — the database is a cache and an index, never the source of truth. If it were lost entirely, every press could be rebuilt from chain data, because the post ID lives in the token's own metadata.

Content script

reads posts, injects the hover button

Side panel

launch form + docked watchlist

Service worker

metadata, quotes, registry

User wallet

signs the one launch transaction

Registry API

post ID → token, first press wins

Image intake

post media → permanent storage

Launchpad factory

token + curve

FEED SPLITTER

our one contract — fees only

Indexer

token pages → aggregators

x.com

the only site we read

feedpad.press

our own API

chain RPC

reads and sends

storage

wallet address, tier, settings

sidePanel

the docked panel

Read endpoints are public and unauthenticated by design — anybody indexing Feedpad tokens should be able to. Write endpoints fail closed and require a signature from the wallet or handle they act for. No endpoint ever moves funds.

Write a post yourself and press it instantly, forever

Self-press is labelled, not blocked. The token page says so; the leaderboard filters it by default.

Spam presses to climb the front page

Front page ranks on curve volume, never on press count.

Farm launches from one wallet

Rate limit per wallet per hour, rising with live rate. Launchers whose tokens trade earn more presses.

Launch from a handle that never wanted this

Blanket opt-out. Any verified handle can turn off launching from their posts, honoured at the extension level, no appeal process for us.

Launder the lock through a viral quote-post

Quotes and reposts resolve to the original post ID.

Impersonate a public figure

Every token page carries community-launched, not affiliated above the fold, permanently.

01 PRESS · weeks 1–4 · LIVE

Hover affordance + side panel · Heuristic auto-fill, no model dependency · One-transaction launch, native pair, no exemption list · Registry lock, post ID written on-chain · Token page at /t/<postID> · Splitter contract, reviewed — Exit: A stranger presses a post; a second stranger finds that token cold on an aggregator and buys it without the extension.

02 CIRCULATE · weeks 5–10

Post badges · In-panel trading · Author index + claim + disavow · Author-discovery outreach · Front page + press records + titles · Store listing + signed zip fallback — Exit: Origin authors start claiming without being contacted first.

03 HUNT · months 3–5

$FEED fair launch, same rules · Tiers live: UNCLAIMED markers, alerts, suffix grinding · Ranked name/ticker suggestions · Buyback routing · Public read API — Exit: Holding $FEED is the obvious move for anyone pressing more than occasionally.

04 SURFACES · months 6–12

Second browser target · Mobile path · Optional group press, once there is an audience for a pool to fill · Other post sources · Author-side tooling

Instant launch, no pooled commit round at v1

A pooled round is only visible to people who already installed. At zero users that is an empty room.

One post, one token

The only scarcity a launchpad can honestly have. Turns scrolling into a race.

Lock is a product rule, stated as one

The post ID on chain makes it auditable anyway.

Origin author paid by default, no opt-in

Turns the obvious objection into the best marketing we have.

Website field points at our own token page

Aggregators become permanent distribution we never pay for.

Never pass an exemption list

There is no insider lane if the call shape has no parameter for one.

Splitter holds fees only, never principal

A contract that never holds principal cannot lose it.

Creator tax chosen by the launcher, disclosed as immutable

Hiding that would be the kind of thing we are differentiating against.

Real curve balances only, never virtual reserves

Competing pads render a virtual reserve as 40% to graduation on tokens holding nothing.

Minimum extension permissions

Anything more and nobody installs a crypto extension.

The category's vanity metric is launch count. We refuse it as a headline — a pad with 131 launches and no trades is the thing we are reacting to.

• Primary: % of presses with ≥1 buyer who is not the launcher
• Primary: Median curve volume per press
• Primary: Cold installs attributed to token-page arrivals

• Secondary: Author claim rate + median time to claim
• Secondary: Median seconds from panel open to press
• Secondary: Repeat press rate at 7 days
• Secondary: Graduation rate

Published whether good or bad, on the docs page, monthly.

• Strength: The registry of claimed posts, author relationships and installed base are not copyable — the mechanic is.
• Strength: Three-sided network: launchers want unclaimed narratives, buyers want badges, authors want their balances.
• Strength: Every press is a labelled narrative-to-market datapoint nobody else is collecting.
• Strength: The honest position is unoccupied: real balances, published metrics, no exemption list, no custody of principal.

Store policy

Trading extensions on X have precedent; launching does not. Minimum permissions, no key custody, signed zip on our own domain as fallback.

Host DOM changes

Parsing sits behind one module and fails soft — if we cannot parse, the button does not appear and nothing else breaks.

Spam at scale

Volume-based ranking, rate limits tied to live rate, author opt-out.

Impersonation

Permanent unaffiliated line, disavow, blanket handle opt-out honoured without negotiation.

Mobile

Most of the timeline is read on phones where extensions do not exist. This caps the base until phase 4.

Pad dependency

Someone else's launch contracts control the snipe parameters. The splitter and registry are ours; the call is abstracted.

• Open any Feedpad token's launch transaction on the chain explorer and check the function selector: the call must be the three-argument form, with no exemption array.
• Read the token's metadata: the website field must point at feedpad.press/t/<postID>, and the post ID must match the origin post.
• Read the splitter for that token: the origin post ID is a public field, and the split shares are immutable.
• Compare the curve's real balance on chain against what the token page shows. Feedpad never displays a virtual reserve as progress.