chore: typo fixes

README.md

@@ -10,11 +10,11 @@ The Odos Router’s primary purpose is to serve as a security wrapper around the
 
 The primary functions of the router are the user-facing swap functions that facilitate token exchange for users. The router supports atomic multi-input and multi-output swaps via the internal `_swapMulti` function, but also supports slightly more gas efficient single to single swaps through the internal `_swap` function. The two functions also have different methods of revenue collection - The `_swap` function collects positive slippage when it occurs (defined as the difference between the executed and quoted output when the executed output is higher), while the `_swapMulti` function collects a flat fee defined by `swapMultiFee` on all swaps (and no positive slippage).
 
-Both `_swap` and `_swapMulti` have several externally facing functions that can be called. For accessing the user's ERC20s, both variants allow for traditional approvals made directly to the router, as well as the use of Uniswap's Permit2 contract (as seen here: https://github.com/Uniswap/permit2). Both variants also have a `compact` option, which uses a custom decoder written in Yul to allow for significantly less calldata to be necesary to describe the swap than the normal endpoints. Although yul typically has low readability, security assumptions for these two functions are low since they make a call to the same internal function that is callable with arbitrary parameters via the normal endpoint. These compact variants can also make use of an immutable address list when `SLOAD` opcodes are cheaper than paying for the calldata needed to pass a full value in.
+Both `_swap` and `_swapMulti` have several externally facing functions that can be called. For accessing the user's ERC20s, both variants allow for traditional approvals made directly to the router, as well as the use of Uniswap's Permit2 contract (as seen here: https://github.com/Uniswap/permit2). Both variants also have a `compact` option, which uses a custom decoder written in Yul to allow for significantly less calldata to be necessary to describe the swap than the normal endpoints. Although yul typically has low readability, security assumptions for these two functions are low since they make a call to the same internal function that is callable with arbitrary parameters via the normal endpoint. These compact variants can also make use of an immutable address list when `SLOAD` opcodes are cheaper than paying for the calldata needed to pass a full value in.
 
 ### Referrals 
 
-The router supports referral codes to track usage and, optionally, an additional fee that can be charged in conjunction with this referral code being used. New referral codes can be permissionlessly registered with the `registerReferralCode` function. A referral registration will consist of mapping a referral code to a `referralInfo` struct, which specifies the additional fee (if any), the beneficiary of the fee (again if any), and a boolean value specifying if that code has already been registered or not. The largest half of the space of possible referral codes is ellgible for an additional fee to be registered, while the lower half is strictly for tracking purposes in order to avoid extra storage reads. Once registered, `referralInfo` is immutable - if a change is needed, a new referral code will need to be registered. 
+The router supports referral codes to track usage and, optionally, an additional fee that can be charged in conjunction with this referral code being used. New referral codes can be permissionlessly registered with the `registerReferralCode` function. A referral registration will consist of mapping a referral code to a `referralInfo` struct, which specifies the additional fee (if any), the beneficiary of the fee (again if any), and a boolean value specifying if that code has already been registered or not. The largest half of the space of possible referral codes is eligible for an additional fee to be registered, while the lower half is strictly for tracking purposes in order to avoid extra storage reads. Once registered, `referralInfo` is immutable - if a change is needed, a new referral code will need to be registered. 
 
 A referral code can be used by passing into the swap function as an argument when a swap is executed. If specified, the swap will then charge the referral fee on the output(s) of the swap and send 80% of the fee to the specified beneficiary immediately, retaining the remaining 20% as router revenue similar to positive slippage and multi-swap fees. The referral code will then be emitted in the swap event in order to track the activity.