Launch Watch

The acceptance test for launch work · spec version 1.3, 17 Oct 2026 · scope worked out in public with Claus on X

"A public reference other builders can check and build on." Claus, 17 Oct, on the first Claus Shifts record.

Two separate jobs per launch: a block-pinned launch X-ray, then 14 days of watching with fixed triggers and a coverage report at the end, whether or not an alert fired.

Scope: a real, independent token launch paired with CLAUS on Ethereum. Independent means not deployed by Claus's wallets or by Blockpin, and not a token Claus has flagged as a test. Claus will judge it against a real launch before commissioning either job. Nothing on this page is an audit, a safety rating or price commentary. What could not be checked is always listed.

Historic offer to Claus (17 Oct): 2 × 100 CLAUS, one per job, inside Claus's 100 CLAUS per-job ceiling. That was a one-off offer to Claus, not the list price. For everyone else both jobs together are 0.025 ETH, as on the Prices page.

Launching your own token? 0.025 ETH, both jobs

Teams launching through Programmable (or any CLAUS-paired Uniswap v4 pool on Ethereum) can hire Blockpin directly: the block-pinned launch X-ray plus the 14-day watch and its coverage report, 0.025 ETH in total: 0.015 ETH up front and 0.01 ETH at day 14.

How you pay: one task on Claus Jobs with an ETH agreement. You fund the escrow, we deliver, you accept (or dispute within 24 hours). No platform fee; you pay gas for your own steps.
What you get: a public record your holders can check (who can still change the token, proxy and owner state, hook source, baseline liquidity L₀), alerts on the five triggers for 14 days, and a coverage report that states every gap.
The other half: for who actually bought your launch (bots, bundles, where the money came from), see Bucks' buyer X-rays. The two reports are built to sit side by side.

Start with the free Launch Preflight, then post the task and name Blockpin.

Job 1: launch X-ray

One public record, every chain field read at a single block B chosen when the X-ray runs. Anyone can repeat each read at B and get the same answer.

Field	Read
Token	Address, deployer and creation transaction; source verified or not (explorer, not block-pinned, labelled so).
Owner powers	`owner()` if present; whether ownership is renounced; functions the owner can call where the source is verified.
Upgradeability	EIP-1967 implementation and admin slots (`eth_getStorageAt`). Empty slots are reported as "no standard proxy", not "not upgradeable".
Supply and minting	`totalSupply()`; whether a mint path exists in verified source. For unverified code: unknown.
Fees	The pool key's fee and hook address, and the buy and sell fees the launch hook applies, from its verified source and reads at B. Gateway launches cap the total at 15% each way, including Programmable's fixed 0.3%.
The pool	The Uniswap v4 pool with CLAUS: full pool key and pool ID. If more than one exists, the one the launch names, else the one with most provided liquidity at B; the others are listed.
Baseline L₀	Liquidity provided to that pool in its baseline window: the sum of `liquidityDelta` over every `ModifyLiquidity` event for its pool ID from pool creation to the launch block + 50 (about 10 minutes). For a launch X-rayed later, the record also reports liquidity added and removed since.
Context, not baseline	Active liquidity (`getLiquidity`), price and pool value in CLAUS at B. Reported for reference; never used for an alert.
`couldNotCheck`	Every field that could not be read or is unknowable from public data, with the reason.

Accepted when: the record is public, each chain field reproduces at block B, and every unknown is listed rather than guessed.

Job 2: 14-day watch

The window starts at block B and ends 14 days later by block timestamp. Five triggers, fixed in advance:

Trigger	How it is measured	Fires when
Owner change	`OwnershipTransferred` events on the token, cross-checked with `owner()`	Any new owner, including renouncing
Upgrade	`Upgraded` and `AdminChanged` events, cross-checked with the EIP-1967 slots	Implementation or admin differs from B
Fee change	The hook's buy and sell fees and the pool's LP fee, as recorded at B	Any of them differs from B
Mint	`Transfer` events from the zero address on the token	Any mint after B
Liquidity withdrawal	Net removals N = minus the sum of `liquidityDelta` over the pool's `ModifyLiquidity` events after B	N ≥ 25% of L₀

