Quantum Audit Logo
Launch App

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

Is BORT Safe?

BNB Chain
Not verified This record has not gone through deep verification and is not being monitored. The score is a dated snapshot — the token’s risk can change at any time.Own this token? Put it under verification →
Last checked Sep 4, 2026 · 1 audit on record
Chart
Low RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical10/10Governance10/10Upgrades10/10Checks passed7 of 7Findings2 Low · 2 Info4
SummaryAI Copilot

The FourERC20 contract is a standard ERC-20 token implementation, largely based on OpenZeppelin Contracts.

Read the full analysis
What raised the score
  • Top-10 concentration > 20%
  • 2 Low finding(s) from audit
Exact 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

Security Checklist

as of audit · Sep 47 of 7 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockLocked
UpgradeabilityFixed code
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026
27.7%Contracts11.8%Wallets60.5%Everyone else
27.7%Contracts11.8%60.5%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
39.5%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking27.7%
  • Walletsanonymous holders, free to sell11.8%
  • Everyone elsethe rest of the supply60.5%
Effective concentrationwhat the score reads22.9%
How holder types affect the score

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.

Holder balances as recorded by the audit of Sep 4, 2026

Liquidity

as of audit · Sep 4$208.4K across 3 pairs

The risk score reads depth across every pair.

LP tokensLocked

The LP tokens of the analysed pool are locked or burned.

Analysed pool$192.3KShare of depth92.3%
LP Burned100.0% · ≈ permanent lock
LP Locked100.0% · Null Address
Unlocked LP held by
0x0417…065a

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

Security Findings

2 Low2 Info
Low

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

If 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.L-01

Issue

If 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.

Fix

For 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.

Status

Unresolved

Low

Standard ERC-20 approve Front-Running Risk

The 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.L-02

Issue

The 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.

Fix

Educate 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.

Status

Unresolved

Info

Base Contract Design for Supply Management and Initialization

The 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.I-01

Issue

The 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.

Fix

Ensure 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.

Status

Unresolved

Info

Missing Events for _init Parameters

The _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).I-02

Issue

The _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).

Fix

Consider 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.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

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.

Technical10/10Low risk

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.

Governance10/10Low risk

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.

Upgrades10/10Low risk

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.

Final RecommendationWhat to do about this score

For any derived contract built upon FourERC20, ensure that external functions for _mint, _burn, and _init are implemented with robust access control, ideally using a multi-signature wallet or a time-locked governance mechanism to mitigate centralization risks.

Educate users on the safer increaseAllowance and decreaseAllowance functions to avoid potential front-running issues associated with the standard approve function. Consider emitting events for critical state changes, such as token initialization, to enhance transparency and off-chain monitoring capabilities.

Contract & Record

1 audit on record
TypeToken
NetworkBNB Chain
Token age10mo
Contract0x2a84…4444
Deployer0x2ba6…e3dc
Badge for your website
BORT security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History
  1. Sep 4, 20260Low

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Related Audits

6 more on the recordAll audits
TCryptochicksTCC · BNB Chain0Low币安人生BNB Chain0LowSKYAIBNB Chain0LowBBNB Chain0LowDOYRBNB Chain0LowCREPEBNB Chain0Low

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 Is this your token? Publish your own audit on this page