Audit name:
[SCA] Tokeny | Access Control | Mar2023
Date:
Mar 21, 2023
Table of Content
Introduction
We express our gratitude to the Tokeny team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
Hacken OÜ (Consultant) was contracted by Tokeny (Customer) to conduct a Smart Contract Code Review and Security Analysis. This report presents the findings of the security assessment of the Customer's smart contracts.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for Tokeny |
| Approved By | Marcin Ugarenko |
| Website | https://docs.onchainid.com→ |
| Changelog | 19/01/2023 - Initial Review |
| 16/02/2023 - Second Review | |
| 21/03/2023 - Third Review | |
| Platform | EVM |
| Language | Solidity |
| Methodology | https://hackenio.cc/sc_methodology→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Tokeny
- Approved By
- Marcin Ugarenko
- Website
- https://docs.onchainid.com→
- Changelog
- 19/01/2023 - Initial Review
- 16/02/2023 - Second Review
- 21/03/2023 - Third Review
- Platform
- EVM
- Language
- Solidity
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope | |
|---|---|
| Initial review scope | https://github.com/onchain-id/solidity/tree/hacken-audit→ |
| Commit | 31209d8db055025c329890da8034d7285ea923c3 |
| Second review scope | https://github.com/onchain-id/solidity/tree/5c40bc7c7b462e4a4bff7925925b0759f7720442→ |
| Commit | 5c40bc7 |
| Third review scope | https://github.com/onchain-id/solidity/tree/c20c1480b5e2ad10d3ffd23d9d760f69f1645825→ |
| Commit | c20c148 |
Review Scope
- Initial review scope
- https://github.com/onchain-id/solidity/tree/hacken-audit→
- Commit
- 31209d8db055025c329890da8034d7285ea923c3
- Commit
- 5c40bc7
- Commit
- c20c148
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report
Documentation quality
The total Documentation Quality score is 8 out of 10.
Functional requirements are partially missed.
NatSpec is consistent.
There is no apparent flow of the contracts.
Run instructions are provided.
Code quality
The total Code Quality score is 10 out of 10.
The development environment is configured.
Best practices are followed.
Test coverage
Test coverage of the project is 89.77% (branch coverage).
Deployment and basic user interactions are covered with tests.
Security score
As a result of the audit, the code contains no issues. The security score is 10 out of 10.
All found issues are displayed in the “Findings” section.
Summary
According to the assessment, the Customer's smart contract has the following score: 9.4.
System Overview
ONCHAINIDs are self-sovereign identities. This means that each holder of an identity is in control of their information and who has access to it.
Their address is a unique identifier that can safely be used by a service provider to identify their owner, and even to sign requests such as direct authentication on a website.
The project aims to achieve a means of decentralized authentication that is in control of the identity holders themselves.
The project consists of standards for claim holders and key holders, which are then combined to create identities.
Information about the contracts in the scope;
Identity.sol: The contract that implements the IERC734 and IERC735 standards and combines them to create an identity which can add/remove keys and claims.
IdFactory.sol: The contract that handles the deployment of identity proxies.
ClaimIssuer.sol: The contract that represents the claim issuers by extending Identity.sol.
IdentityProxy.sol: Proxy contract for upgradeability in Identity.
Structs.sol: The contract that holds struct variables for upgradeability.
ImplementationAuthority.sol: The contract responsible for storing and updating the implementation logic of upgradeable contracts.
Storage.sol: The contract that holds variables for upgradeability.
IIdFactory.sol: Interface for IdFactory.
Version.sol: The contract to hold the version of the Identity contract.
IERC734.sol: Key holder standard interface.
IERC735.sol: Claim holder standard interface.
IClaimIssuer.sol: Interface for ClaimIssuer.
IIdentity.sol: Interface for Identity.
IImplementationAuthority.sol: Interface for ImplementationAuthority.
Privileged roles
Owner: The owner of the system. Responsible for the upgrading of the contracts.
Claim Issuer: Responsible for issuing identity holders’ claims on their identity.
Identity Owner: The OnchainId identities user.
Potential Risks
The upgradeable nature of the contracts puts the implementation at risk in case of logic upgrade.
The EIP-734 and EIP-735 were closed and not integrated into the Ethereum standards. The project is building upon those standards.
The Identity.sol contract tries to implement the old EIP-725 standard, which was updated to the 725v2.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2025-1339 | Data Consistency | mitigated | Critical | |
| F-2025-1343 | Requirements Violation | fixed | High | |
| F-2025-1343 | Requirements Violation | fixed | High | |
| F-2025-1343 | Requirements Violation | fixed | High | |
| F-2025-1343 | Denial of Service | fixed | High | |
| F-2025-1345 | Unscalable Functionality | fixed | Medium | |
| F-2025-1345 | Inefficient Gas Model - Storage Abuse | fixed | Medium | |
| F-2025-1344 | Inconsistent Data - Incorrect Event Emitting Order | fixed | Medium | |
| F-2025-1344 | Best Practice Violation - Lock of Native Tokens | mitigated | Medium | |
| F-2025-1344 | Contradiction - NatSpec Comment Contradiction | fixed | 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 | |
|---|---|
| Initial review scope | https://github.com/onchain-id/solidity/tree/hacken-audit→ |
| Commit | 31209d8db055025c329890da8034d7285ea923c3 |
| Second review scope | https://github.com/onchain-id/solidity/tree/5c40bc7c7b462e4a4bff7925925b0759f7720442→ |
| Commit | 5c40bc7 |
| Third review scope | https://github.com/onchain-id/solidity/tree/c20c1480b5e2ad10d3ffd23d9d760f69f1645825→ |
| Commit | c20c148 |
| Whitepaper | Not Provided |
| Requirements | https://docs.tokeny.com/docs/general-concept→ |
| Technical Requirements | https://docs.tokeny.com/docs/general-concept→ |
Scope Details
- Initial review scope
- https://github.com/onchain-id/solidity/tree/hacken-audit→
- Commit
- 31209d8db055025c329890da8034d7285ea923c3
- Commit
- 5c40bc7
- Commit
- c20c148
- Whitepaper
- Not Provided
- Requirements
- https://docs.tokeny.com/docs/general-concept→
- Technical Requirements
- https://docs.tokeny.com/docs/general-concept→
Appendix 3. Additional Valuables
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.
Additional Considerations
This security assessment was conducted in accordance with the NIST SP 800-115 – Technical Guide to Information Security Testing and Assessment →. This guideline provides a structured foundation for planning, executing, and documenting technical evaluations such as testing, vulnerability assessments, and code reviews. Hacken’s internal methodology and security assessment framework extend these principles to blockchain environments to ensure consistency, repeatability, and verifiable outcomes.