Is Starknet (STRK) Safe? Smart Contract Security Analysis

Security Findings

2 High1 Med2 Info

High

Centralized Minting Authority

H-01The `mint` function allows an account with the `MINTER_ROLE` to create an arbitrary amount of new tokens. This capability, if misused or compromised, can lead to uncontrolled supply inflation, devaluing existing tokens and disrupting the token's economic stability. The `MINTER_ROLE` is initially controlled by the `DEFAULT_ADMIN_ROLE`.

IssueThe `mint` function allows an account with the `MINTER_ROLE` to create an arbitrary amount of new tokens. This capability, if misused or compromised, can lead to uncontrolled supply inflation, devaluing existing tokens and disrupting the token's economic stability. The `MINTER_ROLE` is initially controlled by the `DEFAULT_ADMIN_ROLE`.

FixTransfer the `MINTER_ROLE` to a secure multi-signature wallet or a DAO governance contract. Implement a timelock for minting operations and consider adding rate limits or caps on the amount that can be minted within a specific period.

StatusUnresolved

High

Centralized Role Management

H-02The `DEFAULT_ADMIN_ROLE` has complete authority over all other roles, including the `MINTER_ROLE`. This creates a single point of failure: if the private key controlling the `DEFAULT_ADMIN_ROLE` is compromised, an attacker could gain full administrative control, including the ability to mint tokens and manage all other roles without restriction.

IssueThe `DEFAULT_ADMIN_ROLE` has complete authority over all other roles, including the `MINTER_ROLE`. This creates a single point of failure: if the private key controlling the `DEFAULT_ADMIN_ROLE` is compromised, an attacker could gain full administrative control, including the ability to mint tokens and manage all other roles without restriction.

FixTransfer the `DEFAULT_ADMIN_ROLE` to a robust multi-signature wallet or a DAO governance contract. Implement a timelock for any changes to role administrators or the granting/revoking of critical roles to allow for community oversight and emergency response.

StatusUnresolved

Medium

Lack of Emergency Pause Mechanism

M-01The contract lacks a mechanism to pause token transfers or minting in emergency situations, such as a critical vulnerability discovery, a major exploit in an integrated DeFi protocol, or a significant market manipulation event. Without a pause function, the project team would have limited ability to mitigate ongoing damage during an incident.

IssueThe contract lacks a mechanism to pause token transfers or minting in emergency situations, such as a critical vulnerability discovery, a major exploit in an integrated DeFi protocol, or a significant market manipulation event. Without a pause function, the project team would have limited ability to mitigate ongoing damage during an incident.

FixConsider integrating OpenZeppelin's `Pausable` contract. This would allow a designated role (e.g., controlled by a multi-signature wallet or governance) to temporarily halt critical operations, providing a safety mechanism during emergencies.

StatusUnresolved

Info

Immutability of Contract Logic

I-01The `StarkNetToken` contract is deployed as a standard, non-upgradeable contract. This design choice eliminates the complexities and potential risks associated with upgrade mechanisms (e.g., proxy implementation bugs, improper upgrade paths). However, it also means that any discovered vulnerabilities or desired feature enhancements cannot be addressed without deploying a new contract and migrating all token holders.

IssueThe `StarkNetToken` contract is deployed as a standard, non-upgradeable contract. This design choice eliminates the complexities and potential risks associated with upgrade mechanisms (e.g., proxy implementation bugs, improper upgrade paths). However, it also means that any discovered vulnerabilities or desired feature enhancements cannot be addressed without deploying a new contract and migrating all token holders.

FixAcknowledge the implications of immutability. For future projects, carefully evaluate the trade-offs between immutability (simplicity, reduced upgrade risk) and upgradeability (flexibility for bug fixes, feature additions) based on the project's long-term strategy and risk tolerance.

StatusUnresolved

Info

Reliance on OpenZeppelin Contracts

I-02The contract extensively utilizes battle-tested and widely audited OpenZeppelin libraries for core functionalities such as ERC20, AccessControl, and ERC20Votes. This significantly reduces the likelihood of common low-level vulnerabilities (e.g., reentrancy, integer overflows) in the implemented components, contributing to a higher baseline of code security.

IssueThe contract extensively utilizes battle-tested and widely audited OpenZeppelin libraries for core functionalities such as ERC20, AccessControl, and ERC20Votes. This significantly reduces the likelihood of common low-level vulnerabilities (e.g., reentrancy, integer overflows) in the implemented components, contributing to a higher baseline of code security.

