Preconditions
- You can access the "Read Contract" and "Write Contract" pages of the target smart contract on Etherscan (or the block explorer corresponding to the chain the contract deploys on).
- You have confirmed that the contract's owner() or DEFAULT_ADMIN_ROLE parameter points to a burn/blackhole address such as 0x000...dead.
Renouncing ownership only closes the "super admin" backdoor for a project, but other role permissions embedded in the contract may still enable equally high-risk malicious operations.
A leading global cryptocurrency platform,suitable for both beginners and experienced traders.
New user benefit: 20% off trading fees upon registration!！
"Renounce ownership" usually means the renounceOwnership() function is called, and the contract owner is transferred to a blackhole address. However, many projects adopt the OpenZeppelin AccessControl module that supports a multi-role permission system. The disappearance of the top-level owner does not mean high-risk roles such as MINTER_ROLE (token mint permission) and PAUSER_ROLE (transaction pause permission) are also revoked.
Step 1: Check "Read Contract" — List All Current Role Holders
What to do: Query addresses corresponding to all high-risk roles one by one under the "Read Contract" tab on the Etherscan contract page.
How to do it: Locate and call the following functions in the "Read Contract" list:
- DEFAULT_ADMIN_ROLE or getRoleAdmin: Verify if any address still holds top-level management permission.
- hasRole(role, address): Requires you to know the specific role name defined by the contract (e.g. MINTER_ROLE). If you do not have the role name, use getRoleMemberCount and getRoleMember functions to list all holders of all roles.
Case A: If the hasRole query results for MINTER_ROLE, PAUSER_ROLE, BURNER_ROLE and other high-risk roles return non-blackhole addresses → High Risk. These addresses still have permission to mint unlimited new tokens or pause all transactions. Recommended action: In this scenario, the project team only revoked their own top-level ownership, but reserved critical permissions for other parties. You cannot mark this project as secure.
Case B: All queryable high-risk roles point to 0x000...dead or 0x000...000 zero address → Permissions are mostly clean. But you still need to check for unlisted custom roles that are not publicly documented.
Completion Criteria: You have confirmed all publicly queryable role permissions in the contract, and their current holders are either blackhole addresses or verified multi-sig wallets.
High-Risk Note: In the Solana ecosystem, Mint Authority, Freeze Authority, and Update Authority are three independent permissions. Even if a project claims to have "renounced ownership", it may only have revoked one of the three, while the other two are still retained. Mint Authority can be used to mint unlimited new tokens, and Freeze Authority can freeze token transactions of any wallet, both attacks do not require the top-level owner identity. Renouncing ownership never equals revoking all privileged permissions.
Step 2: Check Proxy Mode — The Actual Logic Resides in the Implementation Contract
What to do: Confirm if the contract adopts the upgradeable proxy pattern (Proxy). If yes, the permission settings are stored in the implementation (logic) contract, not the front-end proxy contract you are viewing.
How to do it: Check the top of the Etherscan page for a "Read as Proxy" or "Upgradeable" label. If the label exists, clicking "Read as Proxy" will pull data from the actual logic contract.
Case A: If the page shows "Proxy" or "Upgradeable" label → You must re-run all checks in Step 1 under the "Read as Proxy" mode. Because all permission configurations are stored in the logic contract, not the proxy shell contract.
Case B: No proxy label is displayed on the page → This is a non-proxy regular contract, you can skip this step.
Completion Criteria: Confirm that the permission data you queried comes from the contract's actual logic layer, not the superficial proxy shell contract.
Common Failure Causes
For contracts after ownership renouncement, the owner() field does show the zero address. But the admin may "forget" or intentionally reserve the MINTER_ROLE, and use this permission to mint a large amount of tokens to dump on the market in the later stage of the project. Only checking the owner field while ignoring other roles is equivalent to locking the front door, but leaving an unlocked small side door wide open.
Post-Operation Verification Method
Go to the "Write Contract" page on Etherscan, check the grantRole and revokeRole functions. If the currently connected wallet does not have the permission to call these functions, the platform will prompt "Connected wallet does not have permission to perform this operation". This step can cross-validate whether your query results from Step 1 are accurate.
A leading global cryptocurrency platform,suitable for both beginners and experienced traders.
New user benefit: 20% off trading fees upon registration!！
Next Step Actions
If you find any suspicious role holders, ask the project community about the use of the address: whether it is a "team reserved multi-sig wallet", a timelock contract, or an old discarded address that was not cleaned up. If the team gives vague answers or refuses to explain, treat the contract as "not fully renounced all permissions". Verification channel: The "Read Contract" and "Write Contract" lists under the "Contract" tab on the Etherscan contract page.
