How Pulse works
Four pieces, none of which can be switched off once set. Everything below is checkable on-chain — the last section shows you the exact calls.
Every pons launch mints the full supply into one Uniswap V3 position and hands the NFT to a locker with no withdrawal path. Immobile forever — that part is pons' guarantee, and Pulse builds on it.
The locker lets a coin's deployer choose where creator fees are paid.
Pulse points them at an immutable receiver — no owner, no upgrade path, no withdrawal
function. Assets can only leave as liquidity or the fixed protocol cut.
increaseLiquidity is permissionless on Uniswap V3 — a contract can deepen a
position it doesn't own and can never withdraw from. That one fact is the whole mechanism.
Anyone can trigger it, and the caller gets paid for doing so.
The launcher calls the pons factory, so the launcher is recorded as
deployer — permanently, with no renounce path anywhere in pons. It sets the
redirect exactly once and has no function to change it. Verified live: the creator, a
stranger, and pons' own locker owner all fail to move it.
Where every fee goes
Followed end to end for one trade on a Pulse coin.
Net: 1% fee × 70% creator share × 72% ≈ 0.50% of every trade goes into the position — that is the ceiling. Whatever the position cannot absorb at the current ratio is burned instead, so on a token-heavy pulse some of that 0.50% becomes supply reduction rather than depth. Measured on the first live pulse: 45% of the value deposited, 27% burned. Both are permanent; only one shows up as depth.
What the receiver guarantees
Four properties, fixed in the contract at launch and checkable by reading it. None of them is a policy we could change our mind about:
The only swap direction in the contract is WETH → coin. Token the position can't absorb is burned, not sold. Pulses are buys or neutral — never sell pressure.
2% of every pulse goes to whoever fired it. Searchers watch every coin around the clock; fees deploy the moment they're worth deploying.
The oracle is armed in the launch transaction and the price check adapts to the pool's age. A coin is crankable ~30 seconds after its first trade.
One crank deploys at most a fixed cap; the rest queues for the next. Worst case for any price games is a hard number, not a hope.
Pulse vs plain pons
| Plain pons | With Pulse | |
|---|---|---|
| Locked LP | Permanent, static | Permanent — and it ratchets up with volume |
| Trading fees | To the dev, forever | 72% back to the coin (deposited or burned) · 28% protocol |
| Dev fee income | ~0.7% of volume | Zero — that's the point |
| Fee redirect | Dev can move it anytime | Nobody can move it, ever |
| What buyers get | A promise | A commitment verifiable in two eth_calls |
Why a dev would do this
On a normal launch, "I'm putting fees into liquidity" is a promise — and the dev keeps the power to break it, because pons has no renounce path. Launch through Pulse and it stops being a promise: a buyer runs two calls and sees the redirect cannot move. The benefit to the dev is precisely that they gave up an option. That's what makes the signal cost something, and therefore worth something.
The honest version
deployer and can unwire it at any time.
Those coins are labelled REVOCABLE everywhere on this site. Only a coin launched through the
Pulse launcher is permanent.Protocol addresses
Where the 30% goes, read live from the launcher — the split and both destinations are immutable, baked in at deployment.
Reading the chain…
Verify it yourself
No claim on this site requires trusting us. For any token:
cast call $LOCKER "getLaunchedToken(address)" $TOKEN → read .deployer
# 2 — where do fees go right now?
cast call $LOCKER "feeRedirects(address)(address)" $TOKEN
If .deployer is the Pulse launcher and the redirect is the coin's receiver, the binding is permanent — the launcher has no function that can call setFeeRedirect again. If .deployer is a wallet, it can be undone tomorrow.
Lockers: active 0x736D…7F35 · legacy 0x31ca…54B5 ·
launcher 0x7752…7134. Full source and fork tests are in the repo.