Quantum Audit Logo

Is Block Street Safe?

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

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

Block Street BSB
0x595d…79cc
BNB Chain
Not verifiedThis 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 18d ago 2 audits on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The audit of the TokenImplementation contract, serving as the logic for a BeaconProxy, reveals a well-structured ERC-20 token with standard functionalities. Key strengths include proper use of the `initializer` modifier for upgrade safety and adherence to basic ERC-20 standards. However, the contract exhibits a high degree of centralization, with a single owner having full control over token supply (mint/burn) and metadata updates. Additionally, while EIP-712 domain separator logic is present, the `permit` function itself is missing, indicating an incomplete feature implementation. The custom `Ownable` pattern also deviates from standard OpenZeppelin practices.

1 High1 Medium1 Low1 Informational
Volume 24h
$40.6K
Liquidity
$32.7K
Price
$0.1079
Token Age
4mo
Top 10 Holders
92.3%

Security Findings

1 High1 Med1 Low1 Info
High

Centralized Control over Token Supply and Metadata

H-01The `owner` address has the ability to `mint` and `burn` an arbitrary amount of tokens, directly affecting the total supply and value. Additionally, the `owner` can `updateDetails` (name, symbol) of the token. This grants significant centralized control over the token's economic properties and identity, posing a high risk if the owner's key is compromised or acts maliciously. This impacts 7.3 Access Control and 7.4 Economic aspects.
IssueThe `owner` address has the ability to `mint` and `burn` an arbitrary amount of tokens, directly affecting the total supply and value. Additionally, the `owner` can `updateDetails` (name, symbol) of the token. This grants significant centralized control over the token's economic properties and identity, posing a high risk if the owner's key is compromised or acts maliciously. This impacts 7.3 Access Control and 7.4 Economic aspects.
FixConsider implementing a multi-signature wallet or a time-locked governance contract to control the `owner` address. For critical functions like `mint` and `burn`, consider requiring multiple approvals or a delay period. Clearly document the extent of owner privileges and the security measures in place for the owner's private key.
StatusUnresolved
Medium

Missing `permit` Function for EIP-712 Support

M-01The contract includes extensive logic for EIP-712 domain separator generation (`_initializePermitStateIfNeeded`, `_domainSeparatorV4`, `_buildDomainSeparator`) and imports `ECDSA`, indicating an intention to support EIP-712 `permit` functionality. However, the actual `permit` function, which allows users to approve token transfers via a signed message without on-chain transactions, is not implemented. This leaves the EIP-712 infrastructure present but unused, resulting in an incomplete feature. This impacts 7.1 Architecture and 7.2 Code Security.
IssueThe contract includes extensive logic for EIP-712 domain separator generation (`_initializePermitStateIfNeeded`, `_domainSeparatorV4`, `_buildDomainSeparator`) and imports `ECDSA`, indicating an intention to support EIP-712 `permit` functionality. However, the actual `permit` function, which allows users to approve token transfers via a signed message without on-chain transactions, is not implemented. This leaves the EIP-712 infrastructure present but unused, resulting in an incomplete feature. This impacts 7.1 Architecture and 7.2 Code Security.
FixEither fully implement the EIP-712 `permit` function to provide the intended functionality, or remove the unused EIP-712 related code and imports to reduce contract size and improve clarity if the feature is not desired.
StatusUnresolved
Low

Custom `Ownable` Implementation Deviates from Standard

L-01The contract imports OpenZeppelin's `Ownable.sol` but does not inherit from it. Instead, it implements its own `owner()` function and `onlyOwner` modifier, managing the `_state.owner` variable directly. While functionally correct for this contract, this deviation from standard OpenZeppelin patterns might lead to confusion or unexpected behavior for developers expecting the full `Ownable` interface (e.g., `transferOwnership`, `renounceOwnership`). This impacts 7.1 Architecture and 7.2 Code Security.
IssueThe contract imports OpenZeppelin's `Ownable.sol` but does not inherit from it. Instead, it implements its own `owner()` function and `onlyOwner` modifier, managing the `_state.owner` variable directly. While functionally correct for this contract, this deviation from standard OpenZeppelin patterns might lead to confusion or unexpected behavior for developers expecting the full `Ownable` interface (e.g., `transferOwnership`, `renounceOwnership`). This impacts 7.1 Architecture and 7.2 Code Security.
FixConsider either inheriting from OpenZeppelin's `Ownable` to leverage its battle-tested implementation and standard interface, or explicitly documenting the custom ownership management to clarify expected behavior and available functions.
StatusUnresolved
Info

