Correct spelling

spec/ics-027-interchain-account/README.md

@@ -31,26 +31,26 @@ The IBC handler interface & IBC relayer module interface are as defined in [ICS
 
 ## Technical Specification  
 
-The implementation of interchain account is non-symmetric. This means that each chain can have a different way to generate an interchain account and deserialize the transaction bytes and a different set of transactions that they can execute. For example, chains that use the Cosmos SDK will deserialise tx bytes using Amino, but if the counterparty chain is a smart contract on Ethereum, it may deserialise tx bytes by an ABI that is a minimal serialisation algorithm for the smart contract.  
+The implementation of interchain account is non-symmetric. This means that each chain can have a different way to generate an interchain account and deserialise the transaction bytes and a different set of transactions that they can execute. For example, chains that use the Cosmos SDK will deserialise tx bytes using Amino, but if the counterparty chain is a smart contract on Ethereum, it may deserialise tx bytes by an ABI that is a minimal serialisation algorithm for the smart contract.
 The interchain account specification defines the general way to register an interchain account and transfer tx bytes. The counterparty chain is responsible for deserialising and executing the tx bytes, and the sending chain should know how counterparty chain will handle the tx bytes in advance.
 
 Each chain must satisfy following features to create a interchain account:
 
 - New interchain accounts must not conflict with existing ones.
 - Each chain must keep track of which counterparty chain created each new interchain account.
 
-Also, each chain must know how the counterparty chains serialize/deserialize transaction bytes in order to send transactions via IBC. And the counterparty chain must implement the process of safely exececuting IBC transactions by verifying the authority of the transaction's signers.
+Also, each chain must know how the counterparty chains serialise/deserialise transaction bytes in order to send transactions via IBC. And the counterparty chain must implement the process of safely exececuting IBC transactions by verifying the authority of the transaction's signers.
 
 The chain must reject the transaction and must not make a state transition in the following cases:
 
-- The IBC transaction fails to be deserialized.
+- The IBC transaction fails to be deserialised.
 - The IBC transaction expects signers other than the interchain accounts made by the counterparty chain.
 
 It does not restrict how you can distinguish signers that was not made by the counterparty chain. But the most common way would be to record the account in state when the interchain account is registered and to verify that signers are recorded interchain account.
 
 ### Data Structures
 
-Each chain must implement the below interfaces to support interchain account. ```createOutgoingPacket``` method in ```IBCAccountModule``` interface defines the way to create an outgoing packet for a specific type. Type indicates how IBC account transaction should be constructed and serialized for the host chain. Generally, type indicates what framework the host chain was built from.  
+Each chain must implement the below interfaces to support interchain account. ```createOutgoingPacket``` method in ```IBCAccountModule``` interface defines the way to create an outgoing packet for a specific type. Type indicates how IBC account transaction should be constructed and serialised for the host chain. Generally, type indicates what framework the host chain was built from.
 ```generateAddress``` defines the way how to determine the account's address by using identifier and salt. Using the salt to generate an address is recommended, but not required. If the chain doesn't support a deterministic way to generate an address with a salt, it can be generated by its own way. ```createAccount``` is used to create account with generated address. New interchain account must not conflict with existing ones, and chains should keep track of which counterparty chain created each new interchain account in order to verify the authority of transaction's signers in ```authenticateTx```.
 ```authenticateTx``` validates a transaction and checks that the signers in the transaction have the right permissions. ```runTx``` executes a transaction after it was authenticated successfully.
 
@@ -61,7 +61,7 @@ interface IBCAccountModule {
   createOutgoingPacket(chainType: Uint8Array, data: any)
   createAccount(address: Uint8Array)
   generateAddress(identifier: Identifier, salt: Uint8Array): Uint8Array
-  deserializeTx(txBytes: Uint8Array): Tx
+  deserialiseTx(txBytes: Uint8Array): Tx
   authenticateTx(tx: Tx): boolean
   runTx(tx: Tx): uint32
 }
@@ -213,7 +213,7 @@ In plain English, between chains `A` and `B`. It will describe only the case tha
 ```typescript  
 function onRecvPacket(packet: Packet): bytes {  
   if (packet.data is RunTxPacketData) {  
-    const tx = deserializeTx(packet.data.txBytes)
+    const tx = deserialiseTx(packet.data.txBytes)
     abortTransactionUnless(authenticateTx(tx) == true)
     return runTx(tx)
   }