KatanaPerps A-1

In ChainlinkDataStreamsIndexPriceAdapter, the validFromTimestamp from Chainlink's ReportV3 is in seconds, but it is assigned directly to timestampInMs without conversion:

return
IndexPrice({
    baseAssetSymbol: market.baseAssetSymbol,
    timestampInMs: SafeCast.toUint64(report.validFromTimestamp),
    price: priceInPips
});

Reference: ChainlinkDataStreamsIndexPriceAdapter.sol#L195-L200

As a result, timestampInMs will contain an incorrect value, leading to unexpected behavior in any logic that relies on it.

Remediation to Consider

Multiply by 1000: timestampInMs = validFromTimestamp * 1000

The ChainlinkDataStreamsIndexPriceAdapter’s validateIndexPricePayload doesn’t validate key fields from the ReportV3 struct, such as:

• report.expiresAt > block.timestamp
• report.price > 0

Similar validation checks are missing in the RedStoneIndexPriceAdapter.

As a result, expired or invalid price reports could be accepted, leading to incorrect index prices being used in the protocol

Remediation to Consider

Add meaningful validation checks for both adapters.

The ChainlinkDataStreamsIndexPriceAdapter does not handle verification fees, as noted in the comments that Katana does not currently have a feeManager set:

// Katana does not have a FeeManager and no funding is needed to verify
// reports. Validate no FeeManager is set as a sanity check
require(verifier.s_feeManager() == address(0), "FeeManager not supported");

Reference: ChainlinkDataStreamsIndexPriceAdapter.sol#L183-L185

If Chainlink enables fees in the future, the adapter will fail to verify reports.

Remediation to Consider

Two options:

1. Redeploy when needed: Keep current implementation and deploy a new adapter with fee support if Chainlink enables fees. Acceptable if potential downtime and governance delay are tolerable.
2. Implement fee handling now: Adapt the implementation to handle fees as shown in https://docs.chain.link/data-streams/reference/interfaces/ifeemanger. This requires:
   • A mechanism to fund the contract
   • A withdraw function to recover tokens
   • Optionally, support for both native and ERC20 fee payment options

The RedStoneIndexPriceAdapter assumes all RedStone price feeds use 8 decimals, but this is not guaranteed for all feeds. As a result, if a feed with non-standard decimals is added, the price will be incorrectly scaled, leading to wrong index prices.

Remediation to Consider

Either:

• Make decimals configurable per market in the RedStoneMarket struct (as done in ChainlinkDataStreamsIndexPriceAdapter), or
• Document and enforce that only standard 8-decimal feeds are supported

When compose() reverts entirely, the user's tokens go to owner(). There are scenarios where the destinationWallet could be successfully decoded. Consider the case where vbUSDC.deposit inside _forwardDeposit reverts due to a paused vault. In this case all user funds from bridging attempts would go to the owner, causing temporary loss of custody and increasing operational burden since affected users need to be identified and refunded.

Remediation to Consider

Trying to decode destinationWallet to reduce operational burden and avoid temporary loss of custody.

The ExchangeLayerZeroAdapter_v1.setMinimumWithdrawQuantityMultiplier enforces bounds of [90%, 100%]. But setComposeParameters sets the same variable without any bounds check. This also applies during deployment, since the constructor routes through setComposeParameters. An accidental value of 0 disables slippage protection entirely; a value above 100% makes all withdrawals fail.

Remediation to Consider

Add the boundary checks <= MAX_MINIMUM_WITHDRAW_QUANTITY_MULTIPLIER and >= MIN_MINIMUM_WITHDRAW_QUANTITY_MULTIPLIER to the setComposeParameters function.

In _forwardWithdrawal, previewRedeem is called to compute usdcAmount, which is then used for the Stargate send and the Ethereum direct transfer. However, the actual redeem call may return a slightly different (higher) amount. Per EIP-4626, previewRedeem "MUST return as close to and no more than the exact amount of assets that would be withdrawn in a redeem call in the same transaction." This means redeem can return ≥ previewRedeem. Aa a result, any dust difference between redeem's actual return and previewRedeem's estimate accumulates in the forwarder contract.

Remediation to Consider

Use the amount returned by the actual redeem call instead of previewRedeem for subsequent transfers.

The ExchangeLayerZeroAdapter_v1.withdrawNativeAsset correctly uses .call{value: quantity}(""), but the StargateForwarder uses .transfer() which forwards only 2300 gas. This will fail if the destination is a contract with a non-trivial receive() (e.g., a multisig). Since this is admin-only, impact is limited to operational inconvenience.

Remediation to Consider

Use .call instead of transfer.

In BalanceTracking, the balance migration logic in loadBalanceStructAndMigrateIfNeeded copies balance data from a source Exchange but omits the managedAccountProvider field. This is intentional and works for migration from an old exchange (without managedAccountProvider support) to a new exchange. However, if a future Exchange upgrade migrates from a version that already supports managedAccountProvider, all managed account associations would be lost.

Document this limitation for future upgrade planning. When migrating from an Exchange that supports managed accounts, the migration logic must be updated accordingly.