# Programmable > Current entry points for Robinhood Custom Launch Plans, Module Mode and source-bound launch indexing. Ethereum and older Robinhood profiles have separate references. ## Start here - [Agent guide](https://programmable.market/agents.md): credentials, launch workflows, wallet authority and recovery. - [Agent discovery](https://programmable.market/api/agent): machine-readable workflow links. The primary Robinhood create workflow is customLaunchPlan. - [Custom Launch quickstart](https://programmable.market/docs/developers/custom-launch-quickstart): the current path for a new Robinhood token, hook or application, including a shared token and hook contract. - [Custom Launch Plan capabilities](https://api.programmable.market/v4/chains/4663/custom-launch-capabilities), [manifest](https://api.programmable.market/v4/chains/4663/custom-launch-contract/manifest.json), [agent setup](https://api.programmable.market/v4/chains/4663/custom-launch-contract/agent-setup.json) and [guide](https://api.programmable.market/v4/chains/4663/custom-launch-contract/guide.md): check live create availability and bind the manifest before packing. - [Module Mode](https://programmable.market/docs/models/module-mode): coin configuration, optional modules and management. - [Module Mode indexing](https://programmable.market/developers/module-mode-indexing-v1.md): verify each exact Native or Engine source version independently of module names and market support. The [JSON contract and ABI](https://programmable.market/api/module-mode/indexer/v1) describes Native V1; the guide links the separate V2 and Engine adapters. - [Direct Ethereum Custom Hooks](https://programmable.market/developer-reference/ethereum-custom-hook): canonical CustomGraph inputs, authority authorization and finalized stamp indexing. The [complete Markdown](https://programmable.market/developers/ethereum-custom-hook-indexing.md) and [ABI bundle](https://programmable.market/developers/ethereum-custom-hook-indexing.zip) provide the exact files. ## When to use Programmable - Build a new Robinhood Custom Launch Plan through the API. For an open plan use admissionPolicy programmable.custom-launch-policy.provenance.v1, feeObligations [] and publication.visibility listed. Preflight the exact packed bytes, create with the same bytes and Idempotency-Key, then let the controller wallet review and sign the prepared transaction. - Discover finalized Robinhood launch projections and index each launch by its verified source version and canonical token identity. Market data and trading support are separate from provenance. - Configure and launch a Module Mode coin through the website with the connected wallet. There is no public Module Mode create API. - Verify Ethereum launches through their exact Registry or finalized Router evidence. The Ethereum V3 guide and older Robinhood V4 profiles are separate from new Robinhood Custom Launch Plans. ## Do not use Programmable to infer - Safety, endorsement, audit coverage, liquidity, price accuracy, tradability, or future value from a verified identity. - Transaction authority from an API key. The Custom Launch API validates and prepares an exact action, but it cannot sign or broadcast for the controller wallet. - Active create authorization from a static schema or stable URL. Read the live Custom Launch Plan capabilities before every new request. - Wallet authorization from preflight, a model, or caller-attested output. An action_required result requires remediation before wallet signing. - A mandatory platform fee, liquidity, trading route or safety review from a Custom Launch Plan stamp. The plan's feeObligations field and deployed contract behavior must be evaluated separately. ## Ethereum identity scope - Ethereum catalog: verified Classic V3 launches, Registry-verified Custom launches, finalized Router-stamped Custom provenance entries, and the sole official Classic V2 main-token exception. - Official main token: 0x7987f03462200b3D8A072E02C89A8A41dCB124EE. - Excluded: all other Classic V1 or V2 launches, every Stock family, and Custom launches without a verified Registry record or finalized Router stamp. - Finalized Router records can surface as provenance-only Custom entries after 64 confirmations. Router is an evidence source, not a separate category, review, audit, liquidity, or safety claim. - Canonical Programmable identity remains authoritative. GMGN, Dexscreener and Bitquery may rank or enrich that catalog, but they can never add, remove or verify a launch. - On Ethereum, GMGN is the bounded primary provider for visible-page market enrichment, canonical-intersection discovery, token analytics and token-address chart series admitted by current exact token_info context. - Highest and lowest market-cap sorts use a fresh, liquidity-qualified GMGN marketcap rank as a canonical-only provider prefix. Dexscreener batch-sorts the complete unmatched canonical remainder by exact-identity FDV; the response reports GMGN coverage and a full-order commitment. This is not a cross-provider numeric merge or a claim of full GMGN coverage. - Dexscreener remains the bounded batch fallback for visible market enrichment and the unmatched market-cap remainder. A provider outage must not hide an already verified token identity. - GMGN token charts are token-address series without historical pool attribution. Bitquery remains the exact-pool chart fallback and reports that scope explicitly. ## Current Robinhood machine-readable resources - Custom Launch Plan capabilities: GET https://api.programmable.market/v4/chains/4663/custom-launch-capabilities - Manifest: https://api.programmable.market/v4/chains/4663/custom-launch-contract/manifest.json - Agent setup: https://api.programmable.market/v4/chains/4663/custom-launch-contract/agent-setup.json - Plan guide: https://api.programmable.market/v4/chains/4663/custom-launch-contract/guide.md - Current Programmable-routed Custom trades charge 0.30% (30 bps) of gross output in the output asset, rounded down once. The wallet review binds the exact fee and transfer. Historical signed fees and verified existing pool fees retain their original rates; no second route fee is added to a verified fee-bearing pool. External trades are outside this routed pricing policy. - OpenAPI: https://api.programmable.market/v4/chains/4663/custom-launch-contract/openapi.json - Create or revoke API keys: https://programmable.market/developers/api-keys - Finalized launch feed: https://api.programmable.market/v4/chains/4663/finalized-launch-projections - Terminal indexer guide: https://programmable.market/developer-reference/robinhood-terminal-indexer#custom-launch-plans - Robinhood Explore catalog: https://programmable.market/api/explore/robinhood - Sitemap: https://programmable.market/sitemap.xml - Human documentation: https://programmable.market/docs - Developer documentation: https://programmable.market/docs/developers - Developer Markdown: https://programmable.market/docs/developers.md ## Other integration references - Historical MultiRole V2 capabilities: https://api.programmable.market/v4/chains/4663/multi-role-custom-launches/capabilities - Historical MultiRole V2 guide and client: https://api.programmable.market/v4/chains/4663/multi-role-custom-launches/guide.md and https://api.programmable.market/v4/chains/4663/multi-role-custom-launches/client.mjs - MultiRole V2 Native20 and evidence_required admission rules belong to that historical contract context; the 4.1 profile is also separate from new open Custom Launch Plans. - Robinhood V4.1 history and separate Ethereum V3 documentation: https://programmable.market/docs/developers/custom-launch - Older /v4/chains/4663/custom-launches requests remain readable for history and recovery. New creation uses /v4/chains/4663/custom-launch-plans. - Ethereum public OpenAPI: https://programmable.market/openapi.json - Historical Ethereum token lookup: https://programmable.market/api/explore/token?address=0x7987f03462200b3D8A072E02C89A8A41dCB124EE ## Ethereum provenance evidence reference > Canonical read-only provenance reference for Router-stamped Programmable Classic and Programmable Custom launches on Ethereum. Finalized Router evidence can feed the existing Custom category; it does not create a separate category or imply review, audit, liquidity, or safety. - Deployment manifest: https://developers.programmable.family/api/v2/manifest - Router: 0x8622DD5bAb44185f2A458ac90384Ac99248f8d56 - startBlock: 25717612 - runtimeCodeHash: 0x40e27ecf201761d5eb66bc4f2d5c6124831ef078d7baf458ca5f41b1a8108546 - ABI: https://developers.programmable.family/abis/ethereum/programmable-launch-stamp-router-v1.json - ABI SHA-256: sha256:bb4e728e9f9c850eb01f928e8a798ac206a82e241a8d93b3b3c686635c88ed86 - GitHub reference: https://github.com/programmablehq/Developers/blob/main/docs/reference/launch-stamp.md - Terminal guide: https://github.com/programmablehq/Developers/blob/main/docs/guides/terminals-and-scanners.md - Human overview: https://programmable.market/docs/developers - Markdown overview: https://programmable.market/docs/developers.md ## Required Router-evidence interpretation - Only launches executed and stamped through this Router inside its published block range have Router V1 provenance. Launches before `startBlock`, and direct factory calls outside the Router even when later, do not. - Map kind 1 to Programmable Custom and kind 2 to Programmable Classic. Kind 0 is invalid. - Verify token, `(PoolManager, poolId)`, or exclusive-component identity with canonical getter reads at one finalized block. - Before returning a result, require complete live or retired-in-range manifest activation data; one concrete block number and hash; Router runtime and ABI-byte hashes; all getter selectors, event topics, and indexed layouts; `CHAIN_ID()` plus all six immutable binding getters; and the permit authority, Graph Factory, and PoolManager runtimes. - Use EIP-1898 canonical block-hash reads where supported. For number-bound reads, require the closing block hash to equal the opening hash before returning `STAMPED` or `NOT_STAMPED`. - Remote RPC URLs must use HTTPS. Plain HTTP is accepted only for loopback development endpoints. - A nonzero result still requires exact query identity, valid record address encoding, nonzero bytes32 identity and commitment fields, matching `stampProof` for token or exclusive-component queries, and the launch-kind route rule: immutable Graph Factory for `CustomGraph`, permit-bound recorded launcher and runtime for `Classic`. - Current component-runtime equality is a separate drift signal, not a historical provenance gate. - A shared Classic hook is not a launch identifier. - A successful canonical zero lookup is not stamped. RPC failure or inconsistent evidence is not a negative result. - After manifest and ABI bootstrap, point verification needs an Ethereum provider only. Indexing, Supabase, a Programmable launch-feed API, and an application server are not trust dependencies. - Event backfill and checkpoint-based subscription are optional for continuous discovery; logs are candidates until getter verification succeeds. - Protocol fee claim discovery is a separate index: complete Classic Launcher and Custom Registry scans plus the fixed Stock release set. Unknown or unverified sources fail closed. Generic fee claiming for arbitrary Custom hooks is not live. - The live claim boundary is published at https://claimhazard.vercel.app/claim-discovery.json and requires one wallet-declared atomic batch from the fixed reward wallet. - A Router record establishes provenance only after the required address, runtime, binding, lookup, and cross-check verification passes. It does not establish safety, tradability, current liquidity, audit coverage, endorsement, terminal support, or launch authorization. - This Ethereum provenance reference grants neither API access, launch authorization nor wallet authorization. ## Expanded Ethereum Router overview This overview is not the normative verification algorithm. Implement against the canonical GitHub Router reference: https://github.com/programmablehq/Developers/blob/main/docs/reference/launch-stamp.md # Programmable developer APIs > Public credential-principal V3.3 general-hook launch creation plus verified Router-stamped Programmable provenance on Ethereum. Custom Launch API: https://api.programmable.market Manage API keys: https://programmable.market/developers/api-keys Custom Launch API OpenAPI: https://programmable.market/openapi/custom-launch-v3.json Public V2 OpenAPI: https://programmable.market/openapi/custom-launch-v2.json Public V3 OpenAPI: https://programmable.market/openapi/custom-launch-v3.json Robinhood V4 OpenAPI: https://programmable.market/openapi/custom-launch-v4.1.json Robinhood V4 pack config: https://programmable.market/schemas/custom-launch/v4.1/pack-config.json Robinhood V4 source verification: https://programmable.market/schemas/custom-launch/v4.1/source-verification-status.json V1 compatibility OpenAPI: https://programmable.market/openapi/custom-launch-v1.json Custom Launch API guide: https://programmable.market/docs/developers/custom-launch Raw Custom Launch API guide: https://programmable.market/developers/custom-launch-api-v1.md Custom Launch API readiness: https://api.programmable.market/readyz Custom Launch capabilities: https://api.programmable.market/v3/capabilities Robinhood architecture coverage, no API key: https://api.programmable.market/v4/chains/4663/launch-coverage Coverage OpenAPI: https://programmable.market/openapi/launch-coverage-v1.json Coverage response schema: https://programmable.market/schemas/custom-launch/coverage/v1.json The separate coverage report distinguishes service readiness, representable architecture and activated verifier coverage. The active graph reports tokenAndHookMayShareAddress: false; requestAuthorization.requestAuthorized is always false. Missing coverage, an unknown report version or an unsupported architecture is not a reason to rotate an API key or expand its scopes. Coverage does not change the existing launch contracts or replace exact-request preflight and server admission. CLI 4.1.1 adds the coverage command; verify its separate immutable release before installation. The API profile stays 4.1.0 and its original CLI assets remain unchanged. The direct public GET needs no CLI upgrade. Custom Launch preflight: https://api.programmable.market/v3/custom-launches/preflight Finalized Custom metadata: https://api.programmable.market/v3/finalized-custom-launches Programmable Launch CLI: https://github.com/programmablehq/PROGRAMMABLE/releases/download/programmable-launch-v3.3.9/programmable-launch-3.3.9.tgz Deployment manifest: https://developers.programmable.family/api/v2/manifest Frozen Router ABI: https://developers.programmable.family/abis/ethereum/programmable-launch-stamp-router-v1.json ABI SHA-256: sha256:bb4e728e9f9c850eb01f928e8a798ac206a82e241a8d93b3b3c686635c88ed86 GitHub reference: https://github.com/programmablehq/Developers/blob/main/docs/reference/launch-stamp.md Programmable read endpoints: no authentication Custom Launch API: wallet pm_live_, partner root or bounded partner subkey Ethereum RPC authentication: provider-specific Read-only Developer API: https://developers.programmable.family ## Shared token and hook: MultiRole V2 On Robinhood chain 4663, a token and hook that share one physical contract use the separate MultiRole V2 lane. The existing 4.1 profile, CLI and graph rules remain a separate contract; do not split the project or substitute profile fields to get past its distinct-role requirement. Read [MultiRole V2 capabilities](https://api.programmable.market/v4/chains/4663/multi-role-custom-launches/capabilities) without a key and check current readiness and context before packing. If unavailable, stop before authenticated submission. Follow the [MultiRole V2 guide](https://api.programmable.market/v4/chains/4663/multi-role-custom-launches/guide.md) and [Node 24 client](https://api.programmable.market/v4/chains/4663/multi-role-custom-launches/client.mjs) for the exact packer and preflight -> create -> status flow. Preserve request bytes and the idempotency key on retries. Preflight/create requires custom-launch:create; status/list requires custom-launch:read, with the key's chain 4663 grant and controller binding. Automatic economic recognition currently covers the Native20 recipe. Unknown economics return evidence_required; this is not a generic hook audit or wallet authority. Published documentation does not imply enabled admission. The following 4.1 release, funding and CLI instructions apply to the existing profile; MultiRole uses its own capabilities and guide above. ## Custom Launch API availability Public V3.3 creation, preflight, list and single-resource reads are live for wallet keys, partner roots and bounded partner subkeys on Ethereum Mainnet at https://api.programmable.market/v3/custom-launches. V2 and V1 history and schemas remain readable; fresh creation returns non-retryable `409 CUSTOM_LAUNCH_V2_READ_ONLY` and `409 CUSTOM_LAUNCH_V1_READ_ONLY`. Only V3.3 accepts new submissions. Legacy Registry and GitHub submission intake is closed. The source-tree V3 OpenAPI at https://programmable.market/openapi/custom-launch-v3.json contains a preparatory profile 3.4 candidate. It is not backend-activation evidence; live discovery and GET /v3/capabilities remain authoritative for the accepted profile, routes and wallet-handoff contract. CLI `3.3.9` is the public Ethereum V3 release. For Robinhood V4, require `publicAuthorization: true`, `publicWrites: true` and `releaseReady: true` in both `customLaunchApi.versions.v4` and the `chains[]` entry for 4663. If either entry reports false, is missing or is incomplete, stop before authenticated preflight or submission. Install CLI `4.1.0` only after verifying the immutable GitHub Release, release manifest, exact source commit and tarball checksum published at `customLaunchApi.versions.v4.cli.release`. Source files and deployed routes alone do not activate the API. The stable V4 integration pointers are https://programmable.market/openapi/custom-launch-v4.1.json, https://programmable.market/schemas/custom-launch/v4.1/pack-config.json, https://programmable.market/schemas/custom-launch/v4.1/source-verification-status.json and https://api.programmable.market/v4/chains/4663/capabilities. They describe the V4 contract; their presence is not current public activation, write authorization, publication or external-indexing evidence. Robinhood 4.1.0 requires a fundingPlan before a funded launch: choose buyer-funded, creator-funded, hybrid or custom capital and the pricing model; declare initial liquidity, initial buy, reserve and other launch value separately. Their sum must equal the native wallet transaction value. Confirm maxLaunchValueWei and maxGasCostWei with the user; gas is additional. A build-only plan cannot obtain a permit. Funding declarations do not prove liquidity or solvency. Funding-plan schema: https://programmable.market/schemas/custom-launch/v4.1/funding-plan.json. Every funded Robinhood launch requires an atomic initial buy of at least USD 1 at permit authorization. Read https://api.programmable.market/v4/chains/4663/initial-buy-quote without an API key before building, confirm the native buy amount and positive minimum token output to the launch wallet, and count the buy once inside total transaction value. The server independently obtains a fresh quote, no older than 60 seconds, without stale fallback. Never increase the amount or budget without user approval. The reference feed is on Ethereum (chain 1); execution remains on Robinhood (chain 4663). The quoted dollar value at wallet execution and third-party indexing are not guaranteed. Robinhood 4.1.0 requires an exact server-verified native fee kernel for the stamped PoolKey. The platform receives 20 bps (0.20%) of the gross native ETH leg once per successful swap, separately from creator and LP fees, rounded up per trade. Fees accrue as PoolManager native claims for 0xD88539d3c4C460136a733A3Fd60cf6BF269079da; a permissionless claim pays only that fixed recipient. Admission is not proof of deployed vault state, completed trades or collected revenue. The API key never signs, broadcasts or claims fees. V4 has a distinct lifecycle: `received`, `validating`, `action_required`, `authorized`, `awaiting_wallet_signature`, `wallet_action_required`, `submitted`, `sequencer_soft_confirmed`, `ethereum_posted`, `finalized` or `failed`. `action_required` is server-authored remediation, not a wallet action or manual approval. `authorized`, `awaiting_wallet_signature` and `wallet_action_required` expose or lead to the exact wallet transaction but do not mean it was signed or broadcast. `sequencer_soft_confirmed` remains reversible; `ethereum_posted` is not final; only `finalized` satisfies the published Robinhood-to-Ethereum finality policy. Guard V4 reads with `programmable-launch status REQUEST_UUID --api-version 4 --chain-id 4663 --watch --until authorized`, stop for separate controller-wallet review, signing and broadcast, then poll `programmable-launch status REQUEST_UUID --api-version 4 --chain-id 4663 --watch --until finalized`. The CLI only prepares and displays the exact transaction; it never signs or broadcasts. V4 source verification begins after finality and remains independent. `finalized` does not imply `sourceVerification.status: exact_match`; a non-authoritative provider observation alone cannot satisfy the independent protected-source/build/compiler/settings/finalized-transaction/bytecode composite, and provider failure does not revise finality. Programmable indexing, third-party indexing, trading readiness, Explore visibility and publication are separate outcomes. V2 detail reads are observation-only while an existing request is prepared or simulating: GET does not advance simulation or authorization and cannot expose a new walletTransaction. Existing authorized and submitted reconciliation and finalized reads remain available. The default profile uses `schemaVersion: programmable.direct-native-hook-graph-profile.v3`, `profileRevision: 3` and `profileVersion: 3.3.0`; its selection binding uses `programmable.direct-native-hook-graph-profile-selection-binding.v3`. It requires canonical project name, symbol, meaningful description, an exact non-empty source-bound image, one website and one X profile; other public links are optional. Discovery advertises `projectMetadata.requiredForProfileVersions = ["3.2.0","3.3.0","3.4.0"]`, `strictMetadataProfileVersions = ["3.3.0","3.4.0"]`, and `legacyMetadataProfileVersions = ["3.2.0"]`, so exact `3.2.0`, `3.3.0` and pending `3.4.0` all carry metadata while only exact `3.3.0` and pending `3.4.0` use the strict current policy and only exact `3.2.0` preserves its older nullable-image semantics. The CLI binds metadata digests into the graph and launch intent. Exact `3.1.0` and `3.0.0` requests remain readable and byte-identical retryable under their original immutable policies; revision 2 also remains compatible. The current profile accepts a project-owned token, a project-owned hook, native or ERC-20 quote currency, all fourteen structurally valid Uniswap v4 permission bits and an exact 3-16 target graph. Structural support is not universal compatibility or a safety promise. CLI `3.3.9` is the current installable release and defaults fresh packs to live profile `3.3.0`. Explicit profile `3.4.0` output remains preparatory and is rejected by live capabilities until the backend and `.well-known` document independently activate that pending profile. Active 3.3 capabilities keep `behaviorEvidence.requiredForProfileVersion = "3.4.0"`, `configurationIsExecutionEvidence = false`, `walletHandoffRequiresVerifiedEvidence = false`, `requiredPlatformFeeConformanceStatus = "verified"`, `nonFeeVectorsMayRemainUnverified = true`, `evidenceAuthority = "platform-runtime-executor"`, `signedExecutionReceiptRequired = true`, `notConfiguredDisposition = "claims_remain_unverified"`, `unavailableDisposition = "claims_remain_unverified"`, `executedFeeFailureDisposition = "blocks_wallet_handoff"`, and `executedHardInvariantFailureDisposition = "blocks_wallet_handoff"`. Their `feePolicy` separately carries `feeBehaviorClaim = false`, `tenBpsClaimRequiresExactPerLaunchVerifiedFeePathEvidence = true`, and `claimScope = "exact-launch-and-stamped-poolkey-only"`. Pending `3.4.0` adds declarative `behaviorScenarioInputs` and stronger required-profile server gates; those source-tree fields are not current acceptance or execution evidence. Profile 3.3.0 uses role-aware exact-source static admission with exactly seven objective hard-block rules: runtime CALLCODE, source or runtime SELFDESTRUCT, definitively missing or invalid callback authentication, a literal wrong PoolManager, and a missing enabled callback implementation. Proxy/delegatecall, mint/tax/pause/transfer controls, liquidity custody or locking, external dependencies and return-delta custom accounting remain evidence duties rather than categorical deployment blocks. Every finding remains bound and visible. A hard-block code-and-role match returns `action_required`; other findings populate needs-evidence or warning codes. There is no manual project allowlist. A final Router simulation is mandatory and must pass before wallet handoff. Missing behavior execution leaves behavior, fee, liquidity and routability claims unverified; an authenticated executed failure blocks the handoff. Local checks, preflight and simulation are not an audit or a guarantee of safety, honeypot resistance, liquidity, tradeability or fee behavior. With no hard-blocking match, server-authored `platformAdmission` binds the report SHA-256, needs-evidence and warning codes with `disposition: no_blocking_static_finding`, requires Router simulation and carries `safetyClaim: false` and `feeBehaviorClaim: false`. A hard-blocking match instead exposes the exact static report through `action_required`. A 10 bps Programmable share applies only to a fee-certified profile or adapter and its exact stamped PoolKey after server-authored per-launch fee-behavior evidence is verified. Arbitrary custom hooks are not automatically fee-enforced, and the open arbitrary-hook lane carries no Programmable fee claim. Funding may be absent, use exact native Router transaction value, or use a separate unsigned EIP-3009 descriptor. Funding signing and Router sending remain separate explicit wallet actions; neither is automatic. Where a selected lane uses applicant buy or sell rates, each rate is capped at 100,000 hundredths of a bip, equal to 1,000 bps or 10%. The API server enforces this cap in additive-platform-share and inclusive-selected-total modes. The separate platform value is 1,000 hundredths of a bip, equal to 10 bps, and creates a claim only in the fee-certified lane. Verify the pinned public CLI checksum before installation: ```sh programmable_cli_dir="$(mktemp -d)" curl --fail --location --output "$programmable_cli_dir/programmable-launch-3.3.9.tgz" https://github.com/programmablehq/PROGRAMMABLE/releases/download/programmable-launch-v3.3.9/programmable-launch-3.3.9.tgz curl --fail --location --output "$programmable_cli_dir/programmable-launch-3.3.9.tgz.sha256" https://github.com/programmablehq/PROGRAMMABLE/releases/download/programmable-launch-v3.3.9/programmable-launch-3.3.9.tgz.sha256 (cd "$programmable_cli_dir" && shasum -a 256 -c programmable-launch-3.3.9.tgz.sha256) npm install --global "$programmable_cli_dir/programmable-launch-3.3.9.tgz" programmable-launch --version ``` Continue only after the checksum reports `OK` and the version is `3.3.9`. The package is `@programmable/launch` and the binary is `programmable-launch`. Omit `profileVersion` for the live `3.3.0` default; explicit `3.4.0` output remains preparatory and is rejected until backend activation. Use `pack -> validate --remote -> submit -> server decision -> status --watch --until authorized -> wallet -> status --watch --until finalized`. Remote validation repeats local byte-identical validation, fails closed on profile, revision, version, route or authentication drift, and preflights those exact bytes without consuming launch-creation quota, allocating a nonce or persisting a launch. The authenticated preflight still consumes its ordinary route rate budget. CLI and preflight results are preparation, not the launch decision. The API server exposes a wallet handoff only after objective static hard blocks and exact Router simulation pass. Missing behavior execution leaves related claims unverified; an authenticated executed failure blocks. Authenticated CLI traffic is fixed to exact origin `https://api.programmable.market`. Wallet is a separate connected-controller action, not a CLI command. The pack command derives the sorted manifest, SourceDescriptor, graph, locators, CREATE2 predictions, canonical hashes and exact-source bundle from real source, Standard JSON, compiler artifacts and evidence files. The CLI never signs or broadcasts. For a wallet flow, connect a wallet and create a key at https://programmable.market/developers/api-keys. A partner flow uses the root or bounded subkey issued to that integration. Store the selected one-time secret only as the encrypted environment secret `PROGRAMMABLE_API_KEY` or in the OS secret store. Put only `$PROGRAMMABLE_API_KEY` in chat, prompts and agent setup. Wallet keys, partner roots and bounded partner subkeys can use their scoped public V3 create, preflight, list and status operations. A wallet key must use its bound wallet as launchWallet. A partner credential selects the exact controller in the request but gains no signing authority; that controller must review, sign and broadcast separately. All credential kinds use the same current-profile metadata requirements. `fees:claim` and `buybacks:manage` are reserved and disabled. Wallet keys expire after 90 days by default, may be issued for at most 366 days, and are limited to 10 active keys per wallet. Partner subkey expiry and budgets cannot exceed the authenticated root. An API key is not a wallet or private key. Existing durable resources record server-authored manifest, graph, evidence, admission and permit checks. `prepared` contains an exact artifact but no wallet transaction. `authorized` is possible only after objective static hard blocks and exact Router simulation pass and contains the permit-attached wallet transaction, which the controller wallet reviews, signs and broadcasts separately. Missing behavior execution leaves related claims unverified; an authenticated executed failure blocks. The API key and CLI never sign or broadcast. Programmable does not audit the project or attest safety. ### Public V3 submission GET https://api.programmable.market/v3/capabilities is public and non-authorizing. POST https://api.programmable.market/v3/custom-launches/preflight requires a create-scoped wallet key, partner root or bounded partner subkey and returns programmable.custom-launch-preflight.v1 with disposition, launch eligibility, evidence tier, riskClassification, platform-owned behaviorEvidence, all six productTruthAxes, typed finding codes, static baseline and remediations. A not_executed or needs_evidence result remains outstanding; it is not a caller-declared pass and cannot authorize a wallet handoff. Its fixed fields are quotaConsumed: false, nonceAllocated: false, persisted: false, walletSignatureRequiredLater: true and walletBroadcastByService: false. quotaConsumed: false means no launch-creation quota or durable launch reservation; the authenticated request still consumes its ordinary route rate budget, including a partner credential's prepareRequestsPerHour budget. The six independent product-truth axes are `deployment`, `trading`, `platform_fee_evidence`, `source_verification`, `indexing` and `featured`. Preflight does not collapse or prove them, and no disposition is an audit, universal compatibility statement or safety guarantee. `POST /v3/custom-launches` binds the idempotency key to the exact request bytes. Retry timeout, `429` and `503` results only with those persisted bytes and honor `Retry-After`. It never falls back to an older create route. Private V3 launch history follows immutable partner lineage. A partner root reads every launch attributed to its partner. Each subkey reads only its own stable lineage and cannot read root or sibling launches. Rotation preserves the lineage history for the replacement credential; a separately issued subkey starts a new isolated lineage. The Router V1 permit-reissue disposition route is wallet-key-only; partner credentials recover by repacking and submitting a new request. ### Closed request body The top-level V3 object has no unknown fields and is limited to 8,388,608 bytes (8 MiB): - `schemaVersion`: exactly `programmable.custom-launch-create-request.v3` - `launchWallet`: for a wallet key, its bound Ethereum address; for a partner credential, the exact selected controller address that later reviews, signs and broadcasts - `chainId`: the string `1` - `nonce`: one nonzero lowercase `bytes32` - `sourceDescriptor`: one `DeterministicSourceBundleV2` descriptor - `sourceBundleManifest`: one complete, non-empty `SourceBundleManifestV2` - `graphBundle`: one executable 3-16 target `CustomGraphBundleV1` - `projectMetadata`: canonical `programmable.project-metadata.v1` token identity, presentation and token-target binding for current profile `3.3.0` - `projectMetadataHash`: the domain-separated canonical metadata digest derived by the CLI - `permitWindow`: the exact bounded Router permit window - `launchProfile`: the complete general V3 production profile; current revision 3 uses `programmable.direct-native-hook-graph-profile.v3` and `profileVersion: 3.3.0`; exact `3.2.0`, `3.1.0` and `3.0.0` remain readable and byte-identical retryable under their original immutable policies - `launchProfileSelection`: exact revision-matched target roles, permission mask, funding mode, fee accounting and claim binding - `launchProfileHash`: the canonical profile digest derived by the CLI - `launchIntentHash`: the canonical request-intent digest derived by the CLI - `agentAttestation`: one `AgentLaunchAttestationV2` self-attestation bound to `launchIntentHash` - `verificationBundle`: required exact-source material using `programmable.exact-source-verification-bundle.v2` Exact profile `3.2.0` requests remain readable and byte-identical retryable with their original nullable-image metadata policy. Exact `3.1.0`, `3.0.0` and revision-2 requests remain readable and byte-identical retryable without project metadata under their original immutable policies. New requests use profile `3.3.0`; fresh V2 and V1 creation are permanently write fenced. `sourceDescriptor` requires exactly `schemaVersion: 2.0.0`, `kind: deterministic-source-bundle`, `controllerWallet`, `sourceLineageNonce`, `sourceBundleDigest`, `bundleContentSha256`, and `publicOriginCommitment`. `controllerWallet` must equal `launchWallet`. `graphBundle.sourceBundleSha256` must equal `sourceDescriptor.bundleContentSha256`. `sourceBundleManifest` contains exactly `schemaVersion: 2.0.0` and at least one entry. Entries are unique and strictly sorted by UTF-8 path bytes. Every entry contains exactly `path`, `kind`, `mode`, decimal `byteLength`, `contentSha256`, and `symlinkTarget`. Files use mode `100644` or `100755` with a null target; symlinks use mode `120000` with a string target. The platform recomputes the frozen manifest digest and requires it to match `sourceDescriptor.sourceBundleDigest`. `graphBundle` contains exactly `schemaVersion: programmable.custom-graph-bundle.v1`, `sourceBundleSha256`, `targets`, and `pool`. V3 accepts 3 to 16 acyclic direct targets, exactly one `token` target and one `hook` target. Aggregate init code and initializer calldata are limited to 524,288 bytes. For metadata profiles `3.3.0` and `3.2.0`, `graphBundleHash` is the domain-separated digest of the unbound graph hash plus `projectMetadataHash`; exact metadata-absent legacy requests preserve their original unbound graph hash. `projectMetadata` contains the exact token name and symbol, a presentation object with description, exact source-bound image and sorted public links, plus a binding to the primary token target. Current profile `3.3.0` requires non-empty image bytes and exactly one website and X link; exact `3.2.0` retries preserve their original nullable-image policy; pending `3.4.0` keeps metadata required. The API preserves these values, and post-deployment `name()` and `symbol()` readback reports `matching`, `mismatch` or `unavailable` without letting a client declare a match. Every target contains exactly `targetId`, `applicantSalt`, `creationBytecode`, `constructorArguments`, `initializerCalldata`, `constructorAddressLocators`, `initializerAddressLocators`, `deploymentValueWei`, `initializerValueWei`, `expectedRuntimeCodeHash`, `componentKind`, and `declaredHookPermissions`. Each address locator contains exactly `targetId`, nonnegative `byteOffset`, and `encoding` (`abi-address-word` or `packed-address-20`). Non-hook targets use `declaredHookPermissions: null`; the hook uses a unique subset of the 14 Uniswap v4 permissions, and its predicted address bits must match that set. The pool contains exactly `tokenTargetId`, `hookTargetId`, `fee`, and `tickSpacing`. Target IDs must select the declared token and hook. The standalone Custom Launch API schema, including every bound, enum, and response, is published at https://programmable.market/openapi/custom-launch-v3.json. The agent attestation is a required request field and contains exactly `schemaVersion: programmable.agent-launch-attestation.v2`, `subjectLaunchIntentHash`, `agentId`, canonical UTC `checkedAt`, and 1 to 64 checks with unique `checkId` values. Each check contains `checkId` and a non-null `sha256:<64 lowercase hex>` evidence digest. Programmable does not publish a universal check-ID catalog or project-independent pass/fail semantics. The submitting workflow chooses IDs for checks it actually ran and preserves the underlying evidence. This is the agent's self-attestation for the exact launch intent, is excluded from platform permit authorization and is not a Programmable safety, audit, approval, compilation, or simulation claim. `verificationBundle` contains 1 to 16 exact compilation units and components. Units are uniquely UTF-8 sorted by `compilationUnitId`; components are uniquely UTF-8 sorted by `targetId` and exactly cover the graph. For the default revision-3 profile, every unit uses exact `solc 0.8.26+commit.8a97fa7a`. Exact Standard JSON bytes use canonical base64, inline source content and SHA-256. Decoded Standard JSON is limited to 5,242,880 bytes per unit and across all units, with at most 2,048 inline sources. Revision-2 requests retain their compatibility contract. Components bind source path, contract name and resolved constructor arguments. URL-only sources fail. The public CLI derives this field and its domain-separated hash from the build artifacts. The CLI derives the full expected runtime hash only when deployed bytecode has no unresolved link or immutable references. Otherwise it fails closed with `RUNTIME_MATERIALIZATION_REQUIRED`; it never trusts a user-entered runtime hash. ### List wallet launch requests Read `https://api.programmable.market/v3/custom-launches?limit=10` with `custom-launch:read`. The newest-first collection contains requests visible to the authenticated lineage: a wallet key's wallet principal, every launch attributed to a partner when using its root, or one stable subkey lineage when using a child. A child cannot read root or sibling launches, and rotation preserves only that child's lineage history. `limit` defaults to 10 and is capped at 25; pass an unchanged non-null `nextCursor` as `cursor` for the next page. The collection is durable. For pending rows in the requested page, list reads may perform bounded best-effort chain reconciliation; RPC failure never hides durable history. Use the V3 single-resource route for the full prepared artifact and exact output. ### Read launch state Read `https://api.programmable.market/v3/custom-launches/{launchId}` with the same Bearer key. The state is one of `received`, `validating`, `pending_review`, `action_required`, `awaiting_funding_authorization`, `funding_authorization_verified`, `simulating`, `prepared`, `authorized`, `submitted`, `finalized`, `failed`, or `cancelled`. `action_required` means one of the current profile's exact hard-blocking code-and-role rules matched. Its exact bound static-baseline report is not a wallet action, approval, audit or safety claim. Needs-evidence and nonblocking findings remain bound and visible without blocking deployment. Read the report and contact support with the resource `requestId` when directed. Send only that ID, status, UTC time and public code; never send the API key. The path keeps the legacy name `launchId`, but its value is the API request UUID. Every resource returns that UUID as both `launchId` and the explicit `requestId`. The separate `onchainLaunchId` is a bytes32 Router identifier; it is null before preparation and when a terminal failure clears the durable output. `prepared` means an exact artifact exists. During `simulating`, a signed permit may exist only inside a worker-private simulation envelope; public output remains null in `simulating` and `failed`, so the evidence gate controls permit and wallet-transaction exposure rather than internal simulation signing. `authorized` means the API server verified the evidence required by the selected lane and made the permit and wallet action public; it is still not wallet-signed or broadcast. Follow only the HTTPS `walletHandoffUrl` before its `expiresAt`, then refetch the single-resource status. Every response `requestHash` is the server's canonical idempotency digest and is distinct from the CLI's local SHA-256 of exact request bytes. `submitted` means a canonical Router event and same-block `launchStamp` getter record match the prepared artifact but have fewer than 64 confirmations. `finalized` means the same evidence reached at least 64 confirmations. After the controller wallet broadcasts the exact transaction, poll the single-resource GET. That route is the canonical full-output status path. POST only captures the bounded observation window; the durable lifecycle worker and list reads can make bounded progress on pending rows. Additive `lifecycleQueue` reports worker scheduling and retry state only: queue completion is not launch finality, and queue retry does not change launch status. After website discovery refreshes, a finalized launch is eligible to appear in Explore and the connected wallet's Profile without Registry publication. Third-party discovery and listing depend on each indexer implementing the published Router verification flow. GET https://api.programmable.market/v3/finalized-custom-launches is an unauthenticated bounded newest-first feed of Router-finalized Custom identities. Each item carries required `launchProfileVersion` (`2.0.0`, `3.0.0`, `3.1.0`, `3.2.0`, `3.3.0`, or `3.4.0`) together with its launch-bound metadata when that profile defines it. Consumers key identities by `routerLaunchId`, not the private request UUID, and must not infer metadata requirements without `launchProfileVersion`. Exact `3.2.0`, `3.3.0` and pending `3.4.0` carry project metadata; legacy `2.0.0`, `3.0.0` and `3.1.0` remain additive compatibility records under their original semantics. The feed contains no API key, pending request, controller-private request bytes or wallet action. A downstream indexer may keep its own bounded last-known-good snapshot with explicit freshness; the endpoint does not embed stale data in errors. After a bundled request is finalized, source verification runs independently for every exclusive component. Optional `sourceVerification` is server-authored and uses `queued`, `retrying`, `exact_match` or `needs_attention`. Only literal `exact_match` for every component means Source verified, and that state requires the independent protected-source/build/compiler/settings/finalized-transaction/bytecode composite in addition to the explicitly non-authoritative provider observation. Clients never submit or infer this state. Explorer failure never blocks or revises launch finality. The current website claim flow supports only explicitly verified fee models. A Router-stamped arbitrary Custom hook is not automatically claimable. FADE has a specifically bound adapter, not a generic hook capability. The reserved `fees:claim` and `buybacks:manage` API operations are not live. ### Provenance boundary A successful Custom Launch API flow can establish that the finalized coin was launched through Programmable when the Router stamp verifies. The Router verifies fixed runtime, token, hook, PoolManager and pool bindings and requires an initialized pool with nonzero `sqrtPriceX96`. Static admission and Router simulation do not establish safety, honeypot resistance, active liquidity, tradeability or fee behavior; the Custom graph owns those behaviors. Normal pool initialization adds no liquidity. Ordinary concentrated liquidity requires a project-funded position. Zero classical LP works only when the project hook and initializer implement custom accounting or hold launch inventory; volume cannot create initial liquidity from nothing. The agent attestation remains caller-declared offchain evidence. Programmable checks its shape, digests and graph binding but does not fetch or assess the evidence or adopt the agent's claims. Exact-source status is a separate server-authored provider result. Router provenance does not establish approval, safety, audit coverage, liquidity, tradability, endorsement or future value. ## Scope Only launches executed and stamped through this Router inside its published block range have Router V1 provenance. Launches before `startBlock`, and direct factory calls outside the Router even when later, do not. After bootstrap from the manifest and ABI, point verification requires only an Ethereum provider. A Programmable launch-feed API, indexer, Supabase project, or application server is not required. Continuous event indexing is optional. ## Router binding | Field | Canonical value | | --- | --- | | `status` | `live` | | `chainId` | `1` | | `address` | `0x8622DD5bAb44185f2A458ac90384Ac99248f8d56` | | `startBlock` | `25717612` | | `endBlock` | `null` | | `runtimeCodeHash` | `0x40e27ecf201761d5eb66bc4f2d5c6124831ef078d7baf458ca5f41b1a8108546` | | `abiSha256` | `sha256:bb4e728e9f9c850eb01f928e8a798ac206a82e241a8d93b3b3c686635c88ed86` | | `finalityConfirmations` | `64` | Read the stable discovery document, follow `manifestUrl`, then use `launchStampRouter` from the deployment manifest. Verify the downloaded ABI bytes against `abiSha256` before the first lookup. At the selected canonical block, also verify the Router runtime and immutable binding getters from the manifest. ## Launch kinds Classify only from the returned stamp record. Names, tickers, logos, creator metadata, factory lookalikes, and shared hook addresses are not provenance. | Value | Enum | Public label | | --- | --- | --- | | `1` | `CustomGraph` | Programmable Custom | | `2` | `Classic` | Programmable Classic | `LaunchKindV1.Invalid = 0` is never a Programmable launch classification. ## Point verification Resolve one finalized canonical block. Use that block for every runtime, binding, lookup, record, and proof read. Remote RPC URLs must use HTTPS. Plain HTTP is accepted only for loopback development endpoints. ### Canonical preflight 1. Fetch the official discovery document and manifest. Require `status: live`, or `retired` for a historical read inside the published block range. 2. Require the complete manifest activation data: finalized canary evidence, chain and Router binding, all six immutable binding fields, block range, finality policy, runtime and ABI hashes, the sole payable atomic signature and selector, every getter descriptor, and every event topic and indexed layout. 3. Resolve the chosen block to one concrete number and opening hash. Enforce `startBlock`, `endBlock` when present, and the published confirmation policy for explicit block-number reads. 4. Require `eth_chainId == manifest.chainId`. At the same block, require the Router runtime Keccak-256 and the exact downloaded ABI byte SHA-256 to match the manifest. Derive and validate every advertised getter selector, event topic, indexed layout, and the sole payable atomic selector from that ABI. 5. Call `CHAIN_ID()` and all six immutable address/runtime binding getters. Require exact manifest matches, then verify `eth_getCode` runtime hashes for the permit authority, Graph Factory, and PoolManager. ### Resolve the launch ID ### Token 1. Call `launchIdByToken(address)`. 2. A successful zero result is a `NOT_STAMPED` candidate. Complete any required closing canonical-block check before returning it. ### Uniswap v4 pool 1. Call `launchIdByPool(address,bytes32)` with `(PoolManager, poolId)`. 2. A successful zero result is a `NOT_STAMPED` candidate. Complete any required closing canonical-block check before returning it. ### Exclusive component 1. Call `launchIdByComponent(address)`. Use this path only for a component explicitly exclusive to one launch. 2. The shared Classic hook is not a launch identifier. 3. A successful zero result is a `NOT_STAMPED` candidate. Complete any required closing canonical-block check before returning it. ### Validate a nonzero result 1. Call `launchStamp(bytes32)` with the nonzero launch ID and require a supported nonzero `record.kind`. 2. Require valid address encoding for `launchWallet`, `token`, `hook`, `poolManager`, and `routeLauncher`. Require nonzero `poolId`, `poolKeyHash`, `componentSetHash`, `routePayloadHash`, `routeLauncherRuntimeCodeHash`, `expectedResultHash`, `permitDigest`, and `stampHash`. 3. Require exact queried identity: `record.token == token`, or exact equality with `record.poolManager` and `record.poolId`. The record PoolManager must also equal the immutable manifest binding. 4. For a token or exclusive component, call `stampProof(address)` and require the same launch ID and `record.stampHash`. Require a nonzero recorded `componentRuntimeCodeHash(address)`. 5. For `CustomGraph`, require `record.routeLauncher` and `record.routeLauncherRuntimeCodeHash` to match the immutable Graph Factory binding. For `Classic`, retain the permit-bound launcher and runtime recorded in the stamp; do not invent a Classic immutable. 6. A current component-runtime comparison is a separate drift signal. A mismatch does not change the historical Router-provenance result. 7. Prefer EIP-1898 `{ blockHash, requireCanonical: true }` reads. If the provider requires number-bound reads, refetch that height and require its closing hash to equal the opening hash before returning `STAMPED` or `NOT_STAMPED`. 8. Classify only from `record.kind`. Return `STAMPED` only after every required gate above succeeds. ### Result states - `STAMPED`: every manifest, canonical-block, runtime, ABI-descriptor, immutable-binding, lookup, record, identity, nonzero-field, proof, route, and any required closing-hash gate succeeds. Current component-runtime equality is reported separately. - `NOT_STAMPED`: the canonical token, pool, or exclusive-component lookup succeeds and returns zero after any required closing canonical-block check. - `UNAVAILABLE`: the Router binding does not cover the requested block, the chain is inactive, or required manifest activation data is incomplete. - `INDETERMINATE`: RPC, ABI, runtime, block, decoding, or cross-check evidence is incomplete or inconsistent. Only a successful canonical zero lookup is `NOT_STAMPED`. A timeout, pruned block, malformed response, chain mismatch, unavailable finalized block, or inconsistent nonzero response is `INDETERMINATE`, not an unsafe claim. `ORPHANED` is an event-observation or reorg state, not a point-verification outcome. ## Discover new launches when needed Point verification does not require an indexer. If you need continuous discovery, scan only the canonical Router from `startBlock`, treat logs as candidates, and establish provenance with the point verifier. | Event | Full signature | topic0 | | --- | --- | --- | | `ProgrammableLaunchStampedV1` | `ProgrammableLaunchStampedV1(bytes32,address,address,address,bytes32,bytes32)` | `0x6cf479a102f1eebc9244f48f8d68f6aa52b4c5a4516318df58ba46614a5b14f2` | | `ProgrammableLaunchRouteStampedV1` | `ProgrammableLaunchRouteStampedV1(bytes32,uint8,bytes32,bytes32,bytes32)` | `0x45e7cc355b63ca67d6278a0d8d23470ce2a0741a9c60283d7dee712df7a877a5` | | `ProgrammableComponentStampedV1` | `ProgrammableComponentStampedV1(bytes32,address,uint8,bytes32)` | `0x8147265e7396d6400cee8d049456a1f7438fdfbe2a7c81c976d51ba67e52ff4b` | 1. Require `eth_chainId == 0x1`, the exact Router emitter, full topic signatures, runtime, ABI, bindings, block range, and finality policy. 2. Backfill bounded `eth_getLogs` chunks from `startBlock` through a finalized boundary. Respect `endBlock` if a future manifest retires this Router. 3. Persist block number and hash, transaction hash and index, and log index as the idempotency key. 4. Correlate the three event types by `launchId`; then reproduce the candidate with getter reads at the same canonical block. 5. Advance a durable checkpoint only through finality. Explicit block reads require at least 64 confirmations. 6. Replay an overlap on every run. Prefer EIP-1898 reads with `requireCanonical: true`; after a reorg, rewind to the last common finalized checkpoint and replay. 7. Begin polling or subscription from the overlapping checkpoint so backfill and subsequent subscription have no gap. ## Protocol fee claim discovery The launch feed is not the protocol fee claim queue. The claim inventory follows the exact execution contracts: Classic V2 and V3 coin rows come from complete canonical Launcher event scans while fee execution remains one aggregate claim per verified version hook; Classic V1 remains a legacy aggregate row. Custom V1 replays the complete Registry history and verifies current state, runtime, reward wallet, fee policy and accrued amount at one block. Stock uses the published fixed release asset set. Custom V2 remains unavailable until an exact deployed and finalized release binding exists. Unknown, revoked, mismatched or unverified sources block the combined claim instead of being omitted. The live console rescans before every attempt and publishes its machine-readable boundary at https://claimhazard.vercel.app/claim-discovery.json. Positive verified entries are sent only as one wallet-declared atomic batch from the fixed reward wallet. ## Canonical resources - [Discovery document](https://developers.programmable.family/.well-known/programmable.json) — stable entry point that supplies `manifestUrl`. - [Deployment manifest](https://developers.programmable.family/api/v2/manifest) — chain, Router, start block, runtime, immutable bindings, event topics, ABI URL, and ABI digest. - [Hosted Router ABI](https://developers.programmable.family/abis/ethereum/programmable-launch-stamp-router-v1.json) — hash the exact downloaded bytes and match `sha256:bb4e728e9f9c850eb01f928e8a798ac206a82e241a8d93b3b3c686635c88ed86`. - [GitHub Router reference](https://github.com/programmablehq/Developers/blob/main/docs/reference/launch-stamp.md) — complete point-verification specification and finalized PCAN test case. - [Terminal guide](https://github.com/programmablehq/Developers/blob/main/docs/guides/terminals-and-scanners.md) — backfill, checkpoint overlap, reorg, and finality handling. - [JSON-RPC verifier](https://github.com/programmablehq/Developers/blob/main/examples/verify-launch-stamp.mjs) — dependency-light implementation. - [viem verifier](https://github.com/programmablehq/Developers/blob/main/examples/verify-launch-stamp-viem.ts) — typed application implementation. ## Finalized PCAN vector Use this CustomGraph launch as the end-to-end integration vector: - transaction: `0xc07b4e70233534a1d4f435ffc9a636ed5f542f4aedcde35052c58224f378b612` - block: `25717953` - launchId: `0x5a52180427785716bff0a36218dde89f0459db265d0c2bdfcfde81a8fe733c92` - stampHash: `0x06cb71b38d9b8b1dd1ffcdb00f31c774be36f5473979c3831d5fd0c96cdaa579` - token: `0x9DEeB39D2590b0cAD5fc473F755C5F97Dcc8f7cE` - hook: `0xEBa46f25DfF528141dE5317109Acb5A989296044` - initializer: `0x87B108848B444bC44A01734D62C7be4a2fA64983` - PoolManager: `0x000000000004444c5dc75cB358380D2e3dE08A90` - poolId: `0x5c5a3ebee6840640642ba2bea526621a4962d2c89c388c36a2edb4725802a229` - launchKind: `1` (Programmable Custom) The token, pool, and exclusive components resolve to the same launch ID and stamp hash. Generic token or pool discovery by a third party is separate from verified Programmable provenance. ## What verification proves A Router record establishes provenance only after the published address, runtime, binding, lookup, and cross-check requirements pass. For its exact recorded pool, successful verification also establishes initialization during the same atomic launch transaction. It does not establish safety, tradability, current liquidity or pool state, audit coverage, review status, approval, endorsement, permission to launch, or terminal support. It does not automatically list or label a launch in GMGN, Axiom, FOMO, or any other terminal; each consumer must implement the published verification procedure. Router verification and the Developer API are read-only. Public V3.3 creation and lifecycle reads use a scoped wallet key, partner root or bounded partner subkey; wallet keys are managed at https://programmable.market/developers/api-keys. Earlier V2 and V1 history and schemas remain readable while their fresh POSTs are write-fenced. The provenance reference alone grants neither API access, launch authorization nor wallet authorization.