The FinP2P blockchain ledger abstraction interface provides a protocol layer between applications and different blockchains DLTs protocols and APIs.

Implementers can decide to use any interface / SDK / API to connect to the underlying blockchainDLT. 

This specification encourages a standard abstraction layer to allow Blockchain DLT vendors to create their own implementation of this layer and, therefore, remove the complexity of integrating with any specific BlockchainDLT.

We also envision 3rd party vendors to provide multiple implementations for this layer, bringing value added differentiation and competition to the market.

The blockchain DLT provides the distributed, redundant, immutable and verifiable ledger layer for the following use cases:

Ledger Storage Use Cases

Asset Transaction

Any transaction that involves assets is recorded in the ledger:

• Issuance: Primary distribution of tokens for an Asset

• Transfers: Change of ownership of an asset’s token

• Redeems: The redeem (burn) of an asset token

• Atomic Swap: Atomic exchange of an asset with a cash asset.

Hash Backup of Private Data

It is encouraged by this specification that Private Data layers implementers persist a verificable hash of the private data in the blockchainDL.

Organizations on different blockchains DLs can verify the validity of the private data received by creating the Hash value of the private data and sending a broadcast query to the network to check if the Hash matches the one stored in the blockchainDL.

Transaction Confirmation Record

Whenever an asset transaction is executed in a local or remote FInP2P node, a transaction “conformation record” is generated and sent to the Node requesting the transaction.

This specification encourages implementers to store the confirmation record in their own blockchain DLT as proof of the remote transaction. The confirmation record can be used at any time to verify if the transaction was actually performed at the remote Node by sending a broadcast query request.