Launchpad
pylon-protocol/launchpad contracts define launchpad logic used for Pylon Investment Pools and Pylon Swap.
- pylon-protocol/launchpad/lockupcontracts wrap around- pylon-protocol/core/poolcontracts, by accepting UST but locking DP tokens released within the lockup contract until a pre-set expiry period has passsed. This only allows depositors to claim back their deposits after the given lockup period.
- pylon-protocol/launchpad/swapcontracts define a virtual AMM, of which:- all UST entering this pool is locked within this contract, and returns PROJECT tokens at a fixed ratio after minimum lockup period have passed. 
- if traders try to reclaim UST before the lockup period: - define - max_swappable
- define a virtual Uniswap-like AMM mechanism, whereby: - liquidity given equals - max_swappable. for instance, if- max_swappableis given as 5M, there exists a 5M UST - 5M PROJECT virtual AMM pool.
 
- any PROJECT accepted by the swap pool is burned, but internal accounting logic treats them as a swap rather than a burn. For example: - Alice wants to swap her 1M vested PROJECT back to UST. Assuming that no one else have swapped beforehand, this will result in: - a virtual balance increase from 5M PROJECT to 6M, and an effective balance decrease of 1M PROJECT. 
- approximately 0.83M UST is returned to Alice instead of the initial 1M deposited (calculated as: - 5M - { 5M UST * 5M PROJECT / (5M + 1M) PROJECT }UST ), resulting in a 0.17M UST loss in total for Alice.
- virtual AMM state is updated to: 4.17 UST - 6M PROJECT 
 
- If Bob were to swap another 1M vested PROJECT back to UST, Bob would receive 0.6M UST, resulting in a 0.4M UST loss in total for Bob. 
 
 
 
All tokens reverse-swapped on Pylon Swap will be permanently burned.
Last updated
Was this helpful?
