Skip to content

Instantly share code, notes, and snippets.

@christroutner
Last active January 3, 2023 21:24
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save christroutner/1e6d8605ae98034fa6992297a5f207af to your computer and use it in GitHub Desktop.
Save christroutner/1e6d8605ae98034fa6992297a5f207af to your computer and use it in GitHub Desktop.
Cross Chain Stablecoin Bridge

Cross-Chain Stablecoin Bridge

Overview

This document sketches-out the construction and operation for a 'token bridge' with the ability to move a stablecoin (or other token) between two blockchains. This would allow the best stablecoins across all chains to be offered on chains with less capability.

The bridge described in this document is 'custodial' in the sense that is in sole possession of the funds for a few minutes, before it transfers the value between chains. However, it is 'trust-minimized' in the sense that every function of the bridge results in on-chain transactions that can be audited and verified by anyone in the world. Beyond the technical considerations, operating this bridge under the control of a business registered in a crypto-friendly jurisdiction would benefit the deployment and long-term operation of the bridge.

Architecture

The diagram below shows the canonical workflow for transferring a stablecoin between the AVAX and BCH chains. Any two blockchains can be used that support tokens, AVAX and BCH are just used here as examples. Likewise, YUSD is used as an example token, but any token from a Source Chain can be transferred to the Deployment Chain in this manner.

image

The canonical workflow follows the arrows in the diagram above:

  1. The users interacts with a web app, to designate the quantity of the token to move across the bridge and the address on the Deployment Chain where the synthetic version of the token should appear.
  2. The web app provides an address on the Source Chain for the user to send their tokens to.
  3. The user sends their tokens to the address provided by the web app.
  4. The web app moves the tokens to its token inventory on the Source Chain.
  5. The web app sends the same quantity of synthetic tokens from its inventory on the Deployment Chain to the address specified by the user in step 1.

The process above is reversible, allowing users to move tokens in both directions across the bridge. The primary role of the bridge app is to balance its inventory on both wallets. Since all activity is on-chain, the accounting of the token inventory and the one-to-one backing of synthetic tokens can be audited by anyone at any time.

The implementation of this bridge app only requires basic wallet functionality and automation, which is available on all blockchains. No smart contracts are used, which reduces complexity and risk. The only requirement is that the wallet on each chain have the ability to detect tokens when they are received.

Since stablecoins are used on both side of the bridge, there is no risk of impermant loss or price fluctuation. One token always equal one token, on both sides of the bridge. In the example, YUSD is used. This stablecoin was chosen because it is overcollateralized, permissionless, unfreezable, audited, and liquid. But any token can be applied to this architecture.

Legal Considerations

I am not a lawyer and have no expertise is choosing a jurisdiction for the company operating this wallet. Howeer, I am pretty sure that operation of this app would be consider a Money Service Provide (MSP) and it would be considered regulated activity. However, the USA is one of the only jurisdictions in the world that make this distinction. Most juridictions in the world do not.

Since the app is simply reacting to on-chain events, there is no concept of a 'customer' and no ability to perform KYC (know your customer). There is also no way to detect or react to users from different juridictions. Because this app is built on the blockchain, it inherits its advantages and disadvantages. Namely, the app only interacts with addresses and transactions, which do not code for geographical location or nationality.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment