book: fixed typos

plutus-book/doc/04-smartcont.adoc

@@ -226,7 +226,7 @@ is again to rely on a third party. This time, the contract relies on this
 party for providing the loan money ahead of time. This is not exactly a
 perfectly sensible solution, partially defeating the purpose of the loan -
 if there is a party willing to risk the full value of the loan (interest
-included), and is not benefitting from the contract, why is this loan even
+included), and is not benefiting from the contract, why is this loan even
 necessary?
 
 There is another approach to building smart contract loans and variations thereof.
@@ -299,7 +299,7 @@ In essence, financial contracts are contracts that only deal with the
 transfer of money and promises made about future money transfers.
 These types of contracts are influenced by outside events, like market values
 of stocks, etc. They are also often the result of a real world change of ownership,
-such a a mortgage would be for the purchase of a house.
+such a mortgage would be for the purchase of a house.
 However, there are two main types of tokens they deal with,
 
 * currency,

plutus-book/doc/05-welcome.adoc

@@ -68,7 +68,7 @@ writers.
 Plutus Playground (PP for short) is a tool for writing and testing any code used to build
 smart contracts and define the endpoints for a wallet to be able to engage
 in a contract (for example, pay to a script, obtain a refund, etc.).
-The other main piece of code defined inside the PP editor is the a function
+The other main piece of code defined inside the PP editor is a function
 that generates a script that will be included
 in the body of a transaction generated by the wallet in the extended UTxO model.
 The execution of the contract, driven by time and other external factors,

plutus-book/doc/09-extended.adoc

@@ -293,7 +293,7 @@ any of them.
 In the real Cardano blockchain environment, on- and off-chain
 contract code is meant to be used by all wallets participating in the contract,
 distributed over the network. This means there needs to be another reliable way
-to share Plutus code. The the on-chain code is hashed, and the hash is stored in the
+to share Plutus code. The on-chain code is hashed, and the hash is stored in the
 UTxO, giving the participants a way to verify that it is indeed the right code
 for the right contract. The off-chain code is simply a way to generate
 scripts and transactions, which then get validated and authenticated as

plutus-book/doc/multi/multi.adoc

@@ -58,7 +58,7 @@ outputsAt :: MonadWallet m => Address -> m (Map TxOutRef TxOut)
 ----
 
 Note that `outputsAt` will only return those outputs which are _known
-to the wallet_, i.e. those residing at an adress that is either _watched_
+to the wallet_, i.e. those residing at an address that is either _watched_
 or for which a trigger has been registered.
 ====
 

plutus-book/doc/parameters/crowd.adoc

@@ -36,7 +36,7 @@ Next, let us figure our which types to use for data- and redeemer scripts!
 
 There are two scenarios where people will want to _claim funds from the
 script: The campaign owner _collection_ after a successful campaign
-and the conitrubutors demanding a _refund_ after a failed one.
+and the contributors demanding a _refund_ after a failed one.
 
 For the validator script to decide whether such a claim is valid,
 it has to know which of the two scenarios applies,
@@ -275,7 +275,7 @@ startCampaign ft ed cd = do
 <3> We _collect_ funds.
 
 The second endpoint is for contributors. It allows them to contribute to a
-campaign and wil also register a trigger that checks whether the collection
+campaign and will also register a trigger that checks whether the collection
 deadline has been reached and the funds have not been collected by the owner,
 in which case the contribution is reclaimed: