Audit name:
[SCA] Taoshi | Collateral | Aug2025
Date:
Aug 12, 2025
Table of Content
Introduction
We express our gratitude to the Taoshi team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
Taoshi is a collateral accounting module that leverages OpenZeppelin’s upgradeable architecture to enable protocol owner to accurately track user balances, total collateral, and slashed amounts, while maintaining full administrative control over collateral-related operations.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for Taoshi |
| Audited By | David Camps Novi, Panos Konstantinidis |
| Approved By | Ivan Bondar |
| Website | https://www.taoshi.io/→ |
| Changelog | 07/08/2025 - Preliminary Report |
| 12/08/2025 - Final Report | |
| Platform | Bittensor EVM |
| Language | Solidity |
| Tags | Centralization, Upgradeable |
| Methodology | https://hackenio.cc/sc_methodology→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Taoshi
- Audited By
- David Camps Novi, Panos Konstantinidis
- Approved By
- Ivan Bondar
- Website
- https://www.taoshi.io/→
- Changelog
- 07/08/2025 - Preliminary Report
- 12/08/2025 - Final Report
- Platform
- Bittensor EVM
- Language
- Solidity
- Tags
- Centralization, Upgradeable
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope | |
|---|---|
| Repository | https://github.com/taoshidev/collateral_contract→ |
| Initial Commit | ae7d7f0 |
| Remediation Commit | c0d38e6 |
Review Scope
- Initial Commit
- ae7d7f0
- Remediation Commit
- c0d38e6
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report
Documentation quality
Functional requirements are insufficient.
Technical description is partially provided.
Code quality
The development environment is configured.
NatSpec is missing.
Test coverage
Code coverage of the project is 60% (branch coverage).
Deployment and basic user interactions are not covered with tests.
System Overview
Taoshi Collateral smart contract is an upgradeable Bittensor EVM-based module designed to track and manage collateral-related accounting within a broader protocol. It is implemented using OpenZeppelin’s OwnableUpgradeable and UUPSUpgradeable patterns, ensuring secure administrative control and upgradability.
The contract allows the owner to record collateral deposits, withdrawals, and slashing actions associated with individual user accounts. It maintains internal accounting through three key state variables:
collateralBalances, which maps each user to their current collateral amount,totalCollateral, which aggregates all active collateral across all users,slashedCollateral, which tracks the total amount removed due to slashing actions.
Core Functionality
The contract implements the following functionalities:
initialize: Initializes the contract with an owner and sets up UUPS upgradeability.deposit: Records a collateral deposit for a given user address and increasestotalCollateral.withdraw: Decreases a user's collateral balance and thetotalCollateralaccordingly.slash: Reduces a user's collateral balance while increasingslashedCollateraland decreasingtotalCollateral.
Only the contract owner is authorized to perform the state-changing operations.
Privileged roles
The contract defines a single privileged role, the contract owner, initialized via the initialize function using OpenZeppelin’s OwnableUpgradeable pattern. The owner holds exclusive authority over all state-mutating operations, including:
Recording collateral deposits for user accounts via the
depositfunction, which increases internal balances.Recording slashing using the
slashfunction, which deducts from user balances and updates the slashed collateral state.Recording withdrawals through the
withdrawfunction, which reduces internal balances and updates the total collateral state.
Potential Risks
System Reliance on External Contracts: The contract depends on OpenZeppelin’s upgradeable modules (OwnableUpgradeable, Initializable, UUPSUpgradeable) for core functionality and access control. While widely trusted, these components were not part of the audit scope, and any vulnerabilities in them could affect the system’s security.
Flexibility and Risk in Contract Upgrades: While UUPS upgradeability provides the flexibility to patch or extend logic, it also introduces a risk surface. If the upgrade mechanism is not protected by off-chain processes (like multi-sig approvals, audits, or delay buffers), it can allow rapid deployment of flawed or malicious code.
Absence of Upgrade Window Constraints: The contract allows immediate upgrades without any enforced delay or review window. This means malicious or erroneous upgrades can be pushed live without a buffer period for stakeholders to review or react, increasing the risk of rapid exploitability.
Owner’s Unrestricted State Modification & Single Points of Failure and Control: The contract owner has full control over key state-modifying functions, including deposit, slash, and withdraw. These functions do not perform token transfers but modify internal accounting values that may represent off-chain or cross-contract balances. Without additional safeguards (e.g., whitelists, caps, or role separation), this unrestricted access can pose a risk to data integrity, especially if the owner key is compromised or misused. In order to mitigate this risk, it is encouraged to introduce a multi-signature mechanism for the owner role and any other highly permissive admin wallets.
Off-Chain Management of Core Operations: The Collateral contract is responsible for maintaining token accounting, including global balances, user-specific balances, and slashed amounts. However, it does not directly handle on-chain token transfers or balance updates. Instead, these operations are managed off-chain by the Bittensor EVM → Super Validator, which is operated by the development team. This validator executes all transactions related to Collateral accounting and slashing to ensure consistency with the contract’s internal state. As these operations occur off-chain and are not enforced or verifiable through smart contract logic, they introduce a degree of trust and associated risk.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2025-1203 | Missing Initialization Lock Allows Potential Ownership Takeover | mitigated | Medium | |
| F-2025-1203 | Missing Two-Step Ownership Transfer Increases Risk of Permanent Admin Loss | fixed | Low | |
| F-2025-1203 | Redundant Getter Functions Duplicate Public Variable Accessors | accepted | Observation | |
| F-2025-1202 | Floating Pragma | fixed | Observation |
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 | |
|---|---|
| Repository | https://github.com/taoshidev/collateral_contract→ |
| Initial Commit | ae7d7f0 |
| Remediation Commit | c0d38e6 |
| Whitepaper | N/A |
| Requirements | N/A |
| Technical Requirements | README.md |
Scope Details
- Initial Commit
- ae7d7f0
- Remediation Commit
- c0d38e6
- Whitepaper
- N/A
- Requirements
- N/A
- Technical Requirements
- README.md
Assets in Scope
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.