Stabilizer

6.1 A collateral depeg flows straight into USDZ

USDZ is minted against collateral at a fixed nominal 1:1, with no price feed. The mintUSDZ(...) function treats one unit of any supported asset as one dollar of backing and mints USDZ accordingly, and isSolvent() in ReserveHolder measures backing by token quantity rather than market value. This is by design, since the protocol is oracle-free, and it holds while every collateral trades at $1.

The problem appears when a collateral asset loses its peg. If USDC falls to $0.90, mintUSDZ(...) still mints one USDZ per USDC, so every mint injects $0.10 of bad debt into USDZ's backing, and nothing in the mint path prices the asset any lower. The only knob the protocol has here is the mint fee, and it cannot defend the peg.

The fee is taken out of the collateral pool rather than kept as backing. mintUSDZ(...) forwards only the post-fee amount into the reserve and books the fee as protocol revenue:

IReserveHolder(reserveHolder).depositToAdapter(address(this), asset, amountAssetIn - fee);
// @audit-issue The fee is booked as revenue, so it never backs USDZ.
accumulatedFees[asset] += fee;
IUSDZ(usdz).mint(msg.sender, amountUSDZOut);

The minted USDZ always equals the collateral added (both are amountAssetIn - fee), so the backing ratio stays at a nominal 1:1 no matter how high the fee is set; raising the fee just shrinks both sides together. Suppose USDC is at $0.90 and the fee is raised to 10% to match. A 1 USDC mint deposits 0.9 USDC into the reserve and mints 0.9 USDZ, so the new USDZ is backed by $0.81, still only $0.90 per USDZ.

Recommendation

Consider implementing a special haircut for depeg scenarios that can feed into USDZ reserves.

Resolution

resolved in

6.2 Asset-side LP fees round to zero and become permanently unclaimable in low-decimal pools

Every pool pays trading fees to its liquidity providers with a per-share accumulator. Two terms matter here. totalSupply is the pool's LP-share supply, the total liquidity provider tokens minted for this pool, which changes only when someone adds or removes liquidity. accFeePerShareX is a running total of "fee earned per LP share, summed over all swaps"; it exists so the pool can pay many LPs without looping over them, since any LP's claim is just their shares times how much the accumulator grew while they held those shares.

On an asset-side swap the LP part of the fee is added to feeReserveX, the pot LPs later withdraw from, and accFeePerShareX is bumped so that new fee becomes claimable. An LP's claimable amount is read straight off that accumulator, so if it does not move, the fee cannot be claimed.

function _distributeFeeX(uint256 feeAmount) internal {
    // ...
    if (lpFee > 0) {
        feeReserveX += lpFee;
        // @audit-issue Rounds to 0 when lpFee < totalSupply / 1e18, and the remainder is dropped.
        if (totalSupply > 0) accFeePerShareX += (lpFee * ACC_PRECISION) / totalSupply;
    }
    // ...
}

The two lines use different units. totalSupply is tracked on an 18-decimal basis, but the asset-side lpFee is in the asset's own decimals. For a 6-decimal asset like USDC that is a 12-decimal gap, and ACC_PRECISION is 1e18. So the increment lpFee * 1e18 / totalSupply rounds down to 0 whenever lpFee is smaller than totalSupply / 1e18. The leftover is not saved for next time, so a run of small fees never adds up either: feeReserveX keeps growing while the accumulator stays put.

The cutoff is a fixed fraction of pool depth. On a pool holding 1,000,000 per side, totalSupply is 2e24, so the accumulator only moves once lpFee reaches 2 USDC, which at the default 1 bps fee is any swapFromAsset(...) below 20,000 USDC. That is about 2% of the per-side size, and the same 2% rule holds at any pool size. Since most swaps are far smaller than 2% of the pool, ordinary trading strands its asset-side fee almost every time, and the 1 bps rate the protocol advertises is the worst case.

When the accumulator does not move, no LP accrues anything, so the fee sitting in feeReserveX is unreachable. The protocol cannot take it either, because it was routed to feeReserveX and not protocolFeeReserveX, and removeLiquidity(...) pays out only reserveX and reserveY. There is no path that pays out feeReserveX beyond what the accumulator recorded, so the stranded fee is frozen in the pool for good.

This affects the asset side only. The USDZ side is already 18-decimal, so its cutoff is below one wei and it credits normally.

