Brica Capital Info
BRX is a utility-driven, community-first blockchain ecosystem architected to bridge the gap between blockchain innovation and real-world economic activity.
TrustNet Score
The TrustNet Score evaluates crypto projects based on audit results, security, KYC verification, and social media presence. This score offers a quick, transparent view of a project's credibility, helping users make informed decisions in the Web3 space.
Real-Time Threat Detection
Real-time threat detection, powered by Cyvers.io,
is currently not
activated
for this project.
This advanced feature provides continuous monitoring and instant alerts to safeguard your assets from potential security threats. Real-time detection enhances your project's security by proactively identifying and mitigating risks.
For more information, click here.
Summary and Final Words
No crucial issues found
The contract does not contain issues of high or medium criticality. This means that no known vulnerabilities were found in the source code.
Contract owner cannot mint
It is not possible to mint new tokens.
Contract owner cannot blacklist addresses.
It is not possible to lock user funds by blacklisting addresses.
Contract owner cannot set high fees
The fees, if applicable, can be a maximum of 25% or lower. The contract can therefore not be locked. Please take a look in the comment section for more details.
Contract cannot be locked
Owner cannot lock any user funds.
Token cannot be burned
There is no burning within the contract without any allowances
Ownership is not renounced
The owner retains significant control, which could potentially be used to modify key contract parameters.
Contract is not upgradeable
The contract does not use proxy patterns or other mechanisms to allow future upgrades. Its behavior is locked in its current state.
Scope of Work
This audit encompasses the evaluation of the files listed below, each verified with a SHA-1 Hash. The team referenced above has provided the necessary files for assessment.
The auditing process consists of the following systematic steps:
- Specification Review: Analyze the provided specifications, source code, and instructions to fully understand the smart contract's size, scope, and functionality.
- Manual Code Examination: Conduct a thorough line-by-line review of the source code to identify potential vulnerabilities and areas for improvement.
- Specification Alignment: Ensure that the code accurately implements the provided specifications and intended functionalities.
- Test Coverage Assessment: Evaluate the extent and effectiveness of test cases in covering the codebase, identifying any gaps in testing.
- Symbolic Execution: Analyze the smart contract to determine how various inputs affect execution paths, identifying potential edge cases and vulnerabilities.
- Best Practices Evaluation: Assess the smart contracts against established industry and academic best practices to enhance efficiency, maintainability, and security.
- Actionable Recommendations: Provide detailed, specific, and actionable steps to secure and optimize the smart contracts.
A file with a different Hash has been intentionally or otherwise modified after the security review. A different Hash may indicate a changed condition or potential vulnerability that was not within the scope of this review.
Final Words
The following provides a concise summary of the audit report, accompanied by insightful comments from the auditor. This overview captures the key findings and observations, offering valuable context and clarity.
Smart Contract Analysis Statement
Contract Analysis
The BRICA (BRX) contract implements a fixed-supply ERC20 token with EIP-2612 permit support, a holder-initiated burn function and a one-shot pre-launch trading gate. While the overall design follows common patterns on BNB Smart Chain and leans almost entirely on battle-tested OpenZeppelin v5 primitives, a few areas need attention:
- The pre-launch trading gate can be turned into a permanent, irreversible global freeze if the owner calls
renounceOwnership()beforeenableTrading(), since no logic prevents this ordering. - The owner is currently a single externally owned account without multisig or timelock protection, which concentrates significant operational trust in one private key.
- The entire 1,000,000,000 BRX supply is minted to one address at construction, creating a single point of failure if that key is lost or compromised before distribution is complete.
- Minor hardening items were identified, including a floating Solidity pragma, missing events for exclusions set inside the constructor, and the absence of zero-address and no-op guards in the exclusion setter.
Ownership Privileges
The ownership of the contract has been assigned to a single externally owned account at deployment (0x8c93…24Be) and has not been transferred to a multisig or timelock. The owner retains the following privileges and is subject to the following limitations:
- Enable trading globally via
enableTrading(). This is a one-way switch: once enabled, trading can never be disabled again. - Add or remove addresses from the pre-launch allowlist via
setExcluded(address,bool). While trading is disabled, only listed addresses can send or receive tokens, which effectively gives the owner a global pause control. - Transfer ownership to any address (including the zero address via
renounceOwnership()). There is no two-step acceptance and no time delay. - Sign or co-ordinate launch operations such as liquidity seeding, since the deployer address is also the initial token holder of the full supply.
- The owner cannot mint new tokens. There is no mint function beyond the one-time call in the constructor, so the maximum supply is hard-capped at 1,000,000,000 BRX.
- The owner cannot set or change any transfer fees, taxes or commissions. The contract contains no fee logic of any kind.
- The owner cannot blacklist holders, freeze individual balances, or reverse transfers once trading has been enabled. The exclusion mapping is only read before launch and is never consulted again afterwards.
- The owner cannot upgrade, migrate or replace the contract code. There is no proxy, no delegatecall, no upgrade hook and no self-destruct, so the deployed bytecode is immutable.
Security Features
The contract implements several positive security features:
- Built on audited OpenZeppelin v5 components (
ERC20,ERC20Permit,Ownable) with no custom arithmetic and no external calls, which removes the most common classes of vulnerabilities such as reentrancy, unsafe math and unchecked low-level calls. - Fixed maximum supply of 1,000,000,000 BRX is minted exactly once at construction and cannot be inflated afterwards, giving holders strong and verifiable supply guarantees.
- No upgradeability, no proxy pattern and no
selfdestruct, so the deployed logic on BNB Smart Chain is permanent and cannot be silently changed by any party. - Full compliance with the ERC20 and EIP-2612 (permit) standards, including correct event signatures and indexed parameters, which ensures smooth integration with wallets, bridges, indexers and decentralized exchanges.
- The
enableTrading()switch is one-way, removing an entire class of rug vectors where an owner could repeatedly pause and resume trading to manipulate liquidity or trap holders.
Note - This Audit report consists of a security analysis of the BRICA (BRX) smart contract. This analysis did not include economic analysis of the contract's tokenomics. Moreover, we only audited the main contract for the BRICA team. Other contracts associated with the project were not audited by our team. We recommend investors do their own research before investing.
Files and details
Functions
public
/
State variables
public
/
Total lines
of code
/
Capabilities
Hover on items
/
Findings and Audit result
medium Issues | 1 findings
Pending
#1 medium Issue
Permanent token freeze if ownership is renounced before launch
The function enableTrading() is onlyOwner and is the single mechanism that flips tradingEnabled from false to true. The inherited Ownable.renounceOwnership() sets the owner to the zero address. If the owner renounces ownership while tradingEnabled is still false, the token is permanently stuck in pre-launch mode: every transfer between two non-excluded holders will revert with "BRX: trading not enabled" forever, and the exclusion list can never be changed again either. Only accounts already in isExcludedFromTrading will still be able to move tokens. The live on-chain state shows tradingEnabled = false and the owner is a plain EOA without any multisig or timelock protection, which makes this failure mode a realistic operational risk.
low Issues | 2 findings
Pending
#1 low Issue
Centralized pre-launch allowlist acts as an emergency pause under single-EOA control
While tradingEnabled is false, only accounts marked in isExcludedFromTrading may transfer tokens. The owner, which is currently a single externally owned account, can freely add or remove addresses from this allowlist through setExcluded. In practice this gives the owner a global pause over the token since enableTrading() has not yet been called. There is no timelock, no multi-party approval, and no on-chain constraint that limits how long this pre-launch state can persist, which concentrates significant trust in one private key.
Pending
#2 low Issue
Floating Solidity pragma
The source file declares pragma solidity ^0.8.26;, which allows any compiler version greater than or equal to 0.8.26 within the 0.8.x range. For production contracts it is a best practice to lock the compiler to a single version so that the audited bytecode and the deployed bytecode remain byte-identical and cannot be affected by future compiler changes.
optimization Issues | 3 findings
Pending
#1 optimization Issue
Unnecessary storage writes and events in setExcluded
setExcluded always writes to the isExcludedFromTrading mapping and always emits ExclusionUpdated, including when the new value is identical to the current one. Each unchanged-value call therefore pays for a full SSTORE and an event emission that carry no semantic value.
Pending
#2 optimization Issue
Trading gate check can be marked unchanged once trading is enabled
After launch the _update function still performs a dedicated SLOAD of tradingEnabled on every single transfer, even though the value will never change again. The current cost (one warm SLOAD per transfer) is very small, but because _update is on the hot path for every token movement, pre-computing or packing this flag can deliver a measurable improvement across the lifetime of the token.
Pending
#3 optimization Issue
Use custom errors instead of revert strings
The contract uses string-based revert messages in require statements. Since Solidity 0.8.4 custom errors are the recommended pattern and are cheaper both in deployment size and in runtime gas when a revert is triggered, while also integrating better with ABI-aware off-chain tooling.
informational Issues | 6 findings
Pending
#1 informational Issue
Missing events for exclusions set inside the constructor
In the constructor, isExcludedFromTrading[initialHolder] and isExcludedFromTrading[address(this)] are set to true directly, without emitting the ExclusionUpdated event. Any off-chain system (indexer, dashboard, explorer, analytics backend) that reconstructs the allowlist purely from events will therefore have an incomplete view and will miss the two initial entries.
Pending
#2 informational Issue
setExcluded lacks zero-address and no-op guards
setExcluded(account, status) always writes to storage and emits ExclusionUpdated, even when the new value equals the current value. This wastes gas and produces misleading log entries. The function also accepts address(0); although zero-address transfers bypass the gate anyway and therefore the mapping value is never read for that key, defensive programming would still reject the zero address explicitly.
Pending
#3 informational Issue
setExcluded remains callable after launch although the mapping is no longer consulted
After enableTrading() has been called, _update no longer reads isExcludedFromTrading at all, so the mapping becomes dead storage. However, setExcluded is still callable by the owner and keeps mutating that mapping and emitting ExclusionUpdated events. Observers can reasonably interpret these post-launch events as meaningful changes, which is confusing and gives the owner a residual permission that serves no purpose.
Pending
#4 informational Issue
Custom burn wrapper duplicates functionality already available in OpenZeppelin
The contract defines a small wrapper function burn(uint256) that calls _burn(msg.sender, amount). OpenZeppelin already ships ERC20Burnable, an extension that provides both burn and burnFrom with well-reviewed semantics. Reimplementing the feature locally adds surface area that must be maintained and does not expose burnFrom.
Pending
#5 informational Issue
Ownership transfer is not two-step
The contract uses OpenZeppelin's single-step Ownable. Its transferOwnership function atomically sets the new owner, which means a typo or a compromised interface can irrevocably transfer administrative control to a wrong address. Ownable2Step is the industry-standard pattern to mitigate this risk.
Pending
#6 informational Issue
PUSH0 opcode target and cross-chain deployment considerations
From Solidity 0.8.20 onwards the default EVM target is Shanghai, which introduces the PUSH0 opcode. BNB Smart Chain supports Shanghai so the deployed bytecode is fine on the current network. This finding is recorded purely as a cross-chain portability reminder: certain sidechains and L2s do not yet support PUSH0 and would reject the exact same bytecode.