Root + Impact

Description

The Snow and Snowman contracts declare storage variables that are assigned only once during deployment (typically in the constructor) but are not marked as immutable.

In Solidity, variables that are set once during construction and never modified thereafter should be declared immutable. This not only provides clearer intent at the code level but also enables the compiler to optimize storage by embedding the value directly into the contract bytecode, significantly reducing gas costs on reads.

Failing to use immutable results in unnecessary storage reads during runtime, which are substantially more expensive than accessing an immutable variable.

Risk

Likelihood: Low
Impact: Low

This issue does not introduce any functional or security risk. However, it results in unnecessary gas inefficiencies on each read of the affected variables. Over time, especially in frequently accessed functions, these inefficiencies can compound. Furthermore, it reduces clarity in the code by not distinguishing between variables that are constant after deployment and those that are truly dynamic.

Proof of Concept

In the Snow contract:

In the Snowman contract:

These variables are initialized once during deployment but not updated afterward, making them prime candidates for the immutable modifier.

Recommended Mitigation

Refactor these variables to use the immutable keyword to reduce storage costs and improve code clarity. This allows the compiler to store the values in the contract's bytecode, making future accesses cheaper.

Suggested Fix — Snow Contract

Suggested Fix — Snowman Contract

Ensure these values are still properly initialized in the constructor. This change will reduce gas costs for every future access and signal the read-only nature of the values more clearly.