Snapshot Code Style Findings

STO-01C: Potentially Inefficient Storage Structure

Type	Severity	Location
Code Style		Snapshot.sol:L16, L23, L28

Description:

The SnapshotLib implementation will ensure that at least one bit remains as 1 whenever a Snapshot entry is mutated as a form of gas optimization, however, the location of this bit may cause issues if the Snapshot structure is expanded.

Specifically, the value of 1 << 31 (i.e. 10000000000000000000000000000000 in binary) will follow any data point in the Snapshot structure that precedes the _stamp value. The issue that arises from this is that expansions of the Snapshot structure cannot be made as any data points introduced would have to accommodate for a potentially dirty most significant bit.

Example:

Copy
9struct Snapshot {
10    // Packed slot: 14 + 14 + 4 = 32
11    // vault's cash holdings
12    Assets cash;
13    // vault's total borrows in assets, in regular precision
14    Assets borrows;
15    // stamp occupies the rest of the storage slot and makes sure the slot is non-zero for gas savings
16    uint32 stamp;
17}
18
19/// @title SnapshotLib
20/// @author Euler Labs (https://www.eulerlabs.com/)
21/// @notice Library for working with the `Snapshot` struct
22library SnapshotLib {
23    uint32 constant STAMP = 1 << 31; // non zero initial value of the snapshot slot to save gas on SSTORE

Recommendation:

We advise the STAMP to be set to 1, ensuring the least significant bit of the overall Snapshot data point is configured and thus permitting the introduction of new variables after borrows.

Alleviation (fb2dd77a6ff9b7f710edb48e7eb5437e0db4fc1a):

The STAMP variable has been updated to represent 1, ensuring that the Snapshot data structure can expand if needed and addressing this exhibit.