Recommendation

Consider matching the units before the division, for example by scaling the asset-side fee up to the same 18-decimal basis as totalSupply, or by using a much larger accumulator precision, so a realistic fee no longer rounds to zero.

Resolution

resolved in

6.3 Depeg protection is enforced only on the pool swap path, not on USDZ mint and redeem

The protocol has two separate ways to convert between a collateral asset and USDZ. One is a pool swap (swapFromAsset(...) / swapFromUSDZ(...)), which is priced on the hybrid curve and carries both the trading fee and the emergency depeg fee. The other is minting and redeeming on the StabilizerAMM contract (mintUSDZ(...) / redeemUSDZ(...)), which converts at a fixed 1:1 rate and carries only a small mint or redeem fee.

The emergency depeg fee is the protocol's defense during a depeg. When an asset loses its peg the guardian raises that pool's fee through setEmergencyDepegFee(...), making it expensive to trade the bad asset. The fee is read by getEffectiveFee(...) and charged on both directions of a pool swap:

function swapFromAsset(uint256 amountIn) external ... {
    // ...
    uint256 feeAmount = (amountIn * getEffectiveFee()) / BPS_DENOMINATOR;
    uint256 netInput = amountIn - feeAmount;
    // ...
}

The root problem is that this defense exists only on the pool path. The mint and redeem path, which is the more direct way to move value between an asset and USDZ, never reads the emergency fee. It charges only mintFeeBPS / redeemFeeBPS, which default to 1 BPS and are set by the admin, not the guardian:

function mintUSDZ(address asset, uint256 amountAssetIn) external ... {
    // ...
    // @audit-issue Only mintFeeBPS is charged here; the pool emergency fee is never read.
    uint256 fee = (amountAssetIn * mintFeeBPS) / BPS_DENOMINATOR;
    uint256 amountAssetAfterFee = amountAssetIn - fee;
    amountUSDZOut = amountAssetAfterFee * (10 ** (18 - assetDecimals));
    // ...
}

So any protection the guardian applies to a pool can be sidestepped by routing through mint or redeem instead. The clearest impact is that the emergency fee can be bypassed outright. Suppose USDC drops to $0.90 and the guardian sets a large emergency fee on the USDC pool. An attacker holding cheap USDC skips the pool and calls mintUSDZ(...), turning USDC worth $0.90 into USDZ worth $1 for a 1 BPS fee, then swaps that USDZ into a healthy asset such as USDT or simply holds it. The protocol is left holding the bad USDC as backing, and the loss falls on the protocol and its LPs, which is exactly what the emergency fee was meant to stop. This was reproduced in a PoC: with a 50% emergency fee live on the USDC pool, the same USDC produces almost no USDZ through the pool but a near full 1:1 amount through mintUSDZ(...), and the full USDC - USDZ - USDT route lets the attacker exit close to par.

The same root cause shows up in several other ways. The guardian's emergency lever has no reach over the main path, since setEmergencyDepegFee(...) only touches pools while mint and redeem can be stopped only by pause(), which is onlyAdmin, so the fast, per-asset, lower-trust response the protocol built for a depeg does not cover the path an attacker would actually use, and only a full admin pause does. The redeem side makes this worse: once an asset depegs USDZ becomes partly backed by the bad asset, yet redeemUSDZ(...) still pays out a healthy asset at 1:1 (minus the redeem fee), letting holders race to pull good collateral and leave the bad behind while the emergency fee cannot slow them down, because redeem never reads it.

Recommendation

Consider enforcing the depeg protection on every path that converts between an asset and USDZ, not just pool swaps, for example by applying the same per-asset, guardian-settable brake (or a shared peg check) inside mintUSDZ(...) and redeemUSDZ(...).

Resolution

resolved in

6.4 Adding liquidity mints LP shares at face value and can dilute existing liquidity providers

When someone provides liquidity to a pool they receive LP shares, which are a claim on a slice of the pool's two reserves. For that claim to be fair, a deposit should receive shares equal to the fraction of the pool it represents, so a depositor can only ever take back what they put in. This pool mints shares equal to the face value of the deposit, the raw amount handed over, ignoring what a share is currently worth:

dy = (dx * reserveY) / reserveX;
// ...
// @audit-issue Shares equal the deposited value, not a fraction of the existing shares.
lpMinted = _normX(dx) + dy;
_mint(msg.sender, lpMinted);

