Verified Creator Badge

The badge

A small [ VERIFIED CREATOR ] tag on relaunched tokens. It means the launcher signed an EIP-712 message proving they held an owner, admin, creator, factoryRef, or comparable role on the OLD token before the new pool was deployed.

The signature is checked against isRecognizedAdmin(oldToken, signer) on-chain. If it passes, the row's deployer_role flips from open to verified-creator and the badge renders on:

• The token detail page (next to the Migration callout)
• The /relaunch directory and per-OLD lists

Why it's opt-in

Most relaunches are organic — a holder picks up a stale ticker and rallies a community around the new pool. Those launches are not less legitimate than creator-led ones. The badge is cherry-on-top, never a launch gate: an opt-in signal for launchers who happen to hold an admin role and want to surface that.

Absence of a badge is not a red flag. Plenty of high-quality relaunches will never carry one.

Claim flow

Two paths:

1. At launch: Tick the checkbox on /relaunch before signing the first transaction. The form attaches the EIP-712 sig to the recorded row.

2. After launch: Visit the new token's detail page while connected with the wallet that holds an admin role on the OLD. A [ CLAIM CREATOR BADGE ] button appears. One sig, done.

The signer's address is verified against body.creator (the wallet doing the claim), not against body.feeRecipient (which is whoever first recorded the migration). This was a silent failure mode we fixed in migrator #13.

Implementation notes

• EIP-712 domain: LiquidMigrator v1, chainId 8453
• Pre-flight check at /api/relaunch/verify-creator — same logic without writing the row
• Sig is rejected if isRecognizedAdmin(oldToken, signer) returns false at the current block

Already showing on the first live migration with a verified creator: GDUPI.