Update lips/lip-1.mdx

Co-authored-by: dahliamalkhi <[email protected]>

lips/lip-1.mdx

@@ -51,7 +51,7 @@ Two VASPs participate in the off-chain protocol. They communicate through HTTP r
 
 A VASP can define a `PaymentCommand` that creates or updates a single `PaymentObject`. Each `PaymentCommand` is sent to the other VASP in a `CommandRequestObject` and responded to by a `CommandResponseObject`. A success status in the response signals that the command was a success and the payment is updated by both VASPs (a command failure indicates the command is invalid, and a protocol failure indicates the command should be resubmitted at a later time).
 
-A VASP initially creates a `PaymentObject`, and then VASPs take turns updating it, through successful `PaymentCommands`, until it is ready to be settled or aborted. In a typical protocol flow, the VASP representing the sender would define the `PaymentObject` and include the sender's KYC information. The receiver VASP would check this information and either request more (see `soft-match` flows), abort, or signal that it is ready to settle the payment by updating sending the receiver's KYC information. The sender's VASP would check the receiver's KYC, and request more, abort, or settle the payment on-chain.
+A VASP initially creates a `PaymentObject`, and then VASPs take turns updating it, through successful `PaymentCommand`s, until it is ready to be settled or aborted. In a typical protocol flow, the VASP representing the sender would define the `PaymentObject` and include the sender's KYC information. The receiver VASP would check this information and either request more (see `soft-match` flows), abort, or signal that it is ready to settle the payment by sending the receiver's KYC information. The sender's VASP would check the receiver's KYC, and request more, abort, or settle the payment on-chain.
 
 The remainder of this document details the specifications for Commands, Objects and the typical and exceptional flows to define Payments and their Commands.