Decentralised Multi-Chain Asset Bridging Architecture

Moving assets seamlessly across many chains

Ł.club

May, Oct 2021

Abstract

We propose a new way to link wallets (addresses) between any address-based blockchain using NFTs minted on the Ethereum network. Multi-chain linked addresses can be used by third parties to seamlessly facilitate cross-chain asset transfers. We propose a decentralised network architecture for the bridging facilitators ensuring maximum security and stability for the users moving their assets. We propose a new Decentralised Autonomous Club (DAC) overseeing this bridging network. Additionally, we explore best ways to incentivise network operators, secure network users, and bootstrap network liquidity.

Content







1. Introduction

There has been a spectacular growth of blockchain alternatives to Ethereum, like Avax, BSC, Dot, Fantom, Polygon, Solana or Stacks, to name a few. The amount of assets on these networks is growing rapidly. At the same time, classic single-token networks, like LTC, BTC, XRP or DOGE, still hold billions of dollars of value.

This situation creates a dilemma for users: in order to fully utilise opportunities across many chains and networks, users' capital has to be spread thin across Layer 1 chains or Layer 2 solutions, and capital movement is often limited by the capacity and limitations of existing bridges. To embrace the multi-chain activity, users' have to take the additional risk of using centralised bridges, often more than one.

We propose a new way to solve this issue using generative NFTs in a decentralised, standardised bridging network operated and governed by both its facilitators and users. We want to make asset transfers across any chain seamless, cheap and fast.







2. Address-based Blockchains

Not every blockchain is address-based. However, most of them are. But even then there is a distinction between a fixed-address blockchain like Ethereum and a fluid-address blockchain like Bitcoin. The difference is more of an user interface issue than a technical issue, but it's worth noting nonetheless.

In an Ethereum-like blockchain, user's address is fixed right from the start of wallet creation. Whether the user has made 1 transaction or 100, the address they used to do it never changes.

In a Bitcoin-like blockchain that's not always the case. Depending on the wallet application design, we often see that, for example, for every deposit, a next address in the list of available wallet addresses is used. Similarly, the user often has an easy option to pick one of their addresses to send from.

The latter design requires users to be extra careful when linking their address using NFTs, as the data defined within the NFT won't change with every transfer as they are used to.







3. Linking Addresses using NFTs

The idea behind linking address using NFTs is simple yet effective: considering Ethereum blockchain as the core of the Ł.club bridging network, we enable minting of NFTs that embed addresses from other blockchains. The embedded addresses can be of two types.

Type 1: End-user Address. Say User A owns an Ethereum wallet with an address of 0x123..456, and a Litecoin wallet with an address ABC..DEF. To link these addresses, User A uses Ł.club bridge contracts on the Ethereum mainnet to mint an NFT that: embeds the string "ABC..DEF", displays a QR code of "ABC..DEF" and displays the Litecoin logotype. We now understand that User A, the owner of address 0x123..456 on the Ethereum blockchain, also owns the address ABC..DEF on the Litecoin blockchain.

Type 2: Deposit Address. Say User A owns an Ethereum wallet with an address of 0x123..456, and wants to receive wrapped LTC (WLTC) to that address. To enable this, User A uses Ł.club bridge contracts on the Ethereum mainnet to mint an NFT that: embeds the string representing a Litecoin wallet address "ABC..XYZ" from the collection of Ł.club addresses used for deposits, displays that address QR code, the Litecoin logotype, the Ł.club logo and the watermark "Deposit". We now understand that User A, the owner of address 0x123..456 on the Ethereum blockchain, wants all the LTC that are deposited to address ABC..XYZ on the Litecoin blockchain to be forwarded as WLTC to address 0x123..456.

We suspect the Type 1 NFT to be more popular than the Type 2 NFT, as the latter one only supports one-direction transfers. Additionally, Type 1 NFTs can be minted at no additional cost than gas. Type 2 NFTs, as generated from a limited set of available deposit addresses, should have a base cost to prevent spamming.

Both types of NFTs should have attractive generative artworks. Type 1 NFTs should have a limit on the amount of NFTs with artworks (for example, first 10,000 per blockchain/asset). Type 2 NFTs could all have artworks, possibly linked to the entities that mint them.

Both types of NFTs are reusable in the sense that they are not strictly connected to a specific Ethereum address. The link relies on the fact that a given Ethereum address is hodling the NFT. Thus, if User A wants to migrate from address 0x123..456 to say 0x654..321, but retain the links to Litecoin addresses ABC..DEF or ABC..XYZ, all is needed is to transfer the NFTs from 0x123..456 to 0x654..321.







4. Single Bridge Architecture

