docs: Documentation Typos and Content Improvements (#102)

Signed-off-by: Cypher Pepe <[email protected]>

README.md

@@ -92,7 +92,7 @@ The action needs to be triggered manually, and can be triggered on any branch ma
 - Make sure the branch you are creating the release on is clean and good to go
 - Go to Actions and select the "Create prod release" action
 - Click "Run workflow" and select the target branch
-- After the workflow run is complete, the new release is automatically pushed to the Releses age of the repo and the commit gets tagged
+- After the workflow run is complete, the new release is automatically pushed to the Releases page of the repo and the commit gets tagged
 - After green light from QA, upload the build to the Chrome
 
 ### Create a production release locally

docs/05-Dapp-connections.md

@@ -25,7 +25,7 @@ Since each EVM-compatible wallet needs to implement the same interface, defined
 
 When Core's provider gets injected, it attempts to lock down both the `window.ethereum` and `window.avalanche` properties. It creates a Proxy object and starts to listen to overwrite attempts. If another wallet attempts to overwrite Core's provider, it gets stored in the `providers` array. Next time when the website attempts to connect to `window.ethereum`, Core prompts the user to select the wallet they want to use. The selected provider will be set as default for the current session for all communications.
 
-In order to try and elimate the "race" to own the `window.ethereum` object, the [EIP-5749](https://eips.ethereum.org/EIPS/eip-5749) replaces `window.ethereum` with `window.evmproviders`. Each wallet will have a `{[index: string]: Provider}` in the `window.evemproviders` object. As for now this is NOT a breaking change and does not required replacing the `window.ethereum` with `window.evmproivders` object but rather has both and in the future replacing `window.ethereum` with `window.evmproviders` and such causing a breaking change.
+In order to try and elimate the "race" to own the `window.ethereum` object, the [EIP-5749](https://eips.ethereum.org/EIPS/eip-5749) replaces `window.ethereum` with `window.evmproviders`. Each wallet will have a `{[index: string]: Provider}` in the `window.evemproviders` object. As for now this is NOT a breaking change and does not required replacing the `window.ethereum` with `window.evmproviders` object but rather has both and in the future replacing `window.ethereum` with `window.evmproviders` and such causing a breaking change.
 
 ## Initialization
 

docs/08-Analytics-and-Feature-Flags.md

@@ -76,5 +76,5 @@ To report an error to Sentry, use the `console.error` method. Unhandled exceptio
 - **DO** be careful about consecutive events. For example, a token selection event itself does not identify the transaction, but with an amount and the timestamp of pushing the send button, it's easy to figure out the source.
 - **DO** add analytics events for new features
 - **DO** default to the less bad when integrating feature flags. If the feature flag service is down, should we disable the feature by default or is it worse if we can't disable it?
-- **DO** make sure your new Fetaure Flags are added to both environments and have the correct default values before merging your PR.
-- **DO** fix the bugs and handle the exceptions fund in Sentry.
+- **DO** make sure your new Feature Flags are added to both environments and have the correct default values before merging your PR.
+- **DO** fix the bugs and handle the exceptions found in Sentry.

docs/09-Keystone.md

@@ -6,7 +6,7 @@ The current firmware version is M-10.3
 ## What we have discovered so far
 
 There is an App for Core. It requires beta firmware for the time being.
-Go to the Menu -> Software Waller -> Core Wallet and select it by tapping on Confirm in the top right corner.
+Go to the Menu -> Software Wallet -> Core Wallet and select it by tapping on Confirm in the top right corner.
 
 ### Create Wallet
 

docs/10-WalletConnect.md

@@ -44,7 +44,7 @@ BTC signing is not supported at the moment, as none of the known wallets support
 Some apps (i.e. Metamask Mobile), do not accept multiple chains to be requested in a session proposal payload - they will automatically reject such a request.
 
 Since we don't know which wallet app the user will use when we initiate the pairing, we must always specify only a single chain in the session proposal - and we default to the currently active chain.
-Most of the time, new chains can added to the session at a later point and we do it on demand, when the user actually tries to sign a message or transaction on a different chain. ļFor more information on that, please refer to a well-documented `establishRequiredSession` method of the [`WalletConnectService`](../src/background/services/walletConnect/WalletConnectService.ts).
+Most of the time, new chains can added to the session at a later point and we do it on demand, when the user actually tries to sign a message or transaction on a different chain. For more information on that, please refer to a well-documented `establishRequiredSession` method of the [`WalletConnectService`](../src/background/services/walletConnect/WalletConnectService.ts).
 
 ## Data storage
 

docs/11-Fireblocks.md

@@ -41,7 +41,7 @@ Then the user can provide us with 2 info.
 2. API Secret (This is the content of .key file from creating a CSR file.)
 
 We store these encrypted like other secrets like private keys.
-The API credentials can't be added, edited, and delted separately right now.
+The API credentials can't be added, edited, and deleted separately right now.
 So the user will have to delete the imported Fireblocks account and then re-import it if they would like to change the info.
 
 ## Signing Flow
@@ -55,7 +55,7 @@ Each policy will decide how many people out of the people listed in the policy n
 
 1. The user submit the request in Core Browser Extension. The user will see the pending state on the confirmation screen.
 2. Core Browser Extension request fireblocks to process the request using API using an unique external transaction ID.
-3. Fireblocks uses the TAP to get all required appovals. If any needed. Auto approval is also possible.
+3. Fireblocks uses the TAP to get all required approvals. If any needed. Auto approval is also possible.
 4. Core Browser Extension fetch the result based on an unique external transaction ID and wait until the returned state has an error or a txHash.
 5. Core Browser Extension returns the txHash (If successful)/ error (If not successful) to UI
 6. The UI closes the confirmation screen and show the toast with link to the transaction in explorer (If successful)/ the error (If not successful)
@@ -162,6 +162,6 @@ We should probably inform the users about that when they start bridging using Fi
 We are going to introduce 2 features in the future.
 
 1. Pending fireblocks tx tracker
-   We would like to let users to be able to use the extension while they wait when the approval process in Fireblocks is taking awile.
+   We would like to let users to be able to use the extension while they wait when the approval process in Fireblocks is taking awhile.
 2. API credential editor
    We would like to let users add, update, and delete the API credential whenever they would like. Right not, they would have to delete then re-import the fireblocks account.

docs/11-Seedless.md

@@ -2,7 +2,7 @@
 
 ## Overview
 
-Core integrates CubeSigner to provide Seedless onboarding and sign in functionality. This allows users to sign into Core using their supported OIDC provider such as Google and a choosen MFA device.
+Core integrates CubeSigner to provide Seedless onboarding and sign in functionality. This allows users to sign into Core using their supported OIDC provider such as Google and a chosen MFA device.
 
 ## Resources
 
@@ -17,12 +17,12 @@ Runbook documenting production access, and incident handling procedures: https:/
 
 ## Key management
 
-Tokens are managed strough the Typescript SDK and through the CLI. Both of them do the token refresh process on their own, automatically. To keep the refreshed token up-to-date in the storage, we need to implement our own storage interface and feed it to the SDK.
+Tokens are managed through the Typescript SDK and through the CLI. Both of them do the token refresh process on their own, automatically. To keep the refreshed token up-to-date in the storage, we need to implement our own storage interface and feed it to the SDK.
 During the implementation you will meet 4 types of tokens:
 
 ### OIDC token
 
-OIDC tokens are JWT tokens aquired from the integrated authentication providers like Google. They are used for registration and authentication of the user. Users usually have to be prompted via authentication propups so that they can select the account they want to use. During the onboarding flow they are exchanged for Signer and Management tokens.
+OIDC tokens are JWT tokens aquired from the integrated authentication providers like Google. They are used for registration and authentication of the user. Users usually have to be prompted via authentication popups so that they can select the account they want to use. During the onboarding flow they are exchanged for Signer and Management tokens.
 
 ### Signer session token
 
@@ -34,7 +34,7 @@ Signer session tokens expire either if the session lifetime expires (maximalized
 The two most important tokens in the signer session token are:
 
 - `id_token`: has a very limited lifetime (5 min), used for authentication to CubeSigner
-- `refresh_token`: used for refreshing the `id_token`. When refreshing the `id_token`, the `refresh_token` is also updated. It has a longer (90 day) lifetime. If this token experies, for example Core was not used in the past 90 days, the user has to re-authenticate using OIDC.
+- `refresh_token`: used for refreshing the `id_token`. When refreshing the `id_token`, the `refresh_token` is also updated. It has a longer (90 day) lifetime. If this token expires, for example Core was not used in the past 90 days, the user has to re-authenticate using OIDC.
 
 ### Managment token
 
@@ -45,18 +45,18 @@ They can be aquired either via exchanging the OIDC token and using the configure
 
 ### Limited scoped management token
 
-Used on the backend API. Since the owner's managent token is waay too powerful for an API deployment, we are utilizing a scoped token, which can only do what it absolutely must have to.
+Used on the backend API. Since the owner's management token is way too powerful for an API deployment, we are utilizing a scoped token, which can only do what it absolutely must have to.
 Scopes can be configured, e.g: only allow new user and key creation, but don't allow key re-assignment
 
 ## Onboarding flow
 
 The onboarding flow requires communication with both the Core seedless backend and with CubeSigner.
 
-1. Extension aquires OIDC from Authentication provider
+1. Extension acquires OIDC from Authentication provider
 2. Extension get a Proof of authentication from CubeSigner. This step is required to avoid sending OIDC tokens to our backend directly.
 3. Core Backend verifies the Proof. After verification, it creates the users and the keys for the first account if the user does not exists yet.
 4. For new users, extension exchanges the OIDC token for a signer session token and prompts the user to configure MFA options.
-5. For existing users, the extension prompts the user to use the previously configured MFA device and exchnages the OIDC token for a signer session token.
+5. For existing users, the extension prompts the user to use the previously configured MFA device and exchanges the OIDC token for a signer session token.
 6. Using the session token, extension configures the account list and initializes the seedless wallet.
 
 <img src="images/seedless-onboarding-flow.png" />