$WORM 🌕 logic — Price Constant / K Factor in DeFi Automated Market Makers

4 min readSep 4, 2022

The ‘Spiral token contract’ suddenly appeared with a wild, yet simple mechanism. They had found some maths in the Uniswap Automated Market Maker (AMM) logic which can benefit a token and its price action; Direct Liquidity Injection.

This was first done by RFCTR — the first ever fork of RFI (which began the trend of tax-reward tokens), but the idea only hyped recently.

How it works; the contract directly injects tokens, and not the pair token to the liquidity pool on every transaction, over time increasing the K Score/Constant (read on for explanation).

The only problem with it being; injecting a token directly affects the price negatively. $WORM fixes this by burning 3x/4x (on buy/sell) as what is injected to liquidity.

In this article we want to cover why this is a really cool find, and how we see SpaceWorm makes it better.

The Uniswap Docs have some good info on how the price constant works, but may be a bit technical. Not many people seem to understand this, so we wanted to break it down in a more simple way, with examples:

Basically in DEX Automated Market Makers, the price (amount of tokens received), slippage etc is calculated via the K Score/Constant.

To calculate K Score:

Token * pairToken = K Score

(For the sake of this example; T * U = Constant)

To start with let’s say our pool holds :

1000 T / 10 U — making it a constant of 10,000

> Someone buys using 1x pair unit for 100 tokens

(since they purchased 10% — slippage would make this closer to 80–90 tokens depending on current movement — higher K score would give more tokens)

For the sake of simplicity in this example, let’s assume the slippage makes it 80 tokens.

Assuming 80 tokens flat. This would make the pool now :

920 T / 11 U — constant of 10,120

The traditional `swapAndLiquifiy()` function with a 10% tax would return roughly 4 tokens and 0.04 pair unit — less the 0.05% (*0.0005) swap fee from a properly implemented swapAndLiquify function— which makes it :

4–4*0.0005 = 3.998 for the T, and

0.04–0.04*0.0005 = 0.03998 for the U

Calculating it from the 80 directly — 924 T / 11.04 U — constant of 10,200.9

With the estimated fees (the constant would actually come out ahead/slightly higher):

923.998 T / 11.03998 U = constant of 10200.91944

However — now the important part.

If 10% tax returns 8 tokens ONLY, directly injected back to LP:

928 T / 11 U — constant of 10,208

This “liquidity trick” gives a progressively higher K Score, which over time (buys+sells) will increase & benefit stability / floors, slippage, price action and so on.

Note: the examples don’t claim to be fully accurate to the number for slippage, fees etc, and are just estimates for the sake of the explanation.

Conclusion :

This could be broken down a lot deeper, but wanted to try to cover the value this brings in the most simple way.

Omitting the swap and providing tokens directly to liquidity appears to give an additional 0.07%-ish gain in the way “LP value” is calculated for each swap / transaction.

It also allows for the liquidity injection + burn to be done automatically with minimal logic on every TX — meaning less fees to be paid ; since there are less transactions/trades happening within the contract (no swapAndLiquify etc).

Over time what it does is create “less slippage”, improve floors, and increase the value of the token rather than decrease it. (In the other tokens case it would be reducing the ”real value” of the LP — over time making people pay more while more tokens are added to liquidity, here the burn cancels this out)

The auto-burn mechanism gives SpaceWorm a pump factor instead, and pushes it up on transactions in either direction + improves the K Factor at the same time ~

We found this particularly interesting (and confusing at first), so we wanted to put some content together around it.

TL;DR :

The SpaceWorm contract should more than fix the issue with ‘liquidity hack’ Spiral discovered, via the burn, also fixing the issue with other ‘burn tokens’ — by injecting liquidity. Plus by not renouncing the contract, and having individually renounceable functions helps ensure project longevity, the possibility of CEX listings — and the ability to change the fees/burn if needed in the future.

We hope this helps the Worm Fam understand even just a little bit more about the technical side!