
Project Background
- The o33 Protocol Contracts handle multiple contracts, and all contracts have different functions.
- o33: The o33 contract is a liquid staking wrapper for xTFY, enabling auto-compounding of rewards, delegated voting, and bribe claiming. It integrates with external vote and reward modules, supports gasless meta-transactions, and includes security measures like epoch locks and whitelisted aggregators.
- xTFY: The xTFY is a yield-bearing ERC20 token representing staked TFY with slashing and vesting mechanics. It enables emissions conversion, vesting-based exit strategies, rebasing via a VoteModule, and transfer restrictions to ensure governance control. The contract also supports pause control, migration, and rescue functionalities via the ACCESS_HUB.
- VoterV4: The VoterV4 is the core governance contract of the TFY protocol that manages voting, emissions distribution, and gauge control. It supports legacy, concentrated liquidity (CL), and Ichi Vault gauges with UUPS upgradability, delegation, and per-period vote accounting. It integrates with the xTFY staking token and VoteModule for modular governance.
- AccessHub: AccessHub is the central governance and access control contract for the TFY Protocol, using UUPS upgradeability and OpenZeppelin’s role-based permissions. It coordinates core modules like Voter, xTFY, Minter, o33, and VoteModule, and enables secure execution, upgrades, parameter management, and emergency actions through a timelock-controlled system.
- FeeCollector: FeeCollector is a fee aggregation and distribution contract for Algebra-based pools within the TFY Protocol. It collects protocol fees from pools, splits them between the treasury and gauge-linked fee distributors, and supports withdrawals from the AlgebraCommunityVault under role-based permissions. It provides granular event logging and safeguards for treasury and voter-controlled operations.
- IchiBribeDistributor: IchiBribeDistributor manages the deposit and distribution of bribes for a specific IchiVaultGauge based on user voting weights. Bribes are deposited for upcoming voting periods and later claimed by voters proportionally to their vote share. The contract ensures only the authorized VoterV4 can submit vote weights and enforces token whitelisting for bribes.
- IchiVaultGauge: IchiVaultGauge manages time-weighted reward distribution to users based on their participation in paired Ichi Vaults during each reward period (weekly). It allows a designated recorder to submit user “share-seconds” data off-chain and supports both voter-notified and externally deposited rewards. Whitelisted tokens can be used as rewards, and users can claim them per completed period.
- Minter: Minter handles the emission schedule for the TFY token, minting weekly rewards with a configurable growth/decay multiplier and enforcing a max supply cap. It interacts with a Voter contract to distribute emissions and can trigger a rebase in the xTFY contract. Governance can adjust the emissions multiplier with a 25% per-epoch deviation limit.
- PositionOracle: PositionOracle feeds time-in-range data of Uniswap V3 NFT positions to the Voter contract for use in gauges. It supports normal and fallback modes for data submission, with role-based access for an operator and emergency admin. The contract ensures batch-safe updates, enabling accurate reward distribution even in subgraph or data feed failures.
- RevenueToRebaseManager: RevenueToRebaseManager automates the weekly distribution of protocol revenue by burning a portion of TFY tokens and rebasing the rest to stakers. It supports community governance to override distribution ratios per epoch, uses UUPS upgradeability, and enforces security via access control, reentrancy protection, and emergency pause mechanisms.
- Thirdfy: Thirdfy is a mintable, burnable ERC20 token with permit support, designed for the TFY protocol’s emissions system. It restricts minting access to a designated minter contract, which typically handles weekly emissions based on governance decisions.
- ThirdfyTimelock: ThirdfyTimelock is a governance contract extending OpenZeppelin’s TimelockController, used to manage delayed execution of proposals within the TFY protocol. It ensures secure and transparent upgrades or parameter changes by enforcing a minimum delay between proposal approval and execution.
- VoteModule: VoteModule is the TFY Protocol’s core staking contract, enabling xTFY deposits for voting power and dual reward streams. It securely distributes both protocol emissions (rebase rewards) and external revenue rewards, with cooldown protection, delegation support, and robust access control via AccessHub.
- ClGaugeFactory: The ClGaugeFactory is a governance-controlled factory contract for deploying and managing Concentrated Liquidity (CL) gauge contracts within the TFY Protocol. It handles role assignments (voter, nfpManager, accessHub) and maintains a registry of created gauges.
- IchiBribeDistributorFactory: The IchiBribeDistributorFactory is a UUPS upgradeable factory contract used to deploy IchiBribeDistributor instances for distributing bribes to gauges. It includes access control via AccessHub, supports governance via VoterV4, and tracks the initial implementation address.
- IchiVaultGaugeFactory: The IchiVaultGaugeFactory is a UUPS upgradeable factory contract for deploying IchiVaultGauge instances linked to Ichi Vault pairs. It supports secure role-based access via AccessHub and VoterV4, and ensures controlled gauge creation with event logging and upgrade flexibility.
- This audit scope has included 16 smart contract files, 18 interface files, and 4 libraries files.
- The o33 Token contracts inherit the Initializable, UUPSUpgradeable, ERC20, IERC20, Pausable, Math, EnumerableSet, ERC4626, SafeERC20, ReentrancyGuard, ReentrancyGuardUpgradeable, TimelockController ,ERC20Burnable, ERC20Permit, Ownable, AccessControlEnumerableUpgradeable standard smart contracts from the OpenZeppelin library.
- These OpenZeppelin contracts are considered community-audited and time-tested, and hence are not part of the audit scope.
Website: https://thirdfy.com
Executive Audit Summary
- According to the standard audit assessment, the Customer`s solidity smart contracts are “Secured”. Also, these contracts contain owner control, which does not make them fully decentralized.
- We used various tools like Slither, Solhint and Remix IDE. At the same time this finding is based on critical analysis of the manual audit.
- We found 0 critical, 1 high, 0 medium, 7 low, and 1 very low-level issues.
We confirm that all issues are fixed in the revised smart contracts code.
Audit Report in PDF
Audit Report Flip book
Please wait while flipbook is loading. For more related info, FAQs and issues please refer to DearFlip WordPress Flipbook Plugin Help documentation.