# Longer immutable modules

Release 0.3.0. These contracts are implemented. The project owner has confirmed a passed independent review; the reviewer and covered code revision have not been specified. See the [review record](review-status.md). No operator-funded mainnet deployment is claimed. The website lets a user simulate and deploy their own contract, then inspect and operate it. New-token genesis through Long additionally requires its signed authorization service and a verified atomic launch flow.

Website availability: holder rewards and fee splitting support verified Long and Pons paths; buybacks are open only for supported Long pools. Project budgets, currency routing, permanent liquidity and staking rewards are reserved for later releases, with new setup flows locked. The references below remain available, and existing policies can still be inspected and operated.

## Composition

Supported existing Long and Pons tokens are checked by version and token implementation. Holder compatibility and fee-source compatibility are separate; see [platform support](platform-support.md).

For Long's supported fee path, a LongerFeeVault is the creator LP-fee beneficiary. Its fixed recipients can be wallets or other deployed Longer modules. Deploy downstream modules first, verify them, then use their actual addresses in the parent vault. Deploy and verify the parent before transferring fee rights. An exported plan is editable; a deployed Longer vault's settings are not. Pons source recipients retain version-specific controls, so routing into a fixed vault does not make future Pons fee income permanent.

Long has run cross-asset holder campaigns, but its inspected public create flow did not expose a self-serve creator passive-distribution policy. Longer adds creator-deployed wallet snapshots with permanent rules. Related Long market features do not establish identical configuration or trust boundaries.

## Passive wallet rewards

LongerHolderRewards serves supported Long tokens; LongerPonsHolderRewards serves the reviewed Pons versions listed in [platform support](platform-support.md). The Pons variant verifies the OpenZeppelin balance mapping at slot 0 and total supply at slot 2; the Long variant keeps its original Solady layout. A token must match the implementation and proof layout supported by the selected release. Runtime checks remain pinned; platform recognition alone does not admit arbitrary token implementations. Reward assets (1–4, native ETH or compatible ERC20), first UTC cutoff, interval (1 minute–7 days) and exclusions cannot be changed. There is no staking, root publisher, admin, proxy or generic executor.

The default constructor start is `first = 0`, resolved to the actual deployment block timestamp. `requestedFirstSnapshotAt` preserves the constructor input for receipt verification; `firstSnapshotAt` and `configHash` contain the resolved permanent time. An explicit start must be in the future. The default UI interval is 60 seconds. The 0.2 artifact remains available for existing deployments, whose original one-hour minimum and fixed schedules are unchanged.

The reward contract, not the deployer or keeper wallet, holds and pays the rewards. It has no `transferFrom`, approval, wallet-pull, rescue or arbitrary-call entry point. Only configured assets already in its own balance can enter a budget. Relayers spend their own gas; their token balances cannot fund a payout. Unrelated assets deposited into this contract remain inaccessible.

Anyone checkpoints the latest due epoch using the first canonical L2 block whose timestamp reaches the cutoff and the immediately preceding block. Both numbered headers must match Robinhood's history contract at 0x0000F90827F1C53a10cb7A02335B175320002935, with runtime hash 0xceef1f6ad6c0cb7eb8fb15678abf11da3ce0d3a7c7106aa900c5930e556a43ff. The snapshot must be at least 32 L2 blocks old. In-EVM block.number is not used for L2 height; ArbSys supplies it. This delay is not L1 finality.

The proof verifier authenticates the token account, total supply and every excluded balance against the snapshot state root. For Long, automatic exclusions are zero, dead, PoolManager, the reward module and token-held vesting inventory. For Pons, they include zero, dead, the reward module, token and factory, plus the canonical v1 pool/locker or v2 curve, PoolManager, locker, hook, escrow and buyback vault. Up to 12 extra addresses can be permanently excluded. Later third-party pools and custody addresses are not automatically added. Other contract wallets remain eligible and must be capable of receiving/accessing rewards. Custodial exchange users cannot prove individual balances held by the exchange.

