Sample Flow

The following diagram illustrates a FinP2P flow of messages betwenn 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.

    1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 identity: { cluster: [ 'cluster_A' ], 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

    1 2 3 4 5 6 7 8 9 10 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.

    1 2 3 4 5 6 7 8 9 10 11 12 13 14 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

    1 2 3 4 5 6 7 8 envelope { ... to: 'cluster_A' } verify: { resourceid: 'org_2:101:asset_1', hash: < hash(payload) > }
  5. All the nodes 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 node.

  8. Org 1 FinP2P node 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

    1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 envelope:{ requestid: 10101 from: 'Org_1' to: 'Org_2' } transfer:{ from: { id: 'Org_1:100:users_1', finid: < user_1 FinP2P Global Identifier >, } to: { id: < asset holder >, finid: < asset holder > } assetid: 'org_2:101:asset_1' quantity: 100 signature:{ alg: < signature algorithm based on ATST > payload: < payload of the signature > } }
  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

    1 2 3 4 5 6 7 8 9 10 get: { accept-types:[ "application/ivms-101" // No standard yet ], resources: [ { 'org_1:100:user_1' } ] }
  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

    1 2 3 4 5 6 7 8 9 10 11 // Send Message Envelope envelope: { ... to: 'cluster_A' } account:{ // acount to retrieve balance finid: < finid of org_1:100:user_1 > } asset:{ id: 'org_2:101:asset_1' }
  17. Any node from Cluster B can answer the Balance request

    1 2 3 4 5 6 7 8 9 10 11 12 13 14 envelope:{ ... } status:{ code: 0 } payload:{ balance: 100, account:{ finid: < finid of org_1:100:user_1 > } asset:{ id: 'org_2:101:asset_1' } } signature: { ... }