When a channel containing a contract is solo closed, who gets the contract's funds?


#1

The contract’s owner?

Or do contract authors write a “destructor” function to compute a distribution of the funds?


#2

Hi @bakkhos
This depends on contract’s logic. When a channel is in a closing state, any participant that provides a valid Force Progress transaction to it can execute an off-chain contract on-chain, thus producing a new state channel’s state on-chain. Those on-chain calls modify the contract’s balances as well. The final balances are according to the last channel’s state provided or computed on-chain.

If you contract has a resolve mechanism stating that at any point of time the contract’s owner can claim the tokens back, yes, one can force progress that call. So this is the way to go:

Or do contract authors write a “destructor” function to compute a distribution of the funds?


#3

The question was about the default behaviour, if no contract functions are called. Then neither party gets the funds, right?

I understand this might not matter. A central assumption seems to be that neither party will ever involuntarily go offline for longer than the duration of the closing state (i.e. the lock period). If this is violated, we have bigger problems (the survivor can close with an obsolete state, potentially double spending). If it holds, both parties can as you say, as a last resort, use FP to withdraw money from contracts.

Or even as a not-so-last resort, if the fees involved in the FP-based closing are negligible… if they are not negligible, it gets complicated.

So can delegates FP as well as slash? Seems like they would need to be able to do both, to protect one from losses in event of disconnection.


#4

Yes, as participants are equal in every regard in a channel exposing a destructor default in contracts that by default benefits one of them seems a generally bad idea. So this is left up to participants to decide in their specific contracts.

Not if a delegate takes care for you. Regarding the delegates being able to FP - this is a tricky one as you might not want all contracts to be force progressable due to their costs. As you’ve noted - it is a matter of a trade off - some contracts have enough tokens to be worth it to be force progressable, some - don’t. Currently delegates can not FP, neither they can provide snapshots.