⚖️ Stabilizer Pool

During the deploying of the linking asset tPUMP a reference stabilizer pool will be created. Its main purpose is to provide a continuous reference for the liquidity available across all tails and maintain a healthy collateralization between all the assets circulating in the omnipool and the available USDC (or equivalent in wMETIS)

The stabilizer pool will act as just another tail, with the only difference being it will also be responsible for handling tPUMP minting.

tPUMP will not be minted if the health factor is insufficient for covering the deposited asset.

Importance of V3 liquidity pools as price oracles and protection against financial attacks

One of the most common attacks in liquidity management are flashloans attacks. As the whole protocol needs to have price references when liquidity is added or removed, using V2 liquidity pools will expose the protocol to continuous flash loans attacks. V3 pools enable Pumpkin to calculate tPUMP proportions and available liquidity using TWA prices and liquidity.

tPUMP

tPUMP acts as the synthetic liquidity counterpart for each tail created.

It has no underlying value apart from the assets deposited in the protocol which could be more or less liquids in other markets.

As it is impossible to measure and aggregate all other liquidity sources, there must be a stabilizer asset that acts as the main liquidity source for tPUMP. That token will be USDC in Pumpkin V1 and actual tPUMP price should be considered the fairer price and is expected to be arbitraged between all other assets in the omnipool.

New tails should pass exhaustive liquidity and security tests in order to participate in Pumpkin Protocol as they could be an attack vector if not handled properly. tPUMP enables an interesting property within the omnipool and the attached AMM as they make any Token A and Token B highly liquid despite the USDC.

Example for clarification

Suppose that we have,

• 100k USDC

• and 100k USD worth of Token A

• and 100k USD worth of Token B

To create Token A / USDC and Token B / USDC liquidity pools in an AMM V2 (or V3 using full ranges), we would need at least 200k USDC.

Using the Pumpkin Omnipool, those 100k USDC could be deposited in the wMETIS/ tPUMP tail, and the same with the Token A and Token B.

Therefore, 100k USDC provides the same liquidity for both Token A and Token B as it would have provided in plain AMMs.

What’s more, Token A and Token B will also be highly liquid with respect to each other and can be traded without even using USDC.

This enables new and interesting trades and swap fees revenues, as well as native on-chain routing where any smart contract can calculate the path needed to swap Token A for Token B or vice versa without knowing neither the liquidity pool addresses nor the intermediate hops (Token A / USDC USDC / WETH / WETH / Token B, for example).