Quantum Audit Logo

Is BORT Safe?

On-chain security analysis — is it a scam or legit?

Is this your token? Publish your own audit on this page →

BORT BORT
0x2a84…4444
BNB Chain Not verifiedLast checked 2d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Low Risk
Executive SummaryAI Copilot

The FourERC20 contract is a standard ERC-20 token implementation, largely based on OpenZeppelin Contracts. It provides core token functionalities like transfer, allowance, minting, and burning. The contract demonstrates high code quality and adherence to established standards, leveraging battle-tested libraries. Key design considerations include the internal nature of supply management and initialization functions, which require a derived contract for external exposure and access control. Potential risks are primarily informational or low-severity, related to design patterns and standard ERC-20 behaviors.

2 Low2 Informational
Volume 24h
$102.9K
Liquidity
$192.3K
Price
$0.001066
Token Age
10mo
Top 10 Holders
39.5%

Security Findings

2 Low2 Info
Low

Centralized Control over Token Supply (if implemented in derived contract)

L-01If a derived contract exposes `_mint` and `_burn` functions, they would typically be controlled by an owner or a multi-sig. This introduces a point of centralization (7.3, 7.4) where a single entity (or a small group) can control the token supply, potentially leading to inflation or deflation without broader community consensus. This is a common design pattern for many tokens but represents a centralization risk.
IssueIf a derived contract exposes `_mint` and `_burn` functions, they would typically be controlled by an owner or a multi-sig. This introduces a point of centralization (7.3, 7.4) where a single entity (or a small group) can control the token supply, potentially leading to inflation or deflation without broader community consensus. This is a common design pattern for many tokens but represents a centralization risk.
FixFor derived contracts, implement robust access control for minting/burning functions, ideally with multi-sig or time-locked mechanisms, or consider a fixed supply model if dynamic supply is not required. Transparency around the minting/burning authority is crucial.
StatusUnresolved
Low

Standard ERC-20 `approve` Front-Running Risk

L-02The contract includes `increaseAllowance` and `decreaseAllowance` to mitigate the known ERC-20 `approve` front-running vulnerability. However, the standard `approve` function is still present and can be vulnerable if users directly interact with it by approving a new non-zero amount without first setting the allowance to zero. An attacker could front-run the transaction, spend the original allowance, and then the new allowance would also be granted, leading to a double-spend of the intended allowance amount.
IssueThe contract includes `increaseAllowance` and `decreaseAllowance` to mitigate the known ERC-20 `approve` front-running vulnerability. However, the standard `approve` function is still present and can be vulnerable if users directly interact with it by approving a new non-zero amount without first setting the allowance to zero. An attacker could front-run the transaction, spend the original allowance, and then the new allowance would also be granted, leading to a double-spend of the intended allowance amount.
FixEducate users to prefer `increaseAllowance` and `decreaseAllowance` or to follow the two-step approval process (approve 0, then approve new amount) when using the `approve` function directly. This is a common best practice for ERC-20 token interactions.
StatusUnresolved
Info

Base Contract Design for Supply Management and Initialization

I-01The `FourERC20` contract provides internal functions (`_mint`, `_burn`, `_init`) for token supply management and initialization (setting name/symbol). These functions are not exposed externally by this contract. This design requires a derived contract to implement external interfaces for these functionalities, including appropriate access control, or to call `_init` in its constructor. If deployed directly without a derived contract, the token's name/symbol cannot be set, and its supply cannot be managed.
IssueThe `FourERC20` contract provides internal functions (`_mint`, `_burn`, `_init`) for token supply management and initialization (setting name/symbol). These functions are not exposed externally by this contract. This design requires a derived contract to implement external interfaces for these functionalities, including appropriate access control, or to call `_init` in its constructor. If deployed directly without a derived contract, the token's name/symbol cannot be set, and its supply cannot be managed.
FixEnsure that any derived contract properly implements and secures the external interfaces for `_mint`, `_burn`, and calls `_init` in its constructor to set the token's metadata. This design choice should be clearly documented and understood by developers integrating with the token.
StatusUnresolved
Info

Missing Events for `_init` Parameters

I-02The `_init` function, intended for setting the token's name and symbol, does not emit an event upon execution. While not a security vulnerability, emitting an event for initialization parameters can be useful for off-chain monitoring, indexing, and transparency regarding the token's metadata (7.8 Operations).
IssueThe `_init` function, intended for setting the token's name and symbol, does not emit an event upon execution. While not a security vulnerability, emitting an event for initialization parameters can be useful for off-chain monitoring, indexing, and transparency regarding the token's metadata (7.8 Operations).
FixConsider adding an event (e.g., `event Initialized(string name, string symbol);`) and emitting it within the `_init` function. This enhances the traceability and observability of the token's initial configuration.
StatusUnresolved

Category Ratings

TechnicalLow10/10

The technical architecture (7.1) of the FourERC20 contract is robust, being a direct implementation of the ERC-20 standard using OpenZeppelin's battle-tested libraries, which significantly reduces the likelihood of common vulnerabilities. Code security (7.2) is strong, with Solidity 0.8+ providing native overflow/underflow checks and the use of `unchecked` blocks being appropriately guarded. Access control (7.3) for core token operations like `transfer` and `approve` follows the ERC-20 standard, while supply management (`_mint`, `_burn`) and initialization (`_init`) are internal, requiring a derived contract to implement external access control. No reentrancy or other complex attack vectors were identified due to the contract's straightforward design.

GovernanceLow10/10

The economic model (7.4) of the FourERC20 token is a standard ERC-20, with its supply mechanism left to a derived contract. If a derived contract implements minting/burning, there is a potential for centralized control over the token supply (L-01), which is a common design but introduces a centralization risk. There are no explicit governance mechanisms (7.5) within this base contract, meaning any governance would need to be implemented in a separate, higher-level contract. The contract does not interact with external protocols or oracles (7.6), limiting external economic dependencies.

UpgradesLow10/10

The FourERC20 contract is not designed as an upgradeable proxy (7.7). It is intended to be deployed as a standalone, immutable contract or as an implementation contract for a proxy pattern managed externally. Therefore, there are no direct upgrade safety risks inherent to this specific contract's code. Any upgradeability would be managed by a separate proxy contract, which would introduce its own set of upgrade-related considerations.

Security Checklist

5/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedPass
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

39.5% in top 10
11.8% in wallets27.7% in contracts
Effective Concentration22.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

$208.4K across 3 pairs
Pancakeswap v2WBNBanalysed$192.3K92.3%Pancakeswap v3USDT$15.5K7.4%UniswapUSDT$6550.3%

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 Burned100.0% · ≈ permanent lock
LP Locked100.0% · Null Address

Key Addresses

2 addresses
Deployer
0x2ba6…e3dc
Unlocked LP Held By
0x0417…065a

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

What Raised This Score

2 factors
  • Top-10 concentration > 20% (39.5% total → 22.9% effective; 11.8% in EOAs, 27.7% in contracts — mild)
  • 2 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

Related Audits

6 more on the record
TCryptochicks (TCC)Low Risk币安人生Low RiskSKYAILow RiskBLow RiskDOYRLow RiskCREPELow Risk

Would You Like a More Detailed Audit of BORT?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit