# Prism Internal Transfer

## Context
Findora adopts a hybrid ledger model which provides the benifits of both the UTXO and Account based models. The two models are complimentary to each other and the thus can help to negate the problems that each model has . The hybrid model implemented by Findora allows users to store assets in the form of a UTXO or Account balance. It is able to do this by using separate storage methods while combining their hashes to maintain integrity within the network
### Utxo
In a UTXO based ledger, strictly speaking, there are no accounts or wallets at the protocol layer. Instead, coins are stored as a list of unspent transaction outputs or UTXOs. Each UTXO has a quantity and a criteria for spending it. Transactions are created by consuming existing UTXOs and producing new UTXOs in their place.

### Account
Instead of having each coin be uniquely referenced, coins are represented as a balance within an account. Accounts can either be controlled by a private key or a smart contract.

### Comparisons

#### Utxo Model advantages in Findora
- The utxo model provides us with privacy features , allowing us to do confidential payments , by masking different fields in the tx body .
- The utxo model also makes it possible for us to submit proofs in zero knowledge which in simple terms means that the ledger (Validators) can never obtain the TX data. This one feature , solves multiple problems existing in the defi space right now.
- Simplicity. Spending a UTXO is all or nothing. Since UTXOs are uniquely referenced and completely consumed upon spending, there is no chance for a transaction to be replayed.
- Transactions can be trivially verified in parallel. It is impossible for two transactions to affect the same UTXO. This is due to the stateless nature of UTXO transactions. Transactions do not refer to any input outside of the UTXOs consumed and corresponding signatures.

#### Account Model advantages in Findora
- Findora uses EVM under the hood , as the vitual machine to power the account based legger . This automatically opens up our gateway to the whole Ethereum ecosystem. Developers can port thier Dapps over to findora with trivial efforts .This also includes existing EVM infrastructure such as Bridges , DEXs etc .
- The Findora EVM also provides a set of precompiled contracts ( think of them as apis ) , which allow developers to leverage additional features , when developing Dapps . In the near future the privacy features powered by the our crypto library will soon be available on the EVM platform .
- More flexible transactions. Transactions depend on the existing state and can have diverging effects based on external input. This allows things like oracles and other logic to influence the resulting state of a transaction.

## Internal Transfer (Prism)

### What is it ?
Internal trasfer provides ability for a user to convert thier FRA from between UTXO and Acc ount ledgers . This functionality can be used to go in both directions .

#### UTXO -> Account
- The transaction is built with a Transfer and Convert operation
- The UTXO is burnt by transferring to a burn address
- Assets are minted by adding to the owner's balance. (Account specified in the transaction)
- THe Tx fees for this transaction is paid using FRA-UTXO.

#### Account -> UTXO
- 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
- The Tx fees for this trasation is paid usin FRA-EVM

NOTE : The exact steps can be found here : https://wiki.findora.org/docs/dapp/wallet

## Internal Transfer Technicals

### Spec
The user can transfer the asset balance in UTXO to the Account, and the asset balance is calculated based on the sum of the balances in the linked UTXO address. The process of fund transfer is to burn UTXO balance and at the same time mint equivalent Account balance to the specified Account address. The Account address can be either an Ethereum address (ecdsa) or a Native Address (ed25519); in the same way, account assets can also be transferred to generate UTXO.

If the user wants to transfer UTXO balance directly to the Ethereum address, the chain realization process is: first convert the ecdsa (H160) address to the ed25519 address ([u8; 32]), and store the balance under the ed25519 address, but the ed25519 address has no private key, only the ecdsa private key owner can manipulate the balance under the address, but this process occurs under the hood
However, the wallet displays the Native address corresponding to the Ethereum address, such as:
0x2aD32846c6DD2ffd3eDADBe51CD5ae04Aa5e575E which corresponds to evm1eexg0w8k4npk8rwehqn9nrxus3yhxyd7m0xl568suq5x7xcqshksvlfl9g
These two addresses are equivalent.

If the user wants to transfer Account Balance back to UTXO, there are two situations:
Ed25519 signature transfer transaction (for addresses beginning with fra)
Ecdsa signature transfer transaction (for addresses starting with 0x or evm)

In the end, for users, users only need to transfer between UTXO balance and Account balance, and the Account address can be either an ethereum address or a native address.