Solid World

Smart Contract Security Assessment

March 1, 2023

SUMMARY​

ABSTRACT​

Dedaub was commissioned to perform a security audit of the Solid World protocol. The core Solid World Protocol is a set of mechanisms (e.g., tokenization, pooling, and ecosystem reward distribution to stakeholders/liquidity providers) that aim to create and incentivize a liquid market for forward carbon offset agreements.

The most critical subjects covered by the audit are the collateralization and decollateralization mechanisms, the reactive time appreciation calculations, the interactions with the staking contract, the accounting and distribution of rewards to stakers and access control.

The code and accompanying artifacts (e.g., test suite, documentation) have been developed with high professional standards. No security issues/threats were identified by the audit.

The main findings of the audit are (1) a potential out of gas situation in the RewardDistributor and DecollateralisationManager contracts and (2) a low possibility of the system ending up in a blocked state that requires the intervention of the protocol’s admins. As these situations described in (1) would require states extremely out of the bounds of what Solid World identified as “business as usual”, no code-level contingencies were deemed necessary, but were noted as possible scenarios. As for (2) the protocol team is in a position to monitor and actively act to avoid this from occurring, while the potential fixes would add unnecessary complexity to the system and its function. There were a few advisory issues raised, the majority of which were addressed.

SETTING & CAVEATS​

The scope of the audit includes the core contracts of the Solid World protocol. The test suite was consulted during the audit but was not part of it. The full list of audited files can be found below:

solid-world-dao-contracts

The audit report covers commit hash b955651893d36b1f946a7fabce2dd28284de002c of the at the time private repository solid-world-dao-contracts. Audited suggested fixes were also reviewed up to commit hash b3e79c2456ecca913be0ff165fd49992eba8e6e1.

Two auditors worked on the codebase for 2 weeks.

The audit’s main target is security threats, i.e., what the community understanding would likely call "hacking", rather than the regular use of the protocol. Functional correctness (i.e. issues in "regular use") is a secondary consideration. Typically it can only be covered if we are provided with unambiguous (i.e. full-detail) specifications of what is the expected, correct behavior. In terms of functional correctness, we often trusted the code’s calculations and interactions, in the absence of any other specification. Functional correctness relative to low-level calculations (including units, scaling and quantities returned from external protocols) is generally most effectively done through thorough testing rather than human auditing.

VULNERABILITIES & FUNCTIONAL ISSUES​

This section details issues affecting the functionality of the contract. Dedaub generally categorizes issues according to the following severities, but may also take other considerations into account such as impact or difficulty in exploitation:

Issue resolution includes “dismissed” or “acknowledged” but no action taken, by the client, or “resolved”, per the auditors.

CRITICAL SEVERITY​

[NO CRITICAL SEVERITY ISSUES]

HIGH SEVERITY​

[NO HIGH SEVERITY ISSUES]

MEDIUM SEVERITY​

//RewardsDistributor.sol::getAllUnclaimedRewardAmountsForUserAndAsset
function getAllUnclaimedRewardAmountsForUserAndAssets(
  address[] calldata assets, address user
)
  external
  view
  override
  returns (address[] memory rewardsList, uint[] memory unclaimedAmounts)
{
  RewardsDataTypes.AssetStakedAmounts[] memory assetStakedAmounts =
    _getAssetStakedAmounts(assets,user);
  rewardsList = new address[](_rewardsList.length);
  unclaimedAmounts = new uint[](rewardsList.length);
  for (uint i; i < assetStakedAmounts.length; i++) {
    for (uint r; r < rewardsList.length; r++) {
      rewardsList[r] = _rewardsList[r];
      unclaimedAmounts[r] += _assetData[assetStakedAmounts[i].asset]
        .rewardDistribution[rewardsList[r]]
        .userReward[user]
        .accrued;

      if (assetStakedAmounts[i].userStake == 0) {
        continue;
      }
      unclaimedAmounts[r] += _computePendingRewardAmountForUser(
        user,
        rewardsList[r],
        assetStakedAmounts[i]
      );
    }
  }
  return (rewardsList, unclaimedAmounts);
}

//DecollateralisationManger.sol::getBatchesDecollateralisationInfo()
function getBatchesDecollateralizationInfo(
  SolidWorldManagerStorage.Storage storage _storage,
  uint projectId,
  uint vintage
)
  external
  view
  returns (DomainDataTypes.TokenDecollateralizationInfo[] memory result)
{
  DomainDataTypes.TokenDecollateralizationInfo[] memory allInfos =
    new DomainDataTypes.TokenDecollateralizationInfo[](
      _storage.batchIds.length
    );
  uint infoCount;

  for (uint i; i < _storage.batchIds.length; i++) {
    uint batchId = _storage.batchIds[i];
    if (
      _storage.batches[batchId].vintage != vintage ||
      _storage.batches[batchId].projectId != projectId
    ) {
      continue;
    }

    (uint amountOut, uint minAmountIn, uint minCbtDaoCut) =
      _simulateDecollateralization(
        _storage,
        batchId,
        DECOLLATERALIZATION_SIMULATION_INPUT
      );

    // Dedaub: part of the code is omitted for brevity

    infoCount = infoCount + 1;
  }

  result = new DomainDataTypes.TokenDecollateralizationInfo[](infoCount);
  for (uint i; i < infoCount; i++) {
    result[i] = allInfos[i];
  }
}

