nits (#92)

contracts/README.md

@@ -26,15 +26,15 @@ An abstract implementation of `ITeleporterTokenBridge` for a bridge contract on
 
 All messages sent by `TeleporterTokenDestination` instances are sent to the specified token source contract, whether they are to redeem the collateral on the home or chain or route the tokens to another destination chain. Routing tokens from one destination chain to another is referred to as a "multi-hop", where the tokens are first sent back to their token source contract to update its accounting, and then automatically routed on to their intended destination.
 
-`TeleporterTokenDestination` contracts allow for scaling token amounts, if the representative "wrapped" token is not a 1-to-1 equivalent of the backing asset. This token scaling can be used when the destination chain asset has a higher or lower denomincation than the source asset, such as allowing for a ERC20 source asset with a denomination of 6 to be used as the native EVM asset on a destination chain (with a denomination of 18).
+`TeleporterTokenDestination` contracts allow for scaling token amounts, if the representative "wrapped" token is not a 1-to-1 equivalent of the backing asset. This token scaling can be used when the destination chain asset has a higher or lower denomination than the source asset, such as allowing for a ERC20 source asset with a denomination of 6 to be used as the native EVM asset on a destination chain (with a denomination of 18).
 
-Note that the term "destination" in reference to bridge contracts refers to a non-home chain of a given asset where a representative asset is minted, backed the collateral locked on the home (source) chain. It is unrelated to the destination of an individual Teleporter message. `TeleporterTokenDestination` instances both send and receive Teleporter messages.
+Note that the term "destination" in reference to bridge contracts refers to a non-home chain of a given asset where a representative asset is minted, backed by the collateral locked on the home (source) chain. It is unrelated to the destination of an individual Teleporter message. `TeleporterTokenDestination` instances both send and receive Teleporter messages.
 
 ### `ERC20Destination`
 A concrete implementation of `TeleporterTokenDestination`, `IERC20Bridge`, and `IERC20` that handles the minting and burning of a destination chain asset. Note that the `ERC20Destination` contract _is_ the "wrapped" ERC20 implementation itself, which is why it takes the `tokenName`, `tokenSymbol`, and `tokenDecimals` in its constructor. All of the ERC20 interface implementations are inherited from the standard OpenZeppelin ERC20 implementation, and can be overriden in other implementations if desired. The optional Teleporter message fees used to incentivize a relayer for messages sent by this contract are all paid in kind, since the contract is an ERC20 token itself.
 
 ### `NativeTokenDestination`
-A concrete implementation of `TeleporterTokenDestination`, `INativeTokenBridge`, and `IWrappedNativeToken` that handles the minting and burning the native EVM on the destination chain using the native minter precompile. Deployments of this contract must be given the permission mint native coins in the chains configuration. Note that the `NativeTokenDestination` is also an implementation of `IWrappedNativeToken` itself, which is why the `nativeAssetSymbol` must be provided in its constructor. The optional Teleporter message fees used to incentivize a relayer for messages sent by this contract are all paid using the wrapped native token that the contract implements.
+A concrete implementation of `TeleporterTokenDestination`, `INativeTokenBridge`, and `IWrappedNativeToken` that handles the minting and burning the native EVM asset on the destination chain using the native minter precompile. Deployments of this contract must be given the permission mint native coins in the chains configuration. Note that the `NativeTokenDestination` is also an implementation of `IWrappedNativeToken` itself, which is why the `nativeAssetSymbol` must be provided in its constructor. The optional Teleporter message fees used to incentivize a relayer for messages sent by this contract are all paid using the wrapped native token that the contract implements.
 
 The [native minter precompile](https://docs.avax.network/build/subnet/upgrade/customize-a-subnet#minting-native-coins) must be configured to allow the contract address of the `NativeTokenDestination` instance to call `mintNativeCoin`. The correctness of a native token bridge implemented using `NativeTokenDestination` relies on no other accounts being allowed to call `mintNativeCoin`, which could result in the bridge becoming undercollateralized. Example initialization steps for a `NativeTokenDestination` instance are shown below.