TakoTako
Smart Contract Audit Report

Executive Summary
This report presents the outcomes of our collaborative engagement with the TakoTako team, focusing on the comprehensive evaluation of the complete TakoTako platform.
Our team conducted an initial security assessment from October 22nd to October 29th, 2024 of the contracts folder at commit 5011868
on the team's GitHub repository. This report was updated on November 5th, 2024 to include additional context on the WETHGateway's Ownership controls.
TakoTako functions as a decentralized lending platform, utilizing a system of smart contracts to manage and facilitate asset lending, borrowing, and staking. It allows users to deposit assets, which are then tokenized as collateral-backed securities, enabling them to borrow against their holdings under both stable and variable interest terms. The system dynamically adjusts borrowing limits and interest rates based on real-time market data and internal risk assessments provided through integrated oracle services. Additionally, it incentivizes user participation and liquidity provision through a structured reward mechanism, ensuring a balanced and continuously active lending environment.
Audit Scope
Name |
Source Code |
Visualized |
AToken |
||
StableDebtToken |
||
VariableDebtToken |
||
StakingConfigurator |
||
Api3PriceFeed |
||
AaveOracle |
||
LendingPoolAddressesProvider |
||
LendingPoolAddressesProviderRegistry |
||
LendingRateOracle |
||
LendingPool |
||
WETHGateway |
||
LendingPoolConfigurator |
Name/Source Code |
Visualized |
AToken |
|
StableDebtToken |
|
VariableDebtToken |
|
StakingConfigurator |
|
Api3PriceFeed |
|
AaveOracle |
|
LendingPoolAddressesProvider |
|
LendingPoolAddressesProviderRegistry |
|
LendingRateOracle |
|
LendingPool |
|
WETHGateway |
|
LendingPoolConfigurator |
Audit Findings
No findings were identified, though some centralized aspects are present.
System Overview
ATokens
The AToken Contract facilitates the creation and management of interest-bearing tokens (aTokens) that correspond to underlying assets. For example, an lvWETH aToken corresponds to WETH. The AToken Contract adheres to the ERC-20 standard. It supports ERC-20 functionality and the EIP-2612 permit function. All other state-modifying functions can only be called by the Lending Pool, ensuring controlled management of the token state.
Minting and BurningUsers are minted aTokens when depositing an underlying asset into a Lending Pool. aTokens are burned from a user when withdrawing from a Lending Pool and the corresponding underlying asset is returned to the user.
Reward DistributionThe contract mints rewards as Staking Tokens in a MultiFeeDistribution contract whenever aTokens are minted, burned, or transferred. The amount of rewards is dependant on the amount of aTokens and the time elapsed since the last reward distribution.
Interest AllocationThe contract handles the allocation of interest generated within the Lending Pool. It mints tokens representing interest, with 80% of the interest directed to the Treasury and 20% sent to the Second Treasury.
StableDebtToken
The StableDebtToken Contract manages the stable interest rate borrowing positions within the Lending Pool. While the StableDebtToken Contract is modeled after the ERC-20 standard, it does not fully implement it due to the non-transferable nature of debt. Consequently, there are no transfer functions for StableDebtTokens. Similar to the aToken Contract, all non-ERC20 public functions that modify the state can only be called by the Lending Pool, ensuring secure management of the token state.
Creation and Repayment of StableDebtTokensStableDebtTokens are created when a user borrows from the Lending Pool with a stable interest rate. Tokens are burned when the borrower repays their position.
Reward DistributionWhen StableDebtTokens are minted or burned, rewards are generated as Staking Tokens in a MultiFeeDistribution contract. The amount of rewards earned depends on the amount of tokens and the time elapsed since the last reward distribution.
VariableDebtToken
The VariableDebtToken Contract manages the variable interest rate borrowing positions within the Lending Pool. The VariableDebtToken Contract is modeled after the ERC-20 standard but does not fully implement it, as debt is non-transferable. Therefore, there are no transfer functions for VariableDebtTokens. Similar to the aToken Contract, all non-ERC20 public functions that modify the state can only be called by the Lending Pool, ensuring secure and controlled management of the token state.
Creation and Repayment of VariableDebtTokensVariableDebtTokens are created when a user borrows from the Lending Pool with a variable interest rate. Tokens are burned when the borrower repays their position.
Variable Interest RateThe variable interest rate is constantly adjusted based on the Utilization rate, which measures the liquidity of the corresponding asset within the Lending Pool.
Reward DistributionWhen VariableDebtTokens are minted or burned, rewards are generated as Staking Tokens in a MultiFeeDistribution contract. The amount of rewards earned depends on the number of tokens involved and the time elapsed since the last reward distribution.
StakingConfigurator
The StakingConfigurator Contract manages and updates essential addresses within the protocol, ensuring flexibility and adaptability to meet changing requirements.
Address ManagementThe contract maintains a list of addresses critical to the protocol's operation. This includes addresses for the MultiFeeDistribution, ChefIncentivesController, MasterChef, and ProtocolRevenueDistribution.
OwnershipThe owner may update the MultiFeeDistribution, ChefIncentivesController, MasterChef, and ProtocolRevenueDistribution addresses at any time
Api3PriceFeed
The Api3PriceFeed Contract provides asset price determination by utilizing Api3. It includes fallback mechanisms to maintain continuity in case of data fetching issues. The team must ensure to accurately account for decimals returned by the Api3 Oracle contract. The Api3 Oracle contract is outside the scope of this audit so we are unable to give an assessment in regard to security.
Price DeterminationThe contract uses Api3 to fetch the current price of an asset. This integration allows for real-time and accurate price data essential for various protocol operations.
Fallback MechanismIf Api3 fails to provide an accurate price due to a failed response or a timeout, the contract reverts to the last known good price. This fallback mechanism ensures that price reporting remains continuous.
AaveOracle
The AaveOracle Contract dynamically tracks the prices of various assets by leveraging data from designated Sources. It allows the owner to adapt to changing data sources and ensure consistent price accuracy.
Price TrackingThe contract monitors asset prices based on information reported by each asset's assigned Source. This ensures that the protocol operates with up-to-date and accurate pricing data.
OwnershipThe owner can set or change the Source for any asset at any time. This allows for a dynamic response to changes in data reporting or the reliability of sources.
LendingPoolAddressesProvider
The LendingPoolAddressesProvider Contract acts as a central hub, managing critical addresses within the protocol.
Address ManagementThe contract maintains a list of various key addresses used throughout the protocol. This includes addresses for the LendingPool, LendingPoolConfigurator, and other critical components.
OwnershipThe owner has the authority to:
- Update implementations of registered Proxy addresses.
- Change addresses associated with specific market IDs.
- Adjust administrative roles, including the Pool Admin and Emergency Admin for specific pools.
LendingPoolAddressesProviderRegistry
The LendingPoolAddressesProviderRegistry Contract maintains a comprehensive registry of LendingPoolAddressesProvider contracts.
OwnershipThe owner can:
- Register new AddressProvider contracts.
- Unregister existing AddressProvider contracts.
- This ensures an orderly and efficient framework for managing multiple address providers within the protocol.
LendingRateOracle
The LendingRateOracle Contract is responsible for tracking and setting the borrow and liquidity rates for various assets within the protocol.
OwnershipThe owner can:
- Adjust the borrow rates for any asset at any time.
- Set the liquidity rates for any asset at any time.
LendingPool
The LendingPool Contract enables depositing and withdrawing tokens, minting corresponding aTokens, and managing borrowing and lending functionalities.
Deposit and WithdrawalUsers can deposit supported tokens into the contract, leading to the automatic minting of aTokens corresponding to the deposited tokens. These aTokens are burned when tokens are withdrawn. The contract also allows for deposits and withdrawals on behalf of another address, enabling aTokens to be minted or withdrawn funds to be received by different addresses as specified by the user.
Borrowing and Collateral ManagementUpon depositing sufficient funds as collateral, users can borrow assets from the pool. Before borrowing, users must manually set their funds to act as collateral. The borrowed amount can be a stable or variable interest rate, tracked by the minting of StableDebtTokens or VariableDebtTokens, respectively. Users also have the flexibility to switch between interest rate models at any time.
Users can specify a different address to receive their debt if they have a credit delegation allowance, with corresponding debt tokens being minted and burned accordingly.
Loan Management and LiquidationThe contract imposes no strict deadline for repayment, but accruing interest over time can decrease the loan's health factor. If the health factor drops below a certain threshold, other users can perform a liquidation by paying off part of the borrowed funds and receiving a portion of the collateral, plus an additional bonus. The liquidator can choose to receive the collateral either as aTokens or the actual underlying assets. Improving the loan's health factor can be achieved by repaying borrowed funds or depositing additional collateral.
Flashloan FunctionalityThe contract offers flashloan options where users can borrow all assets from any liquidity pool within a single transaction, provided they return these assets within the same transaction, with a fee of up to 0.09% charged.
Asset ManagementThe Lending Pool Configurator can add new assets to the pool, respecting a limit of 128 assets. Additionally, the owner of the LendingPoolAddressProvider contract can update the implementation of the LendingPool contract at any time.
WETHGateway
The WETHGateway Contract is designed to streamline interactions with the blockchain’s native token within the standard LendingPool framework.
Wrapping & UnwrappingUsers can wrap the blockchain's native token when depositing into and repaying LendingPools. Conversely, the token is unwrapped when users withdraw or borrow from these pools. Additionally, when repaying loans, any excess tokens that were wrapped and not used in the repayment are returned to the user.
OwnershipThe owner of the WETHGateway Contract retains the ability to withdraw any tokens or ETH from the contract at any time. This is used to withdraw errant ETH and tokens as the WETHGateway Contract is not intended to retain any assets.
LendingPoolConfigurator
The LendingPoolConfigurator Contract serves as a central management tool for configuring various aspects of the lending pools.
Ownership RolesPool Admin: The Pool Admin is empowered to make a variety of updates and configurations to the lending pools. This includes updating token implementations, adjusting loan-to-value ratios, modifying liquidation thresholds and bonuses, and managing reserve activation and strategies.
Emergency Admin: The Emergency Admin has the authority to pause all transactions within the contract in response to emergent situations, ensuring the stability and security of the lending pools.
Ownership FunctionalityThe Pool Admin can:
- Update the implementations of aTokens, StableDebtTokens, or VariableDebtTokens.
- Allow or disallow different types of borrowing on any reserve.
- Activate or deactivate reserves, and freeze or unfreeze reserves to manage deposits, borrows, and rate swaps.
- Change a reserve’s strategy contract for determining how interest is generated.
- Update the reserve factor, which determines how much of an asset is kept in reserve.
Vulnerability Analysis
Vulnerability Category | Notes | Result |
---|---|---|
Arbitrary Jump/Storage Write | N/A | PASS |
Centralization of Control |
|
WARNING |
Compiler Issues | N/A | PASS |
Delegate Call to Untrusted Contract | N/A | PASS |
Dependence on Predictable Variables | N/A | PASS |
Ether/Token Theft | N/A | PASS |
Flash Loans | N/A | PASS |
Front Running | N/A | PASS |
Improper Events | N/A | PASS |
Improper Authorization Scheme | N/A | PASS |
Integer Over/Underflow | N/A | PASS |
Logical Issues | N/A | PASS |
Oracle Issues | N/A | PASS |
Outdated Compiler Version | N/A | PASS |
Race Conditions | N/A | PASS |
Reentrancy | N/A | PASS |
Signature Issues | N/A | PASS |
Sybil Attack | N/A | PASS |
Unbounded Loops | N/A | PASS |
Unused Code | N/A | PASS |
Overall Contract Safety | PASS |
About SourceHat
SourceHat has quickly grown to have one of the most experienced and well-equipped smart contract auditing teams in the industry. Our team has conducted 1800+ solidity smart contract audits covering all major project types and protocols, securing a total of over $50 billion U.S. dollars in on-chain value!
Our firm is well-reputed in the community and is trusted as a top smart contract auditing company for the review of solidity code, no matter how complex. Our team of experienced solidity smart contract auditors performs audits for tokens, NFTs, crowdsales, marketplaces, gambling games, financial protocols, and more!
Contact us today to get a free quote for a smart contract audit of your project!
What is a SourceHat Audit?
Typically, a smart contract audit is a comprehensive review process designed to discover logical errors, security vulnerabilities, and optimization opportunities within code. A SourceHat Audit takes this a step further by verifying economic logic to ensure the stability of smart contracts and highlighting privileged functionality to create a report that is easy to understand for developers and community members alike.
How Do I Interpret the Findings?
Each of our Findings will be labeled with a Severity level. We always recommend the team resolve High, Medium, and Low severity findings prior to deploying the code to the mainnet. Here is a breakdown on what each Severity level means for the project:
- High severity indicates that the issue puts a large number of users' funds at risk and has a high probability of exploitation, or the smart contract contains serious logical issues which can prevent the code from operating as intended.
- Medium severity issues are those which place at least some users' funds at risk and has a medium to high probability of exploitation.
- Low severity issues have a relatively minor risk association; these issues have a low probability of occurring or may have a minimal impact.
- Informational issues pose no immediate risk, but inform the project team of opportunities for gas optimizations and following smart contract security best practices.