Perpetual Pools is a derivative design using a two-sided pool to allocate collateral to long and short parties. The pool moves collateral between sides per an arbitrary transfer agreement. V1.0 contracts base the transfer agreement on a function called power leverage. This function determines the amount of collateral to move in a leveraged response to a changing price feed. As collateral is moved between the sides, the amount of collateral per share of the pool changes. Pool shares, then, track leveraged exposure to any price feed. These shares are tokenised, creating leveraged long and short tokens.
Perpetual Swaps are instruments that aim to track exactly the price feed at all times, forever. The mechanism that ensures the instrument is tracking the price feed is called the funding rate. Funding rates penalise the side which has higher demand.
In contrast, Perpetual Pools are instruments that magnify exposure to an asset based on the change in its price feed. Long and short shares (tokens) don't aim to track the price. Instead, tokens simply have power leveraged returns. The side which has higher demand pays an implicit rate to the other side in the form of polarised gains.
A new market can be deployed from the Perpetual Pools Factory at any time. All the deployer needs to do is specify the following market variables in the template.
- Price Feed (e.g. ETH/USDC)
- Oracle address (e.g. 0x5f4eC3Df9cbd43714FE2740f5E3616155c5b8419)
- Contract Owner (e.g. Tracer DAO)
- Power leverage (e.g. 3)
- Transfer agreement (For V1.0 this will limited to Power Leverage)
- Collateral asset (For V1.0 this will be limited to USDC)
USDC is a widely adopted and available stablecoin. It's also listed on Arbitrum.
Yes – at a later date. Anyone else may deploy a pool using a different collateral asset in the mean time.
For now. Arbitrum is a L2 scalability solution built on top of Ethereum. It was chosen for the initial markets because it completely inherits L1 security and greatly reduces gas costs per transaction, without compromising on decentralisation. The key benefits of Arbitrum are complete EVM compatibility, and its interactive dispute resolution process which allows for no contract size limit. These benefits are currently unique to Arbitrum.
Perpetual Pools can be also be deployed on Ethereum mainnet.
Pool tokens can exist perpetually without upkeep. In saying that, they lose value over time if the price feed is volatile. It's not recommended that a trader hold these pool tokens long term. Read about the impact of volatility decay in Perpetual Pools here.
At launch, there will be BTC/USDC and ETH/USDC markets, each with a 1p and 3p pool. After these pools prove viable, further pools may be added. New pools can have novel data feeds and different power leverages.
Binance and FTX's leveraged tokens are reliant on trusted, centralised third parties. They need a party to create the leveraged exposure for their tokens by holding a perpetual swap or lending platform position. Perpetual Pools leveraged tokens are created by a decentralised, trustless system. This system is also simple, affordable and does not have slippage or market liquidity risk.
BPTs are Balancer Pool Tokens. These tokens represent a proportional share of the pooled assets in a Balancer AMM.
Traders that deposit pool tokens into their respective Balancer AMMs will receive BPTs. TCR tokens are distributed as rewards to traders that stake BPTs in Tracer's staking interface.
The rebalancing rate is an (inadvertent) effect of collateral skew in a pool. If there's an imbalance between long and short side collateral, the effective leverage for each side is polarised.
A favourable rebalancing rate presents asymmetric upside for the less collateralised side. Their returns are amplified relative to their losses. For the over collateralised side, returns are minimised relative to their losses.
Traders have to commit to buy pool tokens because they are created when the pool updates. The rebalancing event that happens during an update adds all the collateral that was committed during the last hour to the pool and creates the appropriate amount of tokens to return to traders. The same thing happens when a trader sells tokens to a pool. In that case, the pool destroys tokens and takes the appropriate amount of collateral from the pool to return to traders.
As stated above, pool tokens are created/destroyed during a rebalancing event. Because the rebalancing event includes the value transfer (which is calculated at the time of rebalance using the price supplied by an oracle feed), the new proportion of collateral in each side cannot be known prior to the update. Traders mint and burn tokens at the post-update rate even though they have to commit beforehand.
The front running interval is a period before an update that excludes traders' mint and burn orders from the upcoming rebalancing event. If traders don't commit before the front running interval, their orders remain queued until the following update. In Perpetual Pools V1.0, the front running interval will be 300 seconds.