OpenZeppelin / OpenZeppelin/openzeppelin-contracts
Move Paused and Unpaused event definitions to an interface
Nobody has claimed this yet.
- Dominant language
- Solidity
- Stars
- 27.2k
- Forks
- 12.4k
- Avg merge
- 2d 19h
- Merged PRs (30d)
- 33
Description
🧐 Motivation
Currently, Paused and Unpaused events are hardcoded in contracts/utils/Pausable.sol and contracts/utils/PausableUpgradeable.sol. While these events are included in the ABI after compilation, customizing ABI visibility for different user groups—so they only load relevant parts into their wallets—requires manual editing of the ABI JSON.
Ideally, different interface files could be defined for different views and linked via inheritance. However, because these events are embedded directly in the implementation contracts, they cannot be reused in interface files without causing Event with same name and parameter types defined twice error.. This is due to Solidity's restriction against redeclaring events.
📝 Details
To improve modularity and ABI customization, I propose moving the Paused and Unpaused events into a dedicated interface. Then, both Pausable.sol and PausableUpgradeable.sol can implement this interface.
This change would enable developers to selectively expose these events through interfaces without requiring manual modification of the ABI.
Overall, this idea can be applied to all errors and events embedded in implementation contracts like contracts-upgradeable/contracts/proxy/utils/Initializable.sol and contracts-upgradeable/utils/PausableUpgradeable.sol
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by comparing contracts/utils/Pausable.sol and contracts/utils/PausableUpgradeable.sol, where the Paused and Unpaused events are currently defined. Introduce the dedicated interface described in the issue and verify that both implementation contracts use it without duplicate event declaration errors. Consider the related Initializable.sol and PausableUpgradeable.sol paths only if extending the same pattern beyond these events.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- solidity
- Domain
- blockchain
- Issue type
- Refactor
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100