Custom Launch API

Robinhood, separate token and hook

Use the V4 profile and CLI selected by live discovery.

Robinhood, shared token and hook

Use the MultiRole V2 guide, request packer and client. Its request format is separate from V4.

Ethereum Mainnet

Follow the V3 quickstart and the profile accepted by Ethereum capabilities.

Robinhood Native20 charges 20 bps (0.20%) for Programmable per successful buy or sell. Creator and pool fees are additional. A zero creator rate produces zero creator rewards while the platform fee still accrues. Read the fee calculation and claim rules.

Use public V3.3 for new Ethereum custom-hook launches. V2 and V1 history and schemas remain readable, but new requests are permanently write fenced with nonretryable CUSTOM_LAUNCH_V2_READ_ONLY and CUSTOM_LAUNCH_V1_READ_ONLY. On Ethereum, only V3.3 accepts new submissions. For Robinhood V4, read the live discovery manifest and use version 4.1.0 only after its public release gates and immutable CLI evidence pass.

1. Build and test every launch component from one exact source revision.
2. Create a wallet-bound key from API keys, or use the partner credential issued to your integration. Store it only as PROGRAMMABLE_API_KEY.
3. Install @programmable/launch 3.3.9 from the immutable GitHub Release asset, verify its checksum, then use the programmable-launch binary.
4. Run pack, then validate --remote against the exact Standard JSON, artifacts and evidence. Never enter a derived hash by hand. Local validation prepares the request; the API server decides whether it may reach a wallet.
5. Run programmable-launch submit ./launch.json --config programmable-launch.config.json, then watch status until authorized. Stop for controller-wallet review and signing, then watch the same request until finalized. The API and CLI never sign or broadcast.

• programmable_cli_dir="$(mktemp -d)"Create an isolated download directory.
• 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.tgzDownload the pinned release asset.
• 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.sha256Download its checksum sidecar.
• (cd "$programmable_cli_dir" && shasum -a 256 -c programmable-launch-3.3.9.tgz.sha256)Continue only after this reports OK.
• npm install --global "$programmable_cli_dir/programmable-launch-3.3.9.tgz"Install the verified local bytes.

Open the raw compatibility guide

CLI 3.3.9 remains the installable release for live Ethereum V3. Robinhood V4 uses the profile advertised in live discovery, 4.1.0 for this request contract. Verify its release manifest, exact source commit and tarball checksum. The V4 OpenAPI, pack-config schema and source-verification schema describe the V4 request contract. Re-read live discovery and current capabilities before use. Your platform API key authorizes requests; your wallet separately signs the onchain transaction and pays gas.

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.

received

The immutable request is durably accepted. No wallet action exists.

validating

Server validation, admission, external-reference checks and exact Router simulation bindings are running.

action_required

Fix the server-authored remediation, rebuild and submit a new immutable request. This is not a wallet action or manual approval stage.

authorized

Server gates passed and the exact wallet transaction is bound. It is not signed or broadcast.

awaiting_wallet_signature

The controller must review and sign the exact transaction through the separate wallet handoff.

wallet_action_required

The controller must verify chain 4663, sender, Router, value and calldata, then submit through the wallet.

submitted

The exact wallet transaction was submitted; no chain checkpoint is implied.

sequencer_soft_confirmed

Robinhood sequencer evidence exists but remains reversible.

ethereum_posted

The Robinhood batch is posted to Ethereum but has not satisfied the finality policy.

finalized

The exact launch evidence satisfies the published Robinhood-to-Ethereum finality policy.

failed

Processing is terminal. Read the bound failure and remediation before creating a new request.

• programmable-launch status LAUNCH_ID --api-version 4 --chain-id 4663 --watch --until authorizedStop for separate controller-wallet review and signing.
• programmable-launch status LAUNCH_ID --api-version 4 --chain-id 4663 --watch --until finalizedPoll the same chain-scoped resource after wallet broadcast.

Provider source verification starts only after finalizedand remains independent. Finality does not imply sourceVerification.status: exact_match, and a provider retry does not revise finality. Programmable indexing, third-party indexing, trading readiness, Explore visibility and publication are separate outcomes.

• The CLI writes a mode 0600 journal before the first request and binds the Idempotency-Key to exact request bytes. It never writes the API key.
• Wallet keys are managed through the connected controller wallet on programmable.market. Partner roots and subkeys are separate credentials advertised by customLaunchApi.partnerCredentials in discovery.
• A wallet key uses its bound wallet as launchWallet. A partner credential selects the exact controller in the request but cannot sign for it. The same current-profile metadata requirements apply to both credential kinds.
• Send Authorization: Bearer $PROGRAMMABLE_API_KEY only to https://api.programmable.market. Wallet keys, partner roots and bounded partner subkeys use the same canonical V3 create, preflight, list and status routes within their scopes. The Router V1 permit-reissue disposition route is wallet-key-only.
• Do not send the website wallet session token to the Custom Launch API.
• A partner root may manage one level of subkeys. A child's scopes, budgets and expiry cannot exceed its root, and a child cannot manage credentials.
• A partner root reads every launch attributed to its partner. A subkey reads only its stable lineage, rotation preserves that lineage history, and a separately issued subkey cannot read root or sibling launches.
• API scopes grant API operations only. No wallet key, partner root or subkey can sign, broadcast or bypass launch gates.
• Store the secret outside source control and logs. Key lists never return the full secret again. Put only $PROGRAMMABLE_API_KEY in chat, prompts and agent setup.

The V1 contract states a 90-day default expiry, a 366-day maximum and no more than 10 active keys per wallet.

• Use the machine-readable remediation catalog to inspect the exact repository, create programmable-launch.config.json and recover from local or API findings. The same catalog applies to every project; there is no project allowlist or private approval route.
• Pin the public source repository and exact immutable Git object, compile every target with solc 0.8.26+commit.8a97fa7a, identify the distinct token, hook and initializer roles, map address dependencies, and declare the real hook permissions, pool, funding, liquidity, fee, custody and withdrawal behavior. Collect the required token name, symbol, meaningful description, non-empty local image, website and X profile; other public links are optional.
• Create a programmable.launch-pack-config.v3 input from exact source, Standard JSON, artifacts and structured ABI values, following the machine-readable pack-config schema. The CLI derives every digest, locator, CREATE2 address and request byte. Never copy or invent them.
• Fetch public GET /v3/capabilities, then run the exact request through validate --remote. The authenticated POST /v3/custom-launches/preflight uses those same bytes, consumes no launch-creation quota or durable launch reservation, allocates no nonce, persists no launch and never signs or broadcasts. The authenticated request still consumes its ordinary route rate budget, including a partner credential's prepareRequestsPerHourbudget. It returns additive riskClassification, platform-owned behaviorEvidence and all six productTruthAxes: deployment, trading, platform_fee_evidence, source_verification, indexing and featured. A not-executed or needs-evidence result remains outstanding; it is not a caller-declared pass and cannot support a positive behavior, fee, liquidity or routability claim. The API server independently enforces objective static hard blocks and exact Router simulation before wallet handoff; an authenticated executed failure blocks.
• In EIP-3009 mode, accept the exact CLI-derived funding descriptor. Do not replace its funding intent or nonce domain. Current V2 authorization patching binds four zero ABI leaves: bytes32 nonce, bytes32 r, bytes32 s and uint8 v. Configure their numeric ABI argument paths with 1 to 16 indices from 0 through 255. Static tuple and fixed-array descendants are supported; dynamic parents and applicant-supplied calldata offsets are not.
• Tooling may report FUNDING_NONCE_DERIVATION_CONFLICT_SUSPECTED or FUNDING_NONCE_CONFORMANCE_UNPROVEN when exact source, ABI and compiler artifacts cannot prove the complete nonce dataflow offline. Inspect a suspected conflict. The mandatory exact Router simulation is the final execution-compatibility detector, not a safety, admission, liquidity or fee-behavior claim.
• Pool initialization does not add liquidity, and trading volume cannot create the initial liquidity from nothing. Select the exact external, launch-seeded or hook-inventory model implemented by the project. V3 does not inject Classic liquidity automatically.
• Admission is automatic. At action_required, read the exact single-resource remediation, fix the reported target and source or config, rebuild, repack and submit a new immutable request. Retrying unchanged bytes or requesting a manual allowlist cannot bypass a blocking finding.

