Chainspin Info
Bet on global sports markets or step into the casino with live dealers, slots, and table games. chainSpin blends sportsbook action and casino play with blockcain-powered rewards - built for speed, fariness, and ownership.
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 renounced
The contract does not include owner functions that allow post-deployment modifications.
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 Chainspin contract implements an ERC20 token with a one-off fixed issuance of one billion units at eighteen decimals and an optional burn function that holders may use on their own balance. It is an unmodified composition of a widely used and well established token library plus an eleven line contract of its own, whose only task is to mint the full supply to a single address at deployment. There is no owner, no role system, no way to create further tokens after deployment, no pause switch, no blacklist, no transfer fee, no proxy and no external call of any kind anywhere in the code. The published source was confirmed to correspond exactly to the code running on the network, including the compiler fingerprint, so what is readable on the block explorer is precisely what executes. The review found no critical and no high severity issues, and every accounting property that matters was proven across the full range of possible inputs and then stress tested with roughly seven hundred and fifty thousand randomised interactions without a single deviation.
Ownership Privileges
The ownership of the contract has been eliminated by design rather than renounced after the fact, since no owner, administrator or privileged role was ever created. What remains is purely economic control through token custody, and the picture is as follows:
- The address named at deployment received the entire issuance of one billion tokens in a single step, and on-chain records confirm it still holds one hundred percent of the supply.
- That address is an ordinary single key account rather than a shared wallet requiring several approvals, it was created shortly before launch, and the deployment is the only transaction it has ever sent.
- No vesting arrangement, time lock or published distribution schedule constrains that holding, so the whole float can be moved or sold in one transaction at any moment.
- Any holder, including that address, may permanently destroy tokens they own, and anyone granted an allowance may destroy the approving holder's tokens rather than merely transferring them.
- No party, including the deployer, can create additional tokens after deployment, so the supply can only ever fall and never rise.
- No party can pause transfers, freeze an account, blacklist an address or block a holder from selling, which removes the usual set of mechanisms behind trapped funds.
- No party can introduce a transfer fee, redirect value to a hidden recipient or alter the token name, ticker or decimals, all of which are fixed for the contract's lifetime.
- No party can upgrade, replace or shut down the contract, because it is not a proxy, contains no code replacement mechanism and cannot be destroyed.
Security Features
The contract implements several positive security features:
- The absence of privileged functions is structural rather than merely restricted, so the most common causes of token loss, namely a hidden issuance path, a trading switch, arbitrary account freezing and an upgrade backdoor, are not present to be abused or leaked through a compromised key.
- The contract makes no external call at all and contains no low level or inline machine code, which removes the entire class of reentrancy, callback and gas exhaustion problems by construction rather than by defensive guards.
- All arithmetic is protected by the compiler's built in overflow checks, the four places where those checks are deliberately skipped were each verified to be provably safe, and the one addition that governs total supply is left fully checked so the supply figure can never wrap.
- The contract contains no loops, no growing lists and no iteration over holders, so every operation costs a predictable amount of gas and no participant can make the token unusable for others by inflating its internal state.
- All state is written at the moment of deployment in a single indivisible step, so there is no separate setup call that an outsider could race to claim control of, and the transfer history confirms the initial issuance was the first and only such event.
- The token conforms fully to the ERC20 standard, with every required function present using the correct types and every event correctly indexed, which reduces the chance of integration failures with exchanges, wallets and custodians.
Points Requiring Attention
Three matters fall outside the code itself and deserve attention before any broad distribution:
- The concentration of the entire supply in one single key account with no vesting or shared control is the single largest risk to holders. Moving the holding into a wallet requiring multiple independent approvals, placing everything not needed for immediate liquidity under a time lock, and publishing the intended allocation together with the receiving addresses would reduce it substantially without touching the contract.
- A separate deployment of the same contract, carrying the same token name and ticker and the same one billion issuance, is already live and distributed on another network, with no bridge or shared accounting linking the two. Two billion tokens have therefore been issued in total while each contract advertises one billion. The team should state clearly which deployment is the official one and either verifiably retire the other supply or quote the combined figure consistently.
- The contract was compiled with optimisation switched off. This has no security consequence, but the deployed code is around twice the size it needs to be and every holder pays a small permanent premium on every interaction. It cannot be corrected without deploying a new contract, and should simply be avoided next time.
Note - This Audit report consists of a security analysis of the Chainspin smart contract. This analysis did not include economic analysis of the contract's tokenomics. Moreover, we only audited the main contract for the Chainspin team. Other contracts associated with the project were not audited by our team, and we note specifically that despite the file name used when the source was published, the reviewed file contains no presale logic whatsoever, so any presale contract is a separate and unreviewed deployment. We recommend investors do their own research before investing.
Files and details
Findings and Audit result
low Issues | 4 findings
Pending
#1 low Issue
Allowance changes can be front-run
The approve function overwrites the stored allowance instead of comparing it against an expected current value. A spender who is watching pending transactions can therefore see an approval being lowered, spend the full old allowance first, and then spend the new one as well, ending up with more than the holder ever intended to grant. The contract offers no increaseAllowance or decreaseAllowance helper and no signature based approval, so there is no built-in way to avoid the race. This is a long-standing characteristic of the token standard rather than a coding mistake, and it was reproduced in testing where a spender obtained 150 tokens from an allowance that the holder had reduced from 100 to 50.
Pending
#2 low Issue
An approved spender can permanently destroy a holder's tokens
The burnFrom function lets anyone holding an allowance destroy the approver's tokens outright rather than merely moving them. Because unlimited approvals to routers, exchanges and other integrations are common practice, a spender contract that is compromised or turns hostile can wipe out a holder's balance with no way to recover it and with no benefit to itself. This goes beyond what most users understand an approval to mean, since the usual expectation is that a spender can at worst take the tokens, not delete them. The behaviour was reproduced in testing where a spender with an unlimited allowance destroyed a holder's entire balance while gaining nothing.
Pending
#3 low Issue
Assets sent to the token contract can never be recovered
The contract has no owner, no recovery entry point and never grants an allowance over its own balance, so any tokens transferred to the contract address are frozen for good. Ether cannot be sent through a normal transfer because there is no payable entry point, but it can still be forced in by other means, and once there it is equally stuck. The constructor only rejects the empty address as the supply recipient, so a deployment that pointed the initial mint at the contract's own address, which is predictable in advance, would have locked the entire supply immediately. This did not happen in the live deployment, where the supply went to a normal account, and both behaviours were reproduced in testing.
Pending
#4 low Issue
The published maximum supply drifts away from the real supply after any burn
The maximum supply is stored as a fixed compile-time value that is written once and never updated, while the real supply falls every time somebody burns tokens. From the first burn onwards the two numbers disagree permanently and there is no way to bring them back together, because the contract has no way to issue new tokens. Anything that uses the fixed value as a denominator, such as an ownership percentage, a market capitalisation figure or a reward share, will progressively understate the true position. Testing confirmed the effect, where a holder of the entire remaining float appeared to hold only half of the supply when measured against the fixed constant.
optimization Issues | 3 findings
Pending
#1 optimization Issue
The contract was compiled and deployed with the optimizer switched off
The published compiler settings show that optimization was disabled when the contract was built, even though the deployment metadata still records a run count. The effect was measured by rebuilding the identical source with optimization enabled and comparing the two. The deployed code occupies 3911 bytes against 1969 bytes, roughly double, and deployment consumed about 1023000 gas against about 587000, an overhead of around 74 percent. Ordinary usage is also affected for as long as the token exists, with a transfer costing about 564 gas more, an approval about 574 gas more, a delegated burn about 712 gas more, and simple balance lookups around 11 percent more. Nothing here is a security problem, but every holder pays the difference on every interaction.
Pending
#2 optimization Issue
The token name and ticker are read from contract storage on every call
The token name and ticker are held in ordinary contract storage rather than being fixed into the code at deployment, so each call to read them performs a storage lookup. Measurements put the name and symbol lookups at just over 3300 gas each under the settings actually used. Because both values are short and can never change after deployment, they could have been embedded in the code instead. This is inherited behaviour from the standard library the contract is built on and has no security impact.
Pending
#3 optimization Issue
The constructor rejects a bad recipient with a text message rather than a typed error
The only validation the contract performs at deployment rejects an empty recipient address using an embedded text message. The message string has to be stored in the compiled code and returned in full when the check fails, which costs more space and gas than a typed error would. Every other failure path in the contract already uses typed errors, so this one line is inconsistent with the surrounding style as well as slightly more expensive. The impact is limited to the deployment transaction and to a deployment that would have failed anyway.
informational Issues | 9 findings
Pending
#1 informational Issue
The file name advertises presale functionality that the contract does not contain
The reviewed file is named as though it were a flattened presale contract, and the same name is carried over into the publicly verified code listing, yet the file contains only a token and the standard library code it depends on. There is no sale logic, no pricing, no contribution handling and no claim mechanism anywhere in it. Anyone reading the published source may reasonably conclude that a presale was part of the reviewed code when it was not. If a presale contract does exist elsewhere, it is a separate deployment that has not been examined here, and it would be the component holding investor funds.
Pending
#2 informational Issue
Unreachable interfaces and helper functions were left in the source
The flattened file carries two complete error interfaces belonging to other token standards, contributing fifteen error definitions that nothing in the contract can ever raise, along with two helper functions in the context base contract that are never called. None of this reaches the compiled code, so there is no gas or size penalty on the deployed contract, and there is no security consequence. The only cost is that the published source is larger than it needs to be and includes declarations that hint at functionality the token does not actually have.
Pending
#3 informational Issue
The compiler release used has two open defects, neither of which affects this contract
The compiler release used for this deployment is listed as being affected by two defects of moderate severity, and the public code listing displays a warning about them. Both were examined against this contract and neither can be triggered. The first requires a manual storage placement directive that positions variables near the very end of the address space, and the contract uses no such directive. The second requires the alternative code generation pipeline together with a set of functions that call each other in a cycle, and this deployment used the standard pipeline and contains no recursion at all. Both are corrected in a later compiler release.
Pending
#4 informational Issue
Transfers of zero tokens are accepted and produce a full transfer record
A transfer of zero tokens succeeds from any address, including one that has never held the token, and produces a transfer record naming both the claimed sender and the recipient in searchable form. This is required behaviour under the token standard and is not a defect, but it is the mechanism behind wallet history poisoning, where an attacker generates records from an address that resembles one the victim trusts in the hope that the victim later copies the wrong address from their transaction history. The behaviour was confirmed in testing using an account with no balance at all.
Pending
#5 informational Issue
No approval record is produced when an allowance is consumed
When a delegated transfer consumes part of an allowance, the contract updates the stored value but deliberately does not publish an approval record for the change. The token standard does not require one and omitting it saves gas, so this is a considered design decision inherited from the standard library. The consequence is that any external service which reconstructs allowances purely from published records, without reading the contract state, will show values that are higher than the real ones. Testing confirmed that a delegated transfer produces only a transfer record and nothing else.
Pending
#6 informational Issue
The older allowance adjustment helpers are not available
The two helper functions that older versions of the standard library provided for raising and lowering an allowance without overwriting it are absent, because the library version this contract is built on removed them. Any older integration that still calls them will fail outright rather than falling back to setting the allowance directly. This is expected behaviour for the library version in use and is not a defect, but it is a compatibility detail worth knowing about when connecting the token to established tooling. Their absence was confirmed by calling both.
Pending
#7 informational Issue
Signature-based approvals are not supported
The token does not implement approvals by signed message, so every allowance must be granted in a separate transaction paid for by the holder. This limits convenience for holders and for applications that would prefer to bundle an approval with the action that consumes it. The flip side is that the contract carries no signature verification at all, which removes an entire class of risk around replayed signatures, expired deadlines and signing domains that is a recurring source of problems in tokens that do offer the feature. Nothing was found to suggest the omission was accidental.
Pending
#8 informational Issue
Documentation and published metadata do not fully match the contract
The contract describes itself as fixed supply, while the burn functions it deliberately exposes allow the supply to fall at any time, so the supply is better described as capped at issuance and deflationary thereafter. Separately, the source declares a permissive licence in its header but the public code listing records no licence at all, which is a metadata inconsistency introduced when the code was submitted for verification rather than a problem with the code. Neither point has any effect on how the contract behaves, and the reviewed source was confirmed to correspond exactly to the deployed code.
Pending
#9 informational Issue
A second token with the same name and the same one billion supply exists on another network
An earlier deployment of the same contract, carrying the same token name and ticker and the same one billion issuance, is live and already distributed on a second network. Each contract independently reports a maximum supply of one billion, so the amount actually issued across both networks is two billion, which is double the figure that either contract advertises. The two are entirely separate tokens with no bridge, no linked issuance or redemption mechanism and no shared accounting, so holders on one network are exposed to the float on the other without any on-chain way to observe or reconcile it, and neither contract identifies itself as the official one. This is a matter of how the supply is represented rather than a flaw in the code, but it directly affects how the token should be valued.