Is Altura (ALU) Safe? Smart Contract Security Analysis

Security Findings

1 Low3 Info

Low

Use of Older Solidity Compiler Version (0.5.16)

L-01The contract is compiled with Solidity version 0.5.16. While the `SafeMath` library is used to prevent integer overflows and underflows, newer compiler versions (e.g., 0.8.x) include built-in overflow checks by default, reducing reliance on external libraries for this specific safety measure. Newer compilers also offer various security improvements, bug fixes, and gas optimizations (7.2 Code Security).

IssueThe contract is compiled with Solidity version 0.5.16. While the `SafeMath` library is used to prevent integer overflows and underflows, newer compiler versions (e.g., 0.8.x) include built-in overflow checks by default, reducing reliance on external libraries for this specific safety measure. Newer compilers also offer various security improvements, bug fixes, and gas optimizations (7.2 Code Security).

FixFor future deployments or upgrades, consider using the latest stable Solidity compiler version (e.g., 0.8.x). This provides enhanced security features, better gas efficiency, and improved developer tooling. Thorough testing should always accompany compiler version upgrades.

StatusUnresolved

Info

Potential for Centralized Supply Control (Mitigated by Renounced Ownership)

I-01The `Altura` contract includes an `onlyOwner` `mint` function, allowing the contract owner to increase the total supply of tokens arbitrarily. This capability, if active, could lead to significant inflation and dilution of existing token holders, posing a substantial economic and governance risk (7.4, 7.5). However, the provided operational data indicates that ownership of the contract has been renounced. This action effectively disables the `mint` function, as there is no longer an owner to call it.

IssueThe `Altura` contract includes an `onlyOwner` `mint` function, allowing the contract owner to increase the total supply of tokens arbitrarily. This capability, if active, could lead to significant inflation and dilution of existing token holders, posing a substantial economic and governance risk (7.4, 7.5). However, the provided operational data indicates that ownership of the contract has been renounced. This action effectively disables the `mint` function, as there is no longer an owner to call it.

FixNo action is required if ownership has indeed been permanently renounced. It is crucial to ensure that the renunciation is irreversible and transparently communicated to the community to build trust in the token's fixed supply post-renunciation.

StatusResolved

Info

Redundant `getOwner()` Function

I-02The `IBEP20` interface defines a `getOwner()` function. The `Altura` contract implements this by simply returning the result of the inherited `owner()` function from the `Ownable` contract. Since `owner()` is already a public function providing the same information, `getOwner()` is redundant and adds unnecessary code (7.1 Architecture).

IssueThe `IBEP20` interface defines a `getOwner()` function. The `Altura` contract implements this by simply returning the result of the inherited `owner()` function from the `Ownable` contract. Since `owner()` is already a public function providing the same information, `getOwner()` is redundant and adds unnecessary code (7.1 Architecture).

FixConsider removing the `getOwner()` function from the `IBEP20` interface and the `Altura` contract if it is not strictly required by external integrations that specifically call `getOwner()`. Relying solely on the `owner()` function is more concise.

StatusUnresolved

Info

Internal Burn Functions Not Publicly Exposed

I-03The `Altura` contract includes internal `_burn` and `_burnFrom` functions, which are standard helpers for token burning. However, there are no public or `onlyOwner` functions that expose this burning functionality to external callers or the contract owner. This means that, by design, tokens cannot be burned after deployment (7.1 Architecture, 7.8 Operations). This might be an intentional design choice, but it's worth noting for clarity regarding tokenomics.

IssueThe `Altura` contract includes internal `_burn` and `_burnFrom` functions, which are standard helpers for token burning. However, there are no public or `onlyOwner` functions that expose this burning functionality to external callers or the contract owner. This means that, by design, tokens cannot be burned after deployment (7.1 Architecture, 7.8 Operations). This might be an intentional design choice, but it's worth noting for clarity regarding tokenomics.

FixIf token burning is intended to be a feature, consider adding a public or `onlyOwner` function that calls `_burn` or `_burnFrom`. If burning is not intended, no action is needed, but this design choice should be clearly documented.

StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract demonstrates good code security (7.2) by utilizing the `SafeMath` library to prevent integer overflows/underflows in all arithmetic operations. Its architecture (7.1) is a standard BEP20 token implementation, adhering to common patterns. A minor technical concern is the use of Solidity 0.5.16, an older compiler version, although `SafeMath` mitigates many associated risks. The contract's external interactions (7.6) are limited to standard token operations.

GovernanceMedium6/10

The contract initially included an `onlyOwner` `mint` function, posing a potential economic risk (7.4) of centralized supply control and governance (7.5) over token inflation. However, the operational data indicates that ownership has been renounced, effectively disabling this minting capability and mitigating this significant economic and governance risk. Access control (7.3) is managed via the `Ownable` pattern, and operational controls (7.8) are now decentralized due to ownership renunciation.

UpgradesMedium6/10

The contract is a standard, non-proxy implementation, meaning it is not upgradeable (7.7). This design choice eliminates any risks associated with upgrade mechanisms, such as proxy implementation bugs, upgrade path vulnerabilities, or malicious upgrade capabilities.

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership RenouncedPass

No Mint FunctionFail

Liquidity LockedFail

Not a ProxyPass

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

54.9% in top 10

21.1% in wallets33.8% in contracts

Effective Concentration34.6%

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

$334.9K across 8 pairs

Pancakeswap v2WBNBanalysed$314.0K BiswapWBNB$12.3K BabyswapUSDT$8.2K Pancakeswap v3WBNB$290 Pancakeswap v2Cake$41 Pancakeswap v2BUSD$17

Show 2 more pairsShow less

Pancakeswap v2USDT$15 0x1E12…39DBWBNB$6

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 Holder58.2%

Top-3 Unlocked100.0%

Key Addresses

11 addresses

Deployer

0x4430…fcca

Unlocked LP Held By

0x6510…27350x3889…4f240xd08c…86ae0xc5da…73b80xbef8…ec3e0x8903…d3be0x02a3…6a570x27a9…47960x98ff…67730x3273…68d3

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

What Raised This Score

6 factors

Mintable supply — no cap found, dilution unbounded
Top-10 concentration > 30% (54.9% total → 34.6% effective; 21.1% in EOAs, 33.8% in contracts — moderate)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top1 unlocked holder = 58.2% (independent LP — depth risk, pool = 94% of DEX liquidity)
LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 94% of DEX liquidity)
1 Low 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

Not Signed In

Is Altura Safe?

Security Findings

Use of Older Solidity Compiler Version (0.5.16)

Potential for Centralized Supply Control (Mitigated by Renounced Ownership)

Redundant `getOwner()` Function

Internal Burn Functions Not Publicly Exposed

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 Altura?