The first phase of the FinP2P protocol provided support for Primary Issuance of digital security tokens of an asset, this allowed Asset’s issuer to offer other users to buy tokens of the asset. in this next phase of FinP2P we introduce transaction support for Assets tokens between users, in which users will be able to publish intents (IOI) for exchanging tokens between them across connected FinP2P nodes. This option allows users to propose to buy or sell digital security token by creating an intent in which they can define the settlement conditions they are willing to pay or receive in exchange for the specified digital security.

Overview

Users, similar to issuers, will be allowed to create intents for selling or buying an Asset’s token and share those intents with other organizations on the FinP2P network. an intent will include the digital security token they are interested in selling or buying and the settlement conditions they are willing to receive or provide in exchange.

This transaction flow is backed by the same instant settlement safeguards used in the issuance flow, and in order to ensure safe transactions between buyers and sellers signatures will need to be provided by both parties in the transactions, those signatures will be validated prior to any action.
multiple Signature Strategies will be supported by the FinP2P node to allow for different types of security and flexibility levels.

Multiple intent types and schemes are introduced to support various application use cases for implementing transactions between users matching capabilities (e.g Trading bulletin board, Automatic matching, Auctions etc..).

Intents will be shared across the FinP2P network as resources and managed by the Asset’s Primary Node, in the same manner of asset issuance, all transactions related to the Asset will be routed and validated by its Primary node.

Types of Intents

As noted above, intents will be allowed to be created by both Sellers and Buyers;
Sellers will create a Selling intent in which they will indicate the amount of the digital security tokens they want to sell along with a set of settlement conditions they are whiling to accept in exchange.
Buyers will create a Buying intent in which they will list the desired digital security token amount and the set of settlement conditions they are willing to pay in exchange.
Intents can be defined with different level of commitment from the buyer or seller, intent can be pre signed by the creator (high level of commitment) or might require manual signing upon a Transaction (low level of commitment ).

Buying intent

For offering to Buy digital security token from other token holders, the buyers can create and share a buying intent in which they will provide the settlement conditions for a transaction.
In order to fulfill a buying intent, a buyer must have enough funds in their escrow account and must provide a signature on the settlement conditions defined in the intent. There are several ways this information can be provided, each way reflects different level of commitment from the Buyer:

Non signed intent: Buyer doesn’t provide a signature on the intent settlement conditions, the Asset Primary node will be required to contact the Buyer (through the FinP2P node) to receive a signature prior to execution of the token transaction on the DLT.
Pre-Signed intent: Buyer will pre-sign the settlement conditions on the buying intent, the asset’s FinP2P primary node will use those signature to ask the Escrow node to hold the relevant funds as part of the transaction flow.
Pre-Signed + Allocated intent: Buyer will pre-sign the settlement condition and pre allocate the settlement funds, indicated in the settlement conditions, on the Escrow Node.

Selling intent

To offer to sell digital security tokens in their possession, sellers will be able to create a selling intent and indicate the expected settlement conditions, similar to buying intent, selling intents can express different level of commitment from the seller side:

Non signed intent: Seller doesn’t provide singed agreement for the transaction, the Asset’s FinP2P primary node will need to contact the seller (through the FinP2P node) to retrieve the required signature to perform the token transaction on the underlying DLT.
Pre-Signed intent: Seller provides signatures that allow to transfer tokens from the account given a settlement condition, defined on the Selling intent, is fulfilled by a buyer, the signature allows for wildcard recipient of the tokens, on condition that the recipient conforms to the settlement conditions.
Pre-Signed + Designated intent: similar to pre-signed intent, signature will be provided in advance, the recipient of the tokens will be bonded to a specific user and not a wildcard.

FinP2P organization may prioritize intents based on level of commitment provided by their creators.

Sample flow

The next diagram will demonstrate a transaction between users, which involves three different organizations:

Asset Organization: Primary node organization of Asset X.
Seller Organization: Primary Node of a User that has possession of tokens of Asset X which was issued by the Asset Organization.
Buyer Organization: Primary Node of a Buyer.

The flow will show a use case for a Seller which wants to show intent of selling the tokens and will require a manual (not pre-signed) signature at the transaction execution time.

Cubes colored in yellow represent proposals for addition of new operations or modifications to existing operations on the FinP2P Spec.

FinP2P Network Interface Specification additions

The definitions below are an extension to the FinP2P Network Interface specifications to support transactions between users functionality.

Asset Service

The asset service was updated to support asynchronous transfer operations, trades between users, and the lifecycle management of Intents.

Secondary Intent Model

Below is the Intent types for accommodating Secondary transactions

message TransactionIntent {
  common.ResourceID id = 1;
  ...
  ...
  oneof intent {
   ...
   ...
    BuyingIntent buyingIntent = 101;
    SellingIntent sellingIntent = 102;
  }
}

message BuyingIntent {
  common.ResourceID buyer = 1;
  SignaturePolicyType signaturePolicyType = 2;
  BuyingSettlementInstruction settlementInstruction = 3;
  oneof signaturePolicy {
    PreSignedSignaturePolicy preSigned = 100;
    ManualSignaturePolicy manual = 101;
  }
}

message BuyingSettlementInstruction {
  oneof type {
    EscrowBuyingSettlementInstruction escrow = 100;
  }
  accounts.Account account = 1;
}

message EscrowBuyingSettlementInstruction {
  int64  expiry = 1;
}

message SellingIntent {
  common.ResourceID seller = 1;
  SignaturePolicyType signaturePolicyType = 2;
  SellingSettlementInstruction sellingSettlementInstruction = 3;
  oneof signaturePolicy {
    PreSignedSignaturePolicy preSigned = 100;
    ManualSignaturePolicy manual = 101;
  }
}

message SellingSettlementInstruction {
  oneof type {
    EscrowSellingSettlementInstruction escrow = 100;
  }
  repeated accounts.Account accounts = 1;
}

message EscrowSellingSettlementInstruction {
  repeated string  whiteListedEscrows = 1;
}

enum SignaturePolicyType {
  PresignedPolicy = 0;
  ManualPolicy = 1;
}

message PreSignedSignaturePolicy {
  signature.Signature signature = 1;
}

message ManualSignaturePolicy {
  ManualSignatureCallback callback = 1;
}

message ManualSignatureCallback {
  oneof method {
    HttpSignatureCallback http = 1;
  }
}

message HttpSignatureCallback {
  string endpoint = 1;
  string secret = 2;
}

FinP2P

Secondary Trading

Table of Contents