• The Router supports 2 to 16 targets, while this profile requires 3 to 16 because token, hook and initializer roles are distinct. All fourteen Uniswap v4 permission bits are supported, including custom-accounting return deltas, provided the declared mask, compiled permissions and low address bits match exactly.
• 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 evidence is verified. Arbitrary custom hooks are not automatically fee-enforced, and the open arbitrary-hook lane carries no Programmable fee claim. Static fees and the 0x800000 dynamic-fee sentinel are supported.
• Native and ERC-20 quote currencies are structurally supported. Funding can be absent, carried as the exact native value of the separately reviewed Router transaction, or use an unsigned USDC EIP-3009 descriptor. Only the EIP-3009 mode contains a funding challenge and authorization patch. CLI 3.3.9 uses programmable.eip3009-authorization-patch.v2 to bind the zero nonce, r, s and v ABI leaves before any wallet signature.
• For EIP-3009 funding, the website first validates and explicitly asks for eth_signTypedData_v4. Only after backend signature verification, final calldata construction and simulation does it present a separately reviewed Router transaction. Neither action is auto-signed or auto-broadcast.
• Initializer source, build, runtime, unsigned patch, final calldata and simulation are exact per-launch bindings. There is no separate global initializer trust root.
• Profile 3.3.0 binds every static finding but hard-blocks only seven objective code-and-role conditions: CALLCODE, source or runtime SELFDESTRUCT, definitively missing or invalid callback authentication, a literal wrong PoolManager, or a missing enabled callback. Proxy, delegatecall, mint, tax, pause, liquidity and return-delta surfaces require evidence instead of categorical rejection. Hard-blocking matches return action_required; all other findings remain visible as needs-evidence or warning conditions. There is no manual project allowlist.
• Every enabled v4 permission must resolve to a concrete reachable callback implementation. An interface declaration or fallback-only route does not qualify.
• With no blocking match, server-authored platformAdmission binds the report hash and warning codes with no_blocking_static_finding, requires Router simulation and carries safetyClaim: false and feeBehaviorClaim: false.

• The CLI binds one explicit model into the request hash: external concentrated liquidity remains liquidity_required; launch-seeded and hook-inventory custom accounting remain assessment_required until separate exact evidence exists. A project cannot declare its own pass.
• Ordinary concentrated liquidity requires the project to fund and create a position. Trading volume cannot create initial liquidity from nothing. Position custody, withdrawal and any lock or burn must be disclosed.
• Zero classical LP works only when the project hook and initializer implement custom accounting or hold inventory that can exchange against incoming assets. Funding mode none does not make an empty ordinary pool liquid.
• Exact-source static admission and Router simulation are not an audit or a guarantee of safety, honeypot resistance, liquidity, tradeability or fee behavior. Disclose transfer, pause, upgrade, mint, liquidity-custody and buy/sell controls.

schemaVersion

programmable.custom-launch-create-request.v3

launchWallet

The Ethereum controller wallet for the launch

chainId

String 1

nonce

A nonzero lowercase bytes32

sourceDescriptor

One DeterministicSourceBundleV2 descriptor

sourceBundleManifest

One complete, non-empty, UTF-8 path-sorted SourceBundleManifestV2

graphBundle

One executable CustomGraphBundleV1

permitWindow

The bounded Router permit validity window

launchProfile

The complete general hook profile

launchProfileSelection

The exact target-role and deployment bindings

launchProfileHash

The CLI-derived canonical profile digest

launchIntentHash

The CLI-derived request intent digest

agentAttestation

One self-attestation for the exact launch intent

verificationBundle

Exact source, compiler and constructor bindings

The platform recomputes the manifest digest and checks that the source descriptor, manifest and graph name the same source bundle. The graph accepts 3 to 16 acyclic direct targets, exactly one token target and one hook target. The complete graph input is limited to 524,288 bytes; per-target init code is limited to 49,152 bytes and initializer calldata to 131,072 bytes. Use the V3 OpenAPI contract for every nested field, enum and bound in reference profile 3.4. Submit that profile only when live discovery and capabilities advertise profile 3.4.0. The retained V1 contract documents compatibility reads and its read-only creation route.

The public CLI derives every commitment from exact source, build and evidence files. It derives the full runtime hash only when deployed bytecode has no unresolved link or immutable references. Otherwise it fails closed with RUNTIME_MATERIALIZATION_REQUIRED.

A Programmable share of 1,000 hundredths of a bip, equal to 0.10% = 10 bps, is claimed only for a fee-certified profile or adapter and its exact stamped PoolKey. That lane requires server-authored per-launch fee-path evidence before the platform makes that claim. Arbitrary custom hooks are not automatically fee-enforced, and the open arbitrary-hook lane carries no Programmable fee claim. Revision-3 local validation, static admission and Router simulation do not independently create feeBehaviorClaim: true. For that certified lane, the bound Programmable recipient is 0x4957f49620AFf3Adbbe8195a4f633E49cc93376c.

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 = 10%. The API server enforces the cap in both additive-platform-share and inclusive-selected-total modes. The separate platform value remains 1,000 hundredths of a bip, equal to 10 bps.

Standard JSON sources contain inline content; URL-only sources fail. Compilation units and components are uniquely UTF-8 sorted, and components exactly cover the graph. The default revision-3 profile pins solc 0.8.26+commit.8a97fa7a. Decoded Standard JSON is limited to 5,242,880 bytes per unit and in aggregate, with at most 2,048 inline sources. Revision-2 requests retain their compatibility contract. Existing legacy resources without a bundle remain readable and unverified.

