KOTAI Info
Kotai project is a global financial ecosystem that aims to give geographic and financial freedom to all cryptocurrency users in the world.
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 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.
Ownership Privileges
- The DEFAULT_ADMIN_ROLE can set the receiver address.
- The DEFAULT_ADMIN_ROLE can set the price engine contract address.
- The DEFAULT_ADMIN_ROLE can set the admin fee wallet address.
- The DEFAULT_ADMIN_ROLE can update the stable allow list.
- The DEFAULT_ADMIN_ROLE can pause/unpause the functionalities in the contract.
Note - This Audit report consists of a security analysis of the kotai OrderBook smart contract. This analysis did not include functional testing (or unit testing) of the contract’s logic. Moreover, we only audited the mentioned contract for the kotai 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 | 4 findings
Resolved
#1 medium Issue
Defective Maintenance Logic and Timer Configuration
The contract defines both ORDER_TTL (Hard Expiration) and INITIAL_MAINTENANCE_PERIOD (Paid Duration) as 30 days. This creates a logical flaw where every new order is initialized with a "paid until" date that exactly matches its expiration date. Consequently, the payMaintenance function serves no purpose; users paying maintenance fees receive zero additional time because the contract logic caps extensions at the expiresAt time, effectively taking user funds for no benefit.
Resolved
#2 medium Issue
Stuck Funds Risk during Pause (Design Flaw)
The cancelOrder function is guarded by the whenNotPaused modifier, which restricts its execution when the contract is in a paused state. While pausing is intended as a safety mechanism during emergencies or upgrades, applying it to withdrawal functions creates a "hostage" scenario where users are prevented from retrieving their own assets exactly when they might feel most unsafe. If the platform administration pauses the contract indefinitely or maliciously, sellers effectively lose access to their deposited KOTAI tokens with no recourse.
Pending
#3 medium Issue
Token Architecture Mismatch ("The Token Trap")
The system suffers from a critical incompatibility between the KotaiSettlementReceiver and KotaiOrderBook. The Receiver is designed to be multi-currency (allowing any whitelisted stablecoin, like USDC or DAI), while the OrderBook is hardcoded to transact in a single immutable token (e.g., USDT). If a buyer funds a purchase with a valid whitelisted token (e.g., USDC) that differs from the OrderBook's base token, the Receiver will transfer USDC to the OrderBook. However, the OrderBook will blindly attempt to pay the seller in USDT. This guarantees the transaction will fail (revert) due to missing funds, rendering the multi-token feature of the Receiver completely broken and potentially trapping funds if not handled carefully.
Resolved
#4 medium Issue
Defective Dynamic Pricing Logic ("Circular Pricing")
The dynamic pricing mechanism fails to react to market demand because of circular logic. When a DYNAMIC order is executed, the OrderBook fetches the current price from the PriceEngine, executes the trade at that exact price, and then reports that same price back to the PriceEngine. The engine then updates its "current price" to the value it just provided. As a result, executing dynamic orders—regardless of volume or frequency—never causes the price to move up or down. The price effectively remains frozen unless a FIXED order executes at a different price point, defeating the entire purpose of an automated market maker or dynamic pricing model.
low Issues | 5 findings
Resolved
#1 low Issue
Initialization Failure of Admin Fee Wallet
The contract constructor fails to initialize the adminFeeWallet state variable, leaving it as the default address(0). Because the createOrder function attempts to transfer fee tokens to this wallet immediately, and most standard ERC20 implementations (like USDT/USDC) revert when transferring to the zero address, the contract will be completely non-functional upon deployment. No users will be able to create orders.
Resolved
#2 low Issue
Missing Validation for Dynamic Pricing Parameters
The createOrder function accepts DynamicParams (min/max price) without validating their logical consistency. A user can accidentally create an order where minPrice is greater than maxPrice or minPrice is zero. This results in a "bricked" order where the user pays fees and locks tokens, but the order can never be filled because the pricing conditions are mathematically impossible to satisfy during settlement.
Resolved
#3 low Issue
Violation of Checks-Effects-Interactions Pattern
The function performs external interactions (transferring the stablecoin fee and the KOTAI tokens) before updating the contract's internal state (incrementing nextOrderId and storing the order struct). This violation of the Checks-Effects-Interactions pattern creates a potential vulnerability to reentrancy attacks, especially if the tokens involved (like ERC-777) have transfer hooks that allow code execution during the transfer.
Resolved
#4 low Issue
Retroactive Payment Penalties ("Lost Time")
The function calculates the new expiration date by adding time to the old paidUntil timestamp (order.paidUntil + EXTENSION), regardless of whether that date is in the past. If a user's maintenance period expired 10 days ago, paying for a 30-day extension effectively only grants them 20 days of future visibility, forcing them to pay for time that has already elapsed and cannot be used.
Resolved
#5 low Issue
Missing events
It is recommended to emit all the critical parameter changes.
informational Issues | 2 findings
Resolved
#1 informational Issue
Incompatibility with Fee-on-Transfer Tokens
The contract assumes that the amount of tokens specified by the user is exactly the amount received by the vault. If the KOTAI token implements a transfer tax (e.g., a 1% burn on transfer), the contract will record the full amount in its ledger while holding less in its balance. This discrepancy will cause future transactions (like filling the order or cancelling it) to fail due to insufficient funds in the contract.
Acknowledged
#2 informational Issue
Security/Trust Vulnerability in Critical Component Updates
The setPriceEngine function currently allows the DEFAULT_ADMIN_ROLE to change the priceEngine address an unlimited number of times. Since the Price Engine dictates the value of all "Dynamic" assets in the system, a malicious or compromised admin could swap the legitimate engine for a fake one that reports manipulated prices (e.g., $0.0001), allowing them to drain all assets from the order book cheaply. This unlimited mutability undermines the trustlessness of the protocol, as users must permanently trust the admin key not to rug-pull the market logic.