Robshooterv4 launch protocol
v4 direct

Docs

Robshooter direct Uniswap v4 launches

Robshooter creates fixed-supply tokens directly on supported networks. Creation, pool initialization, LP custody, and 1–32 configured first buys complete atomically. There is no bonding curve or graduation phase.

Networks

Launch lifecycle

  1. Create token — the factory deploys a 9-decimal ERC-20 with exactly 1 billion tokens and on-chain metadata.
  2. Initialize pool — the entire supply and launcher-provided ETH initialize a native-ETH Uniswap v4 pool.
  3. Record LP custody — the position starts unlocked in creator-controlled custody. No lock, LP burn, or ownership renunciation is applied automatically.
  4. First buys — 1–32 sequential exact-output swaps execute in the same transaction and deliver each configured token amount to its distinct recipient.
  5. Trade — every later buy and sell routes through the selected network's canonical Uniswap v4 Universal Router.
  6. Manage protection — connect the creator wallet on the token’s trading page to manually lock liquidity, burn LP ownership, or renounce token ownership. Other wallets see status only.

Configurable first-buy wallets

The connected launcher pays for initial liquidity and every first buy. Each row specifies a distinct recipient and exact token amount. The app calculates each ETH budget automatically, including fees, sequential price impact, a refundable 2% buffer and a small rounding allowance. Universal Router executes real sequential v4 exact-output swaps and refunds unused ETH. The spending ceiling is enforced on-chain; an insufficient budget or failed swap reverts the complete transaction, including pool creation.

The creation form can generate recipient wallets locally in the browser from a wallet count and common token amount. Download the required offline CSV backup before launch. Wallet storage is automatic: sign in with the creator wallet and, after two launch confirmations, the app uploads the generated keys over HTTPS for encrypted MongoDB storage. The server operator can decrypt stored keys. Keys never go into the blockchain transaction or to the RPC provider. A failed save does not undo the launch; keep the CSV and retry saving without sending another transaction.

Private launch-wallet records

The original creator can unlock records on the trading page or Profile with a wallet signature. Sessions last 15 minutes and currently support EOA wallets. Transferring or renouncing token ownership does not transfer key access. An additional one-use signature is required to export stored private keys.

The server verifies the confirmed factory and first-buy events before linking wallets or importing their keys. Existing launches can track first-buy addresses without keys, or import their original address/private_key CSV. Private keys cannot be recovered from blockchain data. Balances are checked on request, at most every 30 seconds per token; failed reads retain older values and are clearly marked. Records do not authorize automatic trading or movement of funds.

Liquidity locks and LP burn

Liquidity protection is managed on the trading page, not during token creation. New positions start unlocked: the recorded creator can release the NFT immediately or choose protection. Public status clearly identifies unlocked liquidity. Once released, the position can no longer be managed through the Robshooter locker.

Timed locks require a duration, starting when the separate lock transaction is confirmed. The input starts at 30 days; durations from 1 minute to 3,650 days are accepted. Only the recorded token creator can extend a lock or release its position NFT after expiry. Locks cannot be shortened. Releasing the NFT does not automatically withdraw ETH or tokens; it gives the beneficiary control of the liquidity position.

Permanent locker custody has no scheduled release, but the locker remains administrator-upgradeable. LP burn is different: it transfers the position NFT to 0x000000000000000000000000000000000000dEaD. Liquidity stays in the pool, while the position and its LP fees are no longer recoverable through Robshooter. It does not burn ERC-20 tokens or reduce token supply. Uniswap’s BURN_POSITION action is not used because that removes liquidity.

Existing locks are not converted into timed locks. Earlier permanent positions retain their restrictions. Newly configured locks can be extended or burned by their recorded beneficiary from the token page.

Token ownership renunciation

Use the current owner’s wallet on the trading page to manually renounce ownership. This is never automatic in the creation UI. Renunciation permanently sets the token owner to the zero address, clears any pending owner, and prevents future changes to token fee rates and the fee receiver. Existing fee settings continue to apply. Token ownership is independent of liquidity ownership: the liquidity beneficiary remains unchanged. Protocol upgrade authority is also unchanged.

Buy and sell fees

Buy and sell fee inputs default to 0% at launch. The creator can choose either fee up to 10% and can change the receiver, which defaults to the creator. A Uniswap v4 custom-accounting hook collects the fee: exact-input trades pay from output, while exact-output trades add the fee to input. The settings and receiver remain readable on-chain and are displayed on each token page. Collected ETH and token fees accrue in the hook and are claimed to the recorded receiver. This prevents a receiver that rejects ETH from blocking swaps for everyone else.

