# Supported existing tokens

Longer adds separate reward policies to verified existing Long and Pons tokens on Robinhood Chain (4663). The token, holder balances and trading pool stay in place. The Longer name and policy rules are unchanged.

Start at `/existing`. Recognition of a platform is not enough by itself: the lookup checks the supported version and token dependencies, then reports holder-reward and fee-routing capabilities separately. A familiar name, symbol, website listing or deployer address does not establish compatibility. Unknown versions remain unsupported until their code and behavior have been verified.

## Capability matrix

| Capability | Verified Long token | Verified Pons token |
| --- | --- | --- |
| Passive holder rewards | `LongerHolderRewards` | `LongerPonsHolderRewards` |
| Fixed fee splitting | `LongerFeeVault`, for a supported fee-distribution pool | `LongerPonsFeeVault`, when the checked fee source is supported |
| Buyback and burn | Supported Long V4 pool only | Not available in this release |
| Project budgets, currency routing, permanent liquidity, staking rewards | New setups locked | New setups locked |
| New-token launch | Locked | Not available |

These are conditional capabilities, not approval of every token issued by a platform. The compatibility lookup and deployment simulation must pass for the exact token and dependencies.

## Reviewed Pons versions

| Version | Factory on chain 4663 | Boundary |
| --- | --- | --- |
| Active v1 | `0xA5aAb3F0c6EeadF30Ef1D3Eb997108E976351feB` | Exact reviewed token runtime, canonical launch record, pool and locker checks required |
| Current v2 | `0x7eD598BcEf8bd9Edd8C97A195C6d13f40801EC7e` | Exact reviewed token runtime and canonical launch dependencies required |
| Previous v2 | `0x7E1EAbd52Ae29598e6483F72dCf1a70b14284dB8` | Same explicit runtime and dependency requirements; version inferred from verified code, not a token label |

The legacy v1 factory `0x0c37…77a4` is unsupported. Unknown factories and token variants are rejected. Recognition of one version does not admit future versions automatically.

## Holder rewards

A compatible holder policy fixes its token, reward assets, snapshot schedule and exclusions. Anyone may deploy and directly fund it; no creator-fee rights are needed for direct funding. Holders keep their tokens in their wallets and claim against authenticated historical balances.

LongerHolderRewards retains Long’s existing Solady proof layout. LongerPonsHolderRewards uses the reviewed Pons OpenZeppelin layout: balances at mapping slot 0 and total supply at slot 2. Both use authenticated UTC snapshots, with the same five constructor arguments: holder token, reward assets, extra exclusions, first cutoff and interval. Snapshot proofs depend on the exact supported token implementation and storage layout. Platform recognition must not bypass the contract's runtime checks or interpret an unverified token with the wrong proof layout. Existing deployments continue to use the code and settings with which they were created.

Automatic Pons exclusions include burn addresses, the policy itself, the holder token and factory, plus the canonical v1 pool and locker or v2 curve, PoolManager, locker, hook, escrow and buyback vault. Later third-party pools and custody addresses are not automatically excluded; up to twelve extra exclusions must be supplied at deployment.

Choosing a reward asset does not acquire it or turn another fee asset into it. Fund the exact configured assets, or use a separately verified funding route. Reward assets and token platforms are separate concepts: an asset observed in Long's catalogue can be a reward asset without making the holder token a Long token.

## Fee funding differs by platform

### Long

For a supported Long pool, the current creator LP-fee beneficiary may separately transfer its full current entitlement to a deployed LongerFeeVault. The vault fixes its recipients and has no method to transfer that entitlement elsewhere. Current onchain shares, rather than original beneficiary arrays, establish who can attach the rights.

This does not include every trading fee. Long's separate hook allocations, other beneficiaries and upstream governance remain outside the Longer policy.

### Pons

LongerPonsFeeVault fixes a verified token, its two supported fee currencies, one to eight recipients, two allocation tables and an optional transition. Its constructor is `(token, recipients, phase0, phase1, transition)`. It has no owner, approval, wallet-pull or recipient-rotation function. Deployment alone does not connect platform fees.

