[MEDIUM] Batched launch can publish and keeper-register before mandatory insurance verification

[Bayyan16]

Summary

The fresh batched market-launch flow can start two externally visible registration side effects before the mandatory insurance seed has been successfully verified:

1. registration in the markets database;
2. keeper registration for keeper-oracle markets.

If M3b fails, or the resulting on-chain insuranceBalance remains below the requested amount, the launch correctly throws an insurance-seed error. However, the database and keeper requests may already be in flight or may already have completed.

This can leave a market visible or keeper-registered even though the launch is reported as failed because its mandatory insurance invariant was not satisfied.

Severity

Medium

This report does not demonstrate direct fund theft, unauthorized signing, an on-chain authorization bypass, or protocol insolvency.

The impact is an inconsistent launch state across the on-chain market, application registry, keeper service, and user-visible launch result.

Affected baseline

Repository: dcccrypto/percolator-launch
Branch: playground
Commit: ce15a20a039ded7248204bed30f45952fb69a954

Affected path

app/hooks/useCreateMarket.ts

Affected function:

attemptFreshBatchedLaunch()

Root cause

The fresh batched flow correctly treats the requested insurance seed as mandatory:

if (insuranceOnChain < params.insuranceAmount) {
  throw new Error(
    `Insurance fund was not seeded ...`,
  );
}

However, both external registration operations are initiated before that invariant has passed.

The affected ordering is effectively:

create keeperRegisterPromise
...
broadcast M3a
start marketsRegisterPromise
broadcast M3b
read insuranceBalance
throw if insuranceBalance < requested amount
await keeperRegisterPromise
broadcast M4
await marketsRegisterPromise

Promises begin executing when they are created. Awaiting them later does not defer or cancel the underlying registration request.

Therefore, an M3b failure or an under-seeded insurance balance can occur after one or both registrations have already started.

Expected invariant

No externally visible registration should begin until the required insurance outcome has been verified.

The intended ordering is:

M3a
M3b
read and verify insuranceBalance
start markets database registration
start keeper registration
await keeper registration
M4
await markets database registration

Keeper registration must remain before M4 because StakeInitPool rotates marketauth, while keeper registration requires the deployer authority to remain valid.

Impact

A failed mandatory insurance seed can produce conflicting state:

launch result:
failed — insurance was not seeded

on-chain market:
created but under-insured

markets database:
registration may already have succeeded

keeper service:
registration may already have succeeded

Consequences may include:

• an under-insured market becoming visible in market discovery;
• keeper infrastructure accepting a market whose launch was reported as failed;
• retries operating against partially published external state;
• confusing recovery behavior for creators and operators;
• application state claiming that a market is available before all mandatory launch invariants have passed.

This report is intentionally not classified as High or Critical because no direct loss-of-funds path has been demonstrated.

Deterministic reproduction

A non-network regression test was added to the existing fresh-batched source-ordering suite:

app/__tests__/hooks/useCreateMarket-fresh-batched-registration.test.ts

The new assertions require:

expect(register).toBeGreaterThan(insuranceFailure);
expect(keeper).toBeGreaterThan(insuranceFailure);
expect(keeper).toBeLessThan(m4);

Before the fix

Command:

cd app

pnpm exec vitest run \
  __tests__/hooks/useCreateMarket-fresh-batched-registration.test.ts

Result:

Test Files  1 failed
Tests       2 failed | 6 passed

Observed source positions:

keeper registration : 32745
market registration : 33973
insurance failure   : 35413

Both registrations were located before the mandatory insurance-failure boundary.

All six pre-existing tests in the file remained green, confirming that the reproduction was isolated to the new ordering invariants.

Proposed fix

Move the invocation of:

const marketsRegisterPromise = registerMarketInDb();

and creation of:

const keeperRegisterPromise = ...

to immediately after the mandatory insurance-verification block and before M4.

Do not move or modify:

• signed keeper-cosign handling;
• M1, M2, M3a, M3b, or M4 transaction construction;
• sequential/recovery flow;
• registration-payload construction;
• API route behavior;
• the insuranceAmount === 0n best-effort crank behavior.

Regression result after the fix

The focused test changes from:

6 passed
2 failed

to:

Test Files  1 passed
Tests       8 passed

Additional adjacent tests:

insurance-idempotency.test.ts
useCreateMarket-keeper-register.test.ts
useCreateMarket.v17-matcher-recovery.test.ts
useCreateMarket.v17-matcher-resume.test.ts
useCreateMarket.feesplit.test.ts

Result:

Test Files  5 passed
Tests       19 passed

TypeScript:

pnpm exec tsc --noEmit
PASS

Production build:

pnpm build
PASS
Exit code: 0

Full-suite comparison

