Superstate A-4

A new feature in the Redemption contract introduces a redemption fee. The redemption fee is initially set through the initializer, can be updated using setRedemptionFee(), and can be calculated using calculateFee(). In addition, in the calculateUstbIn(), the redemption fee is considered when calculating how much USTB token the user may need to provide to obtain the desired USDC amount.

However, the redemption process flow, which includes RedemptionIdle.redeem() and RedemptionYield.redeem() together with underlying Redemption.calculateUsdcOut(), does not consider the redemption fee at all. As a result, a redemption fee would not be charged in contradiction to the system specification and contract configuration.

Remediations to Consider

• Apply redemption fee in Redemption.calculateUsdcOut().

In the SuperstateToken contract, a new feature allows an end user to mint superstate tokens using subscribe(). This function takes in stablecoins and mints SuperstateToken in the proper amount for the msg.sender, depending on the current Net Asset Value per Share. SuperstateToken, part of a regulation-compliant system, has extra token access constraints that allow only preapproved addresses to obtain tokens. These constraints are enforced in the internal mint wrapper function _mintLogic(). This function is used by mint() and bulkMint() owner-accessible functions.

function _mintLogic(address dst, uint256 amount) internal {
    if (!hasSufficientPermissions(dst)) revert InsufficientPermissions();

    _mint(dst, amount);
    emit Mint(msg.sender, dst, amount);
}

However, subscribe(), which is publicly accessible, does not call _mintLogic() but calls directly the underlying _mint() function, which skips permission checking. As a result, non-approved addresses may obtain SuperstateToken in contradiction with system specifications.

Remediations to Consider

• Replace in subscribe() call to _mint() with a call to the _mintLogic().

In the Redemption contract, calculateUstbIn() function calculates how much superstate token should be provided to obtain the desired amount of USDC tokens in return. As part of the calculation, the redemption fee is also considered.

function calculateUstbIn(uint256 usdcOutAmount)
  public
  view
  returns (uint256 ustbInAmount, uint256 usdPerUstbChainlinkRaw)
  {
      if (usdcOutAmount == 0) revert BadArgs();

      **uint256 usdcOutAmountWithFee = usdcOutAmount + calculateFee(usdcOutAmount);**

      (bool isBadData,, uint256 usdPerUstbChainlinkRaw_) = _getChainlinkPrice();
      if (isBadData) revert BadChainlinkData();

      usdPerUstbChainlinkRaw = usdPerUstbChainlinkRaw_;

      ustbInAmount = (usdcOutAmountWithFee * CHAINLINK_FEED_PRECISION * SUPERSTATE_TOKEN_PRECISION)
          / (usdPerUstbChainlinkRaw * USDC_PRECISION);
  }

However, the redemption fee is incorrectly calculated. Currently, a fee is applied to the net amount of USDC instead of the gross amount of USDC. As a result, the final result underestimates the redemption fee amount. In addition, when invoking redemption with the result of calculateUstbIn(), the user will receive less than the desired usdcOutAmount.

Remediations to Consider

• Update calculateUstbIn() implementation to apply fee on gross USDC amount.

In the Redemption contract, the calculateUstbIn() function calculates the necessary superstate token amount to be provided to receive the desired amount of USDC.

ustbInAmount = (usdcOutAmountWithFee * CHAINLINK_FEED_PRECISION * SUPERSTATE_TOKEN_PRECISION)
    / (usdPerUstbChainlinkRaw * USDC_PRECISION);

However, due to integer division and rounding ustbInAmount may underestimate the necessary superstate token amount to be provided to retrieve the desired amount of USDC. As a result, users may receive less than they initially asked for. On the user side, this would require a more complex integration implementation to handle this edge case.

Remediations to Consider

• Implement rounding up in calculateUstbIn() so that the user receives the desired amount of USDC when redeeming.

In the SuperstateToken contract, the _requireOnchainSubscriptionsEnabled() function verifies necessary dependencies for enabling subscriptions. This includes verifying that the superstateOracle, which provides real-time NAVS price, is configured and set.

function _requireOnchainSubscriptionsEnabled() internal view {
    if (superstateOracle == address(0)) revert OnchainSubscriptionsDisabled();
}

However, this check skips to validate that maximumOracleDelay is also set and has a value greater than 0. In cases when maximumOracleDelay is not configured or has a default value of 0, subscriptions will also not work, as Oracle data will always be treated as stale data.

Remediations to Consider

• Include in _requireOnchainSubscriptionsEnabled() check that maximumOracleDelay is appropriately configured.

The latest, version 2 of Allowlist system component, diverges significantly in the implementation from the previous version. Storage layout, permission handling, and function interface differ. In addition, v2 of Allowlist is upgradeable, while version 1 wasn’t.

However, version 2 of Allowlist tries to maintain backward interface compatibility even though it isn’t an end user-facing system component but rather a wrapped component used by the Superstate token contract and by the internal management system.

Due to the above, maintaining backward compatibility seems unnecessary. Consider removing unnecessary Allowlist version 1 features and code for the benefit of a more clean version 2 Allowlist implementation.

In the Redemption contract, the redemptionFee is defined as uint96. If, in the next upgrade, a new variable is smaller than uint256 and can fit in the same slot, it may not require an update to the storage gap. However, if it is bigger, it will require a new slot and storage gap update.

To reduce potential storage layout slot misalignment in future upgrades, consider using uint256 for redemptionFee instead of uint96.

The Redemption and Allowlist contracts inherit from OwnableUpgredeable. As a result, they contain the unnecessary functionality of renounceOwnership().

Consider overriding it and reverting whenever it is called so it is clear that it is not supported.

Consider updating natspec documentation in the following cases:

• In the SuperstateToken, the natspec for the setOracle() function refers to the old, now obsolete, updateOracle() function. Consider updating the natspec to keep it up to date.
• In the Redemption contract, withdraw() is an abstract function, and withdrawToSweepDestination() relies on it. Since these functions are critical, add natspec documentation that concrete implementation of withdraw() in child functions should implement proper access control.

In the Redemption contract, the sweepDestination variable represents the address where the contract owner-controlled withdrawToSweepDestination() will send the requested amount of USDC tokens. This variable is configured in initialize() and can be updated using setSweepDestination().

However, the underlying implementation in _setSweepDestination() does not have a check that the provided address value for sweepDestination is valid and not 0 address.

To prevent asset loss, consider adding a zero address check for sweepDestination, similar to what is done in SuperstateToken.

The Superstate system is a centralized system with various regulatory compliance requirements. A multi-sig account that is an authorized party in the system has extensive privileges that control all assets through configuration and privileged operations.

Various contracts within the Superstate system, such as Superstate.sol and Management.sol, are implemented with hardcoded peg between USD and configured stablecoins. This is an explicit assumption within the system and an acceptable risk to the system owners. Even though potential malicious end users may attempt to exploit de-peg events, all system users are KYC, and the likelihood of this happening is minimal.