BTC Staking - CoreDAO

The PledgeAgent contract, a component of our blockchain system designed for handling reward claims, employs a hardcoded constant, CLAIM_ROUND_LIMIT, to define the maximum number of rounds for which rewards can be claimed in a single transaction. This parameter plays a critical role in managing gas consumption during these transactions, ensuring that operations remain efficient and do not exceed gas limits. However, the current implementation's rigidity, resulting from the CLAIM_ROUND_LIMIT being a constant value, limits the system's adaptability to evolving network conditions or governance policies. As network congestion, gas prices, and operational parameters change, the inability to adjust this limit dynamically could lead to inefficiencies or hindered functionality for users attempting to claim rewards.

  uint32 public constant INIT_BTC_CONFIRM_BLOCK = 3;
  uint256 public constant INIT_MIN_BTC_LOCK_ROUND = 7;
  uint256 public constant ROUND_INTERVAL = 86400;
  uint256 public constant INIT_MIN_BTC_VALUE = 1e6;
  uint256 public constant INIT_BTC_FACTOR = 5e4;
  uint256 public constant BTC_STAKE_MAGIC = 0x5341542b;
  uint256 public constant CHAINID = 1116;
  uint256 public constant FEE_FACTOR = 1e18;
  int256 public constant CLAIM_ROUND_LIMIT = 500;
  uint256 public constant BTC_UNIT_CONVERSION = 1e10;

Instead of a hardcoded constant, make CLAIM_ROUND_LIMIT a variable that can be adjusted through governance actions.

Remediation Plan

ACKNOWLEDGED : The CoreDAO team acknowledged the issue.

The IPledgeAgent smart contract provides a framework for delegating Bitcoin (BTC) to the Core network, facilitating staking, reward claims, and the transfer of staked BTC among validators. The contract includes functions for parsing transaction data, validating Bitcoin transaction proofs, managing staking receipts, and distributing rewards. However, the IPledgeAgent interface does not reflect all the functionalities implemented in the contract, particularly the newer functions related to BTC delegation.

interface IPledgeAgent {
  function addRoundReward(address[] calldata agentList, uint256[] calldata rewardList) payable external;
  function getHybridScore(address[] calldata candidates, uint256[] calldata powers, uint256 round) external returns(uint256[] memory);
  function setNewRound(address[] calldata validatorList, uint256 round) external;
  function distributePowerReward(address candidate, address[] calldata miners) external;
  function onFelony(address agent) external;
}

Consider implementing missing interface definitions.

Remediation Plan

SOLVED : The CoreDAO team solved the issue by adding missing interfaces.

Within the PledgeAgent contract, specifically in the BtcExpireInfo struct, there is a typographical error in the naming of one of its mappings: agentExsitMap.

Update all instances of agentExsitMap to agentExistMap within the contract.

Remediation Plan

SOLVED : The CoreDAO team solved the issue by fixing the typo.

The transferBtc and claimBtcReward functions in the provided contract are public functions that involve the transfer of Ether (rewards) to external addresses. However, these functions do not implement any reentrancy protection mechanisms. In the case of transferBtc, the function calls collectBtcReward, which in turn calls distributeReward. The distributeReward function uses the low-level send function to transfer Ether (rewards) to the delegator's address. Although, the send / transfer function provides some protection against reentrancy by limiting the gas forwarded to the recipient's fallback function.

Even if It does not pose risk directly, Consider implementing re-entrancy protection on the functions.

Remediation Plan

ACKNOWLEDGED : The CoreDAO team acknowledged the issue.