A single bridge architecture consists of addresses on different blockchains and an off-chain software controlling the asset flows. All transactions are stored on-chain on respective blockchains. Any cross-chain asset transaction can be verified by pairing the two transfers from the two blockchains involved in said transaction.

If a deposit transaction occurred on blockchain A, but the corresponding transfer didn't occur on blockchain B, this is grounds to rising an issue. Similarly, if a transfer occurred on blockchain B, but there is no corresponding deposit on blockchain A, this is grounds to rise an issue.

Issues can be trustlessly resolved with on-chain data thanks to the NFT linking on user's Ethereum address. This means the NFTs are at the core of the security of the Ł.club bridging network. Moreover, the network's insurance mechanism helps mitigate actions by rogue bridge operators (more in section 8.)

There are three types of asset transfers that a single bridge should handle:

Wrapping using Type 1 NFT to Ethereum:
When User A sends their asset X from blockchain A to Ethereum, the process is as follows:

  1. User A sends asset X on blockchain A from their address ABC..DEF to the public, global Bridge deposit address GHI..JKL
  2. The Bridge searches Ethereum blockchain for the owner of the NFT with ABC..DEF address embedded in it and finds User's A Ethereum address 0x123..456
  3. The Bridge mints wrapped X asset and sends it from the smart contract to 0x123..456

Unwrapping using Type 1 NFT from Ethereum:
When User A sends their asset X from Ethereum back to blockchain A, the process is as follows:

  1. User A sends wrapped X asset on Ethereum from their address 0x123..456 to the public Bridge smart contract
  2. The Bridge checks the address 0x123..456 for the NFT for the asset X and finds its embedded address ABC..DEF
  3. The Bridge burns wrapped X asset on Ethereum and sends native X asset to ABC..DEF on blockchain A

Note: To move assets across chains other than Ethereum these operations can be daisy-chained as long as every blockchain on the way, except the first, supports smart contracts and custom tokens. To move assets across non-smart blockchains, the Bridge can facilitate cross-asset swaps.

Wrapping using Type 2 NFT to Ethereum:
When User A sends their asset X from blockchain A to Ethereum, the process is as follows:

  1. User A sends asset X on blockchain A from any address to their dedicated Bridge deposit address GHI..JKL
  2. The Bridge searches Ethereum blockchain for the NFT with GHI..JKL address embedded in it and finds User's A Ethereum address 0x123..456
  3. The Bridge mints wrapped X asset and sends it from the smart contract to 0x123..456

Note: This type of asset transfer seems to be well suited for DeFi applications wanting to bring on assets from other chains.







5. Decentralised Bridging Network Architecture

A collection of single bridges, ideally operated by mutually exclusive parties, creates the network. Each bridge can have custom fees, perks and limitations. However, they all support the standardised wrapped assets.

The process of onboarding new bridges is described in section 6.

Upon onboarding, the DAC-controlled Ethereum smart contracts add the new bridge to the allow list enabling minting of wrapped assets in exchange for the deposit of the insurance (explained in section 8.)

Each bridge operator can set custom transfer fees or incentives and limitations on the transferred amounts. Each new operator strengthens the network while creating a fair market competition to improve the end-user service of the network.

The end goal is to build a network with an Internet-like topology, able to survive the disabling of many nodes while still being able to service its users and wrapped assets.







6. Decentralised Autonomous Club

Existing Decentralised Autonomous Organisations (DAO), as it recently started to turn out, are susceptible to bribery, because they are mostly based on the voting power represented by the amount of owned DAO tokens. Even with quadratic voting, these organisations can be dominated by a wealthy actor, or another DAO that is able to convince/incentivise voting token holders to stake their votes with said DAO (like CVX with CRV).

We propose a new kind of organisation: the Decentralised Autonomous Club (DAC). Just like a club, it relies on the principle that existing members should invite and approve new members. And just like a club, becoming the founding member has its advantages over the members that join later on, yet all of the members have fairly similar status once joined.

Ł.club DAC will rely on the native LCL token and have the following roadmap reflecting the DAC principles:

  1. Ł.club begins with 1 member, the creator.
  2. Ł.club executes a liquidity generation event (LGE) by putting on sale the 1% of all LCL tokens to interested parties at a fixed price.
  3. LGE participants are added to the DAC whitelist, and Ł.club offers these LCL holders an option to stake & lock for a minimum of 30 days a minimum token amount (at least 84,000 LCL) to receive an equal amount of voting tokens (vLCL) and become the founding members of the Ł.club DAC.
  4. Before the first DEX launch, the ability to stake LCL for vLCL is frozen by the Ł.club DAC and no new founding members can ever exist.
  5. New members can join by being put forward by the existing members or by making a request on their own, but all new members have to be approved through a vote by the existing members, and if approved all new members have to stake the minimum token amount to receive their voting tokens: new members are added to the DAC whitelist and the ability to stake & lock LCL for vLCL is unfrozen for 3 days for the club members to increase or decrease their voting power, however any member's stake decreasing below the minimum token amount effectively removes that member from the club.

Ł.club DAC members perform the following roles:







7. Network Operators' Incentives

The crucial element behind the bridging network we propose is diversity of bridge operators. We see a parallel to email service providers: the underlying protocol and communication stack is standardised and interoperable. The core software is standardised. But the top layer of implementation is customised to the liking of the service provider.

As such, network operators (and the public) will have access to our open source protocol design and software stack to operate the bridge. They will be able to change operating parameters like transfer fees, confirmation requirements, amount limits etc.

Our open source stack will be licensed under a permissive license allowing modifications. We hope to build a vibrant development community around the bridging network to accelerate its expansion even more.

Finally, operators by design are part of the Ł.club DAC and therefore shape the future of the bridging network.







8. Network Users' Security

There are two issues that may arise during the operation of the bridge: loss of the deposited native asset (due to a malicious bridge operator) or loss of an asset during the transfer (due to an error in the blockchains).


Solving the issue of malicious bridge operators

Every bridge operator has to stake LCL to join the network. LCL can be purchased with ETH from the Ł.CLUB or on the open market.

The value of the staked LCL must exceed the value of the wrapped asset that the bridge has issued. In case the bridge native asset tokens are lost, the insurance in LCL backed by ETH will compensate that incident.

Additionally, when the bridging network grows sufficiently, user's have a choice of claiming the insurance or unwrapping the assets using a different bridge.


Solving the issue of errors in the blockchains

We propose to follow the policy of "What goes in, must come out".

Each bridge operation consists of an asset going into the bridge and another going out. Either it is a native asset going in and a wrapped asset going out, or the opposite. For any given two blockchains, this is always the case. Even with transfers between many chains (daisy-chained hopping), each atomic transfer only occurs between any given two blockchains.

Therefore, we propose a mechanism to identify where the issue occurs, and then a system to audit the problematic transfer from blockchain A to blockchain B:

  1. User wants to transfers a native asset from blockchain A into a wrapped asset on blockchain B
  2. User deposits native asset on blockchain A into a deposit address of bridge Z: this becomes a fact once the transaction has X confirmations and is stored in the ledger of blockchain A
  3. If the above transaction has less than X confirmations, in the eyes of bridge Z it did not yet happen, thus nothing can come out on blockchain B yet: any issue raised by the user at this point is discarded
  4. If the above transaction has equal or more than X confirmations, the bridge Z should execute a transfer of the wrapped asset to user's address on blockchain B: any issue raised by the user at this point is investigated

Depending on the blockchain, the value X of required confirmations may differ. Additionally, bridge operators can take on more or less risk by adjusting this parameter to offer faster or slower transfers.







9. Network Liquidity


We plan to build up the network liquidity mainly through a liquidity mining program. 840,000,000 LCL, or 10% of the total supply, is reserved for this program. However, we mostly want to incentivise long-term liquidity and not the quick actors that farm empty pools on launch. Therefore, we propose the idea of the exponential Liquidity Mining (eLM).

In essence, the farming rate (in other words APR) grows with time as long as you provide liquidity. It starts very low, growing steadily and at the end of the program grows rapidly (exponentially). In this context, not only the amount of assets you stake matters, but crucially the amount of time you keep on staking without interruptions.

By being committed to the program long-term, low & mid tier liquidity providers can earn as much as high tier short-term providers ("whales").

This approach also solves the problem of bots arriving with large positions in the first blocks of the freshly opened farming pools to claim a lion's share of the rewards early on.

Another advantage is mitigating the issue of early sell pressure towards the reward token when the liquidity is still building up.







10. Conclusions

Combining a simple concept, open source software and network effects, Ł.club wants to build a cheap, fast and accessible cross-chain asset transfers protocol. By distributing the control to early backers from day one, Ł.club wants to become a true DAO.

The project is fully-functional using just a single node, and with every new node becomes more and more secure and decentralised.

By aligning the tokenomic incentives of users and bridge operators, and distributing a large portion of the token supply to protocol's liquidity supporters, we hope to achieve an equilibrium both in terms of price and volume.

Finally, we hope to bring a much needed utility to the NFT space. We believe generative art NFTs can combine attractive artwork with digital data storage. Moreover, we envision limited run series NFTs by talented artists as a special incentive for the users to participate in the protocol and for the bridge operators to promote their services.

The future hodls assets across all chains, seamlessly.

Welcome to Ł.club