“Apply buy fee to initial purchases” controls only the atomic first-buy bundle. It defaults to off; later buys and sells use the selected fees regardless. Each first buyer receives the exact token amount requested. The initial-buy fee, when enabled, is charged in ETH. The per-wallet breakdown shows an indicative ETH fee, its approximate token equivalent, and total cost including pool fees and sequential price impact, excluding gas. With a connected wallet and complete token details, a read-only launch simulation checks purchase totals. The Uniswap-fee split remains approximate because per-tick rounding can differ. Each automatically calculated ETH limit is enforced on-chain.

Importing a first-buy wallet

Click the pencil beside a first-buy address to edit its private key directly in the same field—no modal opens. The key is masked, its address is derived locally, and invalid or duplicate wallets are rejected. Click OK to apply it, or use × or Escape to cancel. Leaving the field does not apply the draft. The token amount stays unchanged, and launch or wallet-list changes are blocked until editing is finished. Never enter a seed phrase or your main wallet key. Download a new wallet-key CSV after importing. Generated and imported keys are saved to encrypted server storage after a confirmed launch, where the server operator can decrypt them.

Launch cost breakdown

The creation page separates initial liquidity, token purchases before fees, Uniswap pool fees, initial-buy token tax, the protocol launch fee, and estimated network gas. Gas is estimated for the entire launch transaction, not charged separately for each recipient. Sell tax does not apply to initial buys.

The estimated total is different from the wallet balance needed upfront. The transaction includes a refundable purchase buffer; the wallet also needs a gas reserve with 20% gas-limit headroom at the suggested fee cap. Unused purchase ETH is refunded and unused gas allowance is not charged. Liquidity is pool funding, not a protocol fee.

Complete the name, ticker and recipient list, then connect the launcher wallet to estimate gas automatically. Estimates refresh when inputs change and periodically afterward. If the RPC cannot estimate gas, the page shows only a subtotal and blocks launch. The full simulation, current fees and wallet balance are checked again before signing. Actual network costs can change.

Recipient wallets do not sign or grant approvals because they receive tokens rather than supply funds. A separate multi-signer funding design would require signed permits from every paying wallet.

Pricing and liquidity

The initial spot price is determined by initial ETH / fixed token supply. The deployment defaults to a 0.30% v4 pool fee, tick spacing 60, a 0.0005 ETH launch fee, and at least 0.01 ETH of initial liquidity. These values are set by the deployed factory and displayed on the creation page.

Trading and indexing

The application derives launches from factory events and reconstructs price, volume, trades, and holders from Uniswap v4 pool events and ERC-20 transfers. Quotes use the canonical v4 Quoter, and trades use exact-input minimum-output protection through the Universal Router.

The trading page uses an official Bubblemaps integration in place of a price chart. The embedded viewer requires a partner ID approved for this domain. Within Robshooter’s networks, it is configured for Robinhood mainnet only. Ethereum Sepolia and Robinhood testnet show an unsupported-network notice; they are never substituted with mainnet maps.

Bubblemaps manages map data, access and token coverage. A new token may not have a map yet, and wallet connections do not prove common ownership. The viewer receives the public token address, network and browser connection data, never your saved wallet keys or Robshooter session. Trades and the top 25 indexed holders remain available separately, without pagination.

About includes the shared Uniswap v4 PoolManager address, the unique pool ID, copy controls, and explicit token ownership status. Renounced token ownership does not remove protocol upgrade powers.

Deploy

From contracts/:

forge script script/DeployRobinhood.s.sol:DeployRobinhood --rpc-url $ROBINHOOD_RPC_URL --broadcast --via-ir

forge script script/DeployUpgradeableSepolia.s.sol:DeployUpgradeableSepolia --rpc-url $SEPOLIA_RPC_URL --broadcast --via-ir

After deployment, configure the frontend factory, multi-buy router, locker, and factory start block. Do not point this interface at the previous bonding-curve factory: its ABI and lifecycle are intentionally incompatible with the direct-launch protocol.

Security boundary

Optional wallet-key storage gives the server operator the ability to decrypt saved keys. Transactions are irreversible, and first-buy bundles still face normal market and ordering risk. New Sepolia infrastructure uses six transparent proxies controlled by one administrator, without a multisig or timelock. Token contracts are not proxies and cannot be upgraded. The administrator can change infrastructure behavior, including fee-hook and locker rules; liquidity locking and fee enforcement are therefore subject to that authority. Earlier non-proxy deployments remain unchanged. Independent contract review is required before a production mainnet deployment; no application can be made attacker-proof solely through implementation controls.