# Existing-token operations and proof preservation

Historical operator rollout: 11 September 2026. Current contract and platform support are documented in [modules](modules.md) and [platform support](platform-support.md). The application adds existing-token lookup, a separate Railway operator service, durable proof caching and a read-only canary verifier. No new production contract or funded keeper is implied by a website deployment.

## Add a policy to an existing token

Open `/existing` and enter a Long or Pons token contract on Robinhood Chain. The lookup checks the recognized platform/version and token dependencies, and reports holder rewards separately from fee-routing capabilities. Long checks include its Airlock record, integrator, initializer, pool and fee-distribution state. Pons uses its verified version-specific sources. A match is not a platform listing or endorsement; unknown versions and unsupported token implementations remain unavailable.

Anyone may deploy and directly fund a compatible holder policy. The token contract, balances and pool remain the same. For Long, only a wallet with a positive current `getShares(poolId,wallet)` entitlement can commit those LP fee rights to a Longer vault. Genesis beneficiary arrays are not used to prove current ownership.

The following fee-vault sequence describes the supported Long path. For Pons, deploy LongerPonsFeeVault and follow the version-specific steps in [operations](operations.md): active v1 uses the original deployer’s locker redirect, and reviewed v2 uses the current recipient’s factory transfer. The v1 deployer can redirect again; v2 retains the three-day-delayed owner override described in [platform support](platform-support.md). Direct funding remains separate from platform fee routing.

1. Check compatibility. Current fee ownership is read onchain and checked against the connected wallet before attachment.
2. Deploy holder rewards with fixed assets, exclusions and a deployment-time or future UTC start. Verify the deployment receipt.
3. For ongoing creator-fee funding, deploy a fee vault whose recipient is the verified holder policy. Make sure each fee currency is supported by a downstream funding route. Selecting another reward asset does not buy it.
4. Inspect the fee vault under `/policies`. From the wallet that currently owns the intended fee rights, simulate and confirm attachment. Verify the original entitlement was transferred to the vault.
5. Fund the intended reward asset, operate the first checkpoint and claim a small positive reward before wider use.

Policies are immutable from deployment. Fee routing becomes effective at the attachment transaction. Earlier token activity is not retroactively covered. Longer does not acquire either platform's separate fee allocations or token-issuer powers. Pons recipient controls can change future funding while the Longer policy itself remains fixed.

## Railway operator

The `operator` service uses `Dockerfile.operator`, listens on port 3000 and stores its SQLite database and keeper state on the `/data` volume. It has no public domain. The web service reaches it over Railway's private network. A random service token authenticates requests; the web variable references the operator variable without putting the token in source. The container adjusts its own volume directory, then drops to the image's unprivileged node user before starting network services.

`/status` shows current RPC observations, preserved proof counts, keeper mode, configured policies and gas balance. `/api/health` and the operator's `/health` are process liveness checks. They do not certify financial readiness. Operator status is refreshed on request; chain and gas observations update every minute. No public endpoint can register keeper policies, change a signing key, execute an arbitrary call or upload a claimed proof root.

Configure these **server-side Railway variables** for the operator:

| Variable | Purpose |
| --- | --- |
| `LONGER_OPERATOR_TOKEN` | Private web-to-operator authentication, at least 32 characters. Already generated for the hosted service. |
| `PORT` | Explicitly set to `3000` in Railway. Otherwise the platform may inject `8080`, which will not match the private web-service URL. |
| `OPERATOR_DATA_DIR` | `/data`, the persistent volume mount. |
| `HOLDER_PROOF_RPC_URL` | HTTPS provider URL with actual historical `eth_getProof` support for Robinhood Chain. Keep provider credentials private. |
| `KEEPER_POLICIES_JSON` | JSON containing 1–20 verified policy addresses and explicit actions. Omit for proof-serving and monitoring only. |
| `KEEPER_PRIVATE_KEY` | Dedicated gas-wallet secret. Omit until the intended operator supplies it through Railway's private variables. |
| `KEEPER_EXECUTE` | Exactly `true` enables configured transactions. Default is simulation. Requires a key and nonempty allowlist. |
| `CANARY_INPUT_JSON` | The canary input below, containing public addresses and four transaction hashes. On startup the operator independently verifies it before displaying a completed record. |
| `MAX_GAS`, `MAX_PONS_GAS`, `MAX_GAS_PRICE_GWEI`, `MAX_TX_PER_PASS`, `INTERVAL_SECONDS` | Keeper execution limits; see `operations.md`. |

Example allowlist, with a real verified address substituted:

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

The service reuses the reviewed keeper runner. Pons holder checkpoints default to a 5,000,000 gas limit; other actions retain 1,500,000. An explicit `MAX_GAS` also caps Pons checkpoints, even when `MAX_PONS_GAS` is higher. Estimates include a 20% buffer and over-budget actions are skipped. It simulates configured actions, checks dependencies and gas limits, persists transaction intent before submission, and verifies receipts. Ambiguous submissions retain the pending record and halt further signing. Review the gas-wallet nonce and receipt before manually resolving that state. Keeper progress is exposed as event names and hashes; private provider error details are not served publicly.

