Nock Robinhood Chain Launch Registry

For each included token, the registry proves that a specific contract-creation transaction deployed the token, a successful transaction initialized a Uniswap v4 pool containing that token, and a successful PositionManager transaction minted the recorded initial liquidity NFT. When the LP field says dead address, a later successful `transferFrom` moved that same minted NFT from the launch wallet to the exact dead address and the current `ownerOf` response still resolves there.

The registry does not prove that all trading liquidity is inaccessible, because later positions can exist. It does not inspect token-holder concentration, taxes, transfer restrictions, external contracts, social ownership, organic demand or future upgrades elsewhere in the trading stack. A successful launch sequence is evidence that the sequence happened, not a recommendation to trade the token.

The backfill starts from the public Nock launch rows and retrieves each contract-creation record from Robinhood Chain Blockscout. The contract address, creator, creation block, timestamp and transaction hash must agree. The deployment block is kept separate from the later database registration block so the public record does not mislabel pool initialization as token deployment.

A token name or symbol is never used as the primary identifier because both can be duplicated. The complete lowercase contract address is the join key. This avoids attributing a transaction to the wrong asset when several launches use similar names, repeated symbols or the same creator wallet.

Pool initialization is accepted only when the successful transaction targets Robinhood Chain's known Uniswap v4 PoolManager at `0x8366a39cc670b4001a1121b8f6a443a643e40951`, uses the initialize call and encodes the launched token address. Initial liquidity is accepted only when the successful transaction targets PositionManager at `0x58daec3116aae6d93017baaea7749052e8a04fa7`, uses `modifyLiquidities` and encodes the same token.

The resulting pool identifier is a Uniswap v4 bytes32 pool ID, not a standalone pool contract address. The initial position ID comes from the PositionManager ERC-721 mint event in the liquidity transaction receipt. Keeping pool ID and NFT ID separate prevents a common verification mistake: treating a v4 pool identifier as an address or treating a token-transfer event as proof of LP custody.

A transaction selector alone is insufficient. The audit decodes `transferFrom`, requires PositionManager as the destination, requires the launch wallet as `from`, requires the exact dead address as `to`, and requires the transferred token ID to equal the ERC-721 ID minted by that launch's liquidity transaction. It then calls `ownerOf` at the latest block and accepts the burn only if the current owner remains the dead address.

This stricter method found two stale database flags. CashFrog position 60399 and Nock Curve Test position 68105 were both transferred to the dead address and remain owned there even though their older rows said `lp_burned=false`. The backfill corrects those flags from chain evidence. Nock Test Flight position 45009 has no qualifying burn transaction in the checked sequence and remains labeled not burned rather than inferred.

This table is a dated historical snapshot. New launches should enter the live JSON feed through receipt-backed capture, so counts can increase after publication. If a future launch is registered before one of its transaction receipts is stored, the affected evidence field remains null until it is independently reconstructed. Null means unavailable under this method, not failed, unsafe or absent.

The HTML owner explains methodology and preserves a citeable dated snapshot; the JSON distribution is the current machine-readable record. Researchers should record the feed retrieval time and relevant transaction hashes when using it. Nock should update the visible snapshot when the launch count materially changes, when verification rules change, or when a chain reorganization or corrected source affects a record.

• Copy the complete launched token address from the table or JSON feed.
• Open its Blockscout contract page and confirm the creation transaction, creator and deployment block.
• Open the recorded pool-initialization transaction and confirm the PoolManager target and token address.
• Open the initial-liquidity transaction and find the PositionManager ERC-721 mint to the creator.
• If a burn hash exists, confirm the same NFT ID moved from the creator to the exact dead address.
• Call PositionManager `ownerOf` for that NFT ID or inspect the current token-instance owner.
• Treat every other token-safety, market and custody question as a separate investigation.