At a high level, a user would lock funds into a CAT covenant that commits to a particular r-value.
This means the spending transaction for this utxo must use that particular r-value when sending funds. If the user sends funds and tries to RBF, they will inevitably end up using a new s-value, resulting in nonce-reuse and allowing for their funds to be slashed by anyone watching the mempool.
Specifically, this involves the following scripts (as outlined by bt canary in their original spec https://gitlab.com/-/snippets/3735654)
Locking Script:
// Verify r and compose signature
OP_OVER
OP_HASH160
<$( OP_HASH160)>
OP_EQUALVERIFY
OP_CAT
OP_SWAP
// Stack: ,
// Standard P2PKH script
OP_DUP
OP_HASH160
<$( OP_HASH160)>
OP_EQUALVERIFY
OP_CHECKSIG
Unlocking script
<$(<0x41> OP_CAT)>
As we can see, the locking script commits to the r-value, which the unlocking script must provide along with the s-value to be used.
CAT is necessary to concatenate the r and s values together on the stack, to be verified by CHECKSIG at the end of the script.
Private key recovery is specified on the original spec as well: https://gitlab.com/-/snippets/3735654
(Or a more comprehensive explanation of how slashing is achieved for those that are new to schnorr signatures can be seen here: https://web.archive.org/web/20231003173156/https://suredbits.com/introduction-to-schnorr-signatures/ )