Face value is only correct while the pool's total value k (its two reserves) equals its share supply totalSupply, so that one share is worth exactly one unit. Once the pool holds more value than that, a face-value deposit hands out shares worth more than the depositor paid. The pool comes to hold that extra value through trading, because when a swap is large enough to move onto the StableSwap curve the trader pays a bit of slippage that stays in the pool. That value belongs to the LPs who are already there, so each existing share becomes worth a little more than one unit (k / totalSupply rises above 1). Rebalancing does not remove it; it only shuffles value between the two reserves and leaves k unchanged. Withdrawals, meanwhile, always pay a strict fraction of the reserves:

amountAssetOut = (lpAmount * reserveX) / totalSupply;
amountUSDZOut = (lpAmount * reserveY) / totalSupply;

So a newcomer who deposits at face value and then withdraws at true value walks off with more than they put in, and the difference is taken from the existing LPs.

An example makes the flow concrete. Say the pool starts balanced with only Alice as its liquidity provider. Alice adds a large amount of liquidity, which pushes the pool onto the StableSwap curve, since adding liquidity raises the pool's internal k/2 floor until swaps begin pricing on the curve. Bob then makes a swap on that curve and pays slippage, and his lost slippage stays in the pool as extra value; because Alice is the LP, that value is now hers, and her shares are worth more, which is the fair reward for providing the liquidity Bob traded against. Carol wants that value without having earned it, but she cannot add liquidity yet, because the pool's reserve is sitting at its floor. So she first mints some USDZ, which tops the reserve back up and leaves Bob's slippage untouched in the pool, and now that she can add liquidity she deposits, is minted shares at face value (over-credited, since each share is really worth more than one unit), and immediately withdraws, leaving with a share of Bob's slippage. The result is that Carol pockets value that should have gone to Alice and any other LP who was there when Bob traded and her round trip is risk-free.

Recommendation

Consider minting LP shares in proportion to the existing share supply so a deposit always receives shares matching its true fraction of the pool, no matter how much extra value the pool has built up.

Resolution

resolved in

6.5 Pool swaps have no slippage protection, exposing direct callers to forced slippage

The pool exposes two swap entry points, swapFromAsset(...) and swapFromUSDZ(...). Both are external and permissionless, and neither takes a minimum-output or deadline argument, so a caller receives whatever the curve returns at execution time with no floor on the result:

function swapFromAsset(uint256 amountIn)
    external override whenNotPaused returns (uint256 amountOut)
{
    // @audit-issue No minAmountOut or deadline, so the caller cannot bound the output.
    // ...
}

The only slippage protection in the system lives one layer up, in the router, which reverts when the final output is below the caller's limit:

if (amountOut < minAmountOut) revert InsufficientOutput();

So router users are protected, but anyone who calls a pool directly has none. This matters because a pool need not be near balance when they trade. Near balance the pool prices at a flat 1:1, but once it is imbalanced it prices on the StableSwap curve and swaps take real slippage, and that imbalanced state can be forced permissionlessly. An attacker can push a target pool onto the StableSwap curve without even holding that pool's assets: they mint USDZ against a different asset's reserve, then swap that USDZ into the target pool to drain it and leave it imbalanced. A direct caller who then swaps against that pool receives a degraded rate, and can be sandwiched, the attacker deepening the imbalance before the victim's swap and unwinding it after, because the pool applies no output check to stop it.

Router users are shielded because the router's minAmountOut makes their transaction revert instead, so the exposure is specific to direct pool interaction rather than the protocol's main entry point, which is why this is rated Low.

Recommendation

Consider adding a minAmountOut (and ideally a deadline) argument to swapFromAsset(...) and swapFromUSDZ(...) so a direct caller can bound the price they accept, or restricting the pool swap entry points so that only the router can call them. Either approach removes the unprotected direct-swap path.

Resolution

resolved in

6.6 Mint and redeem fees are global and cannot be set per asset

The protocol charges a fee on every mint and every redeem. Both fees are single global values set by the admin:

uint256 public mintFeeBPS;
uint256 public redeemFeeBPS;

Their setters take only a new fee value, with no asset parameter, so one number applies to every collateral at once and there is no way to charge a different mint or redeem fee for a single asset:

