Is Spark (SPK) Safe? Smart Contract Security Analysis

Security Findings

1 Crit2 High1 Med1 Low1 Info

Critical

`totalSupply` Overflow in `mint` function

C-01The `mint` function uses an `unchecked` block for the `totalSupply = totalSupply + value;` operation. If `totalSupply` is close to `type(uint256).max` and a large `value` is minted, `totalSupply` will overflow and wrap around to a small number. This breaks the fundamental invariant of token supply, leading to an incorrect total supply and potential economic exploits or system failures in protocols relying on the correct `totalSupply` value. (7.2 Code Security)

IssueThe `mint` function uses an `unchecked` block for the `totalSupply = totalSupply + value;` operation. If `totalSupply` is close to `type(uint256).max` and a large `value` is minted, `totalSupply` will overflow and wrap around to a small number. This breaks the fundamental invariant of token supply, leading to an incorrect total supply and potential economic exploits or system failures in protocols relying on the correct `totalSupply` value. (7.2 Code Security)

FixRemove the `unchecked` block around `totalSupply = totalSupply + value;` to allow default Solidity overflow checks to prevent this. Alternatively, implement a custom check `require(totalSupply + value >= totalSupply, 'SDAO/totalSupply-overflow');` before the addition.

StatusUnresolved

High

Centralized Control of Token Supply

H-01The `mint` function is controlled by addresses in the `wards` mapping via the `auth` modifier. This grants significant power to a small set of authorized addresses, allowing them to arbitrarily inflate the token supply. A compromise of an authorized address could lead to severe economic consequences, including hyperinflation and devaluation of the token. (7.3 Access Control, 7.4 Economic)

IssueThe `mint` function is controlled by addresses in the `wards` mapping via the `auth` modifier. This grants significant power to a small set of authorized addresses, allowing them to arbitrarily inflate the token supply. A compromise of an authorized address could lead to severe economic consequences, including hyperinflation and devaluation of the token. (7.3 Access Control, 7.4 Economic)

FixImplement a more decentralized or time-locked mechanism for minting, or clearly document the implications of this centralized control. Consider using a multi-signature wallet for the `auth` role to require multiple approvals for critical actions.

StatusUnresolved

High

Centralized Control of Token Metadata

H-02The `file` function allows authorized addresses (those in `wards`) to change the token `name` and `symbol`. While not directly impacting token value, this can lead to confusion, misrepresentation, and potential phishing if malicious names/symbols are set. This could undermine user trust and disrupt integrations with exchanges or other protocols. (7.3 Access Control, 7.4 Economic)

IssueThe `file` function allows authorized addresses (those in `wards`) to change the token `name` and `symbol`. While not directly impacting token value, this can lead to confusion, misrepresentation, and potential phishing if malicious names/symbols are set. This could undermine user trust and disrupt integrations with exchanges or other protocols. (7.3 Access Control, 7.4 Economic)

FixRemove the ability to change `name` and `symbol` after deployment, or implement a robust governance mechanism (e.g., time-locked multi-sig or DAO vote) for such critical changes.

StatusUnresolved

Medium

Lack of Granular Access Control

M-01The `auth` modifier provides an 'all-or-nothing' access control mechanism. Any address added to `wards` gains control over all privileged functions, including `mint`, `rely`, `deny`, and `file`. This lack of role separation increases the risk profile, as a single compromised `auth` key could lead to a full compromise of the token's administrative functions. (7.3 Access Control, 7.5 Governance)

IssueThe `auth` modifier provides an 'all-or-nothing' access control mechanism. Any address added to `wards` gains control over all privileged functions, including `mint`, `rely`, `deny`, and `file`. This lack of role separation increases the risk profile, as a single compromised `auth` key could lead to a full compromise of the token's administrative functions. (7.3 Access Control, 7.5 Governance)

FixImplement a more granular role-based access control (RBAC) system, assigning specific permissions (e.g., `MINTER_ROLE`, `ADMIN_ROLE`, `METADATA_EDITOR_ROLE`) to different addresses or multi-signature wallets.

StatusUnresolved

Low

`permit` Function Overload Redundancy