The remaining supply is the denominator. A zero denominator reverts without allocating funds. For each asset, the checkpoint attempts to budget actual balance minus outstanding claim liabilities, capped at uint128.max. Excess carries forward. Each attempt has 180,000 gas; a transaction must reserve sufficient gas for all attempts. A failing asset is skipped with BudgetUnavailable and may fund a later epoch; healthy assets continue. No late refill changes a recorded budget.

A claim proves a wallet's snapshot balance. Amount = floor(budget × balance / eligible supply). Each epoch/wallet/asset can claim once. A relayer may pay gas, but the destination is always the proven wallet. ERC20 payouts require exact sender and recipient balance changes; failure rolls back the claim. Rounding dust and abandoned claims remain reserved forever. No rescue or expiry exists.

This rewards a fixed snapshot, not holding age, time-weighted balances or continuous eligibility. Tokens may be positioned around known cutoff times. Transfers afterward do not change prior entitlements. Funding follows accounting time: harvests and donations can influence which checkpoint receives income. Reward assets must actually be funded; selecting them does not purchase them.

Only the latest due epoch can be processed. The history window is 393,168 L2 hashes, not a guaranteed wall-clock duration. A keeper must capture both headers in time. Missed epochs have no separate budget; unaccounted funds carry forward. Claim proofs require an archive RPC or previously saved proof even though the contract never expires claims. The browser exports complete reviewed call data; the keeper saves checkpoint proof bundles.

The app uses a bounded fixed archive endpoint to retrieve public proofs. RPC labels are not trusted: actual contract simulation and execution verify the proof. Unsupported header encodings fail the canonical hash round-trip; there is no fallback to an operator-published balance list. Proof libraries retain the pinned Aave nonempty-branch truncation fix and their original MIT/Apache license notices. Their review is not an audit of this integration.

## Fixed splits and scheduled allocations

LongerFeeVault locks one pool, two currencies, 1–8 unique recipients, both percentage tables and an optional transition timestamp. No owner, proxy, update or fee-rights rotation method exists. Schedule selection occurs when income is accounted, not when a trade happened. Earlier credited amounts retain their recipients. Cumulative per-phase allocation prevents deposit fragmentation changing a recipient's share; fewer than N base units per currency/phase may remain as dust.

LongerPonsFeeVault applies the same cumulative split model to a verified Pons token’s supported fee currencies. Constructor: `(token, recipients, phase0, phase1, transition)`. `harvest(currency)` collects and accounts both canonical currencies for v1, or independently claims and accounts the selected escrow currency for v2; `sync(currency)` accounts received funds; `payout(currency, index)` pays only that fixed recipient’s credit. Each call is permissionless and non-reentrant. Payout failure rolls back that credit and does not change another recipient’s allocation. Only standard non-rebasing, non-tax currencies are supported; ERC20 payouts check exact vault and recipient balance changes. Unrelated assets have no recovery path.

The Pons vault pins token, factory and fee-source runtime hashes. It does not freeze Pons’ upstream recipient controls: v1 harvest requires the vault to be the current redirect, while v2 escrow claims retrieve only balances credited to the vault. Previously received funds remain subject to the fixed Longer policy if future fee routing changes. See [platform support](platform-support.md) for the current source versions and owner powers.

## Capped funding and calendar budgets

LongerBudgetVault supports 1–4 independently capped currencies. The browser prepares one currency per vault. A cap is consumed when funds are credited, regardless of payout success. Excess is owed to a fixed overflow recipient and remains independently payable.

An empty start and zero duration release immediately. A future start with zero duration is a cliff. A nonzero duration releases a fixed calendar budget linearly: min(total funded, cap × elapsed / duration) less prior releases. Late funding can immediately catch up to the calendar ceiling. Caps are in asset base units, never an implicit dollar target. Neither the beneficiary nor the overflow destination can change. Their own wallet or treasury spending powers remain separate.

