Problems PoNW Solves
Last updated
Last updated
The liquidity function present in most "meme" coins, such as Safemoon, does not work as advertised. In fact, this function puts tremendous inherent sell pressure on the token. And unfortunately, this pressure is not adequately offset by reflection rewards.
It occurs because the price impact of the liquidity event is much greater than the reflection rewards impact. In addition to this, the liquidity function effectively siphons value from other liquidity providers into the control of the contract owner.
Automatic Lopsided “Add Liquidity” Events: These events devalue the token in relation to their primary pegged token (ex: BNB) because the liquidity being added is one-sided. None of these tokens advertising “Automatic Liquidity” are adding liquidity in the way the liquidity pool was designed to operate, quite the opposite. These tokens are actually inflationary rather than, as advertised, deflationary.
Liquidity Pool (LP) Is Not Excluded From Rewards: This effectively cancels out the rewards paid to all holders, because the liquidity pool receives one-sided rewards added to the pool, with no BNB added to keep price constant or on the rise.
Contract Steals Gas: If the token contract needs to perform one of its automatic actions, it simply piggybacks onto the next transaction in line, leaving the next user stuck paying an unnecessarily large gas fee.
The “Burn” Address Doesn’t Receive New Tokens: Apart from the initial burn, no additional tokens are ever transferred to the burn address.
MAJOR RUG PULL RISK: Liquidity Pool Tokens usually go to a developer wallet. Then these LP Tokens, retrieved from the automatic lopsided “add liquidity” events, are transferred to the contract owner. These tokens can be withdrawn from the Liquidity Pool at any time and put all holders at risk of a rug pull.
STEP 1: The contract accumulates Safemoon from reflections and splits the balance in half
STEP 2: The contract then sells half of the accumulated Safemoon balance for BNB. This results in adding that half of the Safemoon to the LP and extracting 5 BNB.
STEP 3: Finally, the contract pairs up the remaining Safemoon, with the BNB received from the previous step, and adds it to the existing liquidity pool.
As you can see, the total initial balance of BNB in the pool is the same as the ending balance, 100 BNB. Contrarily, the total initial balance of Safemoon tokens in the pool is 1,000,000. However, after the liquidity event, the ending balance is up to 1,200,000 Safemoon tokens. Simple supply and demand economics teaches us that rising supply with no change in demand = price depreciation for Safemoon.
The swap and liquify function present in most meme coins, like Safemoon, actually devalues the token approximately 1-5% each time it is executed. The function is performed automatically when the collected “_taxFee” in the contract reaches the required threshold. During periods of high trade volume, and depending on the specific implementation, this function can execute 1-10 times a day.
The function is advertised as something that adds Liquidity to the pool. But this is incorrect because in order to properly add Liquidity to the pool, it must be added in equal value to both sides. If only one token is added to the pool, the value of that token decreases. The WBNB came out of the same Liquidity pool it’s put right back into.
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 not ideal and breaks the Constant Product, which is used to determine the price, thus lowering the price of the token.
