What runs today,
and what does not.

Introduction

BTC Foundry is a launchpad front-end on Robinhood Chain. Today it does one thing end to end: it calls the live pons.family launcher and sets the creator fee wallet to an address the foundry controls. The other half of the design — sweeping those fees and converting them into permanent wBTC-paired liquidity — is described below and is not deployed yet.

The design goal is narrow: make the value that a launch already generates accrue to the people holding it rather than to whoever deployed it, without asking anyone to trust a treasury or a multisig.

Architecture

There are two halves. The first is live and is not ours: the pons launcher at 0x0c37a2…77a4 on Robinhood Chain. Every launch on the platform, including every launch made from this site, is a call to its launchToken() function.

launchToken(
  ( string  name,
    string  symbol,
    string  image,
    string  description,
    ( string x, string telegram, string _, string website, string _ ) socials,
    address creatorFeeWallet ),      <-- the only field the foundry changes
  uint256 configId,
  uint256 dexId,
  bytes32 salt
) payable

The second half is the sweep contract, and it does not exist yet. Its job would be to hold the collected creator fees, split them, buy both legs and deposit them as liquidity — with no function that ever takes liquidity back out.

The sweep

"Keeper" is just a name for whatever pokes the sweep on a schedule — a cron job, a bot, a person clicking a button. It holds no keys over the money and decides nothing. The call is meant to be permissionless, so if the usual trigger stops, anyone can run it and pay the gas.

1. balance = address(this).balance      // fees pons already paid in
2. if (balance == 0) return;           // nothing to do, costs a little gas
3. (a, b) = split(balance, splitBps)
4. buyToken(a)                         // market buy of the launch token
5. buyReserve(b)                       // market buy of wBTC
6. addLiquidity(a', b')                // deposited, never withdrawn

Step 2 is what makes a schedule cheap: a token with no volume earns no fees, so the sweep finds nothing and returns.

Split and routing

splitBps is the share, in basis points, that buys the token back. The remainder buys the reserve asset. It would be set when the sweep contract is deployed and never changed afterwards.

Both legs route through an ordinary DEX at execution time. They take ordinary price impact, and there is no protection against a sandwich beyond a slippage bound.

Reserve accounting

Deposits would be additive and monotonic: every sweep adds to the same position, and no function decreases it. The figure shown on Explore would be the cumulative ETH value deposited, not a mark-to-market of the position.

• The position is owned by the contract, not by the deployer.
• Fees the position itself earns accrue inside it.
• There is no remove-liquidity function.

One open question, honestly: Robinhood Chain has several tokens calling themselves wBTC. Which one is canonical has to be settled before a single wei is spent on it, and nothing on this site hard-codes an answer today.

Launching a token

One transaction, sent by your own wallet to the pons launcher. The site never holds funds and never sees a key.

value = 0.0005 ETH (pons launch fee) + your developer buy
salt  = 32 random bytes
configId = 0, dexId = 0        // pons defaults

creatorFeeWallet = the foundry's address
                   (or your own, if you leave the field empty)

pons charges a graduation fee of 4.2 ETH when a launch graduates to a locked Uniswap pool. That is pons's fee schedule, not the foundry's.

Integration

There is no private API. The launch feed on this site is built from public Blockscout data, filtered to launches whose creator fee wallet is the foundry's.

GET /api/v2/addresses/{launcher}/transactions?filter=to
GET /api/v2/transactions/{hash}
GET /api/v2/transactions/{hash}/internal-transactions

base: https://robinhoodchain.blockscout.com

Anyone can reproduce the same list without asking this site for anything.

Security notes

Two properties do the work here, and both are structural rather than procedural.

• Supply is fixed by the pons launcher; this site does not deploy its own token.
• Liquidity is locked by pons at graduation, not by anything here.
• The site never custodies funds — every transaction is signed by your own wallet.

What is not guaranteed: the market price of any token launched here, the depth of a reserve for a token that never traded, or the behaviour of the venues the buys route through. A deep reserve makes a floor, not a promise.

The sweep contract is not written or deployed, and no audit has been done. Anything on this site describing scheduled sweeps is the design, not a running system. What is real today is the launch call and the fee-wallet routing.

FAQ