Pons fee sink

pons-fee-sink v1

Collects one pons v2 token's creator fees on-chain and hands them straight to a Socket instance you already deployed: a fee splitter or a reward vault.

What it does

pons keeps each fee recipient's earnings in its escrow, and only the recipient can claim them. The sink becomes your token's fee recipient, so it can claim them. Anyone can press **Collect fees now** (`pull()`). That call:

1. tries to sweep fees still sitting in the pons pool into the escrow, if `trySweep` is on. pons refuses some sweeps with `InternalSwapRequiresOperator` (`0x31cdb504`) when its own operator has to do them. That is normal, and the sink skips it. 2. claims the escrow's ETH ledger, releases the buyback vest (if any), and claims the token ledger, 3. takes the Socket fee once (`PonsFees`, 0.5% by default), 4. delivers everything to your splitter or vault (`onPonsFees`). If the destination refuses (paused, halted or full), the value stays in the sink and is retried on the next collect or on **Retry delivery** (`flush()`). Collecting never fails because of the destination.

Setup: 2 transactions

1. **Deploy the sink** with your token and destination (deploy the destination first, or as an earlier step of the same recipe). 2. **From your current pons fee wallet, send `transferCreatorFeeRecipient(token, sink)`** to the pons v2 factory (`0x7eD598BcEf8bd9Edd8C97A195C6d13f40801EC7e`). Only the current recipient can do this. Socket cannot do it for you. A mainnet fork test showed the switch is **immediate**: `getLaunchedToken(token).creatorFeeRecipient` is the sink in the same transaction, and `pendingCreatorFeeRecipient` stays empty. Fees already credited to your old wallet stay there, so claim them from that wallet as usual.

`isLive()` turns true once step 2 is done.

Roles

| Role | Can | |---|---| | Anyone | `pull()`, `flush()` | | Owner (the deployer) | `pause` / `unpause` collecting; `proposeHandBack(to)` then `executeHandBack()` 72 h later, or `cancelHandBack()`; `lockForever()`; `rescue` of stray assets above custody |

The token, the destination and the sweep switch can never change. If the destination instance is migrated to a new version, value follows its `successor()`, which has the same owner and the same settings.

Risks in plain English

- The destination is fixed. Pick it carefully. - The owner can move the fee stream away, but only after a public 72 h countdown, and never after `lockForever()`. - Sweeps that need pons's operator happen on pons's schedule, not yours. `pendingClaimable()` shows what is still in the pool. - When this module is halted or the instance is paused, collecting stops, but fees stay safe in the pons escrow. Held value can always be delivered. - A migrated sink stays fee-exempt (a core rule), so its final delivery into a splitter is not charged a second time. - Only native-ETH pons launches are supported in v1.

Fee lanes

| Flow | When | |---|---| | `PonsFees` (default 50 bps, hard cap 100) | once, on every ETH and token amount collected from pons, or sent to the sink directly |

The sink is published with `FLAG_CHARGES_INFLOW`. The splitter or vault it feeds sees it as an exempt payer, so nothing more is charged along sink → splitter → vault.

What if

- **I lose my wallet?** Collecting and delivering keep working, because they are permissionless. You only lose pause and hand back. - **My splitter or vault is paused or broken?** The sink keeps the fees and retries every time. See `owedToConsumer()`. - **I want my fees back in my own wallet?** Use `proposeHandBack(myWallet)`, wait 72 h, then `executeHandBack()`. - **Someone sends ETH or tokens to the sink directly?** ETH is refused unless it comes from the pons escrow. Stray tokens pay the same fee and are delivered with the next collect. - **The token never graduated?** The sink sweeps the bonding curve instead of the pool, and claiming works the same way.

Consumer interface

```solidity interface IPonsFeeConsumer { function onPonsFees(address token, uint256 eth, uint256 tokens) external payable; // msg.value == eth function acceptsPonsToken(address token) external view returns (bool); } ```

The consumer takes `msg.value` with `_chargeNative` and pulls exactly `tokens` with `_pullIn(token, msg.sender, ...)`. Both are exempt because the sink is flagged.