Is TRIA Safe? Smart Contract Security Analysis

Security Findings

1 Low3 Info

Low

Centralized Control Over Accidental Funds

L-01The `Withdrawable` abstract contract, implemented by `TriaToken`, grants the contract owner (via `onlyAuthorizer` and `_authorizeWithdraw()`) sole authority to withdraw any ETH or ERC20 tokens accidentally sent to the `TriaToken` contract. While this is a common and often necessary pattern for recovering funds, it represents a centralized point of control for these specific operations. The security of these funds relies entirely on the integrity of the owner's address.

IssueThe `Withdrawable` abstract contract, implemented by `TriaToken`, grants the contract owner (via `onlyAuthorizer` and `_authorizeWithdraw()`) sole authority to withdraw any ETH or ERC20 tokens accidentally sent to the `TriaToken` contract. While this is a common and often necessary pattern for recovering funds, it represents a centralized point of control for these specific operations. The security of these funds relies entirely on the integrity of the owner's address.

FixEnsure the contract owner's address is a highly secure entity, such as a well-managed multisignature wallet, to mitigate the risks associated with centralized control. The prefill data indicates the owner is a multisig, which is a good practice.

StatusUnresolved

Info

Immutability and Lack of Upgradeability

I-01The `TriaToken` contract is not designed with upgradeability features (e.g., proxy pattern). This means that once deployed, its logic cannot be modified. Any discovered vulnerabilities or desired feature enhancements would necessitate a new contract deployment and a potentially complex and costly migration process for token holders.

IssueThe `TriaToken` contract is not designed with upgradeability features (e.g., proxy pattern). This means that once deployed, its logic cannot be modified. Any discovered vulnerabilities or desired feature enhancements would necessitate a new contract deployment and a potentially complex and costly migration process for token holders.

FixThis is a design choice. If future flexibility or bug-fixing capabilities are desired, consider implementing an upgradeable proxy pattern (e.g., UUPS or Transparent Proxy) in future iterations. For this immutable contract, thorough testing is paramount before deployment.

StatusUnresolved

Info

Hardcoded Initial Token Supply

I-02The initial total supply of 10,000,000,000 TRIA tokens (10 billion * 1e18) is hardcoded in the constructor of the `TriaToken` contract. This design choice fixes the token's maximum supply from deployment and prevents any future adjustments to the supply without redeploying the contract.

IssueThe initial total supply of 10,000,000,000 TRIA tokens (10 billion * 1e18) is hardcoded in the constructor of the `TriaToken` contract. This design choice fixes the token's maximum supply from deployment and prevents any future adjustments to the supply without redeploying the contract.

FixThis is a deliberate design decision for a fixed-supply token. If future flexibility in token supply (e.g., dynamic minting/burning based on governance) is ever desired, it would require a new contract deployment. For the current design, no change is needed.

StatusUnresolved

Info

Reliance on External OpenZeppelin Libraries

I-03The contract heavily relies on external, well-audited OpenZeppelin libraries, including `ERC20`, `ERC20Permit`, `Ownable`, `SafeERC20`, and `ReentrancyGuard`. While these libraries are industry standards and have undergone extensive audits, any future vulnerabilities discovered within these external dependencies could potentially impact the security of the `TriaToken` contract.

IssueThe contract heavily relies on external, well-audited OpenZeppelin libraries, including `ERC20`, `ERC20Permit`, `Ownable`, `SafeERC20`, and `ReentrancyGuard`. While these libraries are industry standards and have undergone extensive audits, any future vulnerabilities discovered within these external dependencies could potentially impact the security of the `TriaToken` contract.

FixRegularly monitor security announcements and updates from OpenZeppelin. While direct action on the deployed contract is not possible, staying informed is crucial for understanding potential ecosystem-wide risks.

StatusUnresolved

Category Ratings

TechnicalLow8/10

The technical architecture (7.1 Architecture) is sound, leveraging standard ERC20, ERC20Permit, and Ownable patterns. Code security (7.2 Code Security) is enhanced by the use of OpenZeppelin's SafeERC20 for token transfers and ReentrancyGuard for withdrawal functions, preventing common attack vectors. Access control (7.3 Access Control) for withdrawals is centralized to the contract owner, which is a multisig, mitigating single-point-of-failure risks. External dependencies (7.6 External) are limited to battle-tested OpenZeppelin contracts.

GovernanceMedium4/10

The economic model (7.4 Economic) is straightforward with a fixed initial supply of 10 billion tokens, minted to a specified treasury address. Governance (7.5 Governance) is managed through an `Ownable` pattern, where the owner is a multisig, enhancing security and decentralization of control over critical functions like fund withdrawals. There are no complex tokenomics or fee structures, simplifying economic analysis.

UpgradesLow7/10

The contract is not designed as an upgradeable proxy (7.7 Upgrades), meaning its logic is immutable once deployed. This eliminates upgrade-related risks such as proxy storage collisions or logic errors during upgrades. However, it also means that any future bug fixes or feature enhancements would require a new deployment and token migration.

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyPass

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

87.6% in top 10

6.1% in wallets81.5% in contracts

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

$148.0K across 4 pairs

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

4 addresses

Deployer

0x4c49…f80c

Unlocked LP Held By

0x0e09…c2190x8ba4…63b40x0b8a…9377

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

What Raised This Score

6 factors

Ownership NOT renounced — Multisig (3-of-4)
Top-10 concentration > 30% (87.6% total → 38.7% effective; 6.1% in EOAs, 81.5% in contracts — moderate)
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)
LP top3 unlocked holders = 100.0% (independent LP — depth risk)
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 TRIA Safe?

Security Findings

Centralized Control Over Accidental Funds

Immutability and Lack of Upgradeability

Hardcoded Initial Token Supply

Reliance on External OpenZeppelin Libraries

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