Build with Sinjoh

Overview

Every buy and sell of your token earns fees, and the creator's share normally piles up in one wallet. That works out fine for the creator and does nothing for anyone else. The money leaves the moment it is withdrawn, and holders just have to trust whatever the founder says they will do with it.

Sinjoh swaps that wallet for a fee router: a small program with exactly one job, the one you gave it. It can pay you, buy your token back, burn it, send other assets out to your holders, and add liquidity that can never be pulled out. Whatever mix you pick gets written in before the token exists, and nobody can change it after that.

After launch it all runs on its own. Sinjoh keeps it moving so you never have to think about it, but every step is open to anyone. If we disappeared tomorrow, your holders could keep it running themselves.

Launching a token

Launching through Sinjoh is a real Pons launch. Your token gets the same fixed supply, the same locked WETH pool, the same launch protections, and trades on the same DEX as any other Pons token. The difference is one field: the fee wallet Pons pays creator fees to is your Sinjoh router instead of your own address.

The launch screen walks you through it in order, one signature per step, and every step is resumable if it is interrupted:

1. Predict. The exact token, pool, and router addresses are computed before anything is deployed, and the final launch call is simulated against the pinned, reviewed contracts.
2. Deploy the router. Your fee router is created at its predicted address with your full route written into it.
3. Launch through Pons. The token and its pool go live in one transaction, with the router installed as the fee wallet from genesis, so creator fees never touch a private wallet.
4. Bind. The router is bound to the launched token, and any optional first buy you made inside the launch is returned to your wallet.

The binding is verified end to end: the launch transaction must have been sent by the reviewed router, created the predicted token, and matched the route you authorized. Otherwise the token page is not published. Nothing about this flow can be rerouted mid-launch.

Pons v2, the default launchpad

New launches use Pons v2. A v2 launch follows the same router-first shape: predict, deploy the fee router and its Sinjoh adapter, then launch, bind, and make your first buy in one transaction, with different market mechanics:

1. Paired asset. Your token trades on a bonding curve against the pair asset you choose: native ETH or an approved asset such as USDG or a tokenized equity. Approval, graduation thresholds, and curve economics are read live from the Pons v2 factory, and fees are always earned in the pair asset.
2. Creator tax. On top of the curve's 1% base fee you can charge a creator tax, paid entirely to your fee route. The cap is set by Pons and shown live on the launch screen.
3. Launch window. Buys in the first seconds after launch pay a snipe tax that starts near 99% and decays to zero. Your launch and its first buy are exempt automatically; other wallets you list are exempted before trading opens.
4. Graduation. When the curve reaches its threshold, the market graduates into a Uniswap v4 pool that Pons controls.

The terms you are quoted are pinned into the launch itself: if Pons changes any economic parameter between the quote and your signature, the launch reverts instead of executing on repriced terms. Creator fees accrue to a Sinjoh adapter, the only address that can claim them from the v2 escrow, and anyone can trigger the claim that forwards them into your immutable fee route, the same guarantee the v1 flow gets from its router.

Pools, Uniswap's launchpad

Pools (pools.trade) is Uniswap's launchpad on Robinhood Chain, offered as a third venue with two launch modes. There is no bonding curve and no graduation on either: an instant launch puts the entire fixed 1B supply into a live Uniswap v4 pool in the launch transaction, so trading starts immediately at a fixed opening price; an LBPlaunch runs a continuous clearing auction and then migrates the raise into a v4 pool. Neither mode charges a launch fee, and there is no snipe tax, so an instant launch's first buy cannot be front-run inside the launch transaction, and auction bids all pay the same clearing price, so there is nothing to snipe.

1. Instant fee model. Creator fees are built in: 40% of the native side of the pool's 0.25% LP fee pays into your fee route, while trading fees partly auto-compound into liquidity on the token side. (Pools also has a no-fee variant; Sinjoh does not offer it. A launch that never produces a fee has no use for a fee route.)
2. Auction mode. You choose the supply, the raise currency (ETH or an ERC-20), the auction window in blocks, and a raise threshold. An auction that ends below its threshold refunds every bidder in full, so nothing is stranded. Team splits and atomic merkle airdrop legs are funded in the launch transaction itself.
3. LBP revenue. Three streams reach your fee route: your configured share of the raise, LP fees on the migrated pool's positions, and unsold auction tokens. The last normalized in capped chunks by design, so a large sweep drains over hours rather than moving against a thin pool at once.

Every Pools market is spot-priced from its Uniswap v4 pool, because v4 keeps no on-chain oracle, and the same predict → deploy → launch → verify pipeline applies: the adapter, router, and route you authorized are re-verified end to end before the token page is published.

letscash.fun, native ETH pairs

letscash.fun is an additional fixed-supply Uniswap v4 launch option. Sinjoh lists only enabled ETH-pair configurations on the current reviewed hook; upstream self-burn configurations and non-native quote assets are deliberately excluded. Burns remain available as a destination inside your Sinjoh route.

1. Predict first. The adapter and router addresses are fixed before the token exists, so the upstream launch can name the adapter as creator from genesis.
2. Launch, then activate. The first wallet transaction launches upstream. Sinjoh checkpoints its hash, verifies the receipt's token and pool, then asks for a second transaction to bind the immutable route. Either step can be resumed after a refresh.
3. Trade and measure. The token page uses the official letscash.fun SDK for quotes and swaps, and reads the same v4 pool for price history, market cap, volume, and holder data.

Project governance

Project V2 adds an immutable control plane to a Pons v2 launch using ETH or any factory-approved paired asset. Routing is always included. The creator can add either token voting with a timelock or a three-signer multisig, plus Project Treasury, Staking, signed Airdrop, and Raffle modules. Only the controls for modules that actually exist appear on the token's public workspace after launch.

The app assembles one reviewed launch profile, simulates the exact atomic Pons and Project transaction, and verifies the resulting Registry record before publishing it. Funding Bands remains a separate token-workspace action for eligible Pons v2 markets; it is not silently added to a Project launch.

Project routes can execute ordered direct sends, swaps, buyback-and-burn, and Treasury, Airdrop, Raffle, liquidity, or project-sink funding. Treasury is a valid recipient for every routed asset, not only WETH. Every adapter and price guard is checked against the active promotion's Merkle root before the Launcher accepts the configuration.

How fees flow

Trading fees first accrue in the selected launchpad's custody: liquidity fees can include WETH and your token, while letscash.fun's hook accrues the creator share in native ETH. From there, the Sinjoh pipeline runs the same way every time:

1. Collect. The launchpad adapter claims the creator share and forwards it into the router. Anyone can trigger collection at any time.
2. Normalize. The router swaps token fees to WETH so everything is measured in one asset, then takes the fixed 1% Sinjoh protocol fee.
3. Split. The remaining WETH is divided by the percentages you configured. A bucket can stay in WETH, buy your token back on the open market, or swap once into another asset with a funded WETH pool.
4. Deliver. Each bucket pays its recipients: wallets are paid directly, airdrop budgets move to the distributor, liquidity budgets move to the liquidity manager, and burns go to the burn address.

Every step is a separate, simulated, publicly callable transaction, and every amount is verifiable from chain data alone. Destinations come in two shapes: wallets (you, or any address you name) and sinks (the airdrop distributor and the liquidity manager). Sink destinations are frozen forever. The creator wallet can be repointed later only if you enabled that at launch. That is the single mutable value in the whole system.

Building a route

A route has two layers, and both are set once at launch. The first decides what your fees are converted into. The second decides who is paid out of each conversion. Every layer must add up to exactly 100%, and the builder will not let you authorize a route that could not execute on chain.

1 · What fees become

WETH and a buyback of your own token can each appear once. Other tokens and RWAs can be added repeatedly, up to eight conversions in total. The RWA picker only offers assets that actually have a funded WETH pool on the Pons DEX right now, and the launch flow re-verifies every pool before your wallet ever signs.

2 · Who gets paid

Each conversion pays out to up to ten recipients. Which destinations are available depends on what the fees were converted into.

Airdrops

