This can be done by collaboratively creating a shared private key that is specific to the instance of the protocol upon setup. Moreover, using MuSig on the two participants will reduce the need for OP_CHECKMULTISIG/OP_CHECKSIGADD. There is no requirement for an explicit OP_CHECKSEQUENCEVERIFY, or even separate keys for state and update paths. The proposal that does not include OP_CODESEPARATOR is given as OP_CHECKLOCKTIMEVERIFY OP_DROP OP_CHECKSIG OP_CHECKSIG. For update transactions, nSequence is 0, and for state transactions, it is non-0. Both of them will have nLockTime equal to the required index. The nSequence is enforced by the participants refusing to sign invalid nSequence. When updating the channel, anyprevoutanyscript signatures (for the 2-of-2 multisig) are exchanged between Alice and Bob. The chaperone signature can be provided by either Alice or Bob at transaction broadcast time so that it commits to a specific input transaction. However, they could use another key-pair (chaperone key) if the same key for both signatures is unsafe.ZmnSCPxj also mentioned that although the chaperone idea is quite good, it won't play nice with taproot collaborative spends that require anyprevout / anyprevoutanyscript / noinput, making it stand out. Nonetheless, this should happen rarely. Finally, the use of any SIGHASH that is not SIGHASH_ALL already stands out, so there is no significant objection.