Smart contracts with AntiWhale function

We continue the series of articles devoted to the description of fraudulent schemes in smart contracts. Today we will analyze smart contracts with AntiWhale transfer size limitation mechanism.

In this article, we will look in detail at what the AntiWhale mechanism is, how it differs from the Cooldown mechanism, and when they are used together and when they are used separately.

Cooldown mechanism

Purpose:

The Cooldown mechanism is designed to impose time limits between consecutive transactions from the same address. Its purpose is to regulate the frequency of transactions and prevent excessive buying or selling activity within short time intervals.

Realization:

Time Limits: Cooldown mechanisms set waiting periods between transactions, often based on the time elapsed since the last transaction from a particular address. Users must wait for the waiting period to expire before starting a new transaction.

Indicators:

Timestamp Comparison: Look for code segments that compare block timestamps or use time-related functions. State variables of type lastTransactionTimestamp can be used to track the time of the last transaction.

AntiWhale mechanism

Purpose:

The main purpose of the AntiWhale mechanism is to reduce the impact of large transactions from a single address or a small group of addresses, often referred to as "whales". It aims to prevent excessive concentration of tokens in the same hands and to combat possible manipulation or destabilization of the market.

Implementation:

Transaction size limits: AntiWhale mechanisms typically set limits on the size or value of individual transactions. Transactions exceeding a set threshold result in the imposition of restrictions such as transaction rejection, high fees or other redistribution mechanisms.

Indicators:

Look for code segments that check the size or value of transactions, and such state variables (such as maxTransactionAmount or whaleThreshold), they may indicate the presence of the AntiWhale mechanism. AntiWhale primarily affects users with large transaction volumes and focuses on addressing the concentration of tokens in large holders.

Main differences between Cooldown and AntiWhale:

Parameters	AntiWhale	Cooldown
Parameters:Influence	AntiWhale:Primarily affects users with high transaction volumes.	Cooldown:Applies to all users, regardless of transaction size.
Parameters:Market dynamics	AntiWhale:Focused on solving concentration problems.	Cooldown:Aimed at regulating the frequency of transactions.
Parameters:Project Objectives	AntiWhale:The goal is to distribute tokens and ensure the stability of the market.	Cooldown:Primarily aimed at ensuring market stability and preventing rapid trading.

Utilization Scenarios:

1. Minimizing market manipulation:
   Both mechanisms can be used together to address various market manipulation issues. The AntiWhale mechanism helps to limit the size of large transactions, while the Cooldown mechanism prevents multiple transactions from occurring quickly within a short period of time.
   
   Suppose that one entity owns a significant portion of the total token supply. Without the AntiWhale mechanism, this entity could make large transactions that could cause significant price fluctuations, leading to market manipulation. By limiting the maximum size or frequency of transactions at a single address within a certain period of time, the AntiWhale mechanism aims to prevent large holders from having undue influence on the market.


2. Ensuring fair distribution:
   In the context of new tokens or token sales, preventing a small number of participants from acquiring a disproportionate share of the total supply. Setting limits on the maximum amount that an individual address can purchase during a token sale or within a certain period allows for a more even distribution of tokens among a larger number of participants.


3. Tackling liquidity problems:
   High transaction volumes of large holders can affect liquidity and disrupt the natural price discovery process on decentralized exchanges. By limiting the speed of transactions by large holders, the AntiWhale mechanism helps to maintain a more stable liquidity situation.


4. Price stabilization:
   Preventing fast and large-scale transactions can help stabilize prices. By enforcing AntiWhale restrictions, the token price has more time to adapt to market conditions between transactions.


5. Preventing front-running:
   AntiWhale can be implemented to combat front-running, where traders use time-sensitive information to execute trades before others. The AntiWhale mechanism can reduce the advantage gained by executing trades quickly.


6. Mitigation of Flash-loan and reentrancy attacks:
   AntiWhale can add an extra layer of defense against some flash-loan and reentrancy attacks by limiting the speed of transaction execution.

Potential risks for token holders:

1. Setting AntiWhale limits that are too tight can be a problem for users who really have a need for large transactions.


2. Over-reliance on the AntiWhale mechanism may inadvertently promote centralization if it is implemented without considering the broader ecosystem.

How can you independently determine if such threats are present in smart contracts?

Determining whether an AntiWhale constraint mechanism is present in a smart contract is an important task, here are some tips to help with this:

1. Learn the contract documentation: start by reviewing the contract documentation and specifications.


2. Analyze the transfer functions: examine the functions responsible for transferring tokens (transfer, transferFrom, etc.). Look for conditional statements that impose restrictions on transactions.


3. Check for timestamp comparisons: look for cases where the contract compares block timestamps.


