#5 Findora Academy 💟: Prism Addressing Architecture — Deep Dive

Welcome to our second article discussing Prism (fka internal transfer) which enables Findora users to send Findora tokens (FRA and other Findora custom assets) from the Findora Native Chain to the Smart Chain — and vice versa.

This article will discuss in more technical detail how the Prism transfer works. For a higher level overview see the first article of this three-part Prism series.

Addressing Scheme — ECDSA vs. ed25519

One of the key difficulties in designing and implementing Prism is the heterogeneity of address types between the Findora Native Chain and the Findora Smart Chain. To achieve full compatibility with EVM tools such as Metamask, the newly added smart chain has to use ECDSA addresses.

However, as the ed25519 addresses used by the native chain are widely considered to be more secure, Findora engineers did not want to sacrifice the security and backward compatibility of the Findora system when adding support for EVM.

One way to solve this issue would have been to create an address binding process that would have forced users to generate and bind a pair of addresses (i.e. one ECDSA address and one ed25519 address) and only allow transfers between the paired addresses. However, there are two drawbacks to this type of design. First, it is not user-friendly. A user has to understand the concept of address binding (ed25519 and ECDSA). For existing native chain users, who hold only ed25519 addresses, a binding process would be required if they would like to use their addresses for Prism. Second, users would have been unable to fund any other unbinded addresses using Prism. This would add more steps to the fund transfer among different users or different addresses owned by the same user, therefore making Prism more limited and less user-friendly.

No Address Binding, Atomicity and Similarity to a Trustless Bridge

Given these limitations, Findora engineers decided upon a more general approach to implement Prism. There is no binding process between different address types. Prism implements two sets of burn/mint operations for Findora UTXO and Findora EVM modules. The atomicity of Prism transfers is guaranteed by bundling the operations in a single transaction, which is validated through distributed consensus.

Thus, the Prism process is similar to a trustless bridge protocol between the UTXO module and EVM module. Users can exchange FRA (and eventually other custom assets) without address binding.

Therefore, in a Prism transfer from Findora Native Chain (UTXO) to Findora Smart Chain (EVM), the process for transferring assets is to burn UTXO balances while at the same time minting the equivalent amount in an account balance to the specified account address on the smart chain side. The account address MUST be an Ethereum address (ECDSA) when transferring (UTXO-based) native FRA tokens to Findora Smart Chain. In the same way, account assets can also be transferred to generate UTXO amounts when transferring from the smart chain to the native chain. In a Prism transfer from Findora Smart Chain (EVM) to Findora Native Chain (UTXO), the process for transferring assets is to burn some account balance while at the same time minting the equivalent value of UTXO on the native chain.

EVM Compatibility

Users may reuse an existing ECDSA address and a private key derived from any EVM compatible chain, such as Ethereum or BSC to use on the Findora Smart Chain. Hardware wallets that support the EVM should also support Findora Smart Chain addresses (Here is the link to a step-by-step guide for using Ledger hardware wallet with Findora Smart Chain).