Peggy 2.0 Update: An Omni-EVM Future
As close followers of Sifchain already know, our initial version of Peggy (Peggy 1.0) is our bi-directional Sifchain-Ethereum bridge, allowing users to easily import and export ETH, Rowan, and select ERC-20 tokens across both blockchains. We are extremely proud to have deployed Peggy in the Cosmos Network after its storied history and deep anticipation within the community.
We still have much to do to realize our mission of becoming an omni-chain DEX. In this article, we will explain what the next version of Peggy (2.0) will look like and the reasoning behind the decisions we made.
What did you determine would be in Peggy 2.0 and how did you get there?
As we were planning out the next version of Peggy, we centered around two concerns we’ve been hearing from the community:
1) Getting more tokens on to Sifchain
2) Optimizing our infrastructure to lower the fees associated with relayer gas costs.
After much deliberation, we determined that being laser focused on the vision of a truly omni-chain dex is what would provide the greatest value to traders, liquidity providers, and validators. Peggy 2.0 will be centered around integrations with EVM compatible blockchains, what we are calling Omni-EVM. The sole goal will be to build bidirectional connectivity with EVM blockchains in the most efficient way possible. We are building an extensible framework so that we can onboard new chains with minimal amounts of custom deployment work. This means that Sifchain bridges will be able to be built and deployed significantly faster.
As for concern #2: Import/export fees are a very real pain point for the community and a large barrier to product adoption for lower volume users. At the same time, most EVM chains (sanse Ethereum) already have minimal fees. While the core Sifchain team will not be focused on lowering gas costs in the near term, we will be offering multiple grants to the community in the hopes that active SifDAO members will step up to the challenge and look forward to revisiting fee minimization as a goal down the road.
EVM chains only? What about “omni-chain”?
“A journey of a thousand miles begins with a single step” — Lao Tzu
We remain committed to the vision of “omni-chain”, but it is necessary to begin our journey with the biggest opportunities weighted by cost. EVM-compatible chains are one of the fastest growing chains types in the blockchain ecosystem. Given that we already have a bridge to Ethereum, it only made sense to extend our system to other EVM chains.
What is the opportunity size of Omni-EVM Chain Integration?
Peggy 2.0 will impact the flow of assets on Sifchain in 3 key ways:
- Unlocking volume for all ERC-20 tokens
- Enabling integration with all EVM compatible chains
- Future proofing for EVM ecosystem growth
Unlocking volume for all ERC-20 tokens
As you may already know, we currently only allow a select number of tokens to be imported into Sifchain. In the spirit of being a censorship-resistant, permissionless blockchain, we will be allowing any token to be imported into Sifchain. We believe this is an important step in allowing the community to determine which tokens belong on Sifchain. That said, we will build in safeguards to ensure that users are aware of the implications of interacting with particular tokens (recommended lists and warnings for rebase tokens).
Enabling integration with all EVM compatible chains
In the chart above, we see there is a tremendous opportunity ($618B) to enable trade between Sifchain and EVM compatible blockchains. Excluding Ethereum, the total market cap of EVM compatible chains is a sizable $140B. Note that the numbers above are the liquid market caps of the chains’ main tokens only. It does not include the value of ecosystem tokens on these chains which can be massive in their own right. The top 4 non-Ethereum networks alone have more than $50B in TVL from tokens outside of their main coin.
It should also be further noted that by Sifchain connects to Ethereum Layer 2 chains like Optimism and xDAI. Without Sifchain, Layer 2 chain users will need to wait a substantial amount of time to get their tokens from the Layer 2 back to Layer 1 (7 days in the case of Optimism). With Sifchain, users can move back and forth between Layer 1 and Layer 2 Ethereum in a matter of minutes.
Future proofing for EVM ecosystem growth
Things move quickly in DeFi. EXTREMELY quickly. Along with BSC’s rise, we have also seen exponential growth in chains like HECO and Polygon. Further, businesses that are not crypto-native will likely build their blockchains with EVM compatibility, as JPMorgan already did with Quorum (since sold to Consensys). We can’t predict the future, but we can build our system to capitalize on the wide range of possibilities within the EVM ecosystem.
By making Peggy extensible to all EVM chains, we will be well positioned to quickly enable asset transfer across any chain in the EVM ecosystem. We estimate we will be able to deploy these new bridges in a matter of days.
That said, the vision of a quick and efficient Omni-EVM integration process assumes a solid deployment process. The Sifchain core team is ready, willing, and able to build bridges to other EVM-compatible projects, but our pace can be greatly enhanced by strong cooperation from said projects. If you’re part of one of these chains and want to help your chain get prioritized, please get in touch with Sifchain.
Where does IBC and compatibility with Cosmos-based chains fit into all of this?
Peggy 2.0 will allow for what we call double pegging, or the ability to import a token from one chain and export it to a different chain (explained in “Double Pegging Feature” section). Along with our recent migration to Cosmos .42 (link to future announcement about the .42/IBC upgrade), this means that any EVM token imported into Sifchain will be able to move on to any IBC chain.
Let’s get into the nitty gritty, what needs to be built to make Peggy extensible to any EVM compatible chain?
To start, let’s outline the major features:
- Token Identification System Update
- Double Pegging Feature
- Trusted Source Fungibility Groups
Token Identification System Update
In the current version of Peggy, we use token symbols from Ethereum (ex. ETH -> cETH) as Sifchain coin names for our entire identification system. However, as we support additional blockchains beside Ethereum this will not work as the same token symbol may be used across multiple chains. We needed to create a new token ID system that allows the same token symbol to be used on multiple chains.
Let’s first take a look at how token identification works on Peggy 1.0 when importing the YFI ERC-20 token:
Now, let’s take a look at how this same import will work on Peggy 2.0:
The key differences between Peggy 1.0 and 2.0 are:
- Denom: In our example, the denom field is now unique to the YFI token on Ethereum containing the network from which it came, the Ethereum smart contract address, and the number of token decimals. This convention is used to avoid potential collisions when importing tokens with the same symbol on to Sifchain.
- Symbol: Token symbols are now copied from the origin chain, without a “c” prefix. YFI on Ethereum is effectively YFI on Sifchain. This will also apply to exports (eRowan will be changed to Rowan on Ethereum). This will require an update to our current smart contracts.
Double Pegging Feature
As mentioned earlier, Peggy 2.0 will allow users to import token A from chain X and export token A to chain Y. Extending on the previous example, double pegging YFI token will look like the following:
As in the previous example, YFI is imported onto Sifchain. When the YFI is then exported to Binance Smart Chain for the first time, a new BEP20 token is created with the same YFI symbol and name as well as the network descriptor stored in the token metadata. When the YFI on BSC is then imported back to Sifchain, a check is performed to ensure a new Sifchain token is not created and instead points to the original Sifchain YFI token with denom: coin/ethereum/0xbF45BFc92ebD305d4C0baf8395c4299bdFCE9E/18.
Trusted Source Fungibility Groups
A key problem facing all interchain solutions is what happens when two versions of the same token end up on the same chain (think ETH on the Ethereum network and ETH on Binance Smart Chain both ending up on Sifchain)? Treating them as separate tokens would keep liquidity fragmented and thereby reduce utility of both tokens on the network. We know these are functionally identical tokens, but how do we ensure that we treat them as such?
The answer is fungibility defined by trusted sources, or what we call Trusted Source Fungibility Groups. In the case where we import both ETH from the Ethereum network (ETH-ETH) and ETH from BSC (BSC-ETH), a fungibility group would be defined by community governance such that both tokens become mutually interchangeable. This means that poolers can provide both ETHs as liquidity into one pool, providing benefits to both traders and poolers.
Upon export of the user’s ETH to the BSC network, depending on the underlying ETH tokens held, the user could receive both BSC-ETH and Sifchain-ETH-ETH.
If an external app on another chain decides to follow our convention of equating identical tokens like ETH-ETH and BSC-ETH, we will deem them to support Trusted Source Fungibility Groups as well. When tokens with the same underlying token but different trusted sources are exported from Sifchain to the external chain, they will be able to pool them together in an identical manner while similarly reaping the benefits of a unified asset pool. We believe that championing this standard across blockchains is a vital step towards consolidating assets on the ecosystem level.
Fungibility Group Drawbacks
We realize that implementing the concept of fungibility groups poses a few drawbacks to users:
Network custodian risk
If the origin network of a grouped token is compromised, it could threaten the viability of a pool as token holders, poolers and traders would not want to risk receiving an illiquid token. This is a very unlikely event for potential trusted sources like Binance Bridge or Gravity Bridge. Further, community governance will determine what is considered a trusted source and which token will be fungible with each other.
Induced fungibility costs on external chains
In our previous example, when a user exports their ETH (composed of BSC-ETH and Sifchain-ETH-ETH) to BSC, BSC could decide to treat them as different tokens (i.e. decide not to support Trusted Source Fungibility Groups). This poses some costs and inconvenience to the user if they want to ensure they only have BSC-ETH in their BSC wallet.
First, the user must swap their Sifchain-ETH-ETH for BSC-ETH on an exchange, let’s say Pancakeswap. If Pancakeswap does not have a Sifchain-ETH-ETH to BSC-ETH liquidity pool, they must send their Sifchain-ETH-ETH back to Sifchain and then send it to Ethereum (becoming ETH-ETH). The user must then use Binance’s BSC-Ethereum bridge to transfer his ETH-ETH onto BSC for BSC-ETH.
If Pancakeswap or other BSC exchange has an appropriate liquidity pool, the cost of inducing fungibility was the total cost of the swap. If not, the cost of inducing fungibility was the total transaction cost of importing the tokens from BSC to Sifchain, then exporting them from Sifchain to Ethereum, then transferring them from Ethereum to BSC. We can consider the latter case to be the worst scenario cost, meaning the costs the user would pay for any other case (like the former) cannot exceed this cost. The worst scenario cost is roughly constant with respect to the amount of tokens transferred (the cost for inducing fungibility for 1 ETH is roughly the same as the cost for inducing fungibility in 100 ETH).
We can therefore expect a secondary market mechanism to appear in which users (or swapping protocols focused on assets with similar underlyings like Curve on Ethereum or Ellipsis on BSC) facilitate the exchange of BSC-ETH for Sifchain-ETH-ETH at competing rates that will head towards 0. As such, the obligations we’re putting on users to achieve fungibility is negligible in the limit.
While these are real costs to the system, we feel that it is vital to the future of blockchain interoperability to solve the problem of liquidity fragmentation across blockchains. We understand that it will take a lot of user education, technical safeguards, and auditing to bring about token fungibility groups, but the need for consolidation of assets grows stronger with every new bridge, blockchain, and currency created in the crypto ecosystem. The potential to unlock the power of consolidated liquidity through fungibility groups is an opportunity that is worth the mitigable costs.
Final Thoughts
In short, we have a lot to build. The Omni-Chain future doesn’t get built in a day. We are working day and night to bring about a unified crypto ecosystem and we encourage you to join us. If you have blockchain skills (or are just an awesome backend engineer), reach out to us at: https://apply.workable.com/sifchain-finance . Otherwise, we still want to hear your feedback and where you think the future of Omni-Chain lives. Please feel free to submit new ideas/suggestions at https://sifchainpublic.ideas.aha.io/
