Understand every rule.

Reward holders. Commit the rules.

Longer is an independent policy layer for verified existing Long and Pons tokens on Robinhood Chain, network 4663. Its primary module distributes funded reward assets to ordinary token holders using verifiable snapshots. Holders keep tokens in their wallets. Creators commit the reward assets, schedule and exclusions at deployment.

Holder rewards and fee splitting support verified Long and Pons sources. Buybacks are available only for supported Long pools. Project budgets, currency routing, permanent liquidity and staking rewards are reserved for later releases. Funding and policy deployment are separate; verify every destination before directing assets to it.

Passive holder rewards

Already have a token? Check an existing Long or Pons token and add a separate permanent policy when its implementation is supported. Anyone can fund holder rewards. Platform fee funding has separate permissions and controls; no token migration is needed.

LongerHolderRewards for Long and LongerPonsHolderRewards for reviewed Pons tokens each fix one holder token, one to four reward assets, a first UTC snapshot and an interval between one minute and seven days. Eligibility uses the first canonical L2 block at or after each cutoff. This is a point-in-time balance, not proof of continuous holding or a minimum holding period. Known snapshot times can be traded around.

By default the schedule begins at the deployment block’s timestamp, with a snapshot every minute. Advanced setup lets you schedule a later UTC start and add excluded wallets. A one-minute interval still needs a confirmed checkpoint and a claim transaction; it does not make payouts run automatically.

A separate reward contract holds and distributes the deposited assets. The deployer wallet is not the distributor and grants no token allowance for passive rewards. A keeper wallet can pay transaction gas, but cannot redirect payouts. Only the configured assets already held by the contract enter its budgets; prior claim reserves are never spent twice.

The picker uses the verified paired asset when available, alongside a curated reward-asset list and custom contract addresses. The original catalogue was observed on Long; it does not determine which platform the holder token belongs to. Selecting another asset does not convert fees: fund that exact asset or compose a fixed conversion route. Send only configured assets to the reward contract. Unrelated tokens sent there cannot be distributed or rescued.

1. Authenticate the snapshot. Anyone supplies the snapshot and preceding block headers. Both hashes must match Robinhood’s pinned history contract; their timestamps must straddle the exact cutoff. At least 32 L2 blocks must have followed the snapshot.
2. Verify eligible supply. The contract checks the token account and storage proofs. It subtracts every fixed excluded balance from total supply at that same snapshot.
3. Account rewards. Each fixed asset receives its actual unallocated balance as the epoch budget, capped at 2¹²⁸−1 base units. Excess carries forward. Existing claim liabilities stay reserved.
4. Claim the share. Entitlement is floor(epoch budget × proved wallet balance ÷ eligible supply). Anyone can relay a claim, but payment always goes to that wallet. Each asset can be claimed once per wallet and epoch.

Long automatically excludes the burn addresses, V4 PoolManager, reward module and token-held inventory. Pons also excludes its canonical version-specific factory, pool or curve, and fee-system inventories. The full list is fixed at deployment and shown in policy inspection. Creators may add up to twelve extra exclusions. Later third-party pools and custody addresses are not automatically added. Other contract wallets remain eligible and must be able to receive and access rewards; exchange customers cannot prove individual balances held by a custodian.

There is no trusted holder-list publisher, allocation administrator, upgrade key, claim expiry or sweep. Rounding dust and abandoned entitlements remain reserved. Transfers after the snapshot do not change its entitlements. If eligible supply is zero, checkpointing reverts and funds remain unallocated.

Only the latest due epoch can be checkpointed. The history contract retains 393,168 L2 hashes; a keeper must capture the snapshot while both headers remain available. A missed epoch gets no separate budget: unaccounted funds go to the next successfully checkpointed snapshot. Fee harvesting and donations can influence which epoch receives funding because allocation follows accounting time.

A failing reward asset gets no new budget for that checkpoint; healthy assets continue. Exact ERC20 sender and recipient balance changes are checked at payout. A fixed gas allowance bounds each asset’s accounting call. Rebasing, taxed, freezing or otherwise incompatible tokens can still make that asset unusable. Asset compatibility must be checked before committing.

The hosted operator preserves successfully requested wallet proofs on a persistent volume and verifies them against the recorded snapshot root. This covers requested wallets, not every holder. See current operator status. The default public RPC only retains the latest 32,768 blocks of historical state. Production operators must configure an archive RPC for older claims or preserve and distribute proofs. Saved proof JSON can be pasted into the policy page. Claims never expire in the contract, but historical balance proofs require an archive RPC or a preserved proof. The policy page fetches and simulates proofs and exposes the full call as downloadable JSON. Preserve it. Thirty-two L2 blocks are a confirmation delay, not Ethereum settlement finality.