L-01The contract provides two `permit` functions: one accepting `bytes memory signature` and another accepting `uint8 v, bytes32 r, bytes32 s`. The latter simply encodes `v, r, s` into `bytes memory signature` and calls the first `permit` function. While functional, this adds a slight, unnecessary gas overhead for users who already have `v, r, s` separated, as the encoding step is redundant. (7.2 Code Security)

IssueThe contract provides two `permit` functions: one accepting `bytes memory signature` and another accepting `uint8 v, bytes32 r, bytes32 s`. The latter simply encodes `v, r, s` into `bytes memory signature` and calls the first `permit` function. While functional, this adds a slight, unnecessary gas overhead for users who already have `v, r, s` separated, as the encoding step is redundant. (7.2 Code Security)

FixConsider having the `permit` function taking `v, r, s` directly process the signature without re-encoding, or remove the overloaded function if the `bytes memory signature` version is sufficient for all use cases.

StatusUnresolved

Info

`DOMAIN_SEPARATOR` Recalculation on Chain ID Mismatch

I-01The `DOMAIN_SEPARATOR()` view function and the `permit` function recalculate the EIP-712 domain separator if `block.chainid` differs from `deploymentChainId`. While this design choice offers flexibility for potential cross-chain deployments or forks, it introduces a minor gas overhead for `permit` calls executed on a chain ID different from the deployment chain. For a token primarily intended for a single, fixed chain, this recalculation might be an unnecessary complexity and gas cost. (7.1 Architecture, 7.2 Code Security)

IssueThe `DOMAIN_SEPARATOR()` view function and the `permit` function recalculate the EIP-712 domain separator if `block.chainid` differs from `deploymentChainId`. While this design choice offers flexibility for potential cross-chain deployments or forks, it introduces a minor gas overhead for `permit` calls executed on a chain ID different from the deployment chain. For a token primarily intended for a single, fixed chain, this recalculation might be an unnecessary complexity and gas cost. (7.1 Architecture, 7.2 Code Security)

FixDocument this design choice and its implications. If the token is strictly intended for a single chain, consider simplifying the `DOMAIN_SEPARATOR` logic to always return the immutable `_DOMAIN_SEPARATOR` to save gas.

StatusUnresolved

Category Ratings

TechnicalMedium4/10

The contract implements an ERC-20-like token with EIP-2612 `permit` functionality and EIP-1271 signature validation. The `permit` implementation appears robust, correctly handling nonces and domain separators, including chain ID changes. However, a critical vulnerability exists in the `mint` function where `totalSupply` can overflow due to an `unchecked` block (C-01), leading to incorrect token supply. A minor gas optimization could be made in the overloaded `permit` function (L-01). (7.1 Architecture, 7.2 Code Security)

GovernanceHigh1/10

The token's economic model and governance are highly centralized, relying on a single `auth` role managed by the `wards` mapping. This role has extensive power, including the ability to mint tokens (H-01) and modify token metadata (H-02). The lack of granular access control (M-01) means a single compromised key could lead to severe economic and reputational damage. (7.3 Access Control, 7.4 Economic, 7.5 Governance)

UpgradesHigh1/10

The contract is not designed to be upgradeable. This simplifies the architecture by avoiding the complexities and potential risks associated with proxy patterns. Any future changes to the contract logic would require a new deployment and migration of assets, which is a standard approach for non-upgradeable tokens. (7.7 Upgrades)

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

86.1% in top 10

7.5% in wallets78.6% in contracts

Effective Concentration38.9%

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.37M across 3 pairs

Uniswap v4ETHanalysed$758.2K Uniswap v4USDC$614.5K Uniswap v4ETH$742

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.

Key Addresses

1 addresses

Deployer

0x548d…93dc

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% (86.1% total → 38.9% effective; 7.5% in EOAs, 78.6% in contracts — moderate)
Liquidity NOT locked (owner can withdraw — rug-pull risk)
1 Critical finding(s) from audit
2 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 Spark Safe?

Security Findings

`totalSupply` Overflow in `mint` function

Centralized Control of Token Supply

Centralized Control of Token Metadata

Lack of Granular Access Control

`permit` Function Overload Redundancy

`DOMAIN_SEPARATOR` Recalculation on Chain ID Mismatch

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of Spark?