# Deployment, verification and operations

## Browser workflow

Start at /existing to verify the Long or Pons token and its available capabilities, then use /deploy to configure a supported module. Pons discovery is version-specific. Long pool-based modules resolve the exact initializer, PoolKey hash and currencies for the supplied PoolId; do not apply that procedure to a Pons source without a supported integration. Simulation executes the exact contract creation call and estimates gas. The wallet receives the displayed calldata, sender, chain4663 and zero ETH value. Network gas is paid separately.

After submission, Longer waits for three L2 block confirmations, checks the canonical receipt block, transaction sender/target/input/value, and compares the full deployed runtime with the simulation result. The receipt includes address, transaction, block hash, runtime hash, constructor arguments and compiler settings. Pending deployment recovery is stored only in this browser. If the wallet returns an ambiguous result, inspect it before retrying.

Three L2 confirmations are an operational checkpoint, not Ethereum settlement finality. A deep reorganization can invalidate a previously observed receipt. Refresh the policy page before funding or assigning rights.

## Attach an existing Long creator fee stream

Open /policies with the deployed LongerFeeVault address. The page matches the release bytecode and reconstructs configHash from actual settings, checks the source runtime and pool, and reads current fee shares. Connect the wallet that currently owns the desired LP-fee entitlement.

Select “Permanently attach my creator fee rights.” Simulation checks that this wallet has shares. A separate explicit wallet call sends updateBeneficiary(poolId,vault) to Long's initializer. This permanently moves the wallet's full current LP-fee entitlement; it cannot be moved back by this vault. After confirmation, both the old and new entitlement mappings are read. Do not use a historical genesis beneficiary array as proof of current ownership.

The deployment alone has no entitlement. The period between deployment and attachment is visible and is not represented as a genesis lock. This flow does not transfer Long's separate hook fees, change token ownership, or eliminate upstream governance.

## Pons funding controls

Deploy the downstream holder policy, then configure and verify LongerPonsFeeVault with `(token, recipients, phase0, phase1, transition)`. Open that vault under /policies and select “Connect my Pons creator fees.” Active v1 requires the original deployer wallet and calls `setFeeRedirect(token, vault)` on the verified locker. Reviewed v2 requires the current creator-fee recipient and calls `transferCreatorFeeRecipient(token, vault)` on the verified factory. The app rechecks current authorization, simulates the call, and confirms the vault as recipient after the transaction.

The v1 deployer can redirect future fees again. The v2 owner can propose an override with a three-day delay and three-day execution window; a voluntary recipient change does not cancel a pending override. Monitor the source and recipient afterward. Longer fixes its own distribution rules, not these upstream powers. Direct funding of a compatible holder policy needs no platform fee ownership. See [platform support](platform-support.md).

For the Pons vault, use `harvest(currency)` to collect and account both canonical assets on v1, or the selected escrow asset on v2, `sync(currency)` to account supported funds already received, and `payout(currency, index)` to deliver one fixed recipient’s credit. V2 also offers `harvestUpTo(currency, maximum)`; both versions offer `payoutUpTo(currency, index, maximum)`. The optional maximum limits each transfer, leaving the remaining escrow balance or recipient credit in place. The app accepts asset units; direct ABI calls require base units.

For a buyback-enabled Pons v2 token, call `releaseVestedFees()` before harvesting vested launch-token fees. The vault calls Pons as the beneficiary; Pons credits the vested creator allocation into escrow, and the next token harvest claims it. This releases an existing vest and does not execute a new buyback. Pons internal-swap sweeping still depends on its operator. Longer’s buyback execution module remains Long-only.

These actions use only the vault’s own funds or its canonical fee entitlement. They request no token approval and cannot pull from the caller’s wallet. Transfer caps, issuer restrictions and insufficient upstream balances can still prevent a transfer; simulation must pass before signing.

## Anyone can execute

The policy page exposes supported public actions only: harvest, sync, fixed payout, budget release, overflow release, bounded buyback, permanent liquidity add, fee collection/delivery, holder checkpointing, wallet claims, stake activation and withdrawals. Each transaction is independently simulated and reviewed. A keeper has no special role and cannot redirect a payout.

For direct execution, download the ABI from /contracts/<ContractName>.abi.json and call the documented function using any compatible wallet or RPC client. No Longer server signature is required. If the site is down, contracts continue following their existing rules.

## Operator service

scripts/keeper.mjs is a bounded runner. It defaults to simulation only and requires both an explicit --execute flag and a locally configured KEEPER_PRIVATE_KEY to send transactions. Never enter that key into the website or chat. Configure only the listed policies/actions in an operator-owned JSON file. The runner checks release bytecode/configuration before simulation, applies gas and transaction-count limits, records pending hashes before waiting, and reconciles them before subsequent sends.

Run one writer per keeper key. Use a dedicated low-balance gas wallet, an authenticated RPC and persistent storage for pending state. /api/health reports local web process health; Railway's startup probe is not continuous chain monitoring. Monitor /api/network separately and alert on repeated keeper errors, dependency mismatch, unexpected balances and long periods without confirmed progress. No funded production keeper has been started by this release.

## Incidents

A frontend warning or action restriction cannot pause an immutable contract. Preserve transaction hashes and exact observed blocks. If a token issuer freezes an asset, other supported payout paths remain independently callable where documented. A fixed wrong address, unavailable conversion route or permanently unusable price bound cannot be repointed. Publish confirmed facts and the affected policies; never imply administrative recovery exists.

## Railway

The Dockerfile builds the existing Vinext app with LONGER_DEPLOY_TARGET=railway, creates Node standalone output and runs it as a nonroot user. It uses Railway's PORT and handles SIGTERM/SIGINT with a bounded drain. The /api/health startup probe does not depend on an external RPC. Sites/Cloudflare remain a separate default build target.

No wallet or keeper secret is embedded in the image. Use Railway service variables for actual operator configuration only after identifying the operator and reviewing transaction limits. The web service itself does not need a signer, database or private key.

## Holder checkpoint keeper configuration

Use a file like this after deploying and verifying your actual policy:

```json
{
  "policies": [
    {
      "address": "YOUR_VERIFIED_HOLDER_POLICY_ADDRESS",
      "actions": [{ "functionName": "checkpoint", "args": [] }]
    }
  ]
}
```

Run `node --experimental-strip-types scripts/keeper.mjs keeper.json` for one simulation-only pass. Add `--execute --loop` only with an operator-owned gas key configured in the environment. The runner obtains the latest due UTC boundary and fixed exclusions from the contract, fetches canonical historical proofs and archives the bundle under `PROOF_DIRECTORY` (default `keeper-proofs`). A not-due, expired, already processed or invalid snapshot produces an explicit action failure. No allocation publisher signs a root. Native system contracts are never approximated with EVM BLOCKHASH.

Keeper gas limits apply to the estimate plus a 20% buffer. Long policies and all non-checkpoint actions keep the `MAX_GAS` default of 1,500,000. Pons holder checkpoints use `MAX_PONS_GAS` with a default of 5,000,000 because their additional permanent inventory exclusions require more proof verification. If `MAX_GAS` is explicitly configured, it also caps Pons checkpoints: the lower configured bound wins. Both limits must be between 21,000 and 10,000,000. Gas estimates above the applicable limit are logged and skipped; no transaction is sent. A small Pons V2 fixture already used about 1.45 million execution gas before transaction calldata and the buffer, so a 1.5 million limit is often insufficient. Real trie size and reward assets change the cost; inspect the actual simulation.


The browser policy page also offers checkpoint and per-asset holder claim actions. Enter the epoch number and holder wallet, or leave the latter empty to use the connected account. Simulation verifies the proof. Download the reviewed JSON to preserve the exact claim arguments. Archived checkpoint proofs establish the snapshot, but each wallet still needs its own historical storage proof. A proof bundle is public chain data; keep immutable backups if you promise long-term availability.

## 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.

## One-minute holder policies

Release 0.3 accepts 60-second intervals and starts at the actual deployment timestamp by default. Keep the 32-L2-block confirmation requirement. A checkpoint must still execute before the next interval begins. The proof response includes its expiry; the browser rechecks it and simulates again before asking the wallet to sign. A delayed wallet confirmation can still miss a short window, so prepare the next due snapshot if that transaction reverts. Missed budgets remain in the reward contract for the next successful checkpoint.

A keeper wallet pays network gas only. Reward assets remain in the reward contract and claims always pay the proved holder. The deployer wallet grants no token allowance to the passive module. Depositing an unrelated token does not make it spendable, and the module has no rescue function. Use only configured reward assets.