# Integration and immutable policy behavior

Longer supplies contracts, wallet deployment and policy inspection for Robinhood Chain, chain ID **4663**. Passive holder rewards are the main product. Verified existing Long and Pons tokens can use the capabilities shown by their compatibility check. Holder rewards and fee funding are verified separately; Pons support is version-specific. See [platform support](platform-support.md). New-token creation remains gated on Long’s current authorization service and a completed end-to-end launch integration.

## Existing-token setup

Check the token at `/existing` before choosing a policy. A supported holder token can receive directly funded rewards without attaching platform fees. Pons fee sources retain version-specific control over future recipients; they are not covered by Long's irrevocable entitlement-transfer procedure.

### Long creator LP-fee attachment

A supported Long funding path is:

`Long pool → creator’s LP fee entitlement → LongerFeeVault → LongerHolderRewards → eligible wallets`

The fee vault receives only the entitlement assigned to it, not all market revenue. Long and Doppler fees upstream still apply.

1. Inspect the existing token, exact pool currencies, PoolKey, PoolId, initializer and current wallet’s LP shares. Check actual dependencies and token compatibility.
2. Deploy the downstream holder policy or other destination modules first. Record their addresses and permanent configuration. A holder policy requires an already-deployed token matching a supported implementation and proof layout.
3. Deploy LongerFeeVault with the exact source and pool, sorted currencies, recipients, percentages and optional allocation transition. Use the already-verified module addresses as recipients.
4. Inspect the deployed vault in [Policies](/policies). Compare its runtime and reconstructed constructor configuration with the release artifacts. Save the receipt and `configHash`.
5. The existing beneficiary can explicitly transfer its current LP entitlement using the policy page. This calls `updateBeneficiary(poolId,vault)` and is **irreversible for this vault**. The UI checks the old beneficiary’s shares and verifies the post-transaction transfer.
6. Verify collection and funding with a controlled amount before promoting the policy. Deploying a contract alone neither attaches fee rights nor funds rewards.

