On-chain security analysis — is it a scam or legit?
The SekuyaToken contract is an ERC20 token with burnable and access control features, built upon OpenZeppelin libraries.
Read the full analysisEach 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
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.
Holder balances as recorded by the audit of Sep 4, 2026
The risk score reads depth across every pair.
The LP tokens of the analysed pool are locked or burned.
0x8ff5…196f0x264d…3e470xd76a…8baa0xb3b6…73330x8a7f…976f0xead0…2d120x65bb…642aNo privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
MINTER_ROLE has the authority to mint new tokens up to the MAX_SUPPLY (1 billion tokens). This centralized control over the token supply introduces a significant economic risk, as the token supply can be increased by a single entity, potentially leading to dilution for existing token holders if not managed transparently and responsibly. This power is granted to the deployer in the constructor.H-01The MINTER_ROLE has the authority to mint new tokens up to the MAX_SUPPLY (1 billion tokens). This centralized control over the token supply introduces a significant economic risk, as the token supply can be increased by a single entity, potentially leading to dilution for existing token holders if not managed transparently and responsibly. This power is granted to the deployer in the constructor.
Implement a multi-signature wallet for the MINTER_ROLE to ensure that minting operations require consensus from multiple trusted parties. Clearly communicate the minting policy and schedule to the community. Consider mechanisms to decentralize or restrict minting power further in the future if appropriate for the project's roadmap.
Unresolved
DEFAULT_ADMIN_ROLE and MINTER_ROLE to the deployer's address (_msgSender()). This design creates a single point of failure for all administrative functions and token minting. If the private key associated with this single address is compromised, an attacker could gain full control over role management (granting/revoking any role) and the ability to mint tokens up to the maximum supply.M-01The contract's constructor grants both the DEFAULT_ADMIN_ROLE and MINTER_ROLE to the deployer's address (_msgSender()). This design creates a single point of failure for all administrative functions and token minting. If the private key associated with this single address is compromised, an attacker could gain full control over role management (granting/revoking any role) and the ability to mint tokens up to the maximum supply.
Transfer the DEFAULT_ADMIN_ROLE to a robust multi-signature wallet immediately after deployment. This will distribute control and require multiple approvals for critical administrative actions, significantly reducing the risk associated with a single compromised key.
Unresolved
SekuyaToken contract is deployed as a standard implementation contract and does not utilize any proxy patterns (e.g., UUPS, Transparent). This means that the contract's logic is immutable after deployment. Any future bug fixes, feature enhancements, or changes to the token's economic model would necessitate deploying an entirely new contract and migrating existing token holders, which can be a complex and costly process.I-01The SekuyaToken contract is deployed as a standard implementation contract and does not utilize any proxy patterns (e.g., UUPS, Transparent). This means that the contract's logic is immutable after deployment. Any future bug fixes, feature enhancements, or changes to the token's economic model would necessitate deploying an entirely new contract and migrating existing token holders, which can be a complex and costly process.
While not a vulnerability, it's important for the project team to be aware of this limitation. For future projects or if flexibility is a high priority, consider implementing an upgradeable proxy pattern (e.g., UUPS) to allow for future contract modifications without requiring a full redeployment and migration.
Unresolved
MAX_SUPPLY for the token is defined as a public constant within the contract. While this provides clarity and prevents accidental changes, it means the maximum possible token supply cannot be adjusted after deployment without deploying a new contract. This rigidity might limit future economic model adjustments if the project's needs evolve.I-02The MAX_SUPPLY for the token is defined as a public constant within the contract. While this provides clarity and prevents accidental changes, it means the maximum possible token supply cannot be adjusted after deployment without deploying a new contract. This rigidity might limit future economic model adjustments if the project's needs evolve.
Ensure that the MAX_SUPPLY value is thoroughly reviewed and aligns with the long-term vision for the token's economics. If future flexibility for supply adjustments is desired, consider making the MAX_SUPPLY a state variable that can be modified by a privileged role (e.g., DEFAULT_ADMIN_ROLE) under strict governance, though this introduces its own set of risks.
Unresolved
The SekuyaToken contract is an ERC20 token with burnable and access control features, built upon OpenZeppelin libraries. The primary risks identified are the centralized control over token minting and the single point of failure for administrative roles, which could lead to economic instability if compromised. The contract is not upgradeable, limiting future flexibility.
The contract demonstrates strong technical quality (7.2 Code Security) by leveraging battle-tested OpenZeppelin libraries for ERC20, ERC20Burnable, and AccessControl functionalities. This significantly reduces the likelihood of common vulnerabilities like reentrancy or integer overflows, as these libraries are extensively audited. The implementation of unchecked blocks in _transfer, _mint, _burn, and decreaseAllowance is correctly guarded by prior require statements, ensuring arithmetic safety. The overall architecture (7.1 Architecture) is simple and follows standard token patterns.
The economic model (7.4 Economic) of SekuyaToken relies heavily on a centralized MINTER_ROLE, which can mint tokens up to a MAX_SUPPLY. This introduces a significant risk of token dilution if the role is misused or compromised. Furthermore, the contract's governance (7.5 Governance) is entirely centralized through the DEFAULT_ADMIN_ROLE, which can grant or revoke any other role, including the minter role. This creates a single point of failure (7.3 Access Control) where a compromise of the initial deployer's address could lead to full control over the token supply and administrative functions.
The SekuyaToken contract is deployed as a standard implementation contract and does not utilize any proxy patterns (7.7 Upgrades). This means the contract's logic is immutable after deployment. While this eliminates risks associated with upgrade mechanisms, it also means that any future bug fixes, feature enhancements, or changes to the token's economic model would require deploying an entirely new contract and migrating existing token holders, which can be a complex and costly process.
It is strongly recommended to implement a robust multi-signature wallet for managing the DEFAULT_ADMIN_ROLE and MINTER_ROLE to mitigate the single point of failure risk.
This would require multiple trusted parties to approve critical operations, enhancing security. Additionally, consider the long-term implications of a non-upgradeable contract; if future flexibility is desired, a proxy pattern should be explored for new deployments.
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
Score changes are recorded as dated snapshots — history is append-only and cannot be edited.
Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.
Get Detailed Audit Is this your token? Publish your own audit on this page
