Ammplify is the first AMM LP Amplifier that improves yield on existing AMM LP positions without any increase in impermanent loss. It works by segmenting LP positions into shared buckets, applying smart auto-compounding, and enabling piece-wise pooled lending for overlapping liquidity ranges.
Scope
On what chains are the smart contracts going to be deployed?
Monad
Berachain
Arbitrum
Base
Polygon
BnB
If you are integrating tokens, are you allowing only whitelisted tokens to work with the codebase or any complying with the standard? Are they assumed to have certain properties, e.g. be non-reentrant? Are there any types of weird tokens you want to integrate?
We handle any non-weird tokens that fit the ERC20 standard.
The protocol does not have a whitelist, but if a weird token is used with it and operations fail that is okay. It is on the user to not interact with pools that have weird tokens. (We will warn against weird tokens on the front end).
However, we are not expected to have issues with:
The traits listed above are in scope and the contracts are expected to work correctly with them. Users will be able to create pools with tokens with other weird traits, but if they malfunction, it’s considered an acceptable risk.
Are there any limitations on values set by admins (or other roles) in the codebase, including restrictions on array lengths?
The owner is trusted and those with Taker and Veto permissions are trusted.
There are no restrictions on the admin values set.
The Takers are expected to always provide sufficient collateral to cover all the fees they owe.
Are there any limitations on values set by admins (or other roles) in protocols you integrate with, including restrictions on array lengths?
We should be safe to integrated with any reasonable Uniswap pool. If users attempt to use Ammplify on a malformed Uniswap pool that is considered user error.
Is the codebase expected to comply with any specific EIPs?
There are no EIPs adhered to by Ammplify, but its NFT manager does comply with 721.
Are there any off-chain mechanisms involved in the protocol (e.g., keeper bots, arbitrage bots, etc.)? We assume these mechanisms will not misbehave, delay, or go offline unless otherwise specified.
No.
What properties/invariants do you want to hold even if breaking them has a low/unknown impact?
No.
Please discuss any design choices you made.
The fee distribution for taker borrow costs is not split exactly, and it's possible to manipulate it by depositing liquidity in certain ways. This is why we apply a penalty to positions that deploy liquidity for too brief a time. However, it is expected that the manipulation is not too extreme. No single position can be charged 10%+ more than their true fee calculation rate or more than the average pool rate, whichever is larger.
Please provide links to previous audits (if any) and all the known issues or acceptable risks.
Gas costs that are over the usual block gas limit are not considered an issue because Monad's limit is 150M. Even if there are problems with exceeding the gas limit on other chains, it's considered a known and acceptable risk.
Please list any relevant protocol resources.
docs.ammplify.xyz
Additional audit information.
Issues that lead to getting incorrect return values (i.e. deviates from the withdrawal value of the asset by more than 0.01%) from the queryAssetBalance
function (even if the appropriate input is used), which will lead to issues when executing other functions, may be considered valid with Medium severity at max.
Total Rewards
Contest Pool
Lead Senior Watson
Lead Judge
46,200 USDC
22,800 USDC
8,500 USDC
Status
Scope
Start Time
End Time
Judging Rules