The Hacken 2025 Yearly Security ReportCovers major Web3 breaches, their root causes, prevention insights, and key regulatory trends for 2026.
Learn more

Audit name:

[SCA] RYT | Komiti + RYTStablecoin | Dec2025

Date:

Jan 13, 2026

Table of Content

Introduction
Audit Summary
System Overview
Potential Risks
Findings
Appendix 1. Definitions
Appendix 2. Scope
Appendix 3. Additional Valuables
Disclaimer

Want a comprehensive audit report like this?

Introduction

We express our gratitude to the RYT team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.

RYT is a Layer-1 blockchain, built on its patented Proof of Majority (PoM) consensus mechanism, designed to address the core limitations that have held back blockchain from mainstream adoption: speed, scalability, accessibility, decentralization, and energy efficiency.

Document

NameSmart Contract Code Review and Security Analysis Report for RYT
Audited ByTurgay Arda Usman, Viktor Lavrenenko
Approved ByAtaberk Yavuzer
Websitehttps://ryt.io/
Changelog16/12/2025 - Preliminary Report
13/01/2025 - Final Report
PlatformRYT blockchain
LanguageSolidity
TagsFungible Token ; Staking
Methodologyhttps://docs.hacken.io/methodologies/smart-contracts
  • Document

    Name
    Smart Contract Code Review and Security Analysis Report for RYT
    Audited By
    Turgay Arda Usman, Viktor Lavrenenko
    Approved By
    Ataberk Yavuzer
    Changelog
    16/12/2025 - Preliminary Report
    13/01/2025 - Final Report
    Platform
    RYT blockchain
    Language
    Solidity
    Tags
    Fungible Token ; Staking

Review Scope

1st Repositoryhttps://github.com/ryt-io/Komitte-Contract
Initial Commit52685f90e291cc6e9be3a5a4bba052fe2f940164
Final Commit1829f31e73312ff587f102cc2246d3a646982195
2nd Repoitoryryt-stablecoin-develop.zip
Initial fille SHA3-256851798d95a8fa81a37c950c9c2da0a4085a96f52e73d38eb2f044b56868adb21
Final fille SHA3-25604264b6db0b5fdf81a83d00c9cd685e2d715a9af6ebdc33d30c95755e006ac56
  • Review Scope

    Initial Commit
    52685f90e291cc6e9be3a5a4bba052fe2f940164
    Final Commit
    1829f31e73312ff587f102cc2246d3a646982195
    2nd Repoitory
    ryt-stablecoin-develop.zip
    Initial fille SHA3-256
    851798d95a8fa81a37c950c9c2da0a4085a96f52e73d38eb2f044b56868adb21
    Final fille SHA3-256
    04264b6db0b5fdf81a83d00c9cd685e2d715a9af6ebdc33d30c95755e006ac56

Audit Summary

31Total Findings
25Resolved
6Accepted
0Mitigated

The system users should acknowledge all the risks summed up in the risks section of the report

{Finding_Table?columns=title,severity,status&setting.filter.type=Vulnerability}

Documentation quality

  • Functional requirements are not complete:

    • The project’s purpose is  described.

    • Business logic is provided.

    • Use cases are partially provided: pausing flows are not described.

    • Project’s features are described.

  • Technical description is sufficient:

    • Key function descriptions are provided for the files in the scope.

    • Architectural overview is missing.

    • Roles and authorization are mentioned.

    • Information on used technologies provided.

Code quality

  • The code partially follows best practices and Solidity Style Guide.

    • See informational findings for more details.

  • The development environment is configured.

Test coverage

Code coverage of the Komiti project is 96.27% (branch coverage).

  • Deployment and basic user interactions are covered with tests.

  • Negative cases coverage is partially missed.

  • Interactions by several users are tested thoroughly.

Code coverage of the RYTStablecoin project is 22.41 % (branch coverage).

  • Deployment and basic user interactions are not covered with tests.

  • Negative cases coverage is missed.

  • Interactions by several users are not tested thoroughly.

System Overview

Komiti - is a decentralized group savings and contribution contract that allows users to form groups with predetermined rules for contributions and payouts. The contract supports both randomized and sequential payout mechanisms, as well as joint contributor arrangements.

RYTStablecoin \- an ERC20-based stablecoin with role-based access control, blocklisting, pausing, and rescue functionality.

Privileged roles

  • The DEFAULT_ADMIN_ROLE role of the Komiti contract can assign new roles via grantRole() and revoke via revokeRole() functions.

  • The ADMIN_ROLE role can:

    • create new groups via createGroup().

    • update the existing group via updateKomiti().

    • start the payout process of the group via startKomiti().

    • start the distribution of funds via distributeFunds().

    • pause/unpause the contract via triggerJointContribution().

  • The USER_ROLE role can:

    • join a group via joinGroup().

    • join a group without a joint contributor via joinGroupWithJointContributor().

    • accept the invite for the joint contributor via acceptInviteForJointContributor().

    • return the funds via returnFunds().

    • contribute to the group via contribute().

    • contribute to the group as a joint member via contributeAsJointMember().

  • The MANAGER_ROLE role can:

    • assign/revoke USER_ROLE roles via assignUserRoles() and revokeUserRoles().

    • assign/revoke ORGANIZER_ROLE roles via assignOrganizerRoles() and revokeOrganizerRoles().

  • The ORGANIZER_ROLE role can create new groups via createGroup().

  • The DEFAULT_ADMIN_ROLE role of the RYTStablecoin contract can assign new roles via grantRole() and revoke via revokeRole() functions.

  • The MINTER_ROLE role can mint new RYTStablecoin tokens via the mint() function.

  • The PAUSER_ROLE role can pause/unpause the token functionality via pause/unpause() functions.

  • The BLOCKLISTER_ROLE role can add/remove from the blacklist via addToBlocklist()/removeFromBlocklist() functions.

  • The RESCUER_ROLE role can rescue the stuck tokens from the token contract via rescueTokens() function.

Potential Risks

The broad authorization model increases the risk of protocol control loss if any authorized address is compromised, potentially leading to unauthorized actions and significant financial loss.

The digital contract architecture relies on administrative keys for critical operations. Centralized control over these keys presents a significant security risk, as compromise or misuse can lead to unauthorized actions or loss of funds.

The project iterates over large dynamic arrays, which leads to excessive gas costs, risking denial of service due to out-of-gas errors, directly impacting contract usability and reliability.

The project's smart-contracts are non-upgradable. While this approach enhances immutability, it also limits the ability to patch vulnerabilities, fix bugs, or introduce improvements after deployment. In the event of unintended behavior or security issues, the absence of an upgrade mechanism significantly reduces the available response options, potentially leading to prolonged downtime or the need for a full contract migration.

The Komiti smart-contract utilizes the totalSlots to limit the number of users within a specific group. If the number is not properly set or adjusted and if the total number of members exceeds this limit, there is a risk of contract's misbehavior and locked funds.

The lack of multi-signature requirements for key operations centralizes decision-making power, increasing vulnerability to single points of failure or malicious insider actions, potentially leading to unauthorized transactions or configuration changes.

Findings

Code
Title
Status
Severity
F-2025-1424Primary Contributor Deposits Are Not Recorded, Leading to Permanent Fund Loss and Incorrect Payouts
fixed

Critical
F-2025-1426Winner Selection Ignores Assigned Payout Positions Due To A Faulty If Condition
fixed

High
F-2025-1428Secondary Contributions Not Recorded in Slot Total, Leading to Incorrect Payout Ratios
fixed

High
F-2025-1425Winner-Selection Logic Flaw Allows The Group Creator To Capture All Contributed Funds
fixed

High
F-2025-1422Security Mechanisms Inoperative due to OpenZeppelin v5 Hook Incompatibility
fixed

High
F-2025-1425Missing Refund Mechanism for Regular Members Leads To Stuck Assets
fixed

Medium
F-2025-1422Missing USER_ROLE Check Allows Unauthorized Participants in Joint Groups And Payouts
fixed

Medium
F-2025-1428DoS via Concurrent Joint Contributor Invites
fixed

Medium
F-2025-1427Excess Contributions Become Permanently Locked Due to Non-Exact Deposit Enforcement
fixed

Medium
F-2025-1423Broken Participant Invariant Due to Unrestricted USER_ROLE Revocation
accepted

Medium
1-10 of 31 findings

Identify vulnerabilities in your smart contracts.

Appendix 1. Definitions

Severities

When auditing smart contracts, Hacken is using a risk-based approach that considers Likelihood, Impact, Exploitability and Complexity metrics to evaluate findings and score severities.

Reference on how risk scoring is done is available through the repository in our Github organization:

Severity

Description

Critical
Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation.

High
High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation.

Medium
Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category.

Low
Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution.
  • Severity

    Critical

    Description

    Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation.

    Severity

    High

    Description

    High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation.

    Severity

    Medium

    Description

    Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category.

    Severity

    Low

    Description

    Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution.

Potential Risks

The "Potential Risks" section identifies issues that are not direct security vulnerabilities but could still affect the project’s performance, reliability, or user trust. These risks arise from design choices, architectural decisions, or operational practices that, while not immediately exploitable, may lead to problems under certain conditions. Additionally, potential risks can impact the quality of the audit itself, as they may involve external factors or components beyond the scope of the audit, leading to incomplete assessments or oversight of key areas. This section aims to provide a broader perspective on factors that could affect the project's long-term security, functionality, and the comprehensiveness of the audit findings.

Appendix 2. Scope

The scope of the project includes the following smart contracts from the provided repository:

Scope Details

