Formion AI Info
Formion is a next-generation trading intelligence platform for crypto, forex, stocks, CFDs, perps and tokenised commodities. It combines AI signals, smart bots, visual trading tools and automated strategies to help traders analyze markets, act faster and trade with more control.
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.
Security Assessments
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 Formion (FOM) contract implements an ERC20 token with a fixed supply of one billion tokens that is created once at deployment, signature-based approvals following the EIP-2612 permit standard with signatures bound to the network and to the contract address, and no administrative functions of any kind. The token is built entirely on widely used OpenZeppelin components without any change to their transfer logic, and its test deployment on Base Sepolia was reproduced byte for byte from the audited source code.
Ownership Privileges
The ownership of the contract has been removed by design: the token has no owner, no administrator role and no upgrade mechanism, so no account retains any privileges over it after deployment. In practice this means:
- No account can mint new tokens; the total supply is fixed at one billion and can never increase.
- No account can pause transfers, freeze balances or blacklist addresses.
- No account can introduce or change transfer fees; recipients always receive exactly the amount that was sent.
- No account can upgrade, replace or alter the contract code, its name, its symbol or its decimals.
- The entire supply is minted to a single distribution address at deployment, and the contract does not verify that this address is a multi-signature wallet, so the safety of the initial distribution depends on the custody of that address.
- Tokens sent by mistake to the token contract's own address cannot be recovered, because no rescue function exists.
- As with every standard ERC20 token, changing an existing allowance can be front-run by the approved spender, and zero-value transfers can be used to create misleading entries in wallet histories.
- Applications that accept signed approvals should tolerate a signature that someone else has already submitted, otherwise their transactions can be made to fail.
Security Features
The contract implements several positive security features:
- A minimal and immutable design that relies on well-reviewed OpenZeppelin components, with no custom transfer logic and no calls to other contracts, which leaves no reentrancy surface.
- A truly fixed supply: the one billion tokens are created once and no function call can change the total, which was confirmed by formal reasoning over every function and by extensive property-based testing.
- Signed approvals protected against replay by a per-holder counter, an expiry time, rejection of malleable signatures and a signing domain tied to the network and the contract address, so a signature cannot be reused on another network or contract.
- Checked arithmetic and a pinned compiler version, whose known compiler issues were each reviewed and found not to apply to this build.
Note - This Audit report consists of a security analysis of the Formion (FOM) smart contract. This analysis did not include economic analysis of the contract's tokenomics. Moreover, we only audited the main contract for the Formion (FOM) team; the associated vesting wallets are covered in a separate statement. 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
optimization Issues | 1 findings
Pending
#1 optimization Issue
Constructor zero-address check duplicates the library's own validation
The constructor reverts with a custom error when the recipient is the zero address, but the inherited internal mint function performs the same check and reverts with a standard receiver error anyway. The extra comparison and error add a little deployment bytecode and gas without changing behaviour, because a zero recipient can never receive the supply either way.
informational Issues | 6 findings
Pending
#1 informational Issue
Standard ERC-20 approve race condition
The approve function overwrites the current allowance. A spender who watches pending transactions can spend the old allowance just before a change is confirmed and then spend the new allowance afterwards, so a holder who lowers an allowance from one value to another can lose the sum of both. The current library version no longer offers helper functions for increasing or decreasing an allowance, so the token provides no built-in alternative to the overwrite pattern.
Pending
#2 informational Issue
Zero-value transfers allow anyone to create misleading transfer records
A spender without any allowance passes the allowance check when the amount is zero, so any account can call transferFrom with a victim as the source, any destination and a zero amount. The call succeeds and the token emits a transfer event that appears to come from the victim. No balance changes, but combined with look-alike addresses this is the common address-poisoning technique, where users are tricked into copying an attacker's address from their own transaction history.
Pending
#3 informational Issue
Signed approvals can be front-run to make naive integrations revert
A signed approval becomes public as soon as the transaction carrying it is broadcast. Any third party can submit the same signature first, which consumes the holder's nonce and sets the allowance as intended. An integrating contract that calls permit and then transferFrom in one function will then revert, because the signature is no longer valid, even though the allowance it needs is already in place. No funds are at risk, but the user's action, such as a deposit or swap, fails and can be repeatedly disrupted.
Pending
#4 informational Issue
Tokens sent to the token contract itself are permanently lost
Transfers to the token's own address are accepted. The contract never spends its own balance and, having no owner, offers no rescue function, so tokens sent there by mistake can never be recovered. The same applies to any other token sent to this address. Sending tokens to the token contract is a frequent user error, and here it results in a permanent loss for the sender.
Pending
#5 informational Issue
Allowance reductions during transferFrom emit no event
The underlying library deliberately skips the approval event when transferFrom lowers an allowance, in order to save gas. The standard does not require this event, but indexers, allowance dashboards and revocation tools that rebuild allowances from events will show values that are higher than the real on-chain allowance. The state change itself is correct and there is no on-chain impact.
Pending
#6 informational Issue
Compiler version has known bugs, none of which apply
The contract is pinned to compiler version 0.8.28, which has six entries in the official list of known compiler bugs. Each of them requires conditions that are not present in this build, such as the alternative code generator, storage arrays at the very end of storage, or deleting single elements of in-memory byte arrays. The current release has no known bugs, and using it would avoid having to re-justify these items in future reviews.