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

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

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

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

The 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 DL.

Organizations on different 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 DL.

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