The source exposes `collectFees(bytes32)` and `updateBeneficiary(bytes32,address)`. LongerFeeVault collects as the beneficiary and has no beneficiary-transfer function. Check current `getShares` values: stored genesis beneficiary arrays can remain unchanged after a transfer. [Pinned FeesManager source](https://github.com/whetstoneresearch/doppler/blob/bda077cf/src/base/FeesManager.sol), [initializer source](https://github.com/whetstoneresearch/doppler/blob/bda077cf/src/initializers/DopplerHookInitializer.sol).

### Pons creator-fee routing

A supported Pons path is:

`Verified Pons fee source → LongerPonsFeeVault → LongerPonsHolderRewards → eligible wallets`

Deploy and verify the holder policy first. Configure `LongerPonsFeeVault(token, recipients, phase0, phase1, transition)` with that policy as a recipient, then inspect the deployed vault before using the separate “Connect my Pons creator fees” action. Active v1 requires the original deployer to call `setFeeRedirect(token, vault)` on the verified locker. Reviewed v2 requires the current recipient to call `transferCreatorFeeRecipient(token, vault)` on the factory. The app rechecks authorization, simulates that exact call and verifies the vault as recipient after confirmation.

Those upstream permissions remain mutable. The v1 deployer can redirect again; the v2 owner retains a three-day-delayed override with a three-day execution window, and voluntary transfers do not cancel a pending override. The vault itself cannot move the fee recipient onward. Direct reward funding is independent of these actions. Check the [version and capability matrix](platform-support.md); Pons buybacks are not available in this release.

## Passive holder rewards

LongerHolderRewards for Long and LongerPonsHolderRewards for reviewed Pons tokens each fix the holder token, one to four sorted reward currencies, a first snapshot anchored to deployment (or a scheduled future UTC time), an interval of one minute to seven days, and exclusions. Native ETH uses address zero. Compatible ERC20 rewards may include coin or tokenized-stock tokens. Assets are funded and distributed separately; the holder contract does not swap currencies or implement a percentage basket purchase.

The supported holder token must match the runtime and implementation accepted by its released holder contract. Platform discovery verifies supported Long and Pons registrations separately from this proof-compatibility check. This is not a generic proof adapter for arbitrary ERC20 storage layouts. Long automatically excludes zero, the dead address, PoolManager, the holder policy and token itself. Pons excludes the burn addresses, policy, token and factory plus its canonical v1 pool/locker or v2 curve, PoolManager, locker, hook, escrow and buyback vault. Up to twelve additional exclusions are fixed at deployment; later third-party pools and custody addresses are not automatically added. Exclusions reduce the denominator and cannot be changed later.

For Long, the UI finds current pool fee recipients onchain; no fee-wallet input is needed. Original beneficiaries are discovery candidates, then current `getShares` values are read at one block. Bounded transfer-event discovery is used when rights moved; incomplete history is labeled as partial. Attachment always rechecks the connected wallet’s current rights.

The payout picker uses the verified paired asset when available and a searchable asset catalogue, with custom-address lookup. The original catalogue was observed in Long’s create flow on 2026-09-11; that provenance is not a restriction on the holder token's platform or a claim of support for every Pons pairing. Stock contract addresses and decimals come from [Robinhood’s canonical asset API](https://api.robinhood.com/rhj/assets) on chain 4663. Names alone never identify a token; addresses are fixed in the constructor. Native ETH is separate from any wrapped-token address. A custom token lookup verifies code and ERC20 metadata, not issuer trust or transfer compatibility.

### Snapshot and funding rules

Anyone may checkpoint the **latest due epoch**. The checkpoint proves the first canonical block whose timestamp reaches the scheduled cutoff, plus its immediately preceding block. Both hashes are checked against Robinhood’s history contract. The contract waits for at least 32 L2 blocks, using ArbSys’s L2 height; this is not a promise of L1 finality.

Authenticated account and storage proofs establish the token’s total supply and excluded balances. Each eligible wallet’s share is:

`floor(epoch reward budget × wallet balance at snapshot / eligible supply at snapshot)`

The reward contract has no passive-reward token allowance or wallet-pull function. Deployment sends zero ETH to the contract; only the signer’s network gas is spent. Funding is a separate explicit transfer or upstream contract route. A separate keeper wallet can pay execution gas but cannot select reward destinations. The reward budget is fixed when the checkpoint executes, from the actual available balance after subtracting prior reserved liabilities. It is not a historical fee balance at the cutoff. Later funding enters a later checkpoint. Missed checkpoints do not recreate every missed distribution: unallocated funds remain available for a future eligible checkpoint. Failing reward-token balance reads can skip that asset for the epoch without preventing other reward budgets.

This policy measures balances at fixed snapshots. It does not prove uninterrupted holding, reward holding duration or prevent trading around known cutoffs. Selling after a snapshot does not remove an already-earned snapshot entitlement.

### Claims and availability

A claim proves the wallet’s balance under the stored snapshot root. Anyone can relay it, but payment goes to the proved wallet. Claims do not expire, each asset can be claimed once per wallet per epoch, and the contract has no allocation publisher or administrator who supplies a trusted holder list. Unclaimed allocations and rounding dust remain reserved; there is no sweep or rescue path.

The website’s proof helper uses the public [BlockReq Robinhood archive endpoint](https://blockreq.com/chains/robinhood). The contract authenticates the proofs, so the helper cannot invent a valid allocation. Archive availability is still necessary to obtain old claims, and a checkpoint must arrive while its boundary blocks remain available in the chain’s history window and its epoch remains the latest due epoch. The keeper can generate checkpoint proofs and archive its submitted proof bundles. Retaining those bundles does not by itself archive every holder’s future balance proof.

The UI offers checkpoint and claim preparation in [Policies](/policies). Alternative relayers can call the same public ABI. Website downtime does not stop direct contract use, but no contract can submit its own transaction.

## Supporting modules

| Contract             | Fixed behavior and limits                                                                                                                                                                                                                                                                            |
| -------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| LongerFeeVault       | Splits both pool currencies independently among one to eight recipients. An optional timestamp switches between two committed allocations. Phase selection occurs when funds are accounted, not when trades occurred. Cumulative rounding prevents fragmented receipts from changing the allocation. |
| LongerPonsFeeVault | Applies fixed cumulative splits to the verified Pons token’s two fee currencies. `harvest(currency)`, `sync(currency)` and `payout(currency,index)` never pull wallet funds or allow a caller-selected payout destination. Future upstream recipients remain mutable. |
| LongerCurrencyRouter | Applies a different fixed recipient split to each of two currencies. It does not convert either currency.                                                                                                                                                                                            |
| LongerBudgetVault    | Funds a fixed beneficiary up to each currency’s cap, releases against a fixed calendar and credits excess to an overflow recipient. Late funding may be immediately vested under the elapsed calendar. It does not guarantee the cap will be funded.                                                 |
| LongerBuyback        | Available for supported Long pools only, not Pons. Executes a fixed direct V4 route with spend bounds, cooldown, square-root price limit and an absolute output-rate floor. Output goes to a fixed recipient or a verified supply-reducing burn. It has no independent market oracle; a stale floor can halt execution or become economically weak.     |
| LongerLiquidityVault | Adds a fixed amount of liquidity within a fixed tick range and per-execution currency caps. Principal cannot be withdrawn or transferred; fees go to a fixed recipient. Unused balances may remain trapped if market conditions prevent another addition.                                            |
| LongerStakingRewards | Optional deposited-stake rewards with a fixed maturation delay before activation. Pending stake remains withdrawable; this is not a mandatory token lock. Empty-pool rewards go to a fixed recipient. Principal withdrawal has a path independent of reward-token transfers.                         |

All destinations and relevant execution settings are set at construction. Public callers may trigger the allowed operations but cannot redirect them. Ordinary non-rebasing, non-tax ERC20s and native ETH are the supported accounting model. Issuer restrictions, unusual balance behavior, pool conditions or a wrong permanent parameter can prevent execution. Immutability does not guarantee funding, market value or liveness.

## Current Long launch authorization

The researched current Long Robinhood entry point is proxy `0x1Eef016F22A943abC7DD11422EDeE9D235942104`, with verified implementation `0x7B7b87fd1Fb05864cD572C7306038552286c73d9` on the research date. Its launch requires a Long-enabled EIP-712 signer to authorize the launcher, full creation-parameter hash, expected token address and deadline. It is not an unrestricted unsigned-template interface. [Verified implementation](https://robinhoodchain.blockscout.com/address/0x7B7b87fd1Fb05864cD572C7306038552286c73d9?tab=contract), [representative production launch](https://robinhoodchain.blockscout.com/tx/0x8d8041d4cb013bad0e8457a35bd3d1b695cf6ba347f479af620d53098a9de3ac).

The [Authorization page](/authorization) validates an already-authorized launch payload against the current implementation, caller, parameter hash, signature, expiry, signer status, replay state, deterministic token prediction and call simulation. It does not request authorization, launch a token or verify an immutable fee attachment. A valid Long signature is not a complete Longer launch transaction.

New-token support still requires accepted backend access, preserving Long’s required beneficiaries and economics, deriving the exact token and pool, deploying destinations before assigning rights, an atomic reviewed launch path, receipt verification and confirmation of listing behavior. Historical package examples alone do not satisfy these requirements. Never assign rights to an undeployed predicted address.

## Wallet execution and release evidence

[Deploy](/deploy) prepares constructor arguments, checks release artifact hashes, simulates creation and estimates gas before displaying the exact transaction. Reviews expire after two minutes and clear when the account or chain changes. The wallet performs signing. Receipt verification checks transaction intent, deployment code and the mined block after three confirmations. For automatic starts, the app matches the compiled runtime, reconstructs every permanent setting and its fingerprint, and verifies that the resolved start equals the mined deployment block timestamp. Other deployments require exact equality with the simulated runtime. Three confirmations are an application policy, not an assurance against every reorganization.

Policy inspection matches recognized release runtimes and reads current configuration, dependencies and entitlements. Its reads are observations beginning at a displayed block, not an atomic snapshot of all external state. A matching runtime does not certify upstream governance, token issuers or an independent audit.

The supplied keeper defaults to one simulation-only pass. Explicit execution requires a dedicated operator key, gas funding and bounded configuration. It supports generated holder checkpoints, saves checkpoint proof bundles, simulates allowed calls and records pending intents before broadcast. It does not automatically claim every holder’s reward. Ambiguous submissions require reconciliation before further sends.

A Railway website deployment is separate from deploying contracts, directing platform fees, creating a token on either platform or running a funded keeper. Publish each actual chain deployment and configuration separately. See the [validation record](validation.md) and [release readiness](launch-readiness.md) for evidence and outstanding gates.