got the spellcheck

src/basic-syntax/assert-and-abort.md

@@ -40,7 +40,7 @@ The `assert!` macro is a built-in macro that can be used to assert a condition.
 
 ## Error constants
 
-To make error codes more descriptive, it is a good practice to define error constants. Error constants are defined as `const` declarations and are usually prefixed with `E` followed by a camel case name. Error constatns are no different from other constants and don't have special handling. So their addition is purely a practice for better code readability.
+To make error codes more descriptive, it is a good practice to define error constants. Error constants are defined as `const` declarations and are usually prefixed with `E` followed by a camel case name. Error constants are no different from other constants and don't have special handling. So their addition is purely a practice for better code readability.
 
 ```move
 {{#include ../../samples/sources/basic-syntax/assert-and-abort.move:error_const}}

src/basic-syntax/visibility.md

@@ -7,7 +7,7 @@ Every module member has a visibility. By default, all module members are *privat
 A function or a struct defined in a module which has no visibility modifier is *private* to the module. It can't be called from other modules.
 
 ```move
-module book::internal_visbility {
+module book::internal_visibility {
     // This function can be called from other functions in the same module
     fun internal() { /* ... */ }
 
@@ -24,11 +24,11 @@ module book::internal_visbility {
 
 ```move
 module book::try_calling_internal {
-    use book::internal_visbility;
+    use book::internal_visibility;
 
     // Different module -> can't call internal()
     fun try_calling_internal() {
-        internal_visbility::internal();
+        internal_visibility::internal();
     }
 }
 ```

src/hello-sui/module-structure.md

@@ -51,7 +51,7 @@ The function takes the `Postcard` as the first argument and a value of the `addr
 
 ## Keeping the Object
 
-A very common scenario is transfering the object to the caller. This can be done by calling the `send_to` function with the sender address. It can be read from the `ctx` argument, which is a `TxContext` type.
+A very common scenario is transferring the object to the caller. This can be done by calling the `send_to` function with the sender address. It can be read from the `ctx` argument, which is a `TxContext` type.
 
 ```move
 {{#include ../../postcard/sources/postcard.move:keep}}

src/programmability/epoch-and-time.md

@@ -18,7 +18,7 @@ It is also possible to get the unix timestamp of the epoch start:
 {{#include ../../samples/sources/programmability/epoch-and-time.move:epoch_start}}
 ```
 
-Normally, epochs are used in staking and system operations, however, in custom scenarios they can be used to emulate 24h periods. They are cricital if an application relies on the staking logic or needs to know the current validator set.
+Normally, epochs are used in staking and system operations, however, in custom scenarios they can be used to emulate 24h periods. They are critical if an application relies on the staking logic or needs to know the current validator set.
 
 ## Time
 

src/programmability/sui-framework.md

@@ -49,7 +49,7 @@ Just like with [Standard Library](./../basic-syntax/standard-library.md), some o
 Modules:
 
 + sui::address
-- sui::authethicator_state
+- sui::authenticator
 - sui::bag
 - sui::balance
 - sui::bcs
@@ -93,7 +93,7 @@ Modules:
 - sui::ecdsa_r1
 - sui::ecvrf
 - sui::ed25519
-- sui::groth16
+- sui::"groth16"
 - sui::group_ops
 - sui::hash
 - sui::hmac

src/your-first-move/generating-docs.md

@@ -51,7 +51,7 @@ BUILDING Book Samples
 
 > Alternatively, you can use `move test --doc` - this can be useful if you want to test and generate documentation at the same time. For example, as a part of your CI/CD pipeline.
 
-Once the build is complete, the documentation will be available in the `build/docs` directory. Each modile will have its own `.md` file. The documentation for the `hello_world` module will be available in the `build/docs/hello_world.md` file.
+Once the build is complete, the documentation will be available in the `build/docs` directory. Each module will have its own `.md` file. The documentation for the `hello_world` module will be available in the `build/docs/hello_world.md` file.
 
 <details>
 <summary><a style="cursor: pointer">Click to see an example of the `hello_world.md` contents</a></summary>

src/your-first-move/hello-world.md

@@ -39,7 +39,7 @@ hello_world
     Expect the user to know how to use a terminal and a text editor?
 -->
 
-If the output looks like this, then everything is fine, and we can proceed. The folder structure of the package is the folowing:
+If the output looks like this, then everything is fine, and we can proceed. The folder structure of the package is the following:
 
 ```bash
 hello_world