Update adr-003-dynamic-capability-store.md

docs/architecture/adr-003-dynamic-capability-store.md

@@ -9,7 +9,7 @@
 
 Full implementation of the [IBC specification](https://github.com/cosmos/ibc) requires the ability to create and authenticate object-capability keys at runtime (i.e., during transaction execution),
 as described in [ICS 5](https://github.com/cosmos/ibc/tree/master/spec/core/ics-005-port-allocation#technical-specification). In the IBC specification, capability keys are created for each newly initialised
-port & channel, and are used to authenticate future usage of the port or channel. Since channels and potential ports can be initialised during transaction execution, the state machine must be able to create
+port & channel, and are used to authenticate future usage of the port or channel. Since channels and potentially ports can be initialised during transaction execution, the state machine must be able to create
 object-capability keys at this time.
 
 At present, the Cosmos SDK does not have the ability to do this. Object-capability keys are currently pointers (memory addresses) of `StoreKey` structs created at application initialisation in `app.go` ([example](https://github.com/cosmos/gaia/blob/dcbddd9f04b3086c0ad07ee65de16e7adedc7da4/app/app.go#L132))
@@ -27,7 +27,7 @@ the `CapabilityKeeper` will be hooked up to modules through unique function refe
 (by calling `ScopeToModule`, defined below) so that it can identify the calling module when later
 invoked.
 
-When the initial state is loaded from the disk, the `CapabilityKeeper`'s `Initialise` function will create
+When the initial state is loaded from disk, the `CapabilityKeeper`'s `Initialise` function will create
 new capability keys for all previously allocated capability identifiers (allocated during execution of
 past transactions and assigned to particular modes), and keep them in a memory-only store while the
 chain is running.