function setMintFee(uint256 newFeeBPS) external onlyAdmin {
    if (newFeeBPS > MAX_FEE_BPS) revert InvalidFee();
    // @audit-issue One global mint fee for all assets; no per-asset dimension.
    mintFeeBPS = newFeeBPS;
    emit MintFeeUpdated(newFeeBPS);
}

A single global fee is fine only while every collateral sits exactly at $1. In practice the supported stablecoins drift around their peg all the time, and because USDZ is minted and redeemed against them at a fixed 1:1, holding USDZ itself at $1 requires continuously steering flow per asset: encouraging mints of the assets trading at or above peg, and discouraging mints of, while encouraging redemptions of, any asset trading below it. The correct fee response is therefore per-asset and points in opposite directions on the two paths. On the mint side the fee on a deviating, cheaper asset should be raised while the others stay low, so that bringing weak collateral in for full-value USDZ is discouraged without choking honest minting of the assets holding their peg. On the redeem side it is the reverse: the fee on the deviating asset should be lowered while the others are raised, so that holders are encouraged to redeem the weak asset out of the reserve and discouraged from pulling out the good collateral.

A single global fee for each path cannot express any of this. Raising the global mint fee to slow the intake of a weak asset also taxes minting of every healthy asset, and raising the global redeem fee to protect the good collateral also discourages redeeming the weak asset, which is exactly the action worth encouraging. So the protocol cannot nudge flow toward the assets holding their peg and away from those drifting off it; its only fee lever is a blunt, all-asset one that cannot be aimed where it is needed. A full depeg is just the extreme case of a deviation these fees already cannot steer.

Recommendation

Consider making the mint and redeem fees per-asset so that friction can be adjusted on a deviating asset without affecting the others.

Resolution

resolved in

6.7 The redeem fee accrues as reserve surplus and can be locked below the k/2 floor

The mint fee is booked as claimable revenue: mintUSDZ(...) keeps the fee in the StabilizerAMM under accumulatedFees[asset] and it is withdrawn through claimProtocolFees(...). The redeem fee is not booked anywhere. redeemUSDZ(...) charges the fee in USDZ but burns the full input while paying out only the post-fee asset, so the fee's collateral is never removed from the reserve.

uint256 fee = (amountUSDZIn * redeemFeeBPS) / BPS_DENOMINATOR;
amountAssetOut = (amountUSDZIn - fee) / scaleFactor;
// ...
// @audit-issue The full input is burned but only the post-fee asset is paid out, so the
// @audit-issue fee's collateral is left mixed in the reserve, untracked.
IUSDZ(usdz).burn(address(this), amountUSDZIn);
IReserveHolder(reserveHolder).withdrawFromAdapter(msg.sender, asset, amountAssetOut);

The fee therefore accrues as over-collateralization, E = totalReserves() - backedSupply(), mixed in with reserves[asset]. The only way to collect it is rescueExcessCollateral(...), which refuses to drop the reserve below the pool's k/2 floor.

uint256 k = IPool(pool).totalLiquidity();
uint256 postReserve = reserves[asset] - amount;
// ...
// @audit-issue Recovery reverts if it would leave the reserve below the pool's k/2 floor.
if (normPostReserve < k / 2) revert LocalSafetyViolation();

The same reserve figure gates liquidity additions: addLiquidityX(...) and addLiquidityY(...) call checkLocalSafety(...), which passes as long as reserves[asset] covers newK/2. Because the accrued fee inflates reserves[asset], a deposit can raise the pool's k until k/2 equals the reserve, leaving the fee pinned below the floor and unrecoverable.

For example, on the USDS pool seeded at 100,000 / 100,000 (reserve at its 100,000 floor): minting a buffer and redeeming 20,000 USDZ at a 10% fee leaves 2,000 of fee as excess (reserve 102,000, so it is rescuable). Adding the maximum liquidity the reserve allows (2,000 per side) makes the pool 102,000 / 102,000, so k/2 becomes 102,000, exactly the reserve. rescueExcessCollateral(...) then reverts for any amount and the 2,000 fee is stranded. It becomes recoverable again only if that liquidity is removed, which lowers k. The amount at stake is bounded by the accrued fees and no third party gains, so there is no fund loss, but the protocol can be blocked from collecting its own fee revenue.

The same mixing also feeds swap pricing: while the fee sits in reserves[asset], the hybrid swap math counts it as rebalancing capacity, so the pool keeps quoting 1:1 instead of falling to the StableSwap curve as it should through market activity, pricing against more capacity than its true backing provides.

