Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: Quotation marks are used incorrectly. #23071

Merged
merged 1 commit into from
Dec 26, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion docs/architecture/adr-031-msg-service.md
Original file line number Diff line number Diff line change
Expand Up @@ -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;
Expand Down
2 changes: 1 addition & 1 deletion docs/architecture/adr-033-protobuf-inter-module-comm.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
4 changes: 2 additions & 2 deletions docs/architecture/adr-036-arbitrary-signature.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.

Expand All @@ -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

Expand Down
Loading