This security review step focuses on the value of tokens and other assets in smart contracts. It aims to discover errors such as inadvertent value gain (for example through value inflation), loss of value, burning of value, mis-pricing, arbitrage and others.

Define a set of value invariants

As a first step, define a set of value invariants that should not change. Here are some example invariants that could hold for an AMM:

• A liquidity provider cannot take out more LP shares than they deposited
• A liquidity provider can redeem their shares in the form of underlying tokens
• Pool liquidity is either invariant or growing after each trade
• Trades cannot be completed at a more favorable price than the spot price

Verify the invariants

Once the invariants can be established, they need to be individually verified. Hopefully, existing test cases already help validate some of these invariants, but there may also be more nuanced issues associated with the flow of value:

• Floating point errors and rounding
• Gas-related accounting issues
• Pricing & oracle related issues
• Front-running vulnerabilities.

Fuzzing

For more complex code, Fuzzing can help build more confidence about invariants that are hard to validate through reasoning and reading the code alone, for example, floating point errors.

Formal verification

Formal verification could also be used for simpler invariants.

‍

‍