Living The Dream

Smart Contract Audit Report

Executive Summary

This report presents the outcomes of our collaborative engagement with the Living The Dream team, focusing on the comprehensive evaluation of the LivingTheDream $LTD token contract.

Our team conducted an initial security assessment from June 13th to June 16th, 2024. On June 18th, the report was amended to reflect code changes from the project team. On August 29th, the report was amended to reflect the project's mainnet address.

Living The Dream is an ERC20 token created with the goal of integrating Web 2.0 brands into the Web 3.0 space. LTD's long-term vision features cross-chain staking, a wallet and swap platform, and a gaming and ad platform, offering practical utility and innovation within decentralized finance.

Audit Scope

Name	Source Code	Visualized
LivingTheDream	Ethereum Mainnet	Inheritance Chart. Function Graph.

Name	Address/Source Code	Visualized
LivingTheDream	Ethereum Mainnet	Inheritance Chart. Function Graph.

Audit Findings

All findings have been resolved, though some centralized aspects are present.

Finding #1	LivingTheDream	Low Resolved
Finding #1 - LivingTheDream Low Resolved
Description: The contract contains a payable fallback function, but does not have a function to withdraw the ether. Risk/Impact: Any ether sent to the contract will be permanently stuck. Recommendation: Add an owner-restricted function to withdraw the ether. Resolution: The fallback function has been removed from the contract. The contract will now revert if it is sent ether, preventing any funds from being stuck.
Finding #2	LivingTheDream	InformationalResolved
Finding #2 - LivingTheDream InformationalResolved
Description: Events are not present for the custom functions implemented. Recommendation: Add events in the following functions which make meaningful state changes: `swapAndSend()`, `changeFees`, and `setSwapAtAmount`. Resolution: Events have been added to the functions listed above.
Finding #3	LivingTheDream	InformationalResolved
Finding #3 - LivingTheDream InformationalResolved
Description: In the `_update()` function, it is more gas-efficient to use `fees != 0` instead of `fees > 0`. Recommendation: Replace the one instance of `fees > 0` with `fees != 0`. Resolution: The above recommendation has been implemented.
Finding #4	LivingTheDream	InformationalResolved
Finding #4 - LivingTheDream InformationalResolved
Description: Within the `for` loops in the `setFeeExempt()` and `setBlacklistedMany()` functions, it is more gas-efficient to use `++i` rather than `i++`. Recommendation: Replace both instances of `i++` with `++i`. Resolution: The above recommendation has been implemented.
Finding #5	LivingTheDream	InformationalResolved
Finding #5 - LivingTheDream InformationalResolved
Description: Two instances of a `setFeeExempt()` are present allowing the owner to set a single or many addresses as exempt from fees. For blacklisting, the owner can call `setBlacklisted()` and `setBlacklistedMany()`. These functions are named inconsistently. Recommendation: Rename the instance of `setFeeExempt()` that accepts multiple addresses to `setFeeExemptMany()`. Resolution: The above recommendation has been implemented.

System Overview

TOKENOMICS

The LivingTheDream token has a maximum supply of ~33.33 billion (333,333,333,333) $LTD tokens. The total supply is minted to the owner upon deployment. After deployment, the total supply shall only decrease when tokens are burned, as the contract does not allow for minting new tokens. Any user can burn their own tokens or tokens on another user's behalf up to their granted allowance at any time.

TRANSFERS

The transfer mechanism in the contract includes several checks and features to ensure security and proper fee handling. Transactions involving blacklisted addresses are reverted to prevent them from participating. When trading is disabled, all transfers are blocked. A fee structure is in place where buy transactions incur a 10% fee, and sell transactions incur a 7% fee. These fees are collected in tokens and swapped for ETH when their amount exceeds a specified threshold, ensuring continuous funding to the treasury wallet. Fees are deducted from transfers unless the sender or recipient is fee-exempt. Additionally, users can be designated as Automated Market Makers (AMMs), affecting fee calculations during transactions.

OWNERSHIP CONTROLS

The owner has extensive privileges over the contract’s settings. These include enabling trading, updating the treasury wallet address, changing the buy and sell fees (within a 10% cap), and setting the swapping threshold. The owner can also manage user privileges, such as setting addresses as fee-exempt or blacklisted, or designating addresses as AMMs. Additionally, the owner has the ability to withdraw tokens stuck in the contract, minus the $LTD collected through fees. This control ensures that the contract’s settings can be adjusted as needed within limits while maintaining security and functionality.

As the contract is implemented with Solidity v0.8.x, it is protected from overflows/underflows. The contract complies with the ERC-20 standard.

Vulnerability Analysis

Vulnerability Category	Notes	Result
Arbitrary Jump/Storage Write	N/A	PASS
Centralization of Control	The owner can set total fees on buys and sells up to 10% each at any time. The owner can set any address as blacklisted, fee-exempt, or as an AMM. The owner can update the swapping threshold and treasury wallet.	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!

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.

Go Home