Runwago Info
Runwago is a next-generation Run-to-earn app designed for active runners who want to monetize their physical activity while staying motivated to achieve their healthy lifestyle goals. Its revenue model is 100% sustainable: rewards are funded by users who fail to meet their running goals, forfeiting their deposits into the Runwago Deposit Pool.
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.
Token transfer can be locked
Owner can lock user funds with owner functions.
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.
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 admin can set the referral bonus tier in the contract.
- The admin can toggle the referral bonus.
- The admin can toggle the volume buy bonus.
- The admin can set any arbitrary value in the bonus percentage and threshold USD amount.
- The admin can toggle the presale state.
- The admin can enable/disable the claiming functionality in the contract.
- The admin can set the claiming phase vesting duration, claiming phase percentages, claiming start timestamp, and Merkle root.
- The admin can update the payment token.
- The admin can update the treasury wallet.
- The admin can update the data feed address for the specific token.
- The admin can update the data feed address for the native coin.
- The admin can withdraw the native tokens from the contract.
- The admin can update the Merkle root for the referral system.
- The admin can update the Merkle root for the claiming system.
- The admin can update the hot wallet address.
- The admin can update the estimation address for estimation purposes.
- The admin can update the USDC stablecoin address.
- The admin can update the USDT stablecoin address.
- The admin can update any arbitrary value in the minimum purchase amount.
- The admin can update the claimable token address.
- The admin can update the presale phase start timestamp.
- The admin can initialize the bonus tiers and settings for the referral and volume buy bonuses.
- The server role can set the current presale phase.
Note - This Audit report consists of a security analysis of the RUNWAGO smart contract. This analysis did not include functional testing (or unit testing) of the contract’s logic. Moreover, we only audited one token contract for the RUNWAGO 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
high Issues | 2 findings
Pending
#1 high Issue
The admin can lock claim
The contract allows the admin to indefinitely disable the claiming functionality, posing significant risks. In extreme cases, this could involve malicious intent, where the admin permanently locks claiming to freeze user funds, or accidental oversight, leaving users unable to access their tokens for extended periods. To prevent this, a maximum locking period should be implemented, ensuring the functionality cannot remain disabled indefinitely. Additionally, automated safeguards, such as a countdown timer or community-based unlock mechanisms, can further enhance trust and fairness.
Pending
#2 high Issue
Missing Precision factor
The _getReferralBonusTokens function could experience precision loss due to the large decimal adjustments in the USDT bonus calculation. Specifically, the division by _PERCENTAGE_DIVISOR and the adjustment factor 1 0 12 10 12 (for base and stable coin decimals) may result in very small values, leading to rounding or truncation. Similarly, the token bonus calculation may lose precision if the result is a fractional token. To mitigate this, higher precision types (like uint256) should be used, and careful handling of rounding and decimal scaling should be considered to ensure accurate bonus calculations without significant loss of value.
medium Issues | 2 findings
Pending
#1 medium Issue
The admin can drain claimable tokens.
The admin's ability to withdraw tokens mid-sale via emergencyWithdrawToken introduces significant risks, including insufficient funds in the contract, which could prevent users from claiming tokens. This centralization issue also impacts the claim process and could lead to misuse. To mitigate these risks, safeguards should be implemented, such as limiting withdrawal amounts, checking available token balances before allowing withdrawals, and ensuring the function is used only during true emergencies. Additionally, adopting a multi-signature or governance-based solution would reduce the risks of a single admin having full control over token withdrawals, ensuring more secure and transparent management.
Pending
#2 medium Issue
Missing Non-reentrant check.
The contract contains the functionality in which the claim function (and similar functions like withdraw), making an external call to transfer ERC20 tokens using the transfer function. Since the contract hasn't yet marked the claim as completed (i.e., updated the claimed variable), the attacker can exploit this to re-enter the claim function, repeatedly withdrawing tokens. The transfer happens first (interaction with an external contract) before the internal state is updated. The nonReentrant modifier ensures that any attempts to call the claim function again during execution are blocked, providing an additional safeguard. Therefore, It is recommended to do the check-effect-transaction method or use the non-reentrant modifier to prevent the code from this issue.
low Issues | 4 findings
Resolved
#1 low Issue
Insufficient Validation of Percentages
To ensure accurate token distribution, validate that the sum of _claimingPhasePercentages equals 100% (or 10,000 basis points). Without this, over-allocation (percentages exceeding 100%) may lead to errors or unmet obligations, while under-allocation leaves tokens undistributed. Add a loop to calculate the total percentage and revert if it doesn’t equal 100%. This prevents mathematical errors, ensures fairness, and builds user trust by guaranteeing all tokens are distributed by the final phase. Basis points provide precision, and while this adds minor gas costs, it eliminates critical misconfigurations that could harm the system's integrity. Validation safeguards against admin mistakes or misuse.
Pending
#2 low Issue
Incorrect Token decimals validation
The function setPaymentToken using ERC20(_paymentToken).decimals() will work if the token implements OpenZeppelin’s ERC20 standard, but it can lead to issues if the token uses a custom ERC-20 implementation or does not implement the decimals() function at all. This creates a potential risk of failure or incorrect behavior with non-OpenZeppelin tokens. To ensure better compatibility and avoid tight coupling to OpenZeppelin's implementation, it’s recommended to use the IERC20Metadata interface, which explicitly includes the decimals() function. This approach allows the contract to work with any ERC-20 token that implements decimals(), improving flexibility and reducing the risk of errors or incompatibilities. Additionally, consider adding error handling to account for tokens that do not implement decimals().
Pending
#3 low Issue
Missing zero or dead address check.
Make sure to validate that the address passed in the function parameters is “non-zero”.
Resolved
#4 low Issue
Missing Threshold for heartbeat
The function does not validate the value of _heartbeat, which could lead to an unusually large or small value being set. A very short heartbeat may result in unnecessary resource consumption, while a very long heartbeat could introduce delays in data updates. The heartbeat value should be validated to ensure it falls within a sensible range, such as 1 minute to 24 hours. This ensures that the data feed is updated at a reasonable frequency, balancing responsiveness with resource consumption. Depending on your specific use case, these values might be adjusted, but this range is a safe starting point.
informational Issues | 1 findings
Pending
#1 informational Issue
Use abi.encode() instead of abi.encodePacked()
The function uses abi.encodePacked to create the hash for the node. Using abi.encodePacked can lead to hash collisions when concatenating different data types or values that might result in the same byte representation. Use abi.encode, which avoids ambiguity in encoding.