Creator fee redirect + escrow release for two Seam coins (Robinhood Chain 4663)

[neuroncolony]

Hi Pons team,

We're Seam (seam.family), a launchpad built on Pons V2. Two coins launched through our first launch contract (0xc930359b514e916c67714abed85706da19368163) have their creator fees going to per-coin RigVault contracts. Those vaults are immutable and can't call your fee-recipient update themselves, so we're stuck without your help.

Coins:

1. DWOG (dwoggy)
   Token: 0xb6b881b09b8a80b236e1070acaedba751a8c60b3
   Vault (current fee recipient): 0x086c8a761d0f5baf514f082287b99dc038b59c6c
2. SEAM (seam.family)
   Token: 0x7e8f400b7de0cb7e63dda9ce12f7b6c221c24a33
   Vault (current fee recipient): 0x70b888d2f7fdf82e81c18cd2c7b3fa68e65c4ef0

Fee escrow: 0xd3afeb2a57f70ef218aa82451c51b2fb0416ac9e (currently about 0.11 ETH credited to the DWOG vault 0x086c... and 0.53 ETH to the SEAM vault 0x70b888d2...).

What we're asking:

1. Future fees: as owner (0x263ed295dafae1d9aadd6e56c4b6f9f38ee019dd), please point the creator fee recipient for both tokens to 0x9eBa461a8B6226170CF4394cE64831376C924726. We understand there's a 3 day delay.
2. Escrowed balance: can you release or reassign the ETH already in escrow for these two vaults to the same address? If your contracts can't do that, a short "not possible" is enough and we'll use the in-vault route instead.

Why: our newer launch contract (0x0d830e62caa2ad8f49bb649d367fd329bc179613) already sends fees straight to that wallet. These two are the only coins left on the old setup.

Happy to sign a message from 0x9eBa...4726 or our owner wallet 0xFB10DEe2b407347F732399af51540722B24C212f to prove control.

Thanks,
Seam team
help@seam.family

[koriyoshi2041]

Source-level triage against current main (162310fb), without making any chain calls:

Future fees: supported through the owner override

The factory has the requested recovery path:

1. The factory owner calls setCreatorFeeRecipient(token, 0x9eBa461a8B6226170CF4394cE64831376C924726) for each token.
2. This records a proposal with effectiveAt = block.timestamp + 3 days.
3. After effectiveAt, any address can call executeCreatorFeeRecipientChange(token); it does not need to be the owner.

One operational detail is easy to miss: execution has a second three-day deadline. The proposal expires at effectiveAt + 3 days, so each change must be executed during days 3–6 after proposal. If it expires, the owner must propose it again.

_setCreatorFeeRecipient forwards the update to the currently active payout contract (curve before graduation, meme hook after graduation) and also updates the buyback vault beneficiary. This means the same two-call owner flow covers both tokens regardless of graduation phase, assuming these deployments match the checked-in V2 implementation.

Relevant source: contractsV2/src/v2/PonsV2LaunchFactory.sol, setCreatorFeeRecipient, executeCreatorFeeRecipientChange, and _setCreatorFeeRecipient (around lines 946–1005).

Already escrowed ETH: no factory-side reassignment path in the published API

The published IPonsV2FeeEscrow surface exposes only recipient-keyed balances and self-claims:

claim()
claim(uint256 amount)
balanceOf(address recipient)

There is no transferBalance, reassign, owner rescue, or claimFor method in that interface, and changing the launch's creatorFeeRecipient only changes future routing plus the buyback beneficiary; it does not migrate an existing escrow ledger entry. Therefore the factory override cannot move the approximately 0.11/0.53 ETH already credited to the two RigVault addresses.

Based on the checked-in contracts, the existing balances need to be claimed by each old vault through its own callable route. If those vaults truly cannot invoke the escrow, the repository does not expose a protocol-side recovery path for those historical credits. A maintainer should confirm this against the exact deployed escrow bytecode before treating it as final, because the escrow implementation itself is not included in this repository—only its interface is.

No transaction, RPC call, wallet, or private key was used for this analysis.