Valinity Contract Audit

In this project, many contracts extend `RegistrarClient.sol` and rely on the `Registrar` to provide the contract address references. These contracts include: 1. `VYToken` 2. `VETHYieldRateTreasury` 3. `VETHP2P` 4. `VETHRevenueCycleTreasury` 5. `VETHGovernance` 6. `VETHReverseStakingTreasury` In contract `Registrar.sol`, function `setContracts()` allows privileged role `AdminAgents` to update the address reference. Any compromise to the `AdminAgents` account may allow the hacker to take advantage of this authority and set incorrect contracts address references. Misuse of this functionality might potentially affecting all users and contracts interacting with those addresses and threaten the integrity of multiple contracts within the project. ```solidity=67 function setContracts(address[] calldata _addresses) external onlyAdminAgents onlyUnfinalized { require(_validContractsLength(_addresses.length), "Invalid number of addresses"); // Loop through and update _prevContracts entries only if those addresses are new. // For example, assume _prevContracts[0] = 0xABC and contracts[i] = 0xF00 // If _addresses[i] = 0xF00 and we didn't perform the check below, then we would overwrite the old // 0xABC with 0xF00, thereby losing whatever actual previous contract address that was. for (uint i = 0; i < _contracts.length; i++) { if (_addresses[i] != _contracts[i]) { _prevContracts[i] = _contracts[i]; } } _contracts = _addresses; emit SetContracts(_addresses); } ```

The function `airdropTokens()` allows BackendAgents to mint arbitrary amounts of tokens when registrar contract has not been finalized. Furthermore, these minted tokens are not included in the calculated circulating supply, leading to an inaccurate representation of the token's total supply and valuation metrics. ```solidity=243 function airdropTokens(address[] calldata _addresses, uint[] calldata _amounts) external onlyBackendAgents { require(_addresses.length == _amounts.length, "Argument array length mismatch"); _requireRegistrarIsUnfinalized(_getMainEcosystemRegistrar()); // Check main ecosystem for (uint i = 0; i < _addresses.length; i++) { super._mint(_addresses[i], _amounts[i]); } } ``` Exploit Scenario: - An attacker with control of a BackendAgent account could mint an excessive number of vyTokens. - They could then transfer these minted tokens into the `VETHRevenueCycleTreasury`, artificially diluting the circulating supply and significantly lowering the yield rate. - Exploiting this artificially lowered yield rate, the attacker could then interact with the `VETHReverseStakingTreasury` to restake a minimal amount of vyTokens and borrow a disproportionally large amount of ETH. - The attacker could drain the ETH treasury with this method, causing substantial financial loss. Unlimited minting presents a major risk as it allows for substantial economic manipulation and exploitation. An attacker can not only devalue the yield rate but can also extract large amounts of ETH from the treasury, thereby compromising the entire ecosystem's financial stability.

An address is not validated before assignment or external calls, potentially allowing the use of zero addresses and leading to unexpected behavior or vulnerabilities. For example, transferring tokens to a zero address can result in a permanent loss of those tokens. ```solidity=23 _primaryStakeholder = primaryStakeholder_; ``` - `primaryStakeholder_` is not zero-checked before being used.