Scroll
[

Treasury

]

YEARN.FINANCE (Ethereum Mainnet)

‍0x93A62dA5a14C80f265DAbC077fCEE437B1a0Efde

Security Score:

Low

The score is calculated based on lines of code and weights assigned to each issue depending on the severity and confidence. To improve your score, view the detailed result and leverage the remediation solutions provided.

[ SECURITY ASSESSMENT ]

[ SECURITY SCORE ]

48.62
/
100
YEARN.FINANCE (Ethereum Mainnet)
Critical
The issue affects the contract in such a way that funds may be lost, allocated incorrectly, or otherwise result in a significant loss.
High
High-severity vulnerabilities pose a significant risk to both the Smart Contract and the organization. They can lead to user fund losses, may have conditional requirements, and are challenging to exploit.
Medium
The issue affects the ability of the contract to operate in a way that doesn’t significantly hinder its behavior.
Low
The issue has minimal impact on the contract’s ability to operate.
Informational
The issue does not affect the contract's operational capability but is considered good practice to address.
Gas
This category deals with optimizing code and refactoring to conserve gas.

[ Scan Duration ]

19 sec
YEARN.FINANCE (Ethereum Mainnet)
Critical
The issue affects the contract in such a way that funds may be lost, allocated incorrectly, or otherwise result in a significant loss.
High
High-severity vulnerabilities pose a significant risk to both the Smart Contract and the organization. They can lead to user fund losses, may have conditional requirements, and are challenging to exploit.
Medium
The issue affects the ability of the contract to operate in a way that doesn’t significantly hinder its behavior.
Low
The issue has minimal impact on the contract’s ability to operate.
Informational
The issue does not affect the contract's operational capability but is considered good practice to address.
Gas
This category deals with optimizing code and refactoring to conserve gas.

[ Lines of Code ]

218
YEARN.FINANCE (Ethereum Mainnet)
Critical
The issue affects the contract in such a way that funds may be lost, allocated incorrectly, or otherwise result in a significant loss.
High
High-severity vulnerabilities pose a significant risk to both the Smart Contract and the organization. They can lead to user fund losses, may have conditional requirements, and are challenging to exploit.
Medium
The issue affects the ability of the contract to operate in a way that doesn’t significantly hinder its behavior.
Low
The issue has minimal impact on the contract’s ability to operate.
Informational
The issue does not affect the contract's operational capability but is considered good practice to address.
Gas
This category deals with optimizing code and refactoring to conserve gas.

[ THREAT SUMMARY ]

Threat scan is designed to assist users in identifying potential rug pull scams by providing an in-depth analysis of a smart contract's code and highlighting any potential red flags that may indicate a scam.

IS SOURCE CODE VERIFIED
The contract’s source code is verified.
Source code verification provides transparency for users interacting with smart contracts. Block explorers validate the compiled code with the one on the blockchain. This also gives users a chance to audit the contracts.
PRESENCE OF MINTING FUNCTION
The contract cannot mint new tokens. The _mint functions was not detected in the contracts.
Mint functions are used to create new tokens and transfer them to the user’s/owner’s wallet to whom the tokens are minted. This increases the overall circulation of the tokens.
PRESENCE OF BURN FUNCTION
The tokens can not be burned in this contract.
Burn functions are used to increase the total value of the tokens by decreasing the total supply.
SOLIDITY PRAGMA VERSION
The contract can be compiled with an older Solidity version.
Pragma versions decide the compiler version with which the contract can be compiled. Having older pragma versions means that the code may be compiled with outdated and vulnerable compiler versions, potentially introducing vulnerabilities and CVEs.
PROXY-BASED UPGRADABLE CONTRACT
This is an upgradable contract.
Having upgradeable contracts or proxy patterns allows owners to make changes to the contract’s functions, token circulation, and distribution.
OWNERS CANNOT BLACKLIST TOKENS OR USERS
Owners cannot blacklist tokens or users.
If the owner of a contract has permission to blacklist users or tokens, all the transactions related to those entities will be halted immediately.
PAUSABLE CONTRACTS
This is not a pausable contract.
If a contract is pausable, it allows privileged users or owners to halt the execution of certain critical functions of the contract in case malicious transactions are found.
CRITICAL ADMINISTRATIVE FUNCTIONS
Critical functions that add, update, or delete owner/admin addresses are not detected.
selfdestruct() is a special function in Solidity that destroys the contract and transfers all the remaining funds to the address specified during the call. This is usually access-control protected.
CONTRACT/TOKEN SELF DESTRUCT
The contract cannot be self-destructed by owners.
Renounced ownership shows that the contract is truly decentralized and once deployed, it can’t be manipulated by administrators.
ERC20 RACE CONDITION
The contract is not vulnerable to ERC-20 approve race condition vulnerability.
ERC-20 approve function is vulnerable to a frontrunning attack which can be exploited by the token receiver to withdraw more tokens than the allowance. Proper mitigation steps should be implemented to prevent such vulnerabilities.
RENOUNCED OWNERSHIP
The contract's owner was not found.
Renounced ownership shows that the contract is truly decentralized and once deployed, it can’t be manipulated by administrators.
OVERPOWERED OWNERS
The contracts have not defined any owner-controlled functions.
Giving too many privileges to the owners via critical functions might put the user's funds at risk if the owners are compromised or if a rug-pulling attack happens.
COOLDOWN FEATURE
The contract does not have a cooldown feature.
Cooldown functions are used to halt trading or other contract workflows for a certain amount of time so as to prevent users from repeatedly executing transactions or buying and selling tokens.
OWNERS WHITELISTING TOKENS/USERS
Owners cannot whitelist tokens or users.
If the owner of a contract has permission to whitelist users or tokens, it’ll be unfair toward other users or the transaction flow may not be executed impartially.
OWNERS CAN SET/UPDATE FEES
Owners cannot set or update fees in the contract.
HARDCODED ADDRESSES
The contract was hardcoding addresses in the code.
OWNERS UPDATING TOKEN BALANCE
The contract does not have any owner-controlled functions modifying token balances for users or the contract.
FUNCTION RETRIEVING OWNERSHIP
No such functions were found.
If this function exists, it is possible for the project owner to regain ownership even after relinquishing it.
 

Disclaimer

The Reports neither endorse nor condemn any specific project or team, nor do they guarantee the security of any specific project. The contents of this report do not, and should not be interpreted as having any bearing on, the economics of tokens, token sales, or any other goods, services, or assets.

The automated security audit is not meant to replace functional testing done before a software release.

There is no warranty that all possible security issues of a particular smart contract(s) will be found by the tool, i.e., It is not guaranteed that there will not be any further findings based solely on the results of this evaluation.

Emerging technologies such as Smart Contracts carry a high level of technical risk and uncertainty. There is no warranty or representation made by this report to any Third Party in regards to the quality of code, the business model or the proprietors of any such business model, or the legal compliance of any business.

In no way should a third party use these reports to make any decisions about buying or selling a token, product, service, or any other asset. It should be noted that this report is not investment advice, is not intended to be relied on as investment advice, and has no endorsement of this project or team. It does not serve as a guarantee as to the project's absolute security.

The assessment provided by Veritas Protocol is subject to dependencies and under continuing development. You agree that your access and/or use, including but not limited to any services, reports, and materials, will be at your sole risk on an as-is, where-is, and as-available basis. Veritas Protocol owes no duty to any third party by virtue of publishing these Reports.

As one audit-based assessment cannot be considered comprehensive, we always recommend proceeding with several independent manual audits including manual audit and a public bug bounty program to ensure the security of the smart contracts.