Scherwode Graft A community should be able to move chains or relaunch without pretending the old contract is somehow the new one. Graft is basically how we are handling that on Scherwode. You escrow the legacy token, get marks, and those marks claim a finite portion of the new token on the destination chain. Not a tradable IOU, just a clean way to prove who migrated and what they are entitled to. The other part is liquidity. If there is recoverable capital from the old token, that gets moved over and matched into real liquidity on the new chain, so you are not just launching from zero again and hoping everyone buys the curve. Claims can unlock on a published schedule, anything unclaimed can burn, anything that never migrates can stay locked, and the actual relaunch terms are set before anyone deposits. Supply, dilution, direct launch vs curve, Wild vs Rooted, whatever makes sense for that project, but it is all disclosed up front. Not live yet, but we are building the rails for it now.

More than 50% of the basket supply is already burnt, and launch activity keeps feeding value back into what remains. Less supply. Stronger basket. scherwode.fun

LIVE NOW — Sprouted tokens. A token launches, people trade it, and part of that activity starts building a real perpetual position underneath it. That’s the basic idea. Scherwode handles the launch and token side. @artificeSystems powers the perpetual side, with positions settled on Hyperliquid. So instead of all the activity just disappearing into fees and liquidity, the launch starts growing something underneath itself. scherwode.fun/create

New site is live! A new home splash ...

quit telling people i’m dead. Scherwode has been quiet, mostly because we’ve been building, and a little dissapointed in the lack of launches. The first thing is the site. The current UI still feels too much like the version we launched with, and the product has moved past that. So we’ve stripped a lot of that back — a more modernized UI, a much simpler launch process, cleaner navigation, better discovery, less clutter, less friction. The goal is that you should be able to land on Scherwode, understand what you can do, and launch something without having to fight the interface first. The more interesting part is what we’re actually letting people launch. We haven’t gotten the traction we wanted with launches yet. That’s just true. But I still think the original idea was right: launches should be more interesting than make token, make pool, hope people buy it. We already built around rooted assets, baskets, different launch structures, different ways of deciding what actually sits behind a market. Now we’re pushing that further with a new perpetuals-backed launch type. There is already a ridiculous amount of liquidity, open interest and price discovery sitting in perpetual markets, so instead of pretending every new asset needs to start from zero, we want Scherwode launches to be able to use that existing market structure underneath them. That gives us a lot more room to do interesting things with launches, a place where you can build markets around actual underlying structure. And then there’s $WODE. We haven’t gotten the launch traction yet, but we do have an absolutely massive basket sitting behind $WODE, and we have mostly just... left it there. So we’ve been looking at that too ;) This week: a much simpler launch process, a more modernized UI, perpetuals-backed launches, some work around $WODE, and more.

Scherwode Did Not Need to Patch This Pons recently described a launch issue where token creation, pool creation, and the creator’s initial buy happened across separate transactions. That means the pool could become publicly tradable before the creator’s buy landed. A bot could see the pool, buy first, and force the creator to enter after them. It is a real issue. It is also not an issue Scherwode has. Scherwode was built from the ground up so that token creation, market creation, and the optional initial buy all happen inside the same transaction. There is no first transaction that creates the market, followed by a second transaction where the creator attempts to buy their own launch. There is no gap for a sniper to insert themselves into because the gap does not exist. On legacy Wild launches, the token is created, the bonding pool is initialized, and the initial buy is executed before the launch transaction finishes. On Wild V4 and Rooted launches, the market is opened and the factory purchase is executed atomically through the same launch call. The frontend also sends the launch and initial buy together. It does not create the token and then submit a separate purchase afterward. This is not a front-running patch. It is simply the correct transaction structure. Scherwode’s V4 launches also do not create an immediately open Uniswap pool and hope nothing goes wrong. Wild V4 and Rooted launches begin inside the DRAW phase. The pool may be initialized, but trading is still controlled by the Scherwode hook and DrawVault. External liquidity is blocked during DRAW. The factory-controlled initial buy can only be executed through the authorized launch path, and it can only happen once during creation. Public trading begins after the launch transaction is complete, through the controlled curve. Pons now needs platform-level hook whitelisting to repair a launch sequence that should not have been split in the first place. Scherwode designed the hook, vault, curve, factory, and launch transaction as one system from the beginning. When a Scherwode launch completes DRAW, liquidity activation and anti-snipe configuration happen together. The token receives a delayed market opening and enters a temporary restriction window. Default protections include maximum wallet and transaction limits during the first hour. Rooted launches also configure the hook protections before the graduated market becomes active. There is no separate migration transaction followed by another transaction that remembers to turn protection on afterward. Again, the sequencing is part of the protocol. Once the public curve is open, bots and traders can compete for entries. That is a market. A creator can also launch with no initial purchase. In that case, trading opens after the launch transaction completes and everyone begins from the same public state. Neither of those is the bug Pons described. The bug was allowing a market to open before the creator’s intended purchase had executed. Scherwode does not have that failure mode. Most launchpads are still assembling conventional pieces and then adding protection after somebody finds the opening. Scherwode was built as launch infrastructure. Creation, initial buying, controlled price discovery, liquidity formation, graduation, and anti-snipe protection are coordinated state transitions, not a chain of loosely connected transactions. There is no exposed create-then-buy window. There is no naked V4 pool waiting for the creator’s second transaction. There is no graduation gap where protection is added after the market becomes active. That is the difference between patching a launchpad and actually designing one.