The hosted service starts without a signing key, policy allowlist or execution permission. Its actual state is visible on `/status`. Funding a wallet alone does not configure execution. A keeper is permissionless: anyone else can submit the same valid checkpoint, and it has no power to change reward destinations.

For a verified Pons fee vault, the keeper also accepts `harvest`, `harvestUpTo`, `sync`, `payout`, `payoutUpTo` and `releaseVestedFees` where the contract version supports them. Configure explicit currency addresses, recipient indexes and base-unit limits. V1 harvest accounts both canonical assets together. V2 vested launch-token fees require release into Pons escrow followed by a token harvest. Add downstream holder checkpoints and claims separately; fee collection alone does not distribute holder rewards. See [operations](operations.md) for the action sequence and remaining upstream controls.

## What the proof store preserves

A successful wallet-proof request reads the policy's recorded epoch storage root. The service verifies the Merkle Patricia proof against that root using the EthereumJS trie library, then saves it. The cache key includes chain, token, storage root and wallet. A response's reported balance is derived from the proof rather than trusted from an RPC field. Cached proofs are reverified before being returned.

The store preserves **requested wallets only**. It does not enumerate all holders or turn the public RPC into an archive node. An unrequested wallet at an old epoch still needs an archive RPC or its own previously saved proof. The configured custom-RPC flag only reports configuration, not verified retention guarantees. Default public RPC state is limited to recent blocks.

Verified checkpoint bundles are also saved when prepared through the service. The keeper stores its checkpoint bundles separately under `/data/checkpoints`. Those bundles do not contain every holder's individual claim proof.

The database uses synchronous SQLite writes and WAL recovery. Existing entries are never automatically evicted. A 512 MiB serialized-payload budget bounds new entries; database indexes and filesystem overhead are additional. When the budget is exhausted, the service can still return a fresh verified proof, with `preserved:false`; the holder should download it. Monitor volume usage separately and expand storage before it fills.

A Railway volume survives redeployments but is not an independent backup. Configure volume backups and test restore to a separate service before promising long-term proof availability. Do not copy a live SQLite main file without its WAL; use an SQLite-consistent backup or stop the service for a coherent copy. Keep checkpoint files and pending keeper intent with the database backup. A proof-store outage does not change an onchain entitlement; another archive RPC or preserved proof can be used directly.

## Verify the first real holder canary

The verifier makes read-only RPC calls. It does not deploy, fund or sign. Prepare JSON with public data:

```json
{
  "policy": "YOUR_DEPLOYED_HOLDER_POLICY",
  "holder": "THE_HOLDER_WALLET",
  "deployment": "DEPLOYMENT_TRANSACTION_HASH",
  "funding": "DIRECT_FUNDING_TRANSACTION_HASH",
  "checkpoint": "CHECKPOINT_TRANSACTION_HASH",
  "claim": "CLAIM_TRANSACTION_HASH"
}
```

Run `node --experimental-strip-types scripts/verify-canary.mjs canary-input.json canary-record.json` from this checkout. The output path must not already exist. This command checks:

- Release runtime, reconstructed configuration, pinned dependencies and exact deployment constructor data.
- Successful canonical receipts on chain 4663, at least 32 L2 blocks deep, ordered deployment → funding → checkpoint → claim.
- A positive direct native or ERC20 transfer to the policy. ERC20 receipts must confirm the exact transfer.
- Checkpoint and claim calls to that policy, a matching epoch event, a cryptographically verified holder balance, and the expected positive payout event.

The resulting record includes addresses, configuration/runtime hashes, amounts, snapshot and transaction blocks. It covers that holder policy and reward asset. Fee attachment, harvesting, conversion, other reward assets, historic proof coverage and independent review remain separately verifiable steps. Thirty-two L2 blocks are not Ethereum settlement finality. The unit tests use simulated receipts with real balance-proof fixtures; they are not a completed mainnet canary.

## Long authorization and independent review

The existing-token flow does not require a new-token signing integration. Creating a new token through Long's current router requires an authorization from an enabled Long backend signer. The supplied payload validator checks the current implementation, signature, expiry, parameters and simulation. No supported public signing endpoint or integrator credentials have been obtained. A complete atomic new-token launch flow remains gated on that access and a verified supported wallet flow.

The project owner confirmed a passed independent review on 14 September 2026; see the [review record](review-status.md) for its currently unspecified reviewer and code scope. An actual funded canary, complete archive arrangements and a named operator with support/security contacts remain production requirements. These need external services, real wallets or operator-supplied details. Neither a successful build nor the canary-verification software completes those steps by itself.

## Public read RPC availability

Application chain reads use the public BlockReq endpoint with the Robinhood endpoint as a fallback. Production checks found the Robinhood endpoint could challenge requests from some hosting IPs. This uses an independent public blockchain provider; it does not bypass that endpoint’s challenge. Both providers remain external availability dependencies. Chain identity and pinned contract checks still apply. The keeper’s transaction broadcast uses its configured single transport and persisted intent; read failover does not replay a signed transaction.