What is it about Safemoon SwapandLiquify and numTokensSellToAddToLiquidity

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?

Is it just not possible to do two-sided automatic liquidity? I like the project but I don’t see a dashboard as incentive enough for people to provide liquidity, do you struggle with liquidity?

These are so interesting, been going through the incoming dump tweets, spot on

  • The ‘deliver’ function allows any wallet to donate directly to the funds distributed as rewards. I actually copied that from the original Safemoon contract and it did take a bit of testing with my test contracts to figure out what it was actually doing. I did verify its functionality though. I found it pretty interesting in Certik’s Safemoon audit that neither Certik nor Safemoon knew what it was for.

  • That is correct, sending tokens to the burn address does not directly effect the price of the token. Instead, it takes tokens permanently out of circulation. The effect of removing tokens from circulation decreases the market cap. This stabilizes the token price because it increases the ratio of BNB available in the Liquidity Pool to cover the market cap. For example; if a token has $1,000,000 worth of BNB in the Liquidity Pool and a $10,000,000 market cap then 10% of that total market value is covered by the available funds. This creates a situation where all LP token swaps have a price impact 10x of the swaps face value. So if $1,000 is swapped, the market cap would change by $10,000. If we jump forward in time after a lot of transactions have taken place, and for sake of an easy calculation, lets say the available funds in the LP is still $1,000,000, the price has stayed fairly consistent, but a lot of transactions have taken place and a lot of tokens have been removed from circulation leaving the new market cap at $5,000,000. Now the ratio of available BNB to cover the market cap is at 20% and the price will fluctuate less on large trades. We’ve all heard of the term ‘bubble’, the bubble is that gap between the market cap and the available funds to cover the market cap. The way Safemoon and others operate with these backwards liquidity additions actually continually shift that percentage in the wrong direction making things more unstable as time goes on.

  • The burn address is forever excluded from rewards on our contract and the rate is fixed to 2% of each transaction. This actually makes the first 4 lines in the _transferBurn function totally unnecessary:

  • I should have written it like this:

1 Like

After the dashboard is released we have a very exciting new use case that will pair with the dashboard and add balanced liquidity to the pool. I can’t give away too many details because no one is doing anything like this yet. We will be announcing what this is in the next month or so.

Just wondering why anybody would move his own tokens to the total fee? And nobody contributes from this. _tHODLrRewardsTotal is not used anywhere? Also how would they know how to do that :slight_smile: I dont think that anyone checks the contract code looking out for a donation :slight_smile:

Another thought, I believe they didn’t care for the deflation because they want others to be able to swap tokens. If there is only worth 5 BNB i guess they want to put back tokens so others can still swap.

What’s the best way to remove all of the automatic liquidity features? Just delete anything to do with SwapandLiquify?

it is quite simple. simply set false the “swapandliquifyenabled” function

Thanks Bro, and easy explanation :+1:

Interesting … have a look at my Safemoon rewrite https://github.com/solidity-guru/safetoken which removed some redundant code and prepared the contract to be “proxified” :wink:

I think, ultimately, all these contracts should be done in a way like this:

contract MyToken {
    private ILiquifier liquifier;
    private IReflectFinance rfi;
    private ITokenomics tokenomics;

    constructor(address liq, address refl, address tknmx){
      liquifier = ILiquifier(liq);
      rfi = IReflectFinance(refl);
      tokenomics = ITokenomics(tknmx);

    function transfer(address sender, address recipient, uint256 amount) public {
      uint256[] fees = tokenomics.getFees();