Recommendation

Consider booking the redeem fee in a dedicated accumulator outside reserves[asset], the way the mint fee uses accumulatedFees, so it is tracked, claimable through the normal claimProtocolFees(...) path, and never subject to a pool's k/2 floor.

Resolution

resolved in

6.8 Missing lock period lets an LP front-run a large swap and capture its fees risk-free

The trading fee from a swap is credited to whoever holds LP shares at the instant of that swap.

if (lpFee > 0) {
    feeReserveX += lpFee;
    // @audit Credited by current share of totalSupply, to whoever holds shares now.
    if (totalSupply > 0) accFeePerShareX += (lpFee * ACC_PRECISION) / totalSupply;
}

There is no minimum holding period and no lock: addLiquidityX(...) and addLiquidityY(...) mint shares immediately, and removeLiquidity(...) burns them immediately. So anyone who sees a large swap in the mempool can, in the same block, add liquidity just before it, take a proportional share of that swap's fee, then remove the liquidity and claim.

Because the pool is constant-sum, this is risk-free: add and remove are exactly proportional and there is no impermanent loss, so the actor recovers their principal intact and keeps the fee. They supply liquidity for a single block yet earn the same per-share fee as LPs who keep liquidity in the pool, diluting the standing LPs' yield. This is the standard just-in-time liquidity dynamic, worth noting here mainly because the constant-sum design removes the price risk that normally limits it on other AMMs. No protocol or user funds are lost. The effect is a redistribution of fee income away from passive LPs.

Recommendation

Consider discouraging just-in-time liquidity, for example by requiring a minimum holding period before freshly added shares accrue fees, or by locking newly minted LP shares for a short window before they can be removed.

Resolution

resolved in

6.9 Redeem fees aren't tracked and affect adapter solvency checks

The StabilizerAMM implements the functions mintUSDZ and redeemUSDZ that allow a user to exchange supported stablecoin assets for USDZ, or vice versa. Both functions support a fee mechanism, with the fee amount being limited to a maximum of 10% of the amount being exchanged. The fee mechanism for the mint flow and redeem flow are different in how they track the accumulated fees, and where the fee asset is stored. To describe the different behaviors, let's assume a scenario with a 1% fee on both mint and redeem, with a user who owns 1000 USDC.

For the mint flow, a user calls mintUSDZ and provides their 1000 USDC, of which 1% will be treated as mint fees. The 10 USDC in mint fees will stay in custody of the StabilizerAMM contract, while the 990 USDC will be transferred to the adapter via a depositToAdapter call. The 10 USDC in fees on the AMM contract are accounted for in the accumulatedFees mapping, while the 990 USDC in the adapter is tracked in the reserves mapping. The user then receives 990 USDZ.

function mintUSDZ(address asset, uint256 amountAssetIn) ... {
    // ...
    // Transfer in 1000 USDC
    IERC20(asset).safeTransferFrom(msg.sender, address(this), amountAssetIn);
    // Send out 990 USDC to adapter
    IERC20(asset).forceApprove(reserveHolder, amountAssetIn - fee);
    IReserveHolder(reserveHolder).depositToAdapter(address(this), asset, amountAssetIn - fee);
    // Account for the remaining 10 USDC in `accumulatedFees`
    accumulatedFees[asset] += fee;
    IUSDZ(usdz).mint(msg.sender, amountUSDZOut);
    // ...
}

For the redeem flow, a user calls redeemUSDZ and following the prior example, they want to exchange their 990 USDZ for USDC. The fee of 1% will mean that 9USDC (not 10 due to integer division) is treated as fees, and the user is entitled to receive 981 USDC. The 990 USDZ is burned and 981 USDC is withdrawn from the adapter, then passed to the user. The remaining 9 USDC which represent the withdrawal fee is left in the adapter. No updates to the accumulatedFees mapping is done and the redeem USDC fee is stored on the adapter which is different to the mint flow which stores the fee asset in the AMM.

