chore: update documentation from cosmos-sdk/docs (#248)

cosmos · Dec 29, 2024 · 64d1f0d · 64d1f0d
1 parent 13f593d
commit 64d1f0d
Show file tree

Hide file tree

Showing 5 changed files with 6 additions and 6 deletions.
diff --git a/docs/build/packages/02-collections.md b/docs/build/packages/02-collections.md
@@ -819,7 +819,7 @@ type BaseAccount struct {
 ```
 
 First of all, when we save our accounts in state we map them using a primary key `sdk.AccAddress`.
-If it were to be a `collections.Map` it would be `collections.Map[sdk.AccAddres, authtypes.BaseAccount]`.
+If it were to be a `collections.Map` it would be `collections.Map[sdk.AccAddress, authtypes.BaseAccount]`.
 
 Then we also want to be able to get an account not only by its `sdk.AccAddress`, but also by its `AccountNumber`.
 

diff --git a/versioned_docs/version-0.52/build/architecture/adr-031-msg-service.md b/versioned_docs/version-0.52/build/architecture/adr-031-msg-service.md
@@ -26,7 +26,7 @@ that `Msg` return types be captured using a protobuf extension field, ex:
 package cosmos.gov;
 
 message MsgSubmitProposal
-	option (cosmos_proto.msg_return) = “uint64”;
+	option (cosmos_proto.msg_return) = "uint64";
 	string delegator_address = 1;
 	string validator_address = 2;
 	repeated sdk.Coin amount = 3;

diff --git a/...oned_docs/version-0.52/build/architecture/adr-033-protobuf-inter-module-comm.md b/...oned_docs/version-0.52/build/architecture/adr-033-protobuf-inter-module-comm.md
@@ -43,7 +43,7 @@ own account. These permissions are actually stored as a `[]string` array on the
 However, these permissions don’t really do much. They control what modules can be referenced in the `MintCoins`,
 `BurnCoins` and `DelegateCoins***` methods, but for one there is no unique object capability token that controls access —
 just a simple string. So the `x/upgrade` module could mint tokens for the `x/staking` module simple by calling
-`MintCoins(“staking”)`. Furthermore, all modules which have access to these keeper methods, also have access to
+`MintCoins("staking")`. Furthermore, all modules which have access to these keeper methods, also have access to
 `SetBalance` negating any other attempt at OCAPs and breaking even basic object-oriented encapsulation.
 
 ## Decision

diff --git a/versioned_docs/version-0.52/build/architecture/adr-036-arbitrary-signature.md b/versioned_docs/version-0.52/build/architecture/adr-036-arbitrary-signature.md
@@ -33,7 +33,7 @@ The aim is being able to sign arbitrary messages, even using Ledger or similar H
 
 As a result signed messages should look roughly like Cosmos SDK messages but **must not** be a valid on-chain transaction. `chain-id`, `account_number` and `sequence` can all be assigned invalid values.
 
-Cosmos SDK 0.40 also introduces a concept of “auth_info” this can specify SIGN_MODES.
+Cosmos SDK 0.40 also introduces a concept of "auth_info" this can specify SIGN_MODES.
 
 A spec should include an `auth_info` that supports SIGN_MODE_DIRECT and SIGN_MODE_LEGACY_AMINO.
 
@@ -43,7 +43,7 @@ An offchain transaction follows these rules:
 
 * the memo must be empty
 * nonce, sequence number must be equal to 0
-* chain-id must be equal to “”
+* chain-id must be equal to ""
 * fee gas must be equal to 0
 * fee amount must be an empty array
 

diff --git a/versioned_docs/version-0.52/build/packages/02-collections.md b/versioned_docs/version-0.52/build/packages/02-collections.md
@@ -819,7 +819,7 @@ type BaseAccount struct {
 ```
 
 First of all, when we save our accounts in state we map them using a primary key `sdk.AccAddress`.
-If it were to be a `collections.Map` it would be `collections.Map[sdk.AccAddres, authtypes.BaseAccount]`.
+If it were to be a `collections.Map` it would be `collections.Map[sdk.AccAddress, authtypes.BaseAccount]`.
 
 Then we also want to be able to get an account not only by its `sdk.AccAddress`, but also by its `AccountNumber`.