{
  "schemaVersion": "programmable.custom-launch-agent-setup.v1",
  "manifestDigest": "sha256:3cd25308629f932d6a75e4a7694e6bcb67e4471fd2c1782d3b11ba5a7e3f8b61",
  "requestSchemaVersion": "programmable.custom-launch-plan.v1",
  "text": "Manifest digest: sha256:3cd25308629f932d6a75e4a7694e6bcb67e4471fd2c1782d3b11ba5a7e3f8b61\n\nUse the normal Programmable API key with custom-launch:create and custom-launch:read. Never place it in a URL, source file or log.\nFetch /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.\nUse /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.\nFor 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.\nNew listed submissions must include publication.name, publication.symbol, a public HTTPS publication.imageUrl and at least one public project or social link in publication.links. Capabilities advertise publicationPolicy with schema programmable.public-launch-presentation-policy.v1. The image URL must return PNG, JPEG, WebP or GIF bytes with the matching image Content-Type; an HTTP 200 HTML page or redirect is not an image. This short check runs before compilation. Fix permanent metadata errors at the returned /publication pointer and repack with a new idempotency key. A temporary image-host outage is retryable with unchanged bytes and key. Stored reads, byte-identical replay, existing continuations and unlisted resources retain their original bindings. Publication metadata is display data and never creates launch or routing authority.\nRead currentTradeFeePolicy in live capabilities for trading fees. Current open-provenance trades routed through Programmable use 30 bps (0.30%), under programmable.routed-swap-fee.v2, charged once on gross output in the output asset. Historical signed obligations and verified existing pool fees retain their original rules without a second route fee. The separate feeModes field describes legacy-policy-v1 launch obligations, not the current open-provenance trading rate. Keep feeObligations empty for new open-provenance plans; do not copy the trading rate into a legacy launch obligation. An API stamp does not guarantee fees on external routes.\nPOST 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.\nOnly 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.\nPOST 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.\nNew submissions enter manual platform review automatically when the live review policy is enabled; no separate application is needed. Poll the same owned resource and display manualReview.state. Pending, rejected and expired reviews cannot open a new signing handoff. Approval opens a 24-hour window from approvedAt to expiresAt, including starting and signing the launch. Start does not reset or extend the approval window. Fetch the current resource again before signing: the server prepares fresh unsigned transaction deadlines within that window while preserving the reviewed execution. Historical transactions retain their original deadlines; replan against the current bindings for the 24-hour contracts. A resubmission does not extend approval. Existing broadcasts continue through their original recovery path. Platform review does not provide a contract audit or safety rating.\n\nReview feedback: read manualReview.reason before generic requiresRepack guidance. Reply or add HTTPS document links with POST /v1/custom-launch-reviews/feedback using {operation:\"reply\",chainId,launchId,revision,subjectHash,message,links}. Read it with {operation:\"ownerRead\",chainId,launchId}. Use the normal wallet API key. The linked submitting wallet can also reply on the website. A reply never changes execution bytes or grants approval. For an explicit replacement use {operation:\"replace\",chainId,launchId,revision,subjectHash,replacementReviewId}; only a newer submission by the same owner, controller and chain is eligible. Continue with manualReview.supersededBy.launchId when present. Replaced requests cannot be approved.\n\nEthereum preflight reviewReadiness includes named embedded calldata deadlines and the fee summary. Robinhood preflight emits advisory PLAN_WINDOW_INVALID findings at preflight.review_timing. The ownerRead review response includes assessment.timing and assessment.fees on either chain. Platform approval refreshes the platform permit only: it cannot refresh an initializer deadline. Allow 24 hours of review plus the 24-hour launch window in contract-compatible execution parameters. If now is 12:00 UTC October 10, an embedded deadline earlier than 12:00 UTC October 12 does not cover that full window. Repacking changes execution bytes and needs a new request; a contract limited to five-minute deadlines needs an execution-time deadline design. Unrecognized/opaque parameters and source-specific conditions still require review.\n\nRead reviewReadiness.fees or the ownerRead response assessment.fees for the route rate, recipient and fee basis. Custom hook and pool fees are additional unless the route verifies its documented existing-pool-fee waiver. combinedTotal:null and customHookFees:not_measured are unknown, not zero fees. Launch approval and launch simulation do not prove buy/sell behavior. Operator fork checks separately record buy, sell and measured platform payout for the exact reviewed subject and fork block.\nAn 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.\nRequest 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.\nFor 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.\nThe 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.\nResponse 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.\nDirect 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.\nFor 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.\nIf 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.\nAfter 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.\nReplan 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.\nThe 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.\nHistorical 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.\nTrack 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.\nAn 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.\n",
  "guideUrl": "/v4/chains/4663/custom-launch-contract/guide.md"
}