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 | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for RYT |
| Audited By | Turgay Arda Usman, Viktor Lavrenenko |
| Approved By | Ataberk Yavuzer |
| Website | https://ryt.io/→ |
| Changelog | 16/12/2025 - Preliminary Report |
| 13/01/2025 - Final Report | |
| Platform | RYT blockchain |
| Language | Solidity |
| Tags | Fungible Token ; Staking |
| Methodology | https://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
- Website
- https://ryt.io/→
- Changelog
- 16/12/2025 - Preliminary Report
- 13/01/2025 - Final Report
- Platform
- RYT blockchain
- Language
- Solidity
- Tags
- Fungible Token ; Staking
Review Scope | |
|---|---|
| 1st Repository | https://github.com/ryt-io/Komitte-Contract→ |
| Initial Commit | 52685f90e291cc6e9be3a5a4bba052fe2f940164 |
| Final Commit | 1829f31e73312ff587f102cc2246d3a646982195 |
| 2nd Repoitory | ryt-stablecoin-develop.zip |
| Initial fille SHA3-256 | 851798d95a8fa81a37c950c9c2da0a4085a96f52e73d38eb2f044b56868adb21 |
| Final fille SHA3-256 | 04264b6db0b5fdf81a83d00c9cd685e2d715a9af6ebdc33d30c95755e006ac56 |
Review Scope
- 1st Repository
- https://github.com/ryt-io/Komitte-Contract→
- Initial Commit
- 52685f90e291cc6e9be3a5a4bba052fe2f940164
- Final Commit
- 1829f31e73312ff587f102cc2246d3a646982195
- 2nd Repoitory
- ryt-stablecoin-develop.zip
- Initial fille SHA3-256
- 851798d95a8fa81a37c950c9c2da0a4085a96f52e73d38eb2f044b56868adb21
- Final fille SHA3-256
- 04264b6db0b5fdf81a83d00c9cd685e2d715a9af6ebdc33d30c95755e006ac56
Audit Summary
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_ROLErole of theKomiticontract can assign new roles viagrantRole()and revoke viarevokeRole()functions.The
ADMIN_ROLErole 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_ROLErole 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_ROLErole can:assign/revoke
USER_ROLEroles viaassignUserRoles()andrevokeUserRoles().assign/revoke
ORGANIZER_ROLEroles viaassignOrganizerRoles()andrevokeOrganizerRoles().
The
ORGANIZER_ROLErole can create new groups viacreateGroup().The
DEFAULT_ADMIN_ROLErole of theRYTStablecoincontract can assign new roles viagrantRole()and revoke viarevokeRole()functions.The
MINTER_ROLErole can mint newRYTStablecointokens via themint()function.The
PAUSER_ROLErole can pause/unpause the token functionality viapause/unpause()functions.The
BLOCKLISTER_ROLErole can add/remove from the blacklist viaaddToBlocklist()/removeFromBlocklist()functions.The
RESCUER_ROLErole can rescue the stuck tokens from the token contract viarescueTokens()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-1424 | Primary Contributor Deposits Are Not Recorded, Leading to Permanent Fund Loss and Incorrect Payouts | fixed | Critical | |
| F-2025-1426 | Winner Selection Ignores Assigned Payout Positions Due To A Faulty If Condition | fixed | High | |
| F-2025-1428 | Secondary Contributions Not Recorded in Slot Total, Leading to Incorrect Payout Ratios | fixed | High | |
| F-2025-1425 | Winner-Selection Logic Flaw Allows The Group Creator To Capture All Contributed Funds | fixed | High | |
| F-2025-1422 | Security Mechanisms Inoperative due to OpenZeppelin v5 Hook Incompatibility | fixed | High | |
| F-2025-1425 | Missing Refund Mechanism for Regular Members Leads To Stuck Assets | fixed | Medium | |
| F-2025-1422 | Missing USER_ROLE Check Allows Unauthorized Participants in Joint Groups And Payouts | fixed | Medium | |
| F-2025-1428 | DoS via Concurrent Joint Contributor Invites | fixed | Medium | |
| F-2025-1427 | Excess Contributions Become Permanently Locked Due to Non-Exact Deposit Enforcement | fixed | Medium | |
| F-2025-1423 | Broken Participant Invariant Due to Unrestricted USER_ROLE Revocation | accepted | Medium |
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 Repository | https://github.com/ryt-io/Komitte-Contract→ |
| 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 |
Scope Details
- 1st Repository
- https://github.com/ryt-io/Komitte-Contract→
- 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
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. | Passed | 20000 |
Komiti::revokeUserRoles() should always revoke the USER_ROLE from unique users. | Passed | 20000 |
Komiti::assignOrganizerRoles() should always assign the USER_ROLE to unique users. | Passed | 20000 |
Komiti::revokeOrganizerRoles() should always revoke the USER_ROLE from unique users. | Passed | 20000 |
Komiti::createGroup() should always increase the s_groupCounter value by 1. | Passed | 20000 |
Komiti::joinGroup() should always increase the length of the group members list for unique contributors. | Passed | 20000 |
Invariant
Komiti::assignUserRoles()should always assign theUSER_ROLEto unique users.Test Result
- Passed
Run Count
- 20000
Invariant
Komiti::revokeUserRoles()should always revoke theUSER_ROLEfrom unique users.Test Result
- Passed
Run Count
- 20000
Invariant
Komiti::assignOrganizerRoles()should always assign theUSER_ROLEto unique users.Test Result
- Passed
Run Count
- 20000
Invariant
Komiti::revokeOrganizerRoles()should always revoke theUSER_ROLEfrom unique users.Test Result
- Passed
Run Count
- 20000
Invariant
Komiti::createGroup()should always increase thes_groupCountervalue 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.