Sample Flow

Owned by Yuval Carmel
Last updated: Jul 10, 2024 by Yuval Carmel
3 min read

The following diagram illustrates a FinP2P flow of messages between Organizations from different clusters.

The flow starts with an Asset advertisement followed with an asset transfer transaction.

Diagram

The flow represents a subset of the FinP2P-Core and FinP2P-Network iteraction.

Actors

  • Cluster B: This cluster holds 3 Organizations. Org 2, Org 3 and Org 4

  • Organization 1: This organization belongs to Cluster A.

  • User: This User is managed by Organization 1.

  • Asset: An asset managed by Organization 2 and shared with Organization 1.

Flow

  1. Org B advertise Asset to the network. In this case to Org 1.

    identity: { cluster: [ 'cluster_B' ], resource: 'Org_2', finid: { < Org_2 Global FinP2P Identifier> } }, address: { hosts:[ { scheme: 'TCP', address: 'finp2p.org2.com', } ] }, resources: [ { resourceid: 'org_2:101:asset_1' } ]

  2. Org 1 request the Asset data to offer to its customers

    get: { accept-types: [ 'application/json', ], resources: [ { 'org_2:101:asset_1' } ] }

  3. Org 2 receives the request, verifies the sender signature and checks if the requestor is allowed to get the Resource data. If all OK, it responds with the resource data.

    status:{ code: 0 }, payload:{ resources: [ { response: { resource: 'org_2:101:asset_1', status: 0, payload: { ... } // Asset Data } } ] }

  4. Org 1 receives the asset data. To verify that the data is correct, it sends a broadcast message to the cluster

  5. All the Routers from the cluster can respond to the verify request.

  6. Org 1 now can offer Org B’s asset to its users

  7. A user from Org 1 wants to buy 100 tokens of the Asset. It uses an Application provided by Org 1 to perform the Transaction. this application implements FinP2P Application API to communicate with the Router.

  8. Org 1 FinP2P Router received the request and creates the Transfer message using the Asset’s Asset Transaction Signature Template

  9. The request is signed by the users or his custodian and the message is sent to Org 2

  10. Org 2 receives the transaction, creates the Tx ID and returns the Tx ID to Org 1. Org 2 verifies the request.

  11. Org 2 ask Org 1 for the User Information

  12. Org 2 receives the user information and executes regulation checks to validate the transaction.

  13. Org 2 feeds the transaction to its cluster DLT.

  14. When the Transaction settles, Org 2 sends a notification to Org 1 with the Tx status and a chainpoint anchor as proof of the transaction.

  15. At this point Org 1 can use the chainpoint to verify the transaction at any time by sending a broadcast verify request to the cluster of Org 2

  16. To refresh the application and reflects the new user balance, Org 1 sends a brodcast Balance request to Cluster B

  17. Any Router from Cluster B can answer the Balance request

Â