# Programmable Custom Launch Plan V1

Manifest digest: sha256:bc46db5afd756dbfe679b1befbb0efeec4aff63b531bccdbe62b063a1da62e8b

Use the normal Programmable API key with custom-launch:create and custom-launch:read. Never place it in a URL, source file or log.
Fetch /v4/chains/4663/custom-launch-contract/manifest.json, /v4/chains/4663/custom-launch-capabilities and /v4/chains/4663/custom-launch-credentials/me before building. Check the returned chain, controller, scopes, limits, manifest digest and live operation availability. A disabled create operation is a platform state; replacing a valid key does not enable it.
Use /v4/chains/4663/custom-launch-contract/request-packer.mjs with --input plan.json --out request.canonical.json --report pack-report.json. The plan is programmable.custom-launch-plan.v1. The source/compiler bundle is the existing exact-source V2 bundle.
For new launches set admissionPolicy to programmable.custom-launch-policy.provenance.v1, feeObligations to [] and publication.visibility to listed. Start from the openProvenance reference examples. Arbitrary custom contract and hook behavior is allowed without an audit, safety rating, fee, bonding curve or liquidity lock prerequisite. Exact source/runtime, authorized execution, the Programmable stamp and finalized public indexing remain required.
POST exact canonical request bytes to /v4/chains/4663/custom-launch-plans:preflight. Inspect every finding: code, stage, blockingAxis, jsonPointer, actual, constraint, witness, repair, retry and resumeUrl.
Only local declarative repairs from the same published parser may be applied with --repair. Repack and use the new reported idempotency key whenever any byte changes. Never rewrite source to satisfy an unproved claim.
POST the same packed bytes and Idempotency-Key to /v4/chains/4663/custom-launch-plans only when that operation is available. After an ambiguous response inspect or retry the exact same bytes and key; never start a second launch.
An existing exact replay remains readable after a manifest change or disabled release under the same current principal, controller, key, bytes and predecessor. A lookup miss still needs current admission. HTTP 409 means the original idempotency binding differs.
Request Programmable-Launch-Response-Version: 1.2 on create, exact replay, read, list and proofs. This version is required for atomic_execute_and_stamp_v2 and also reads historical multistep resources. Open returned walletUrl on Programmable. resumeUrl and HTTP Location remain API status paths, not website links. Existing 1.0 and 1.1 clients keep their closed V1 authorization contract; the header is required before creating or reading an Atomic resource. New clients may derive the fixed website path from a validated historical plan ID: https://programmable.market/developers/api-keys?view=history&chainId=4663&launchId=<planId>. The link carries no private authorization. Review each exact controller/chain/target/data/value/gas/nonce/deadline transaction and use the user's authorized wallet handoff. The API key itself cannot sign, broadcast or pay gas.
For one transaction that executes the project and records provenance, select atomic_execute_and_stamp_v2 only when live capabilities bind execution.atomic to the released address/runtime, selector 0x506aba45, permit authority and PoolManager roots. The issuer separately prepares and signs the versioned execution order, then the complete executeAndStampV2 transaction must simulate successfully before wallet handoff. Project calls see the Atomic executor as msg.sender. GraphDeployer calls therefore require that exact executor as authorizedLauncher and new salt/address derivations. Preserve source and explicit owner semantics. Direct EOA creation and a separate V1 stamp placeholder cannot be included in Atomic. atomic_graph_v2 retains its historical meaning and may still require a later stamp transaction. A static artifact never proves Atomic deployment or current availability.
The existing signed website BFF uses the same response header on /v4/chains/4663/wallet-admin/custom-launch-plans list, read and step-proof routes. Its owner checks remain required. Its proof response remains a non-authoritative discovery receipt with its API resumeUrl; 1.1 adds only the canonical walletUrl. The manifest declares these separate closed wallet-list and proof-receipt schemas.
Response 1.2 may add continuation {schemaVersion:programmable.custom-launch-plan-continuation.v1,status:replan_required,originalManifestDigest,currentManifestDigest,replanUrl} to an owned historical plan that needs issuance under a retired manifest. This derived advice leaves the original status, preflight, admission, signed evidence and steps unchanged. A still-valid admission-backed next step remains usable, and known transaction hashes continue through their original finality path. Reconcile every local unresolved wallet send, including an unknown hash, before following replanUrl with newly packed bytes and a new idempotency key. No successor is created automatically. Versions 1.0 and 1.1 omit this notice.
Direct EOA deployment uses the additive deployEoaCreate action: componentId, nonce and execution {target:null,data:exact compiled initcode,value,gasLimit}. Use an eoa or explicitly bound delegated_eoa_v1 controller and controller_multi_step_v1, derive expectedAddress from that controller and actual transaction nonce, and omit to when sending the wallet step whose to is null. Never rewrite the source or silently change its constructor sender. The terminal V1 stamp remains a later transaction after finality; count it before showing confirmation totals.
For an already delegated EIP-7702 wallet use controller.kind delegated_eoa_v1, runtimeCodeHash equal to keccak256 of its exact 23-byte 0xef0100 plus delegate-address designator, and authoritySnapshot {schemaVersion:programmable.delegated-eoa-authority.v1,chainId,delegate,delegateRuntimeCodeHash}. The backend independently binds both code reads and rejects drift. This adapter only sends standard type 0/1/2 transactions from the existing EOA; it does not send authorization lists, install or revoke delegation, batch transactions, or impersonate a Safe.
If a wallet send has an ambiguous outcome and no hash, preserve controller, chain, nonce and step digest indefinitely and recover the original transaction. Elapsed time or one empty provider lookup never permits another send.
After broadcast submit only the transaction hash to the bound step proof route, then poll the plan. Preserve finalized steps when replanning. Continue through independent finality, source/runtime readback, feed and website visibility.
Replan creates a fresh immutable successor and returns a server-generated replan binding to the predecessor hashes and finalized prefix. Review that binding; do not resubmit finalized transactions as new wallet steps or treat their stored evidence as fresh admission.
The open provenance policy performs no contract safety or economic assessment and produces no safety rating. Its stamp records exact launch provenance. Actual execution failures and missing chain evidence still prevent completion. Provider failures are analysis_pending and retryable.
Historical plans without admissionPolicy retain policy V1, including its 20 bps obligations and callback checks. Do not remove fields or rewrite an existing plan to change its rules; use a fresh plan and idempotency identity. Later business rules require a new policy version and apply to new launches.
Track execution, finalized public indexing and optional external distribution separately. External submissions require stored user opt-in. Show generic claim controls only for bound verified descriptors.
An explicit platform stamp action is an optional terminal call placeholder: authority launch_stamp/stampPlanV1, released target, data 0x and value 0. Use your own action ID outside the reserved platform: namespace. The protected issuer constructs the final stamp bytes from the finalized controller prefix.


The eight action kinds describe execution mechanics. Zero, one or many markets are allowed. Components can share roles or use arbitrary descriptive tags. The existing V2 bytes and replay domains remain unchanged.

Published limits

- requestBytes: 16777216
- jsonDepth: 64
- components: 16
- compilationUnits: 16
- ownerResourceBytes: 67108864
- ownerResponseBytes: 68157440
- publicProjectionResponseBytes: 16777216
- actions: 64
- markets: 16
- dependencies: 64
- effects: 256
- claims: 64
- initCodeBytes: 49152
- runtimeBytes: 24576
- calldataBytes: 131072
- compilationInputBytes: 5242880
- identifierBytes: 256
- listPageSize: 25

Use the exact public MultiRole guide path /v4/chains/4663/multi-role-custom-launches/guide.md for historical V2 requests. Its downloadable Inventory hashes are generated from the released files. A successful pack or download does not prove production execution.

Poll the owned plan at its stored resumeUrl after each lifecycle change. If an integration separately receives authenticated lifecycle notifications, treat them as discovery hints and re-read the resource. This contract does not publish a webhook transport or grant callback authority for finality, signing or publication.