PieDAO

Relevant discussion can be found here https://forum.piedao.org/t/pip-59-play-metaverse-index-prospectus/977/10

Summary

Two issues seem to affect the current PLAY allocation: -> “Long tail” of not meaningful allocations. The 9 smallest allocations account for 10% of PLAY in total -> Thin liquidity on DEXes for several assets

Specification

Few issues seem to currently represent a bottleneck to PLAY’ scalability:

1. Several items compose a “long tail” of not very meaningful allocations (the sum of 9 smallest allocations account for 10% of PLAY in total), despite having introduced a min 2% allocation for each asset during the past rebalance. In order to position PLAY on multiple venues (L2 included) PieDAO could be ideally leveraging on some professional support for its market making (MM). Still this long tail makes the required hedging almost impossible for many underlying assets.

2. The thin liquidity available on DEXes for several assets is representing a concrete bottleneck for the minting of decent-sized batches of PLAY. Furthermore, for assets with most of liquidity on Uniswap V3, this can result even more challenging due to its range-concentrated allocation. The need to limit the size of each batch exponentially boost up the gas cost incurred when minting liquidity for PLAY. Vice-versa, the minting of bigger batches incurs in consistent slippage.

Proposed solutions

A possible way to address the above issues would include the following solutions:

A) Removing all assets with negligible liquidity on DEXes + capping the allocation of each asset so to always keep its slippage below 2% when minting PLAY (this by making each asset’s allocation also a function of its DEX liquidity)

B) Drastically cutting the current long tail of micro-allocation, bringing the PLAY underlying assets down to the 8 most relevant assets

The joint application of both solutions proposed (A + B) would result in an allocation optimised form a liquidity standpoint, allowing the minting of up to $1m of PLAY in a single transaction, with total slippage < 1%.

Do you support any of these solutions proposed to optimize the PLAY scalability?