function redeemUSDZ(address asset, uint256 amountUSDZIn) ... {
    // ...
    // Determine withdrawal amount after fee
    uint256 amountUSDZAfterFee = amountUSDZIn - fee;
    amountAssetOut = amountUSDZAfterFee / scaleFactor;
    // Burn the 990 USDZ
    IReserveHolder(reserveHolder).assertLocalSafety(pool, amountAssetOut);
    IERC20(usdz).safeTransferFrom(msg.sender, address(this), amountUSDZIn);
    IUSDZ(usdz).burn(address(this), amountUSDZIn);
    // Withdraw the 981 (postfee) USDC from the reserve, leaving 9 USDC in reserve as fee
    IReserveHolder(reserveHolder).withdrawFromAdapter(msg.sender, asset, amountAssetOut);
    // ...
}

Since the redeem fees remain in the adapter, they are still accounted for in the reserves mapping in the adapter. The only way to collect it is rescueExcessCollateral(...), which refuses to drop the reserve below the pool's k/2 floor.

uint256 k = IPool(pool).totalLiquidity();
uint256 postReserve = reserves[asset] - amount;
// ...
// @audit-issue Recovery reverts if it would leave the reserve below the pool's k/2 floor.
if (normPostReserve < k / 2) revert LocalSafetyViolation();

The same reserve figure gates liquidity additions: addLiquidityX(...) and addLiquidityY(...) call checkLocalSafety(...), which passes as long as reserves[asset] covers newK/2. Because the accrued fee inflates reserves[asset], a deposit can raise the pool's k until k/2 equals the reserve, leaving the fee pinned below the floor and unrecoverable.

For example, on a USDS pool seeded at 100,000 / 100,000 (reserve at its 100,000 floor): minting a buffer and redeeming 20,000 USDZ at a 10% fee leaves 2,000 of fee as excess (reserve 102,000, so it is rescuable). Adding the maximum liquidity the reserve allows (2,000 per side) makes the pool 102,000 / 102,000, so k/2 becomes 102,000, exactly the reserve. rescueExcessCollateral(...) then reverts for any amount and the 2,000 fee is stranded. It becomes recoverable again only if that liquidity is removed, which lowers k. The amount at stake is bounded by the accrued fees and no third party gains, so there is no fund loss, but the protocol can be blocked from collecting its own fee revenue.

The same mixing also feeds swap pricing: while the fee sits in reserves[asset], the hybrid swap math counts it as rebalancing capacity, so the pool keeps quoting 1:1 instead of falling to the StableSwap curve as it should through market activity, pricing against more capacity than its true backing provides.

Recommendation

Consider storing and tracking redeem fees in the same way as mint fees, by withdrawing the entire redeem amount of USDC from the adapter and then using the accumulatedFees mapping on redeem.

Resolution

resolved in

6.10 The AdapterUSDS contract overrides balance() to return the live token balance, diverging from the other adapters

All four adapters inherit AdapterBase, whose balance() returns the internal trackedBalance. Three adapters (AdapterUSDC, AdapterUSDT, AdapterPYUSD) use this default; AdapterUSDS alone overrides it to return the live on-chain balance.

// AdapterUSDS.sol
function balance() external view override returns (uint256) {
    return IERC20(underlying).balanceOf(address(this));
}

// AdapterBase.sol
function balance() external view virtual override returns (uint256) {
    return trackedBalance;
}

Recommendation

Consider making the balance() semantics uniform across all adapters, or documenting explicitly why AdapterUSDS must expose the live balance while the others expose the tracked balance, and defining a single authoritative balance source to avoid future integrations mixing tracked and live balances.

Resolution

resolved in

6.11 The guardian can halt pool's swaps through the uncapped emergency fee

Two roles can act on a pool. The admin can halt it with pause(), which is onlyAdmin. The guardian is a separate, lower-privilege role whose power is setEmergencyDepegFee(...), meant to raise a pool's swap fee temporarily during a depeg. Unlike every other fee setter (setMintFee, setRedeemFee, and setTradingFee all cap at 1000 BPS), the emergency fee has no upper bound.

function setEmergencyDepegFee(uint256 newFeeBPS) external onlyAMM {
    emergencyDepegFeeBPS = newFeeBPS;
    emit EmergencyDepegFeeSet(newFeeBPS);
}

That value becomes the effective fee on every swap (feeAmount = amountIn * getEffectiveFee() / BPS_DENOMINATOR, then netInput = amountIn - feeAmount), so an uncapped, guardian-settable fee gives the guardian pausing power as at 10000 BPS (100%) netInput is 0 and every swap reverts with ZeroOutput; above 10000 the subtraction underflows and reverts. swapFromAsset(...), swapFromUSDZ(...), and every router route through the pool stop working. This is the same effect as pause(), reached by the guardian, even though pausing is onlyAdmin.

