SyFu

Single Points of Failure and Control: The project is fully or partially centralized, introducing single points of failure and control. This centralization can lead to vulnerabilities in decision-making and operational processes, making the system more susceptible to targeted attacks or manipulation.

Flexibility and Risk in Contract Upgrades: The project's contracts are upgradable, allowing the administrator to update the contract logic at any time. While this provides flexibility in addressing issues and evolving the project, it also introduces risks if upgrade processes are not properly managed or secured, potentially allowing for unauthorized changes that could compromise the project's integrity and security.

Absence of Upgrade Window Constraints: The contract suite allows for immediate upgrades without a mandatory review or waiting period, increasing the risk of rapid deployment of malicious or flawed code, potentially compromising the system's integrity and user assets.

Emergency Withdrawal Can Break Accounting Consistency: The emergencyWithdraw function intentionally allows privileged operators to recover ERC-20 tokens from the contract without updating internal accounting variables such as per-stake, per-pool, or total locked balances. While this behavior is designed for emergency response and is only available when the contract is paused, it creates a scenario where on-chain accounting may no longer accurately reflect the actual token balance held by the vault. As a result, following emergency intervention, recorded locked amounts may become inconsistent with recoverable assets unless additional off-chain reconciliation or operational remediation is performed.

Heavy Reliance on Off-Chain Backend Logic: A significant portion of the protocol’s functional and economic logic is enforced exclusively by the off-chain Go backend rather than by the smart contract itself. This includes reward calculations, EVT-days accumulation, contribution scoring, lottery handling, soft-to-hard pool transitions, and per-pool CAP tracking. While this design keeps the on-chain contract minimal, it also introduces operational and trust dependencies on the correctness, security, and availability of the backend systems. If the backend is misconfigured, unavailable, or compromised, important protocol rules may be applied incorrectly or not enforced at all, even though the smart contract itself continues to operate as designed.

Admin Lock Duration Update Can Front-Run User Lock: The lock() function uses the current poolLockDuration[poolId] value at execution time to determine the stake expiry. Because setPoolLockDuration() can update this value at any time through the DEFAULT_ADMIN_ROLE, a user’s pending lock() transaction may be front-run by an admin duration update. As a result, a user who submitted a transaction expecting the previous lock period may instead have their tokens locked for a newly increased duration once the transaction is mined. This creates timing dependence on privileged admin actions and may lead to users being locked under terms they did not anticipate at submission time.

String-Based Pool IDs Increase Gas Costs: The contract uses string values for poolId, which introduces additional gas overhead compared to a fixed-size type such as bytes32. Dynamic string handling is generally more expensive, particularly for storage writes, comparisons, and hashing. Additionally, poolId currently has no explicit length restriction, meaning longer values may increase execution costs unnecessarily. While this may be manageable in a system with a small, backend-controlled set of pools, it remains a design choice that trades gas efficiency for readability and flexibility.