# Validation record — 10 September 2026 The dated results below describe the exact versions and fixtures tested at the time. Earlier Long-only checks are not evidence for Pons compatibility, other platform versions or new fee adapters. Current platform support is documented separately in [platform support](platform-support.md); a website update is not a production canary. Current review update, 14 September 2026: the project owner confirmed that independent review passed. The earlier pending-review statements below describe their original dates. No public report, reviewer or covered code revision has been supplied; see the [review record](review-status.md). This confirmation does not change the historical test evidence or establish review coverage of every current artifact. Release 0.2. This records completed implementation checks, not an independent audit, a guarantee of correctness or a funded mainnet launch certification. ## Contracts 70 Foundry tests passed with Solidity 0.8.28 and Forge 1.7.1. The ordinary offline run skips one optional RPC fork test. The suite covers fee rights, native/ERC20 accounting, cumulative rounding, scheduled phases, capped funding, overflow, currency splits, fixed buybacks, permanent liquidity, staking and passive holder rewards. Fuzz cases use 256 runs each. 29 of these tests target passive holder rewards: real token account/storage inclusion and non-inclusion proofs, truncated-positive proof rejection, snapshot cutoff and 32-block confirmation boundaries, forged headers/proofs, fixed recipients, duplicate claims, prior liabilities, capped oversized donations, failing and gas-consuming assets, transfer rollback and reentrancy. Epoch 0's fixture is real Long token state at L2 block 59702555. Epoch 1 explicitly uses synthetic later timing over that same real storage root for offline accounting tests. Native history calls are mocked in those fixture tests. This is not a live chain distribution. The optional V4 manager fork passed at recorded L2 block 59741134. It uses the actual pinned manager code and a synthetic no-hook pool created only on the local fork, then exercises liquidity addition, swaps, supply burn and separate LP-fee delivery. The earlier pinned block 59703949 also passed during development; attempting it later failed because the public provider had aged it out. `LONGER_FORK_BLOCK` makes the selected block explicit. No real Long listing or genesis launch is implied. ## Application and deployment - 30 application tests passed: exact inputs and UTC behavior, draft integrity, fingerprints, wallet account/chain guards, runtime matching, module arguments, network response validation, historical-header serialization, bounded storage proofs, first-crossing snapshot search and four production Long CREATE2 prediction fixtures. - The earlier reward-design model remains tested as an editable, non-executable specification; it is no longer the public rewards page. It does not establish continuous-holding execution. - Local Anvil integration deployed all eight release artifacts, compared actual runtime with simulated creation, and independently reconstructed each configuration fingerprint through the same inspector used by the site. It also tested existing-pool fee-rights adoption, old entitlement removal and actual fixed-recipient payout. Chain-system/token code was installed only in this isolated test chain for holder deployment checks. - Live read-only proof preparation found the fixed cutoff at block 59740510 and retrieved the real token account proof plus five exclusion proofs. It did not broadcast a checkpoint or claim. - TypeScript and authored-code lint passed. Vendored UI scaffolding is excluded from lint. This is not a complete accessibility certification. - A Vinext Railway standalone production build completed. Dependency audit reported 0 known vulnerabilities. An advisory-free result is not a security guarantee. - GitHub Actions configuration runs application checks, contract tests, artifact consistency and local integration. No hosted CI run is claimed. ## Browser and runtime scope The app was exercised in the in-app browser on desktop and at 390×844. The primary reward entry leads to the passive module, wallet-unavailable guidance is visible, transaction simulation is disabled without a connected wallet, and the reward page fits the mobile viewport. Browser review found and corrected overlapping module-card text. The old design-only rewards page was replaced with implemented snapshot semantics and deployment/claim entry points. No real wallet signature, funded mainnet deployment, fee-rights transfer, production swap or holder payout was performed. Local unlocked-account tests do not replace a canary with the intended production wallet. Downloads also expose copyable JSON so proof and receipt data can be preserved when a browser restricts file downloads. ## Remaining external prerequisites Long's backend authorization service and a verified atomic genesis flow are still required for new-token creation. Independent review, a production canary, actual contract records, a funded monitored keeper and public operator/security contacts remain outstanding. Historical claims require an archive RPC or preserved proofs; the default public endpoint retains only 32,768 blocks of historical state. The website includes server-side archive configuration and saved-proof import. See [release readiness](launch-readiness.md). Website hosting success is separate from a safe funded protocol launch. ## Application 0.2.1 — 11 September 2026 - All 36 application tests passed. Six added tests cover existing-token compatibility and wrong-chain rejection, authenticated wallet-proof verification, persistence across SQLite restart, storage-cap behavior, and canary verification of simulated receipts with real historical proof fixtures. - All eight local Anvil deployment/inspection checks and existing-pool fee adoption/payout passed again. Contract source and artifacts are unchanged from 0.2. - Read-only existing-token lookup verified LMEOW's current token implementation, Airlock integration and locked fee pool at block 59771940. The browser performed a second real lookup at block 59778332 and carried the token into the passive reward configuration form. This is compatibility evidence, not a claim of listing approval or token ownership. - The private operator passed local startup, correct-token status access, rejection of unauthenticated requests and read-only chain monitoring with no signing key. Proof storage verification used a genuine chain fixture, an incorrect root, a different wallet and a truncated proof. - The canary verifier accepted a coherent simulated deployment/funding/checkpoint/claim sequence and rejected diverted funding, missing payout events, wrong constructor data, reverted receipts, insufficient confirmations and reordered steps. No funded mainnet canary was performed. - Lint, TypeScript, the Railway standalone build and dependency audit passed; the audit reported zero known vulnerabilities. Existing-token setup and operator status were checked in the browser; each fit a 390-pixel viewport without horizontal overflow. - The operator was deployed to Railway with a private network endpoint and a 5 GB persistent volume. No signing wallet, keeper allowlist or paid archive provider was configured. Current live status is published at `/status` after the web rollout. See [operator setup and verification](operator-guide.md) for what is preserved, how to configure execution, and the remaining external requirements. The final read-RPC update adds a provider-failure regression test (37 application tests total) and uses the already configured public BlockReq service for initial reads. Its chain response was verified inside the Railway web container. The operator’s explicit port was corrected to 3000 after confirming Railway had injected 8080; the public operator endpoint then returned healthy RPC and persistent-volume status. ## Release 0.3 — 2026-09-11 - 43 application tests passed, including current fee-recipient discovery after ownership transfers, explicit partial history, asset metadata validation, native/custom selection, one-minute proof windows and UTC configuration bounds. TypeScript and application lint passed. - 73 Solidity tests passed; the optional public-fork test remains skipped without its RPC environment variable. New real-proof tests cover deployment-time starts, one-minute epochs, skipped-epoch funding carry, reserved old claims and isolation of deployer/relayer wallets and unrelated assets. - Local Anvil deployed and inspected all eight release contracts. A delayed automatic-start deployment reproduced every reviewed setting and used the mined timestamp, while altered settings and timestamps were rejected. Saved transaction reviews resumed successfully. The 0.2 holder artifact still deployed and inspected correctly. Existing-pool fee-right adoption and fixed-recipient payout also passed. This isolated test is not a production canary. - COKE (`0x9c28B6778977a79d8a990a137E47703E00C01E18`) resolved to SNOW and two current LP-fee beneficiaries at block 59982411. The connected creator candidate held 95% of pool LP-fee entitlement; this percentage is not a claim about all trading fees. - Read-only mainnet creation simulation passed at observed block 59983123 for COKE holder balances, MONITOR (`0x1a911bb954dAA9CB38513423075bE74450351e18`) rewards, deployment-time start and a 60-second interval. Creation-code hash: `0x9fae7ee8716ace67964d837ebf9703b37444eb3c276d0cf8aba4a062e8697945`. No wallet transaction or funding was sent by these checks. - Browser checks exercised the named asset dropdown, preserved MONITOR while adding a canonical stock, resolved custom MONITOR metadata, and opened the collapsed advanced controls. Long’s 64 picker symbols were observed in its public create UI; 61 stock addresses/decimals came from Robinhood’s canonical asset registry. AI and USDG metadata were read onchain (USDG uses six decimals), and ETH is explicitly native. Website deployment does not start a funded keeper. Short intervals still require a confirmed checkpoint and claim transaction. Different payout assets require direct funding or configured conversion contracts. Independent review and a real funded end-to-end production canary remain separate. ## Pons integration — 13 September 2026 - All 60 application tests and 105 Solidity tests passed. One optional public Long fork test was skipped without its RPC configuration. Pons coverage includes version-specific discovery, exact token runtime matching, the OpenZeppelin balance/supply proof layout, authentic inclusion and non-inclusion proofs, inventory exclusions, rejected proofs, reserved rewards and duplicate-claim prevention. - Fee-vault tests cover both canonical currencies, fixed allocations, source changes, isolation of unrelated assets and caller wallets, partial harvest and payout limits, vested-fee release and allocation conservation with 256 fuzz runs. The original Long contract artifacts are unchanged. - Live read-only checks recognized an active-v1 token, a current-v2 token and a previous-v2 token. Their raw balance/supply slots matched ERC20 getters. Both new contracts passed creation simulations and release-runtime matching for each token. The record at `output/validation/pons-2026-09-13/live-simulations.json` contains the observed blocks and artifact hashes. These checks sent no public transactions. - On a disposable Robinhood Chain fork, both Pons contracts deployed and passed full configuration/dependency inspection for all three supported factories. A native-asset partial payout delivered the exact amount and preserved the remaining recipient credit. The test resets its disposable recipient to a plain account because the well-known development address has delegation code on the public chain. All test transactions and account changes were confined to localhost. - The existing Long local integration passed all eight original modules, the prior holder release, deployment-time scheduling and saved-review recovery, fee-right adoption and fixed-recipient payout. - TypeScript, lint and the Railway production build passed. Desktop and 390-pixel browser checks exercised Pons discovery, paired-asset selection, holder setup and the Pons fee form without horizontal overflow. The four modules reserved for future releases remain locked for new setup. Reproduce with `npm run test:unit`, `npm run test:contracts`, `npm run test:integration`, `node --experimental-strip-types scripts/check-pons-integration.mjs`, and `PONS_TEST_RPC=https://rpc.mainnet.chain.robinhood.com node --experimental-strip-types scripts/pons-integration-test.mjs`. Public RPC availability can affect the last two checks. This release has no completed funded Pons production canary. The local fork does not establish a live fee-attachment, harvest, holder checkpoint and claim sequence with the intended wallet. Keeper funding, archive access and independent review remain separate. Existing Pons-token support does not enable new-token launches or Pons buyback execution through Longer.