PSM Adapter

The adapter integration documents that Securitize must update ExternalAssetProvider.availableAsset() to delegate to EthenaPSMAdapter.availableAsset(), but there is no equivalent sell-side liquidity view for ExternalLiquidityProvider.availableLiquidity(). In the Securitize ELP implementation, availableLiquidity() resolves the liquidity custodian through getLiquidityCustodian()/_custodianOf() and, when the external provider is EthenaPSMAdapter, this reports USDC.balanceOf(address(adapter)).

That value does not represent redeem-side executable liquidity. Sell output is sourced by PSM.swap() from the PSM collateral send custodian and is bounded by custodian balance, custodian allowance, and sell-direction PSM caps. As a result, availableLiquidity() can underreport liquidity when the adapter holds no USDC, or overreport liquidity when USDC fees temporarily sit on the adapter before sweep().

This does not directly block redemptions because ExternalLiquidityProvider.supplyExactIn() does not use availableLiquidity() as an execution precheck, but frontends or off-chain integrators using the public off-ramp liquidity view may display or act on stale liquidity data.

Consider adding a sell-direction liquidity view to EthenaPSMAdapter that accounts for collateral send custodian balance/allowance and swapForCollateral PSM caps, and have Securitize delegate ExternalLiquidityProvider.availableLiquidity() to it. Alternatively, explicitly document that availableLiquidity() is not meaningful for this adapter integration and should not be used for off-ramp capacity decisions.

In swapExactIn(), the adapter checks amountIn < PSM_MIN_AMOUNT_IN before resolving the swap direction with _resolveDirection(). As a result, both collateral-to-asset and asset-to-collateral swaps revert with the same AmountInBelowPsmMinimum error, instead of preserving the PSM’s direction-specific distinction between InvalidCollateralAmount and InvalidAssetAmount.

Consider whether the adapter should keep the current generic AmountInBelowPsmMinimum error for simplicity, or introduce direction-specific low-amount errors.

The README documents the following key invariant.

Key invariant: the adapter always sets beneficiary: address(this) so it can measure the balance delta (received == amountOut) before forwarding funds to the ramp.

While this is technically true, there is another reason why beneficiary must be set to the adapter and it is because the benefactor of the order is the adapter as well.

PSM._validateBenefactor() reverts if the benefactor and the beneficiary differ, unless the beneficiary is approved for the given benefactor.

        if (order.benefactor != order.beneficiary && !_benefactorState.config.approvedBeneficiaries[order.beneficiary])
        {
            revert BeneficiaryNotApproved(order.beneficiary);
        }

Because the adapter has no way to call setApprovedBeneficiary(), this check would have always reverted if the two didn't match.

Add this requirement to the key invariant documentation.

EthenaPSMAdapter.swapExactIn() does not identify or authorize the underlying investor. On the Securitize public on-ramp path, investor access is gated by the BUIDL/Securitize registry and token compliance checks rather than a ramp-specific allowlist. Therefore, any token-level eligible investor can buy or sell through the configured ramp path. The downstream PSM order sets both benefactor and beneficiary to address(this), so all ramp users consume the same adapter-level benefactor caps rather than separate per-investor caps.

Consider documenting this trust boundary explicitly. If shared token-level investor eligibility is intended, no code change is required. If Ethena wants granular per-investor or per-ramp access control, add authorization or limits in the Securitize ramp/provider path.

EthenaPSMAdapter.availableAsset() returns the remaining BUIDL capacity without considering PSM_MIN_AMOUNT_IN. If the amount of BUIDL can be received by paying USDC below the floor, availableAsset() will return that BUIDL amount, even though it cannot be executed.

This inconsistency affects only view paths, since EAP.supplyExactIn() calls previewSwapExactIn() before availableAsset(), and previewSwapExactIn() reverts if the provided amount is below the floor.

If this is fine, acknowledge the finding. If not, return 0 in case the available variable is below the minimum executable amount.

  uint256 minExecutableOut = _pegAmountOut(uint128(PSM_MIN_AMOUNT_IN), true);
  if (available < minExecutableOut) return 0;

EthenaPSMAdapter.setPsm() rotates the configured PSM without first sweeping token balances held by the adapter. EthenaPSMAdapter.sweep() always reads the current PSM and sends pending USDC/BUIDL balances to the current PSM custodian addresses.

As a result, if USDC ramp fees or stray BUIDL are present on the adapter when setPsm() is called, a later sweep() sends those pre-rotation balances to the new PSM custodians rather than the custodians configured on the previous PSM.

Document that operators should call sweep() before setPsm() when balances should be attributed to the previous PSM custodian set.

The previewSwapExactIn() documentation states that the preview may overestimate when the PSM oracle price deviates below pegPrice. This only describes the buy-direction case.

Since previewSwapExactIn() replicates only the peg path while swapExactIn() uses psm.getQuote() and returns the lower of the peg path and oracle path, overestimation for sells can happen whenever the oracle path is lower than the peg path. Whether this occurs below or above pegPrice depends on direction: below pegPrice for buys, and above pegPrice for sells.

Additionally, the previewSwapExactIn and swapExactIn() documentations refers to tokenIn and tokenOut while the actual parameters are named assetIn and assetOut.

Consider updating the previewSwapExactIn() documentation to state that overestimation can occur whenever the oracle path wins, with the side of peg depending on swap direction. Also replace tokenIn/tokenOut with assetIn/assetOut.

The README states that amounts below PSM_MIN_AMOUNT_IN revert in collateral-token units. However, EthenaPSMAdapter.swapExactIn() applies PSM_MIN_AMOUNT_IN to amountIn before resolving the swap direction, so the floor is denominated in the input token’s units. For sells, this means the threshold is in asset decimals, not collateral decimals.

Update the README to state that PSM_MIN_AMOUNT_IN is enforced in input-token units before direction resolution.