Recommendation

Consider capping emergencyDepegFeeBPS in the setter in order to prevent the scenario or consider documenting that the guardian should be able to pause.

Resolution

acknowledged, guardian already has broad responsibility during a depeg so the halt power was kept; but added a 100% cap as a guard against human error in commit a55aeca7237aaff32bb88feea62c773d0bea0b8f

6.12 The AMM and pool pause switches are misaligned in both directions

The AMM, each pool, USDZ, and the reserve holder each have their own pause switch. Two gaps break the isolation.

First, pausing the AMM stops all pool swaps. Every pool swap ends by calling rebalance(...) on the AMM, and rebalance(...) is whenNotPaused, so pausing the AMM (for example to halt mint/redeem during an incident) makes every swapFromAsset(...), swapFromUSDZ(...), and router swap revert, even though the pools were never paused.

// @audit-issue rebalance is whenNotPaused, so an AMM pause reverts every pool swap.
IStabilizerAMM(stabilizerAMM).rebalance(address(this));

Second, pausing a pool does not stop rebalancing into it. The user-facing swap functions check the pool's pause, but the AMM-only functions the rebalancer uses do not, and rebalance(...) never checks the pool's pause either.

// @audit-issue No whenNotPaused, unlike the user-facing swap functions.
function ammSwapFromAsset(...) external override onlyAMM returns (uint256 amountOut) {
    // ...
}

Since rebalance(...) is permissionless, anyone can call it on a paused pool and move its reserves (pulling collateral in or out). The rebalance only nudges the pool toward balance and pays the caller nothing, so by itself it takes no funds; the concern is that a pool the admin paused (say, to contain a separate bug) is not actually frozen. Pausing the pool's adapter or the AMM does close this path.

Recommendation

Consider aligning the two pause switches: do not gate rebalance(...) on the AMM pause (or document that an AMM pause is meant to halt swaps too), and gate the AMM-only pool functions or rebalance(...) on the target pool's pause so a paused pool is fully frozen.

Resolution

resolved in

6.13 Redeeming a small USDZ amount burns USDZ but returns zero asset for low-decimal collateral

The redeemUSDZ(...) function lets a holder burn USDZ (18 decimals) and receive the chosen collateral. For collateral with fewer than 18 decimals (USDC, USDT, PYUSD are 6 on mainnet) the USDZ amount is divided by 10 ** (18 - assetDecimals) to convert to asset units, and the full input is burned.

uint256 scaleFactor = 10 ** (18 - assetDecimals);
uint256 fee = (amountUSDZIn * redeemFeeBPS) / BPS_DENOMINATOR;
uint256 amountUSDZAfterFee = amountUSDZIn - fee;
// @audit-issue For 6-dec assets, any amountUSDZAfterFee < 1e12 floors amountAssetOut to 0.
amountAssetOut = amountUSDZAfterFee / scaleFactor;
// ...
IUSDZ(usdz).burn(address(this), amountUSDZIn);
IReserveHolder(reserveHolder).withdrawFromAdapter(msg.sender, asset, amountAssetOut);

There is no check that amountAssetOut 0. If a user redeems any amountUSDZIn whose post-fee value is below one asset unit (below 1e12 for a 6-decimal asset), amountAssetOut floors to 0, yet the entire amountUSDZIn is pulled in and burned and the withdrawal transfers 0 tokens. The user destroys their USDZ and receives nothing; the burned value becomes silent over-collateralization for the protocol.

Recommendation

Consider reverting when the computed amountAssetOut is zero (as the swap paths already do with ZeroOutput), so redemptions that would return nothing fail loudly instead of burning USDZ for no asset.

Resolution

resolved in

6.14 Unnecessary transfer before burn during redeem

When redeeming USDZ for an underlying asset in the StabilizerAMM, user's funds are transferred from their own address to the AMM contract, and then they are burned. The AMM-only burn function in the USDZ contract allows the AMM to burn funds from any address, not necessarily just funds belonging to itself. This makes the transferFrom call to move assets from the caller to the AMM unnecessary, costing additional gas.

