# Release readiness Current platform scope: verified existing Long and Pons tokens, with version-specific capabilities. The historical release checks below began on 10 September 2026. This release implements deployable policy contracts and wallet workflows. It is not an independent audit or a statement that production contracts, a token launch or an operating keeper have been deployed. The [validation record](validation.md) identifies completed checks and their limits. On 14 September 2026, the project owner confirmed that the independent review passed. There is no public report, and the reviewer and covered code revision have not been specified. The [review record](review-status.md) distinguishes this project confirmation from verified coverage of a particular release, including Pons. The older pending-review status has been superseded by this confirmation. ## Implemented in this release - Passive holder rewards with permanent assets, scheduled historical balance snapshots, authenticated state proofs, fixed exclusions and non-expiring claims paid to the proved wallet. No stake deposit or trusted allocation publisher is required. - Fixed fee routing and a deterministic fee-vault factory; separate currency splits; capped scheduled funding; bounded buybacks and burns; permanent liquidity; optional staking rewards. - Wallet preparation, simulation, gas estimation, permanent-settings review, deployment, receipt verification and recovery of pending local deployment records. - Inspection of recognized contracts and their configuration, dependency checks, simulated public actions and explicit transfer of an existing beneficiary’s fee rights to a fee vault. - Holder checkpoint and claim proof preparation. A permissionless keeper can generate checkpoint proofs, archive checkpoint bundles and execute configured actions with gas limits, receipt checks and persisted pending intent. - Read-only validation of a supplied current Long-authorized launch payload. New-token launch execution remains a separate integration gate. - On-site documentation, downloadable contract artifacts and release evidence, plus website deployment configuration for Railway. Website setup remains limited to holder rewards, fee splitting and buybacks on their supported sources. Project budgets, currency routing, permanent liquidity and staking rewards remain locked for new setups. Existing policies retain inspection and operation access. ## Product boundaries Passive rewards use fixed snapshots, not continuous holding time. Choosing a reward asset does not purchase it, and listing several assets does not create an automatic rebalancing basket. Funding, conversion and reward distribution are separate contracts or actions. Long’s announced cross-asset campaigns and Community Mode are distinct from the general creator-deployed passive policy implemented here. The inspected public Long creation steps did not expose that setting; the research does not establish its absence from every backend or private integration. See [Long and Longer](long-comparison.md). A verified existing Long or Pons token can use the capabilities established by its lookup. Holder rewards and fee funding require separate checks. Long entitlement attachment is distinct from Pons recipient routing: v1 deployers can redirect recipients, and v2 retains an owner override after a delay. See [platform support](platform-support.md). A new token cannot yet be launched end to end through Longer solely by completing the builder or importing a signature. Long’s current authorization service, exact accepted parameters and atomic fee attachment still need a completed integration. ## Before handling production funds 1. **Fix the release identity and review scope.** Run the final checks against the exact release commit and generated artifacts. Publish source, compiler settings, creation/runtime hashes and the relevant test results. The project has reported that independent review passed; record the reviewer and covered code before attributing that result to a particular contract or later change. Do not label local tests or fork simulations an audit. 2. **Exercise a controlled chain deployment.** Use the intended wallet and chain to deploy a small canary policy. Verify the actual constructor values and runtime, attachment receipt, current Long LP entitlement or Pons creator-fee recipient, harvest, funding and payout. Exercise each supported Pons version separately; Long evidence does not establish Pons behavior. For holder rewards, verify the first due checkpoint and a real historical-balance claim. Record failures and recovery behavior before wider use. 3. **Publish actual deployment records.** Include chain ID, addresses, transaction hashes, mined blocks, source release, constructor values, configuration hashes and execution dependencies. For a fee vault, record the precise pool and transferred entitlement. A successful website build or a predicted address is not such a record. 4. **Operate checkpoint availability.** Configure and fund the keeper explicitly, first in simulation mode. Monitor the next UTC cutoff, confirmation delay, history availability, archive RPC failures and failed transactions. Prove that another operator can checkpoint through the public ABI. Preserve checkpoint proof bundles and arrange durable access to historical holder proofs; stored checkpoint bundles alone do not contain every wallet’s claim proof. 5. **Check actual funding routes and remaining controls.** Confirm reward-token compatibility, decimals, exclusions, real transfer behavior and exact recipient addresses. Check that each intended reward asset can actually reach the holder policy. A token metadata response cannot establish this. Test intended conversion pools and thresholds with controlled amounts where conversion is used. 6. **Make operations attributable.** Publish the actual service operator, support and confidential security-reporting channels, and applicable service/privacy terms before inviting public use. These details must come from the operator; this release does not invent an entity, contact address or audit provider. ## Additional gate for new-token creation Obtain access to Long’s accepted authorization flow and confirm its current launch and listing requirements. Verify the current proxy implementation, enabled signer, exact token factory, pool parameters and required upstream allocations. Implement and simulate the full authorized transaction so that destinations exist before fee rights are assigned. Verify token creation, pool identity, vault code, entitlements and listing after execution. Keep this path unavailable until these requirements are satisfied. The supplied authorization checker is useful evidence for a particular payload. It does not authorize Longer to obtain signatures, certify listing acceptance or establish that a passive holder module can be created before its required existing token is deployed. ## Website and keeper deployment Railway serves the application. Deploying it does not deploy a contract, transfer fees, create a Long or Pons listing, fund rewards or start a keeper. Check the public URL, health endpoint, RPC-dependent routes, mobile flows and release documentation after the website deployment. The keeper is a separate process. Simulation is the default; transaction execution needs an explicit configuration, a dedicated funded key and monitoring. Never put its private key in a browser bundle or a downloadable example. Configure only the intended policy addresses and actions. Holder checkpoints are generated dynamically; holders still claim through the website or a compatible relayer. If a submission result is ambiguous, reconcile the persisted intent before retrying. ## Incident limits The website may stop preparing transactions or display an incident notice; deployed contracts continue to follow their code. There is no policy administrator who can repair a wrong recipient, change exclusions, revise a reward schedule, withdraw permanently locked liquidity or sweep reserved holder claims. Issuer freezes, unsupported transfer behavior, unavailable proof infrastructure and unusable fixed trading parameters can stop parts of the system. Report affected addresses and observed behavior precisely. Provide direct-call and claim options that remain available. Do not promise a rescue or upgrade mechanism that the deployed contract does not contain. ## Archive RPC availability The default public BlockReq RPC currently limits historical state to its most recent 32,768 blocks. This is shorter than the onchain history window. A production operator must configure `HOLDER_PROOF_RPC_URL` as a private HTTPS archive-RPC variable in the Railway operator service, or provide durable holder-proof distribution. The hosted web app forwards proof requests to that service. In a deployment without the hosted operator, configure the web service and any standalone keeper instead. The URL is server-side only; never put credentials in public configuration. Recent checkpoints are supported by the public endpoint. Older claims can use a previously exported proof pasted into the policy page; otherwise an archive provider is required. Non-expiring contracts alone do not guarantee historical data availability. ## Hosted operator update — 11 September 2026 The Railway application now includes an existing-token compatibility flow at `/existing`, a separate operator service with persistent proof storage, and live infrastructure status at `/status`. Requested wallet proofs are verified against onchain snapshot roots before preservation. The operator starts without a signing key or policy allowlist; transaction execution, full archive coverage and a completed production canary are not implied. See [the operator guide](operator-guide.md) for private configuration, proof coverage, backups, and the read-only canary verification command.