For the last several months, Ruby has been building an NFT-powered AMM, which is designed to leverage the benefits of the SKALE network and will soon launch on SKALE V2.
For Ruby, SKALE is far more than just a suitable network on which to deploy another DeFi service. It’s our home and the foundation of a new DeFi ecosystem. Ruby’s success will be closely tied to the success of SKALE, and many of the dApps that launch on SKALE will use Ruby. As the foremost AMM on SKALE and a key source of liquidity for the whole network, there will be symbiosis between Ruby and SKALE.
As well as developing Ruby, we have therefore also been working closely with the SKALE team to help refine their tech and identify priorities for the SKALEVERSE.
One of the key issues we’ve been discussing is around token bridging. In short, if there are multiple bridges from Ethereum mainnet to different SKALE chains, there can also be multiple and incompatible versions of every token migrated across those bridges. This means liquidity for popular tokens like USDC, USDT, BTC, and ETH can become fragmented, since a dApp that supports one version of a token will not support another version.
It is important to find a solution to this challenge before dApps begin to launch on SKALE in large numbers—at which point, it will become increasingly difficult and costly to address the problem.
The Europa proposal aims to establish consensus around bridging and token wrapping standards, ensuring clarity for every dApp and user on the SKALE network.
3 Likes
1/10 Europa: A Community-Run Liquidity Hub And Gateway To The SKALEVERSE
The SKALE V2 upgrade brings to reality a universe of connected blockchains, giving SKALE the capacity to grow to thousands of chains and enabling millions of transactions per second at no cost to users. This increased capacity adds tremendous value, but also brings new challenges to user experience and token mapping. These challenges can be mitigated if dealt with upfront in a thoughtful, strategic, and coordinated manner.
The Europa Initiative is a direct effort to ensure that token mapping is optimized from the start in a decentralized and community-driven way.
1 Like
2/10 TL;DR
SKALE V2 enables all SKALE Chains to bridge to one another and the Ethereum mainnet as independent chains. SKALE imposes no global token mapping across SKALE Chains, meaning that every bridge could potentially have its own token mapping standards and different wrappings of USDC, ETH, etc, cannot be used interchangeably. This can cause the creation of numerous versions of the same token, resulting in confusion and poor user experience.
To circumvent this issue, we propose the creation of a community-run SKALE Chain, which will host the default mainnet bridge and act as a gateway for tokens entering the SKALEVERSE. This will ensure bridging is uniform and will result in an optimized user experience across the network.
To maintain independence and decentralization, the chain will be managed by a group of major stakeholders from the SKALE community including validators, dApp developers, Foundation representatives, and ultimately a DAO. In pre-empting the problem of liquidity fragmentation, there is also an opportunity to invite initial stakeholders to create a Liquidity Hub, comprising a cluster of “public service” dApps on the same chain.
The ultimate and sole purpose of the Europa initiative is to drive the creation of a unified, interconnected Web3 ecosystem on SKALE V2 in a way that is effective, credibly neutral and open to participants who share the same vision. This requires striking a careful balance, ensuring close coordination but with all parties involved maintaining full independence and autonomy. There must be a commitment to transparent and genuine dialogue in good faith at all times, with the aim of serving the long-term collective good of the SKALEVERSE ahead of narrow, short-term individual interests. The Europa initiative does not intend to create a walled garden favoring the few but strives to diligently integrate all participants. As such, its governance should ultimately be placed in the hands of the community in a timely fashion. The alternative is a fragmented ecosystem in which competition is placed above collaboration, to the detriment of everyone.
1 Like
3/10 Background : Liquidity Fragmentation
SKALE’s architecture is designed to be open, powerful, and performant, giving developers all the tools they need to build trustless decentralized applications running on independent but interoperable chains.
While such flexibility is critical, there are cases where standardization and limited choice are necessary or desirable. One instance of this is token bridging and the problem of liquidity fragmentation.
In IMA/Skale v2.0 anyone can run a bridge between Ethereum mainnet and their dApp’s SKALE Chain, as well as directly between SKALE Chains. However, each bridge has its own token mapping standards. Tokens are locked on the bridge and a “wrapped” version of the token is minted on the other side.
The openness and decentralization of the SKALE network mean that the same L1 token will have different ids when migrated across different bridges, and these tokens will not be fungible.
For example, if USDC is migrated across two different bridges from mainnet, this will result in two separate wrapped tokens. While both are backed by L1 USDC locked in their respective bridges, they cannot be used interchangeably, and a dApp that supports USDC-A will not support USDC-B.
This problem is compounded when tokens are bridged between SKALE Chains, since they are wrapped on every bridge transfer. Migrating USDC-A to 10 different SKALE Chains will result in a further 10 different token ids. This fragmentation of liquidity and loss of fungibility—especially for key assets such as stablecoins, ETH, BTC, SKL, and so on—requires a solution before the launch of IMA v2.0, when dApps start deploying on v2.0 chains (at which point the wider SKALE network can and will evolve freely, and it will become difficult and costly to put the toothpaste back in the tube).
1 Like
4.1/10 Single Mainnet Bridge And Hub Chain
An effective solution to the problem is for migration of all key tokens from Ethereum mainnet to be concentrated to just one bridge, and therefore also into one chain. The SKALE Chain on which the bridge is hosted—provisionally titled “Europa”—will become the gateway to the wider SKALE network. Based on the SKALE v2 vision vision recently published by the SKALE team, as a critical Hub chain, Europa may have multiple dApps deployed on it.
This does not prevent other projects/SKALE Chains from launching their own bridges and providing the means to migrate tokens. However, establishing a community-managed chain onto which multiple liquidity-focused projects can reach consensus and clarity around the agreed version of each token that will be fungible between dApps, and therefore the route for each token into the SKALEVERSE, is vital for DeFi users, developers, and services like fiat gateway providers.
The same principle holds for other bridging services that link to the SKALE network: Each token should bridge to just one SKALE Chain.
While each blockchain token can be integrated with any SKALE Chain, so long as it is only one SKALE Chain, there are good reasons why the SKALEVERSE’s first bridges would ideally all be integrated with Europa. In the future, this initial Bridge/Hub model might be replicated throughout the SKALE ecosystem (see further below).
The Europa chain is also vital for transfers between SKALE Chains, since every bridging operation wraps the tokens and results in a unique token id. For example, transferring USDC from the Europa chain to dApp #1 and then to dApp #2 will result in one version of USDC, while a direct transfer from Europa to dApp #2 would result in a different version.
1 Like
4.2/10 Single Mainnet Bridge And Hub Chain
All “direct” transfers between SKALE Chains should therefore use the Europa chain as an intermediary hop, thereby unwrapping the token from the wrapper it received when transferred into its starting chain. For example, dApp #1 → dApp #2 would be routed dApp #1 → Europa → dApp #2.
In practice, much of the complexity can be abstracted away to ensure a user-friendly bridging experience. A community-provided bridging widget, which can be embedded into Europa-connected dApps, will make bridging compatibly-wrapped tokens from the Europa chain a straightforward process.
1 Like
5/10 Community-Governed Liquidity Hub
DeFi systems are built on the principle of decentralization, and the Ruby.Exchange team recognizes the importance of community ownership. To that end, we propose the creation of a shared dApp/service ecosystem Hub on Europa, which will also host a mainnet bridge, and which will be the default and logical route for liquidity to enter the SKALEVERSE upon the launch of SKALE v2.
Because the bridge and the chain on which it is hosted will be pieces of critical public infrastructure for the SKALE network, control should be distributed among multiple parties.
A key task for the Europa’s governance will be the simple but important process of approving or denying proposals for new tokens to be supported (whitelisted) by the bridge. Governance will also be able to add or remove key holders, to facilitate deployment of other or new dApps onto the chain, and to update the governance framework as required.
Distributed governance of the bridge necessarily also requires distributed ownership of the Europa SKALE Chain. This additionally gives all key holders the right to deploy dApps directly on Europa.
To make the most of this opportunity, we therefore also propose that the Europa SKALE Chain becomes home to a cluster of liquidity-focused dApps that it makes sense to be in direct connection with Ethereum mainnet, as a major source of migrating liquidity, and in close proximity to each other. As a community-run Liquidity Hub, Europa will essentially provide key public services for all SKALE users, and will become a staging post to the wider SKALEVERSE.
1 Like
6/10 From Multi-Sig To DAO
It is important that governance for the Hub reflects the needs of the community, but also remains agile.
We therefore propose a solution that evolves from multi-sig control to a system involving a DAO component, allowing the growing SKALE community to take a greater role in decision-making over time but without relying on slow and inefficient collective votes in the early days, when the community is still small.
- Stage 1 (April-September 2022): 3/5 multi-sig
- Stage 2 (October 2022-March 2023): 5/8 multi-sig
- Stage 3 (April 2023- ): 2/3 multi-sig, including 1/3 DAO
Stages 2 and 3 will require proposals to be submitted by the community, and for existing signatories to approve them and update the bridge contract. (The proposed dates are suggested as a starting point only, rather than being absolute deadlines.) Use of the SKALE forum is recommended to maintain a permanent record of all Europa proposals and discussion, and the SKALE Discord offers a venue for real-time discussion of proposals.
Phase 2 should also include tools to provide greater granularity for the controls that key holders have over the SKALE Chain. For example, while all stakeholders should have the ability to whitelist tokens for the bridge, non-dApp stakeholders would not need to deploy dApps.
1 Like
7/10 Founder dApps
Initially, the Hub will be controlled by five key holders, with contract upgrades implemented using three-of-five multi-sig. As soon as reasonably possible, this will be updated to five-of-eight. Soon after we hope to see this control be managed entirely by on-chain voting. This level of decentralization is in line with other major DeFi projects.
We would hope and expect that key SKALE projects would appreciate the opportunity to become key holders and host their dApps on Europa, since:
-
It helps position them as leaders within their sector and within the SKALE ecosystem.
-
They will enjoy the benefits of close integration with other major dApps and services.
-
It minimizes the potential for these key dApps to encounter incompatible tokens (e.g. the USDC-A and USDC-B examples above).
Most dApps will, in any case, need to access a mainnet bridge and address the problem of liquidity fragmentation. They will typically do this by bridging to the Europa chain, if not by deploying directly on it.
Europa founders would ideally include a mixture of dApps and other services, such as bridges and fiat integrations, as well as large SKALE holders/validators. Potential key holders might include:
1 Like
8/10 Europa DAO Governance Token
In the final phase, the Europa DAO would hold a large part of the responsibility for contract updates, with other signatories only required to confirm any decisions, or to enable fast response in the event of a security threat.
There are various options for a DAO governance token, including:
-
Dedicated Europa Hub (EUROPA) token
-
Existing SKL tokens, or a proxy on SKALE network itself
-
RUBY tokens or another Europa stakeholder token
Of these options, we suggest creating a dedicated EUROPA token. Using an existing token like RUBY compromises Europa’s independence, and does not fairly reflect the shared nature of the Europa SKALE Chain. And, while SKALE holders have a vested interest in seeing the SKALEVERSE succeed, their chief task is securing the SKALE network as a whole, and requiring them to take specific actions to manage just one SKALE Chain imposes an unnecessary governance burden on them, without aligning incentives well.
A better option is to airdrop EUROPA tokens to a large number of Hub users, who will have an interest in maintaining and shaping the future of the bridge and Europa SKALE Chain, including the services it hosts. Tokens might be airdropped to users who have bridged funds from Ethereum mainnet since the hub launched, since most or all value in the SKALEVERSE will originate from mainnet. Additional tranches of tokens might be granted to initial founder members/multi-sig key holders, to distribute to their users as they see fit. A further token reserve can be retained in case future hub dApps mint value directly on-chain. This suggestion is, like other major decisions, open for discussion within the SKALE community.
1 Like
9/10 A Blueprint For The SKALEVERSE
The model of a cluster of dApps hosted on the same “Hub” chain is designed to help partners integrate efficiently to provide their services to dApps within the network. As suggested on SKALE’s blog, there could be “a few primary Decentralized Exchange Hubs in the network and a few primary NFT Marketplace hubs. This enables partners to focus their integration efforts on a handful of chains rather than needing to provide support across the entire universe of chains.”
Europa will be the first SKALE Hub chain, and the process of launching it will provide insights to future hubs that wish to replicate this approach across the SKALEVERSE.
1 Like
10/10 The Role Of Ruby.Exchange
Ruby.Exchange has several roles to play in the Europa and wider SKALE ecosystems:
-
Proposal and development. As one of the parties leading the creation of Europa, Ruby’s team will help refine the initial proposal, present it to the community, develop the smart contracts required to manage the SKALE Chain, and communicate with potential stakeholders.
-
Key holder. Ruby’s team also offers to be one of the five initial key holders for the Europa SKALE Chain.
-
Community member. Ruby intends to be an active community member and advocate for governance decisions that benefit the wider SKALE ecosystem.
-
Listing EUROPA tokens. Ruby.Exchange will be the first and default venue for trading EUROPA governance tokens.
-
Whitelisting for liquidity pools. All tokens approved by Europa (i.e. that are whitelisted for the Bridge) will automatically be whitelisted for Ruby.Exchange, enabling anyone to create new liquidity pools for these assets without further approval.
1 Like
Of every major exploit I have seen on platforms trying to do this, the keyholders are the most vulnerable and having a majority of them would give a malicious actor a lot of control. Is there a way we can think of safe guarding against this?
An idea that comes to mind is having the swap platform as an ‘official’ S-Chain, with core team involvement at the highest level (contract upgrades) but building and managing the platform delegated to those with ‘proof-of-intent’, a look at what that applicant thinks about the state and future of the network, what they will do as a governing body to push towards those goals, and what ways they will be utilizing skale for their applications. These applications could be viewed and voted on by the already decentralized network of validators and would allow integrated members of the community to have a voice on the matter, without worrying about another token to hold.
TLDR; Applicants could go through the validator network to be allowed development access to Europa, but on-chain upgrades happen with core and delegate approval.
There could be a lot of flaws to this, feel free to tell me how wrong or what can be improved about this for a better solution, thanks.
3 Likes
Hi imdev.eth, thanks for your feedback!
I’m not sure I understand your suggestion fully but I think there are a few things we can say at this point:
Firstly, we hear you on the multi-sig issue (the Axie/Ronin exploit being the most recent and largest example). Our view is that multi-sig is very safe when used correctly, i.e. when keys are not held by the same people or stored in the same place, as was the case with Sky Mavis last month or Bitfinex back in 2016. We’re suggesting (initially) five completely separate key holders, including major dApps and SKL holders/validators - so from the start, there’s no centralized control. That will be increased to eight, and then finally the DAO will assume control.
Secondly, while we’re also exploring how to give different roles to different parties on the shared Europa chain, the granularity of control to assign different roles does not yet exist (6/10). That’s something that will need to be built along the way and we need something that works now, before dApps deploy on the network.
Lastly, there’s definitely something to be said for avoiding a new governance token and going with the existing network of SKALE validators. The reason we suggested creating a separate DAO is because we felt it would add a burden to validators that is outside their core mandate of securing the network, without giving them adequate incentives to do so, potentially leading to lack of participation (8/10).
Hope that’s of some help.
2 Likes
We’re pleased to be able to announce that the Europa Liquidity Hub is going ahead, with support from the following organizations:
These five SKALE dApps, services, and staking/validator partners will share multi-sig control over the Europa chain, providing a vital mainnet bridge and common token standard for migrating liquidity. We’re very excited and encouraged at the interest shown by major SKALE organizations as network rollout continues and V2 becomes a reality!
