Current calculation of _getBasedBondAmount and _getCurrentBondAmount restricts the number of pods that an operator can bond in

[code423n4]

Lines of code

https://github.com/code-423n4/2022-10-holograph/blob/f8c2eae866280a1acfdc8a8352401ed031be1373/contracts/HolographOperator.sol#L1160
https://github.com/code-423n4/2022-10-holograph/blob/f8c2eae866280a1acfdc8a8352401ed031be1373/contracts/HolographOperator.sol#L849

Vulnerability details

Impact

Based bond amount is calculated with the pod as the power factor. This restricts the number of pods available for operators when trying to join a pod even though there can be unlimited pods created because the bond amount gets too high.

Proof of Concept

In pod 1, operators pay 2 ** 0 * 100 * (10 ** 18), as mentioned in the docs.

  function _getBaseBondAmount(uint256 pod) private view returns (uint256) {
    return (_podMultiplier**pod) * _baseBondAmount;
  }

whereby _podMultiplier = 2
pod = 1 , podIndex = 0
_baseBondAmount = 100 * (10**18)

Deducting the decimal places, operators pay 100 tokens to join pod 1, which is not bad.

However, in pod 20, operators pay 2 ** 21 * 100 * (10 ** 18) to join, which evaluates to 104,857,600 tokens, deducting decimal places. Since the total supply of tokens is only 10B, this amount is pretty large and most operators can't possibly pay that much, which results in a redundancy of pods.

Tools Used

Remix IDE

Recommended Mitigation Steps

Consider a more gradual calculation of _getBasedBondAmount to accommodate more pods and operators or limit the number of pods available.

[gzeoneth]

Looks like design choice by await sponsor comment.

[alexanderattar]

Design choice. Save gas by not running such calculations and math, naturally limit number of pods. But also since bonding minimum might change at any time, by not setting a hard limit, the number of possible pods will adjust dynamically as well.