Read the recipe.

Overview

PATTY is a launch kitchen for Pons V2 on Robinhood Chain. Bring the coin, choose a recipe, and read the order before signing.

• Today, the machine builds one launch call to the Pons V2 wrapper.
• Your connected wallet signs the call and is the creator fee recipient.
• Your recipe appears in the launch review only. It is not stored on chain.

The PATTY router is not deployed. Choosing a recipe does not switch on fee routing. The console builds the call, shows its details for review, and sends it from the connected wallet when you sign.

Getting started

The machine has four screens: coin details, links, recipe, and launch review. These five steps include connecting the wallet on the review screen.

1. Open the machine

   Open the PATTY machine. Start with the coin details. You can fill in the order before connecting your wallet.

2. Name the coin and add its logo

   Add a name, a ticker of 2 to 8 letters, a description, and a logo. On the links screen, add an X link and an HTTPS website. Both links are required.

   Logo upload needs a configured provider. If the upload endpoint responds with 501, the machine says ?Image upload is not switched on for this site yet.? You cannot continue past coin details until upload is available and a logo URI is set.

3. Pick a recipe

   Choose Direct, OHM fork, or Miner, then review the five cuts. Adjusting one cut redistributes the others. Seigniorage is marked soon and cannot be selected. Optional team wallets skip the launch-window tax; your connected wallet is already exempt.

4. Connect your wallet

   On the launch screen, connect the wallet you want to use and switch to Robinhood Chain if prompted. The screen shows its address, chain, and balance. That connected address is the fee recipient for this launch.

5. Review and sign

   The review shows the fee wallet, recipe name, all five splits, and a rounded total of 0.0175 ETH. Technical details show the wrapper, selector, salt, exemption count, and a launch config id field. That id currently displays a dash because this configuration supplies no value.

   Check the coin preview and the wallet request. The recipe remains in the review only. Nothing moves until your wallet signs the transaction.

What the launch call contains

The encoder uses wrapper selector 0xf85f8e41. Its launch tuple contains name, symbol, metadata URI, description, social links, the connected recipient, a creator-tax field fixed at 300 bps, disabled Pons buyback, another fixed zero field, and a salt. Social slots are X, Telegram, Discord, website, and Farcaster; the current form supplies X and website.

The outer arguments include the launch tuple, two zero fields, a fixed buy amount, another zero field, the connected recipient, and the optional exemption array. There is no recipe field in this call. The encoder accepts up to 31 optional exemptions and generates a random 32-byte salt when none is supplied.

The machine labels the fixed amount as 0.017 ETH starting buy plus a 0.0005 ETH launch fee, or 0.0175 ETH total. Precisely, the encoder sends 17500000000000002 wei (0.017500000000000002 ETH), with 17000000000000002 wei for the buy. That is two wei above the rounded label. Changing the optional starting-buy input does not change this encoded amount.

Recipes

These are presets of the same five-way fee split. The PATTY router is not deployed, so the splits are design targets, not live routing. Today, every selectable recipe uses the same wrapper launch transaction and leaves creator fees with your wallet.

Direct

60% buyback and burn, 15% creator, 10% coin treasury, 10% flagship, 5% caller bounty. This preset is designed to put the largest cut into buying the coin and sending it to the burn destination.

OHM fork

25% buyback and burn, 10% creator, 50% coin treasury, 10% flagship, 5% caller bounty. This preset is designed to put the largest cut into the coin treasury. The name selects a split; it does not deploy a separate OHM protocol.

Miner

55% buyback and burn, 10% creator, 20% coin treasury, 10% flagship, 5% caller bounty. This preset is designed around buying the coin for the burn destination, with a larger treasury cut than Direct. It uses the same launch call.

Seigniorage Soon

The proposed mode uses epoch emissions with pegs, shares, and bonds. It needs a separate seigniorage module and is outside router version one. There is no selectable split for it today.

Fees

The PATTY router is not deployed. Fee routing below is a design, not live behaviour.

On Pons V2, curve trades book a base fee and a creator tax. The base fee has a creator share; the creator tax goes to the creator in full when swept. Post-graduation creator fees can also reach the same escrow recipient through the hook.

Today, the creator recipient is your connected wallet. Fees credited to that address sit in Pons V2FeeEscrow until claimed. The machine reads the recipient from the token's factory record, then reads that recipient's escrow balance. Its Claim button sends claim() to the escrow. The claim pays only msg.sender, the calling wallet, and claims that recipient's full native balance across launches.

The router is designed to claim through a per-coin receiver and divide those fees across the plan's five cuts. Its flagship floor starts at 10%, a PATTY design target, not a live rate or a Pons rule. The router owner can lower that floor. Before a $PATTY treasury exists, the specified flagship destination is a placeholder wallet controlled by Ben.

The router

The PATTY router is not deployed. Everything in this section describes its design, not a live service.

One receiver per coin

The design uses one PattyRouter for plan logic and a separate PattyFeeReceiver for each launch. Pons escrow groups balances by recipient, not by token. A shared recipient would mix fees from different coins. Each receiver is therefore designed to be that coin's creator fee recipient, with its own escrow bucket.

Each receiver would have immutable router and creator addresses and be able to receive ETH. Only the router would instruct it to sweep, claim, forward tokens, or transfer the fee recipient. The router would keep immutable factory and escrow references; its owner would control the flagship destination and minimum flagship cut.

The four-call sequence

1. createReceiver(salt): the connected wallet would deploy its receiver before launching. The site could read predictReceiver to obtain the expected address.

2. launchAndBuy(...): the wrapper launch would use that receiver as creatorFeeRecipient, with Pons buybackEnabled = false. This would keep the creator bucket available to the receiver instead of the Pons buyback vest.