FixContinue to monitor OpenZeppelin's security advisories and ensure that any future deployments or integrations with OpenZeppelin contracts are based on the latest stable and audited versions.

StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract architecture (7.1) is straightforward, implementing a standard ERC20 token with OpenZeppelin's AccessControl and ERC20Votes. Code security (7.2) is robust due to the extensive use of battle-tested OpenZeppelin libraries, minimizing common low-level vulnerabilities. However, access control (7.3) presents a significant technical risk due to the centralized nature of the `MINTER_ROLE` and `DEFAULT_ADMIN_ROLE`, which could lead to unauthorized supply inflation or administrative actions if compromised.

GovernanceHigh1/10

The economic model (7.4) carries a high risk due to the `mint` function, which allows an authorized `MINTER_ROLE` to create an arbitrary amount of tokens, potentially leading to hyperinflation and devaluation. Governance (7.5) is highly centralized, with the `DEFAULT_ADMIN_ROLE` having complete control over all other roles, including the `MINTER_ROLE`. This single point of failure could be exploited if the admin key is compromised, impacting token supply and voting power.

UpgradesHigh3/10

The contract is not designed to be upgradeable (7.7), which eliminates all risks associated with upgrade mechanisms, such as proxy implementation bugs or improper upgrade paths. This immutability ensures the contract's logic remains fixed post-deployment. However, it also means that no bug fixes or feature enhancements can be implemented without a complete redeployment and token migration.

Security Checklist

2/5 checks passed

Contract VerifiedPass

Ownership Renounced?

No Mint FunctionFail

Liquidity LockedFail

Not a ProxyPass

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

68.2% in top 10

17.4% in wallets50.8% in contracts

Effective Concentration37.7%

Share held by contracts — treasury, vesting, bridge or staking — is discounted against share held by wallets when the score is computed: a contract cannot decide to sell the way an anonymous holder can, though it can still be drained or voted to sell. Effective concentration is the figure the risk score is actually calculated from.

Liquidity Depth

$143.9K across 6 pairs

Uniswap v4ETHanalysed$94.3K Uniswap v3WETH$26.3K Uniswap v2WETH$21.1K Uniswap v3ARB$1.9K Uniswap v4AZTEC$337 Uniswap v4AZTEC$16

The risk score reads depth across every pair. The volume figure and the volume-to-liquidity ratio elsewhere on this page describe only the pair this audit analysed, so the two are not directly comparable.

LP Distribution

Top-1 Unlocked Holder99.8%

Top-3 Unlocked100.0%

Key Addresses

5 addresses

Deployer

0xf28f…8130

Unlocked LP Held By

0x7c81…6f4b0x5044…28960x87b5…fe4a0x388c…82e0

No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.

What Raised This Score

8 factors

Ownership status UNKNOWN (owner could not be resolved)
Mintable supply — no cap found, dilution unbounded
Top-10 concentration > 30% (68.2% total → 37.7% effective; 17.4% in EOAs, 50.8% in contracts — moderate)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top1 unlocked holder = 99.8% (independent LP — depth risk, pool = 66% of DEX liquidity)
LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 66% of DEX liquidity)
2 High finding(s) from audit
1 Medium finding(s) from audit

Each factor is an on-chain fact recorded at the time of this analysis. The score is computed from them by a deterministic function, so the same contract returns the same score for anyone who runs the audit. How scores are computed

Final Recommendation

AI Copilot

To mitigate the identified high risks, it is strongly recommended to decentralize the control of the `DEFAULT_ADMIN_ROLE` and `MINTER_ROLE`.…

Read the verdictHide

Transfer these critical roles to a robust multi-signature wallet with a sufficient number of trusted signers or, ideally, to a decentralized autonomous organization (DAO) governance contract. Additionally, consider implementing a timelock for critical administrative actions, such as granting or revoking roles, to provide a window for community review and emergency intervention. For future token designs, evaluate the inclusion of an emergency pause mechanism to provide a safety net against unforeseen exploits.

Contract

TypeStarkNetToken

Audit History

1 audit on record

Sep 1869

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Not Signed In

Is Starknet Safe?

Security Findings

Centralized Minting Authority

Centralized Role Management

Lack of Emergency Pause Mechanism

Immutability of Contract Logic

Reliance on OpenZeppelin Contracts

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of Starknet?