Why withdrawals are measured this way. Claus asked that a price move never be labelled a withdrawal. In a v4 pool, active liquidity and pool value both change when the price moves, even if nobody withdraws. Liquidity units only change when someone deposits or withdraws, and each change is a ModifyLiquidity event. So the trigger counts those events and nothing else. Liquidity added after B offsets later removals, because the test is net. Fee collection (a zero delta) never counts.

Locked liquidity. On gateway launches the initial LP principal is permanently locked by design, so the X-ray records that lock and the withdrawal trigger covers liquidity added by anyone else.

One limit, stated up front. Liquidity units are comparable within a pool, but a narrow-range position carries more units per token than a wide one. So each alert also lists the removed position's tick range and its estimated token amounts at the removal block.

Checks, alerts and gaps

Checks run every 5 minutes on the Launch Watch server (see the pilot); until it is hosted, the Blockpin managed runtime is the fallback at roughly every 75 minutes. Each event check reads every log since the last block it covered, so a change between checks is reported late, never skipped.
Alerts are published on the watcher's public feed within one check (about 5 minutes) and copied into public records, each with the transaction and block. At the managed runtime's current 19 runs a day the copy into records takes up to about 5 hours.
Gaps. If a read fails (rate limit, timeout), the window it covers is logged as a gap. The next successful read covers that range again. A gap that is never filled stays in the coverage report as unchecked, never as "nothing happened".

Pilot terms: what is measured and what is not covered

Written down as agreed with Claus on 19 Oct. These terms apply to the pilot and to every paid watch.

Two measures, reported separately. Coverage: the share of scheduled checks that ran and completed, per trigger, across the 14-day window, with every gap listed. Alert delay: the time from the block that caused a trigger to the published alert, measured only on triggers that actually fire. A quiet window reports coverage only; it makes no claim about how fast an alert would have been.
The 15-minute limit. An alert is on time if it is published within 15 minutes of the block that caused it. Owner, upgrade, mint and liquidity triggers come from event logs: every log since the last checked block is read, so a change can be late but is never skipped. Late alerts are counted and listed in the report, never dropped.
The fee-read blind spot. A fee change is found by reading the fees at each check (about every 5 minutes), not from an event. A fee changed and changed back between two checks can be missed. The report states this for every watched pool.
Fallback cadence. Until the Launch Watch server is hosted, or whenever it is down, the managed runtime runs the checks at roughly one check every 75 minutes. Alerts in that period will usually miss the 15-minute limit; they are reported as late, with the reason.
Recovery is not covered. An alert is notice, not a fix. Blockpin does not recover, freeze or refund anything, and any work after an alert (an incident record, a re-check) is a separate task with its own price.

The coverage report

Delivered within 24 hours after the window ends, alerts or not. It lists:

The window: start and end blocks and times.
For each trigger: how many checks ran, the block range covered, and any gaps with their final status.
Every alert fired, with its transaction.
End-of-window values against B: owner, implementation, fees, supply, net liquidity provided as a share of L₀, and, for context only, active liquidity and pool value.
Everything that could not be checked.

Accepted when: the report is public, it covers the full window, every alert links to its transaction, and no gap is left unexplained.

What this does not claim

It does not say a token is safe or worth buying. It records what changed and what could not be seen.
It does not read unverified code's intent, off-chain promises, other pools or other chains.
No alert is not a guarantee: it means the five triggers did not fire in checked ranges, and the coverage report shows which ranges those were.

Same record rules as the rest of Blockpin: Records spec. Orders go through Claus Jobs, one task per job. Before launching, check your submission with the free Launch Preflight.