Fix typos

docs/dao/proposals/5.15.mdx

@@ -30,7 +30,7 @@ A discussion in the DAO Meta-Gov working group titled: [Seeking Feedback: ENS Go
 
 Since the time of that PR and during the follow up discussions, the community has asked for the following additions:
 
-- Ensure that the ProposalBond work proposed by Agora works with the new Veto rules and security council. This covers the case of a proposal being vetod from within the timelock therefore making sure we have the code to handle that case. The default case here being that the bond would not be returned.
+- Ensure that the ProposalBond work proposed by Agora works with the new Veto rules and security council. This covers the case of a proposal being vetoed from within the timelock therefore making sure we have the code to handle that case. The default case here being that the bond would not be returned.
 - Work with OpenZeppelin to see if we can bring this functionality into OZ Governance Core
 - Collaborate with ScopeLift to bring in a few sensible defaults to the voting delay period which is currently set to only one block. This leaves the DAO open to attack and the MetaGov working group is agreed on a 24 hour delay to ensure the DAO time to protect itself if needed.
 

docs/dao/proposals/5.16.mdx

@@ -48,4 +48,4 @@ The ENS community, through the passage of EP 5.3, has demonstrated its support f
 
 ---
 
-_Note - When the orignal snapshot for the social vote was posted it was numbered as 5.2, but it should have been 5.3. It has been renumbered in the official ENS documentation. Some links point to forum discussions and Snapshots that show the original duplicitive label of 5.2_
+_Note - When the original snapshot for the social vote was posted it was numbered as 5.2, but it should have been 5.3. It has been renumbered in the official ENS documentation. Some links point to forum discussions and Snapshots that show the original duplicitive label of 5.2_

docs/dao/proposals/5.17.3.mdx

@@ -47,7 +47,7 @@ Subtracting the 89k available to rollover from 2024, the unmet need is 226k USDC
 
 ### Builder Grants
 
-This new category consolidates the exisiting Large and Small grants under one category and program title. The Public Good working group has been working with a provider to create a unified platform which will be announced during frENSday in Bangkok on 11/11/2024. To ensure grantees have consistency, the funds requested for this category carry the program through to Q3 which is an exception from the other spending categories which plan through to April 2025.
+This new category consolidates the existing Large and Small grants under one category and program title. The Public Good working group has been working with a provider to create a unified platform which will be announced during frENSday in Bangkok on 11/11/2024. To ensure grantees have consistency, the funds requested for this category carry the program through to Q3 which is an exception from the other spending categories which plan through to April 2025.
 
 - **Small Grants**  
 Multiple micro-grants will be distributed to builders via the Builder Grants platform to be launched. We have added the amount expected to spend in the next 5 months with the same amounts distributed in the last rounds.

docs/dao/proposals/5.9.mdx

@@ -67,7 +67,7 @@ Meta-Gov sets aside funds to ensure coverage for mission-critical initiatives. W
 ### Description of Initiatives/Pods
 
 - **Steward + Secretary Compensation**: Working Group Steward and Secretary compensation as required by [revised steward working group rules](https://snapshot.org/#/ens.eth/proposal/0x26a5c8dec547837495707e70446d1e7cd874a91f75753c602998f6e70083a266) and [totaling $294,000 USDC to cover the costs for all 9 stewards and supporting roles for a 6 month period](https://discuss.ens.domains/t/ens-dao-steward-compensation/18063).  
-- **Governance**: Fee reimbursements and initiatives related to reducing friction in the governance process. This can also include $ENS distributed in order to lower barriers to the governance proposal process.  The $ENS distributions to stewards and service providers falls into this catagory.
+- **Governance**: Fee reimbursements and initiatives related to reducing friction in the governance process. This can also include $ENS distributed in order to lower barriers to the governance proposal process.  The $ENS distributions to stewards and service providers falls into this category.
 - **DAO Tooling**: Developing interfaces and dashboards to improve the governance process and increase transparency across the DAO. An example of DAO tooling spend is our current engagement with Agora as they help build out an enhanced DAO proposal flow to streamline the proposal process.
 - **Discretionary**: Funds distributed at the discretion of stewards towards new initiatives + governance experiments. In this cycle, we've consolidated the former DAO Sponsorship category into this discretionary category.
 

docs/ensip/19.mdx

@@ -69,7 +69,7 @@ Below is a step-by-step resolution process of ENS reverse resolution. A dapp mus
 8) If the primary name is not the empty string, go to step 11.
 9) If `name` is an empty string, and `coinType` is not 0, set `reverseName = '[address].default.reverse'` and `coinType = 0` and go to step 5.
 10) Otherwise, no primary name exists for this account on this chain; halt and display the address instead.
-11) If the dapp finds an ENS name, it MUST then check the forward resolution. This can be done by using the resolution processs in [ENSIP-10](https://docs.ens.domains/ensip/10). When constructing the ENSIP-10 `resolve()` calldata, encode a call to `addr(bytes32 node, uint256 coinType)`. Set `resolvedAddress` to the result of calling `resolve` on the resolver with this calldata.
+11) If the dapp finds an ENS name, it MUST then check the forward resolution. This can be done by using the resolution process in [ENSIP-10](https://docs.ens.domains/ensip/10). When constructing the ENSIP-10 `resolve()` calldata, encode a call to `addr(bytes32 node, uint256 coinType)`. Set `resolvedAddress` to the result of calling `resolve` on the resolver with this calldata.
 12) If `resolvedAddress == address`, the dapp considers the Primary Name valid, and can now show this instead of the address within the application.
 13) If `resolvedAddress != address` the dapp considers the Primary Name invalid and MUST show the address instead.
 

docs/resolution/names.mdx

@@ -48,7 +48,7 @@ If the name was not able to be normalized, then that method will throw an error.
 
 In the core ENS registry, names are stored as a hash instead of the raw string to optimize for gas, performance, and more. This hashed value is typically referred to as a `node`. The node is a hex-encoded 32-byte value that is derived from the name using the `namehash` algorithm defined in [ENSIP-1](/ensip/1).
 
-Namehash is a recursive algorithm that hashes each part of the name, then hashes the results together. Beacuse recursive functions aren't very efficient in Solidity, it's usually best to derive the namehash offchain and pass to it a contract. Luckily, there are libraries that do this for us.
+Namehash is a recursive algorithm that hashes each part of the name, then hashes the results together. Because recursive functions aren't very efficient in Solidity, it's usually best to derive the namehash offchain and pass to it a contract. Luckily, there are libraries that do this for us.
 
 <CodeGroup title="Calculating Namehash">
 ```tsx {{ title: 'Viem (TS)', language: 'ts', variant: 'viem', link: 'https://viem.sh/docs/ens/utilities/namehash' }}

docs/web/multichain.mdx

@@ -18,13 +18,13 @@ export const meta = {
 The ENS Labs team recently announced our plans and roadmap for scaling ENS to the entire internet and beyond.
 You can read more [on our blog](https://blog.ens.domains/post/ensv2), [on X](https://twitter.com/ensdomains/status/1795440186513576318), and [the forums](https://discuss.ens.domains/t/technical-feedback-thread-for-ensv2/19233).
 The roadmap involves migrating .eth registrations to a new system, in addition to improved support for existing L2 solutions.
-You can findout more on the [changelog](/changelog).
+You can find out more on the [changelog](/changelog).
 
 ## But isn't ENS on mainnet? {{ label: "ENS Multichain", navtitle: "Resolution" }}
 
 Yes, technically. The resolution process always starts on mainnet. There needs to be, one source of truth after all. However, the name
 resolution process can branch off to other chains, offchain gateways and much more.<br />
-To read a more indepth explanation of how resolution works, checkout the [section dedicated to the Resolution Process](/resolution/).
+To read a more in-depth explanation of how resolution works, checkout the [section dedicated to the Resolution Process](/resolution/).
 
 ## My dapp is on X but I want ENS {{ label: "dApp Multichain", navtitle: "dApps on other Chains" }}
 

docs/wrapper/creating-subname-registrar.mdx

@@ -92,7 +92,7 @@ These contracts include two different implementations:
 
 #### Forever Subname Registrar
 
-This is a basic FIFS (First in first serve) registrar. The registration can take a fixed fee, or this fee can be set to 0 if you wish for subnames to be free. Names automatically are set to the parent's expiry can the fuse for `CAN_EXTEND_EXPIRY` will be burnt on registration so the user can extend their expiry if the parent also extends theirs. For a better UX, it is recommened that the parent sets their expiration as high as possible to allow their users to not have to think about renewing.
+This is a basic FIFS (First in first serve) registrar. The registration can take a fixed fee, or this fee can be set to 0 if you wish for subnames to be free. Names automatically are set to the parent's expiry can the fuse for `CAN_EXTEND_EXPIRY` will be burnt on registration so the user can extend their expiry if the parent also extends theirs. For a better UX, it is recommended that the parent sets their expiration as high as possible to allow their users to not have to think about renewing.
 
 #### Rental Subname Registrar