The Confluence Bridge

The Confluence Bridge connects Fractal Confluence (the EVM layer) to Fractal Spring (the UTXO layer). It enables the transfer of FRC20, FRC721, and FRC1155 between the two chains.

The first two layers in Fracrtal's multi-chain ecosystem are

• Fractal Spring - a UTXO-based blockchain layer with native ZK

• Fractal Confluence - an accounts-based blockchain layer that connects Fractal to CEXs and EVM ecosystems.

The Confluence Bridge lets users transfer assets from the UTXO layer (addresses that follow the fra... format) to the EVM layer (addresses that follow the 0x... format) of Fractal.

NOTE: When purchasing FRA on a CEX, be sure to check which network you are using. If you are purchasing EVM-FRA (most CEXs only offer EVM FRA) make sure to use an 0x... address on Fractal Confluence.

Essentially, the Confluence Bridge is an internal bridge between the two networks.

Users can initiate a transfer on Confluence Bridge via the Fractal wallet. Developers can integrate the Confluence Bridge into their applications via the SDK.

Differences between the UTXO and Account Model​

• A UTXO model stores its assets as a set of unspent transaction outputs whereas the account model stores a set of addresses with their associated balances.

• UTXO transactions specify the resulting state but in an account-based model the resulting state is dependent on the previous one.

• The account model simplifies UI/UX implementations in terms of displaying balances for specific addresses where it is a bit more complex to display this information from a UTXO-based system. Since most users are familiar with accounts and balances, this needs to be generated by summing up the UTXOs of given addresses.

• With a UTXO-based system, the smart contracting abilities are limited. This is because of the nature of the conditions set within the UTXO for spending. This can require signatures that can be difficult to produce.

• When executing transactions in an account-based system, each transaction must be processed serially when dealing with the same address. The UTXO model can however process its transactions in parallel since it is impossible for two transactions to affect the same UTXO.

• There is a precaution that must be made for account-based systems to ensure previously signed transactions are not replayed on the network. This is usually in the form of an incrementing nonce that ensures uniqueness. For UTXO-based systems, this is not an issue since every UTXO gets consumed and can't be spent again.

Hybrid UTXO Model​

The hybrid model implemented by Fractal allows users to store assets in the form of a UTXO or balance. It is able to do this by using separate storage methods while combining their hashes to maintain integrity within the network.

There are two main transactions that a user can broadcast in order to translate the asset types from one to the other:

1. Transfer UTXO assets to account balance

   • The transaction is built with a Transfer and Convert operation

   • The UTXO is burnt by transferring to a burn address

   • Assets are minted for the owner address specified in the transaction

2. Transfer to UTXO assets from account balance

   • Assets are burnt from the specified address by subtracting the balance

   • Minting operations are queued to be processed by the chain

   • The Ledger mints UTXOs based on the amounts specified

   • Once Assets can be transferred between the different models, the system can take advantage of the capabilities provided by both Accounts and UTXO models.

A hybrid model can overcome some of the disadvantages experienced by one model. For example:

• The account-based model supports EVM-compatible smart contracts.

• The UTXO model can prevent replay attacks.

• The UTXO model supports confidential and anonymous transfers

Fractal EVM FRA vs Fraactal UTXO FRA​

On the Fractal Spring chain, the tokens are called FRA-native tokens and are used to stake tokens to guarantee network security, pay transaction fees, and vote on Fractal Improvement Proposals.

On Fractal Confluence, the EVM layer, the tokens are called FRA-smart tokens and are used to pay transaction fees and interact with Dapps built on the Fractal EVM. You can tell which type of FRA you are using by the nature of the wallet address that holds it. Fractal Spring addresses use the fra... format and Fractal confluence (EVM FRA) uses wallets with the 0x...format.

A key innovation is that UTXO-based tokens on Fractal Spring can be used on Fractal confluence without being wrapped. Because UTXO-FRA follows the FRC20 token standard, they simply need to be atomically transferred via the Confluence bridge, and no wrapping is necessary.

Confluence Bridge Transfers

Prism for FRA-native and FRA-smart​

With Prism, users can atomically and trustlessly convert their FRA-native tokens on the native chain to FRA-smart tokens on the smart chain. Below are the workflows of how Prism transfer works for FRA.

Case 1: Smart Chain -> Native Chain​ (FRA)

• User/contract calls depositFRA on PrismXXBridge.

• PrismXXBridge internally burns/locks the tokens and builds a mint operation to store on contract.

• At the block end, each mint operation will be consumed.

• For each mint operation, the coinbase mints the equivalent ASSET on native chain.

Case 2: Native Chain -> Smart Chain​ (FRA)

• Users build ConvertAccount operation and transfer some amount of FRA to BlackHole. (Note: user can also send data in EVM ABI format to call the smart contract on EVM side )

• Blockchain calls withdrawFRA function in PrismXXBridge

• PrismXXBridge internally mints/releases equivalent assets to the target EVM address.

Prism++ for FRC20/FRC721/FRC1155​ tokens

Apart from FRA, Prism supports all tokens coming from FRC20/FRC721/FRC1155 family. For every deployed FRC20/FRC721/FRC1155 asset in smart chain, Prism will automatically create a mapped UTXO-based asset in the native chain, meaning whitelisting is done by Prism in a decentralized way. Similar to FRA Prism transfer, users can easily convert FRC20/FRC721/FRC1155 token to mapped UTXO token in native chain and vice versa. Below are the workflows of how Prism transfer works for FRC20/FRC721/FRC1155.

Case 1: Smart Chain -> Native Chain​ (FRC20/FRC721/FRC1155)

• User/contract approves PrismXXBridge some amount of FRC20 tokens.

• User/contract calls depositAsset on PrismXXBridge.

• PrismXXBridge internally maps FRC20/FRC721/FRC1155 asset (EVM) to a native ASSET (UTXO).

• PrismXXBridge internally burns/locks the tokens and builds a mint operation to store on contract.

• At the block end, each mint operation will be consumed.

• For each mint operation, the coinbase mints the equivalent ASSET on native chain.

Case 2: Native Chain -> Smart Chain​ (FRC20/FRC721/FRC1155)

• Users build ConvertAccount operation and transfer some amount of ASSET to BlackHole. (Note: user can also send data in EVM ABI format to call the smart contract on EVM side)

• Blockchain calls withdrawFRC20 function in PrismXXBridge

• PrismXXBridge internally maps ASSET(UTXO) to FRC20/FRC721/FRC1155 asset (EVM).

• PrismXXBridge internally mints/releases equivalent assets to the target EVM address.

NOTE: Detailed steps are explained here.