Research work on Logon and Logon Reject

[uwezukwechibuzor]

Both parties should generate new DID, then create Account on the FIX module

Initiator: The initiator uses DID and sends a login request to the acceptor, including their DID and a proof of authenticity, such as a digital signature.

Acceptor: The acceptor verifies the authenticity of the initiator's request by checking the digital signature against the public key associated with the initiator's DID. If the request is valid, the acceptor sends a challenge message to the initiator.

Initiator: The initiator signs the challenge message using their private key, and sends it back to the acceptor.

Acceptor: The acceptor verifies the signature of the challenge response using the public key associated with the initiator's DID. If the signature is valid, the acceptor logs in the initiator and grants them access to the blockchain-based FIX protocol(Session Creation).

Ongoing communication: The initiator and acceptor can then communicate with each other over the blockchain-based FIX protocol, with each message signed and verified using their DIDs and digital signatures.

[uwezukwechibuzor]

Logon from a sender(Initiator)

8=FIX.4.4|9=59|35=A|34=1|49=SenderCompID|52=20230219-10:30:00.000|56=TargetCompID|98=0|108=30|141=Y|10=118|

In this message, each field is separated by the vertical bar (|) symbol and contains a tag number and a value, separated by an equals (=) symbol. The fields in this message are:

8 (BeginString): The FIX version being used. In this case, it is FIX 4.4. 9 (BodyLength): The length of the message body (excluding the header and trailer) in bytes. 35 (MsgType): The type of message. In this case, it is a Logon message (A). 34 (MsgSeqNum): The sequence number of this message. 49 (SenderCompID): The identifier of the sending party. 52 (SendingTime): The time the message was sent, in the format YYYYMMDD-HH:MM:SS.sss. 56 (TargetCompID): The identifier of the receiving party. 98 (EncryptMethod): The encryption method used. 108 (HeartBtInt): The number of seconds between heartbeats. 141 (ResetSeqNumFlag): Indicates whether the receiving party should reset its sequence numbers. 10 (CheckSum): The checksum of the message body, calculated using the Checksum algorithm.

[uwezukwechibuzor]

Logon from a Receiver(acceptor)

8=FIX.4.4|9=60|35=A|34=2|49=TargetCompID|52=20230219-10:30:00.000|56=SenderCompID|98=0|108=30|141=Y|10=094|

In this message, the fields have the same meaning as in the Logon message sent by the initiator, but with the following differences:

The MsgSeqNum (34) field contains a sequence number one greater than the sequence number of the Logon message received from the initiator. The SenderCompID (49) and TargetCompID (56) fields are reversed to reflect the fact that the acceptor is now sending the message to the initiator. The CheckSum (10) field contains the calculated checksum for the entire message (header, body, and trailer). The Logon response message serves to acknowledge the session and confirm that the acceptor is ready to receive messages from the initiator.

[uwezukwechibuzor]

Take note of this

In a blockchain-based FIX Protocol, the "EncryptMethod" field may not be required in the same way as in a traditional FIX Protocol implementation, because the encryption of messages is already inherently provided by the blockchain technology itself.

Blockchain technology uses cryptography to secure and validate transactions and messages, which means that messages exchanged between counterparties are already encrypted and authenticated by default. This makes it unnecessary to include an explicit "EncryptMethod" field in the FIX Protocol message.

However, it is still possible that a blockchain-based FIX Protocol implementation may include an "EncryptMethod" field in the message for compatibility reasons, to ensure that the messages conform to the FIX Protocol standard. In this case, the value of the "EncryptMethod" field may still be set to "0" for "None", or it may be set to a different value to indicate the specific encryption method used by the blockchain implementation.

[uwezukwechibuzor]

The logon acceptor in a blockchain-based FIX protocol will typically use queries to access the data sent to the blockchain by the initiator. The initiator will typically send the request as a transaction on the blockchain, which will be recorded as a block on the chain.

The logon acceptor can then query the blockchain to retrieve the relevant data for the transaction, including the digital signatures and public keys used to authenticate the initiator. The logon acceptor can then verify the authenticity and integrity of the request by comparing the digital signatures to the public keys on the blockchain.

In addition, the logon acceptor may also need to query other data on the blockchain, such as transaction history or smart contract code, to ensure that the request is valid and complies with the rules and protocols of the blockchain-based FIX system.

Overall, queries are an essential tool for the logon acceptor to access and verify data on the blockchain in a blockchain-based FIX protocol.

[uwezukwechibuzor]

In a blockchain-based FIX protocol, the "BodyLength" field with a numerical tag of "9" may or may not be needed, depending on how the protocol is designed and implemented.

The FIX protocol is primarily used in traditional financial markets for exchanging messages related to trading and other financial activities. In a blockchain-based financial market, the FIX protocol could potentially be used to facilitate communication between participants in the market.

However, in a blockchain-based system, the message size and the length of the message body may be handled differently compared to traditional FIX protocols. Since blockchain-based systems use distributed ledger technology to maintain a decentralized ledger of transactions, the size and structure of messages may be different.

Therefore, the message format and field structure in a blockchain-based FIX protocol may be different from a traditional FIX protocol. The BodyLength field with a numerical tag of "9" may or may not be necessary, depending on the specific design of the protocol.

[uwezukwechibuzor]

In the FIX (Financial Information eXchange) protocol, BodyLength and CheckSum are two different fields with different purposes.

BodyLength is a required field in every FIX message and represents the length of the message body in bytes, including the SOH (Start Of Header) character and the trailing SOH character. It is calculated by counting the number of bytes in the message body and adding two for the SOH characters at the beginning and end of the message.

For example, if the message body is "35=D|55=MSFT|", where '|' represents the SOH character, the BodyLength field would be 13 (i.e., the length of the string plus two SOH characters).

CheckSum is also a required field in every FIX message and is used to ensure the integrity of the message. It represents a single-digit checksum value calculated over the entire message (excluding the SOH character at the beginning of the message and the CheckSum field itself).

To calculate the CheckSum, you take the ASCII value of each character in the message (excluding the SOH at the beginning of the message) and add them together. The result is then modulo 256, and the remainder is subtracted from 256 to obtain the final CheckSum value. For example, if the sum of the ASCII values is 300, the CheckSum value would be 44 (i.e., 256 - 44 = 212 in decimal).

In summary, BodyLength represents the length of the message body in bytes, including the SOH characters, while CheckSum is a checksum value calculated over the entire message (excluding the SOH at the beginning of the message and the CheckSum field itself) and is used to ensure the integrity of the message.

[uwezukwechibuzor]

Logon Reject: The Logon Reject message is sent by a FIX session acceptor to a FIX session initiator in response to a Logon message from the initiator that could not be processed successfully. It is identified by the FIX message type "A". The Logon Reject message has the following fields:

MsgType (35): This field specifies the message type as "A" for Logon Reject messages. Text (58): This field is required and provides a human-readable description of the reason for the logon rejection.