Docs / Introduction
// Hood Prntr Protocol

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.

1B
Supply per token
100%
Deposited to pool
0
removeLiquidity paths
4663
Chain ID

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.

i

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.

// Start Here

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. 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. 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. 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

ChainRobinhood Chain
Chain ID4663
RPChttps://rpc.mainnet.chain.robinhood.com
Explorerrobinhoodchain.blockscout.com
DEX engineUniswap v4
// Using The Web App

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. 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. 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. 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. 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.

i

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.
// Using The Web App

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 minOut protection 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.

// Using The Web App

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:

FieldWhat it shows
Fee tierThe trading fee this token was printed with (1/2/3/5%) - fixed at print time, can't be changed after.
LiquidityThe starting ETH value used to set this token's launch price (1-10 ETH).
SniperWhether the 85% anti-snipe fee was enabled for this token's first 30 seconds.
LockIf 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 / ExplorerJump 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.
i

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.

// Using The Web App

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.

// Using The Web App

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.

BridgeNotes
Relay Protocol RECOMMENDEDFastest of the three - median 2-second execution, widest route selection.
Across ProtocolOptimistic bridge, covers ETH and major tokens.
Arbitrum Bridge OFFICIALThe 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.

// Using The Web App

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.

// Protocol Mechanics

How Printing Works

One transaction takes a token from nonexistent to tradeable. Here's exactly what printToken() does, in order.

CALLER wallet FACTORY 1. mint 1B supply 2. build pool key 3. unlock pool mgr POOL MANAGER initialize + seed single-sided liquidity HOOK registerPool() fee tier + sniper flag ROUTER buy() / sell() live printToken() seed pool register pool live
Fig. 1 - printToken() mints supply, seeds the pool, and registers it with the hook, all inside one transaction. The router only becomes usable once registration completes.

Step by step

  1. 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. 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. 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. 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.

WETH IS CURRENCY0 (common case) tick floor tick ceiling 100% TOKEN current price buys push price down, into position TOKEN IS CURRENCY0 (~5% of tokens) tick floor tick ceiling 100% TOKEN current price buys push price up, into position
Fig. 2 - Same single-sided design, mirrored. Whichever side of current price the token sits on, the liquidity is 100% token until buys move price into the range.
// Protocol Mechanics

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.

// Protocol Mechanics

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.

TierBasis 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 creator30%
To the platform70%

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.

85% 1–5% t = 30s t = 0 (launch) shield active normal fee tier
Fig. 3 - With the shield on, any trade inside the first 30 seconds pays 85% regardless of the token's chosen tier; every trade after pays that tier as normal.

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.

// Trust

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's ReentrancyGuard.
  • 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.
i

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.

// Reference

Smart Contracts

Every address a script, indexer, or curious reader needs - copy straight from here, or verify independently on the explorer.

Deployed addresses

ContractAddressRole
Factory (PRNTR)0x697FAbf62908cD9C1a18d0fF3520E4C000Bc8B80Creates every token, emits TokenPrinted
Hook (PRNTRHook)0x2fB8b35c8A29994B07E243526Cb83aBe8c3600ccFees, sniper shield, pool registration
Router (PRNTRRouter)0x06EAa292a3Aa172da6ceF862D26728c60823e841ETH-wrapping swap router
Vault (PRNTRVault)0x9159eA67435AFA1CC8C6Dd4BFca06C76947c07B5Custody for creator-locked tokens
PoolManager0x8366a39CC670B4001A1121B8F6A443A643e40951Official Uniswap v4 singleton
WETH0x0Bd7D308f8E1639FAb988df18A8011f41EAcAD73Quote 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.

// Reference

FAQ

Short, direct answers to what people actually ask.

Can a creator pull liquidity after printing?

No. The deployed factory has no function that removes liquidity from a pool, for anyone. See Security & Trust.

Is there a team allocation or presale?

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.

Who can claim trading fees?

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.

What happens if I set a bad slippage tolerance?

The trade reverts entirely - you keep your ETH or tokens, nothing partially executes. See Trading & Charts.

Why does the chart show a much bigger number than the token's price?

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.

How do I verify any of this myself?

Every contract is verified on Blockscout - read the source and the ABI directly against the addresses in Smart Contracts.

A trading bot flagged my token as "unsafe" - is that real?

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.

A scanner flags "Hidden Fees" and "Liquidity Drain" on a token printed here - is that real?

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.