Documentation

A snapshot may settle a commit or a decommit, never both: close and fanout carry a single incremental action, so a snapshot with both would leave the head unclosable.

A decommit that materializes no output cannot be settled: the decrement validator requires at least one decommit output.

The deposit is claimed by a signed snapshot whose increment settled on-chain but was rolled back: its funds are already accounted for in the head, so recovering them on-chain would corrupt the L2 ledger. The increment is re-posted instead, see #2741.

The requested deposit is claimed by an already signed snapshot whose increment settled on-chain but was rolled back (which is the only way it resurfaces in the pending deposits): signing a second snapshot claiming it would double claim the deposit. Only re-posting the increment settles it, see #2741.

The side-loaded snapshot commits the same UTxO as the confirmed one, but from a different deposit. Since the deposit is what identifies a pending commit, this is a distinct disagreement from SideLoadUTxOToCommitInvalid, whose payload would show two identical UTxO sets here.

The snapshot commits to more outputs than the accumulator's trusted setup supports, so its commitment could never be computed.

SECURITY: unlike its siblings, this one is raised at the client API boundary rather than by the head logic, and it has to be: forcing an over-capacity accumulator calls RequirementFailure (see checkAccumulatorSize), and by the time the head logic sees an input the node has already traced it, which forces it. See validateClientInput.

update keeps an independent check for any future producer that skips the boundary, reported as SideLoadSnapshotFailed. That route deliberately does not go through sideLoadFailed: a SideLoadSnapshotRejected client message echoes the offending ClientInput back, and encoding that echo would force the very accumulator that cannot be computed. This constructor carries only the two counts, so it is safe to report either way.