Is FARM Reward Token (FARM) Safe? Smart Contract Security Analysis

Security Findings

1 High1 Med1 Low1 Info

High

Centralized Minter Role Management and Single Point of Failure

H-01The `MinterRole` is highly centralized, with the `addMinter` function only callable by an existing minter. There is no mechanism for the contract owner or any other designated role to add or remove minters. This creates a single point of failure: if the initial minter's private key is lost, compromised, or if the last minter renounces their role without assigning another, the ability to mint new tokens (up to the defined cap) could be permanently lost or fall into malicious hands. This poses a significant operational risk and could lead to an unrecoverable state for the token's minting functionality.

IssueThe `MinterRole` is highly centralized, with the `addMinter` function only callable by an existing minter. There is no mechanism for the contract owner or any other designated role to add or remove minters. This creates a single point of failure: if the initial minter's private key is lost, compromised, or if the last minter renounces their role without assigning another, the ability to mint new tokens (up to the defined cap) could be permanently lost or fall into malicious hands. This poses a significant operational risk and could lead to an unrecoverable state for the token's minting functionality.

FixImplement a more robust role management system. Consider allowing the contract owner to add and remove minters, or integrate a multi-signature wallet for managing the MinterRole. This would distribute control and reduce the risk associated with a single point of failure. A timelock for critical role changes could also be considered.

StatusUnresolved

Medium

Renounce Minter Leads to Potential Loss of Minting Capability

M-01The `renounceMinter` function allows any address holding the MinterRole to remove themselves. If the last remaining minter calls this function without first assigning another minter, the contract will enter a state where no address holds the `MinterRole`. In this scenario, the `mint` function will become permanently unusable, preventing any further token issuance, even if the supply cap has not been reached.

IssueThe `renounceMinter` function allows any address holding the MinterRole to remove themselves. If the last remaining minter calls this function without first assigning another minter, the contract will enter a state where no address holds the `MinterRole`. In this scenario, the `mint` function will become permanently unusable, preventing any further token issuance, even if the supply cap has not been reached.

FixImplement a safeguard within the `renounceMinter` function to prevent the last minter from renouncing their role. This could involve checking `_minters.count()` (if a counter is added) or requiring that at least one other minter exists before allowing a minter to renounce. Alternatively, ensure strict operational procedures are in place to manage minter roles.

StatusUnresolved

Low

Older Solidity Compiler Version

L-01The contract is compiled with Solidity version `^0.5.0`. While `SafeMath` is used to mitigate integer overflows, older compiler versions may contain known bugs, lack certain security features, or be less optimized compared to more recent and actively maintained versions (e.g., 0.8.x).

IssueThe contract is compiled with Solidity version `^0.5.0`. While `SafeMath` is used to mitigate integer overflows, older compiler versions may contain known bugs, lack certain security features, or be less optimized compared to more recent and actively maintained versions (e.g., 0.8.x).

FixConsider upgrading the contract to a more recent and actively supported Solidity compiler version (e.g., 0.8.x). This would allow the contract to benefit from the latest bug fixes, security enhancements (such as native overflow checks), and gas optimizations.

StatusUnresolved

Info

Missing Dedicated Event for `_burnFrom`

I-01The internal `_burnFrom` function performs a token burn and an allowance update. While the underlying `_burn` and `_approve` calls emit `Transfer` and `Approval` events respectively, there is no dedicated event specifically for the `_burnFrom` action. A distinct event could provide clearer and more granular off-chain visibility for this specific operation, aiding in monitoring and auditing.

IssueThe internal `_burnFrom` function performs a token burn and an allowance update. While the underlying `_burn` and `_approve` calls emit `Transfer` and `Approval` events respectively, there is no dedicated event specifically for the `_burnFrom` action. A distinct event could provide clearer and more granular off-chain visibility for this specific operation, aiding in monitoring and auditing.

FixConsider adding a dedicated event, such as `BurnFrom(address indexed account, address indexed spender, uint256 amount)`, within the `_burnFrom` function. This would enhance transparency and provide a clearer audit trail for tokens burned on behalf of another address.

StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract demonstrates good technical security practices (7.2 Code Security) by using SafeMath for all arithmetic operations, effectively mitigating integer overflow/underflow vulnerabilities. It adheres to the ERC20 standard, ensuring compatibility and expected behavior. However, the use of Solidity compiler version ^0.5.0 is an older version, which may lack some security enhancements and optimizations present in newer versions. No reentrancy vulnerabilities were identified due to the absence of external calls to untrusted contracts.

GovernanceHigh1/10

The economic model (7.4 Economic) includes a supply cap, which is a positive control against excessive inflation. However, the governance and access control (7.3 Access Control, 7.5 Governance) for the MinterRole are highly centralized. The `addMinter` function can only be called by an existing minter, and there is no mechanism for the contract owner to manage minters. This creates a single point of failure: if the initial minter's key is lost or compromised, the ability to add new minters or mint tokens (up to the cap) could be permanently lost or abused. The `renounceMinter` function also poses an operational risk, as the last minter could inadvertently disable minting functionality.

UpgradesHigh3/10

The contract is not designed with an upgrade mechanism (7.7 Upgrades) such as a proxy pattern. Therefore, it is not upgradeable, which eliminates upgrade-related risks but means any discovered vulnerabilities or desired feature changes would require a new deployment and migration.

Security Checklist

2/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionFail

Liquidity LockedFail

Not a ProxyPass

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

69.5% in top 10

48.8% in wallets20.8% in contracts

Effective Concentration57.1%

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

$74.6K across 7 pairs

Uniswap v2WETHanalysed$47.3K Uniswap v2USDC$14.7K SushiswapWETH$9.5K Uniswap v3WETH$2.9K DefiswapWETH$217 DefiswapCRO$34

Show 1 more pairShow less

Uniswap v2UNI$1

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 Holder60.5%

Top-3 Unlocked89.6%

Key Addresses

11 addresses

Deployer

0xf00d…5f7f

Unlocked LP Held By

0x6555…19580x52f1…f3250xcb2a…4b5a0x1d5e…2a2e0x6456…4e1a0xcea3…26350x4d35…20ea0x4d74…da650x588f…ee880x252e…653c

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

What Raised This Score

9 factors

Ownership NOT renounced (admin/mint authority retained)
Mintable supply — no cap found, dilution unbounded
Top-10 concentration > 50% (69.5% total → 57.1% effective; 48.8% in EOAs, 20.8% in contracts — heavy)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top1 unlocked holder = 60.5% (independent LP — depth risk, pool = 63% of DEX liquidity)
LP top3 unlocked holders = 89.6% (independent LP — depth risk, pool = 63% of DEX liquidity)
1 High finding(s) from audit
1 Medium finding(s) from audit
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 FARM Reward Token Safe?

Security Findings

Centralized Minter Role Management and Single Point of Failure

Renounce Minter Leads to Potential Loss of Minting Capability

Older Solidity Compiler Version

Missing Dedicated Event for `_burnFrom`

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 FARM Reward Token?