4. Check for state variables: examine state variables that can be used to store AntiWhale related information.


5. Look for functions or modifiers related to time calculations, such as block.timestamp, block.number, or now.


6. Look for parameters that control AntiWhale's behavior: these can be maxTransferAmount, maxTxLimit, and the like. These parameters are often set by the contract owner or through the individual transaction management mechanisms.


7. Examine event logs: check the event logs for special events. Implementations will be able to log relevant information when a transaction is executed, which provides insight into the cooling process.


8. Analyze user-specific logic: if user restrictions are implemented in the contract, check the logic for determining individual transfer limits. This logic may include user attributes, balance or other criteria.


9. Be informed: Keep up to date with the latest developments in our community (Telegram channel) and best practices for fraud detection (our Blog and YouTube channel).

Good news: our Security Scanner successfully finds (including hidden) as well as calculates transfer restrictions (AntiWhale) in 90% of cases. Use our premium subscription and protect your funds from threats.

Although the AntiWhale mechanism is designed to prevent market manipulation and ensure token distribution, fraudsters can use its capabilities to defraud users. Below are some possible scenarios and tips for securing token investments with the AntiWhale mechanism in place.

Example 1: Limitations on the amount of transactions with a cooling-off period (Transaction Amount Limits with Cooldown)

    uint256 public maxTransactionAmount = 1000000; // Maximum transaction amount
    uint256 public cooldownTime = 1 days; // Cooldown time between transactions
    
    mapping(address => uint256) private lastTransactionTimestamp;
    
    function transfer(address to, uint256 value) public {
        require(value <= maxTransactionAmount, "Exceeded maximum transaction amount");
        require(block.timestamp - lastTransactionTimestamp[msg.sender] >= cooldownTime, "Wait for cooldown period to end");
        ...
        lastTransactionTimestamp[msg.sender] = block.timestamp;
    }

This example limits the maximum amount that a single address can transfer within a certain period of time.

It includes a cooling mechanism that provides a waiting period between transactions at the same address. The lastTransactionTimestamp array keeps track of the timestamp of the last transaction for each address.

Example 2: Dynamic translation restrictions (Progressive Transaction Limits)

      uint256 public initialMaxTransactionAmount = 500000; // Initial maximum transaction amount
      uint256 public maxTransactionIncreaseRate = 20000; // Maximum increase rate per transaction
      uint256 public cooldownTime = 2 days; // Cooldown time between transactions
              
      mapping(address => uint256) private lastTransactionTimestamp;
              
      function transfer(address to, uint256 value) public {
          uint256 currentMaxTransactionAmount = initialMaxTransactionAmount + (maxTransactionIncreaseRate * (block.timestamp - lastTransactionTimestamp[msg.sender]) / cooldownTime);
          require(value <= currentMaxTransactionAmount, "Exceeded maximum transaction amount");
          ...
          lastTransactionTimestamp[msg.sender] = block.timestamp;
      }

This example uses a dynamic mechanism in which the maximum transaction amount gradually increases over time.

The maxTransactionIncreaseRate parameter controls the rate at which the maximum transaction amount increases. The lastTransactionTimestamp array keeps track of the timestamp of the last transaction for each address.

Example 3: Whitelisted exceptions (Whitelist Exemption)

    address[] public whitelistedAddresses;
    mapping(address => bool) public isWhitelisted;
    
    uint256 public maxTransactionAmount = 1000000; // Maximum transaction amount
    
    function transfer(address to, uint256 value) public {
        require(value <= maxTransactionAmount || isWhitelisted[msg.sender], "Exceeded maximum transaction amount");
        ...
    }

This example uses whitelist exemptions for specific addresses from AntiWhale restrictions.

Addresses in the whitelistedAddresses array are considered exempt from the maximum transaction amount restriction. The isWhitelisted array determines whether a particular address is whitelisted.

Example 4: Tiered transaction limits (Tiered Transaction Limits)

    uint256[] public tieredLimits = [5000000, 2000000, 1000000]; // Tiered transaction limits for different address balances

    function transfer(address to, uint256 value) public {
        require(value <= getTransactionLimit(msg.sender), "Exceeded maximum transaction amount");
        ...
    }
    
    function getTransactionLimit(address user) internal view returns (uint256) {
        uint256 userBalance = balanceOf(user);
    
        if (userBalance < 10000) {
            return tieredLimits[0];
        } else if (userBalance < 50000) {
            return tieredLimits[1];
        } else {
            return tieredLimits[2];
        }
    }

This example implements tiered transaction limits depending on the balance of the sender's address. Users with a lower balance have a higher transaction limit, and users with a higher balance have a lower transaction limit.

The getTransactionLimit function determines the appropriate transaction limit based on the user's balance.

