fix typos (#1022)

spec/core/ics-003-connection-semantics/UPGRADES.md

@@ -456,12 +456,12 @@ function cancelConnectionUpgrade(
     abortTransactionUnless(verifyConnectionUpgradeError(currentConnection, proofHeight, proofUpgradeError, errorReceipt))
 
     // cancel upgrade
-    // and restore original conneciton
+    // and restore original connection
     // delete unnecessary state
     originalConnection = privateStore.get(restorePath(identifier))
     provableStore.set(connectionPath(identifier), originalConnection)
 
-    // delete auxilliary upgrade state
+    // delete auxiliary upgrade state
     provableStore.delete(timeoutPath(identifier))
     privateStore.delete(restorePath(identifier))
 }
@@ -503,7 +503,7 @@ function timeoutConnectionUpgrade(
     originalConnection = privateStore.get(restorePath(identifier))
     provableStore.set(connectionPath(identifier), originalConnection)
 
-    // delete auxilliary upgrade state
+    // delete auxiliary upgrade state
     provableStore.delete(timeoutPath(identifier))
     privateStore.delete(restorePath(identifier))
 }
@@ -515,4 +515,4 @@ The TRY chain will receive the timeout parameters chosen by the counterparty on
 
 ### Migrations
 
-A chain may have to update its internal state to be consistent with the new upgraded connection. In this case, a migration handler should be a part of the chain binary before the upgrade process so that the chain can properly migrate its state once the upgrade is successful. If a migration handler is necessary for a given upgrade but is not available, then th executing chain must reject the upgrade so as not to enter into an invalid state. This state migration will not be verified by the counterparty since it will just assume that if the connection is upgraded to a particular connection version, then the auxilliary state on the counterparty will also be updated to match the specification for the given connection version. The migration must only run once the upgrade has successfully completed and the new connection is `OPEN` (ie. on `ACK` and `CONFIRM`).
+A chain may have to update its internal state to be consistent with the new upgraded connection. In this case, a migration handler should be a part of the chain binary before the upgrade process so that the chain can properly migrate its state once the upgrade is successful. If a migration handler is necessary for a given upgrade but is not available, then th executing chain must reject the upgrade so as not to enter into an invalid state. This state migration will not be verified by the counterparty since it will just assume that if the connection is upgraded to a particular connection version, then the auxiliary state on the counterparty will also be updated to match the specification for the given connection version. The migration must only run once the upgrade has successfully completed and the new connection is `OPEN` (ie. on `ACK` and `CONFIRM`).

spec/core/ics-004-channel-and-packet-semantics/UPGRADES.md

@@ -329,7 +329,7 @@ function startFlushUpgradeHandshake(
 // openUpgradeHandshake will switch the channel fields 
 // over to the agreed upon upgrade fields.
 // it will reset the channel state to OPEN.
-// it will delete auxilliary upgrade state.
+// it will delete auxiliary upgrade state.
 // caller must do all relevant checks before calling this function.
 function openUpgradeHandshake(
   portIdentifier: Identifier,
@@ -346,7 +346,7 @@ function openUpgradeHandshake(
   channel.state = OPEN
   provableStore.set(channelPath(portIdentifier, channelIdentifier), channel)
 
-  // delete auxilliary state
+  // delete auxiliary state
   provableStore.delete(channelUpgradePath(portIdentifier, channelIdentifier))
   privateStore.delete(channelCounterpartyLastPacketSequencePath(portIdentifier, channelIdentifier))
   privateStore.delete(channelCounterpartyUpgradeTimeout(portIdentifier, channelIdentifier))
@@ -357,7 +357,7 @@ function openUpgradeHandshake(
 
 ```typescript
 // restoreChannel will restore the channel state to its pre-upgrade state
-// and delete upgrade auxilliary state so that upgrade is aborted.
+// and delete upgrade auxiliary state so that upgrade is aborted.
 // it writes an error receipt to state so counterparty can restore as well.
 // NOTE: this function signature may be modified by implementors to take a custom error
 function restoreChannel(
@@ -373,7 +373,7 @@ function restoreChannel(
   channel.state = OPEN
   provableStore.set(channelPath(portIdentifier, channelIdentifier), channel)
 
-  // delete auxilliary state
+  // delete auxiliary state
   provableStore.delete(channelUpgradePath(portIdentifier, channelIdentifier))
   privateStore.delete(channelCounterpartyLastPacketSequencePath(portIdentifier, channelIdentifier))
   privateStore.delete(channelCounterpartyUpgradeTimeout(portIdentifier, channelIdentifier))
@@ -979,7 +979,7 @@ function timeoutChannelUpgrade(
     if upgrade.fields.version == counterpartyChannel.version &&
         upgrade.fields.order == counterpartyChannel.order &&
         counterpartyHops == counterpartyChannel.connectionHops {
-          // counterparty has already succesfully upgraded so we cannot timeout
+          // counterparty has already successfully upgraded so we cannot timeout
           abortTransactionUnless(false)
     }
   }
@@ -1018,4 +1018,4 @@ Note that a channel upgrade handshake may never complete successfully if the in-
 
 ### Migrations
 
-A chain may have to update its internal state to be consistent with the new upgraded channel. In this case, a migration handler should be a part of the chain binary before the upgrade process so that the chain can properly migrate its state once the upgrade is successful. If a migration handler is necessary for a given upgrade but is not available, then the executing chain must reject the upgrade so as not to enter into an invalid state. This state migration will not be verified by the counterparty since it will just assume that if the channel is upgraded to a particular channel version, then the auxilliary state on the counterparty will also be updated to match the specification for the given channel version. The migration must only run once the upgrade has successfully completed and the new channel is `OPEN` (ie. on `ChanUpgradeConfirm` or `ChanUpgradeOpen`).
+A chain may have to update its internal state to be consistent with the new upgraded channel. In this case, a migration handler should be a part of the chain binary before the upgrade process so that the chain can properly migrate its state once the upgrade is successful. If a migration handler is necessary for a given upgrade but is not available, then the executing chain must reject the upgrade so as not to enter into an invalid state. This state migration will not be verified by the counterparty since it will just assume that if the channel is upgraded to a particular channel version, then the auxiliary state on the counterparty will also be updated to match the specification for the given channel version. The migration must only run once the upgrade has successfully completed and the new channel is `OPEN` (ie. on `ChanUpgradeConfirm` or `ChanUpgradeOpen`).

spec/core/ics-026-routing-module/UPGRADES.md

@@ -93,7 +93,7 @@ is invalid. If an error is returned by the callback, core IBC will revert any ch
 The `onChanUpgradeAck` callback may also perform custom ACK logic.
 
 After `onChanUpgradeAck` returns successfully, the application upgrade is complete on this end so any 
-auxilliary data stored for the purposes of recovery is no longer needed and may be deleted.
+auxiliary data stored for the purposes of recovery is no longer needed and may be deleted.
 
 If the callback returns successfully, the application MUST have its state fully migrated to start processing packet data according to the new application parameters.
 
@@ -111,7 +111,7 @@ function onChanUpgradeAck(
 `onChanUpgradeOpen` will perform custom OPEN logic. It MUST NOT error since the counterparty has already approved the handshake, and transitioned to using the new upgrade parameters.
 
 After `onChanUpgradeOpen` returns, the application upgrade is complete so any 
-auxilliary data stored for the purposes of recovery is no longer needed and may be deleted.
+auxiliary data stored for the purposes of recovery is no longer needed and may be deleted.
 
 The application MUST have its state fully migrated to start processing packet data according to the new application parameters by the time the callback returns.