Vulnerability: zBanc - DynamicLiquidTokenConverter isActive should only be returned if converter is fully configured and converter parameters should only be updateable while converter is inactive
Severity: medium

Description:
By default, a converter is `active` once the anchor ownership was transferred. This is true for converters that do not require to be properly set up with additional parameters before they can be used.\\n```\\n/\\*\\*\\n \\* @dev returns true if the converter is active, false otherwise\\n \\*\\n \\* @return true if the converter is active, false otherwise\\n\\*/\\nfunction isActive() public view virtual override returns (bool) {\\n    return anchor.owner() == address(this);\\n}\\n```\\n\\nFor a simple converter, this might be sufficient. If a converter requires additional setup steps (e.g. setting certain internal variables, an oracle, limits, etc.) it should return `inactive` until the setup completes. This is to avoid that users are interacting with (or even pot. frontrunning) a partially configured converter as this may have unexpected outcomes.\\nFor example, the `LiquidityPoolV2Converter` overrides the `isActive` method to require additional variables be set (oracle) to actually be in `active` state.\\n```\\n  \\* @dev returns true if the converter is active, false otherwise\\n  \\*\\n  \\* @return true if the converter is active, false otherwise\\n\\*/\\nfunction isActive() public view override returns (bool) {\\n    return super.isActive() && address(priceOracle) != address(0);\\n}\\n```\\n\\nAdditionally, settings can only be updated while the contract is `inactive` which will be the case during an upgrade. This ensures that the `owner` cannot adjust settings at will for an active contract.\\n```\\nfunction activate(\\n    IERC20Token \\_primaryReserveToken,\\n    IChainlinkPriceOracle \\_primaryReserveOracle,\\n    IChainlinkPriceOracle \\_secondaryReserveOracle)\\n    public\\n    inactive\\n    ownerOnly\\n    validReserve(\\_primaryReserveToken)\\n    notThis(address(\\_primaryReserveOracle))\\n    notThis(address(\\_secondaryReserveOracle))\\n    validAddress(address(\\_primaryReserveOracle))\\n    validAddress(address(\\_secondaryReserveOracle))\\n{\\n```\\n\\nThe `DynamicLiquidTokenConverter` is following a different approach. It inherits the default `isActive` which sets the contract active right after anchor ownership is transferred. This kind of breaks the upgrade process for `DynamicLiquidTokenConverter` as settings cannot be updated while the contract is active (as anchor ownership might be transferred before updating values). To unbreak this behavior a new authentication modifier was added, that allows updates for the upgrade contradict while the contract is active. Now this is a behavior that should be avoided as settings should be predictable while a contract is active. Instead it would make more sense initially set all the custom settings of the converter to zero (uninitialized) and require them to be set and only the return the contract as active. The behavior basically mirrors the upgrade process of `LiquidityPoolV2Converter`.\\n```\\n    modifier ifActiveOnlyUpgrader(){\\n      if(isActive()){\\n        require(owner == addressOf(CONVERTER\\_UPGRADER), "ERR\\_ACTIVE\\_NOTUPGRADER");\\n      }\\n      \\_;\\n    }\\n```\\n\\nPre initialized variables should be avoided. The marketcap threshold can only be set by the calling entity as it may be very different depending on the type of reserve (eth, token).\\n```\\nuint32 public minimumWeight = 30000;\\nuint32 public stepWeight = 10000;\\nuint256 public marketCapThreshold = 10000 ether;\\nuint256 public lastWeightAdjustmentMarketCap = 0;\\n```\\n\\nHere's one of the setter functions that can be called while the contract is active (only by the upgrader contract but changing the ACL commonly followed with other converters).\\n```\\nfunction setMarketCapThreshold(uint256 \\_marketCapThreshold)\\n    public\\n    ownerOnly\\n    ifActiveOnlyUpgrader\\n{\\n    marketCapThreshold = \\_marketCapThreshold;\\n    emit MarketCapThresholdUpdated(\\_marketCapThreshold);\\n}\\n```\\n

Impact:

Recommended mitigation:
Align the upgrade process as much as possible to how `LiquidityPoolV2Converter` performs it. Comply with the bancor API.\\noverride `isActive` and require the contracts main variables to be set.\\ndo not pre initialize the contracts settings to “some” values. Require them to be set by the caller (and perform input validation)\\nmirror the upgrade process of `LiquidityPoolV2Converter` and instead of `activate` call the setter functions that set the variables. After setting the last var and anchor ownership been transferred, the contract should return active.