Cap on Minting:
Introducing a cap on the total supply of rsETH tokens can prevent excessive minting, aligning the contract with your tokenomics model. This cap can be set during contract initialization or via a separate configuration function accessible only to the admin.
Proof of Concept
Adding a Supply Cap:
uint256 private _cap;
/// @dev Initializes the contract with a supply cap
function initialize(address admin, address lrtConfigAddr, uint256 cap_) external initializer {
// ... existing initialization code ...
require(cap_ > 0, "RSETH: cap is 0");
_cap = cap_;
}
/// @dev Function to set or update the cap (optional)
/// @dev Only callable by the admin
function setCap(uint256 cap_) external onlyRole(DEFAULT_ADMINROLE) {
require(cap > 0, "RSETH: new cap is 0");
require(cap_ >= totalSupply(), "RSETH: new cap less than existing supply");
cap = cap;
emit CapUpdated(cap_);
}
/// @dev Overriding _mint to include cap logic
function _mint(address account, uint256 amount) internal virtual override {
require(totalSupply() + amount <= _cap, "RSETH: cap exceeded");
super._mint(account, amount);
}
Rationale:
Supply Cap: A cap on the total supply is a fundamental aspect of tokenomics. It provides predictability in the monetary policy of the token and can be crucial for maintaining value and trust in the token.
Tools Used
VS code
Recommended Mitigation Steps
Proactive measures aimed at enhancing the overall robustness and trustworthiness of the smart contract
Testing and Verification: After implementing these changes, it's crucial to thoroughly test the contract to ensure that the new logic works correctly and does not introduce any regressions or new issues.
Lines of code
https://github.com/code-423n4/2023-11-kelp/blob/main/src/RSETH.sol#L32
Vulnerability details
Impact
Cap on Minting: Introducing a cap on the total supply of rsETH tokens can prevent excessive minting, aligning the contract with your tokenomics model. This cap can be set during contract initialization or via a separate configuration function accessible only to the admin.
Proof of Concept
Adding a Supply Cap:
uint256 private _cap;
/// @dev Initializes the contract with a supply cap function initialize(address admin, address lrtConfigAddr, uint256 cap_) external initializer { // ... existing initialization code ...
}
/// @dev Function to set or update the cap (optional) /// @dev Only callable by the admin function setCap(uint256 cap_) external onlyRole(DEFAULT_ADMINROLE) { require(cap > 0, "RSETH: new cap is 0"); require(cap_ >= totalSupply(), "RSETH: new cap less than existing supply"); cap = cap; emit CapUpdated(cap_); }
/// @dev Overriding _mint to include cap logic function _mint(address account, uint256 amount) internal virtual override { require(totalSupply() + amount <= _cap, "RSETH: cap exceeded"); super._mint(account, amount); }
Rationale: Supply Cap: A cap on the total supply is a fundamental aspect of tokenomics. It provides predictability in the monetary policy of the token and can be crucial for maintaining value and trust in the token.
Tools Used
VS code
Recommended Mitigation Steps
Proactive measures aimed at enhancing the overall robustness and trustworthiness of the smart contract
Testing and Verification: After implementing these changes, it's crucial to thoroughly test the contract to ensure that the new logic works correctly and does not introduce any regressions or new issues.
Assessed type
Token-Transfer