BullskiCoin Info
Bullski is a community driven meme coin on Ethereum, built to ride through every market cycle. Here is the story, the mission, and everything you need to know before the presale.
Team and KYC Verification
The KYC verification for this project is currently in progress.
The team has submitted their information and verification is pending.
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.
Token transfer can be locked
Owner can lock user funds with owner functions.
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 BULLSKI contract implements an ERC20 token with a fixed supply that is minted once at deployment, a burn capability available to every holder, and a single one-way launch switch that keeps trading against registered liquidity pairs closed until the owner opens the market. There are no taxes, no fees, no reflection, no rebasing, no blacklist, and no upgrade mechanism. Ordinary wallet-to-wallet transfers are always allowed, and once trading is enabled the restriction is removed permanently. The version of the contract that is live on-chain was reproduced exactly from the reviewed source, and at the time of review trading had not yet been enabled.
Ownership Privileges
The ownership of the contract has been retained by a single externally owned account that, at the time of review, had not been renounced and was not a multi-signature wallet. The owner retains full privileges including:
- Enable public trading once, in a way that cannot be reversed
- Register or de-register the addresses that are treated as trading pairs
- Burn tokens from the owner's own balance
- Transfer ownership of the contract or give it up entirely
- The owner cannot create new tokens after deployment, because the supply is fixed
- The owner cannot charge any fee or tax on transfers
- The owner cannot freeze, seize, or blacklist the balances of other holders once the market is open
- The owner cannot change or upgrade the contract logic, which is immutable
The most important point for holders and prospective buyers is that the privileged powers are concentrated in the pre-launch phase. After trading is enabled the transfer gate no longer has any effect, and the remaining owner actions cannot touch other people's balances. The main consideration is therefore trust in the owner around launch timing and around the supply the owner already holds, since at deployment the owner holds the entire supply. Moving ownership to a multi-signature wallet and adding a delay before administrative changes take effect would reduce this concentration of control.
Security Features
The contract implements several positive security features:
- It is built on widely used, audited token and ownership components, and the deployed code matches the reviewed source exactly
- It relies on checked arithmetic and reverts on any overflow or underflow, and the supply can only ever decrease through burning
- It makes no external calls and exposes no token callbacks, which removes the usual reentrancy exposure
- Wallet-to-wallet transfers are always permitted and the trading restriction is lifted permanently once enabled, so holders cannot be locked in, and there is no fee, blacklist, or minting power that could be abused after launch
Note - This Audit report consists of a security analysis of the BULLSKI smart contract. This analysis did not include economic analysis of the contract's tokenomics. Moreover, we only audited the main contract for the BULLSKI 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
Findings and Audit result
medium Issues | 2 findings
Pending
#1 medium Issue
Centralized control and single point of failure
All administrative power is concentrated in a single owner account, which on-chain is an externally owned account rather than a multi-signature wallet, and there is no timelock or two-step handover. The owner alone decides if and when public trading is switched on, can register or de-register the addresses treated as trading pairs, and at deployment holds the entire token supply. Because trading is gated until the owner enables it, the owner can postpone or withhold activation of the official market indefinitely, and a lost or compromised owner key would either freeze that decision or allow the whole supply to be moved at once.
Pending
#2 medium Issue
Owner can selectively restrict arbitrary addresses before launch
The pair registry accepts any address, not only genuine liquidity-pool contracts. While trading is disabled, marking an address as a pair blocks every transfer involving it unless the other side is the owner, so the marked account cannot send to or receive from any ordinary holder and can only move tokens back to the owner or burn them. This gives the owner a selective, temporary freeze over any chosen address that behaves like a pre-launch blacklist, which is at odds with the project's stated lack of a blacklist. The effect is removed permanently once trading is enabled, and it only causes real harm when tokens are already held by third parties before launch, so the severity depends on whether pre-launch distribution takes place.
low Issues | 2 findings
Pending
#1 low Issue
Ownership transfer is single-step
Ownership is transferred in a single step, so handing it to an address with a typo, or to a contract that cannot act as owner, takes effect immediately and cannot be undone. This is especially sensitive before trading is enabled, because the ability to switch trading on lives only with the owner, and an unrecoverable transfer would leave the registered pair permanently gated.
Pending
#2 low Issue
Renouncing ownership before launch permanently disables trading
Renouncing ownership sets the owner to the zero address. If this is done while trading is still disabled, the function that switches trading on can never be called again, which permanently leaves any registered pair gated and also disables the owner burn helper and pair management. There is no safeguard that prevents renouncement while trading is disabled.
optimization Issues | 3 findings
Pending
#1 optimization Issue
Redundant storage read in the transfer hook
On every transfer while trading is disabled, the hook reads the owner from storage even when the transfer is a mint or a burn, where the owner value is not needed. Reading it only after confirming the transfer is not a mint or burn would avoid an unnecessary storage read on those paths.
Pending
#2 optimization Issue
Combined condition could be split for minor savings
The pre-launch restriction combines two negated conditions in a single statement. Expressing them as nested checks can let the runtime skip the second evaluation more often. The effect on gas is negligible for this logic.
Pending
#3 optimization Issue
Redundant timestamp in event payload
The trading-enabled event stores the block timestamp, which is already available from the block that contains the event. Emitting it as event data adds a small cost without adding information.
informational Issues | 9 findings
Pending
#1 informational Issue
Floating compiler version
The source uses a floating compiler version of caret 0.8.20, which allows compilation with any 0.8.x release at or above 0.8.20. Although the deployed artifact was built with 0.8.20, leaving the version floating means a future recompilation could use a different compiler and produce slightly different behavior or bytecode.
Pending
#2 informational Issue
Unreachable zero-address check in the constructor
The constructor checks the initial owner against the zero address after the inherited ownership component has already been initialized with the same value. That base initialization runs first and itself rejects the zero address, so the later check can never be reached and the contract's own zero-address error is never the one returned for this case.
Pending
#3 informational Issue
Maximum supply constant is really a fixed initial supply
The constant presented as a maximum supply is only used as the amount minted once at deployment. Nothing enforces it as an ongoing ceiling, and because tokens can be burned the circulating amount can fall below it and can never rise again. The name may lead integrators to assume a minting capability up to this value exists, which it does not.
Pending
#4 informational Issue
Duplicate burn interface and event
A dedicated owner burn helper duplicates the burn capability already inherited and available to every holder, and it emits a custom burn event in addition to the standard transfer-to-zero event that the burn already produces. Systems that watch both events could double-count burned amounts.
Pending
#5 informational Issue
Standard ERC20 approval race condition (standards caveat)
This is inherent behavior of the standard approval method, which overwrites the existing allowance and therefore exposes the well-known race in which a spender can use both the old and the new allowance if an allowance change is front-run. It is not specific to this contract and applies to standard tokens generally, and no incremental allowance helpers are available to soften it.
Pending
#6 informational Issue
Pre-launch gate is a soft control for the general population
The general pre-launch restriction only applies to addresses the owner has explicitly registered as pairs, so holders who have not been flagged can still transfer freely between ordinary wallets, and trading could in principle occur through a pool that has not been registered. For the unflagged population the gate behaves as a soft launch control rather than a strict lock. The separate ability of the owner to flag specific addresses is described in its own finding.
Pending
#7 informational Issue
Trading activation can be front-run by snipers
Enabling trading is a public transaction that is visible in the mempool before it is mined. Automated buyers can observe it and place a purchase in the same block, gaining an advantage over ordinary participants at launch. The contract contains no measures to discourage this.
Pending
#8 informational Issue
Large numeric literal is a readability preference
The supply constant is written as a grouped integer multiplied by a power of ten. Whether it is written this way or in scientific notation, the compiler folds it to the same value, so there is no effect on behavior, bytecode, or gas. The point is purely about readability.
Pending
#9 informational Issue
No recovery path for assets sent to the contract
The contract has no function to move out assets that end up at its own address, and it has no way to accept or withdraw native currency. Tokens of this or any other kind that are accidentally transferred to the contract address cannot be retrieved, and native currency that is force-sent to the address would also be permanently stuck. This is a common situation for simple tokens and has no effect on normal balances, but the funds involved are unrecoverable.