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 FOM Vesting contracts implement a set of five non-revocable vesting wallets that together hold 600 million FOM, or 60 percent of the supply. A custom wallet releases the 54.4 million token private backer allocation in twenty equal monthly tranches after a six-month cliff. Four standard OpenZeppelin vesting wallets release the team allocation of 150 million tokens linearly over 24 months after a twelve-month cliff, the marketing allocation of 100 million and the advisor allocation of 50 million linearly over 18 months after a six-month cliff, and the treasury allocation of 245.6 million linearly over 36 months from launch. All five wallets of the Base Sepolia test deployment were reproduced byte for byte from the audited source code, and the custom schedule behaves exactly as documented.
Ownership Privileges
The ownership of each wallet has been assigned to its beneficiary: the backer and team wallets belong to their recipients, while the marketing, advisor and treasury wallets belong to the project's distribution Safe. No deployer or administrator role exists. The beneficiary of each wallet retains full privileges including:
- Receiving every released amount; anyone may trigger a release, but the tokens are always paid to the current beneficiary.
- Transferring the vesting stream to another address, which takes effect immediately and also makes positions transferable before they have vested.
- Renouncing ownership, which permanently locks every token that has not yet been released, because releases would then be sent to an address that cannot receive them.
- For the three wallets owned by the distribution Safe, deciding how vested tokens are used, since the end recipients of the marketing and advisor allocations are not fixed on-chain.
- Nobody, including the project team, the deployer or the Safe, can accelerate, pause, revoke or claw back a vesting schedule.
- Start times, durations, tranche counts and the release rules cannot be changed after deployment, and the contracts are not upgradeable.
- The deployment script does not yet validate its start time and addresses, so the parameters of every mainnet wallet should be checked before funding, because mistakes cannot be corrected afterwards.
- Tokens added to a wallet after its start follow the schedule as if they had been locked from the beginning, so part of such a top-up becomes releasable immediately.
Security Features
The contract implements several positive security features:
- The custom schedule is small and correct: nothing vests before the start, exactly one tranche is added per period, the full allocation is available from the last tranche onwards, and the vested amount never decreases or exceeds the allocation, which was confirmed by formal reasoning and extensive property-based testing.
- Releases update their accounting before transferring tokens, contain no loops and keep each token's accounting separate, so neither reentrancy nor a misbehaving token can affect the FOM allocation.
- Schedule parameters are stored as immutable values and no administrative function exists, which removes any possibility of manipulating a schedule after deployment.
- The wallets reuse the widely used OpenZeppelin vesting implementation and change only the schedule calculation, using checked arithmetic and rounding in favour of the lock.
Note - This Audit report consists of a security analysis of the FOM Vesting smart contracts. 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 FOM token itself is 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
low Issues | 2 findings
Pending
#1 low Issue
Beneficiaries can irreversibly renounce or misdirect a vesting stream
Each vesting wallet is owned by its beneficiary, and every release is paid to the current owner. Renouncing ownership sets the owner to the zero address, after which every token release tries to pay the zero address and reverts. Because the wallets have no administrative recovery, all unreleased tokens then stay locked forever, and any ether held by the wallet can be pushed to the zero address by anyone. Transferring ownership takes effect immediately in a single step, so a mistyped or unusable address permanently receives the rest of the stream. One mistaken call can lose a full allocation, up to 245.6 million tokens for the treasury wallet and up to 600 million tokens across the five wallets. The three wallets owned by the distribution Safe require its signing threshold, which reduces the likelihood, while the backer and team wallets depend on a single key if those beneficiaries are plain accounts.
Pending
#2 low Issue
Deployment script performs no sanity checks on the start time, beneficiaries or funding
The script turns environment variables directly into permanent schedules. The start time is cast to a smaller integer type without any range check. A value given in milliseconds would set every start tens of thousands of years in the future, while a zero or stale value would make the backer, marketing and advisor allocations releasable immediately after funding. The Safe, backer and team addresses are not checked for having code or for being distinct. Funding is a separate manual step whose amounts exist only as comments, so nothing confirms that each wallet receives the correct amount before its start time. Because the wallets cannot be changed or revoked, any of these mistakes becomes irreversible once the tokens are transferred.
optimization Issues | 1 findings
Pending
#1 optimization Issue
Schedule function reads the start time twice
The step schedule calls the inherited start getter twice, once for the comparison and once for the subtraction. The getter is a public virtual function, so the repeated evaluation adds a small amount of gas to every release, releasable query and vested-amount query.
informational Issues | 7 findings
Pending
#1 informational Issue
Documentation says the beneficiary only receives, but it can hand over or destroy the stream
The contract documentation says there are no owner powers beyond the standard vesting wallet and that the beneficiary only receives. In practice the beneficiary is the owner and can transfer the whole stream to another address, which also makes unvested positions sellable, or renounce it, which locks the remaining tokens. A test file comment still states that no custom vesting code is used, although the monthly wallet is custom. Investors and integrators may wrongly assume that positions are bound to the original recipient.
Pending
#2 informational Issue
Invalid schedules fail with an arithmetic error before the custom validation runs
The total duration is computed as the period multiplied by the number of tranches minus one, and this happens in the parent constructor call before the contract's own validation runs. With zero tranches the subtraction underflows, and with a very large period the multiplication overflows, so both cases revert with a generic arithmetic error instead of the intended custom schedule error. Invalid input still always reverts, so there is no security impact, but deployment tooling and tests receive an unrelated error.
Pending
#3 informational Issue
395.6 million tokens vest to the distribution Safe itself
The marketing, advisor and treasury wallets, together 39.56 percent of the supply, name the distribution Safe as their beneficiary. Their schedules limit how fast the Safe receives these tokens, but once vested the Safe can move them at its discretion, so end recipients such as advisors have no on-chain guarantee of their own schedule. Together with the 400 million tokens that remain liquid in the Safe, this makes the Safe the largest controller of supply throughout the vesting period. This is a matter of transparency and trust in the signers rather than a code defect.
Pending
#4 informational Issue
Inherited duration and end getters do not describe the monthly step curve
The monthly wallet reports a duration of nineteen periods and an end time at the last tranche, while it actually pays twenty tranches, the first one already at the start time. Dashboards that treat standard vesting wallets as linear between start and end will show nothing vested at the start, while five percent is already releasable, and almost everything vested just before the end, while only ninety-five percent is. They may also describe the schedule as nineteen months instead of twenty monthly tranches. The on-chain behaviour is correct, but reported circulating supply and unlock dates can be wrong.
Pending
#5 informational Issue
Backer allocation and schedule differ between the deployment script and the tests
One test describes the private backer allocation as 56 million tokens vesting linearly from month six to month thirty-six. The deployment script, the monthly vesting tests and the allocation total all use 54.4 million tokens released in twenty monthly tranches from month six to month twenty-five. The referenced launch plan was not available for review, so the authoritative schedule cannot be confirmed from the code. If the linear 56 million schedule were the agreed one, the deployed configuration would be wrong in both amount and duration.
Pending
#6 informational Issue
Monthly tranches are fixed periods of 30.4375 days
A month is defined as 2,629,800 seconds, one twelfth of a 365.25-day year. Unlocks therefore occur at a fixed interval that drifts against calendar months by up to about a day and a half. In the test deployment, for example, the first backer tranche falls at 09:16 UTC on 2 April 2027 rather than at the start of a calendar month. Timing relies on the block timestamp, whose possible skew on this network is negligible at this scale, so this is purely a communication matter.
Pending
#7 informational Issue
Compiler version has known bugs, none of which apply
The wallets are compiled with version 0.8.28, which has six known compiler bugs. Each requires conditions that are absent here, such as the alternative code generator, storage arrays at the end of storage, or deleting elements of in-memory byte arrays. The current compiler release has no known bugs.