The repository currently contains unrelated pre-existing wallet/UI test failures.

A clean detached baseline worktree at commit:

ce15a20a039ded7248204bed30f45952fb69a954

was tested separately using the same dependency and environment setup.

Clean baseline

Test Files  4 failed | 260 passed | 1 skipped
Tests       14 failed | 2822 passed | 16 skipped

Patched worktree

Test Files  4 failed | 260 passed | 1 skipped
Tests       14 failed | 2824 passed | 16 skipped

The additional two passing tests are the two new ordering regressions.

The complete set of 14 failures was identical between baseline and patched worktrees and remained limited to:

__tests__/components/ConnectButton.test.tsx
__tests__/components/Header.test.tsx
__tests__/components/Portfolio.test.tsx
__tests__/hooks/useWallet.test.ts

No new failing test was introduced by this patch.

Duplicate and active-PR analysis

Searches across open and closed issues and pull requests were performed using:

insurance registration M3b
registerMarketInDb insurance
publish before insurance
under-insured registration
keeper registration insurance verification

No report addressing this exact ordering invariant was found.

Two open pull requests touched one of the same file paths:

PR #2451

This is a wallet/test-suite refactor. Its historical changed-file list included the fresh-batched registration test and useCreateMarket.ts, but its remaining delta against current playground is unrelated to the insurance-registration ordering.

It does not implement this fix.

PR #2434

This fixes mainnet Hyperp oracle-mode resolution in a different hunk of useCreateMarket.ts.

It does not modify the M3b insurance-registration ordering and is not a duplicate.

A temporary combined worktree was created by applying PR #2434 to current playground and then applying this insurance patch.

Compatibility result:

PR #2434 applies cleanly to current playground
insurance patch applies cleanly on top of PR #2434
no conflict markers
unique oracle and registration call sites

Combined validation:

Targeted tests  : 52 passed
TypeScript      : PASS
Production build: PASS
Diff checks     : PASS

Scope of the proposed patch

Files changed:

app/hooks/useCreateMarket.ts
app/__tests__/hooks/useCreateMarket-fresh-batched-registration.test.ts

The patch does not modify:

• API routes;
• database schema;
• keeper-route authentication;
• transaction signing;
• wallet authorization;
• Solana instruction encoding;
• on-chain program code;
• oracle-price handling;
• sequential launch recovery;
• registration-payload format.

Suggested acceptance criteria

• Markets-database registration does not begin before mandatory insurance verification passes.
• Keeper registration does not begin before mandatory insurance verification passes.
• Keeper registration still completes before M4.
• Insurance amount 0 retains its current best-effort crank behavior.
• Existing M3a collateral and zombie-market guards remain intact.
• Focused regression suite passes.
• TypeScript and production build pass.

[dcccrypto]

Confirming this on current playground (19a1fddb), with the constraint that makes the obvious fix not work — and a mechanism that landed in this same base which probably does.

Confirmed

useCreateMarket.ts pins registration to the window between M3a and M4, and its own comment says it cannot move either way:

REGISTRATION — deliberately pinned to this window, between M3a and M4. […] It also cannot move any LATER: M4's StakeInitPool rotates marketauth away […] keeper-register's H1 check requires marketauth to still equal the deployer. After M3a and before M4 is the only window that works.

M3b — the insurance seed — is broadcast inside that same window (broadcastTailTx(3)), and the balance assertion runs after it:

