Canonical page: [Work & reports](https://www.guvenkaya.co/work) Report # Sweat Economy Tiered Jars & Boosters Smart Contract Security Review [View PDF on GitHub](https://github.com/Guvenkaya/public-reports/blob/master/The-Sweat-Foundation-Ltd-Tiered-Jars-%26-Boosters-Smart-Contract-Security-Review.pdf) ![Sweat Economy logo](https://www.guvenkaya.co/v2/clients/sweat.svg) - All findings 4 - Critical 0 - High 0 - Medium 0 - Low 1 - Informational 3 Date of engagement: 29th December 2025 - 12th January 2026 ![Michal Bajor](https://www.guvenkaya.co/v2/portraits/michal-bajor.png) Security review by ## Michal Bajor [Meet the team](https://www.guvenkaya.co/about#team) ## About Us Guvenkaya is a security research firm specializing in Rust security, Web3 security of Non-EVM protocols, and Web2 security. With our expertise, we provide both security auditing services and custom security solutions ## About The Sweat Foundation The Sweat Foundation is an organization behind Sweat Economy, an innovative project at the intersection of fitness and crypto. It motivates users to stay active by converting their steps into SWEAT Token. This approach promotes health and fitness and works as an entry point to crypto for many users. ## Audit Results Guvenkaya conducted a security assessment of the SWEAT Jar code changes introduced in PR #144 (Tiered Score Based Jars & Boosters). During this engagement, 4 findings were reported: 1 Low and 3 Informational severity issues. The Low finding highlights possible arithmetic overflow paths, while the Informational findings cover APY representation constraints, booster lifecycle edge-cases, and global APY clamping behavior. ## Project Scope SWEAT Jar (PR #144) | Files | Link | | ---------------------------------- | -------------------------------------------------------- | | Tiered Score Based Jars & Boosters | | ## Out of Scope The audit included reviewing the code changes in scope for security vulnerabilities, coding practices, and architecture. The audit does not include a review of external dependencies, off-chain services, or oracle infrastructure beyond how they are consumed by the smart contracts. ## Timeline 1. Start of the audit 29th December 2025 2. Draft report 12th January 2026 3. Final report 14th January 2026 ## Methodology - RESEARCH INTO PROJECT ARCHITECTURE - PREPARING ATTACK VECTORS - SETTING UP AN ENVIRONMENT - MANUAL CODE REVIEW OF THE CODE - ASSESSMENT OF RUST SECURITY ISSUES - ASSESSMENT OF NEAR SECURITY ISSUES - ASSESSMENT OF ARITHMETIC ISSUES - BUSINESS LOGIC VULNERABILITY ASSESSMENT - ONCHAIN TESTING USING NEAR WORKSPACES - BEST PRACTICES AND CODE QUALITY - CHECKING FOR CODE REFACTORING/SIMPLIFICATION POSSIBILITIES - ARCHITECTURE IMPROVEMENT SUGGESTIONS - PREPARING POCS AND/OR TESTS FOR EACH CRITICAL/HIGH/MEDIUM ISSUES ## Severity Breakdown ### Likelihood Ratings - Likely The vulnerability is easily discoverable and not overly complex to exploit. - Possible The vulnerability presents some challenges either in discovery or in the complexity of the attack. - Rare The vulnerability is either very difficult to discover or complex to exploit, or both. This matrix provides a nuanced view, taking into account both the ease of discovering a vulnerability and the complexity involved in exploiting it. ### Impact - Severe Exploitation could result in critical loss or compromise, such as full system control, substantial financial loss, or severe reputational damage. - Moderate Exploitation may lead to limited data loss, partial compromise, moderate financial impact, or noticeable degradation of services. - Negligible Exploitation has minimal impact, such as minor data exposure without significant consequences or slight inconvenience without substantial disruption. ### Severity Ratings - Critical Assigned to vulnerabilities with severe impact and a likely likelihood of exploitation. - High For vulnerabilities with either severe impact but only a possible likelihood, or moderate impact with a likely likelihood. - Medium Used for vulnerabilities with severe impact but a rare likelihood, moderate impact with a possible likelihood, or negligible impact with a likely likelihood. - Low For vulnerabilities with moderate impact and rare likelihood, or negligible impact with a possible likelihood. - Informational The lowest severity rating, typically for vulnerabilities with negligible impact and a rare likelihood of exploitation. ### Likelihood Matrix | Attack Complexity / Discovery Ease | Obvious | Concealed | Hidden | | ---------------------------------- | -------- | --------- | -------- | | Complex | Possible | Rare | Rare | | Moderate | Likely | Possible | Rare | | Straightforward | Likely | Possible | Possible | ### Likelihood/Impact Matrix | Likelihood / Impact | Severe | Moderate | Negligible | | ------------------- | -------- | -------- | ------------- | | Likely | Critical | High | Medium | | Possible | High | Medium | Low | | Rare | Medium | Low | Informational | ## Findings Summary ### Remediation Complexity This measures how difficult it is to fix the vulnerability once it has been identified. - Simple Patches or fixes are readily available and easily implemented. - Moderate Requires some time and resources to remediate, but well within the capabilities of most organizations. - Difficult Remediation requires significant resources, specialized skills, or substantial changes to systems or architecture. ### Status This measures how difficult it is to fix the vulnerability once it has been identified. - Not Fixed Indicates that the vulnerability has been identified but no remedial action has been taken yet. This status is crucial for newly discovered vulnerabilities or those awaiting prioritization. - Fixed This status is applied when the vulnerability has been successfully remediated. It implies that appropriate measures (like patching, configuration changes, or architectural modifications) have been implemented to resolve the issue. - Acknowledged This status is used for vulnerabilities that have been recognized, but for various reasons (such as risk acceptance, cost, or other business decisions), have not been fixed. It indicates that the risk posed by the vulnerability is known and has been consciously accepted. - Scheduled This status indicates that the vulnerability has been acknowledged and a plan is in place to fix it in the future. It signifies that while remediation hasn't yet occurred, the issue has been prioritized and is part of the planned development roadmap. | Finding | Impact | Likelihood | Severity | Remediation complexity | Remediation status | | ------------------------------------------------------------- | ---------- | ---------- | ------------- | ---------------------- | ------------------ | | [GUV-1: Possible overflows](#guv-1) | Moderate | Rare | Low | Simple | Fixed | | [GUV-2: Possible misinterpretation of the APY value.](#guv-2) | Negligible | Rare | Informational | Moderate | Fixed | | [GUV-3: Possible Booster lifecycle panic](#guv-3) | Negligible | Rare | Informational | Simple | Fixed | | [GUV-4: Inconsistent global APY clamping](#guv-4) | Negligible | Rare | Informational | Simple | Fixed | ## Findings Details ### GUV-1: Possible overflows Low If the booster is active, the DailyScore::to\_capped\_apy calculates the \`self.value.min(cap) + self.booster\`, each individual component being a \`u16\` types. When added together, they might overflow, if their sum is bigger than \`u16::MAX\`. The contract enables overflow-checks so whenever it would be encounter, the contract will panic instead. model/src/data/score/mod.rs:to\_capped\_apy ``` pub fn to_capped_apy(&self, cap: Score, include_booster: bool) -> UDecimal { (self.value.min(cap) + if include_booster { self.booster } else { 0 }).to_apy() } ``` Another case is of a possible overflow is in get\_interest function. It calculates the interest as \`term\_in\_milliseconds \* apy \* principal\` using \`u128\` type. That type can contain large numbers, so an actual overflow in production environment is not likely, but still possible given the right combination of values. #### Recommendation It is recommended to use the the \`saturating\_\` variants of mathematical operations to make sure overflow is not encountered. #### Remediation - Fixed The Sweat Foundation team has fixed the issue in this commit: 607f3f61ab38faed74fe23e16ee825a55c289f17 [View this finding in the original PDF](https://www.guvenkaya.co/reports/pdfs/sweat-tiered-jars.pdf#page=11) ### GUV-2: Possible misinterpretation of the APY value. Informational 100% APY (as indicated in the PR docs) seems to not be possible due to type constraints The APY is represented as \`u16\` which is then converted to \`UDecimal\` type. The "encoding" makes 1% = 1000. Since \`u16\`'s max value is \~65k, the max APY that can be represented is about 65.5%. This, however, might not be an issue, depending if the PR description is correct. #### Recommendation An altnerative type representing the Score can be considered, \`u32\` will be able to represent the whole range of per-cent values using the current encoding. #### Remediation - Fixed The Sweat Foundation team has fixed the issue in this commit: 607f3f61ab38faed74fe23e16ee825a55c289f17 [View this finding in the original PDF](https://www.guvenkaya.co/reports/pdfs/sweat-tiered-jars.pdf#page=12) ### GUV-3: Possible Booster lifecycle panic Informational First, the booster timestamp might case a panic within the contract if it's older than \`DAYS\_STORED\` in the past. This panic requires an oracle to pass an older-than-expected value, which possibly is not expected to happen, however for resiliency, it would be advised to not panic, and instead simply ignore those values. #### Recommendation We recommend gracefully handling the errorouns cases here instead of panicing. #### Remediation - Fixed The Sweat Foundation team has fixed the issue in these commits: 3f60fa06e1530aa743e6d230cb028deede60614e and 8abef8c4b010de7a9aa8ba9be38da000adda98b5 [View this finding in the original PDF](https://www.guvenkaya.co/reports/pdfs/sweat-tiered-jars.pdf#page=13) ### GUV-4: Inconsistent global APY clamping Informational The current APY cap is implemented as capping the value and adding booster ontop of it, which might increase the total APY to be above the defined cap. This might be intended, however. Documentation suggests that it's not. #### Recommendation We recommend double checking the design to make sure which approach is the intended one and changing the implementation (if needed) accordingly - making the cap act on a sum of actual value with a booster. #### Remediation - Fixed The Sweat Foundation team has fixed the issue in this commit: 607f3f61ab38faed74fe23e16ee825a55c289f17 [View this finding in the original PDF](https://www.guvenkaya.co/reports/pdfs/sweat-tiered-jars.pdf#page=14) Source: [published GitHub report](https://github.com/Guvenkaya/public-reports/blob/master/The-Sweat-Foundation-Ltd-Tiered-Jars-%26-Boosters-Smart-Contract-Security-Review.pdf) ยท 14 pages. The original PDF includes the source formatting, figures, and linked references. ## Table of Contents - [Overview](#overview) - [About Us](#about-us) - [About The Sweat](#about-the-sweat) - [Audit Results](#audit-results) - [Project Scope](#project-scope) - [Out of Scope](#out-of-scope) - [Timeline](#timeline) - [Methodology](#methodology) - [Severity Breakdown](#severity-breakdown) - [Findings Summary](#findings-summary) - [Findings Details](#findings-details) ## Share [Share on X](https://twitter.com/intent/tweet?url=https%3A%2F%2Fwww.guvenkaya.co%2Freports%2Fsweat-tiered-jars\&text=Sweat%20Economy%3A%20Tiered%20Jars%20%26%20Boosters%20Smart%20Contract%20Security%20Review) [Share on LinkedIn](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.guvenkaya.co%2Freports%2Fsweat-tiered-jars) [Share on Threads](https://www.threads.net/intent/post?text=Sweat%20Economy%3A%20Tiered%20Jars%20%26%20Boosters%20Smart%20Contract%20Security%20Review%20https%3A%2F%2Fwww.guvenkaya.co%2Freports%2Fsweat-tiered-jars) [Discuss a security review](https://www.guvenkaya.co/contact?source=report) [View PDF on GitHub](https://github.com/Guvenkaya/public-reports/blob/master/The-Sweat-Foundation-Ltd-Tiered-Jars-%26-Boosters-Smart-Contract-Security-Review.pdf) ## Tell us what you need to secure. Describe your system, main concern, and deadline. We will reply with scoping questions and a proposed next step. [Discuss your scope](https://www.guvenkaya.co/contact?source=report)