Prism++ Transfer

Prism++ allows for the transfer of FRC20, FRC721, and FRC1155 assets between Findora Native Chain and Findora EVM Chain, providing enhanced privacy features for those assets.

Findora is built from two different blockchain layers that follow a single consensus algorithm.

These two blockchain layers include:

• Findora Native Chain - a UTXO-based blockchain layer

• Findora Smart Chain - an accounts-based blockchain layer

Prism++ is the feature that enables users to bridge (aka transfer) assets from the UTXO-based side to the EVM accounts-based side (and vice-versa) of the Findora blockchain.

Essentially, Prism++ transfer is an internal bridge between the two Findora blockchains.

Users can initiate a Prism++ transfer via the Findora wallet. Developers can integrate PRISM transfers into their applications via the SDK.

Prism Overview

Why Prism++?​

Most blockchains follow one of two record-keeping models: the UTXO model or the account model. Blockchains such as Bitcoin and ZCash use a UTXO model and others, such as Ethereum and Polkadot, use an account model.

Findora integrates both models in its architecture to capitalize on the advantages of each. However, to enable compatibility across these two blockchains inside Findora, the Prism feature was introduced so that the two chains can atomically swap tokens and work together as a single blockchain without having to trust a central intermediary during the swap process.

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 Findora 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

Native Chain FRA and Smart Chain FRA​

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

On the smart chain, the tokens are called FRA-smart tokens and are used to pay transaction fees and interact with Dapps built on the Findora EVM.

While using the Findora wallet, if the FRA token is simply labeled “FRA” (rather than FRA-native or FRA-smart), simply check which chain the token exists on to determine what type of FRA it is. For example, Metamask only supports accounts-based tokens so any FRA stored on Metamask is of type FRA-smart.

Special Note: A key innovation of the Findora’s Smart Chain is the design of the Smart Chain token which is not only a token required to pay for gas transactions on the Smart Chain but it’s also been enhanced to follow the Smart Chain’s FRC-20 standard (i.e. Findora’s version of Ethereum’s ERC-20) by default. So unlike Ethereum, which requires the ETH tokens to be wrapped into ERC-20 form before they can work on an Ethereum DEX, Findora Smart Chain tokens will work automatically on any Findora DEX without the extra step of needing to wrap the FRA tokens first.

Prism and Prism++ Transfers

Transfer Type	Supported Tokens
Prism Transfer	FRA
Prism++ Transfers	FRC20, FRC721, FRC1155

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.