tweetdotfun

tweetdotfun is a GenLayer-powered launchpad for turning verified public X posts into real ERC-20 tokens.

The idea is simple: a user pastes an X post, a GenLayer Intelligent Contract verifies the public post metadata under validator consensus, and the user launches one token for that post through a wallet-signed EVM factory. The two contracts then verify each other on-chain — the GenLayer launchpad eth_calls the EVM factory to confirm the deployed ERC-20 before linking it. Every token has its own bonding-curve trading contract, so buys and sells are on-chain and visible through explorer links.

What It Does

• Verifies public X post metadata with a GenLayer Intelligent Contract, under validator consensus across multiple JSON mirrors with fallback (reliable even when one source is rate-limited).
• Prevents duplicate launches by enforcing one token per tweet id.
• Creates a real ERC-20 token through a user-signed factory transaction.
• Links the ERC-20 back into the GenLayer registry only after verifying it cross-contract — the launchpad eth_calls the EVM factory to confirm the token, so the two contracts verify each other on-chain.
• Gives the launch wallet a 0.2% registrant allocation.
• Holds the curve allocation inside the token contract for live buy/sell trading.
• Shows live token state, curve inventory, reserve liquidity, price, and trade history.
• Shows trending tokens based on actual Buy events.
• Shows a transactions page with buy/sell events across all linked tokens.
• Links transaction hashes to explorers so users can verify what happened on-chain.

Live Contracts

• GenLayer TweetLaunchpad: 0xb3cEaf2769F6247060F9d4E6575DcF957D313C4D
• EVM TweetTokenFactory: 0xd5d36cfe347e28fc2f0bdc2d09f5dafcc4e7fc8d
• Sample TweetToken: 0xc793065e529949aBFB37f5839F044Ee07274Ba41

Why GenLayer

tweetdotfun uses GenLayer for the parts that need validator consensus on external state, not a generic backend:

• Verifying a public X post — reading tweet metadata from multiple mirrors and having validators independently agree on the immutable facts (id, author, text hash). View counts are treated as an advisory snapshot, never a consensus gate, because they aren't reproducible across validators.
• Verifying the EVM token cross-contract — link_evm_token does an eth_call to TweetTokenFactory.tokenForTweet(keccak256(tweetId)) under a strict equivalence principle, so the launchpad only links a token the canonical factory actually deployed for that tweet. The intelligent contract and the EVM contract check each other.
• Enforcing one token per tweet id, and deriving token name/ticker/description from the verified post.

The token itself is not a GenLayer child contract. It's a real EVM ERC-20 created by the factory, because the trading surface needs normal wallet behavior, balances, transfers, and direct buy/sell calls. GenLayer owns the trust layer; the EVM owns issuance and trading.

Architecture

GenLayer Launchpad

contracts/TweetLaunchpad.py

The Intelligent Contract:

• accepts an X/Twitter status URL and desired supply,
• extracts the tweet id,
• verifies public metadata under validator consensus (see Consensus reliability below),
• derives token metadata from the author and post text,
• stores the launch wallet, tweet id, description, supply, and token metadata,
• rejects duplicate tweet ids,
• exposes link_evm_token(tweetId, tokenAddress) so the original launch wallet can link the deployed ERC-20 — verified cross-contract (see below).

Cross-contract link (GenLayer ↔ EVM)

link_evm_token does not trust a frontend-supplied address. It performs an eth_call to TweetTokenFactory.tokenForTweet(keccak256(tweetId)) on the EVM layer under a strict equivalence principle, and only links the ERC-20 if the factory itself reports that token for this exact tweet id. So the GenLayer record and the EVM token verify each other on-chain — a registrant can't point a tweet's GenLayer record at an arbitrary or unrelated token.

Consensus reliability

Verification is engineered so independent validators reliably reach the same result:

