Is sato Safe? Smart Contract Security Analysis

Security Findings

1 High1 Low1 Info

High

Centralized Minter Control Poses High Economic Risk

H-01The `minter` address has unlimited power to `mint` and `burn` tokens. This creates a single point of failure for the token's economic stability (7.4 Economic). If the `minter`'s private key is compromised, an attacker could arbitrarily inflate or deflate the token supply, leading to a complete loss of value for token holders. There are no checks or limitations on the amount that can be minted or burned, nor any governance mechanism to oversee these actions (7.5 Governance).

IssueThe `minter` address has unlimited power to `mint` and `burn` tokens. This creates a single point of failure for the token's economic stability (7.4 Economic). If the `minter`'s private key is compromised, an attacker could arbitrarily inflate or deflate the token supply, leading to a complete loss of value for token holders. There are no checks or limitations on the amount that can be minted or burned, nor any governance mechanism to oversee these actions (7.5 Governance).

FixImplement a multi-signature wallet for the `minter` role to require multiple approvals for minting/burning operations. Consider adding a time-lock mechanism for large mint/burn operations to provide a window for community review or emergency action. Explore integrating a decentralized governance model to control the `minter` role or its capabilities in the long term.

StatusUnresolved

Low

Unused Immutable Variables (Dead Code)

L-01The contract declares several `immutable` state variables: `RESTRICTIONS_FORBIDDEN`, `GENESIS_BLOCK`, and `GENESIS_HASH`. While these are initialized in the constructor, they are never read or used in any subsequent contract logic (7.2 Code Security). This constitutes dead code, which slightly increases contract deployment size and can lead to confusion regarding their intended purpose.

IssueThe contract declares several `immutable` state variables: `RESTRICTIONS_FORBIDDEN`, `GENESIS_BLOCK`, and `GENESIS_HASH`. While these are initialized in the constructor, they are never read or used in any subsequent contract logic (7.2 Code Security). This constitutes dead code, which slightly increases contract deployment size and can lead to confusion regarding their intended purpose.

FixRemove the unused `RESTRICTIONS_FORBIDDEN`, `GENESIS_BLOCK`, and `GENESIS_HASH` variables and their initialization from the constructor. If these variables are intended for future use, ensure their purpose is clearly documented or integrated into the contract's logic.

StatusUnresolved

Info

Single-Step Minter Setup

I-01The `setMinter` function allows the `DEPLOYER` to set the `minter` address only once. While this prevents re-assignment, it is a single-step operation (7.8 Operations). If the `DEPLOYER` accidentally sets an incorrect address or a zero address, the `minter` role will be permanently assigned incorrectly or disabled, rendering the minting/burning functionality unusable (7.3 Access Control).

IssueThe `setMinter` function allows the `DEPLOYER` to set the `minter` address only once. While this prevents re-assignment, it is a single-step operation (7.8 Operations). If the `DEPLOYER` accidentally sets an incorrect address or a zero address, the `minter` role will be permanently assigned incorrectly or disabled, rendering the minting/burning functionality unusable (7.3 Access Control).

FixConsider implementing a two-step process for setting critical roles like `minter`. This could involve a `proposeMinter` function followed by an `acceptMinter` function, allowing the proposed minter to confirm their acceptance. This adds a layer of safety against accidental misconfigurations.

StatusUnresolved

Category Ratings

TechnicalLow9/10

The contract leverages battle-tested OpenZeppelin ERC20 for core token functionality, ensuring robust and secure token operations (7.2 Code Security). Custom logic for `setMinter`, `mint`, and `burn` is minimal, straightforward, and correctly implements access control checks (7.3 Access Control). The architecture is simple and avoids complex external interactions (7.1 Architecture). Minor issues include unused immutable variables like `RESTRICTIONS_FORBIDDEN`, `GENESIS_BLOCK`, and `GENESIS_HASH`, which constitute dead code and slightly increase contract size (7.2 Code Security).

GovernanceHigh3/10

The contract clearly defines and enforces the `DEPLOYER` and `minter` roles, ensuring that only authorized addresses can manage token supply (7.3 Access Control). The `minter` role can only be set once by the `DEPLOYER`, preventing re-assignment (7.3 Access Control). A significant economic risk is the highly centralized control over token supply by the `minter` (7.4 Economic). The `minter` has unlimited power to `mint` and `burn` tokens, making it a single point of failure; compromise of this address could lead to arbitrary token inflation or deflation, severely impacting token value (7.4 Economic). There are no on-chain governance mechanisms to mitigate this centralization (7.5 Governance).

UpgradesMedium6/10

The contract is not designed with upgradeability in mind, which eliminates risks associated with proxy patterns, storage collisions, and upgrade path complexities (7.7 Upgrades). Its immutable nature provides a fixed and predictable codebase. As the contract is not upgradeable, any discovered critical vulnerabilities or desired feature enhancements would necessitate a complete redeployment and migration of token holders (7.7 Upgrades). This lack of flexibility could be a long-term operational concern (7.8 Operations).

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership Renounced?

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyPass

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

16.3% in top 10

5.6% in wallets10.6% in contracts

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

$184.7K across 9 pairs

Uniswap v4USDTanalysed$100.3K Uniswap v3WETH$31.9K Uniswap v4USDT$30.2K Uniswap v4ETH$12.5K Uniswap v4ETH$7.2K Uniswap v4USDT$1.8K

Show 1 more pairShow less

Uniswap v4ETH$869

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 Holder37.4%

Top-3 Unlocked84.3%

Key Addresses

10 addresses

Deployer

0xc1d3…c3ec

Unlocked LP Held By

0x9e31…7a7a0xa8e4…c4f50x1c84…93ba0xaca6…b41d0x0c3a…692c0x8f46…242c0x60b8…733c0x5420…e6d40x88fc…806d

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

What Raised This Score

5 factors

Ownership status UNKNOWN (owner could not be resolved)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top3 unlocked holders = 84.3% (independent LP — depth risk, pool = 54% of DEX liquidity)
1 High 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 sato Safe?

Security Findings

Centralized Minter Control Poses High Economic Risk

Unused Immutable Variables (Dead Code)

Single-Step Minter Setup

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