Verified Long and Pons tokens must match a supported implementation and proof layout. Long retains its Solady layout; the reviewed Pons variant uses OpenZeppelin balances at slot 0 and supply at slot 2. Platform discovery is version-specific. Unknown or incompatible implementations remain unavailable instead of being interpreted with the wrong storage layout. Upstream chain consensus and token-issuer powers remain dependencies.

Long, Pons and Longer

Long and Pons provide token platforms. Longer adds a separate policy for verified existing tokens, with reward assets, snapshot rules and holder entitlements enforced by its own deployed contract. Support is checked per version and token implementation; it is not a promise that every coin from either platform is compatible.

Pons support covers exact reviewed tokens from the active v1 factory and the current and previous v2 factories. Legacy v1 and unknown variants are unsupported. Holder rewards and fee routing are checked separately. Buybacks remain Long-only; the four modules marked for later remain locked on both platforms.

Pons fee vaults can claim in smaller amounts and deliver partial payouts to the same fixed recipients. An optional maximum helps with issuer transfer limits. For enabled Pons buyback vests, release the vested fees into escrow first, then claim the credited token. This does not execute new buybacks or replace Pons’ fee-sweep operator.

Choose compatible coins, native ETH or tokenized-stock tokens as reward assets. Selecting an asset does not buy it or establish a liquid conversion route. These are token distributions, not a promise of stock dividends. Longer is independent and does not claim endorsement by Long or Pons.

Deploy an existing-token policy

1. Choose the policy. Use the holder-reward form for passive rewards or select another module. Set every address, asset, unit and UTC timestamp.
2. Verify dependencies. The token lookup reports its verified platform and supported capabilities. Long pool-based modules resolve the supplied PoolId from the supported initializer and reproduce its PoolKey hash. Pons funding uses its own version-specific checks. Amount-based forms check entered decimals against the token.
3. Simulate. Connect a compatible wallet on chain 4663. The app simulates exact creation calldata and checks the returned runtime against the published release artifact.
4. Review and deploy. Review constructor arguments and gas; acknowledge permanent settings and audit status. Your wallet sends a separate contract deployment with zero ETH value. Network gas is additional.
5. Verify the receipt. After three L2 confirmations, the app checks transaction input, sender, value, canonical receipt block and full deployed runtime. Save the record.
6. Attach and fund. Directly fund supported reward assets, or configure the verified platform’s funding route. For Long, the current fee owner may separately attach their LP entitlement to a deployed fee vault. For Pons, deploy LongerPonsFeeVault and use the original v1 deployer or current v2 fee-recipient wallet to connect fees. The verified version’s upstream controls remain. Simulate each action first.
7. Operate. Configure a keeper, test with bounded funding, verify actual payouts and preserve proofs and receipts before announcing production use.

New-token launches are locked while Long integration access and launch testing are pending. Existing-token policy setup remains available. A JSON fingerprint is a consistency check on editable data. Immutability begins with deployed code, and fee funding starts only after the separate platform action succeeds. Pons future recipients may still change under the verified version’s rules. Existing-token attachment is not a claim that the route was locked at token genesis.

Wallet connection alone requests account and chain information. Deployment, approvals, staking, attachment and other actions each require their own explicit wallet transaction. No private key is requested by this site.

Trust the precise promise

On Long, the current owner of a creator LP-fee share can transfer that share again. It is not a one-time setting. Each transfer moves the caller’s full share to the new owner; the original deployer does not keep control after transferring it. Assigning those rights to a Longer fee vault commits them to that vault’s fixed rules.

Longer’s policy contracts have no owner, proxy upgrade, settings editor or arbitrary external-call executor. A creator cannot change recipients, percentages, reward assets, exclusions, schedules or execution bounds after deployment. The fee vault has no method to transfer its assigned fee rights elsewhere.

Pons funding must be read separately from Long’s entitlement transfer. A v1 deployer can redirect the recipient. The reviewed v2 factories retain an owner override with a three-day delay and three-day execution window; a voluntary transfer does not cancel a pending override. Sending fees to a Longer contract does not remove those powers. Assets already deposited follow the Longer policy, while future platform income can still change.