1st Repositoryhttps://github.com/ryt-io/Komitte-Contract
Initial Commit52685f90e291cc6e9be3a5a4bba052fe2f940164
Final Commit1829f31e73312ff587f102cc2246d3a646982195
2nd Repostioryryt-stablecoin-develop.zip
Initial fille SHA3-256851798d95a8fa81a37c950c9c2da0a4085a96f52e73d38eb2f044b56868adb21
Final file SHA3-25604264b6db0b5fdf81a83d00c9cd685e2d715a9af6ebdc33d30c95755e006ac56
WhitepaperN/A
RequirementsREADME.md
Technical RequirementsREADME.md
  • Scope Details

    Initial Commit
    52685f90e291cc6e9be3a5a4bba052fe2f940164
    Final Commit
    1829f31e73312ff587f102cc2246d3a646982195
    2nd Repostiory
    ryt-stablecoin-develop.zip
    Initial fille SHA3-256
    851798d95a8fa81a37c950c9c2da0a4085a96f52e73d38eb2f044b56868adb21
    Final file SHA3-256
    04264b6db0b5fdf81a83d00c9cd685e2d715a9af6ebdc33d30c95755e006ac56
    Whitepaper
    N/A
    Requirements
    README.md
    Technical Requirements
    README.md

Assets in Scope

contracts
Komiti.sol - contracts › Komiti.sol
RYTStablecoin.sol - contracts › RYTStablecoin.sol

Appendix 3. Additional Valuables

Verification of System Invariants

During the audit of Komiti+RYTStablecoin, Hacken followed its methodology by performing fuzz-testing on the project's main functions. Foundry, a tool used for fuzz-testing, was employed to check how the protocol behaves under various inputs. Due to the complex and dynamic interactions within the protocol, unexpected edge cases might arise. Therefore, it was important to use fuzz-testing to ensure that several system invariants hold true in all situations.

Fuzz-testing allows the input of many random data points into the system, helping to identify issues that regular testing might miss. A specific Echidna fuzzing suite was prepared for this task, and throughout the assessment, 6 invariants were tested over 120000 runs. This thorough testing ensured that the system works correctly even with unexpected or unusual inputs.

Invariant

Test Result

Run Count

Komiti::assignUserRoles() should always assign the USER_ROLE to unique users.Passed20000
Komiti::revokeUserRoles() should always revoke the USER_ROLE from unique users.Passed20000
Komiti::assignOrganizerRoles() should always assign the USER_ROLE to unique users.Passed20000
Komiti::revokeOrganizerRoles() should always revoke the USER_ROLE from unique users.Passed20000
Komiti::createGroup() should always increase the s_groupCounter value by 1.Passed20000
Komiti::joinGroup() should always increase the length of the group members list for unique contributors.Passed20000
  • Invariant

    Komiti::assignUserRoles() should always assign the USER_ROLE to unique users.

    Test Result

    Passed

    Run Count

    20000

    Invariant

    Komiti::revokeUserRoles() should always revoke the USER_ROLE from unique users.

    Test Result

    Passed

    Run Count

    20000

    Invariant

    Komiti::assignOrganizerRoles() should always assign the USER_ROLE to unique users.

    Test Result

    Passed

    Run Count

    20000

    Invariant

    Komiti::revokeOrganizerRoles() should always revoke the USER_ROLE from unique users.

    Test Result

    Passed

    Run Count

    20000

    Invariant

    Komiti::createGroup() should always increase the s_groupCounter value by 1.

    Test Result

    Passed

    Run Count

    20000

    Invariant

    Komiti::joinGroup() should always increase the length of the group members list for unique contributors.

    Test Result

    Passed

    Run Count

    20000

Additional Recommendations

The smart contracts in the scope of this audit could benefit from the introduction of automatic emergency actions for critical activities, such as unauthorized operations like ownership changes or proxy upgrades, as well as unexpected fund manipulations, including large withdrawals or minting events. Adding such mechanisms would enable the protocol to react automatically to unusual activity, ensuring that the contract remains secure and functions as intended.

To improve functionality, these emergency actions could be designed to trigger under specific conditions, such as:

  • Detecting changes to ownership or critical permissions.

  • Monitoring large or unexpected transactions and minting events.

  • Pausing operations when irregularities are identified.

These enhancements would provide an added layer of security, making the contract more robust and better equipped to handle unexpected situations while maintaining smooth operations.

Frameworks and Methodologies

This security assessment was conducted in alignment with recognised penetration testing standards, methodologies and guidelines, including the NIST SP 800-115 – Technical Guide to Information Security Testing and Assessment , and the Penetration Testing Execution Standard (PTES) , These assets provide a structured foundation for planning, executing, and documenting technical evaluations such as vulnerability assessments, exploitation activities, and security code reviews. Hacken’s internal penetration testing methodology extends these principles to Web2 and Web3 environments to ensure consistency, repeatability, and verifiable outcomes.

Disclaimer