Is Briun Armstrung (BRIUN) Safe? Smart Contract Security Analysis

Security Findings

1 Low2 Info

Low

Centralized Initial Token Distribution

L-01The contract's constructor mints the entire initial supply of 1,000,000,000 tokens (1 billion) to the deployer address. This results in 100% of the token supply being held by a single address immediately after deployment (7.4 Economic).

IssueThe contract's constructor mints the entire initial supply of 1,000,000,000 tokens (1 billion) to the deployer address. This results in 100% of the token supply being held by a single address immediately after deployment (7.4 Economic).

FixWhile not a technical vulnerability in the contract code, this represents a significant centralization risk for the token's economic model. Future distribution strategies should aim for broader decentralization to mitigate potential market manipulation or single points of failure, aligning with principles of decentralized finance.

StatusUnresolved

Info

Ownership Renounced

I-01The contract's `Ownable` ownership has been renounced, as indicated by the `ownership_renounced: true` flag in the provided metadata. This means the `owner()` function will return the zero address, and any functions protected by the `onlyOwner` modifier are no longer callable. This affects `transferOwnership` and `renounceOwnership` functions.

IssueThe contract's `Ownable` ownership has been renounced, as indicated by the `ownership_renounced: true` flag in the provided metadata. This means the `owner()` function will return the zero address, and any functions protected by the `onlyOwner` modifier are no longer callable. This affects `transferOwnership` and `renounceOwnership` functions.

FixConfirm that renouncing ownership was an intentional design choice. This makes the contract immutable in terms of administrative control, preventing future changes to ownership or other `onlyOwner` protected functions. This is often a desired state for fully decentralized tokens.

StatusUnresolved

Info

Standard OpenZeppelin ERC20 Implementation

I-02The contract is a standard implementation of the ERC20 token specification, leveraging well-audited OpenZeppelin Contracts (v4.9.3). This includes robust handling of transfers, approvals, and supply management. The use of battle-tested libraries significantly reduces the risk of common vulnerabilities (7.2 Code Security).

IssueThe contract is a standard implementation of the ERC20 token specification, leveraging well-audited OpenZeppelin Contracts (v4.9.3). This includes robust handling of transfers, approvals, and supply management. The use of battle-tested libraries significantly reduces the risk of common vulnerabilities (7.2 Code Security).

FixContinue to rely on battle-tested libraries for core functionalities. Ensure any custom logic introduced in future versions maintains the same security standards and undergoes thorough testing and auditing.

StatusUnresolved

Category Ratings

TechnicalLow10/10

The contract demonstrates high technical quality, primarily due to its reliance on OpenZeppelin's well-audited ERC20 and Ownable implementations (7.2 Code Security). There are no complex custom logic, external calls, or reentrancy vectors. Standard Solidity 0.8.0+ features mitigate integer overflow/underflow risks. The architecture (7.1 Architecture) is straightforward, representing a basic token contract.

GovernanceMedium6/10

The contract's ownership has been renounced (7.3 Access Control), which removes a single point of administrative control and enhances decentralization for contract functions. However, the entire initial token supply is minted to the deployer (7.4 Economic), presenting a centralized distribution risk. There are no explicit governance mechanisms beyond the renounced `Ownable` pattern (7.5 Governance).

UpgradesLow10/10

The contract is not designed to be upgradeable (7.7 Upgrades). This eliminates upgrade-related risks such as proxy implementation vulnerabilities or administrative key compromise. The immutability provides certainty regarding the contract's future behavior.

Security Checklist

5/5 checks passed

Contract VerifiedPass

Ownership RenouncedPass

No Mint FunctionPass

Liquidity LockedPass

Not a ProxyPass

Holder Composition

45.6% in top 10

24.7% in wallets20.9% in contracts

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

$1.2K

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

LP Locked100.0% · UNCX Locker

Top-1 Unlocked Holder0.0%

Key Addresses

3 addresses

Deployer

0x66c6…2617

Unlocked LP Held By

0xb583…952c0x0b18…80af

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

What Raised This Score

3 factors

Top-10 concentration > 30% (45.6% total → 33.1% effective; 24.7% in EOAs, 20.9% in contracts — moderate)
Liquidity < $10k ($1,168 across 1 pairs — easily drained)
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 Briun Armstrung Safe?

Security Findings

Centralized Initial Token Distribution

Ownership Renounced

Standard OpenZeppelin ERC20 Implementation

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 Briun Armstrung?