-
Notifications
You must be signed in to change notification settings - Fork 241
Presentation compare continuous time swaps
⚠ This file is automatically generated from this org file using this script.
The exported presentation can be accessed via this githack link.
REVISIONS:
Date | Notes |
2024-04-04 | EthereumZuri.ch 2024 presentation |
2024-04-19 | ETHTallinn 2024 presentation |
- Why you should trade time-continously.
- What different designs of decentralized exchange there are.
- A Comparison of these designs.
- Reference: https://advisor.visualcapitalist.com/cost-of-trying-to-time-the-market/
- Reference: https://advisor.visualcapitalist.com/cost-of-trying-to-time-the-market/
- user: a normal ethereum user who sends transactions.
- searcher: advanced ethereum user specialized in finding MEV opportunities and sending advanced transaction types like bundles.
- builder: party specialized in the construction of ethereum execution payloads using transactions received from users and searchers (trusted by searchers and users for fair inclusion).
- validator: party which signs and submits a beacon block to the network. It is also called proposer, hence the term PBS (Proposer Builder Separation).
(courtesy to https://flashbots.mirror.xyz/)
This is possible because the transaction is transparent through out the supply chain (even with PBS, where 95% of validators are utilizing it using MEV-Boost.)
Let swaps happen (virtually) every block, modeled with continuous-time:
- avoid market timing.
- minimize the single-block MEV risk.
- The curve represent the constant function used: constant (liquidity) product.
- A swap is instant, and it moves the product from blue point to red point instantly.
- With some magic, to be explained shortly, we make the “point” moves smoothly along the curve over time.
- Liquidity bootstrap required (TVL == funds at risk): YES
- Complexity to provide liquidity: SIMPLE, almost same as Uniswap V2
- MEV protection: SAFE
- A LP sends two money streams, one for token A, one for token B, and receives them back simultaneously.
- A trader sends one money stream for token A, in exchange for another money stream for token B.
- LPs provide the difference, and take fees from the streams.
Like an “Aqueduct” that routes money streams.
- Liquidity bootstrap required (TVL == funds at risk): NO
- Complexity to provide liquidity: HIGH, due to its unconventional model
- MEV protection: SAFE
- TWAP stands for “Time Weighted Average Price”. TWAP was added in Uniswap v2 and improved in Uniswap v3.
- A price cumulative is re-calibrated with each swap, its value changes per each block.
- One can observe price cumulatives of two time points, and calculate the average price of that time window.
Note: Uniswap V3 differs in using geometric mean instead.
Comparing two weeks data of OP-USDC spot prices (from Yahoo Finance) and the average prices sinces the last observation (green dots):
- Liquidity bootstrap required (TVL == funds at risk): NO
- Complexity to provide liquidity: SIMPLE.
- One benchmark price,
- flexible, agnostic liquidity source,
- and competitive.
- MEV protection: SAFE for traders; a competitive challenge to be solved by the liquidity movers.
- Reference: https://www.paradigm.xyz/2021/07/twamm
- “The Time-Weighted Average Market Maker (TWAMM) provides the on-chain equivalent of the TWAP order.”
- “Because it processes trades in between blocks, it is also less susceptible to sandwich attacks.”
Design | Liquidity Bootstrap (*) | Complexity to Provide Liquidity | MEV Protection |
---|---|---|---|
“FlowSwap” | Required | Same as Uniswap V2 | Safe |
ZILMM | Not Required | High and unconventional | Safe |
TOREX | Not Required | simple, flexiby and competitive | Safe (**) |
- (*) Liquidity bootstrap requires higher TVL, and TVL == funds at risk.
- (**) Liquidity movers must mitigate the MEV risks themselves to compete.
Without it, these designs cannot be implemented effectively.
- ERC20 compatible.
- Wrapping existing ERC20 tokens (upgrade) or pure super tokens.
- Providing programmable money streams.
- Composable, hence the “just-in-time” liquidity that minimizes idle liquidity.
Following the progress of TOREX implementation on:
- https://warpcast.com/superboring
- https://warpcast.com/superfluid
Follow me on:
- https://warpcast.com/hellwolf
The source of this slide is available from https://github.com/superfluid-finance/protocol-monorepo/wiki by searching “continuous time swaps”
- Governance Overview
- For Contributors
- Development Process
- Protocol EVMv1 Operations
- Protocol EVMv1 Technical Notes
- Protocol EVMv1 Core Subgraph