1358  const keeperRegisterPromise = …        // registration starts
1393  const m3bSig = await broadcastTailTx(3) // insurance seed
1400+ if (params.insuranceAmount > 0n) { …    // insuranceBalance verified here
1423  const keeperOutcome = await keeperRegisterPromise

So the report is accurate: registration is in flight before the insurance invariant is checked. Note it is now a single call — POST /api/markets is gone and keeper-register writes the markets row itself, so both side effects in the report share one request rather than two.

Why the obvious fix is blocked

"Move registration after insurance verification" cannot work as-is: that pushes it past M4, where StakeInitPool has already rotated marketauth away from the deployer, and keeper-register's H1 proof then fails. The ordering is a real constraint, not an oversight.

What probably does work

e38804de — in this very base — added markets.keeper_status, defaulting to retired. That gives the two-phase shape this needs: register inside the mandatory M3a→M4 window (satisfying the marketauth constraint) but in a non-live state, then flip to live only after insuranceBalance is verified. A launch that fails at M3b then leaves a retired row rather than a visible/keeper-registered market.

I have not implemented that — market-registration.ts, the spec, and the 6-task plan all landed hours ago and this sits squarely inside that in-flight consolidation. Flagging it so whoever owns that work can fold it in, rather than having a second change land on top of it.

For reference, the visibility half was already narrowed by the 2026-07-27 zombie-market fix (registration deferred until after M3a so a market is only listed once it holds collateral); this issue is the remaining gap between that point and insurance verification.

[Bayyan16]

Thanks for confirming this on the current playground and for clarifying the M3a–M4 marketauth constraint.

Agreed — now that registration is consolidated into a single marketauth-gated call, my original “move registration after insurance verification” patch is no longer the right shape. I’ll hold that patch and won’t open a competing PR on top of the in-flight market-registration work.

The two-phase approach makes sense: perform the authenticated registration inside the required M3a→M4 window in a non-live state, then promote keeper_status to active only after the on-chain insurance balance has been verified. An M3b failure should leave the row retired, while activation should remain idempotent and retryable.

I’ll keep #2464 open as the tracked invariant and preserve the existing reproduction evidence. Please point me to the owning PR or workstream if a focused regression-test or follow-up contribution would be useful once the consolidation settles.

[Bayyan16]

Reopening this issue because it was accidentally closed.

The tracked invariant remains unresolved on the current playground flow: the market registration request can still begin before the mandatory M3b insurance outcome is verified, and the registration path currently promotes the market directly to keeper_status = active.

The proposed two-phase retired → active activation flow discussed above has not yet been implemented, so #2464 should remain open until the invariant and its regression coverage are addressed.

I’ll be more careful and thorough when updating issue states going forward to avoid repeating the same mistake.

[dcccrypto]

Confirmed still live — keeping open. The reordering fix is blocked on BOTH sides, which is worth knowing before anyone attempts it.

Verified: keeperRegisterPromise starts at useCreateMarket.ts:1387, and the on-chain insurance verification (parseMarketGroupV17OI(...).insuranceBalance) does not happen until :1439. So registration is in flight before the seed is confirmed, exactly as you describe.

It cannot move earlier (:1378-1381):

Firing it earlier would republish the zombie bug this ordering exists to prevent: registration used to fire right after M1, so any launch that died later still published a listed, unfunded, untradeable market (that is what happened to the ANSEM market).

It cannot move later (:1383-1386):

M4's StakeInitPool rotates marketauth away from the deployer, and keeper-register's H1 check requires marketauth to still equal the deployer. After M3a and before M4 is the only window that satisfies both constraints.

So the window is genuinely pinned: earlier reintroduces a worse bug, later makes keeper-register structurally impossible.

That means the remedy is not reordering. The options are compensating rather than preventive:

1. Roll back on failure — unlist the DB row and revoke the keeper registration when the insurance-seed check at :1439 fails.
2. Register in a pending state and promote to listed only after :1439 succeeds, so a failed seed leaves an unlisted row rather than a zombie.
3. Accept it and rely on the existing zombie filtering (nonZombieListedMarkets in /api/stats) to hide the artifact.

Option 2 looks closest to the intent — it keeps the H1 window while making listing conditional — but it changes the registration contract, so it is a decision rather than a fix.

[dcccrypto]

FIXED and merged in PR #2536. Closing.

The keeper-register call is now a thunk invoked after the insurance verification, rather than a promise started before it. Your description of the failure was precise:

the database and keeper requests may already be in flight or may already have completed

They were. The call was created, then M3b broadcast, then the on-chain insuranceBalance check ran and could throw — all while the request was outstanding.

Why this was fixable at all

The source documents a hard window for that call, and it turns out the insurance check sits inside it, so registration only had to move later within the window rather than out of it:

• after M3a — a market is listed only once it holds collateral. This is the ANSEM zombie the ordering already existed to prevent: registration used to fire right after M1, and since "create the market" always succeeds, every failed launch left a listed, unfunded, untradeable market behind.
• before M4 — StakeInitPool rotates marketauth away from the deployer, and keeper-register's H1 check requires it to still equal the deployer.

Had the check been outside that window, this would have been a decision rather than a fix.

The cost

Latency: the round-trip no longer overlaps M3b's broadcast, so the tail sits longer against the shared blockhash.

Worth it — the blockhash-expiry path already rebuilds a not-yet-landed tail tx against a fresh blockhash (TailTxDescriptor), whereas an incorrectly published market has no equivalent undo. One failure mode is recoverable in code; the other is not.

On your severity framing

This report does not demonstrate direct fund theft, unauthorized signing, an on-chain authorization bypass, or protocol insolvency.

That precision is why this was straightforward to action. An inconsistent state across four systems is a real defect and it is not a fund-loss one, and saying so plainly meant the fix could be judged on its own terms rather than against an inflated claim.

Two existing source-position tests pinned the old ordering; updated to assert the invocation, and tightened so the zombie guard now also requires registration to follow the insurance gate — the #2464 property itself.

Negative control: restoring the eager start fails both. Launch suite: 3149 passed / 16 skipped / 0 failed.