Versions Compared

Old Version 1

changes.mady.by.user Diego Besprosvan

Saved on

compared with

New Version 2

changes.mady.by.user Diego Besprosvan

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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

Image RemovedImage Added

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.

    Code Block
    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

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

    Code Block
    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

    Code Block
    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

    Code Block
    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

    Code Block
    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

    Code Block
    // 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

    Code Block
    envelope:{ ... }
status:{
  code: 0
}
payload:{
  balance: 100,
  account:{
    finid: < finid of org_1:100:user_1 >
  }
  asset:{ 
    id: 'org_2:101:asset_1'
  }
}
signature: { ... }