Canonical page: [Work & reports](https://www.guvenkaya.co/work) Report # Sweat Economy Sweat Jars Migration & Refactor Smart Contract Review [View PDF on GitHub](https://github.com/Guvenkaya/public-reports/blob/master/The-Sweat-Foundation-Ltd-Sweat-Jars-Migration-And-Refactor-Smart-Contract-Review-Final-Report.pdf) ![Sweat Economy logo](https://www.guvenkaya.co/v2/clients/sweat.svg) - All findings 2 - Critical 0 - High 0 - Medium 1 - Low 0 - Informational 1 Date of engagement: 7th May 2025 - 12th May 2025 ![Timur Güvenkaya](https://www.guvenkaya.co/v2/portraits/timur-guvenkaya.png) Security review by ## Timur Guvenkaya [Meet the team](https://www.guvenkaya.co/about#team) ## About Us Guvenkaya is a security research firm specializing in Rust security, Web3 security of Rust-based 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 migration and refactor changes inside the Sweat Jar smart contract. During this engagement, 2 findings were reported. One is Medium severity and another is Ingormational severity. The Sweat Foundation team has fixed the medium issue and acknowledged the informational one. ## Project Scope Sweat Jar Contract | Files | Link | | ------------ | ------------------------------------------------------------------------------------------------------------------------------ | | V2 Migration | | | Migration | | | Model | | | FT Receiver | | | Withdraw All | | | Restake | | ## Out of Scope The audit will include, but is not limited to, reviewing the code for security vulnerabilities, coding practices, and architecture. The audit does not include a review of the dependencies. Scope only includes: New Migration Functionality: Migration code in new contract and old contract Restaking changes: Addition of ticketing system to restake and restake\_all Withdrawal Changes: withdraw\_all accepting optional product arguments Codebase refactor: Moving non-NEAR related code to the models folder. High level review ## Timeline 1. Start of the audit 7th May 2025 2. Draft report 12th May 2025 3. Final report 12th May 2025 ## 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. | Finding | Impact | Likelihood | Severity | Remediation complexity | Remediation status | | ------------------------------------------------------------- | ---------- | ---------- | ------------- | ---------------------- | ------------------ | | [GUV-1: Possible Double Claim Through Race Condition](#guv-1) | Severe | Rare | Medium | Simple | Fixed | | [GUV-2: Cross Function Ticket Reuse](#guv-2) | Negligible | Rare | Informational | Simple | Fixed | ## Findings Details ### GUV-1: Possible Double Claim Through Race Condition Medium We observed that it is not verified whether a user is in migrating state through assert\_account\_is\_not\_migrating in any of the state changing functions like claim/withdraw/restake in old contract. Since the account is deleted only inside of the after\_account\_transferred, there is a time for a malicious actor to call claim to claim accumulated amount and then after the account is deleted, call claim again on a new migrated smart contract to claim twice. migration:contract/src/migration/v2.rs ``` pub fn after_account_transferred(&mut self, account_id: AccountId) -> PromiseOrValue<(AccountId, bool)> { let is_success = is_promise_success(); ``` ``` if is_success { self.clear_account(&account_id); emit(EventKind::JarsMerge(account_id.clone())); } ... ``` PROPOSED SOLUTION Consider asserting the assert\_account\_is\_not\_migrating in all state mutating functions. REMEDIATION - FIXED The Sweat Foundation team has fixed the issue by adding the assert\_account\_is\_not\_migrating in all state mutating functions in this commit: 89755f5cfbac88764131560ec1d0085464f58cc9 [View this finding in the original PDF](https://www.guvenkaya.co/reports/pdfs/sweat-jars-migration.pdf#page=11) ### GUV-2: Cross Function Ticket Reuse Informational We observed that it is possible to generate a ticket with a signature for jar creation but supply it to the restake and restake\_all functions. Depending on logic of both functions, it can introduce security issues in the future and in general it increases the attack surface. migration:contract/src/feature/restake/api/api.rs ``` fn restake( &mut self, from: ProductId, ticket: DepositTicket, signature: Option, amount: Option, ) -> PromiseOrValue<()> { ``` migration:contract/src/migration/v2.rs pub(crate) fn create\_jar( \&mut self, account\_id: AccountId, ticket: JarTicket, amount: U128, signature: Option\, ) -> JarView PROPOSED SOLUTION Consider disallowing cross-function ticket reuse. REMEDIATION - FIXED The Sweat Foundation team has fixed the issue by introducing purpose in deposit message in this commit and update on the backend: fd72e8cb72af66eb254d90c173387bf8236e61f3 [View this finding in the original PDF](https://www.guvenkaya.co/reports/pdfs/sweat-jars-migration.pdf#page=12) Source: [published GitHub report](https://github.com/Guvenkaya/public-reports/blob/master/The-Sweat-Foundation-Ltd-Sweat-Jars-Migration-And-Refactor-Smart-Contract-Review-Final-Report.pdf) · 12 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-jars-migration\&text=Sweat%20Economy%3A%20Sweat%20Jars%20Migration%20%26%20Refactor%20Smart%20Contract%20Review) [Share on LinkedIn](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.guvenkaya.co%2Freports%2Fsweat-jars-migration) [Share on Threads](https://www.threads.net/intent/post?text=Sweat%20Economy%3A%20Sweat%20Jars%20Migration%20%26%20Refactor%20Smart%20Contract%20Review%20https%3A%2F%2Fwww.guvenkaya.co%2Freports%2Fsweat-jars-migration) [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-Sweat-Jars-Migration-And-Refactor-Smart-Contract-Review-Final-Report.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)