DefiLlama's Llama Swap | Avalanche Subnet Messaging | zkBob and Vesta Finance Integrate LI.FI's Widget & More!
Last Week In The Multi-Chain Ecosystem (2-8 Jan '23)
Welcome to LI.FI’s Cross Chain Insider newsletter. If you want to join this community of cross-chain aficionados learning about bridges, interoperability, and the multi-chain ecosystem, subscribe below:
You can also check out LI.FI’s research articles, and follow us on Twitter!
1) Connext’s 2022 Recap and Plans for 2023 🧐
As Connext builds towards becoming ‘a ubiquitous public good that truly enables a safe, open, composable Web3’, the team released a blog recapping 2022 and stating plans for 2023.
According to the team, 2022 will be remembered as the “heads down and build” period, while 2023 will be the year of the next wave for Connext. Read more here.
2) zkBob Integrates LI.FI’s Widget 🚀
zkBob, a stablecoin-based privacy solution, has integrated LI.FI’s widget inside their dApp! zkBob users now have access to cross-chain bridging and swapping directly in the dApp across 15+ EVM-compatible networks in just a few clicks.
3) Multiple Bridging Protocols Listed on Mises Browser 🔥
Mises Browser, an extension-supported mobile Web3 browser, has listed multiple bridging protocols on its interface. Listed protocols include bridges like Synapse, Multichain, and aggregators like LI.FI, XY Finance
4) LI.FI 2022 Update 🦎
LI.FI has released a blog recapping 2022, highlighting key events in the protocol’s journey. Read more here.
5) Vesta Finance Integrates LI.FI’s Widget 💪🏻
Vesta Finance, a layer-2 stablecoin protocol, has integrated the LI.FI widget inside Vesta! Users can now easily bridge and swap assets across 15+ EVM-compatible chains, all without ever having to leave the dApp.
Multi-Chain Ecosystem Updates
1) DefiLlama Launches Meta DEX Aggregator 🔥
DefiLlama has launched Llama Swap, a meta DEX aggregator offering the best price from 8 aggregators and supporting swaps across 22 chains.
2) Subnet-to-Subnet Messaging is Now Live on Avalanche 🔺
Avalanche released the “Banff 5″ software upgrade to introduce Avalanche Warp Messaging (AWM). The upgrade will enable messaging between Avalanche subnets without relying on any bridges.
3) Fantom’s dApp Gas Monetization Vote Passed 🧐
The proposal to enable Gas Monetization for dApps has been passed by Fantom governance. This will reduce the burn rate from 20% to 5% and redirect the 15% to incentivize the usage of dApps on Fantom. As a result, it will optimize demand for block space and reward quality dApps on Fantom.
Trade Joe has announced its plans to expand to BNB Chain. The team plans to deploy Joepegs NFT Marketplace and Trader Joe DEX on BNB Chain by the end of March, making Trader Joe a true multi-chain platform available on Avalanche, Arbitrum, and BNB Chain.
5) OpenSea Now Supports Arbitrum Nova 💙
OpenSea continues its expansion on multiple chains, with Arbitrum Nova, Arbitrum’s dedicated chain for social and gaming, being the most recent one. Nova collections will still be grouped with other Arbitrum collections on the rankings and search pages under the “Arbitrum” chain filter.
What’s Popping on Twitter?
In Crypto, it’s essential and healthy for the ecosystem to debate critical topics related to security and protocol development. This week, L2BEAT’s research team kick-started a heated discussion on isolated security and how it can be misused by dApp developers by taking LayerZero’s architecture as an example.
The topic of the Debate: shared security models of cross-chain applications (shared security vs. per-application security).
Let's look at this from both L2BEAT’s and LayerZero’s perspectives and try to conclude:
L2BEAT’s Argument: Shared security > Isolated security
According to L2BEAT, the isolated security model creates more problems than it solves. By enabling each app to define its unique security policies, we’re expanding the attack surface given:
dApp developers can adopt sub-par security policies that expose users to exploits.
dApp developers can change the security model anytime and rug the users.
It becomes the users' responsibility to ensure either 1) the dApp conforms to the security parameters set by the underlying layer (in this case, LayerZero), and if it doesn’t, then 2) access the security of the dApp given its unique security policies.
Thus, L2BEAT believes that every dApp using isolated security should be considered “risky by default until proven otherwise.” In this case, the argument is specific to dApps built on LayerZero, suggesting that all dApps built on LayerZero (like Stargate) should be considered risky since the developers behind these dApps can freely change the security model and potentially rug users.
L2BEAT also conducts a comprehensive experiment to prove that such a scenario is, in fact, possible for dApps built on LayerZero.
LayerZero’s Counter-Argument: We don’t want to pick a side; we offer both, let the devs decide.
As it should be, LayerZero had their own opinion on this discussion, shared via a thread and Bryan’s responses to questions on numerous threads. LayerZero doesn’t deny that such a scenario is possible for dApps built on top of LayerZero; however, the way they think about having standards when it comes to setting security parameters is different:
Like the internet can be used for building websites, Ethereum can be used to build smart contract applications, LayerZero is just an enabler to build cross-chain applications. Along the same lines, just like people can build malicious websites on the internet and malicious applications on Ethereum, it is possible for someone to build a malicious cross-chain application on LayerZero.
Being an infrastructure protocol, LayerZero makes it possible for devs to create applications with any type of security parameters and wants to stay completely unopinionated on application security configurations.
Shared security mechanism in a cross-chain ecosystem can potentially be attractive honey pots for attackers (as we’ve seen with >$2 lost in bridge hacks in 2022).
Thus, LayerZero believes that instead of choosing between shared vs. isolated security mechanism, it’s better to offer flexibility in terms of being able to set security parameters is vital for dApps as different use cases have different requirements. For instance, a money market dealing in 8-9 figure liquidations prices security differently than an NFT project dealing in $0.10 NFTs, and thus would require different security parameters that fit their requirements.
What Does Twitter Say?
Twitter, as always, has a voice of its own, and often the consensus on Twitter (sometimes wrongly) is taken as the final decision for a debate. For this argument, Twitter is heavily favored towards a shared security model. Even then, let's look at some of the different perspectives on Twitter:
Camp 1: say no to isolated security — Letting dApp developers determine security parameters can be irresponsible as most devs don’t want to be involved in this decision and simply want to build on top of a secure and robust infrastructure. Rollups are a good example of a shared security model where everyone that’s building a Rollup or on it embraces the shared security of Ethereum as the L1.
Camp 2: isolated security is useful — However, the counter-argument to this sentiment is offered in the form of app chains where certain like dydx teams prefer having control over all the parameters, and the users have to do their own due diligence.
Camp 3: apps with isolated security can be risky, but for some use cases, an isolated security mechanism might make sense — It’s essential to recognize the risks of an isolated security model and use dApps that have adopted it with caution. However, there’s a world where application or use-case specific might benefit more by adopting an isolated security model than shared security.
Is there a conclusion?
The debate boils down to whether an industry-wide standard on application security configurations should exist. Right now, there’s no right or wrong answer to this question, and we hope that the discussion between L2BEAT and LayerZero can bring us closer to a solution.
A possible consideration to meet somewhere in the middle of this debate could be to establish a process to verify relayer and oracle combinations being used by different dApps built on LayerZero. This would work similarly to how source code verification currently works on explorers like Etherscan. It would allow users to check if a dApp is using the default relayer/oracle combination advised by LayerZero (considered secure) or if it is using a unique combination. While this doesn’t completely solve the problem, as the users will still need to manually check from time to time if the combination is verified. However, it does offer some resolve in the form of a guarantee that the current combination is safe to use.
Moreover, as suggested by many others and Bryan himself, it’s crucial that LayerZero updates its website and marketing material, like the white paper, to reflect these issues in order to better inform the users about the risks of using LayerZero or any dApp built on it.
We appreciate and applaud the work done by the L2BEAT team. It’s important to have difficult discussions on critical topics such as this one, and L2BEAT has done a commendable job with its research work. Additionally, we must recognize and appreciate LayerZero’s positive response to this debate and an openness to listen to criticism and other design ideas.
1) Horatius At The Bridge
2) Exploring Hyperlane Use Cases
Thanks for reading LI.FI - The Cross-Chain Insider Newsletter! Subscribe for free to receive new posts and support my work.
Get Started with LI.FI Today
To learn more about us,
Head to our link portal at Link3.to/lifi
Read our SDK ‘quick start’ at docs.li.fi
Join the official Discord server
Follow our Telegram Newsletter
or try our any-2-any swaps NOW at transferto.xyz