LOW SEVERITY​

//RewardsDistributor.sol::updateCarbonRewardDistribution()
function updateCarbonRewardDistribution(
  address[] calldata assets,
  address[] calldata rewards,
  uint[] calldata rewardAmounts
) external override onlyEmissionManager {
  if (
    assets.length != rewards.length ||
    rewards.length != rewardAmounts.length
  ) {
    revert InvalidInput();
  }

  for (uint i; i < assets.length; i++) {
    if (!_canUpdateCarbonRewardDistribution(assets[i], rewards[i])) {
      revert UpdateDistributionNotApplicable(assets[i], rewards[i]);
    }
  }
  // Dedaub: part of the code is omitted for brevity
}

//RewardDistributor.sol::canUpdateCarbonRewardDistribution()
function _canUpdateCarbonRewardDistribution(address asset, address reward)
  internal view returns (bool)
{
  uint32 currentDistributionEnd =
    _assetData[asset].rewardDistribution[reward].distributionEnd;
  uint32 nextDistributionEnd =
    _computeNewCarbonRewardDistributionEnd(asset, reward);

  bool isInitializedDistribution = currentDistributionEnd != 0;
  bool isBetweenDistributions =
    block.timestamp >= currentDistributionEnd &&
    block.timestamp < nextDistributionEnd;

  return isInitializedDistribution && isBetweenDistributions;
}

//SolidMath.sol::computeWeeklyBatchReward()
function computeWeeklyBatchReward(
  uint certificationDate,
  uint availableCredits,
  uint timeAppreciation,
  uint rewardsFee,
  uint decimals
) internal view returns (uint netRewardAmount, uint feeAmount)

CENTRALIZATION ISSUES​

It is often desirable for DeFi protocols to assume no trust in a central authority, including the protocol’s owner. Even if the owner is reputable, users are more likely to engage with a protocol that guarantees no catastrophic failure even in the case the owner gets hacked/compromised. We list issues of this kind below. (These issues should be considered in the context of usage/deployment, as they are not uncommon. Several high-profile, high-value protocols have significant centralization threats.)

//CarbonDomainRepository.sol::addBatch()
function addBatch(
  SolidWorldManagerStorage.Storage storage _storage,
  DomainDataTypes.Batch calldata batch,
  uint mintableAmount
) external {
  // Dedaub: part of the code is omitted for brevity

  _storage._forwardContractBatch.mint(
    batch.supplier, batch.id, mintableAmount, ""
  );

  emit BatchCreated(batch.id);
}

OTHER / ADVISORY ISSUES​

This section details issues that are not thought to directly affect the functionality of the project, but we recommend considering them.

// DomainDataTypes.sol::Category
struct Category {
  uint volumeCoefficient;
  uint40 decayPerSecond;
  uint16 maxDepreciation;
  uint24 averageTA;
  uint totalCollateralized;
  uint32 lastCollateralizationTimestamp;
  uint lastCollateralizationMomentum;
}

// Dedaub: tighter packed version
struct Category {
  uint volumeCoefficient;
  uint40 decayPerSecond;
  uint16 maxDepreciation;
  uint24 averageTA;
  uint32 lastCollateralizationTimestamp;
  uint totalCollateralized;
  uint lastCollateralizationMomentum;
}

DISCLAIMER​

The audited contracts have been analyzed using automated techniques and extensive human inspection in accordance with state-of-the-art practices as of the date of this report. The audit makes no statements or warranties on the security of the code. On its own, it cannot be considered a sufficient assessment of the correctness of the contract. While we have conducted an analysis to the best of our ability, it is our recommendation for high-value contracts to commission several independent audits, a public bug bounty program, as well as continuous security auditing and monitoring through Dedaub Security Suite.

ABOUT DEDAUB​

Dedaub offers significant security expertise combined with cutting-edge program analysis technology to secure some of the most prominent protocols in DeFi. The founders, as well as many of Dedaub's auditors, have a strong academic research background together with a real-world hacker mentality to secure code. Protocol blockchain developers hire us for our foundational analysis tools and deep expertise in program analysis, reverse engineering, DeFi exploits, cryptography and financial mathematics.