Skip to main content

Unconstrained Signals

Detector Type:Constrain Only

Summary and Usage​

The Unconstrained Signals (UCS) detector identifies signals in ZK circuits that are not used in any constraint. If a signal is unconstrained, a malicious actor may be able to generate new valid proofs by reusing an existing proof and simply changing the value of the unconstrained signal.

Usage​

info

Coming soon.

Example and Explanation​

info

Coming soon.

Usage Example​

info

Coming soon.

Limitations​

While attackers may be able to exploit unconstrained input signals, some proof systems automatically introduce a "magic constraint" that constrains otherwise unconstrained inputs (see this discussion on Groth16 malleability). These implicit constraints prevent attackers from manipulating unconstrained public inputs to forge new proofs. As a result, unconstrained input findings may have lower severity than other ZK Vanguard findings, and can sometimes be false positives due to these system-level constraints.

How to Assess Severity​

Findings from the UCS detector can range from benign to critical, depending on which type of signal is unconstrained and how it affects the circuit.

  • Input signals may sometimes be intentionally left unconstrained, for example when magic constraints are expected to be generated or when a value only needs to be tied to the proof (e.g., a nonce checked for uniqueness by a smart contract). However, developers should still be cautious: different proof systems may or may not add such constraints automatically, and unconstrained inputs may also indicate semantic bugs, such as forgetting to include a value in a hash computation.
  • Output signals that are unconstrained (see Underconstrained Outputs) are usually severe, since they often mean key computations or constraints have been accidentally omitted. These findings are highly likely to be critical.
  • Internal signals that are unconstrained may cause nondeterministic proofs, where multiple valid proofs can be generated for the same inputs and outputs. This can lead to severe protocol issues such as double spending or multiple nullifiers for the same commitment.