V1 does not publish a universal check-ID catalog or define project-independent pass/fail semantics for those IDs. The submitting workflow chooses stable IDs for checks it actually ran, preserves the underlying evidence and attests each sha256: digest. Programmable validates shape, digest presence and graph-subject binding; it does not fetch or assess the evidence or adopt the attestation as its own claim.

• On timeout, 429 or 503, retry only the exact persisted bytes and honor Retry-After.
• A byte-identical replay can return the existing resource. A reused key bound to different bytes is a conflict.
• 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. Stop at authorized. The API and CLI never sign or broadcast the returned transaction.
• Keep deployment, trading, platform-fee evidence, source verification, indexing and featured placement as independent product-truth axes. Preflight eligibility does not prove any later external state.

Service readiness and API authorization do not replace controller approval. The connected wallet must review the exact chain, sender, Router, value and calldata before a separate signature.

During simulating, a signed permit may exist only inside a worker-private simulation envelope. Public output remains null in simulating and failed; the evidence gate controls permit and wallet-transaction exposure, not internal permit signing required for simulation.

New V3 requests share a durable global admission cap of 120 created requests per hour and 500 per day. An exact idempotent replay is checked first and consumes no additional capacity.

received

The request is durably accepted.

validating

Request and graph validation are running.

pending_review

Server-side admission and the selected lane's per-launch evidence decision are still running. No wallet transaction exists.

action_required

One of the current profile's exact hard-blocking code-and-role rules matched. Read the exact bound report and contact support with the request ID when directed. This is not a wallet-signing stage.

awaiting_funding_authorization

EIP-3009 mode only, after the server evidence gate: review and sign the exact typed data in the connected controller wallet.

funding_authorization_verified

The separate funding signature was verified and final calldata construction can continue.

simulating

The final graph and exact Router transaction are being simulated.

prepared

The exact artifact exists. output.signedPermit and output.walletTransaction are both null. There is nothing for the wallet to sign yet.

authorized

The server verified the evidence required by the selected lane, and the platform permit and exact output.walletTransaction exist. The controller wallet has not signed or broadcast it.

submitted

Canonical Router event and same-block getter evidence match below 64 confirmations.

finalized

The matching canonical evidence has at least 64 confirmations.

failed / cancelled

The request is terminal. Read failure before deciding whether to create a new request.

After wallet broadcast, poll the single-resource route to drive exact reconciliation. GET /v3/custom-launches is a newest-first exact-credential-principal history view with bounded summaries; its output is always null. Use the single-resource route for the artifact, wallet transaction and durable failure. Its additive lifecycleQueue reports bounded worker scheduling and retry state only; queue completion is not launch finality.

• A finalized Router launch is eligible for Explore and the connected wallet's Profile after website discovery data refreshes. Finality is not an immediate listing SLA.
• Router provenance does not require a Custom Registry record. Third-party discovery remains controlled by each indexer.
• Router provenance alone does not create a claim route. Only explicitly supported fee models appear in the current website claim flow; an arbitrary Custom hook is not automatically claimable.
• FADE uses a specifically bound adapter. That does not create generic fee claiming or buyback management for arbitrary hooks.
• V1 scopes fees:claim and buybacks:manage are reserved and disabled.

400

Fix malformed JSON, fields, query values or the idempotency key before retrying.

401

Use an active, unexpired and unrevoked credential from PROGRAMMABLE_API_KEY.

403

Use a credential with the required scope and access to the exact launch principal.

404

Verify the request UUID and key. Do not infer whether another wallet owns that ID.

409

Keep the original idempotency key and bytes. A conflicting binding must be fixed locally, not retried with changed bytes.

413

Reduce the body to at most 8,388,608 bytes.

415

Send Content-Type: application/json.

422

Fix the reported source, graph, attestation, verification or permit binding. Do not retry unchanged.

429

Honor Retry-After. An exact replay does not consume reservation quota.

503

Honor Retry-After and retry only the byte-identical request. Service availability never grants wallet signing authority.

500

Keep error.requestId for support and preserve the original request-byte binding.

In an HTTP error, error.requestId is a correlation ID for that response. It is not the Custom launch resource requestId. A resource-level failure is the durable lifecycle failure for that launch request.

Check API readiness. For action_required, preserve the resource requestId and exact static report. For HTTP errors, preserve error.requestId. For support, send only that request ID, HTTP status, UTC time and error code. Never send the API key.

Generic fee claims, buyback management, reusable-template publication and a public Hookbuilder are not granted by the V3 Custom Launch API. Use the operation and credentials defined by each separate service.