Is The Innovation Game (TIG) Safe? Smart Contract Security Analysis

Security Findings

1 High1 Med1 Low1 Info

High

Centralized Minting Authority

H-01The `mint` function is restricted to the contract owner, allowing them to create an arbitrary amount of new tokens. This introduces a significant centralization risk and potential for supply inflation, impacting token value and trust. If the owner's intent is to maintain a controlled supply, this mechanism grants them unilateral power.

IssueThe `mint` function is restricted to the contract owner, allowing them to create an arbitrary amount of new tokens. This introduces a significant centralization risk and potential for supply inflation, impacting token value and trust. If the owner's intent is to maintain a controlled supply, this mechanism grants them unilateral power.

FixClearly communicate the minting policy and the role of the owner in the token's documentation. For future iterations, consider implementing a hard cap on the total supply or transitioning minting authority to a decentralized governance mechanism or a timelock contract.

StatusUnresolved

Medium

Owner Key Compromise Risk

M-01Critical functions such as `mint` and `transferOwnership` are controlled by a single owner address. While the pre-filled data indicates the owner is a multisig, a compromise of this multisig's keys (e.g., a majority of signers) would grant an attacker full control over token supply and ownership, leading to severe economic damage.

IssueCritical functions such as `mint` and `transferOwnership` are controlled by a single owner address. While the pre-filled data indicates the owner is a multisig, a compromise of this multisig's keys (e.g., a majority of signers) would grant an attacker full control over token supply and ownership, leading to severe economic damage.

FixEnsure the multisig setup for the owner address follows best practices, including strong key management, geographically distributed signers, and robust operational security procedures. Regularly review and update multisig signers as needed.

StatusUnresolved

Low

Lack of Programmatic Supply Cap

L-01The token contract does not implement a hard cap on the total supply. While the `mint` function is owner-controlled, the absence of a programmatic limit means the owner can continuously mint tokens without a protocol-enforced upper bound. This is a design choice but should be transparent to token holders.

IssueThe token contract does not implement a hard cap on the total supply. While the `mint` function is owner-controlled, the absence of a programmatic limit means the owner can continuously mint tokens without a protocol-enforced upper bound. This is a design choice but should be transparent to token holders.

FixIf a fixed supply is desired, implement a `maxSupply` variable and enforce it within the `_mint` function. If an uncapped supply is intentional, ensure this is clearly communicated in all project documentation to manage community expectations.

StatusUnresolved

Info

No Pause/Emergency Stop Mechanism

I-01The contract lacks a mechanism to pause critical operations (e.g., transfers, minting) in case of an emergency, such as a detected vulnerability or a major market disruption. While not strictly necessary for a simple ERC20, it's a common security feature in more complex systems to mitigate unforeseen risks.

IssueThe contract lacks a mechanism to pause critical operations (e.g., transfers, minting) in case of an emergency, such as a detected vulnerability or a major market disruption. While not strictly necessary for a simple ERC20, it's a common security feature in more complex systems to mitigate unforeseen risks.

FixConsider adding a `Pausable` mechanism (e.g., from OpenZeppelin) to allow the owner to temporarily halt operations in an emergency. This should be paired with clear documentation on the conditions under which pausing would occur and how it would be unpaused.

StatusUnresolved

Category Ratings

TechnicalLow7/10

The contract leverages battle-tested OpenZeppelin libraries for ERC20, ERC20Burnable, and Ownable functionalities, ensuring a robust and standard implementation (7.2 Code Security). Standard ERC20 operations like `transfer` and `approve` are correctly implemented, including checks for zero addresses and sufficient balances. The use of `unchecked` blocks for subtractions is safe due to preceding `require` statements, preventing underflow vulnerabilities.

GovernanceMedium4/10

The primary economic and governance risk stems from the `onlyOwner` controlled `mint` function, allowing the owner to arbitrarily increase the token supply (7.4 Economic, 7.5 Governance). This centralization grants significant power to the owner, potentially impacting token value. The pre-filled information indicates the owner is a multisig, which partially mitigates the single point of failure for the owner address (7.8 Operations).

UpgradesMedium4/10

The contract is not designed with an upgradeability pattern (e.g., proxy contracts), meaning its logic cannot be modified post-deployment (7.7 Upgrades). This eliminates risks associated with upgrade mechanisms, such as proxy misconfigurations or malicious upgrade paths. Any future 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

Holder Composition

64.0% in top 10

3.6% in wallets60.4% in contracts

Effective Concentration27.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

$1.14M across 4 pairs

Uniswap v3USDCanalysed$683.3K AerodromeUSDC$210.3K AerodromeWETH$135.0K Uniswap v3WETH$109.3K

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 Holder100.0%

Top-3 Unlocked100.0%

Key Addresses

5 addresses

Deployer

0xc30e…79be

Unlocked LP Held By

0x7a14…17950xe7f2…270a0x73e3…93d50xae8a…d7bd

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 — Multisig (2-of-3)
Mintable supply — no cap found, dilution unbounded
Top-10 concentration > 20% (64.0% total → 27.7% effective; 3.6% in EOAs, 60.4% in contracts — mild)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top1 unlocked holder = 100.0% (independent LP — depth risk, pool = 60% of DEX liquidity)
LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 60% 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

Is The Innovation Game Safe?

Security Findings

Centralized Minting Authority

Owner Key Compromise Risk

Lack of Programmatic Supply Cap

No Pause/Emergency Stop Mechanism

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 The Innovation Game?