In Chapter 4: Zap, we saw how to easily add or remove liquidity from an existing SelfPeggingAsset (SPA) Pool using a single transaction. But what if the pool you need doesn’t exist yet? How are new pools, along with their associated LPTokens and WLPTokens, created in the first place?
Imagine you want to open a new currency exchange booth, but instead of just one booth, you want to open many, each specializing in a different pair of currencies (like USD/EUR, or in our case, Token C/Token D). Building each one from scratch would be slow, expensive, and might lead to inconsistencies.
You’d want a standardized process, like a franchise headquarters, that provides blueprints and helps you quickly set up new, identical booths with the right configurations.
The SelfPeggingAsset Factory acts exactly like this franchise headquarters for our digital currency exchange pools. It provides a single, reliable way to deploy and configure a whole new trading ecosystem for a specific pair of tokens.
The SelfPeggingAssetFactory
is a smart contract whose only job is to create new instances of other related contracts. Think of it as:
SelfPeggingAsset
pool, an LPToken
, a WLPToken
, and a RampAController
should be built.Specifically, when you use the factory to create a pool for, say, Token C and Token D, it will:
LPToken
contract specifically for the C/D pool.RampAController
to manage the pool’s ‘A’ parameter.SelfPeggingAsset
(SPA) pool contract configured to use Token C, Token D, the new LPToken
, and the new RampAController
.WLPToken
contract that wraps the new LPToken
.All of this happens reliably through one interaction with the factory.
Let’s say you want to create a brand new pool for swapping between two stablecoins, Token C (USDC) and Token D (DAI). You know their contract addresses and they are standard ERC20 tokens.
Your Goal: Create a new SPA Pool ecosystem for USDC/DAI using the factory’s default settings for fees and the ‘A’ parameter.