Remove the payment channel (paych) actor entirely

[rvagg]

This came up during Solstice / FIP-0118 implementation, having to dodge paych actors as recipients of funds because they are an actor type that can delete itself and therefore prevent a send causing some backlog problems..

Payment channels may have solved a particular problem at the time they were dreamed up, but they never became a meaningful part of the network. We also now have better tools for this kind of thing, with FEVM. This proposal to remove the paych actor should be a warning not to start depending on native payment channels because the'll likely be yanked in the near future during a clean-up. We would implicitly expire any unsubmitted off-chain vouchers, which are unlikely to be for meaningful un-claimed work.

Blast radius

Actors:

• There are 5,602 payment-channel actors currently on chain.
• None of these actors has changed in the last two years.
• 5,555 existed before FVM and are unchanged since 2023-03-13 (I don't currently have access to an archival node that goes back further than this).
• 47 created later.
• Current state of all of these actors is identical to what it was on 2024-09-16, two years ago today.

Funds:

• Total channel balance: 142.388445741182127271 FIL
• Total current ToSend obligations: 0.000144331336436440 FIL
• Balance in the 47 post-FVM channels: 0.000120349427722464 FIL

How to remove

At the network upgrade:

1. Credit each channel's recorded ToSend amount to To.
2. Credit the remaining balance to From.
3. Remove the payment-channel actor and its state.
4. Remove the builtin-actors paych actor type.

[jennijuju]

Stop allowing new paych creation and set of operation makes sense and set up a trajectory to completely deprecating it ; Move balance as suggested, however, sets a very bad precedence imo.

[jennijuju]

To elaborate: if this passes, it establishes that the network will move user funds through state surgery. You provided data suggests it’s okay to do cuz it is "small balance, little activity." The same reasoning could later be applied to low-activity multisigs, inactive miner actors with locked balances, or FEVM contracts holding funds with little movement. Once a FIP has redistributed user funds, future fips can be open and the discussion will be moved from "is this ever acceptable?" to "is this case different enough?" Which then becomes expensive governance problems.

Returning balances to From and To doesn't avoid this. The protocol would still be deciding how funds are split between two parties who never settled, overriding the channel's own rules (including To's right to redeem unsubmitted vouchers) to do it.

It also sends the wrong signal to builders. If core devs can rewrite native actor balances once an actor type becomes inconvenient, builders and their users would then reasonably ask why their contract balances are any different. Payment rails, including FEVM-based ones, depend on a credible guarantee that neither the protocol nor any party on the network can reallocate funds under users' control.

I understand this is meant as technical hygiene, and I support that goal: disable creation, stop changes to the paych and only allow settles, and set a deprecation path. But a change to who holds funds is a fund-ownership decision, not a code-hygiene one. It makes it harder to say that no party can move user funds on Filecoin, which undermines a core guarantee of the blockchain as a ledger.

[ThatGuyLLC]

@rvagg want to discuss this on core devs on the 30th?

[rvagg]

sorry, missed this comment
but no, core devs isn't in my timezone