Example 5: Fees on large transactions (Tax on Large Transactions)

    uint256 public taxRate = 75; // 5% tax rate on transactions exceeding the limit
    uint256 public maxTransactionAmount = 1000000; // Maximum transaction amount
    
    function transfer(address to, uint256 value) public {
        if (value > maxTransactionAmount) {
            uint256 taxAmount = (value * taxRate) / 100;
            uint256 netTransferAmount = value - taxAmount;
    
            // Transfer logic here for the net transfer amount
            ...
        } else {
            // Transfer logic here for amounts within the limit
            ...
        }
    }

In this example, the fee is charged on transactions that exceed the maximum transaction amount.

The commission rate (TaxRate) determines the percentage of the transaction amount. The commission is deducted and then the net amount of the transfer is processed.

Example 6: Tiered limits (Multi-Level Transaction Limits)

    uint256 public maxTransactionAmount1 = 500000; // Maximum transaction amount for tier 1 (500,000 tokens)
    uint256 public maxTransactionAmount2 = 200000; // Maximum transaction amount for tier 2 (200,000 tokens)
    
    function transfer(address to, uint256 value) public {
        if (value <= maxTransactionAmount1) {
            ...
        } else if (value <= maxTransactionAmount2) {
            ...
        } else {
            revert("Exceeded maximum transaction amount");
        }
    }

This example implements multiple levels of transaction limits, where different limits are applied depending on the amount of the transaction.

This allows transaction limits to be set at varying levels of granularity for different volumes of tokens.

Example 7: Dynamic transaction limits depending on balance (Dynamic Transaction Limits based on Token Balance)

    uint256 public maxTransactionPercentage = 5; // Maximum transaction percentage relative to total token supply
    
    function transfer(address to, uint256 value) public {
        uint256 maxTransactionAmount = (totalSupply() * maxTransactionPercentage) / 100;
        require(value <= maxTransactionAmount, "Exceeded maximum transaction amount");
        ...
    }

This example dynamically calculates the maximum transaction amount as a percentage of Total Supply. The maxTransactionPercentage parameter defines the allowable percentage for a single transaction.

Example 8: Time-dependent limits (Time-Dependent Transaction Limits)

    uint256 public maxTransactionAmount = 1000000; // Maximum transaction amount (1 million tokens)
    uint256 public startTime = 1700000000; // Start time in Unix timestamp
    uint256 public endTime = 1800000000; // End time in Unix timestamp

    function transfer(address to, uint256 value) public {
        require(block.timestamp >= startTime && block.timestamp <= endTime, "Transaction not allowed at this time");
        require(value <= maxTransactionAmount, "Exceeded maximum transaction amount");
        ...
    }

In this example, time-dependent transaction restrictions are applied, allowing transactions only within a given time frame.

The startTime and endTime parameters define the period during which transactions are allowed.

Example 9: Progressive taxation(Progressive Taxation)

    uint256 public maxTransactionAmount = 1000000; // Maximum transaction amount (1 million tokens)
    uint256 public taxRate = 2; // Initial tax rate in percentage
    
    function transfer(address to, uint256 value) public {
        require(value <= maxTransactionAmount, "Exceeded maximum transaction amount");
    
        uint256 taxAmount = (value * taxRate) / 100;
        uint256 netTransferAmount = value - taxAmount;
    
        // Transfer logic here for the net transfer amount
        ...
    }

This example presents a progressive taxation mechanism, where a tax (fee) is levied on transactions exceeding a maximum amount.

The tax (fee) rate may be adjusted over time or based on certain conditions.

Example 10: Transaction limits based on holder balances (Weighted Transaction Limits based on Token Holders' Balances)

    uint256 public maxTotalTransactionAmount = 5000000; // Maximum total transaction amount for all token holders
    mapping(address => uint256) public userTransactionLimit; // Transaction limits based on individual token holder balances
    
    function transfer(address to, uint256 value) public {
        require(value <= maxTotalTransactionAmount, "Exceeded maximum total transaction amount");
        require(value <= userTransactionLimit[msg.sender], "Exceeded individual transaction limit");
        ...
    }

This example implements transaction limits based on both the total amount of transactions and the balance of individual token holders.

The userTransactionLimit binding allows you to set personalized limits based on the balances of specific addresses.

 

We hope these examples have helped you better understand the AntiWhale mechanism in smart contracts.

 

Since all information in the blockchain is open (provided, of course, that the source code of the contract is verified), armed with this knowledge you can independently study smart contracts and identify various scam schemes.

However, we've already done it all for you! Sign up for a premium subscription and get access to exclusive filters on smart contracts features and fresh analytics. Increase your chances of successfully investing in profitable tokens.

Regards, Lotus Market team.

All posts