Print a token.
Trade it instantly.
Hood Prntr is a fair-launch token printer for Robinhood Chain. Every token is created with its entire supply deposited into a live Uniswap v4 pool at the moment of printing - no presale, no team allocation, no separate liquidity step.
What this is
Hood Prntr wraps four verified, non-upgradeable contracts - a factory, a Uniswap v4 hook, a router, and a custody vault for optional creator locks - around a single mechanic: printToken() mints a fresh ERC-20, seeds a Uniswap v4 pool with its entire supply as single-sided liquidity, and makes it tradeable in the same transaction.
There is no vesting, no locked team allocation the contract can later unlock to itself, and - as of the current deployment - no function that lets anyone withdraw liquidity from a pool once it's live. What a creator can adjust at print time (trading fee tier, an optional anti-snipe window, an optional lock on their own tokens) is fixed at that moment and readable on-chain afterward.
Why single-sided liquidity
Most launch mechanisms ask the creator to pair their new token against some amount of ETH. Hood Prntr doesn't - the entire 1,000,000,000-token supply is placed as liquidity on one side of the pool, positioned so that early buyers are the ones providing the ETH side as they trade against it. See How Printing Works for the mechanics.
This documentation describes the contracts as deployed and verified on-chain. Every address referenced here is checked against Blockscout at time of writing - see Smart Contracts for the live addresses.
Getting Started
Three things to do before your first print or trade: get a wallet on Robinhood Chain, bridge in ETH, and understand the two things you can do on Hood Prntr.
-
1
Connect a wallet
Any injected EVM wallet (MetaMask and similar) works. Use the Connect Wallet button in the top right of any page.
-
2
Bridge ETH to Robinhood Chain
Trading and printing both run on native ETH (wrapped to WETH internally for pool accounting). Use the Bridge page to move ETH in from another chain.
-
3
Print or trade
Print New Token creates a brand-new token you control the launch parameters for. Buying and selling existing tokens needs no setup beyond a wallet connection and ETH balance.
Network details
| Chain | Robinhood Chain |
| Chain ID | 4663 |
| RPC | https://rpc.mainnet.chain.robinhood.com |
| Explorer | robinhoodchain.blockscout.com |
| DEX engine | Uniswap v4 |
Printing a Token
What the Print New Token form actually asks for, field by field, and what happens after you submit.
The form
Everything below lives on one page. A live preview panel on the right updates as you type, showing exactly what gets written on-chain before you commit to anything.
-
1
Logo, name, ticker
Upload an image, pick a token name (up to 32 characters) and a ticker (up to 10, letters and numbers only - lowercase gets uppercased automatically). These two fields are the only ones required to print.
-
2
Description & socials
Optional: a short description, plus website, X/Twitter, and Telegram links. None of this is on-chain data - it's saved separately (see below) and shown on the token's page.
-
3
Token settings
Trading fee (1/2/3/5%), starting liquidity (1-10 ETH - this sets the launch price, not an amount you're spending), the sniper shield toggle (on by default), and an optional lock on your own tokens with a specific unlock date and time.
Turning the lock on doesn't hold anything back from your wallet or change anything else about the form - it changes where your creator buy (step 4) ends up. With no lock, those tokens land straight in your wallet. With a lock, they're deposited into a separate custody contract, PRNTRVault, instead - held there until the date and time you picked. The printed token itself never has any transfer-restriction code in it, locked or not; the lock lives entirely in the vault, not the token. Leave the date field empty and nothing changes from an unlocked print.
-
4
Creator buy
Optional. An amount of ETH to buy your own token with, in the same transaction as the print - at 0% fee, since it executes before the sniper shield window starts. Quick-select buttons for 0.1/0.5/1 ETH, or type your own.
Starting liquidity isn't a deposit. It sets where the token's price begins - it doesn't come out of your wallet unless you also fill in a creator buy. Printing itself costs only gas.
After you print
The transaction goes to your wallet to confirm, same as any on-chain call. Once it's mined:
- If you filled in a description, image, or any social link, you'll be asked to sign a message (not a second transaction - this one is free) to save that off-chain. Skip it and the token still exists, just without that extra info attached.
- You're redirected straight to the new token's page, where it's immediately tradeable.
Trading & Charts
Every token's page has a live chart and a buy/sell panel. Here's what each control does.
The chart
Embedded from GeckoTerminal, defaulted to price view rather than market cap - so the numbers you see match the token's actual per-token price, not a larger figure that can read as inconsistent for a token worth a fraction of a cent.
The buy/sell panel
- Buy / Sell toggle - switches the whole panel's direction. Selling a token you haven't approved the router for yet shows an Approve step first, a one-time on-chain permission separate from the trade itself.
- Quick-fill buttons - 25% / 50% / 75% / Max, calculated off your actual ETH or token balance.
- You pay / You receive - the estimated output updates live as you type, along with the minimum you'd receive after slippage.
- Slippage settings (gear icon) - presets of 1% / 5% / 10% / 15%, or a custom value from 0.1% up to 50%. This is the same
minOutprotection described in Swap Mechanics - if the fill would be worse than this tolerance, the transaction reverts rather than executing at a worse price.
If the sniper shield is still active on a token, the panel shows a countdown banner - trades inside that window pay the 85% shield rate, not the token's normal fee.
Below the chart
Holders Distribution lists the largest holders by share, including the pool itself. Transactions lists recent trades with time, type, USD value, token amount, ETH amount, trader address, and a link to the transaction.
My Prints
Every token your connected wallet has printed, and the one place you claim your creator share of trading fees.
What's on this page
Each card shows:
| Field | What it shows |
|---|---|
| Fee tier | The trading fee this token was printed with (1/2/3/5%) - fixed at print time, can't be changed after. |
| Liquidity | The starting ETH value used to set this token's launch price (1-10 ETH). |
| Sniper | Whether the 85% anti-snipe fee was enabled for this token's first 30 seconds. |
| Lock | If you locked your own creator tokens at print time: the unlock date while it's still pending, then "Ready to withdraw" once it's passed, then "Withdrawn" after you've actually claimed them. |
| View / Explorer | Jump to the token's trading page, or its verified source on Blockscout. |
Claiming fees
Claim Fees reads "Nothing to claim" until there's an actual balance to send - it activates the moment a pool has real fees to pay out, so you never end up sending a transaction that would just revert.
What the button actually pays out
Clicking it doesn't send you the whole accumulated balance - it triggers collectFees(token) on the factory, which splits the pool's entire accumulated fee balance on the spot: 30% to you, 70% to the platform, in the same transaction. You only ever receive your 30% share; the platform's cut isn't something you're moving on its behalf.
See Fees & Sniper Shield for where that 30/70 split comes from and how the fee tier itself is set.
Withdrawing locked tokens
If you printed a token with a creator lock, those tokens don't sit in your wallet, waiting - they're held in PRNTRVault, a separate custody contract, until the unlock date passes. Unlocking is a claim, not something that happens automatically:
- Before the unlock date, no button shows here - the Lock field just shows the date you picked at print time.
- Once that date passes, a Withdraw Locked Tokens button appears on that token's card. Clicking it sends one transaction that moves your full locked balance from the vault straight to your wallet.
- After that transaction confirms, the button reads Withdrawn - there's nothing left in the vault for that print to claim again.
Only you - the address that printed the token - can withdraw its lock, and only after the unlock time. The vault enforces both of those on-chain; there's no way to claim early or claim someone else's lock, from this page or anywhere else.
Live Feed
Every token printed on Hood Prntr, updating in real time.
The feed refreshes automatically and briefly highlights a token's card - green for a buy, red for a sell - the moment a new trade lands on it, so activity is visible without reloading the page.
Each card shows the token's logo, ticker, contract address and creator address (both one click to copy), how long ago it was printed, market cap, volume, and trade count. The search bar filters by name, ticker, or contract address as you type.
Bridge
Robinhood Chain is an Arbitrum L2. The Bridge page doesn't move funds itself - it's a curated set of links to three external bridges that do.
| Bridge | Notes |
|---|---|
| Relay Protocol RECOMMENDED | Fastest of the three - median 2-second execution, widest route selection. |
| Across Protocol | Optimistic bridge, covers ETH and major tokens. |
| Arbitrum Bridge OFFICIAL | The canonical Arbitrum bridge - slowest of the three, most conservative trust assumptions. |
Each opens the bridge's own site in a new tab with the destination pre-set to Robinhood Chain. Bridging typically takes anywhere from a few seconds to a few minutes depending on which one you use.
Support
A real AI assistant, backed by a human, not a static FAQ page.
The AI assistant
Ask anything about printing, fees, the sniper shield, or trading, and it answers directly. It's connected to a live backend, not a canned set of responses - conversations are specific to whatever you actually ask.
Talking to a human
If the assistant can't help, it hands off automatically - or you can request a human agent yourself at any point with the button below the chat. Once escalated, a real reply from the team appears in the same conversation thread, polled in continuously.
Notifications
If you're on another tab or window when a reply comes in, the browser tab title shows an unread count and a short tone plays, so a conversation doesn't go unnoticed while you're elsewhere on the site.
Your conversation persists
Connect the same wallet later and your chat history is still there - it's tied to your wallet address, not just the current browser session.
How Printing Works
One transaction takes a token from nonexistent to tradeable. Here's exactly what printToken() does, in order.
Step by step
-
1
Token minted
A new ERC-20 is deployed with a fixed total supply of 1,000,000,000 tokens, minted directly to the factory. There is no separate mint function reachable afterward.
-
2
Pool seeded, single-sided
The factory deposits the entire supply as concentrated liquidity in Uniswap v4, positioned so the position holds 100% of the new token and 0% WETH at launch. Which side of the pool (currency0 or currency1) the token lands on depends on whether its address sorts above or below WETH's - see the diagram below.
-
3
Registered with the hook
The pool is registered with the fee tier the creator picked (1/2/3/5%) and whether the sniper shield is active. A pool that isn't registered here can't be traded through the router at all.
-
4
Optional creator buy
If the creator sent extra ETH beyond the mechanics require, that amount executes as a real buy in the same transaction - the creator ends up holding tokens immediately, recorded in the print event.
Currency ordering
Uniswap v4 requires currency0 < currency1 by address. Roughly 1 in 20 tokens happen to sort below WETH's address (0x0Bd7…AcAD73) and become currency0 instead of the more common case where WETH is currency0. The factory handles both orderings correctly, placing the single-sided position on whichever side of current price keeps it 100% token-only.
Swap Mechanics
The on-chain mechanics behind every buy and sell - what the router actually does. For the UI you click through, see Trading & Charts.
Buying
Send ETH to router.buy() with the pool key and a minimum-tokens-out amount. The router wraps your ETH to WETH, executes the swap, and sends the resulting tokens straight to your wallet in the same transaction.
Selling
Approve the router for the amount you're selling, then call router.sell(). The router pulls your tokens, swaps them, unwraps the resulting WETH back to native ETH, and sends it to you.
Slippage protection
Both directions take a minimum-output parameter. If the actual fill would return less than that minimum - from price movement, thin liquidity, or a partial fill - the entire transaction reverts. Nothing is spent and nothing is received; there's no partial-execution state to end up stuck in.
The router validates that the pool key's hook address matches the deployed Hood Prntr hook before doing anything else. A pool key pointing at a different hook is rejected outright, rather than silently trading against something unexpected.
Partial fills
If a swap can't fully fill at the requested size - the position's range runs out before the full amount is consumed - the router refunds whatever wasn't actually spent (leftover ETH on a buy, leftover tokens on a sell) rather than leaving it stranded.
Fees & Sniper Shield
Every printed token has its own trading fee, chosen once at print time. An optional shield can raise that fee sharply for the first half-minute a pool is live.
Trading fee tiers
At print time, the creator picks one of four fee tiers. This is the cut taken from every buy and sell on that specific token's pool, in WETH.
| Tier | Basis points |
|---|---|
| 1% | 100 bps |
| 2% | 200 bps |
| 3% | 300 bps |
| 5% | 500 bps |
Where the fee goes
Fees accumulate in the hook per pool. Calling collectFees(token) on the factory does not let the caller claim anything for themselves - it simply triggers the payout, which always goes to the same two places below no matter who calls it. Anyone is free to trigger that payout (so fees don't sit stuck waiting on the creator), but only the creator and the platform ever receive funds:
| To the token's creator | 30% |
| To the platform | 70% |
This split is a constant in the contract - not adjustable per token, not adjustable after deploy.
Sniper shield
Optional, set at print time. When enabled, the trading fee jumps to 85% for the first 30 seconds after a pool goes live, on both buys and sells, then drops to the token's normal tier.
The shield is measured strictly by block timestamp against when the pool was registered - there's no reliance on trade count or block number, so it can't be gamed by batching.
Security & Trust
What's true about the deployed contracts, checkable by anyone, not asserted on faith.
No liquidity-removal path
The factory has no removeLiquidity or withdrawLiquidity function - checked directly against the verified ABI, not just the source. The one place the contracts touch pool liquidity at all is a single, one-time, add-only call inside the print flow itself. There is no second code path that calls it again afterward, by the creator, the platform owner, or anyone else.
Sweep functions are scoped, not a backdoor
The factory has owner-only sweepETH() / sweepToken() functions. These only move whatever ETH or tokens are sitting directly in the factory contract's own balance - stray dust, failed refunds. Pool liquidity lives in the Uniswap v4 PoolManager singleton, which the factory has no privileged withdrawal path into. Worth stating plainly since the function names alone can look alarming without checking the implementation.
Verified, non-upgradeable
Hook, factory, and router are all verified on Blockscout - the deployed bytecode is checked to match this exact published source, not just self-reported. None of the three contracts sit behind a proxy or expose an upgrade path; what's deployed is permanent.
Guarded against common failure modes
- Reentrancy - state-changing entry points (
printToken,collectFees) use OpenZeppelin'sReentrancyGuard. - Zero-address deploys - every constructor rejects a zero address for any dependency it would otherwise be stuck with permanently.
- Slippage - both buy and sell revert entirely rather than fill at a worse price than requested.
- Settlement mismatches - every pool settlement is checked against the amount actually transferred; a mismatch reverts rather than proceeding silently.
- Wrong pool ID - the router validates a trade's pool key targets the real deployed hook before touching anything else.
These properties describe the currently deployed generation of contracts. See Smart Contracts for the exact addresses this documentation was checked against.
Audit process
Where things stand right now, plainly:
- Full test suite - buy and sell in both currency orderings, slippage protection in both directions, reentrancy protection, sniper-shield timing, repeated-claim protection, and rejection of pools that were never registered through the factory.
- Fuzz testing - the tick-alignment math specifically was fuzzed across thousands of runs after a manual review missed a real rounding bug at exact tick-spacing boundaries; the fuzz test caught it, the fix is deployed, and the test stays in the suite as a permanent regression check.
- Static analysis - run through Slither with zero High or Medium severity findings. Every Low and Informational finding was triaged individually: some led to real fixes (checked settlement return values, formal interface inheritance, removed leftover template code), others were confirmed as false positives on inspection (the tick-flooring arithmetic Slither flags as imprecise is intentional, exact integer alignment, not financial rounding).
- Verified and tagged - every deploy is verified on Blockscout immediately, and the reviewed commit is tagged in git against the exact deployed bytecode, so what was reviewed and what's live can always be checked against each other.
This is the project's own internal review, done ahead of and in preparation for a professional third-party audit. It's not a substitute for one. Treat it as a genuine, checkable starting point - not a claim that an independent audit firm has signed off on these contracts.
Disclaimer
Tokens printed on Hood Prntr are created permissionlessly by whoever prints them - the platform doesn't create, endorse, or vet any individual token. Anyone can print a token with any name, symbol, or logo.
Nothing in this documentation is financial advice. A printed token can lose all of its value; there's no guarantee of liquidity, trading volume, or price stability for any token, including ones referenced as examples here.
Smart contracts carry inherent risk. Testing and static analysis reduce that risk but don't eliminate the possibility of an undiscovered vulnerability, in these contracts or in Uniswap v4 itself. Do your own research before trading any token, and never risk more than you can afford to lose.
Smart Contracts
Every address a script, indexer, or curious reader needs - copy straight from here, or verify independently on the explorer.
Deployed addresses
| Contract | Address | Role |
|---|---|---|
| Factory (PRNTR) | 0x697FAbf62908cD9C1a18d0fF3520E4C000Bc8B80 | Creates every token, emits TokenPrinted |
| Hook (PRNTRHook) | 0x2fB8b35c8A29994B07E243526Cb83aBe8c3600cc | Fees, sniper shield, pool registration |
| Router (PRNTRRouter) | 0x06EAa292a3Aa172da6ceF862D26728c60823e841 | ETH-wrapping swap router |
| Vault (PRNTRVault) | 0x9159eA67435AFA1CC8C6Dd4BFca06C76947c07B5 | Custody for creator-locked tokens |
| PoolManager | 0x8366a39CC670B4001A1121B8F6A443A643e40951 | Official Uniswap v4 singleton |
| WETH | 0x0Bd7D308f8E1639FAb988df18A8011f41EAcAD73 | Quote currency for every pool |
Detecting a launch
The factory emits one event per print. tokenAddress and creator are indexed.
event TokenPrinted( address indexed tokenAddress, address indexed creator, uint256 startingEth, uint24 feeTier, uint160 sqrtPriceX96, bytes32 poolId, uint256 creatorBuyETH, uint256 creatorTokensReceived, bool sniperEnabled, uint256 lockExpiry );
Deriving a pool key
Every token trades against WETH in a Uniswap v4 pool. The key is fully deterministic from the token address alone - but currency ordering must be sorted correctly, or the derived pool ID will be wrong and look like the pool has no trades at all.
// Uniswap v4 requires currency0 < currency1 - sort WETH // against the token address numerically, don't assume WETH is c0. const wethIsZero = WETH.toLowerCase() < token.toLowerCase(); PoolKey { currency0: wethIsZero ? WETH : token, currency1: wethIsZero ? token : WETH, fee: 0x800000, // dynamic fee flag tickSpacing: 60, hooks: 0x2fB8b35c8A29994B07E243526Cb83aBe8c3600cc } poolId = keccak256(abi.encode(currency0, currency1, fee, tickSpacing, hooks))
About 1 in 20 tokens sort below WETH's address and become currency0. Skip the sort and you'll compute the wrong pool ID - the symptom looks exactly like "this token has zero trades," not an obvious error.
FAQ
Short, direct answers to what people actually ask.
No. The deployed factory has no function that removes liquidity from a pool, for anyone. See Security & Trust.
No. 100% of a token's supply goes into the pool at print time. A creator can optionally buy in themselves in the same transaction, which is visible in the TokenPrinted event - same mechanism anyone else uses to buy.
Only the token's creator (30%) and the platform (70%) ever receive the fee payout - that split is fixed in the contract. Anyone can trigger the payout by calling collectFees(token), but triggering it is not the same as receiving it: the caller gets nothing for themselves unless they happen to be the creator.
The trade reverts entirely - you keep your ETH or tokens, nothing partially executes. See Trading & Charts.
Some embedded chart widgets default to showing market cap rather than per-token price. If a chart looks inconsistent with a tiny per-token price, check whether it's toggled to market cap view.
Every contract is verified on Blockscout - read the source and the ABI directly against the addresses in Smart Contracts.
Tokens printed on the earlier version of the factory could trip this. That version's optional creator-lock feature worked by adding a transfer-restriction check directly inside the token's own _update function - narrow and opt-in in practice (only the factory could set it, only for the one address it was set for), but automated scanners can't tell "a dormant, opt-in self-lock" apart from a predatory blacklist or trading-cooldown mechanism, since both compile to the same underlying pattern: a function that can conditionally block one address from transferring. We confirmed this was the actual cause, not a guess - tokens that had never had the lock used at all still got flagged the same way, purely from the code shape being present.
The printed token contract has since been rebuilt as a plain, unmodified ERC-20 with no transfer-restriction code at all - the same pattern Clanker uses, which doesn't get flagged for exactly this reason. A creator lock now works through a separate custody contract, PRNTRVault: locked tokens are held there until the unlock time, then claimed back by the creator - the token itself never has any code capable of blocking a transfer, for anyone, ever. See Smart Contracts for the current addresses.
Both are a scanner reading real code correctly, but labeling it alarmingly without context it can't see. Any scanner that reads bytecode the same way would flag the same two things - it's not specific to one tool.
"Hidden Fees" is the sniper shield - an 85% fee for the first 30 seconds after a token launches, then the token's normal 1-5% fee after that. It's not hidden: it's a toggle on the print form ("85% tax on buys & sells for first 30s"), shown as ON/OFF on every token's own page, and covered in Fees & Sniper Shield. A scanner sees a large fee constant in the bytecode and flags it by default - it has no way to check whether that fee is disclosed anywhere off-chain.
"Liquidity Drain" is the creator/platform fee-claim function, and the finding's own description usually gives away the mislabel: it only ever withdraws fees the hook has already collected, not traders' pool liquidity. claimFees() moves already-collected trading fees, split a fixed 30% creator / 70% platform - it never touches the pool's actual reserves, and there's no owner override that could redirect it. It's the same mechanism behind the Claim Fees button on My Prints.
Every contract is verified on Blockscout - read the source yourself against the addresses in Smart Contracts.