## Different routes for different currencies

LongerCurrencyRouter accepts the two fixed pool currencies and a separate complete allocation for each. Example: quote-asset revenue funds a budget, while launch-token revenue goes to a supply-burning module. There is no exchange or automatic valuation. Cumulative accounting preserves proportions despite fragmented receipts.

## Buyback, burn and conversion

The website’s LongerBuyback setup is limited to supported Long pools; it does not support Pons pools. LongerBuyback uses the actual V4 PoolManager interface with one fixed PoolKey. A successful execution must consume at least minSpend and no more than maxSpend, meet a minimum acquired-output ratio using actual balance movements, and respect a cooldown. The chosen batch is min(available balance, maxSpend); callers cannot substitute their own recipients, route or price limit.

The output floor is a permanent absolute price limit, not an oracle or a promise of best execution. It can become stale and make execution stop indefinitely. Sandwiching within the accepted bound is possible. The displayed ratio uses human token units; the committed ratio uses output base units per 1e18 input base units. Verify both tokens' decimals before committing.

Burn mode calls burn(uint256) and verifies both totalSupply and the module's balance decrease by the exact amount. An incompatible token makes that execution revert. Conversion mode sends acquired assets to one fixed downstream module or recipient. Directly received output tokens can be delivered separately. Output must be an ERC20. Independent conversion routes are required for each selected reward asset; there is no arbitrary multihop router or mutable basket.

The PoolManager and nonzero hook runtime hashes are pinned. A runtime hash does not detect proxy implementation changes or mutable upstream policy. Verify those separately.

## Permanent liquidity

LongerLiquidityVault owns a direct V4 position, with no transferable position token. Its pool, tick range, position salt, liquidity increment, per-currency principal caps, cooldown and LP-fee recipient are fixed. Public execution can only add the exact positive increment. There is no negative-liquidity, transfer, approval, rescue or generic-call path.

Fees are collected into separate per-currency credits. Failed fee recipients cannot block other fee payouts or additions. Existing credits cannot fund principal. Principal cost is measured separately from accrued fees, so netting cannot conceal overspending. Unspent deposits remain available only for future fixed additions; they cannot be recovered. An out-of-range or uneconomic fixed policy may stop adding liquidity. Permanent custody does not protect token value or ensure a position remains in range.

## Staking rewards

LongerStakingRewards uses opt-in staking, not passive wallet snapshots. It accepts one stake token and 1–4 fixed ERC20 reward assets, a fixed maturation period and a fixed recipient for rewards accounted while nobody is eligible. The stake token cannot itself be a reward asset.

1. Approve only the exact intended amount and deposit.
2. Deposits remain pending through the maturation period. Adding another pending deposit restarts the pending batch's clock; already active stake stays active.
3. Anyone can activate a matured account. Eligibility begins at activation, after previously received rewards are accounted.
4. Rewards received while active stake exists accrue proportionally to that active stake. Distribution occurs at accounting time, with no offchain holder list or root publisher.
5. Claims always pay the staking account. Each reward asset can be claimed independently.
6. Standard withdrawal accounts rewards first. Principal-only withdrawal avoids all reward-token calls and remains available if a reward issuer fails; it forgoes newly unaccounted rewards on that exit. Previously credited rewards remain claimable. Stake-token failure itself can still prevent withdrawal.

Cumulative funding per reward asset and total deposits are limited to uint128. The accumulator scale is 2^128. Global and per-account fractional remainders are retained; changing eligibility can move less than one reward base unit of global rounding remainder into subsequent accounting. Fractional claims are not guaranteed to become a whole transferable unit. No admin may withdraw stakes or replace reward assets.

Fund the reward assets directly, or compose fixed conversion modules upstream. The staking contract does not claim that every stock or coin has an executable conversion path. Issuer freezes, rebase behavior, transfer taxes and unsupported token implementations remain material compatibility limits.

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