3. registerPlan(token, salt, plan): after launch, the original deployer would register the plan. The router would check the deployer, the predicted fee recipient, and native ETH quote support.

4. execute(token, minTokensOut): anyone would be able to trigger the plan when claimable fees meet its minClaimWei threshold.

The plan

The specified Plan would hold the following fields. Its five uint16 basis-point fields must sum to 10,000. The creator would be set once from the factory deployer.

struct Plan {
    address creator;
    address receiver;
    address treasury;
    address buybackTo;
    uint16 buybackBps;
    uint16 creatorBps;
    uint16 treasuryBps;
    uint16 flagshipBps;
    uint16 keeperBps;
    uint64 minClaimWei;
    uint64 planTimelock;
    bool active;
}

buybackBps would fund curve buys; creatorBps would pay the creator; treasuryBps would pay the named coin treasury; flagshipBps would pay the flagship destination; and keeperBps would pay the caller. The treasury could be the creator's own wallet. A zero buybackTo would select the burn destination; another address would receive the bought tokens. The router would deliver tokens to a named pool, without distributing them to holders itself.

minClaimWei would avoid dust-sized claims. planTimelock is specified as a constant 24 hours. active would gate execution.

Execution and the caller bounty

Execution is designed to run under a reentrancy lock, reject missing or inactive plans, and check that the receiver still owns the fee route and the quote asset is native ETH. The receiver would attempt to sweep curve fees, check the escrow threshold, claim its balance, and forward the claimed ETH to the router.

The router would split the claim and pay the caller from the keeper cut. Integer-division remainder would also go to the caller. The design would not require a funded PATTY keeper wallet. A failed payout would revert the execution.

While the curve can sell, the buyback leg would buy the coin and send it to the burn destination or the chosen pool. The caller would supply minTokensOut; the design rejects zero when a buy is attempted. After graduation, or when no sellable tokens remain, the buyback cut would instead join the treasury payout. Refunds from partial fills would also go to the treasury. Router version one would not swap on V4 and would never sell the coin.

Changing a plan

The creator would propose changes through proposePlanUpdate. A pending update would carry the five splits, treasury, buyback destination, claim threshold, and effectiveAt. After the 24 hour delay, anyone could call applyPlanUpdate. This delay would apply to plan updates; the emergency recipient return is a separate path.

Emergency recovery

For a registered plan, only its creator would call returnFeeRecipient(token, newRecipient). The receiver would transfer the fee route, claim its own remaining escrow balance, send it to the new recipient, and leave the plan inactive. Routing incentives would stop for that token.

If the creator never registered a plan, rescueUnregistered would let the receiver's creator return the fee recipient to themselves while no plan is active. Separately, the Pons factory owner has a recipient-override path with a 3 day timelock and a 3 day execution window. The PATTY design would not remove that Pons authority.

$PATTY

$PATTY is prelaunch. There is no token contract address yet. The configured token and vault fields are empty.

At go-live, the site's configuration is intended to publish the token address and switch to live mode. The homepage kitchen strip and contract-address line would change, the creator-fee input would prefill with the token address, and the token panel would switch to on-chain reads. The go-live procedure leaves the vault empty.

The flagship cut exists in the router design. The router is not deployed, so that cut is not being routed by PATTY today. Its initial destination is specified as Ben's placeholder wallet until a real treasury is set. The rest of the $PATTY holder programme, including any airdrop or snapshot programme, is not decided.

Security

Your wallet signs each transaction. The site sends requests to your selected wallet provider and holds no signing keys. The escrow claim pays only the caller's credited balance; it cannot claim for another wallet. The machine disables Claim when your connected address does not match the recorded recipient.

PATTY contracts are unaudited. The deployed Pons contracts are linked below so you can read their on-chain code and available source on the explorer. The PATTY router is not deployed and has no live address to inspect.

Wallets

The console discovers injected wallets through EIP-6963 and offers an inline chooser when it finds several. If none announce, it falls back to window.ethereum. If no wallet is found, install a wallet that supports Robinhood Chain, then reload. Connecting can request a network switch or add the configured chain.

Contracts

These are the configured Pons V2 contracts on Robinhood Chain, chain id 4663 (0x1237). They are shared infrastructure, not a $PATTY token or a deployed PATTY router.

State reads try https://robinhood-rpc.publicnode.com first, then https://rpc.mainnet.chain.robinhood.com. Log reads try the official endpoint first. Wallet signing goes through the connected provider.

FAQ

Does choosing a recipe turn on buybacks?

No. The router is not deployed. Recipe splits stay in the launch review; today's transaction sends creator fees to your wallet.

Does OHM fork deploy an OHM system?

No. It selects the treasury-led split preset. Direct, OHM fork, and Miner all use the same launch call.

Can I choose a smaller starting buy?

The current encoder uses a fixed buy amount. The optional starting-buy field does not change this transaction. See the exact amounts in Getting started.

Why will the logo step not continue?

It requires a logo URI from a successful upload. If the upload service is not switched on, the machine shows that message and blocks the step until the service is configured.

Why can I read fees but not claim them?

The fee reader looks up the token's recorded recipient. Claim requires that same wallet to be connected. A different wallet cannot claim its balance.

Where is the $PATTY contract address?

There is no $PATTY contract address yet. It is prelaunch; the site is intended to publish the address at go-live.

Would I need to run a keeper?

In the router design, anyone could call execute and receive the plan's caller bounty from claimed fees. The router is not deployed, so that execution path is not available today.

Could I change a recipe or stop routing later?

The router design includes plan changes after a 24 hour delay and a separate creator-only fee-recipient return. The router is not deployed. Those controls do not exist in today's launch flow.

Risk

Memecoins can go to zero. PATTY contracts are unaudited. You review and sign every transaction yourself.