`updateDetails` Requires Sequence Increment

I-01The `updateDetails` function, which allows the owner to change the token's name and symbol, requires the `sequence_` parameter to be strictly greater than `_state.metaLastUpdatedSequence`. This mechanism prevents replaying old metadata updates but also implies that if an owner wishes to revert to a previous name/symbol (e.g., due to a typo), they must use a new, higher sequence number. This is a design choice, not a vulnerability, but it's an operational constraint. This impacts 7.8 Operations.
IssueThe `updateDetails` function, which allows the owner to change the token's name and symbol, requires the `sequence_` parameter to be strictly greater than `_state.metaLastUpdatedSequence`. This mechanism prevents replaying old metadata updates but also implies that if an owner wishes to revert to a previous name/symbol (e.g., due to a typo), they must use a new, higher sequence number. This is a design choice, not a vulnerability, but it's an operational constraint. This impacts 7.8 Operations.
FixEnsure this design choice is well-documented for operators. If flexibility to revert to previous metadata is desired without incrementing a sequence, the `require` statement would need to be adjusted, but this would also introduce the risk of replay attacks for metadata updates.
StatusUnresolved

Category Ratings

TechnicalMedium4/10

The technical implementation of the Token contract is generally robust, adhering to ERC-20 standards for core functionalities like `transfer` and `approve`. Solidity 0.8.0+ provides automatic overflow/underflow protection, enhancing code security (7.2 Code Security). However, the contract includes EIP-712 domain separator logic and imports `ECDSA` but lacks the actual `permit` function, leaving an intended feature incomplete (7.1 Architecture). The custom implementation of `owner()` and `onlyOwner` also deviates from standard OpenZeppelin `Ownable` patterns, potentially causing developer confusion.

GovernanceHigh1/10

The governance and economic model of the Token contract are highly centralized. A single `owner` address possesses significant power, including the ability to `mint` and `burn` an arbitrary amount of tokens, directly impacting the total supply and token value (7.4 Economic). Furthermore, this owner can `updateDetails` such as the token's name and symbol, which could affect its identity and perception (7.3 Access Control). This centralization introduces a high risk if the owner's private key is compromised or if the owner acts maliciously.

UpgradesHigh1/10

The contract is designed as an implementation for a BeaconProxy, leveraging OpenZeppelin's proxy patterns for upgradeability. The `initializer` modifier correctly prevents re-initialization on subsequent upgrades, ensuring state integrity (7.7 Upgrades). The use of a `TokenState` struct for all state variables is a good practice for storage layout compatibility across upgrades. This architecture generally supports safe and controlled upgrades, minimizing risks associated with future logic changes.

Security Checklist

1/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeBeacon
ImplementationVerified source

Holder Composition

92.3% in top 10
54.6% in wallets37.7% in contracts
Effective Concentration69.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

$34.5K across 3 pairs
UniswapUSDTanalysed$32.7K94.7%UniswapUSDT$9632.8%Pancakeswap v3USDT$8822.6%

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

9 addresses
Deployer
0x8901…df68
Unlocked LP Held By
0x8823…82e10x8854…46ed0x6458…2df50x612e…5e010x4694…a2cf0x4e9f…974e0x827b…a5830xfacd…2a14

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

What Raised This Score

12 factors
  • Ownership NOT renounced — owner is a contract (governance/executor, not an EOA)
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • Complex proxy pattern (BEACON)
  • Top-10 concentration > 50% (92.3% total → 69.7% effective; 54.6% in EOAs, 37.7% in contracts — heavy)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Liquidity < $50k ($34,542 across 3 pairs — thin market)
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk, pool = 95% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 95% of DEX liquidity)
  • 1 High finding(s) from audit
  • 1 Medium 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

Frequently Asked Questions

Is Block Street a scam?

Based on automated analysis, Block Street scores 64/100 (High Risk) on our risk scale. No honeypot was detected, but always verify independently before investing.

Is Block Street safe to buy?

Our scanner flagged a risk score of 64/100. Ownership has not been renounced, which is a risk factor. DYOR before purchasing any token.

Has Block Street been audited?

The contract has not been verified on-chain. Verification is not the same as a full security audit. Use Quantum Audit's free tool to run a deeper analysis of the contract code.

Related Audits

6 more on the record
LIGHTCritical RiskCea Industries (BNC4)Critical RiskDexeCritical RiskArcium (ARX)Critical RiskSolstice (SLX)Critical RiskFLOKICritical Risk

Would You Like a More Detailed Audit of Block Street?

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

Get Detailed Audit