fix:Typo Correction

RELEASE.md

@@ -69,7 +69,7 @@
 
    1. Deploy the verifier contract and schedule the update.
 
-   2. After the timelock delay has passed (7 days on mainnet chains and 1 second on testnet), finsh the operation to add the new verifier to the router.
+   2. After the timelock delay has passed (7 days on mainnet chains and 1 second on testnet), finish the operation to add the new verifier to the router.
 
    3. Run the deployment tests to confirm that the state recorded in `deployment.toml` matches the state of the contracts deployed on-chain.
 

contracts/script/README.md

@@ -26,7 +26,7 @@ Configurations and deployment state information is stored in `deployment.toml`.
 It contains information about each chain (e.g. name, ID, Etherscan URL), and addresses for the timelock, router, and verifier contracts on each chain.
 
 Accompanying the `deployment.toml` file is a `deployment_secrets.toml` file with the following schema.
-It is used to store somewhat sensative API keys for RPC services and Etherscan.
+It is used to store somewhat sensitive API keys for RPC services and Etherscan.
 Note that it does not contain private keys or API keys for Fireblocks.
 It should never be committed to `git`, and the API keys should be rotated if this occurs.
 

examples/governance/README.md

@@ -56,7 +56,7 @@ At a high level, `finalize_votes.rs`:
     }
 ```
 
-This function calls a RISC Zero [verifier contract] to verify the RISC Zero `Groth16Receipt` produced by the prover. If this proof is invalid, the execution will revert within this call, otherwise the [journal] is decoded and the `_finalizeVotes` function within `RiscZeroGovernorCounting.sol` is called. `_finalizeVotes` handles the votes commited to the journal in 100 byte chunks in `votingData`.
+This function calls a RISC Zero [verifier contract] to verify the RISC Zero `Groth16Receipt` produced by the prover. If this proof is invalid, the execution will revert within this call, otherwise the [journal] is decoded and the `_finalizeVotes` function within `RiscZeroGovernorCounting.sol` is called. `_finalizeVotes` handles the votes committed to the journal in 100 byte chunks in `votingData`.
 
 When a user votes, this has both an onchain and an offchain aspect. The vote is processed offchain as seen in [finalize_votes.rs], and onchain `castVote` is called ([RiscZeroGovernor.sol]), which commits the vote by hashing its vote support (a `uint8` representing the vote state, i.e. 1 represents a `for` vote) and the account's address with a hash accumulator of all previous votes.
 

steel/README.md

@@ -24,7 +24,7 @@ You can watch this [video tutorial] for a quick runthrough of using the create-s
 
 ## Documentation
 
-This documentation covers the core concepts of Steel. After reading, you will understand how Steel creates verifiable EVM execution proofs allowing you to carry out execution off-chain verfiably.
+This documentation covers the core concepts of Steel. After reading, you will understand how Steel creates verifiable EVM execution proofs allowing you to carry out execution off-chain verifiably.
 
 - [Introducing Steel 1.0] (blog post)
 - [What is Steel?]

steel/docs/create-steel-app/README.md

@@ -18,7 +18,7 @@ Make sure to have the following installed:
 sh <(curl -fsSL https://raw.githubusercontent.com/risc0/risc0-ethereum/refs/heads/main/steel/docs/create-steel-app/create-steel-app)
 ```
 
-The script will automatically detect your current `cargo-risczero` version and use that for the corresponding version of the `erc20-counter` example. You also have the manual choice between between two release versions: [1.0] and [1.1].
+The script will automatically detect your current `cargo-risczero` version and use that for the corresponding version of the `erc20-counter` example. You also have the manual choice between two release versions: [1.0] and [1.1].
 
 Once the script is finished running, you should:
 

steel/docs/what-is-steel.md

@@ -61,7 +61,7 @@ contract OffChainERC20Counter() {
 
 To make sure that Steel's execution proofs can be trusted, we check the output of the zkVM program to make sure that the token contract address is correct, and we validate the [Steel Commitment]. Only if these are valid, the proof is verified. Upon successful verification, we can be sure that the account balance is larger than 1 and we increment the counter variable. Notice there is no check on-chain of the balance or any EVM execution other than the validations and proof verification. The EVM execution happens within the zkVM guest program.
 
-In [How does Steel work?], we dive deeper into how exactly the zkVM guest program verifies state access and runs EVM execution, generating an smart contract execution proof, and verifying the proof on-chain.
+In [How does Steel work?], we dive deeper into how exactly the zkVM guest program verifies state access and runs EVM execution, generating a smart contract execution proof, and verifying the proof on-chain.
 
 ---