In OrchidDirectory.step() and OrchidDirectory.lift(), use a signed amount  Won't Fix
`step()` and `lift()` both accept a `uint128` parameter called `amount`. This `amount` is added to various struct fields, which are also of type `uint128`.\\nThe contract intentionally underflows this `amount` to represent negative numbers. This is roughly equivalent to using a signed integer, except that:\\nUnsigned integers aren't sign extended when they're cast to a larger integer type, so care must be taken to avoid this.\\nTools that look for integer overflow/underflow will detect this possibility as a bug. It's then hard to determine which overflows are intentional and which are not.\\n```\\nlift(key, stake, -amount, stakee, staker);\\n```\\n\\n```\\nstep(key, stake, -current.amount\\_, current.parent\\_);\\n```\\n
Resolution\\nThe variables in question are now uint256s. The amount of type casts that would be needed in case the recommended change was implemented would defeat the purpose of simplification.\\nUse `int128` instead, and ensure that amounts can never exceed the maximum `int128` value. (This is trivially achieved by limiting the total number of tokens that can exist.)
```\\nlift(key, stake, -amount, stakee, staker);\\n```\\n