DMD Diamond

The ClaimContract contains a critical vulnerability in its fill function that allows a malicious actor to permanently prevent the contract from being initialized.

The claim function in the ClaimContract is vulnerable to signature replay attacks. The function uses a _postfix parameter in the signature verification process, but there's no mechanism to ensure this postfix is unique for each claim.

The 'certified' function in the CertifierHbbft contract contains a vulnerability in its logic for determining whether an address is certified.

The KeyGenHistory contract has an initialization vulnerability where the counters numberOfPartsWritten and numberOfAcksWritten are not properly initialized during the contract's initialization process.

The RandomHbbft contract has an inconsistency in how it tracks the health status of the validator set. The contract sets an unhealthiness flag for a block when setCurrentSeed is called and the validator set is not at full health.

The getSliceUInt256 function in the TxPermissionHbbft contract contains a critical vulnerability that allows for out-of-bounds array access.

The areStakeAndWithdrawAllowed() function in the StakingHbbft contract is currently hardcoded to always return true, effectively disabling any time-based restrictions on staking and withdrawal operations.

The setPoolInfo function in the StakingHbbft contract lacks crucial input validation for its parameters. This function allows users to set their pool's public key, IP address, and port number.

The claimMessageMatchesSignature function in the ClaimContract uses the Solidity ecrecover function directly to verify signatures.

The publicKeyToDMDAddress function in the ClaimContract attempts to generate a Bitcoin-style address from ECDSA public key coordinates.

The ClaimContract contains two significant issues related to the validation of dilution event timestamps: 1.

The claimMessageMatchesSignature function in the ClaimContract lacks crucial validation for the ECDSA public key coordinates (_pubKeyX and _pubKeyY) provided as input parameters.

The claimMessageMatchesSignature function in the ClaimContract is vulnerable to signature malleability attacks. The function verifies ECDSA signatures without implementing protection against the malleability property of ECDSA signatures.

When switchPhase is called, the new phase's start and end timestamps are derived from the previous phase's end timestamp: uint64 newPhaseStart = daoPhase.end + 1; daoPhase.start = newPhaseStart; daoPhase.end = newPhaseStart +…

During the finalize step of a proposal, votes are counted from a fixed user stakeAmount snapshot taken at the end of the Voting phase: function _snapshotStakes(uint64 daoEpoch) private { address[] memory daoEpochVoters =…

When a proposal contains multiple calldatas, the _checkProposalType function determines the proposal type based on the last processed calldata that successfully identifies a range or defaults to a ContractUpgrade if any of the calldatas is…

In the claim function of the ClaimContract, there is a misspelling in the parameter name _targetAdress. The correct spelling should be _targetAddress.

In the claim function of the ClaimContract, there is an incorrect comment for the _pubKeyY parameter. The comment incorrectly states "ECDSA public key X coordinate" instead of "Y coordinate".

In the ClaimContract, specifically within the dilution functions (dilute1, dilute2, and dilute3), there is a typographical error in the error message used when reverting due to an already executed dilution.

In the ClaimContract, the createClaimMessage function has a discrepancy between its documented return type and its actual return type.

The publicKeyToDMDAddress function in the ClaimContract uses the ripemd160 hash function, which is implemented as a precompile contract in Ethereum at address(2).

In the _sendDilutedAmounts function of the ClaimContract, there is a typographical error in the variable name used for calculating the transfer amount to the Reinsert Pot.

The _distributeRewards function in the BlockRewardHbbft contract performs external calls before completing all state updates.

The certified function in the CertifierHbbft contract performs a redundant check against the validator set.

In the KeyGenHistory contract, when the clearPrevKeyGenState function is called at the start of a new key generation round, it clears all pending validators' states and revocations from the previous epoch.

The ValidatorSetHbbft contract's pool removal functions (_removePool and _removePoolUnordered) lack comprehensive validation checks before removing a pool from the active validator set.

The DiamondDao contract initializes the ReentrancyGuard in its initialize function but fails to apply the nonReentrant modifier to several critical functions that handle funds or make significant state changes.

The _getCurrentValWithSelector function in the DiamondDao contract performs a staticcall to an external contract and attempts to read a 32-byte value from the returned data without verifying the data length.

The DiamondDao contract implements a voting system for proposals using an EnumerableSet to track voters and a mapping to store vote records.

The DAO contract inherits Ownable functionality but never invokes __Ownable_init or otherwise sets the owner during initialization. As a result, the owner() is permanently address(0).

In extreme scenarios where the total staking amount is zero or extremely small, the quorum calculation will allow proposals to almost always pass.

The DAO uses a transparent proxy pattern controlled by a ProxyAdmin contract. For on-chain governance proposals to perform contract upgrades, the DAO must own the ProxyAdmin.

According to the DiamondDAO documentation, historical proposals can be finalized and executed at any time.

The ClaimContract contains several critical state variables that are set in the constructor and are not intended to be changed after contract deployment. These variables include beneficiary addresses and dilution timestamps.

The diamond-contracts-core repository has achieved 95% test coverage, but there are specific test gaps that should be addressed to ensure comprehensive coverage of all contract functionalities and edge cases.

The DiamondDAO contract's initialize function sets up a fixed array of allowed proposal fee values (createProposalFeeAllowedParams). This array is hardcoded with nine specific values ranging from 10 to 90 ether.

The DiamondDao contract uses a hashProposal function to generate unique identifiers for proposals.

The documentation states that the proposal fee is fixed at 20 DMD and can be changed via an ecosystem parameter proposal: The proposal fee is fixed at 20 DMD for all proposal types.

When multiple Open proposals execute in quick succession, they may drain the governancePot. Subsequent proposals attempting to execute transfers could fail if insufficient funds remain.

Currently, the contract calculates proposal acceptance based on exceeding yes/no percentages. Since participation thresholds is the same as the acceptance, abstain votes have no meaningful impact on the final outcome, despite being…

Rather than using constant literal values, create a constant state variable and reference it throughout the contract.

Index event fields make the field more quickly accessible to off-chain tools that parse events. Each event should use three indexed fields if there are three or more fields, and gas usage is not particularly of concern for the events in…

It is recommended that the definition be removed when custom error is unused. Found 2 instances: • Line 55: error FunctionUpgradeNotAllowed(bytes4 funcSelector, address targetContract); • Line 56: error InvalidUpgradeValue(uint256…

In the loop condition (i < currentPhaseProposals.length) of the switchPhase function, the contract repeatedly reads the length property of a storage array. Each read from storage is more expensive than reading from memory.

The BlockRewardHbbft contract uses a hardcoded governance pot address (0x2000000000000000000000000000000000000002 or similar) throughout its distribution logic.

The certified function in the CertifierHbbft contract contains commented-out code that references a staking contract check.

The KeyGenHistory contract contains a consistent spelling error in multiple locations where the parameter name _upcommingEpoch is used instead of the correct spelling _upcomingEpoch (with one 'm' instead of two). This typo appears in: 1.

The DiamondDao contract's initialize function accepts an _txPermission parameter but never uses it anywhere in the contract.