The tree wallet contains about 34% of the original supply. That worries you? Let us explain it to you briefly:

The Tree wallet cannot fall below 34% because we have developed a mechanism that simply does not allow this!

Here is how the contract works:

The crucial part is in the lines 601 - 604.

They are only executed if the charity owner (tree wallet with the address 0x99e4004be8797ad18f0f427f6db26da0b6d26613) wants to make a transaction.
You can check this under the read functions on BSC: https://bscscan.com/address/0x5ab41eaa399e0dbdb35bdf49dc8ca0c0692f5fc5#readContract

So when the charity owner tries to sell, the current balance of the charity owner minus the value to be sold is calculated (line 602), if this value (its called predictedTokenBalance in code) is then less than 34% (= 340 billion Grooots) the function terminates and the transaction will never take place (line 603).
This part of the function is therefore more difficult to read because an auxiliary function is used. To understand this I have to explain something else:

To calculate the token count much more precisely, you convert the token amount into another unit. This is done in this helper function: "reflectionFromToken()".
The locked value of the CharityWallet is stored in the variable "_charityTokenLimit", you can find it in line 454.

_rOwned[sender] = the balance of the applicant.
_rOwned[] is a so called "Mapping", all Holders and their balances are stored here.

Contract link: (Contract Source Code Verified - Exact Match on BSCSCAN)

https://bscscan.com/address/0x5ab41eaa399e0dbdb35bdf49dc8ca0c0692f5fc5#code

You are welcome to test and verify the code and then report to everyone else that the code is safe and we are telling the truth. (Github link is on top)

Thank you!

So if the sender is charity owner, then the transferred value minus the current balance is calculated. If the new value is below the charity token limit the transaction fails. The variable charitytokenlimit defines the limit. For easy examples check the bottom of the website.

SECURITY AUDIT PASSED!

Our $GROOOT smart contract has been
audited and approved by TechRate.org

Tree wallet – Locked liquidity examples:


Tree-Wallet total Supply:
350,000,000,000 GROOOT

Tree-Wallet wants to sell:    11,000,000,000 GROOOT

350,000,000,000 – 11,000,000,000 = 339,000,000,000 GROOOT

In this case Transaction fails cause the balance of Tree Wallet would be under 34%
(34% = 340,000,000,000)

Example 2:

Tree-Wallet total Supply: 350,000,000,000 GROOOT

Tree-Wallet wants to sell:     10,000,000,000 GROOOT

350,000,000,000 – 10,000,000,000 = 340,000,000,000 GROOOT

In this case Transaction goes forward cause the balance of Tree Wallet would be 34% or more.

Example 3:

Tree-Wallet total Supply: 350,000,000,000 GROOOT

Tree-Wallet wants to sell:       9,000,000,000 GROOOT

350,000,000,000 – 9,000,000,000 = 341,000,000,000 GROOOT

In this case Transaction goes forward cause the balance of Tree Wallet would be 34% or more.

Conclusion:

The amount of 340,000,000,000 GROOOT is totally locked in a blackhole forever.