• Multiple metadata mirrors with fallback — the contract reads public tweet JSON from api.fxtwitter.com, falling back to api.vxtwitter.com, normalized to the same fields. One mirror being rate-limited or down does not break consensus.
• Consensus on immutable facts only — validators agree on tweet_id, author, author_name, and a hash of the post text. Live view counts are deliberately excluded from the agreement (they change between fetches), so popularity is recorded as an advisory view_bucket snapshot rather than a consensus-gated launch requirement.
• Transient vs. permanent error classification — a deleted/404 post is a deterministic rejection all validators agree on; a 5xx/429/timeout is treated as transient (the launch asks the user to retry) instead of being locked in as a permanent failure on a single node's blip.

It does not deploy tokens internally.

EVM Token Factory

contracts/evm/TweetTokenFactory.sol

The factory:

• deploys one TweetToken ERC-20 per tweet,
• requires the registrant wallet to sign createTweetToken(...),
• prevents duplicate factory tokens for the same tweet id,
• emits TweetTokenCreated with the token address.

Each TweetToken:

• has normal ERC-20 transfers and approvals,
• gives 0.2% of total supply to the launch wallet,
• keeps the remaining curve allocation inside the token contract,
• exposes buy, sell, quoteBuy, quoteSell, currentPrice, reserve, soldSupply, and totalSupply,
• emits Buy and Sell events for the feed, trending page, and transactions page.

App Pages

• Feed: all GenLayer-registered tokens, including pending and live tokens.
• Launch: the wallet-signed launch flow: register tweet, create ERC-20, link token.
• Trending: only tokens with at least one live Buy event, ranked by buy volume, buy count, reserve, then sold supply.
• Transactions: latest Buy and Sell events across linked tweet tokens.
• Token: token detail, curve state, reserve liquidity, token info, original post summary, and buy/sell trading.

Live Bradbury Deployment

• GenLayer TweetLaunchpad: 0xb3cEaf2769F6247060F9d4E6575DcF957D313C4D
• EVM TweetTokenFactory: 0xd5d36cfe347e28fc2f0bdc2d09f5dafcc4e7fc8d
• Factory deploy transaction: 0x3ab16965e3953ba912a0d79cc45ef0b9d6af5d339a53705a05bac71f7adeb110
• Factory deploy block: 4785064
• Sample token: 0xc793065e529949aBFB37f5839F044Ee07274Ba41
• Sample tweet id: 2041967195647815968

Explorer links:

• GenLayer transactions: https://explorer-bradbury.genlayer.com/tx/<hash>
• EVM token transactions: https://zksync-os-testnet-genlayer.explorer.zksync.dev/tx/<hash>

Built With

• GenLayer Intelligent Contracts for X post verification and tweet id registry state.
• Bradbury testnet for the live prototype deployment.
• A wallet-signed EVM factory for real ERC-20 tweet token creation.
• ERC-20 token contracts with bonding-curve buy/sell methods and trade events.
• React, Vite, RainbowKit, wagmi, viem, and pnpm for the web app.

Network State

The current app points at the Bradbury testnet launchpad and factory deployment listed above. The frontend starts event scans from factory deploy block 4785064, which keeps trending and transaction history tied to the known factory deployment instead of scanning unrelated chain history.

Important Constraints

X access is the hardest external dependency, so verification is hardened for it (see Consensus reliability above): validators read from multiple public JSON mirrors with fallback, agree only on immutable post facts (not volatile view counts), and treat upstream rate-limits/5xx as retryable rather than as a permanent rejection. If every mirror is simultaneously unreachable for a post, verification returns a transient error and the launch can simply be retried.

The transactions and trending pages use event logs from the token contracts. Bradbury RPC currently limits log queries to a maximum block range of 10,000, so tweetdotfun chunks log scans from the factory deployment block instead of querying the whole chain in one request.

Current Status

This is a working Bradbury testnet prototype:

• GenLayer verifies and registers tweets under consensus, across multiple mirrors with fallback.
• The launchpad verifies the linked ERC-20 against the EVM factory via cross-contract eth_call.
• The factory creates real ERC-20 tweet tokens.
• The launch flow is wallet signed.
• Trading calls the token contract directly.
• Trending and transaction history are event-backed.
• Explorer links are exposed for user verification.
• Contract behavior is covered by gltest direct tests (tests/direct/).