Taxed Liquidity Pools
The proliferation of applications like uniswap, compound, pooltogether and other asset-pooling-based applications have shown that the structure of issuing tokens as a representative ownership of a pool of assets that is used for some purpose to provide a yield is attractive to both users and liquidity providers. The complexity of applications can be greatly reduced using these structures but for the best user experience the application needs to attract liquidity (ideally a whole bunch of it) and hold onto it. Most applications (or protocols, dealers choice) have a built in incentives for liquidity providers like some fee (uniswap) or yield (compound) which flows to liquidity providers but the incremental return from Y to Y+1 is the same regardless of if you contributed capital at time Y-1 or Y-100. This also means you can remove capital and re-deploy it without any negative affect.
While it isn't applicable to all use cases I think that an improvement could be made to this structure by adding an increasing tax on newly deposited capital. Early contributors are taking more risk by using an untested platform so if returns are equal than risk adjusted return for them is actually LOWER than the late comers. Also, as a someone launching a product you want liquidity as fast as possible, in this model if someone was going to contribute anyway it behooves them to get in early. Also, unless a withdraw fee is implemented capital providers can withdraw at any time and then re-contribute, potentially creating more volatility in your application. In a normal liquidity pool example the number of tokens you receive is:
new tokens = (amt contributed / value in pool) * tokens outstanding
In a taxed pool
new tokens = (amt contributed / value in pool) * tokens outstanding * (1 — tax)
Lets step through some examples with a contribution tax.
This is if all participants are hit with the 1% tax, a new participant joins (with all participants contributing 1 of the base asset) every period, and there are NO returns to the pool. In this model there is a large incentive to be early that tails off, but then maybe then they would be encouraged to pull out their capital after being early and earning a return even if there were no returns from the application.
Adding back the .3% return we now see how early contributors get a benefit compared to the first chart. It is still very heavily weighted to the very first contributors though since each subsequent gross tax for a new participant is a smaller portion of the total amount in the pool. To spread the benefit amongst a larger group of early contributors an increasing fee can be deployed.
Starting the fee at 0 and then increasing .1% per period until reaching a maximum of 2% creates a more even distribution of benefit amongst early contributors, falling off once the cap is hit. The tax increase could be based on time (block) or total amount added (perhaps tracked by tokens minted). It is difficult to map all scenarios into a nice chart but I hope this does a sufficient job in informing the concept. I have a couple applications coming up where this may be put into practice, happy to chat if you think it may be useful for your needs and have questions.
If you are interested in playing around with the model and the settings message me here or on twitter (https://twitter.com/Tompkins_Jon) and I will share a copy of the spreadsheet I used.
