Typos/fixes

suifrens/suifrens/tests/genesis_tests.move

@@ -288,7 +288,7 @@ module suifrens::genesis_tests {
         //Increase Epoch X+1
         tx_context::increment_epoch_number(ts::ctx(&mut test));
 
-        //Mix Capy Again... This should passs
+        //Mix Capy Again... This should pass
         let _mixedCapy2 = capy_labs::mix(&mut capy_labs, &mut  _mixedCapy, &mut  _capy2, &clock, &mut coin_to_pay_mix2, ts::ctx(&mut test));
 
         sf::test_destroy_admin_cap(admin_cap);

upgrade_policy/quorum_upgrade/README.md

@@ -172,7 +172,7 @@ proper to be able to switch those at will. It's possible that voting for a trans
 is all that will be required, however we are still considering the alternatives.
 
 Shared object deletion is coming very soon, and today the policy protocol is
-not as seemless as it could be if that feature was already available. In
+not as seamless as it could be if that feature was already available. In
 an ideal scenario the `quorum_upgrade_policy::authorize_upgrade` should
 take the `ProposedUpgrade` by value and destroy it. But that does not work
 for now. As soon as shared object deletion is enabled we may decide to
@@ -181,7 +181,7 @@ by value.
 
 Also, and for the same reasons, `quorum_upgrade_policy::destroy_proposed_upgrade`
 will not work right now. However we thought it was important to expose
-that API right now so that once shared object deletion is avaiable,
+that API right now so that once shared object deletion is available,
 `ProposedUpgrade` instances can be deleted and the storage cost recovered.
 
 We are also considering offering an alternative way to vote in a proposal by

upgrade_policy/quorum_upgrade/sources/quorum_upgrade_policy.move

@@ -146,7 +146,7 @@ module quorum_upgrade_policy::quorum_upgrade_policy {
         signer: address,
     }
 
-    /// A succesful upgrade.
+    /// A successful upgrade.
     public struct UpgradePerformed has copy, drop {
         /// The instance of the quorum upgrade policy.
         upgrade_cap: ID,