Opting in to additional slashing conditions
At a conceptual level, restaking works by letting a validator voluntarily opt in to one or more additional sets of rules, each defined by a separate service, and each carrying its own slashing conditions. The validator's original stake on the base chain doesn't move anywhere, it stays locked exactly where it was, still subject to the base chain's original slashing rules for base-chain misbehavior. What changes is that the validator now also commits to performing specific duties for the additional service, whether that's signing off on data, relaying information, or attesting to some outcome, and agrees that failing to do so correctly can trigger a separate slashing penalty against that same underlying stake.
This opt-in step is deliberate and explicit, not automatic. A validator has to actively choose which services to secure, weighing the extra rewards on offer against the extra risk being taken on. Each service defines its own conditions for what counts as a violation and how severe the resulting penalty is, and those conditions get enforced independently of the base chain's own rules. The restaking protocol's job is essentially to be the plumbing that connects a validator's existing stake to these additional, pluggable rule sets, so that new services can define their own slashing logic without needing to convince validators to set up an entirely separate staking system.