That does not freeze upstream contracts, token issuers, chain governance or the spending permissions of a receiving treasury. Runtime hashes identify code; a proxy’s unchanged runtime alone does not identify its current implementation. Pool and token dependencies remain explicit. Immutability cannot guarantee income, token price, liquidity or successful execution.

Wrong addresses and unusable settings cannot be repaired through an administrator. Unaccepted currencies may become permanently stranded. Only fund the exact supported assets after inspecting and testing the actual deployed configuration.

Fees, budgets and execution

Longer adds no protocol fee. Wallet transactions consume network gas. A Long fee vault receives only the LP-fee entitlement actually assigned to it; Long’s separate hook fees and other beneficiaries remain outside its allocation. Pons fee amounts and recipient controls depend on the verified version. Read current state instead of assuming a universal percentage or permanent future income.

All rounding and failure rules are part of the contract, not discretionary decisions by a keeper. See the detailed module reference before deploying a composition.

Independent review record

Review passed — project confirmation. The project owner confirmed on 14 September 2026 that the independent review passed. No public report is available. The reviewer and covered code revision have not been specified, so coverage of the current release, including Pons, is not verified.

This records the project’s confirmation. It does not label every contract version as audited or replace a production payout test. Review scope must be tied to exact code before extending its result to later changes.

Release status and launch gates

Holder rewards, fee splitting and buybacks are available for their verified platform capabilities. Project budgets, currency routing, permanent liquidity and staking rewards are reserved for later releases. Their new setup flows are locked; existing policies can still be inspected and operated.

Reproducible deployment artifacts, wallet deployment and operation flows, public policy inspection, passive proof retrieval, documentation and an operator runner are included. Automated validation covers local contracts, real historical proofs and a fork of the actual V4 manager; these checks are not an independent audit.

The project has confirmed a passed independent review; its scope is recorded above as unspecified. Before a funded public protocol launch, the operator still needs a bounded production canary with verified fee receipts and payouts, historical proof access, a funded keeper with persistent state and monitoring, and a public operating identity and security contact. Hosting this website does not supply a production signer or fund a contract.

Long’s current router requires a backend-signed authorization tied to launcher, exact parameters, predicted token and expiry. Longer cannot generate that permission. The read-only authorization checker decodes a supplied payload, checks current dependencies and signer state, reproduces the predicted token and simulates it. It neither obtains authorization nor broadcasts a new launch. A fully verified atomic creation-and-fee-attachment flow remains gated on this integration.

Operate without privileged keys

Anyone may harvest, checkpoint, release budgets, execute allowed swaps or liquidity additions, and pay recorded recipients. The keeper has no power to edit rules. Every browser action is simulated, reviewed and checked against the confirmed transaction.

The supplied keeper defaults to a simulation-only pass. Sending requires an explicit execution flag and an operator-owned gas key kept outside the website. It checks contract fingerprints, gas bounds and pending transactions, saves intent before sending, and stops on ambiguous submissions. Run one writer per key and persist its state. Holder checkpoints save their proof bundle; individual claims also need historical wallet proofs.

If this interface is unavailable, published ABIs allow direct contract calls. If a payout fails, retry that asset or recipient where the contract supports isolated payouts. The UI cannot pause deployed contracts or recover permanently committed funds. Preserve hashes, blocks and proof files when investigating an incident.

The web health endpoint checks the running application, not chain progress. Monitor keeper failures, missed snapshots, dependency changes, balances and successful payouts separately. Three L2 confirmations do not guarantee L1 finality.

Data, support and disclosures

Your drafts, pending deployment recovery and receipts are stored in your browser. The app has no user account database, advertising analytics or private-key store. Wallet providers receive connection and transaction requests you initiate. Public RPC providers receive queried addresses, pools and chain reads. The holder proof service uses a fixed archive RPC; Railway and RPC providers may retain ordinary connection and request logs under their policies.

Policy addresses, balances and submitted transactions are public chain data. Downloaded proofs and receipts stay with you. Clearing browser storage removes local recovery records but does not change a deployed policy. Never send seed phrases or private keys through this interface.

A public operator identity and security contact have not yet been supplied. They are required before a funded public protocol launch. No response-time commitment, bug bounty or administrative recovery service is claimed.

Source and verification library

Contract source, compiler settings, deployment bytecode, runtime bytecode and ABIs are available for independent reproduction. Each artifact records its creation-code hash and compiler immutable references. The inspector also reconstructs the configuration hash from onchain getters; matching source is not a security certification.

Historical state verification uses pinned Aave governance proof libraries, including the reviewed nonempty-branch truncation guard. Their prior review does not constitute an audit of Longer’s integration.