For active v1, the original deployer calls the verified locker’s `setFeeRedirect(token, vault)`. That deployer keeps the ability to redirect future fees afterward. A current fee recipient can collect but does not inherit the deployer’s redirect power. The vault’s v1 harvest requires the current redirect to name the vault.

For the reviewed v2 factories, the current creator-fee recipient calls `transferCreatorFeeRecipient(token, vault)` on the factory. The owner can propose an override with a three-day delay and a three-day execution window. A voluntary recipient transfer does not cancel a pending owner override. Directing fees into Longer does not remove those upstream powers or guarantee that future fees will keep arriving. See the [version-pinned Pons v2 factory source](https://github.com/ponsdotdev/ponsfamily/blob/06adcd8241ed5cf3ac76f31cf369bba9b55a5471/contractsV2/src/v2/PonsV2LaunchFactory.sol#L879) and [verified active-v1 locker source](https://sourcify.dev/server/v2/contract/4663/0x736D76699C26D0d966744cAe304C000d471f7F35?fields=all).

Permissionless `harvest(currency)` collects and accounts both canonical currencies on v1, while v2 claims and accounts the selected escrow currency. `sync(currency)` accounts supported funds already in the vault; `payout(currency, index)` pays one fixed recipient. If the upstream recipient changes or harvest dependencies fail, funds already received can still be accounted and paid under the fixed rules. Phase selection follows accounting time.

V2 also supports `harvestUpTo(currency, maximum)` and both versions support `payoutUpTo(currency, index, maximum)`. These cap a transfer without changing its destination; unclaimed escrow funds and unpaid recipient credits stay in place. The app offers an optional maximum in units of the selected asset. Native ETH, standard non-rebasing ERC20s and exact transfers are supported; issuer freezes, transfer taxes or restrictions can still prevent a transfer.

When Pons buyback vesting is enabled, `releaseVestedFees()` lets anyone have this vault call the pinned Pons buyback vault as its beneficiary. Pons releases only the vested amount into its escrow; a separate token harvest then claims the creator allocation. Factory recipient changes also update the buyback beneficiary. This releases an existing Pons vest; it does not execute a new buyback. Pons internal-swap fee sweeps still require Pons' operator, so Longer cannot force all trading fees to reach escrow. These rules are present in the [current verified buyback source](https://sourcify.dev/server/v2/contract/4663/0x42df2a798f82289E177311362e8f5ccC45c1219c?fields=sources,abi) and the [previous verified buyback source](https://sourcify.dev/server/v2/contract/4663/0x2d6e3aA895EDa2603189c2A89679bD4279175FdB?fields=sources).

Use only the funding actions enabled for the verified version in the app. A successful holder-token check is not permission to apply Long's beneficiary-transfer procedure to a Pons pool. Recipient changes and Longer deployment are separate wallet actions; review the source, recipient and remaining control before signing.

Once supported assets have reached a Longer holder policy, its fixed accounting and claim rules govern those assets. Future platform income remains subject to the upstream version and its controls. The policy does not promise a funding rate or investment return.

## Current release boundaries

Holder rewards and fee splitting support the verified Long and Pons paths above. Longer’s buyback execution remains limited to supported Long pools. A Pons fee vault can release existing vested fees as described above. Project budgets, currency routing, permanent liquidity and staking rewards remain locked for new setup. Existing policies can still be inspected and operated.

New-token launches remain locked. Long's launch authorization checker is specifically for Long; it does not obtain authorization or launch a token. Support for existing Pons tokens does not enable new Pons token creation through Longer.

The project owner has confirmed a passed independent review; [its recorded scope](review-status.md) does not yet establish coverage of Pons or a specific release revision. Platform-specific end-to-end production evidence, reward funding, keeper gas and historical-proof availability remain separate requirements. See [release readiness](launch-readiness.md), [operations](operations.md) and the dated [validation record](validation.md).