An airdrop allocation turns a slice of your trading fees into recurring payouts for your holders, in WETH, in another token, or in a tokenized stock. Holders do not claim anything: payments are pushed to their wallets, proportional to what they hold.

Each round follows the same verifiable cycle:

1. Rebuild. Holder balances are reconstructed from archive history and independently verified against the snapshot block.
2. Attest. A deterministic Merkle-sum artifact is committed by an isolated attestor while the snapshot is still inside its confirmation window.
3. Push. Payments go out in batches. This step is permissionless, so anyone can finish a round the keeper started.

Entitlements are cumulative: each round's record builds on the last, so a missed round is never lost. It is paid the next time the pipeline runs. Pools, protocol contracts, and the creator are excluded from snapshots, so the budget goes to actual holders rather than back into infrastructure.

Permanent liquidity

A liquidity allocation makes your pool deeper forever. WETH routed to liquidity is swapped roughly 50/50 into your token and WETH, then minted as a position in your token's own pool. The principal is protocol-owned and permanent: there is no withdrawal, no transfer, and no rescue path. Not for you, not for Sinjoh, for anyone.

The position earns trading fees like any other, and those fees are recycled: they compound back into the position's own budget and become more permanent liquidity on the next mint. Once a route sends fees to liquidity, depth only ever increases.

Holder raffles

A launch can add a Holder Raffle: an immutable per-launch contract that pays prizes to holders from a pool funded by the token's own fee routing. Holders are entered automatically just by holding. No signup, no tickets to buy, and no claiming. The keeper snapshots balances, draws winners with publicly verifiable randomness, and pays them straight to their wallets.

Tickets scale with holdings: one ticket per configured amount of the token. The recommended basis counts each wallet's lowest balance across the snapshot window, so buying right before a draw earns nothing. Each draw pays a fixed share of whatever the pool holds: a percentage, never a fixed obligation, so the raffle can never run dry. Launchpad infrastructure (the venue's own market and custody contracts, and the Sinjoh contracts) is excluded from winning at deployment, permanently.

A raffle can pay WETH, swap each winner's prize into one specific stock chosen at launch, or run as a Mystery Stock raffle that picks from 25 tokenized stocks ($AAPL, $AMC, $BB, $BE, $COIN, $COST, $CRCL, $DJT, $GME, $HIMS, $INDA, $LLY, $META, $MSTR, $MU, $NVDA, $QQQ, $RBLX, $RDDT, $SGOV, $SNDK, $SPCX, $SPY, $TSLA, $TSM) per-winner with the same verifiable randomness. A specific stock choice is immutable and every winner receives that asset. Every stock route runs through a reviewed swap adapter under a five-minute price guard; winners never set slippage, and a route that cannot execute keeps the prize as a retryable credit with a WETH fallback for the winner. Only routes that passed an on-chain preflight are offered.

Developer integration

The public protocol API is available at api.sinjoh.com/v1 ↗. It needs no key for the anonymous 60-requests-per-minute tier and exposes deployments, launches with optional Project V2 identity, markets, raffles, airdrops, liquidity, Funding Bands, revenue, randomness, normalized events, and wallet activity. The API contract is published as OpenAPI 3.1 version 1.3.1.

Install @sinjoh/sdk@2.2.5 for typed reads, launch builders, complete Project V2 routed-action encoding, transaction preparation, and verification helpers. Use @sinjoh/abis@2.2.5 and @sinjoh/deployments@2.2.5 when you need the exact generated contract and deployment surfaces. All are published under Apache License 2.0 from the canonical SDK repository ↗.

@sinjoh/agent@2.2.5 provides the MCP server. Its Project tools preview and validate a launch, read complete Registry records, and prepare and simulate the exact atomic Pons Project transaction with its reviewed route proofs. The server holds no wallet keys and never signs or submits transactions.

Checking rewards for a wallet

• Paid raffle prizes. Filter the API winner history or the indexed PrizePaid and StockPrizePaid events by holder. This is payment history, not a pending-win check.
• Deferred raffle delivery. Read owed(wallet) and stockOwed(wallet, asset)on each launch's raffle clone. A positive value means a valid winning payout was settled but its transfer failed; anyone can retry delivery.
• Pending raffle wins. There is no single on-chain claimable(wallet)view and no public proof endpoint today. A pending win requires the drawn round, unpaid slot, winning index, and the wallet's committed Merkle leaf and proof from the keeper artifact. Do not infer it from current token balance.
• Holder airdrops. These are push distributions. Holders do not claim, approve, sign, or pay gas. For a known airdrop account, paid(accountId, wallet) is cumulative delivery, not a pending entitlement.

Shared deployments are listed below. Every launch has its own raffle clone, so discover that clone through GET /v1/raffles or the factory's RaffleDeployed event, then verify its subject() before trusting it.

Automation

Everything above is permissionless, which means it does not need you. Independent routing, airdrop, raffle, randomness, and Funding Bands workers run the production pipeline. They do not hold protocol assets or choose destinations, so automation never becomes a custody assumption: each worker can only advance the immutable onchain configuration.

The routing keeper handles all of this on its own:

It re-plans against fresh onchain state every 15 seconds, attempts a Pons collection every 5 minutes, and performs one simulated action per transaction, waiting for 2 confirmations before planning the next. The airdrop worker runs legacy and signed Project V2 snapshot cycles on their configured schedules. Raffle and randomness workers progress drawings and delivery, while the Funding Bands guard independently observes eligible v3 TWAP state.

Fees

Three fees exist in the whole system, and each one is fixed and public. There are no hidden spreads, no performance fees, and no fee that can be raised later.

The 70% creator share is what your router routes. Sinjoh's 1% is taken when fees are normalized to WETH, before your split is applied, and flows to the protocol revenue collector. Everything after that follows your route to the last percentage point.

Security model

• Settings are permanent. Splits, destinations, and pool routes are written at launch. Nothing can change them afterwards: not the creator, not Sinjoh. The one exception, repointing the creator wallet, exists only if you enabled it at launch, and can touch nothing else.
• No operator keys. Routers have no owner, no upgrade path, no sweep, and no rescue call. The keeper keys can only trigger actions anyone else could trigger too.
• Nobody controls the trigger. Collection and processing are open to every address, so the system cannot be quietly switched off or timed to benefit an insider.
• Routes stay simple. Token fees swap to WETH first. Each output then uses at most one direct WETH pool, and callers cannot substitute another adapter, pool, or fee tier at call time.
• Prices are checked. Liquidity mints are gated by a time-weighted price check on the token's own pool, so a manipulated price pauses the pipeline instead of draining it.
• One router per token. Each launch gets its own contract holding only that token's fees. Nothing is pooled across launches.
• Outcomes are verifiable. Payments, airdrops, and LP mints are ordinary transfers, auditable from chain data alone. The launch itself is verified against the reviewed contracts before a token page is ever published.

Risk disclosures

• Immutability cuts both ways. The same permanence that protects holders means a mistake in your route is forever. Review the summary panel carefully. There is no edit button after launch.
• Liquidity is one-way. LP principal minted by the router is permanent. There is no withdrawal, transfer, or decrease-principal path, for anyone, ever.
• Markets are markets. Buybacks, burns, and deeper liquidity do not guarantee a higher price. Tokens can be volatile, illiquid, or lose all value.
• Dependencies can fail. Sinjoh builds on Pons, the Pons DEX, and Robinhood Chain. Wallets, RPCs, and indexers can fail; displayed values are estimates, not execution guarantees.
• Unaudited software. The contracts are immutable and public, but unaudited. Launching a token risks total loss. Read the contracts before trusting them with value.

Network & contracts

Everything Sinjoh does happens in these contracts. They are deployed once and reused by every launch: the only thing created per token is that token's router. Deployed contracts are immutable. If a new version ever ships, it ships as new addresses, and existing launches keep running on the contracts they were born with.

Parameters

Routing uses one shared, reviewed swap adapter. The launch flow resolves a funded direct WETH pool for every asset you pick and never asks you for adapters, guards, pools, or encoded route data.