What is it about Safemoon SwapandLiquify and numTokensSellToAddToLiquidity

So in the end the function does the opposite of what is advertised, devalues the token, and sends
the LP tokens to a dev wallet

Yes correct. Infact it is advised to change the LP recipient to death address

Any idea what the fix might be?

Is it better to just disable both SwapandLiquify and numTokensSellToAddToLiquidity? Will the liquidity tax per transaction still work correctly?

Sorry I can’t believe this. When somebody swaps BNB to Safemoon he sends over BNB to the contract. right?

Looking at function swapAndLiquify it shows that it adds BNB balance “newBalance” with half of the current token with function addLiquidity.

function swapAndLiquify(uint256 contractTokenBalance) private lockTheSwap {
        // split the contract balance into halves
        uint256 half = contractTokenBalance.div(2);
        uint256 otherHalf = contractTokenBalance.sub(half);

        // capture the contract's current ETH balance.
        // this is so that we can capture exactly the amount of ETH that the
        // swap creates, and not make the liquidity event include any ETH that
        // has been manually sent to the contract
        uint256 initialBalance = address(this).balance;

        // swap tokens for ETH
        swapTokensForEth(half); // <- this breaks the ETH -> HATE swap when swap+liquify is triggered

        // how much ETH did we just swap into?
        uint256 newBalance = address(this).balance.sub(initialBalance);

        // add liquidity to uniswap
        addLiquidity(otherHalf, newBalance);
        
        emit SwapAndLiquify(half, newBalance, otherHalf);
    }

    function swapTokensForEth(uint256 tokenAmount) private {
        // generate the uniswap pair path of token -> weth
        address[] memory path = new address[](2);
        path[0] = address(this);
        path[1] = uniswapV2Router.WETH();

        _approve(address(this), address(uniswapV2Router), tokenAmount);

        // make the swap
        uniswapV2Router.swapExactTokensForETHSupportingFeeOnTransferTokens(
            tokenAmount,
            0, // accept any amount of ETH
            path,
            address(this),
            block.timestamp
        );
    }

    function addLiquidity(uint256 tokenAmount, uint256 ethAmount) private {
        // approve token transfer to cover all possible scenarios
        _approve(address(this), address(uniswapV2Router), tokenAmount);

        // add the liquidity
        uniswapV2Router.addLiquidityETH{value: ethAmount}(
            address(this),
            tokenAmount,
            0, // slippage is unavoidable
            0, // slippage is unavoidable
            owner(),
            block.timestamp
        );
    }

Why do you think it is not adding BNB and Tokens to the LP to receive LP Token? And yes, at the end the owner is receiving the LP tokens. So they wouldnt leave the BNB in the Contract, right?

No it is adding BNB but the BNB inside the pool will rest the saim

1 Like

What happens then with the BNB somebody is swapping?

what do you mean? When someone is swapping BNB for tokens the BNB fo to pair contract

Isnt the BNB from the person who swaps send to the Contract when swap happens?

How would you fix this so that it doesn’t devalue the token and actually does what it advertises?

When the normal user swaps bnb for safemoon, bnb is added to the pool and safemoon is removed. This is normal and will increase the price of safemoon.

When the normal user adds Liquidity to the pool, they add an equal value of safemoon and bnb to the pool. This is normal and doesn’t change the price of Safemoon.

When the safemoon contract itself adds Liquidity to the pool, the contract begins with only the safemoon collected from the Liquidity fee. The contract has no external source of BNB. The net result is an addition of only safemoon to the pool. This is bad. This breaks the Constant Product which is used to determine the price. This lowers the price of Safemoon.

Read more here:

1 Like

Good question. I fixed it by totally rewriting the entire contract so that it operates as advertised.

1 Like

Looks like an interesting rewrite. You don’t have any automatic liquidity at all?

Nothing automatic. Adding Liquidity is incentivized by requiring a wallet holds LP tokens for the advanced analytics section of the moon coin all of dashboard we are building. None of these tokens advertising “Automatic Liquidity” are adding liquidity in the way the liquidity pool was designed to operate. These are all one-sided additions to the liquidity pool. This actually makes all of these tokens inflationary rather than, as advertised, deflationary.

1 Like

I think you are wrong. It sells the token for bnb, then deposit both bnb and the token to the LP, but I am not totally sure how exactly LP is added to the Pool or may be it is sent to a dedicated wallet eg charity wallet.

I think this is bogus claims. I doubt the absolute correctness of your allegations. LoL. Haha

I’m not claiming or alleging anything. I’m simply analyzing the data on the blockchain and the blockchain is fact. Once a block is closed, validated, and sufficiently confirmed there is no changing it, and it’s forever. It’s just a bunch of math. It’s very complicated and obscure math, but math nonetheless. So regardless of one’s understanding of the intricate complexities involved, you can’t argue math.

In fact, it’s so predictable and so automatic, that I coded a price predicting twitter bot to tweet right before these lopsided liquidity dumps happen. I’m able to determine with 100% accuracy the exact amount the price will drop and the moment it will happen. That my friend, is math.

2 Likes

I dont doubt the effects you are showing, but the code definitely does swap token to eth

Now to better understand this, does it mean it swaps token with the router to bnb from its own LP, so it has BNB then adding this BNB with collected fee tokens back?

That is correct, the code does swap the tokens for ETH or BNB or whatever the token happens to be paired with. But the source of BNB is the tokens liquidity pool. It’s not an external source of BNB.

In the same transaction this is what happens:
-The token contract starts with 500 Billion tokens
-The token contract initiates a swap and sends 250B tokens to it’s own Liquidity Pool and receives BNB in return.
-The token contract initiates the ‘addLiquidity’ function and sends ALL the BNB it just received, and the other 250B tokens back to the liquidity pool.
-The LP tokens are then sent to a privately held, unlocked developer wallet.
This all happens in the same transaction.

The end result is a liquidity pool that has 500B more tokens, but the exact same amount of BNB. This actually breaks the ‘Constant Product’ which is the mechanism determining the price of the token.

Here are 2 plots of liquidity pool price curves. On the left side is what the price curve should look like. The X & Y axis represent the Quantity of Token A & the Quantity of Token B in the liquidity pool. When a liquidity pool is first initialized the two quantities are multiplied and they create something known as the ‘constant product’. This number is supposed to be a Constant. The number of output tokens a trader receives for their input tokens is calculated such that after the trade, the product of the two liquidity pool reserves is the same as it was before the trade

This is a plot of the “Constant Product” for Safemoon. This should be a nearly flat line with an extremely slight slope due to the small fee paid to liquidity providers. Safemoon’s constant product plot is an uphill staircase. Each ‘step’ in the plot is one of these automatic token dumps. If you look closely you’ll see that the line is also sloping upward. This is because the liquidity pool is receiving token reflections. This further devalues the token and breaks the ‘constant product’. Also, the “rewards” paid to holders are actually a net loss due to how much these operations devalue the token.

Thank you. Just took a look in your contract. Some questions

  • What is function “deliver” used for?
  • You burn 2% on each transaction. Burning in the case of moving the fee token into the balance of the burn address. Why do you think “burning” token will help the price stability? The tokens are still part of the total sum so the liquidity pool will not become more value?
  • why is _transferBurn function adding reward token? wouldnt the burn address stay without rewards?