function redeemUSDZ(...) ... returns (...) {
    // ...
    IERC20(usdz).safeTransferFrom(msg.sender, address(this), amountUSDZIn);
    IUSDZ(usdz).burn(address(this), amountUSDZIn);
    // ...
}

Recommendation

Consider burning assets directly from the user to reduce gas costs.

Resolution

resolved in

6.15 The setGuardian(...) function emits the wrong value for the old guardian

The StabilizerAMM emits GuardianTransferred(oldGuardian, newGuardian) when the guardian changes and AdminTransferred(oldAdmin, newAdmin) when the admin changes; both share "old value, new value" semantics.

function transferAdmin(address newAdmin) external onlyAdmin {
    if (newAdmin == address(0)) revert ZeroAddress();
    emit AdminTransferred(admin, newAdmin);
    admin = newAdmin;
}

The setGuardian(...) function does the opposite: it overwrites guardian first and then emits, reading the already-updated guardian as the "old" argument.

function setGuardian(address newGuardian) external onlyAdmin {
    guardian = newGuardian;
    // @audit-issue guardian already equals newGuardian, so old value is emitted as new.
    emit GuardianTransferred(guardian, newGuardian);
}

As a result the GuardianTransferred event always reports the new guardian in both fields, so off-chain indexers and monitoring can never reconstruct the previous guardian from logs.

Recommendation

Consider emitting the GuardianTransferred event before the state assignment, matching the ordering already used by transferAdmin(...).

Resolution

resolved in

6.16 Unused function updateReserve

The ReserveHolder contract has a function updateReserve which can be used to manually adjust the reserves of a given asset. This function is only accessible to the AMM contract, however, the AMM contract has no logic which calls this function. As a result, the function is uncallable and unused.

// Only callable by AMM, but AMM cannot call
function updateReserve(...) external override onlyAMM {
    // ...
}

Recommendation

Consider removing the unused function.

Resolution

resolved in

6.17 Unnecessary double declaration of pool asset

In the function rebalance on the StabilizerAMM the pool address is passed as an argument, from which the pool asset can be derived. This function queries the same pool asset twice, under two different variable names asset and _asset. Since they both hold the same information, one of these declarations can be removed.

function rebalance(address pool) external override whenNotPaused noReentrantRebalance {
    address _asset = IPool(pool).asset(); // Asset declaration

    if (poolForAsset[_asset] != pool) revert AssetNotSupported();
    (uint256 delta, bool xGreater) = computeDelta(pool);
    if (delta == 0) return;

    address asset = IPool(pool).asset(); // Asset declaration
    // ...
}

Recommendation

Consider removing one of these duplicate declarations.

Resolution

resolved in

6.18 The USDZ contract should inherit Openzeppelin ERC20 logic

The USDZ contract is an ERC20 token with additional features such as upgradeability, pause/unpause, and the mint/burn flows being accessible to the StabilizerAMM. The underlying ERC20 token logic (such as transfers, allowances, balance checks, etc) has been implemented by the Stabilizer team rather than importing from the OpenZeppelin ERC20 library. A reference implementation should always be imported where possible, especially in the case of heavily standardised EIPs such as ERC20. The custom implementation deviates from the standard in the following ways:

• The transferFrom function emits an Approval event on every call, since it internally calls _approve which emits the event. This excessive event emission when an actual approval didn't occur may affect offchain infrastructure for protocols which integrate with the USDZ token.

• An allowance of uint256.max does not give an infinite allowance. Executing a transferFrom will always reduce the allowance of the caller. While the ERC20 specification doesn't state that uint256.max should be treated as an infinite allowance, it is extremely common in other implementations. Other protocols which integrate with this token may have unexpected behavior when an infinite allowance assumption breaks.

• The errors returned by the USDZ token upon a call failure have a different naming standard, and lack context such as the involved addresses and token amounts. For example: InsufficientBalance vs ERC20InsufficientBalance(sender, balance, needed). Offchain infrastructure, wallets, or block explorers may be designed to detect the more common OpenZeppelin errors and present them in an easier to understand way to the user.

The OpenZeppelin ERC20 library also includes an upgradeable variant ERC20Upgradeable which supports the USDZ design approach of using a UUPS proxy.

Recommendation

Consider reimplementing the USDZ contract to inherit ERC20Upgradeable and then use function overrides to add the additional features such as pausing and AMM-only minting/burning.

Resolution

resolved in