docs: Improve markdownlint configuration (#11104)

## Description Closes: #9404 --- ### Author Checklist *All items are required. Please add a note to the item if the item is not applicable and please add links to any relevant follow up issues.* I have... - [x] included the correct [type prefix](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title - [ ] added `!` to the type prefix if API or client breaking change - [x] targeted the correct branch (see [PR Targeting](https://github.com/cosmos/cosmos-sdk/blob/master/CONTRIBUTING.md#pr-targeting)) - [x] provided a link to the relevant issue or specification - [ ] followed the guidelines for [building modules](https://github.com/cosmos/cosmos-sdk/blob/master/docs/building-modules) - [ ] included the necessary unit and integration [tests](https://github.com/cosmos/cosmos-sdk/blob/master/CONTRIBUTING.md#testing) - [ ] added a changelog entry to `CHANGELOG.md` - [ ] included comments for [documenting Go code](https://blog.golang.org/godoc) - [ ] updated the relevant documentation or specification - [x] reviewed "Files changed" and left comments if necessary - [x] confirmed all CI checks have passed ### Reviewers Checklist *All items are required. Please add a note if the item is not applicable and please add your handle next to the items reviewed if you only reviewed selected items.* I have... - [ ] confirmed the correct [type prefix](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title - [ ] confirmed `!` in the type prefix if API or client breaking change - [ ] confirmed all author checklist items have been addressed - [ ] reviewed state machine logic - [ ] reviewed API design and naming - [ ] reviewed documentation is accurate - [ ] reviewed tests and test coverage - [ ] manually tested (if applicable)
2022-02-10 12:07:01 +00:00
parent b1f9a117f7
commit 58597139fa
212 changed files with 3792 additions and 3755 deletions
@@ -26,7 +26,7 @@ ADR creation is an **iterative** process. Instead of trying to solve all decisio

 Status has two components:

-```
+```text
 {CONSENSUS STATUS} {IMPLEMENTATION STATUS}
 ```

@@ -34,7 +34,7 @@ IMPLEMENTATION STATUS is either `Implemented` or `Not Implemented`.

 #### Consensus Status

-```
+```text
 DRAFT -> PROPOSED -> LAST CALL yyyy-mm-dd -> ACCEPTED | REJECTED -> SUPERSEDED by ADR-xxx
                  \        |
                   \       |
@@ -42,15 +42,15 @@ DRAFT -> PROPOSED -> LAST CALL yyyy-mm-dd -> ACCEPTED | REJECTED -> SUPERSEDED b
                     ABANDONED
 ```

-+ `DRAFT`: [optional] an ADR which is work in progress, not being ready for a general review. This is to present an early work and get an early feedback in a Draft Pull Request form.
-+ `PROPOSED`: an ADR covering a full solution architecture and still in the review - project stakeholders haven't reached an agreed yet.
-+ `LAST CALL <date for the last call>`: [optional] clear notify that we are close to accept updates. Changing a status to `LAST CALL` means that social consensus (of Cosmos SDK maintainers) has been reached and we still want to give it a time to let the community react or analyze.
-+ `ACCEPTED`: ADR which will represent a currently implemented or to be implemented architecture design.
-+ `REJECTED`: ADR can go from PROPOSED or ACCEPTED to rejected if the consensus among project stakeholders will decide so.
-+ `SUPERSEEDED by ADR-xxx`: ADR which has been superseded by a new ADR.
-+ `ABANDONED`: the ADR is no longer pursued by the original authors.
+* `DRAFT`: [optional] an ADR which is work in progress, not being ready for a general review. This is to present an early work and get an early feedback in a Draft Pull Request form.
+* `PROPOSED`: an ADR covering a full solution architecture and still in the review - project stakeholders haven't reached an agreed yet.
+* `LAST CALL <date for the last call>`: [optional] clear notify that we are close to accept updates. Changing a status to `LAST CALL` means that social consensus (of Cosmos SDK maintainers) has been reached and we still want to give it a time to let the community react or analyze.
+* `ACCEPTED`: ADR which will represent a currently implemented or to be implemented architecture design.
+* `REJECTED`: ADR can go from PROPOSED or ACCEPTED to rejected if the consensus among project stakeholders will decide so.
+* `SUPERSEEDED by ADR-xxx`: ADR which has been superseded by a new ADR.
+* `ABANDONED`: the ADR is no longer pursued by the original authors.

 ## Language used in ADR

-+ The context/background should be written in the present tense.
-+ Avoid using a first, personal form.
+* The context/background should be written in the present tense.
+* Avoid using a first, personal form.
@@ -19,11 +19,11 @@ You can read more about the ADR concept in this [blog post](https://product.reve
 ADRs are intended to be the primary mechanism for proposing new feature designs and new processes, for collecting community input on an issue, and for documenting the design decisions.
 An ADR should provide:

- Context on the relevant goals and the current state
- Proposed changes to achieve the goals
- Summary of pros and cons
- References
- Changelog
+* Context on the relevant goals and the current state
+* Proposed changes to achieve the goals
+* Summary of pros and cons
+* References
+* Changelog

 Note the distinction between an ADR and a spec. The ADR provides the context, intuition, reasoning, and
 justification for a change in architecture, or for the architecture of something
@@ -36,7 +36,7 @@ If recorded decisions turned out to be lacking, convene a discussion, record the

 Read about the [PROCESS](./PROCESS.md).

-#### Use RFC 2119 Keywords
+### Use RFC 2119 Keywords

 When writing ADRs, follow the same best practices for writing RFCs. When writing RFCs, key words are used to signify the requirements in the specification. These words are often capitalized: "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL. They are to be interpreted as described in [RFC 2119](https://datatracker.ietf.org/doc/html/rfc2119).

@@ -44,41 +44,41 @@ When writing ADRs, follow the same best practices for writing RFCs. When writing

 ### Accepted

- [ADR 002: SDK Documentation Structure](./adr-002-docs-structure.md)
- [ADR 004: Split Denomination Keys](./adr-004-split-denomination-keys.md)
- [ADR 006: Secret Store Replacement](./adr-006-secret-store-replacement.md)
- [ADR 009: Evidence Module](./adr-009-evidence-module.md)
- [ADR 010: Modular AnteHandler](./adr-010-modular-antehandler.md)
- [ADR 019: Protocol Buffer State Encoding](./adr-019-protobuf-state-encoding.md)
- [ADR 020: Protocol Buffer Transaction Encoding](./adr-020-protobuf-transaction-encoding.md)
- [ADR 021: Protocol Buffer Query Encoding](./adr-021-protobuf-query-encoding.md)
- [ADR 023: Protocol Buffer Naming and Versioning](./adr-023-protobuf-naming.md)
- [ADR 029: Fee Grant Module](./adr-029-fee-grant-module.md)
- [ADR 030: Message Authorization Module](./adr-030-authz-module.md)
- [ADR 031: Protobuf Msg Services](./adr-031-msg-service.md)
+* [ADR 002: SDK Documentation Structure](./adr-002-docs-structure.md)
+* [ADR 004: Split Denomination Keys](./adr-004-split-denomination-keys.md)
+* [ADR 006: Secret Store Replacement](./adr-006-secret-store-replacement.md)
+* [ADR 009: Evidence Module](./adr-009-evidence-module.md)
+* [ADR 010: Modular AnteHandler](./adr-010-modular-antehandler.md)
+* [ADR 019: Protocol Buffer State Encoding](./adr-019-protobuf-state-encoding.md)
+* [ADR 020: Protocol Buffer Transaction Encoding](./adr-020-protobuf-transaction-encoding.md)
+* [ADR 021: Protocol Buffer Query Encoding](./adr-021-protobuf-query-encoding.md)
+* [ADR 023: Protocol Buffer Naming and Versioning](./adr-023-protobuf-naming.md)
+* [ADR 029: Fee Grant Module](./adr-029-fee-grant-module.md)
+* [ADR 030: Message Authorization Module](./adr-030-authz-module.md)
+* [ADR 031: Protobuf Msg Services](./adr-031-msg-service.md)

 ### Proposed

- [ADR 003: Dynamic Capability Store](./adr-003-dynamic-capability-store.md)
- [ADR 011: Generalize Genesis Accounts](./adr-011-generalize-genesis-accounts.md)
- [ADR 012: State Accessors](./adr-012-state-accessors.md)
- [ADR 013: Metrics](./adr-013-metrics.md)
- [ADR 016: Validator Consensus Key Rotation](./adr-016-validator-consensus-key-rotation.md)
- [ADR 017: Historical Header Module](./adr-017-historical-header-module.md)
- [ADR 018: Extendable Voting Periods](./adr-018-extendable-voting-period.md)
- [ADR 022: Custom baseapp panic handling](./adr-022-custom-panic-handling.md)
- [ADR 024: Coin Metadata](./adr-024-coin-metadata.md)
- [ADR 027: Deterministic Protobuf Serialization](./adr-027-deterministic-protobuf-serialization.md)
- [ADR 028: Public Key Addresses](./adr-028-public-key-addresses.md)
- [ADR 032: Typed Events](./adr-032-typed-events.md)
- [ADR 033: Inter-module RPC](./adr-033-protobuf-inter-module-comm.md)
- [ADR 035: Rosetta API Support](./adr-035-rosetta-api-support.md)
- [ADR 037: Governance Split Votes](./adr-037-gov-split-vote.md)
- [ADR 038: State Listening](./adr-038-state-listening.md)
- [ADR 039: Epoched Staking](./adr-039-epoched-staking.md)
- [ADR 040: Storage and SMT State Commitments](./adr-040-storage-and-smt-state-commitments.md)
- [ADR 046: Module Params](./adr-046-module-params.md)
+* [ADR 003: Dynamic Capability Store](./adr-003-dynamic-capability-store.md)
+* [ADR 011: Generalize Genesis Accounts](./adr-011-generalize-genesis-accounts.md)
+* [ADR 012: State Accessors](./adr-012-state-accessors.md)
+* [ADR 013: Metrics](./adr-013-metrics.md)
+* [ADR 016: Validator Consensus Key Rotation](./adr-016-validator-consensus-key-rotation.md)
+* [ADR 017: Historical Header Module](./adr-017-historical-header-module.md)
+* [ADR 018: Extendable Voting Periods](./adr-018-extendable-voting-period.md)
+* [ADR 022: Custom baseapp panic handling](./adr-022-custom-panic-handling.md)
+* [ADR 024: Coin Metadata](./adr-024-coin-metadata.md)
+* [ADR 027: Deterministic Protobuf Serialization](./adr-027-deterministic-protobuf-serialization.md)
+* [ADR 028: Public Key Addresses](./adr-028-public-key-addresses.md)
+* [ADR 032: Typed Events](./adr-032-typed-events.md)
+* [ADR 033: Inter-module RPC](./adr-033-protobuf-inter-module-comm.md)
+* [ADR 035: Rosetta API Support](./adr-035-rosetta-api-support.md)
+* [ADR 037: Governance Split Votes](./adr-037-gov-split-vote.md)
+* [ADR 038: State Listening](./adr-038-state-listening.md)
+* [ADR 039: Epoched Staking](./adr-039-epoched-staking.md)
+* [ADR 040: Storage and SMT State Commitments](./adr-040-storage-and-smt-state-commitments.md)
+* [ADR 046: Module Params](./adr-046-module-params.md)

 ### Draft

- [ADR 044: Guidelines for Updating Protobuf Definitions](./adr-044-protobuf-updates-guidelines.md)
+* [ADR 044: Guidelines for Updating Protobuf Definitions](./adr-044-protobuf-updates-guidelines.md)
@@ -6,14 +6,14 @@ There is a need for a scalable structure of the Cosmos SDK documentation. Curren

 Ideally, we would have:

- All docs related to dev frameworks or tools live in their respective github repos (sdk repo would contain sdk docs, hub repo would contain hub docs, lotion repo would contain lotion docs, etc.)
- All other docs (faqs, whitepaper, high-level material about Cosmos) would live on the website.
+* All docs related to dev frameworks or tools live in their respective github repos (sdk repo would contain sdk docs, hub repo would contain hub docs, lotion repo would contain lotion docs, etc.)
+* All other docs (faqs, whitepaper, high-level material about Cosmos) would live on the website.

 ## Decision

 Re-structure the `/docs` folder of the Cosmos SDK github repo as follows:

-```
+```text
 docs/
 ├── README
 ├── intro/
@@ -39,21 +39,21 @@ docs/

 The files in each sub-folders do not matter and will likely change. What matters is the sectioning:

- `README`: Landing page of the docs.
- `intro`: Introductory material. Goal is to have a short explainer of the Cosmos SDK and then channel people to the resource they need. The [Cosmos SDK tutorial](https://github.com/cosmos/sdk-application-tutorial/) will be highlighted, as well as the `godocs`.
- `concepts`: Contains high-level explanations of the abstractions of the Cosmos SDK. It does not contain specific code implementation and does not need to be updated often. **It is not an API specification of the interfaces**. API spec is the `godoc`.
- `clients`: Contains specs and info about the various Cosmos SDK clients.
- `spec`: Contains specs of modules, and others.
- `modules`: Contains links to `godocs` and the spec of the modules.
- `architecture`: Contains architecture-related docs like the present one.
- `translations`: Contains different translations of the documentation.
+* `README`: Landing page of the docs.
+* `intro`: Introductory material. Goal is to have a short explainer of the Cosmos SDK and then channel people to the resource they need. The [Cosmos SDK tutorial](https://github.com/cosmos/sdk-application-tutorial/) will be highlighted, as well as the `godocs`.
+* `concepts`: Contains high-level explanations of the abstractions of the Cosmos SDK. It does not contain specific code implementation and does not need to be updated often. **It is not an API specification of the interfaces**. API spec is the `godoc`.
+* `clients`: Contains specs and info about the various Cosmos SDK clients.
+* `spec`: Contains specs of modules, and others.
+* `modules`: Contains links to `godocs` and the spec of the modules.
+* `architecture`: Contains architecture-related docs like the present one.
+* `translations`: Contains different translations of the documentation.

 Website docs sidebar will only include the following sections:

- `README`
- `intro`
- `concepts`
- `clients`
+* `README`
+* `intro`
+* `concepts`
+* `clients`

 `architecture` need not be displayed on the website.

@@ -65,22 +65,22 @@ Accepted

 ### Positive

- Much clearer organisation of the Cosmos SDK docs.
- The `/docs` folder now only contains Cosmos SDK and gaia related material. Later, it will only contain Cosmos SDK related material.
- Developers only have to update `/docs` folder when they open a PR (and not `/examples` for example).
- Easier for developers to find what they need to update in the docs thanks to reworked architecture.
- Cleaner vuepress build for website docs.
- Will help build an executable doc (cf https://github.com/cosmos/cosmos-sdk/issues/2611)
+* Much clearer organisation of the Cosmos SDK docs.
+* The `/docs` folder now only contains Cosmos SDK and gaia related material. Later, it will only contain Cosmos SDK related material.
+* Developers only have to update `/docs` folder when they open a PR (and not `/examples` for example).
+* Easier for developers to find what they need to update in the docs thanks to reworked architecture.
+* Cleaner vuepress build for website docs.
+* Will help build an executable doc (cf <https://github.com/cosmos/cosmos-sdk/issues/2611>)

 ### Neutral

- We need to move a bunch of deprecated stuff to `/_attic` folder.
- We need to integrate content in `docs/sdk/docs/core` in `concepts`.
- We need to move all the content that currently lives in `docs` and does not fit in new structure (like `lotion`, intro material, whitepaper) to the website repository.
- Update `DOCS_README.md`
+* We need to move a bunch of deprecated stuff to `/_attic` folder.
+* We need to integrate content in `docs/sdk/docs/core` in `concepts`.
+* We need to move all the content that currently lives in `docs` and does not fit in new structure (like `lotion`, intro material, whitepaper) to the website repository.
+* Update `DOCS_README.md`

 ## References

- https://github.com/cosmos/cosmos-sdk/issues/1460
- https://github.com/cosmos/cosmos-sdk/pull/2695
- https://github.com/cosmos/cosmos-sdk/issues/2611
+* <https://github.com/cosmos/cosmos-sdk/issues/1460>
+* <https://github.com/cosmos/cosmos-sdk/pull/2695>
+* <https://github.com/cosmos/cosmos-sdk/issues/2611>
@@ -2,8 +2,8 @@

 ## Changelog

- 12 December 2019: Initial version
- 02 April 2020: Memory Store Revisions
+* 12 December 2019: Initial version
+* 02 April 2020: Memory Store Revisions

 ## Context

@@ -326,14 +326,14 @@ Proposed.

 ### Positive

- Dynamic capability support.
- Allows CapabilityKeeper to return same capability pointer from go-map while reverting any writes to the persistent `KVStore` and in-memory `MemoryStore` on tx failure.
+* Dynamic capability support.
+* Allows CapabilityKeeper to return same capability pointer from go-map while reverting any writes to the persistent `KVStore` and in-memory `MemoryStore` on tx failure.

 ### Negative

- Requires an additional keeper.
- Some overlap with existing `StoreKey` system (in the future they could be combined, since this is a superset functionality-wise).
- Requires an extra level of indirection in the reverse mapping, since MemoryStore must map to index which must then be used as key in a go map to retrieve the actual capability
+* Requires an additional keeper.
+* Some overlap with existing `StoreKey` system (in the future they could be combined, since this is a superset functionality-wise).
+* Requires an extra level of indirection in the reverse mapping, since MemoryStore must map to index which must then be used as key in a go map to retrieve the actual capability

 ### Neutral

@@ -341,4 +341,4 @@ Proposed.

 ## References

- [Original discussion](https://github.com/cosmos/cosmos-sdk/pull/5230#discussion_r343978513)
+* [Original discussion](https://github.com/cosmos/cosmos-sdk/pull/5230#discussion_r343978513)
@@ -2,10 +2,10 @@

 ## Changelog

- 2020-01-08: Initial version
- 2020-01-09: Alterations to handle vesting accounts
- 2020-01-14: Updates from review feedback
- 2020-01-30: Updates from implementation
+* 2020-01-08: Initial version
+* 2020-01-09: Alterations to handle vesting accounts
+* 2020-01-14: Updates from review feedback
+* 2020-01-30: Updates from implementation

 ### Glossary

@@ -38,11 +38,11 @@ vesting coins (which is safe since these cannot contain arbitrary denominations)

 The following APIs will be added to the `x/bank` keeper:

- `GetAllBalances(ctx Context, addr AccAddress) Coins`
- `GetBalance(ctx Context, addr AccAddress, denom string) Coin`
- `SetBalance(ctx Context, addr AccAddress, coin Coin)`
- `LockedCoins(ctx Context, addr AccAddress) Coins`
- `SpendableCoins(ctx Context, addr AccAddress) Coins`
+* `GetAllBalances(ctx Context, addr AccAddress) Coins`
+* `GetBalance(ctx Context, addr AccAddress, denom string) Coin`
+* `SetBalance(ctx Context, addr AccAddress, coin Coin)`
+* `LockedCoins(ctx Context, addr AccAddress) Coins`
+* `SpendableCoins(ctx Context, addr AccAddress) Coins`

 Additional APIs may be added to facilitate iteration and auxiliary functionality not essential to
 core functionality or persistence.
@@ -100,13 +100,13 @@ Accepted.

 ### Positive

- O(1) reads & writes of balances (with respect to the number of denominations for
+* O(1) reads & writes of balances (with respect to the number of denominations for
 which an account has non-zero balances). Note, this does not relate to the actual
 I/O cost, rather the total number of direct reads needed.

 ### Negative

- Slightly less efficient reads/writes when reading & writing all balances of a
+* Slightly less efficient reads/writes when reading & writing all balances of a
 single account in a transaction.

 ### Neutral
@@ -115,6 +115,6 @@ None in particular.

 ## References

- Ref: https://github.com/cosmos/cosmos-sdk/issues/4982
- Ref: https://github.com/cosmos/cosmos-sdk/issues/5467
- Ref: https://github.com/cosmos/cosmos-sdk/issues/5492
+* Ref: <https://github.com/cosmos/cosmos-sdk/issues/4982>
+* Ref: <https://github.com/cosmos/cosmos-sdk/issues/5467>
+* Ref: <https://github.com/cosmos/cosmos-sdk/issues/5492>
@@ -2,10 +2,10 @@

 ## Changelog

- July 29th, 2019: Initial draft
- September 11th, 2019: Work has started
- November 4th: Cosmos SDK changes merged in
- November 18th: Gaia changes merged in
+* July 29th, 2019: Initial draft
+* September 11th, 2019: Work has started
+* November 4th: Cosmos SDK changes merged in
+* November 18th: Gaia changes merged in

 ## Context

@@ -47,8 +47,8 @@ Running tests locally on a Mac require numerous repetitive password entries.

 ## References

- #4754 Switch secret store to the keyring secret store (original PR by @poldsam) [__CLOSED__]
- #5029 Add support for github.com/99designs/keyring-backed keybases [__MERGED__]
- #5097 Add keys migrate command [__MERGED__]
- #5180 Drop on-disk keybase in favor of keyring [_PENDING_REVIEW_]
- cosmos/gaia#164 Drop on-disk keybase in favor of keyring (gaia's changes) [_PENDING_REVIEW_]
+* #4754 Switch secret store to the keyring secret store (original PR by @poldsam) [__CLOSED__]
+* #5029 Add support for github.com/99designs/keyring-backed keybases [__MERGED__]
+* #5097 Add keys migrate command [__MERGED__]
+* #5180 Drop on-disk keybase in favor of keyring [_PENDING_REVIEW_]
+* cosmos/gaia#164 Drop on-disk keybase in favor of keyring (gaia's changes) [_PENDING_REVIEW_]
@@ -2,7 +2,7 @@

 ## Changelog

- 2019 Jul 31: Initial Draft
+* 2019 Jul 31: Initial Draft

 ## Context

@@ -26,22 +26,22 @@ governance proposals include a field for issue type.
 A specialization group can be broadly broken down into the following functions
 (herein containing examples):

- Membership Admittance
- Membership Acceptance
- Membership Revocation
-    - (probably) Without Penalty
-        - member steps down (self-Revocation)
-        - replaced by new member from governance
-    - (probably) With Penalty
-        - due to breach of soft-agreement (determined through governance)
-        - due to breach of hard-agreement (determined by code)
- Execution of Duties
-    - Special transactions which only execute for members of a specialization
+* Membership Admittance
+* Membership Acceptance
+* Membership Revocation
+    * (probably) Without Penalty
+        * member steps down (self-Revocation)
+        * replaced by new member from governance
+    * (probably) With Penalty
+        * due to breach of soft-agreement (determined through governance)
+        * due to breach of hard-agreement (determined by code)
+* Execution of Duties
+    * Special transactions which only execute for members of a specialization
     group (for example, dCERT members voting to turn off transaction routes in
     an emergency scenario)
- Compensation
-    - Group compensation (further distribution decided by the specialization group)
-    - Individual compensation for all constituents of a group from the
+* Compensation
+    * Group compensation (further distribution decided by the specialization group)
+    * Individual compensation for all constituents of a group from the
     greater community

 Membership admittance to a specialization group could take place over a wide
@@ -163,15 +163,15 @@ type SpecializationGroup interface {

 ### Positive

- increases specialization capabilities of a blockchain
- improve abstractions in `x/gov/` such that they can be used with specialization groups
+* increases specialization capabilities of a blockchain
+* improve abstractions in `x/gov/` such that they can be used with specialization groups

 ### Negative

- could be used to increase centralization within a community
+* could be used to increase centralization within a community

 ### Neutral

 ## References

- [dCERT ADR](./adr-008-dCERT-group.md)
+* [dCERT ADR](./adr-008-dCERT-group.md)
@@ -2,7 +2,7 @@

 ## Changelog

- 2019 Jul 31: Initial Draft
+* 2019 Jul 31: Initial Draft

 ## Context

@@ -35,22 +35,22 @@ The dCERT group is proposed to include an implementation of a `SpecializationGro
 as defined in [ADR 007](./adr-007-specialization-groups.md). This will include the
 implementation of:

- continuous voting
- slashing due to breach of soft contract
- revoking a member due to breach of soft contract
- emergency disband of the entire dCERT group (ex. for colluding maliciously)
- compensation stipend from the community pool or other means decided by
+* continuous voting
+* slashing due to breach of soft contract
+* revoking a member due to breach of soft contract
+* emergency disband of the entire dCERT group (ex. for colluding maliciously)
+* compensation stipend from the community pool or other means decided by
   governance

 This system necessitates the following new parameters:

- blockly stipend allowance per dCERT member
- maximum number of dCERT members
- required staked slashable tokens for each dCERT member
- quorum for suspending a particular member
- proposal wager for disbanding the dCERT group
- stabilization period for dCERT member transition
- circuit break dCERT privileges enabled
+* blockly stipend allowance per dCERT member
+* maximum number of dCERT members
+* required staked slashable tokens for each dCERT member
+* quorum for suspending a particular member
+* proposal wager for disbanding the dCERT group
+* stabilization period for dCERT member transition
+* circuit break dCERT privileges enabled

 These parameters are expected to be implemented through the param keeper such
 that governance may change them at any given point.
@@ -60,27 +60,27 @@ that governance may change them at any given point.
 An `Electionator` object is to be implemented as continuous voting and with the
 following specifications:

- All delegation addresses may submit votes at any point which updates their
+* All delegation addresses may submit votes at any point which updates their
   preferred representation on the dCERT group.
- Preferred representation may be arbitrarily split between addresses (ex. 50%
+* Preferred representation may be arbitrarily split between addresses (ex. 50%
   to John, 25% to Sally, 25% to Carol)
- In order for a new member to be added to the dCERT group they must
+* In order for a new member to be added to the dCERT group they must
   send a transaction accepting their admission at which point the validity of
   their admission is to be confirmed.
-    - A sequence number is assigned when a member is added to dCERT group.
+    * A sequence number is assigned when a member is added to dCERT group.
     If a member leaves the dCERT group and then enters back, a new sequence number
     is assigned.  
- Addresses which control the greatest amount of preferred-representation are
+* Addresses which control the greatest amount of preferred-representation are
   eligible to join the dCERT group (up the _maximum number of dCERT members_).
   If the dCERT group is already full and new member is admitted, the existing
   dCERT member with the lowest amount of votes is kicked from the dCERT group.
-    - In the split situation where the dCERT group is full but a vying candidate
+    * In the split situation where the dCERT group is full but a vying candidate
     has the same amount of vote as an existing dCERT member, the existing
     member should maintain its position.
-    - In the split situation where somebody must be kicked out but the two
+    * In the split situation where somebody must be kicked out but the two
     addresses with the smallest number of votes have the same number of votes,
     the address with the smallest sequence number maintains its position.  
- A stabilization period can be optionally included to reduce the
+* A stabilization period can be optionally included to reduce the
   "flip-flopping" of the dCERT membership tail members. If a stabilization
   period is provided which is greater than 0, when members are kicked due to
   insufficient support, a queue entry is created which documents which member is
@@ -128,9 +128,9 @@ capable of shutting down the exploitable message routes.

 Active dCERT members

- change of the description of the dCERT group
- circuit break a message route
- vote to suspend a dCERT member.
+* change of the description of the dCERT group
+* circuit break a message route
+* vote to suspend a dCERT member.

 Here circuit-breaking refers to the capability to disable a groups of messages,
 This could for instance mean: "disable all staking-delegation messages", or
@@ -157,12 +157,12 @@ they should all be severely slashed.

 ### Positive

- Potential to reduces the number of parties to coordinate with during an emergency
- Reduction in possibility of disclosing sensitive information to malicious parties
+* Potential to reduces the number of parties to coordinate with during an emergency
+* Reduction in possibility of disclosing sensitive information to malicious parties

 ### Negative

- Centralization risks
+* Centralization risks

 ### Neutral

@@ -2,8 +2,8 @@

 ## Changelog

- 2019 July 31: Initial draft
- 2019 October 24: Initial implementation
+* 2019 July 31: Initial draft
+* 2019 October 24: Initial implementation

 ## Status

@@ -27,14 +27,14 @@ chain so that the equivocating validator(s) can be slashed.
 We will implement an evidence module in the Cosmos SDK supporting the following
 functionality:

- Provide developers with the abstractions and interfaces necessary to define
+* Provide developers with the abstractions and interfaces necessary to define
  custom evidence messages, message handlers, and methods to slash and penalize
  accordingly for misbehavior.
- Support the ability to route evidence messages to handlers in any module to
+* Support the ability to route evidence messages to handlers in any module to
  determine the validity of submitted misbehavior.
- Support the ability, through governance, to modify slashing penalties of any
+* Support the ability, through governance, to modify slashing penalties of any
  evidence type.
- Querier implementation to support querying params, evidence types, params, and
+* Querier implementation to support querying params, evidence types, params, and
  all submitted valid misbehavior.

 ### Types
@@ -160,23 +160,23 @@ type GenesisState struct {

 ### Positive

- Allows the state machine to process misbehavior submitted on-chain and penalize
+* Allows the state machine to process misbehavior submitted on-chain and penalize
  validators based on agreed upon slashing parameters.
- Allows evidence types to be defined and handled by any module. This further allows
+* Allows evidence types to be defined and handled by any module. This further allows
  slashing and jailing to be defined by more complex mechanisms.
- Does not solely rely on Tendermint to submit evidence.
+* Does not solely rely on Tendermint to submit evidence.

 ### Negative

- No easy way to introduce new evidence types through governance on a live chain
+* No easy way to introduce new evidence types through governance on a live chain
  due to the inability to introduce the new evidence type's corresponding handler

 ### Neutral

- Should we persist infractions indefinitely? Or should we rather rely on events?
+* Should we persist infractions indefinitely? Or should we rather rely on events?

 ## References

- [ICS](https://github.com/cosmos/ics)
- [IBC Architecture](https://github.com/cosmos/ics/blob/master/ibc/1_IBC_ARCHITECTURE.md)
- [Tendermint Fork Accountability](https://github.com/tendermint/spec/blob/7b3138e69490f410768d9b1ffc7a17abc23ea397/spec/consensus/fork-accountability.md)
+* [ICS](https://github.com/cosmos/ics)
+* [IBC Architecture](https://github.com/cosmos/ics/blob/master/ibc/1_IBC_ARCHITECTURE.md)
+* [Tendermint Fork Accountability](https://github.com/tendermint/spec/blob/7b3138e69490f410768d9b1ffc7a17abc23ea397/spec/consensus/fork-accountability.md)
@@ -2,8 +2,8 @@

 ## Changelog

- 2019 Aug 31: Initial draft
- 2021 Sep 14: Superseded by ADR-045
+* 2019 Aug 31: Initial draft
+* 2021 Sep 14: Superseded by ADR-045

 ## Status

@@ -284,7 +284,7 @@ Since pros and cons are written for each approach, it is omitted from this secti

 ## References

- [#4572](https://github.com/cosmos/cosmos-sdk/issues/4572):  Modular AnteHandler Issue
- [#4582](https://github.com/cosmos/cosmos-sdk/pull/4583): Initial Implementation of Per-Module AnteHandler Approach
- [Weave Decorator Code](https://github.com/iov-one/weave/blob/master/handler.go#L35)
- [Weave Design Videos](https://vimeo.com/showcase/6189877)
+* [#4572](https://github.com/cosmos/cosmos-sdk/issues/4572):  Modular AnteHandler Issue
+* [#4582](https://github.com/cosmos/cosmos-sdk/pull/4583): Initial Implementation of Per-Module AnteHandler Approach
+* [Weave Decorator Code](https://github.com/iov-one/weave/blob/master/handler.go#L35)
+* [Weave Design Videos](https://vimeo.com/showcase/6189877)
@@ -2,7 +2,7 @@

 ## Changelog

- 2019-08-30: initial draft
+* 2019-08-30: initial draft

 ## Context

@@ -145,8 +145,8 @@ This will be moved to `auth`. We will leave it to projects to write their own co

 Under the new scheme, module and vesting account types need some minor updates:

- Type registration on `auth`'s codec (shown above)
- A `Validate` method for each `Account` concrete type
+* Type registration on `auth`'s codec (shown above)
+* A `Validate` method for each `Account` concrete type

 ## Status

@@ -156,15 +156,15 @@ Proposed

 ### Positive

- custom accounts can be used without needing to fork `genaccounts`
- reduction in lines of code
+* custom accounts can be used without needing to fork `genaccounts`
+* reduction in lines of code

 ### Negative

 ### Neutral

- `genaccounts` module no longer exists
- accounts in genesis files are stored under `accounts` in `auth` rather than in the `genaccounts` module.
+* `genaccounts` module no longer exists
+* accounts in genesis files are stored under `accounts` in `auth` rather than in the `genaccounts` module.
 -`add-genesis-account` cli command now in `auth`

 ## References
@@ -2,7 +2,7 @@

 ## Changelog

- 2019 Sep 04: Initial draft
+* 2019 Sep 04: Initial draft

 ## Context

@@ -125,9 +125,9 @@ Where the `key` argument in core method is typed.

 Some of the properties of the accessor types are:

- State access happens only when a function which takes a `Context` as an argument is invoked
- Accessor type structs give rights to access the state only that the struct is referring, no other
- Marshalling/Unmarshalling happens implicitly within the core methods
+* State access happens only when a function which takes a `Context` as an argument is invoked
+* Accessor type structs give rights to access the state only that the struct is referring, no other
+* Marshalling/Unmarshalling happens implicitly within the core methods

 ## Status

@@ -137,19 +137,19 @@ Proposed

 ### Positive

- Serialization will be done automatically
- Shorter code size, less boilerplate, better UX
- References to the state can be transferred safely
- Explicit scope of accessing
+* Serialization will be done automatically
+* Shorter code size, less boilerplate, better UX
+* References to the state can be transferred safely
+* Explicit scope of accessing

 ### Negative

- Serialization format will be hidden
- Different architecture from the current, but the use of accessor types can be opt-in
- Type-specific types (e.g. `Boolean` and `Integer`) have to be defined manually
+* Serialization format will be hidden
+* Different architecture from the current, but the use of accessor types can be opt-in
+* Type-specific types (e.g. `Boolean` and `Integer`) have to be defined manually

 ### Neutral

 ## References

- [#4554](https://github.com/cosmos/cosmos-sdk/issues/4554)
+* [#4554](https://github.com/cosmos/cosmos-sdk/issues/4554)
@@ -2,7 +2,7 @@

 ## Changelog

- 20-01-2020: Initial Draft
+* 20-01-2020: Initial Draft

 ## Status

@@ -148,7 +148,7 @@ func (k BaseKeeper) MintCoins(ctx sdk.Context, moduleName string, amt sdk.Coins)

 ### Positive

- Exposure into the performance and behavior of an application
+* Exposure into the performance and behavior of an application

 ### Negative

@@ -2,9 +2,9 @@

 ## Changelog

- 2019-10-15: Initial draft
- 2020-05-25: Removed correlation root slashing
- 2020-07-01: Updated to include S-curve function instead of linear
+* 2019-10-15: Initial draft
+* 2020-05-25: Removed correlation root slashing
+* 2020-07-01: Updated to include S-curve function instead of linear

 ## Context

@@ -16,13 +16,13 @@ In Proof of Stake-based chains, centralization of consensus power amongst a smal

 To solve this problem, we will implement a procedure called Proportional Slashing.  The desire is that the larger a validator is, the more they should be slashed.  The first naive attempt is to make a validator's slash percent proportional to their share of consensus voting power.

-```
+```text
 slash_amount = k * power // power is the faulting validator's voting power and k is some on-chain constant
 ```

 However, this will incentivize validators with large amounts of stake to split up their voting power amongst accounts (sybil attack), so that if they fault, they all get slashed at a lower percent.  The solution to this is to take into account not just a validator's own voting percentage, but also the voting percentage of all the other validators who get slashed in a specified time frame.

-```
+```text
 slash_amount = k * (power_1 + power_2 + ... + power_n) // where power_i is the voting power of the ith validator faulting in the specified time frame and k is some on-chain constant
 ```

@@ -51,7 +51,7 @@ Griefing, the act of intentionally getting oneself slashed in order to make anot

 In the slashing module, we will add two queues that will track all of the recent slash events.  For double sign faults, we will define "recent slashes" as ones that have occurred within the last `unbonding period`.  For liveness faults, we will define "recent slashes" as ones that have occurred withing the last `jail period`.

-```
+```go
 type SlashEvent struct {
    Address                     sdk.ValAddress
    ValidatorVotingPercent      sdk.Dec
@@ -75,11 +75,11 @@ Proposed

 ### Positive

- Increases decentralization by disincentivizing delegating to large validators
- Incentivizes Decorrelation of Validators
- More severely punishes attacks than accidental faults
- More flexibility in slashing rates parameterization
+* Increases decentralization by disincentivizing delegating to large validators
+* Incentivizes Decorrelation of Validators
+* More severely punishes attacks than accidental faults
+* More flexibility in slashing rates parameterization

 ### Negative

- More computationally expensive than current implementation.  Will require more data about "recent slashing events" to be stored on chain.
+* More computationally expensive than current implementation.  Will require more data about "recent slashing events" to be stored on chain.
@@ -2,12 +2,12 @@

 ## Changelog

- 2019 Oct 23: Initial draft
- 2019 Nov 28: Add key rotation fee
+* 2019 Oct 23: Initial draft
+* 2019 Nov 28: Add key rotation fee

 ## Context

-Validator consensus key rotation feature has been discussed and requested for a long time, for the sake of safer validator key management policy (e.g. https://github.com/tendermint/tendermint/issues/1136). So, we suggest one of the simplest form of validator consensus key rotation implementation mostly onto Cosmos SDK.
+Validator consensus key rotation feature has been discussed and requested for a long time, for the sake of safer validator key management policy (e.g. <https://github.com/tendermint/tendermint/issues/1136>). So, we suggest one of the simplest form of validator consensus key rotation implementation mostly onto Cosmos SDK.

 We don't need to make any update on consensus logic in Tendermint because Tendermint does not have any mapping information of consensus key and validator operator key, meaning that from Tendermint point of view, a consensus key rotation of a validator is simply a replacement of a consensus key to another.

@@ -17,37 +17,37 @@ Also, it should be noted that this ADR includes only the simplest form of consen

 ### Pseudo procedure for consensus key rotation

- create new random consensus key.
- create and broadcast a transaction with a `MsgRotateConsPubKey` that states the new consensus key is now coupled with the validator operator with signature from the validator's operator key.
- old consensus key becomes unable to participate on consensus immediately after the update of key mapping state on-chain.
- start validating with new consensus key.
- validators using HSM and KMS should update the consensus key in HSM to use the new rotated key after the height `h` when `MsgRotateConsPubKey` committed to the blockchain.
+* create new random consensus key.
+* create and broadcast a transaction with a `MsgRotateConsPubKey` that states the new consensus key is now coupled with the validator operator with signature from the validator's operator key.
+* old consensus key becomes unable to participate on consensus immediately after the update of key mapping state on-chain.
+* start validating with new consensus key.
+* validators using HSM and KMS should update the consensus key in HSM to use the new rotated key after the height `h` when `MsgRotateConsPubKey` committed to the blockchain.

 ### Considerations

- consensus key mapping information management strategy
-    - store history of each key mapping changes in the kvstore.
-    - the state machine can search corresponding consensus key paired with given validator operator for any arbitrary height in a recent unbonding period.
-    - the state machine does not need any historical mapping information which is past more than unbonding period.
- key rotation costs related to LCD and IBC
-    - LCD and IBC will have traffic/computation burden when there exists frequent power changes
-    - In current Tendermint design, consensus key rotations are seen as power changes from LCD or IBC perspective
-    - Therefore, to minimize unnecessary frequent key rotation behavior, we limited maximum number of rotation in recent unbonding period and also applied exponentially increasing rotation fee
- limits
-    - a validator cannot rotate its consensus key more than `MaxConsPubKeyRotations` time for any unbonding period, to prevent spam.
-    - parameters can be decided by governance and stored in genesis file.
- key rotation fee
-    - a validator should pay `KeyRotationFee` to rotate the consensus key which is calculated as below
-    - `KeyRotationFee` = (max(`VotingPowerPercentage` *100, 1)* `InitialKeyRotationFee`) * 2^(number of rotations in `ConsPubKeyRotationHistory` in recent unbonding period)
- evidence module
-    - evidence module can search corresponding consensus key for any height from slashing keeper so that it can decide which consensus key is supposed to be used for given height.
- abci.ValidatorUpdate
-    - tendermint already has ability to change a consensus key by ABCI communication(`ValidatorUpdate`).
-    - validator consensus key update can be done via creating new + delete old by change the power to zero.
-    - therefore, we expect we even do not need to change tendermint codebase at all to implement this feature.
- new genesis parameters in `staking` module
-    - `MaxConsPubKeyRotations` : maximum number of rotation can be executed by a validator in recent unbonding period. default value 10 is suggested(11th key rotation will be rejected)
-    - `InitialKeyRotationFee` : the initial key rotation fee when no key rotation has happened in recent unbonding period. default value 1atom is suggested(1atom fee for the first key rotation in recent unbonding period)
+* consensus key mapping information management strategy
+    * store history of each key mapping changes in the kvstore.
+    * the state machine can search corresponding consensus key paired with given validator operator for any arbitrary height in a recent unbonding period.
+    * the state machine does not need any historical mapping information which is past more than unbonding period.
+* key rotation costs related to LCD and IBC
+    * LCD and IBC will have traffic/computation burden when there exists frequent power changes
+    * In current Tendermint design, consensus key rotations are seen as power changes from LCD or IBC perspective
+    * Therefore, to minimize unnecessary frequent key rotation behavior, we limited maximum number of rotation in recent unbonding period and also applied exponentially increasing rotation fee
+* limits
+    * a validator cannot rotate its consensus key more than `MaxConsPubKeyRotations` time for any unbonding period, to prevent spam.
+    * parameters can be decided by governance and stored in genesis file.
+* key rotation fee
+    * a validator should pay `KeyRotationFee` to rotate the consensus key which is calculated as below
+    * `KeyRotationFee` = (max(`VotingPowerPercentage` *100, 1)* `InitialKeyRotationFee`) * 2^(number of rotations in `ConsPubKeyRotationHistory` in recent unbonding period)
+* evidence module
+    * evidence module can search corresponding consensus key for any height from slashing keeper so that it can decide which consensus key is supposed to be used for given height.
+* abci.ValidatorUpdate
+    * tendermint already has ability to change a consensus key by ABCI communication(`ValidatorUpdate`).
+    * validator consensus key update can be done via creating new + delete old by change the power to zero.
+    * therefore, we expect we even do not need to change tendermint codebase at all to implement this feature.
+* new genesis parameters in `staking` module
+    * `MaxConsPubKeyRotations` : maximum number of rotation can be executed by a validator in recent unbonding period. default value 10 is suggested(11th key rotation will be rejected)
+    * `InitialKeyRotationFee` : the initial key rotation fee when no key rotation has happened in recent unbonding period. default value 1atom is suggested(1atom fee for the first key rotation in recent unbonding period)

 ### Workflow

@@ -63,14 +63,14 @@ Also, it should be noted that this ADR includes only the simplest form of consen

 3. `handleMsgRotateConsPubKey` gets `MsgRotateConsPubKey`, calls `RotateConsPubKey` with emits event
 4. `RotateConsPubKey`
-    - checks if `NewPubKey` is not duplicated on `ValidatorsByConsAddr`
-    - checks if the validator is does not exceed parameter `MaxConsPubKeyRotations` by iterating `ConsPubKeyRotationHistory`
-    - checks if the signing account has enough balance to pay `KeyRotationFee`
-    - pays `KeyRotationFee` to community fund
-    - overwrites `NewPubKey` in `validator.ConsPubKey`
-    - deletes old `ValidatorByConsAddr`
-    - `SetValidatorByConsAddr` for `NewPubKey`
-    - Add `ConsPubKeyRotationHistory` for tracking rotation
+    * checks if `NewPubKey` is not duplicated on `ValidatorsByConsAddr`
+    * checks if the validator is does not exceed parameter `MaxConsPubKeyRotations` by iterating `ConsPubKeyRotationHistory`
+    * checks if the signing account has enough balance to pay `KeyRotationFee`
+    * pays `KeyRotationFee` to community fund
+    * overwrites `NewPubKey` in `validator.ConsPubKey`
+    * deletes old `ValidatorByConsAddr`
+    * `SetValidatorByConsAddr` for `NewPubKey`
+    * Add `ConsPubKeyRotationHistory` for tracking rotation

    ```go
    type ConsPubKeyRotationHistory struct {
@@ -98,7 +98,7 @@ Also, it should be noted that this ADR includes only the simplest form of consen
 6. at `previousVotes` Iteration logic of `AllocateTokens`,  `previousVote` using `OldConsPubKey` match up with `ConsPubKeyRotationHistory`, and replace validator for token allocation
 7. Migrate `ValidatorSigningInfo` and `ValidatorMissedBlockBitArray` from `OldConsPubKey` to `NewConsPubKey`

- Note : All above features shall be implemented in `staking` module.
+* Note : All above features shall be implemented in `staking` module.

 ## Status

@@ -108,18 +108,18 @@ Proposed

 ### Positive

- Validators can immediately or periodically rotate their consensus key to have better security policy
- improved security against Long-Range attacks (https://nearprotocol.com/blog/long-range-attacks-and-a-new-fork-choice-rule) given a validator throws away the old consensus key(s)
+* Validators can immediately or periodically rotate their consensus key to have better security policy
+* improved security against Long-Range attacks (<https://nearprotocol.com/blog/long-range-attacks-and-a-new-fork-choice-rule>) given a validator throws away the old consensus key(s)

 ### Negative

- Slash module needs more computation because it needs to lookup corresponding consensus key of validators for each height
- frequent key rotations will make light client bisection less efficient
+* Slash module needs more computation because it needs to lookup corresponding consensus key of validators for each height
+* frequent key rotations will make light client bisection less efficient

 ### Neutral

 ## References

- on tendermint repo : https://github.com/tendermint/tendermint/issues/1136
- on cosmos-sdk repo : https://github.com/cosmos/cosmos-sdk/issues/5231
- about multiple consensus keys : https://github.com/tendermint/tendermint/issues/1758#issuecomment-545291698
+* on tendermint repo : <https://github.com/tendermint/tendermint/issues/1136>
+* on cosmos-sdk repo : <https://github.com/cosmos/cosmos-sdk/issues/5231>
+* about multiple consensus keys : <https://github.com/tendermint/tendermint/issues/1758#issuecomment-545291698>
@@ -2,8 +2,8 @@

 ## Changelog

- 26 November 2019: Start of first version
- 2 December 2019: Final draft of first version
+* 26 November 2019: Start of first version
+* 2 December 2019: Final draft of first version

 ## Context

@@ -44,13 +44,13 @@ Implementation of this ADR will require changes to the Cosmos SDK. It will not r

 ### Positive

- Easy retrieval of headers & state roots for recent past heights by modules anywhere in the Cosmos SDK.
- No RPC calls to Tendermint required.
- No ABCI alterations required.
+* Easy retrieval of headers & state roots for recent past heights by modules anywhere in the Cosmos SDK.
+* No RPC calls to Tendermint required.
+* No ABCI alterations required.

 ### Negative

- Duplicates `n` headers data in Tendermint & the application (additional disk usage) - in the long term, an approach such as [this](https://github.com/tendermint/tendermint/issues/4210) might be preferable.
+* Duplicates `n` headers data in Tendermint & the application (additional disk usage) - in the long term, an approach such as [this](https://github.com/tendermint/tendermint/issues/4210) might be preferable.

 ### Neutral

@@ -58,4 +58,4 @@ Implementation of this ADR will require changes to the Cosmos SDK. It will not r

 ## References

- [ICS 2: "Consensus state introspection"](https://github.com/cosmos/ibc/tree/master/spec/core/ics-002-client-semantics#consensus-state-introspection)
+* [ICS 2: "Consensus state introspection"](https://github.com/cosmos/ibc/tree/master/spec/core/ics-002-client-semantics#consensus-state-introspection)
@@ -2,7 +2,7 @@

 ## Changelog

- 1 January 2020: Start of first version
+* 1 January 2020: Start of first version

 ## Context

@@ -18,8 +18,8 @@ Thus, we propose the following mechanism:

 ### Params

- The current gov param `VotingPeriod` is to be replaced by a `MinVotingPeriod` param.  This is the the default voting period that all governance proposal voting periods start with.
- There is a new gov param called `MaxVotingPeriodExtension`.
+* The current gov param `VotingPeriod` is to be replaced by a `MinVotingPeriod` param.  This is the the default voting period that all governance proposal voting periods start with.
+* There is a new gov param called `MaxVotingPeriodExtension`.

 ### Mechanism

@@ -50,17 +50,17 @@ Proposed

 ### Positive

- More complex/contentious governance proposals will have more time to properly digest and deliberate
+* More complex/contentious governance proposals will have more time to properly digest and deliberate

 ### Negative

- Governance process becomes more complex and requires more understanding to interact with effectively
- Can no longer predict when a governance proposal will end. Can't assume order in which governance proposals will end.
+* Governance process becomes more complex and requires more understanding to interact with effectively
+* Can no longer predict when a governance proposal will end. Can't assume order in which governance proposals will end.

 ### Neutral

- The minimum voting period can be made shorter
+* The minimum voting period can be made shorter

 ## References

- [Cosmos Forum post where idea first originated](https://forum.cosmos.network/t/proposal-draft-reduce-governance-voting-period-to-7-days/3032/9)
+* [Cosmos Forum post where idea first originated](https://forum.cosmos.network/t/proposal-draft-reduce-governance-voting-period-to-7-days/3032/9)
@@ -2,12 +2,12 @@

 ## Changelog

- 2020 Feb 15: Initial Draft
- 2020 Feb 24: Updates to handle messages with interface fields
- 2020 Apr 27: Convert usages of `oneof` for interfaces to `Any`
- 2020 May 15: Describe `cosmos_proto` extensions and amino compatibility
- 2020 Dec 4: Move and rename `MarshalAny` and `UnmarshalAny` into the `codec.Codec` interface.
- 2021 Feb 24: Remove mentions of `HybridCodec`, which has been abandoned in [#6843](https://github.com/cosmos/cosmos-sdk/pull/6843).
+* 2020 Feb 15: Initial Draft
+* 2020 Feb 24: Updates to handle messages with interface fields
+* 2020 Apr 27: Convert usages of `oneof` for interfaces to `Any`
+* 2020 May 15: Describe `cosmos_proto` extensions and amino compatibility
+* 2020 Dec 4: Move and rename `MarshalAny` and `UnmarshalAny` into the `codec.Codec` interface.
+* 2021 Feb 24: Remove mentions of `HybridCodec`, which has been abandoned in [#6843](https://github.com/cosmos/cosmos-sdk/pull/6843).

 ## Status

@@ -28,9 +28,9 @@ From the Amino docs:

 Amino also aims to have the following goals (not a complete list):

- Binary bytes must be decode-able with a schema.
- Schema must be upgradeable.
- The encoder and decoder logic must be reasonably simple.
+* Binary bytes must be decode-able with a schema.
+* Schema must be upgradeable.
+* The encoder and decoder logic must be reasonably simple.

 However, we believe that Amino does not fulfill these goals completely and does not fully meet the
 needs of a truly flexible cross-language and multi-client compatible encoding protocol in the Cosmos SDK.
@@ -42,13 +42,13 @@ largely reflected in the performance of simulations and application transaction

 Thus, we need to adopt an encoding protocol that meets the following criteria for state serialization:

- Language agnostic
- Platform agnostic
- Rich client support and thriving ecosystem
- High performance
- Minimal encoded message size
- Codegen-based over reflection-based
- Supports backward and forward compatibility
+* Language agnostic
+* Platform agnostic
+* Rich client support and thriving ecosystem
+* High performance
+* Minimal encoded message size
+* Codegen-based over reflection-based
+* Supports backward and forward compatibility

 Note, migrating away from Amino should be viewed as a two-pronged approach, state and client encoding.
 This ADR focuses on state serialization in the Cosmos SDK state machine. A corresponding ADR will be
@@ -62,8 +62,8 @@ applications wishing to continue to use Amino. We will provide this mechanism by
 accept a codec interface, `Marshaler`, instead of a concrete Amino codec. Furthermore, the Cosmos SDK
 will provide two concrete implementations of the `Marshaler` interface: `AminoCodec` and `ProtoCodec`.

- `AminoCodec`: Uses Amino for both binary and JSON encoding.
- `ProtoCodec`: Uses Protobuf for both binary and JSON encoding.
+* `AminoCodec`: Uses Amino for both binary and JSON encoding.
+* `ProtoCodec`: Uses Protobuf for both binary and JSON encoding.

 Modules will use whichever codec that is instantiated in the app. By default, the Cosmos SDK's `simapp`
 instantiates a `ProtoCodec` as the concrete implementation of `Marshaler`, inside the `MakeTestEncodingConfig`
@@ -320,11 +320,11 @@ have been registered properly with Amino).

 In order for this functionality to work:

- **all legacy code must use `*codec.LegacyAmino` instead of `*amino.Codec` which is
+* **all legacy code must use `*codec.LegacyAmino` instead of `*amino.Codec` which is
  now a wrapper which properly handles `Any`**
- **all new code should use `Marshaler` which is compatible with both amino and
+* **all new code should use `Marshaler` which is compatible with both amino and
  protobuf**
- Also, before v0.39, `codec.LegacyAmino` will be renamed to `codec.LegacyAmino`.
+* Also, before v0.39, `codec.LegacyAmino` will be renamed to `codec.LegacyAmino`.

 ### Why Wasn't X Chosen Instead

@@ -361,19 +361,19 @@ seamless.

 ### Positive

- Significant performance gains.
- Supports backward and forward type compatibility.
- Better support for cross-language clients.
+* Significant performance gains.
+* Supports backward and forward type compatibility.
+* Better support for cross-language clients.

 ### Negative

- Learning curve required to understand and implement Protobuf messages.
- Slightly larger message size due to use of `Any`, although this could be offset
+* Learning curve required to understand and implement Protobuf messages.
+* Slightly larger message size due to use of `Any`, although this could be offset
  by a compression layer in the future

 ### Neutral

 ## References

-1. https://github.com/cosmos/cosmos-sdk/issues/4977
-2. https://github.com/cosmos/cosmos-sdk/issues/5444
+1. <https://github.com/cosmos/cosmos-sdk/issues/4977>
+2. <https://github.com/cosmos/cosmos-sdk/issues/5444>
@@ -2,19 +2,19 @@

 ## Changelog

- 2020 March 06: Initial Draft
- 2020 March 12: API Updates
- 2020 April 13: Added details on interface `oneof` handling
- 2020 April 30: Switch to `Any`
- 2020 May 14: Describe public key encoding
- 2020 June 08: Store `TxBody` and `AuthInfo` as bytes in `SignDoc`; Document `TxRaw` as broadcast and storage type.
- 2020 August 07: Use ADR 027 for serializing `SignDoc`.
- 2020 August 19: Move sequence field from `SignDoc` to `SignerInfo`, as discussed in [#6966](https://github.com/cosmos/cosmos-sdk/issues/6966).
- 2020 September 25: Remove `PublicKey` type in favor of `secp256k1.PubKey`, `ed25519.PubKey` and `multisig.LegacyAminoPubKey`.
- 2020 October 15: Add `GetAccount` and `GetAccountWithHeight` methods to the `AccountRetriever` interface.
- 2021 Feb 24: The Cosmos SDK does not use Tendermint's `PubKey` interface anymore, but its own `cryptotypes.PubKey`. Updates to reflect this.
- 2021 May 3: Rename `clientCtx.JSONMarshaler` to `clientCtx.JSONCodec`.
- 2021 June 10: Add `clientCtx.Codec: codec.Codec`.
+* 2020 March 06: Initial Draft
+* 2020 March 12: API Updates
+* 2020 April 13: Added details on interface `oneof` handling
+* 2020 April 30: Switch to `Any`
+* 2020 May 14: Describe public key encoding
+* 2020 June 08: Store `TxBody` and `AuthInfo` as bytes in `SignDoc`; Document `TxRaw` as broadcast and storage type.
+* 2020 August 07: Use ADR 027 for serializing `SignDoc`.
+* 2020 August 19: Move sequence field from `SignDoc` to `SignerInfo`, as discussed in [#6966](https://github.com/cosmos/cosmos-sdk/issues/6966).
+* 2020 September 25: Remove `PublicKey` type in favor of `secp256k1.PubKey`, `ed25519.PubKey` and `multisig.LegacyAminoPubKey`.
+* 2020 October 15: Add `GetAccount` and `GetAccountWithHeight` methods to the `AccountRetriever` interface.
+* 2021 Feb 24: The Cosmos SDK does not use Tendermint's `PubKey` interface anymore, but its own `cryptotypes.PubKey`. Updates to reflect this.
+* 2021 May 3: Rename `clientCtx.JSONMarshaler` to `clientCtx.JSONCodec`.
+* 2021 June 10: Add `clientCtx.Codec: codec.Codec`.

 ## Status

@@ -168,9 +168,9 @@ attempt to upstream important improvements to `Tx`.

 All of the signing modes below aim to provide the following guarantees:

- **No Malleability**: `TxBody` and `AuthInfo` cannot change once the transaction
+* **No Malleability**: `TxBody` and `AuthInfo` cannot change once the transaction
  is signed
- **Predictable Gas**: if I am signing a transaction where I am paying a fee,
+* **Predictable Gas**: if I am signing a transaction where I am paying a fee,
  the final gas is fully dependent on what I am signing

 These guarantees give the maximum amount confidence to message signers that
@@ -181,9 +181,9 @@ manipulation of `Tx`s by intermediaries can't result in any meaningful changes.
 The "direct" signing behavior is to sign the raw `TxBody` bytes as broadcast over
 the wire. This has the advantages of:

- requiring the minimum additional client capabilities beyond a standard protocol
+* requiring the minimum additional client capabilities beyond a standard protocol
  buffers implementation
- leaving effectively zero holes for transaction malleability (i.e. there are no
+* leaving effectively zero holes for transaction malleability (i.e. there are no
  subtle differences between the signing and encoding formats which could
  potentially be exploited by an attacker)

@@ -219,10 +219,10 @@ Signature verifiers do:
 1. Deserialize a `TxRaw` and pull out `body` and `auth_info`.
 2. Create a list of required signer addresses from the messages.
 3. For each required signer:
-   - Pull account number and sequence from the state.
-   - Obtain the public key either from state or `AuthInfo`'s `signer_infos`.
-   - Create a `SignDoc` and serialize it using [ADR 027](./adr-027-deterministic-protobuf-serialization.md).
-   - Verify the signature at the the same list position against the serialized `SignDoc`.
+   * Pull account number and sequence from the state.
+   * Obtain the public key either from state or `AuthInfo`'s `signer_infos`.
+   * Create a `SignDoc` and serialize it using [ADR 027](./adr-027-deterministic-protobuf-serialization.md).
+   * Verify the signature at the the same list position against the serialized `SignDoc`.

 #### `SIGN_MODE_LEGACY_AMINO`

@@ -263,14 +263,14 @@ by `SIGN_MODE_TEXTUAL` when it is implemented.
 Unknown fields in protobuf messages should generally be rejected by transaction
 processors because:

- important data may be present in the unknown fields, that if ignored, will
+* important data may be present in the unknown fields, that if ignored, will
  cause unexpected behavior for clients
- they present a malleability vulnerability where attackers can bloat tx size
+* they present a malleability vulnerability where attackers can bloat tx size
  by adding random uninterpreted data to unsigned content (i.e. the master `Tx`,
  not `TxBody`)

 There are also scenarios where we may choose to safely ignore unknown fields
-(https://github.com/cosmos/cosmos-sdk/issues/6078#issuecomment-624400188) to
+(<https://github.com/cosmos/cosmos-sdk/issues/6078#issuecomment-624400188>) to
 provide graceful forwards compatibility with newer clients.

 We propose that field numbers with bit 11 set (for most use cases this is
@@ -279,9 +279,9 @@ ignored if unknown.

 To handle this we will need a unknown field filter that:

- always rejects unknown fields in unsigned content (i.e. top-level `Tx` and
+* always rejects unknown fields in unsigned content (i.e. top-level `Tx` and
  unsigned parts of `AuthInfo` if present based on the signing mode)
- rejects unknown fields in all messages (including nested `Any`s) other than
+* rejects unknown fields in all messages (including nested `Any`s) other than
  fields with bit 11 set

 This will likely need to be a custom protobuf parser pass that takes message bytes
@@ -379,7 +379,7 @@ can gracefully transition away from Amino JSON.

 ### `SIGN_MODE_DIRECT_AUX`

-(\*Documented as option (3) in https://github.com/cosmos/cosmos-sdk/issues/6078#issuecomment-628026933)
+(\*Documented as option (3) in <https://github.com/cosmos/cosmos-sdk/issues/6078#issuecomment-628026933>)

 We could add a mode `SIGN_MODE_DIRECT_AUX`
 to support scenarios where multiple signatures
@@ -408,27 +408,27 @@ To generate a signature in `SIGN_MODE_DIRECT_AUX` these steps would be followed:
 1. Encode `SignDocAux` (with the same requirement that fields must be serialized
   in order):

-```proto
-// types/types.proto
-message SignDocAux {
-    bytes body_bytes = 1;
-    // PublicKey is included in SignDocAux :
-    // 1. as a special case for multisig public keys. For multisig public keys,
-    // the signer should use the top-level multisig public key they are signing
-    // against, not their own public key. This is to prevent against a form
-    // of malleability where a signature could be taken out of context of the
-    // multisig key that was intended to be signed for
-    // 2. to guard against scenario where configuration information is encoded
-    // in public keys (it has been proposed) such that two keys can generate
-    // the same signature but have different security properties
-    //
-    // By including it here, the composer of AuthInfo cannot reference the
-    // a public key variant the signer did not intend to use
-    PublicKey public_key = 2;
-    string chain_id = 3;
-    uint64 account_number = 4;
-}
-```
+    ```proto
+    // types/types.proto
+    message SignDocAux {
+        bytes body_bytes = 1;
+        // PublicKey is included in SignDocAux :
+        // 1. as a special case for multisig public keys. For multisig public keys,
+        // the signer should use the top-level multisig public key they are signing
+        // against, not their own public key. This is to prevent against a form
+        // of malleability where a signature could be taken out of context of the
+        // multisig key that was intended to be signed for
+        // 2. to guard against scenario where configuration information is encoded
+        // in public keys (it has been proposed) such that two keys can generate
+        // the same signature but have different security properties
+        //
+        // By including it here, the composer of AuthInfo cannot reference the
+        // a public key variant the signer did not intend to use
+        PublicKey public_key = 2;
+        string chain_id = 3;
+        uint64 account_number = 4;
+    }
+    ```

 2. Sign the encoded `SignDocAux` bytes
 3. Send their signature and `SignerInfo` to primary signer who will then
@@ -437,7 +437,7 @@ message SignDocAux {

 ### `SIGN_MODE_DIRECT_RELAXED`

-(_Documented as option (1)(a) in https://github.com/cosmos/cosmos-sdk/issues/6078#issuecomment-628026933_)
+(_Documented as option (1)(a) in <https://github.com/cosmos/cosmos-sdk/issues/6078#issuecomment-628026933>_)

 This is a variation of `SIGN_MODE_DIRECT` where multiple signers wouldn't need to
 coordinate public keys and signing modes in advance. It would involve an alternate
@@ -449,14 +449,14 @@ too burdensome.

 ### Positive

- Significant performance gains.
- Supports backward and forward type compatibility.
- Better support for cross-language clients.
- Multiple signing modes allow for greater protocol evolution
+* Significant performance gains.
+* Supports backward and forward type compatibility.
+* Better support for cross-language clients.
+* Multiple signing modes allow for greater protocol evolution

 ### Negative

- `google.protobuf.Any` type URLs increase transaction size although the effect
+* `google.protobuf.Any` type URLs increase transaction size although the effect
  may be negligible or compression may be able to mitigate it.

 ### Neutral
@@ -2,7 +2,7 @@

 ## Changelog

- 2020 March 27: Initial Draft
+* 2020 March 27: Initial Draft

 ## Status

@@ -2,8 +2,8 @@

 ## Changelog

- 2020 Apr 24: Initial Draft
- 2021 Sep 14: Superseded by ADR-045
+* 2020 Apr 24: Initial Draft
+* 2021 Sep 14: Superseded by ADR-045

 ## Status

@@ -196,23 +196,23 @@ This method would prepend handlers to an existing chain.

 ### Positive

- Developers of Cosmos SDK based projects can add custom panic handlers to:
+* Developers of Cosmos SDK based projects can add custom panic handlers to:
    * add error context for custom panic sources (panic inside of custom keepers);
    * emit `panic()`: passthrough recovery object to the Tendermint core;
    * other necessary handling;
- Developers can use standard Cosmos SDK `BaseApp` implementation, rather that rewriting it in their projects;
- Proposed solution doesn't break the current "standard" `runTx()` flow;
+* Developers can use standard Cosmos SDK `BaseApp` implementation, rather that rewriting it in their projects;
+* Proposed solution doesn't break the current "standard" `runTx()` flow;

 ### Negative

- Introduces changes to the execution model design.
+* Introduces changes to the execution model design.

 ### Neutral

- `OutOfGas` error handler becomes one of the middlewares;
- Default panic handler becomes one of the middlewares;
+* `OutOfGas` error handler becomes one of the middlewares;
+* Default panic handler becomes one of the middlewares;

 ## References

- [PR-6053 with proposed solution](https://github.com/cosmos/cosmos-sdk/pull/6053)
- [Similar solution. ADR-010 Modular AnteHandler](https://github.com/cosmos/cosmos-sdk/blob/v0.38.3/docs/architecture/adr-010-modular-antehandler.md)
+* [PR-6053 with proposed solution](https://github.com/cosmos/cosmos-sdk/pull/6053)
+* [Similar solution. ADR-010 Modular AnteHandler](https://github.com/cosmos/cosmos-sdk/blob/v0.38.3/docs/architecture/adr-010-modular-antehandler.md)
@@ -2,8 +2,8 @@

 ## Changelog

- 2020 April 27: Initial Draft
- 2020 August 5: Update guidelines
+* 2020 April 27: Initial Draft
+* 2020 August 5: Update guidelines

 ## Status

@@ -132,13 +132,13 @@ The following guidelines are recommended for marking packages as alpha or beta:

 * marking something as `alpha` or `beta` should be a last resort and just putting something in the
 stable package (i.e. `v1` or `v2`) should be preferred
-* a package *should* be marked as `alpha` *if and only if* there are active discussions to remove
+* a package _should_ be marked as `alpha` _if and only if_ there are active discussions to remove
 or significantly alter the package in the near future
-* a package *should* be marked as `beta` *if and only if* there is an active discussion to
+* a package _should_ be marked as `beta` _if and only if_ there is an active discussion to
 significantly refactor/rework the functionality in the near future but not remove it
-* modules *can and should* have types in both stable (i.e. `v1` or `v2`) and unstable (`alpha` or `beta`) packages.
+* modules _can and should_ have types in both stable (i.e. `v1` or `v2`) and unstable (`alpha` or `beta`) packages.

-*`alpha` and `beta` should not be used to avoid responsibility for maintaining compatibility.*
+_`alpha` and `beta` should not be used to avoid responsibility for maintaining compatibility._
 Whenever code is released into the wild, especially on a blockchain, there is a high cost to changing things. In some
 cases, for instance with immutable smart contracts, a breaking change may be impossible to fix.

@@ -2,7 +2,7 @@

 ## Changelog

- 05/19/2020: Initial draft
+* 05/19/2020: Initial draft

 ## Status

@@ -93,9 +93,9 @@ As an example, the ATOM's metadata can be defined as follows:

 Given the above metadata, a client may infer the following things:

- 4.3atom = 4.3 * (10^6) = 4,300,000uatom
- The string "atom" can be used as a display name in a list of tokens.
- The balance 4300000 can be displayed as 4,300,000uatom or 4,300matom or 4.3atom.
+* 4.3atom = 4.3 * (10^6) = 4,300,000uatom
+* The string "atom" can be used as a display name in a list of tokens.
+* The balance 4300000 can be displayed as 4,300,000uatom or 4,300matom or 4.3atom.
  The `display` denomination 4.3atom is a good default if the authors of the client don't make
  an explicit decision to choose a different representation.

@@ -124,13 +124,13 @@ via an endpoint, we may consider supporting automatic conversion of a given unit

 ### Positive

- Provides clients, wallet providers and block explorers with additional data on
+* Provides clients, wallet providers and block explorers with additional data on
  asset denomination to improve UX and remove any need to make assumptions on
  denomination units.

 ### Negative

- A small amount of required additional storage in the `x/bank` module. The amount
+* A small amount of required additional storage in the `x/bank` module. The amount
  of additional storage should be minimal as the amount of total assets should not
  be large.

@@ -2,8 +2,8 @@

 ## Changelog

- 2020-08-07: Initial Draft
- 2020-09-01: Further clarify rules
+* 2020-08-07: Initial Draft
+* 2020-09-01: Further clarify rules

 ## Status

@@ -126,12 +126,12 @@ default value).
 There are three main implementation strategies, ordered from the least to the
 most custom development:

- **Use a protobuf serializer that follows the above rules by default.** E.g.
+* **Use a protobuf serializer that follows the above rules by default.** E.g.
  [gogoproto](https://pkg.go.dev/github.com/gogo/protobuf/gogoproto) is known to
  be compliant by in most cases, but not when certain annotations such as
  `nullable = false` are used. It might also be an option to configure an
  existing serializer accordingly.
- **Normalize default values before encoding them.** If your serializer follows
+* **Normalize default values before encoding them.** If your serializer follows
  rule 1. and 2. and allows you to explicitly unset fields for serialization,
  you can normalize default values to unset. This can be done when working with
  [protobuf.js](https://www.npmjs.com/package/protobufjs):
@@ -146,7 +146,7 @@ most custom development:
  }).finish();
  ```

- **Use a hand-written serializer for the types you need.** If none of the above
+* **Use a hand-written serializer for the types you need.** If none of the above
  ways works for you, you can write a serializer yourself. For SignDoc this
  would look something like this in Go, building on existing protobuf utilities:

@@ -231,14 +231,14 @@ backlinks: []

 must result in the serialization

-```
+```text
 0a1b54686520776f726c64206e65656473206368616e676520f09f8cb318e8bebec8bc2e280138024a084e696365206f6e654a095468616e6b20796f75
 ```

 When inspecting the serialized document, you see that every second field is
 omitted:

-```
+```sh
 $ echo 0a1b54686520776f726c64206e65656473206368616e676520f09f8cb318e8bebec8bc2e280138024a084e696365206f6e654a095468616e6b20796f75 | xxd -r -p | protoc --decode_raw
 1: "The world needs change \360\237\214\263"
 3: 1596806111080
@@ -255,20 +255,20 @@ for all protobuf documents we need in the context of Cosmos SDK signing.

 ### Positive

- Well defined rules that can be verified independent of a reference
+* Well defined rules that can be verified independent of a reference
  implementation
- Simple enough to keep the barrier to implement transaction signing low
- It allows us to continue to use 0 and other empty values in SignDoc, avoiding
+* Simple enough to keep the barrier to implement transaction signing low
+* It allows us to continue to use 0 and other empty values in SignDoc, avoiding
  the need to work around 0 sequences. This does not imply the change from
-  https://github.com/cosmos/cosmos-sdk/pull/6949 should not be merged, but not
+  <https://github.com/cosmos/cosmos-sdk/pull/6949> should not be merged, but not
  too important anymore.

 ### Negative

- When implementing transaction signing, the encoding rules above must be
+* When implementing transaction signing, the encoding rules above must be
  understood and implemented.
- The need for rule number 3. adds some complexity to implementations.
- Some data structures may require custom code for serialization. Thus
+* The need for rule number 3. adds some complexity to implementations.
+* Some data structures may require custom code for serialization. Thus
  the code is not very portable - it will require additional work for each
  client implementing serialization to properly handle custom data structures.

@@ -283,32 +283,32 @@ the need of implementing a custom serializer that adheres to this standard (and

 ## References

- <sup>1</sup> _When a message is serialized, there is no guaranteed order for
+* <sup>1</sup> _When a message is serialized, there is no guaranteed order for
  how its known or unknown fields should be written. Serialization order is an
  implementation detail and the details of any particular implementation may
  change in the future. Therefore, protocol buffer parsers must be able to parse
  fields in any order._ from
-  https://developers.google.com/protocol-buffers/docs/encoding#order
- <sup>2</sup> https://developers.google.com/protocol-buffers/docs/encoding#signed_integers
- <sup>3</sup> _Note that for scalar message fields, once a message is parsed
+  <https://developers.google.com/protocol-buffers/docs/encoding#order>
+* <sup>2</sup> <https://developers.google.com/protocol-buffers/docs/encoding#signed_integers>
+* <sup>3</sup> _Note that for scalar message fields, once a message is parsed
  there's no way of telling whether a field was explicitly set to the default
  value (for example whether a boolean was set to false) or just not set at all:
  you should bear this in mind when defining your message types. For example,
  don't have a boolean that switches on some behavior when set to false if you
  don't want that behavior to also happen by default._ from
-  https://developers.google.com/protocol-buffers/docs/proto3#default
- <sup>4</sup> _When a message is parsed, if the encoded message does not
+  <https://developers.google.com/protocol-buffers/docs/proto3#default>
+* <sup>4</sup> _When a message is parsed, if the encoded message does not
  contain a particular singular element, the corresponding field in the parsed
  object is set to the default value for that field._ from
-  https://developers.google.com/protocol-buffers/docs/proto3#default
- <sup>5</sup> _Also note that if a scalar message field is set to its default,
+  <https://developers.google.com/protocol-buffers/docs/proto3#default>
+* <sup>5</sup> _Also note that if a scalar message field is set to its default,
  the value will not be serialized on the wire._ from
-  https://developers.google.com/protocol-buffers/docs/proto3#default
- <sup>6</sup> _For enums, the default value is the first defined enum value,
+  <https://developers.google.com/protocol-buffers/docs/proto3#default>
+* <sup>6</sup> _For enums, the default value is the first defined enum value,
  which must be 0._ from
-  https://developers.google.com/protocol-buffers/docs/proto3#default
- <sup>7</sup> _For message fields, the field is not set. Its exact value is
+  <https://developers.google.com/protocol-buffers/docs/proto3#default>
+* <sup>7</sup> _For message fields, the field is not set. Its exact value is
  language-dependent._ from
-  https://developers.google.com/protocol-buffers/docs/proto3#default
- Encoding rules and parts of the reasoning taken from
+  <https://developers.google.com/protocol-buffers/docs/proto3#default>
+* Encoding rules and parts of the reasoning taken from
  [canonical-proto3 Aaron Craelius](https://github.com/regen-network/canonical-proto3)
@@ -2,8 +2,8 @@

 ## Changelog

- 2020/08/18: Initial version
- 2021/01/15: Analysis and algorithm update
+* 2020/08/18: Initial version
+* 2021/01/15: Analysis and algorithm update

 ## Status

@@ -29,12 +29,12 @@ a security break of one account type shouldn't impact the security of other acco
 One initial proposal was extending the address length and
 adding prefixes for different types of addresses.

-@ethanfrey explained an alternate approach originally used in https://github.com/iov-one/weave:
+@ethanfrey explained an alternate approach originally used in <https://github.com/iov-one/weave>:

 > I spent quite a bit of time thinking about this issue while building weave... The other cosmos Sdk.
 > Basically I define a condition to be a type and format as human readable string with some binary data appended. This condition is hashed into an Address (again at 20 bytes). The use of this prefix makes it impossible to find a preimage for a given address with a different condition (eg ed25519 vs secp256k1).
-> This is explained in depth here https://weave.readthedocs.io/en/latest/design/permissions.html
-> And the code is here, look mainly at the top where we process conditions. https://github.com/iov-one/weave/blob/master/conditions.go
+> This is explained in depth here <https://weave.readthedocs.io/en/latest/design/permissions.html>
+> And the code is here, look mainly at the top where we process conditions. <https://github.com/iov-one/weave/blob/master/conditions.go>

 And explained how this approach should be sufficiently collision resistant:

@@ -53,15 +53,15 @@ This disqualifies the initial proposal.

 In the issue we discussed various modifications:

-+ Choice of the hash function.
-+ Move the prefix out of the hash function: `keyTypePrefix + sha256(keybytes)[:20]` [post-hash-prefix-proposal].
-+ Use double hashing: `sha256(keyTypePrefix + sha256(keybytes)[:20])`.
-+ Increase to keybytes hash slice from 20 byte to 32 or 40 bytes. We concluded that 32 bytes, produced by a good hash functions is future secure.
+* Choice of the hash function.
+* Move the prefix out of the hash function: `keyTypePrefix + sha256(keybytes)[:20]` [post-hash-prefix-proposal].
+* Use double hashing: `sha256(keyTypePrefix + sha256(keybytes)[:20])`.
+* Increase to keybytes hash slice from 20 byte to 32 or 40 bytes. We concluded that 32 bytes, produced by a good hash functions is future secure.

 ### Requirements

-+ Support currently used tools - we don't want to break an ecosystem, or add a long adaptation period. Ref: https://github.com/cosmos/cosmos-sdk/issues/8041
-+ Try to keep the address length small - addresses are widely used in state, both as part of a key and object value.
+* Support currently used tools - we don't want to break an ecosystem, or add a long adaptation period. Ref: <https://github.com/cosmos/cosmos-sdk/issues/8041>
+* Try to keep the address length small - addresses are widely used in state, both as part of a key and object value.

 ### Scope

@@ -82,8 +82,8 @@ We define the following account types, for which we define the address function:
 Currently (Jan 2021), the only officially supported Cosmos SDK user accounts are `secp256k1` basic accounts and legacy amino multisig.
 They are used in existing Cosmos SDK zones. They use the following address formats:

- secp256k1: `ripemd160(sha256(pk_bytes))[:20]`
- legacy amino multisig: `sha256(aminoCdc.Marshal(pk))[:20]`
+* secp256k1: `ripemd160(sha256(pk_bytes))[:20]`
+* legacy amino multisig: `sha256(aminoCdc.Marshal(pk))[:20]`

 We don't want to change existing addresses. So the addresses for these two key types will remain the same.

@@ -118,8 +118,8 @@ We use the `address.Hash` function for generating addresses for all accounts rep

 * simple public keys: `address.Hash(keyType, pubkey)`

-+ aggregated keys (eg: BLS): `address.Hash(keyType, aggregatedPubKey)`
-+ modules: `address.Hash("module", moduleName)`
+* aggregated keys (eg: BLS): `address.Hash(keyType, aggregatedPubKey)`
+* modules: `address.Hash("module", moduleName)`

 ### Composed Addresses

@@ -196,13 +196,13 @@ func Module(moduleName string, key []byte) []byte{

 **Example**  A lending BTC pool address would be:

-```
+```go
 btcPool := address.Module("lending", btc.Addrress()})
 ```

 If we want to create an address for a module account depending on more than one key, we can concatenate them:

-```
+```go
 btcAtomAMM := address.Module("amm", btc.Addrress() + atom.Address()})
 ```

@@ -220,7 +220,7 @@ Note: `Module` is a special case of the more general _derived_ address, where we

 **Example**  For a cosmwasm smart-contract address we could use the following construction:

-```
+```go
 smartContractAddr := Derived(Module("cosmwasm", smartContractsNamespace), []{smartContractKey})
 ```

@@ -252,21 +252,21 @@ This ADR is compatible with what was committed and directly supported in the Cos

 ### Positive

- a simple algorithm for generating addresses for new public keys, complex accounts and modules
- the algorithm generalizes _native composed keys_
- increased security and collision resistance of addresses
- the approach is extensible for future use-cases - one can use other address types, as long as they don't conflict with the address length specified here (20 or 32 bytes).
- support new account types.
+* a simple algorithm for generating addresses for new public keys, complex accounts and modules
+* the algorithm generalizes _native composed keys_
+* increased security and collision resistance of addresses
+* the approach is extensible for future use-cases - one can use other address types, as long as they don't conflict with the address length specified here (20 or 32 bytes).
+* support new account types.

 ### Negative

- addresses do not communicate key type, a prefixed approach would have done this
- addresses are 60% longer and will consume more storage space
- requires a refactor of KVStore store keys to handle variable length addresses
+* addresses do not communicate key type, a prefixed approach would have done this
+* addresses are 60% longer and will consume more storage space
+* requires a refactor of KVStore store keys to handle variable length addresses

 ### Neutral

- protobuf message names are used as key type prefixes
+* protobuf message names are used as key type prefixes

 ## Further Discussions

@@ -280,50 +280,50 @@ End of Dec 2020 we had a session with [Alan Szepieniec](https://scholar.google.b

 Alan general observations:

-+ we don’t need 2-preimage resistance
-+ we need 32bytes address space for collision resistance
-+ when an attacker can control an input for object with an address then we have a problem with birthday attack
-+ there is an issue with smart-contracts for hashing
-+ sha2 mining can be use to breaking address pre-image
+* we don’t need 2-preimage resistance
+* we need 32bytes address space for collision resistance
+* when an attacker can control an input for object with an address then we have a problem with birthday attack
+* there is an issue with smart-contracts for hashing
+* sha2 mining can be use to breaking address pre-image

 Hashing algorithm

-+ any attack breaking blake3 will break blake2
-+ Alan is pretty confident about the current security analysis of the blake hash algorithm. It was a finalist, and the author is well known in security analysis.
+* any attack breaking blake3 will break blake2
+* Alan is pretty confident about the current security analysis of the blake hash algorithm. It was a finalist, and the author is well known in security analysis.

 Algorithm:

-+ Alan recommends to hash the prefix: `address(pub_key) = hash(hash(key_type) + pub_key)[:32]`, main benefits:
-    + we are free to user arbitrary long prefix names
-    + we still don’t risk collisions
-    + switch tables
-+ discussion about penalization -> about adding prefix post hash
-+ Aaron asked about post hash prefixes (`address(pub_key) = key_type + hash(pub_key)`) and differences. Alan noted that this approach has longer address space and it’s stronger.
+* Alan recommends to hash the prefix: `address(pub_key) = hash(hash(key_type) + pub_key)[:32]`, main benefits:
+    * we are free to user arbitrary long prefix names
+    * we still don’t risk collisions
+    * switch tables
+* discussion about penalization -> about adding prefix post hash
+* Aaron asked about post hash prefixes (`address(pub_key) = key_type + hash(pub_key)`) and differences. Alan noted that this approach has longer address space and it’s stronger.

 Algorithm for complex / composed keys:

-+ merging tree like addresses with same algorithm are fine
+* merging tree like addresses with same algorithm are fine

 Module addresses: Should module addresses have different size to differentiate it?

-+ we will need to set a pre-image prefix for module addresse to keept them in 32-byte space: `hash(hash('module') + module_key)`
-+ Aaron observation: we already need to deal with variable length (to not break secp256k1 keys).
+* we will need to set a pre-image prefix for module addresse to keept them in 32-byte space: `hash(hash('module') + module_key)`
+* Aaron observation: we already need to deal with variable length (to not break secp256k1 keys).

 Discssion about arithmetic hash function for ZKP

-+ Posseidon / Rescue
-+ Problem: much bigger risk because we don’t know much techniques and history of crypto-analysis of arithmetic constructions. It’s still a new ground and area of active research.
+* Posseidon / Rescue
+* Problem: much bigger risk because we don’t know much techniques and history of crypto-analysis of arithmetic constructions. It’s still a new ground and area of active research.

 Post quantum signature size

-+ Alan suggestion: Falcon: speed / size ration - very good.
-+ Aaron - should we think about it?
+* Alan suggestion: Falcon: speed / size ration - very good.
+* Aaron - should we think about it?
  Alan: based on early extrapolation this thing will get able to break EC cryptography in 2050 . But that’s a lot of uncertainty. But there is magic happening with recurions / linking / simulation and that can speedup the progress.

 Other ideas

-+ Let’s say we use same key and two different address algorithms for 2 different use cases. Is it still safe to use it? Alan: if we want to hide the public key (which is not our use case), then it’s less secure but there are fixes.
+* Let’s say we use same key and two different address algorithms for 2 different use cases. Is it still safe to use it? Alan: if we want to hide the public key (which is not our use case), then it’s less secure but there are fixes.

 ### References

-+ [Notes](https://hackmd.io/_NGWI4xZSbKzj1BkCqyZMw)
+* [Notes](https://hackmd.io/_NGWI4xZSbKzj1BkCqyZMw)
@@ -2,8 +2,8 @@

 ## Changelog

- 2020/08/18: Initial Draft
- 2021/05/05: Removed height based expiration support and simplified naming.
+* 2020/08/18: Initial Draft
+* 2021/05/05: Removed height based expiration support and simplified naming.

 ## Status

@@ -137,17 +137,17 @@ set and correctly deduct fees based on fee allowances.

 ### Positive

- improved UX for use cases where it is cumbersome to maintain an account balance just for fees
+* improved UX for use cases where it is cumbersome to maintain an account balance just for fees

 ### Negative

 ### Neutral

- a new field must be added to the transaction `Fee` message and a new `AnteDecorator` must be
+* a new field must be added to the transaction `Fee` message and a new `AnteDecorator` must be
 created to use it

 ## References

- Blog article describing initial work: https://medium.com/regen-network/hacking-the-cosmos-cosmwasm-and-key-management-a08b9f561d1b
- Initial public specification: https://gist.github.com/aaronc/b60628017352df5983791cad30babe56
- Original subkeys proposal from B-harvest which influenced this design: https://github.com/cosmos/cosmos-sdk/issues/4480
+* Blog article describing initial work: <https://medium.com/regen-network/hacking-the-cosmos-cosmwasm-and-key-management-a08b9f561d1b>
+* Initial public specification: <https://gist.github.com/aaronc/b60628017352df5983791cad30babe56>
+* Original subkeys proposal from B-harvest which influenced this design: <https://github.com/cosmos/cosmos-sdk/issues/4480>
@@ -2,10 +2,10 @@

 ## Changelog

- 2019-11-06: Initial Draft
- 2020-10-12: Updated Draft
- 2020-11-13: Accepted
- 2020-05-06: proto API updates, use `sdk.Msg` instead of `sdk.ServiceMsg` (the latter concept was removed from Cosmos SDK)
+* 2019-11-06: Initial Draft
+* 2020-10-12: Updated Draft
+* 2020-11-13: Accepted
+* 2020-05-06: proto API updates, use `sdk.Msg` instead of `sdk.ServiceMsg` (the latter concept was removed from Cosmos SDK)

 ## Status

@@ -20,9 +20,9 @@ on behalf of that account to other accounts.

 The concrete use cases which motivated this module include:

- the desire to delegate the ability to vote on proposals to other accounts besides the account which one has
+* the desire to delegate the ability to vote on proposals to other accounts besides the account which one has
 delegated stake
- "sub-keys" functionality, as originally proposed in [\#4480](https://github.com/cosmos/cosmos-sdk/issues/4480) which
+* "sub-keys" functionality, as originally proposed in [\#4480](https://github.com/cosmos/cosmos-sdk/issues/4480) which
 is a term used to describe the functionality provided by this module together with
 the `fee_grant` module from [ADR 029](./adr-029-fee-grant-module.md) and the [group module](https://github.com/regen-network/cosmos-modules/tree/master/incubator/group).

@@ -232,9 +232,9 @@ message GenericAuthorization {

 ### Positive

- Users will be able to authorize arbitrary actions on behalf of their accounts to other
+* Users will be able to authorize arbitrary actions on behalf of their accounts to other
 users, improving key management for many use cases
- The solution is more generic than previously considered approaches and the
+* The solution is more generic than previously considered approaches and the
 `Authorization` interface approach can be extended to cover other use cases by
 SDK users

@@ -244,6 +244,6 @@ SDK users

 ## References

- Initial Hackatom implementation: https://github.com/cosmos-gaians/cosmos-sdk/tree/hackatom/x/delegation
- Post-Hackatom spec: https://gist.github.com/aaronc/b60628017352df5983791cad30babe56#delegation-module
- B-Harvest subkeys spec: https://github.com/cosmos/cosmos-sdk/issues/4480
+* Initial Hackatom implementation: <https://github.com/cosmos-gaians/cosmos-sdk/tree/hackatom/x/delegation>
+* Post-Hackatom spec: <https://gist.github.com/aaronc/b60628017352df5983791cad30babe56#delegation-module>
+* B-Harvest subkeys spec: <https://github.com/cosmos/cosmos-sdk/issues/4480>
@@ -2,8 +2,8 @@

 ## Changelog

- 2020-10-05: Initial Draft
- 2021-04-21: Remove `ServiceMsg`s to follow Protobuf `Any`'s spec, see [#9063](https://github.com/cosmos/cosmos-sdk/issues/9063).
+* 2020-10-05: Initial Draft
+* 2021-04-21: Remove `ServiceMsg`s to follow Protobuf `Any`'s spec, see [#9063](https://github.com/cosmos/cosmos-sdk/issues/9063).

 ## Status

@@ -41,7 +41,7 @@ This isn’t really documented anywhere and clients would need to know the inter
 of the Cosmos SDK to parse that value and return it to users.

 Also, there may be cases where we want to use these return values programatically.
-For instance, https://github.com/cosmos/cosmos-sdk/issues/7093 proposes a method for
+For instance, <https://github.com/cosmos/cosmos-sdk/issues/7093> proposes a method for
 doing inter-module Ocaps using the `Msg` router. A well-defined return type would
 improve the developer UX for this approach.

@@ -183,20 +183,20 @@ Finally, closing a module to client API opens desirable OCAP patterns discussed

 ### Pros

- communicates return type clearly
- manual handler registration and return type marshaling is no longer needed, just implement the interface and register it
- communication interface is automatically generated, the developer can now focus only on the state transition methods - this would improve the UX of [\#7093](https://github.com/cosmos/cosmos-sdk/issues/7093) approach (1) if we chose to adopt that
- generated client code could be useful for clients and tests
- dramatically reduces and simplifies the code
+* communicates return type clearly
+* manual handler registration and return type marshaling is no longer needed, just implement the interface and register it
+* communication interface is automatically generated, the developer can now focus only on the state transition methods - this would improve the UX of [\#7093](https://github.com/cosmos/cosmos-sdk/issues/7093) approach (1) if we chose to adopt that
+* generated client code could be useful for clients and tests
+* dramatically reduces and simplifies the code

 ### Cons

- using `service` definitions outside the context of gRPC could be confusing (but doesn’t violate the proto3 spec)
+* using `service` definitions outside the context of gRPC could be confusing (but doesn’t violate the proto3 spec)

 ## References

- [Initial Github Issue \#7122](https://github.com/cosmos/cosmos-sdk/issues/7122)
- [proto 3 Language Guide: Defining Services](https://developers.google.com/protocol-buffers/docs/proto3#services)
- [Initial pre-`Any` `Msg` designs](https://docs.google.com/document/d/1eEgYgvgZqLE45vETjhwIw4VOqK-5hwQtZtjVbiXnIGc)
- [ADR 020](./adr-020-protobuf-transaction-encoding.md)
- [ADR 021](./adr-021-protobuf-query-encoding.md)
+* [Initial Github Issue \#7122](https://github.com/cosmos/cosmos-sdk/issues/7122)
+* [proto 3 Language Guide: Defining Services](https://developers.google.com/protocol-buffers/docs/proto3#services)
+* [Initial pre-`Any` `Msg` designs](https://docs.google.com/document/d/1eEgYgvgZqLE45vETjhwIw4VOqK-5hwQtZtjVbiXnIGc)
+* [ADR 020](./adr-020-protobuf-transaction-encoding.md)
+* [ADR 021](./adr-021-protobuf-query-encoding.md)
@@ -2,13 +2,13 @@

 ## Changelog

- 28-Sept-2020: Initial Draft
+* 28-Sept-2020: Initial Draft

 ## Authors

- Anil Kumar (@anilcse)
- Jack Zampolin (@jackzampolin)
- Adam Bozanich (@boz)
+* Anil Kumar (@anilcse)
+* Jack Zampolin (@jackzampolin)
+* Adam Bozanich (@boz)

 ## Status

@@ -34,7 +34,7 @@ This proposal is specifically about how to consume these events as a client of t

 ## Decision

-__Step-1__:  Implement additional functionality in the `types` package: `EmitTypedEvent` and `ParseTypedEvent` functions
+**Step-1**:  Implement additional functionality in the `types` package: `EmitTypedEvent` and `ParseTypedEvent` functions

 ```go
 // types/events.go
@@ -111,7 +111,7 @@ Here, the `EmitTypedEvent` is a method on `EventManager` which takes typed event

 When we subscribe to emitted events on the tendermint websocket, they are emitted in the form of an `abci.Event`. `ParseTypedEvent` parses the event back to it's original proto message.

-__Step-2__: Add proto definitions for typed events for msgs in each module:
+**Step-2**: Add proto definitions for typed events for msgs in each module:

 For example, let's take `MsgSubmitProposal` of `gov` module and implement this event's type.

@@ -128,7 +128,7 @@ message EventSubmitProposal {
 }
 ```

-__Step-3__: Refactor event emission to use the typed event created and emit using `sdk.EmitTypedEvent`:
+**Step-3**: Refactor event emission to use the typed event created and emit using `sdk.EmitTypedEvent`:

 ```go
 // x/gov/handler.go
@@ -145,7 +145,7 @@ func handleMsgSubmitProposal(ctx sdk.Context, keeper keeper.Keeper, msg types.Ms
 }
 ```

-#### How to subscribe to these typed events in `Client`
+### How to subscribe to these typed events in `Client`

 > NOTE: Full code example below

@@ -315,5 +315,5 @@ func PublishChainTxEvents(ctx context.Context, client tmclient.EventsClient, bus

 ## References

- [Publish Custom Events via a bus](https://github.com/ovrclk/akash/blob/90d258caeb933b611d575355b8df281208a214f8/events/publish.go#L19-L58)
- [Consuming the events in `Client`](https://github.com/ovrclk/deploy/blob/bf6c633ab6c68f3026df59efd9982d6ca1bf0561/cmd/event-handlers.go#L57)
+* [Publish Custom Events via a bus](https://github.com/ovrclk/akash/blob/90d258caeb933b611d575355b8df281208a214f8/events/publish.go#L19-L58)
+* [Consuming the events in `Client`](https://github.com/ovrclk/deploy/blob/bf6c633ab6c68f3026df59efd9982d6ca1bf0561/cmd/event-handlers.go#L57)
@@ -2,7 +2,7 @@

 ## Changelog

- 2020-10-05: Initial Draft
+* 2020-10-05: Initial Draft

 ## Status

@@ -14,9 +14,9 @@ This ADR introduces a system for permissioned inter-module communication leverag
 service definitions defined in [ADR 021](./adr-021-protobuf-query-encoding.md) and
 [ADR 031](./adr-031-msg-service.md) which provides:

- stable protobuf based module interfaces to potentially later replace the keeper paradigm
- stronger inter-module object capabilities (OCAPs) guarantees
- module accounts and sub-account authorization
+* stable protobuf based module interfaces to potentially later replace the keeper paradigm
+* stronger inter-module object capabilities (OCAPs) guarantees
+* module accounts and sub-account authorization

 ## Context

@@ -99,8 +99,8 @@ transaction

 This mechanism has the added benefits of:

- reducing boilerplate through code generation, and
- allowing for modules in other languages either via a VM like CosmWasm or sub-processes using gRPC
+* reducing boilerplate through code generation, and
+* allowing for modules in other languages either via a VM like CosmWasm or sub-processes using gRPC

 ### Inter-module Communication

@@ -376,16 +376,16 @@ replacing `Keeper` interfaces altogether.

 ### Positive

- an alternative to keepers which can more easily lead to stable inter-module interfaces
- proper inter-module OCAPs
- improved module developer DevX, as commented on by several particpants on
+* an alternative to keepers which can more easily lead to stable inter-module interfaces
+* proper inter-module OCAPs
+* improved module developer DevX, as commented on by several particpants on
    [Architecture Review Call, Dec 3](https://hackmd.io/E0wxxOvRQ5qVmTf6N_k84Q)
- lays the groundwork for what can be a greatly simplified `app.go`
- router can be setup to enforce atomic transactions for module-to-module calls
+* lays the groundwork for what can be a greatly simplified `app.go`
+* router can be setup to enforce atomic transactions for module-to-module calls

 ### Negative

- modules which adopt this will need significant refactoring
+* modules which adopt this will need significant refactoring

 ### Neutral

@@ -393,8 +393,8 @@ replacing `Keeper` interfaces altogether.

 ## References

- [ADR 021](./adr-021-protobuf-query-encoding.md)
- [ADR 031](./adr-031-msg-service.md)
- [ADR 028](./adr-028-public-key-addresses.md)
- [ADR 030 draft](https://github.com/cosmos/cosmos-sdk/pull/7105)
- [Object-Capability Model](../docs/core/ocap.md)
+* [ADR 021](./adr-021-protobuf-query-encoding.md)
+* [ADR 031](./adr-031-msg-service.md)
+* [ADR 028](./adr-028-public-key-addresses.md)
+* [ADR 030 draft](https://github.com/cosmos/cosmos-sdk/pull/7105)
+* [Object-Capability Model](../docs/core/ocap.md)
@@ -2,7 +2,7 @@

 ## Changelog

- 30-09-2020: Initial Draft
+* 30-09-2020: Initial Draft

 ## Status

@@ -73,4 +73,4 @@ Breaks the current assumed relationship between address and pubkeys as H(pubkey)

 ## References

-+ https://www.algorand.com/resources/blog/announcing-rekeying
+* <https://www.algorand.com/resources/blog/announcing-rekeying>
@@ -2,14 +2,14 @@

 ## Authors

- Jonathan Gimeno (@jgimeno)
- David Grierson (@senormonito)
- Alessio Treglia (@alessio)
- Frojdy Dymylja (@fdymylja)
+* Jonathan Gimeno (@jgimeno)
+* David Grierson (@senormonito)
+* Alessio Treglia (@alessio)
+* Frojdy Dymylja (@fdymylja)

 ## Changelog

- 2021-05-12: the external library  [cosmos-rosetta-gateway](https://github.com/tendermint/cosmos-rosetta-gateway) has been moved within the Cosmos SDK.
+* 2021-05-12: the external library  [cosmos-rosetta-gateway](https://github.com/tendermint/cosmos-rosetta-gateway) has been moved within the Cosmos SDK.

 ## Context

@@ -203,9 +203,9 @@ Proposed

 ### Positive

- Out-of-the-box Rosetta API support within Cosmos SDK.
- Blockchain interface standardisation
+* Out-of-the-box Rosetta API support within Cosmos SDK.
+* Blockchain interface standardisation

 ## References

- https://www.rosetta-api.org/
+* <https://www.rosetta-api.org/>
@@ -2,14 +2,14 @@

 ## Changelog

- 28/10/2020 - Initial draft
+* 28/10/2020 - Initial draft

 ## Authors

- Antoine Herzog (@antoineherzog)
- Zaki Manian (@zmanian)
- Aleksandr Bezobchuk (alexanderbez) [1]
- Frojdi Dymylja (@fdymylja)
+* Antoine Herzog (@antoineherzog)
+* Zaki Manian (@zmanian)
+* Aleksandr Bezobchuk (alexanderbez) [1]
+* Frojdi Dymylja (@fdymylja)

 ## Status

@@ -41,11 +41,11 @@ Create the `offchain` proto definitions, we extend the auth module with `offchai

 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 “”
- fee gas must be equal to 0
- fee amount must be an empty array
+* the memo must be empty
+* nonce, sequence number must be equal to 0
+* chain-id must be equal to “”
+* fee gas must be equal to 0
+* fee amount must be an empty array

 Verification of an offchain transaction follows the same rules as an onchain one, except for the spec differences highlighted above.

@@ -110,23 +110,23 @@ Backwards compatibility is maintained as this is a new message spec definition.

 ### Positive

- A common format that can be used by multiple applications to sign and verify off-chain messages.
- The specification is primitive which means it can cover every use case without limiting what is possible to fit inside it.
- It gives room for other off-chain messages specifications that aim to target more specific and common use cases such as off-chain-based authN/authZ layers [2].
+* A common format that can be used by multiple applications to sign and verify off-chain messages.
+* The specification is primitive which means it can cover every use case without limiting what is possible to fit inside it.
+* It gives room for other off-chain messages specifications that aim to target more specific and common use cases such as off-chain-based authN/authZ layers [2].

 ### Negative

- Current proposal requires a fixed relationship between an account address and a public key.
- Doesn't work with multisig accounts.
+* Current proposal requires a fixed relationship between an account address and a public key.
+* Doesn't work with multisig accounts.

 ## Further discussion

- Regarding security in `MsgSignData`, the developer using `MsgSignData` is in charge of making the content laying in `Data` non-replayable when, and if, needed.
- the offchain package will be further extended with extra messages that target specific use cases such as, but not limited to, authentication in applications, payment channels, L2 solutions in general.
+* Regarding security in `MsgSignData`, the developer using `MsgSignData` is in charge of making the content laying in `Data` non-replayable when, and if, needed.
+* the offchain package will be further extended with extra messages that target specific use cases such as, but not limited to, authentication in applications, payment channels, L2 solutions in general.

 ## References

-1. https://github.com/cosmos/ics/pull/33
-2. https://github.com/cosmos/cosmos-sdk/pull/7727#discussion_r515668204
-3. https://github.com/cosmos/cosmos-sdk/pull/7727#issuecomment-722478477
-4. https://github.com/cosmos/cosmos-sdk/pull/7727#issuecomment-721062923
+1. <https://github.com/cosmos/ics/pull/33>
+2. <https://github.com/cosmos/cosmos-sdk/pull/7727#discussion_r515668204>
+3. <https://github.com/cosmos/cosmos-sdk/pull/7727#issuecomment-722478477>
+4. <https://github.com/cosmos/cosmos-sdk/pull/7727#issuecomment-721062923>
@@ -2,7 +2,7 @@

 ## Changelog

- 2020/10/28: Intial draft
+* 2020/10/28: Intial draft

 ## Status

@@ -22,7 +22,7 @@ However, often times the entity owning that address might not be a single indivi

 We modify the vote structs to be

-```
+```go
 type WeightedVoteOption struct {
  Option string
  Weight sdk.Dec
@@ -37,7 +37,7 @@ type Vote struct {

 And for backwards compatibility, we introduce `MsgVoteWeighted` while keeping `MsgVote`.

-```
+```go
 type MsgVote struct {
  ProposalID int64
  Voter      sdk.Address
@@ -58,7 +58,7 @@ The `ValidateBasic` of a `MsgVoteWeighted` struct would require that

 The governance tally function will iterate over all the options in a vote and add to the tally the result of the voter's voting power * the rate for that option.

-```
+```go
 tally() {
    results := map[types.VoteOption]sdk.Dec

@@ -78,7 +78,7 @@ simd tx gov vote 1 "yes=0.6,no=0.3,abstain=0.05,no_with_veto=0.05" --from mykey

 To create a single-option vote a user can do either

-```
+```sh
 simd tx gov vote 1 "yes=1" --from mykey
 ```

@@ -94,18 +94,18 @@ to maintain backwards compatibility.

 ### Backwards Compatibility

- Previous VoteMsg types will remain the same and so clients will not have to update their procedure unless they want to support the WeightedVoteMsg feature.
- When querying a Vote struct from state, its structure will be different, and so clients wanting to display all voters and their respective votes will have to handle the new format and the fact that a single voter can have split votes.
- The result of querying the tally function should have the same API for clients.
+* Previous VoteMsg types will remain the same and so clients will not have to update their procedure unless they want to support the WeightedVoteMsg feature.
+* When querying a Vote struct from state, its structure will be different, and so clients wanting to display all voters and their respective votes will have to handle the new format and the fact that a single voter can have split votes.
+* The result of querying the tally function should have the same API for clients.

 ### Positive

- Can make the voting process more accurate for addresses representing multiple stakeholders, often some of the largest addresses.
+* Can make the voting process more accurate for addresses representing multiple stakeholders, often some of the largest addresses.

 ### Negative

- Is more complex than simple voting, and so may be harder to explain to users.  However, this is mostly mitigated because the feature is opt-in.
+* Is more complex than simple voting, and so may be harder to explain to users.  However, this is mostly mitigated because the feature is opt-in.

 ### Neutral

- Relatively minor change to governance tally function.
+* Relatively minor change to governance tally function.
@@ -2,7 +2,7 @@

 ## Changelog

- 11/23/2020: Initial draft
+* 11/23/2020: Initial draft

 ## Status

@@ -535,17 +535,17 @@ These changes will provide a means of subscribing to KVStore state changes in re

 ### Backwards Compatibility

- This ADR changes the `MultiStore`, `CacheWrap`, and `CacheWrapper` interfaces, implementations supporting the previous version of these interfaces will not support the new ones
+* This ADR changes the `MultiStore`, `CacheWrap`, and `CacheWrapper` interfaces, implementations supporting the previous version of these interfaces will not support the new ones

 ### Positive

- Ability to listen to KVStore state changes in real time and expose these events to external consumers
+* Ability to listen to KVStore state changes in real time and expose these events to external consumers

 ### Negative

- Changes `MultiStore`, `CacheWrap`, and `CacheWrapper` interfaces
+* Changes `MultiStore`, `CacheWrap`, and `CacheWrapper` interfaces

 ### Neutral

- Introduces additional- but optional- complexity to configuring and running a cosmos application
- If an application developer opts to use these features to expose data, they need to be aware of the ramifications/risks of that data exposure as it pertains to the specifics of their application
+* Introduces additional- but optional- complexity to configuring and running a cosmos application
+* If an application developer opts to use these features to expose data, they need to be aware of the ramifications/risks of that data exposure as it pertains to the specifics of their application
@@ -2,12 +2,12 @@

 ## Changelog

- 10-Feb-2021: Initial Draft
+* 10-Feb-2021: Initial Draft

 ## Authors

- Dev Ojha (@valardragon)
- Sunny Aggarwal (@sunnya97)
+* Dev Ojha (@valardragon)
+* Sunny Aggarwal (@sunnya97)

 ## Status

@@ -43,10 +43,10 @@ There is a design consideration for whether to apply a slash immediately or at t

 Applying it immediately can be viewed as offering greater consensus layer security, at potential costs to the aforementioned usecases. The benefits of immediate slashing for consensus layer security can be all be obtained by executing the validator jailing immediately (thus removing it from the validator set), and delaying the actual slash change to the validator's weight until the epoch boundary. For the use cases mentioned above, workarounds can be integrated to avoid problems, as follows:

- For threshold based cryptography, this setting will have the threshold cryptography use the original epoch weights, while consensus has an update that lets it more rapidly benefit from additional security. If the threshold based cryptography blocks liveness of the chain, then we have effectively raised the liveness threshold of the remaining validators for the rest of the epoch. (Alternatively, jailed nodes could still contribute shares) This plan will fail in the extreme case that more than 1/3rd of the validators have been jailed within a single epoch. For such an extreme scenario, the chain already have its own custom incident response plan, and defining how to handle the threshold cryptography should be a part of that.
- For light client efficiency, there can be a bit included in the header indicating an intra-epoch slash (ala https://github.com/tendermint/spec/issues/199).
- For fairness of deterministic leader election, applying a slash or jailing within an epoch would break the guarantee we were seeking to provide. This then re-introduces a new (but significantly simpler) problem for trying to provide fairness guarantees. Namely, that validators can adversarially elect to remove themself from the set of proposers. From a security perspective, this could potentially be handled by two different mechanisms (or prove to still be too difficult to achieve). One is making a security statement acknowledging the ability for an adversary to force an ahead-of-time fixed threshold of users to drop out of the proposer set within an epoch. The second method would be to  parameterize such that the cost of a slash within the epoch far outweights benefits due to being a proposer. However, this latter criterion is quite dubious, since being a proposer can have many advantageous side-effects in chains with complex state machines. (Namely, DeFi games such as Fomo3D)
- For staking derivative design, there is no issue introduced. This does not increase the state size of staking records, since whether a slash has occured is fully queryable given the validator address.
+* For threshold based cryptography, this setting will have the threshold cryptography use the original epoch weights, while consensus has an update that lets it more rapidly benefit from additional security. If the threshold based cryptography blocks liveness of the chain, then we have effectively raised the liveness threshold of the remaining validators for the rest of the epoch. (Alternatively, jailed nodes could still contribute shares) This plan will fail in the extreme case that more than 1/3rd of the validators have been jailed within a single epoch. For such an extreme scenario, the chain already have its own custom incident response plan, and defining how to handle the threshold cryptography should be a part of that.
+* For light client efficiency, there can be a bit included in the header indicating an intra-epoch slash (ala <https://github.com/tendermint/spec/issues/199>).
+* For fairness of deterministic leader election, applying a slash or jailing within an epoch would break the guarantee we were seeking to provide. This then re-introduces a new (but significantly simpler) problem for trying to provide fairness guarantees. Namely, that validators can adversarially elect to remove themself from the set of proposers. From a security perspective, this could potentially be handled by two different mechanisms (or prove to still be too difficult to achieve). One is making a security statement acknowledging the ability for an adversary to force an ahead-of-time fixed threshold of users to drop out of the proposer set within an epoch. The second method would be to  parameterize such that the cost of a slash within the epoch far outweights benefits due to being a proposer. However, this latter criterion is quite dubious, since being a proposer can have many advantageous side-effects in chains with complex state machines. (Namely, DeFi games such as Fomo3D)
+* For staking derivative design, there is no issue introduced. This does not increase the state size of staking records, since whether a slash has occured is fully queryable given the validator address.

 ### Token lockup

@@ -73,36 +73,36 @@ Until an ABCI mechanism for variable block times is introduced, it is ill-advise

 ## Decision

-__Step-1__:  Implement buffering of all staking and slashing messages.
+**Step-1**:  Implement buffering of all staking and slashing messages.

 First we create a pool for storing tokens that are being bonded, but should be applied at the epoch boundary called the `EpochDelegationPool`. Then, we have two separate queues, one for staking, one for slashing. We describe what happens on each message being delivered below:

 ### Staking messages

- **MsgCreateValidator**: Move user's self-bond to `EpochDelegationPool` immediately. Queue a message for the epoch boundary to handle the self-bond, taking the funds from the `EpochDelegationPool`. If Epoch execution fail, return back funds from `EpochDelegationPool` to user's account.
- **MsgEditValidator**: Validate message and if valid queue the message for execution at the end of the Epoch.
- **MsgDelegate**: Move user's funds to `EpochDelegationPool` immediately. Queue a message for the epoch boundary to handle the delegation, taking the funds from the `EpochDelegationPool`. If Epoch execution fail, return back funds from `EpochDelegationPool` to user's account.
- **MsgBeginRedelegate**: Validate message and if valid queue the message for execution at the end of the Epoch.
- **MsgUndelegate**: Validate message and if valid queue the message for execution at the end of the Epoch.
+* **MsgCreateValidator**: Move user's self-bond to `EpochDelegationPool` immediately. Queue a message for the epoch boundary to handle the self-bond, taking the funds from the `EpochDelegationPool`. If Epoch execution fail, return back funds from `EpochDelegationPool` to user's account.
+* **MsgEditValidator**: Validate message and if valid queue the message for execution at the end of the Epoch.
+* **MsgDelegate**: Move user's funds to `EpochDelegationPool` immediately. Queue a message for the epoch boundary to handle the delegation, taking the funds from the `EpochDelegationPool`. If Epoch execution fail, return back funds from `EpochDelegationPool` to user's account.
+* **MsgBeginRedelegate**: Validate message and if valid queue the message for execution at the end of the Epoch.
+* **MsgUndelegate**: Validate message and if valid queue the message for execution at the end of the Epoch.

 ### Slashing messages

- **MsgUnjail**: Validate message and if valid queue the message for execution at the end of the Epoch.
- **Slash Event**: Whenever a slash event is created, it gets queued in the slashing module to apply at the end of the epoch. The queues should be setup such that this slash applies immediately.
+* **MsgUnjail**: Validate message and if valid queue the message for execution at the end of the Epoch.
+* **Slash Event**: Whenever a slash event is created, it gets queued in the slashing module to apply at the end of the epoch. The queues should be setup such that this slash applies immediately.

 ### Evidence Messages

- **MsgSubmitEvidence**: This gets executed immediately, and the validator gets jailed immediately. However in slashing, the actual slash event gets queued.
+* **MsgSubmitEvidence**: This gets executed immediately, and the validator gets jailed immediately. However in slashing, the actual slash event gets queued.

 Then we add methods to the end blockers, to ensure that at the epoch boundary the queues are cleared and delegation updates are applied.

-__Step-2__: Implement querying of queued staking txs.
+**Step-2**: Implement querying of queued staking txs.

 When querying the staking activity of a given address, the status should return not only the amount of tokens staked, but also if there are any queued stake events for that address. This will require more work to be done in the querying logic, to trace the queued upcoming staking events.

 As an initial implementation, this can be implemented as a linear search over all queued staking events. However, for chains that need long epochs, they should eventually build additional support for nodes that support querying to be able to produce results in constant time. (This is do-able by maintaining an auxilliary hashmap for indexing upcoming staking events by address)

-__Step-3__: Adjust gas
+**Step-3**: Adjust gas

 Currently gas represents the cost of executing a transaction when its done immediately. (Merging together costs of p2p overhead, state access overhead, and computational overhead) However, now a transaction can cause computation in a future block, namely at the epoch boundary.

@@ -2,7 +2,7 @@

 ## Changelog

- 2020-01-15: Draft
+* 2020-01-15: Draft

 ## Status

@@ -19,11 +19,11 @@ Currently, Cosmos SDK uses IAVL for both state [commitments](https://cryptograph
 IAVL has effectively become an orphaned project within the Cosmos ecosystem and it's proven to be an inefficient state commitment data structure.
 In the current design, IAVL is used for both data storage and as a Merkle Tree for state commitments. IAVL is meant to be a standalone Merkelized key/value database, however it's using a KV DB engine to store all tree nodes. So, each node is stored in a separate record in the KV DB. This causes many inefficiencies and problems:

-+ Each object query requires a tree traversal from the root. Subsequent queries for the same object are cached on the Cosmos SDK level.
-+ Each edge traversal requires a DB query.
-+ Creating snapshots is [expensive](https://github.com/cosmos/cosmos-sdk/issues/7215#issuecomment-684804950). It takes about 30 seconds to export less than 100 MB of state (as of March 2020).
-+ Updates in IAVL may trigger tree reorganization and possible O(log(n)) hashes re-computation, which can become a CPU bottleneck.
-+ The node structure is pretty expensive - it contains a standard tree node elements (key, value, left and right element) and additional metadata such as height, version (which is not required by the Cosmos SDK). The entire node is hashed, and that hash is used as the key in the underlying database, [ref](https://github.com/cosmos/iavl/blob/master/docs/node/node.md
+* Each object query requires a tree traversal from the root. Subsequent queries for the same object are cached on the Cosmos SDK level.
+* Each edge traversal requires a DB query.
+* Creating snapshots is [expensive](https://github.com/cosmos/cosmos-sdk/issues/7215#issuecomment-684804950). It takes about 30 seconds to export less than 100 MB of state (as of March 2020).
+* Updates in IAVL may trigger tree reorganization and possible O(log(n)) hashes re-computation, which can become a CPU bottleneck.
+* The node structure is pretty expensive - it contains a standard tree node elements (key, value, left and right element) and additional metadata such as height, version (which is not required by the Cosmos SDK). The entire node is hashed, and that hash is used as the key in the underlying database, [ref](https://github.com/cosmos/iavl/blob/master/docs/node/node.md
 ).

 Moreover, the IAVL project lacks support and a maintainer and we already see better and well-established alternatives. Instead of optimizing the IAVL, we are looking into other solutions for both storage and state commitments.
@@ -54,18 +54,18 @@ We propose to use a KV database for both `SS` and `SC`. The store interface will

 State Storage requirements:

-+ range queries
-+ quick (key, value) access
-+ creating a snapshot
-+ historical versioning
-+ pruning (garbage collection)
+* range queries
+* quick (key, value) access
+* creating a snapshot
+* historical versioning
+* pruning (garbage collection)

 State Commitment requirements:

-+ fast updates
-+ tree path should be short
-+ query historical commitment proofs using ICS-23 standard
-+ pruning (garbage collection)
+* fast updates
+* tree path should be short
+* query historical commitment proofs using ICS-23 standard
+* pruning (garbage collection)

 ### SMT for State Commitment

@@ -192,9 +192,9 @@ The presented workaround can be used until the IBC module is fully upgraded to s

 We consider a compression of prefix keys by creating a mapping from module key to an integer, and serializing the integer using varint coding. Varint coding assures that different values don't have common byte prefix. For Merkle Proofs we can't use prefix compression - so it should only apply for the `SS` keys. Moreover, the prefix compression should be only applied for the module namespace. More precisely:

-+ each module has it's own namespace;
-+ when accessing a module namespace we create a KVStore with embedded prefix;
-+ that prefix will be compressed only when accessing and managing `SS`.
+* each module has it's own namespace;
+* when accessing a module namespace we create a KVStore with embedded prefix;
+* that prefix will be compressed only when accessing and managing `SS`.

 We need to assure that the codes won't change. We can fix the mapping in a static variable (provided by an app) or SS state under a special key.

@@ -209,10 +209,11 @@ TODO: finalize this or move to another ADR.
 ## Migration

 Using the new store will require a migration. 2 Migrations are proposed:
+
 1. Genesis export -- it will reset the blockchain history.
 2. In place migration: we can reuse `UpgradeKeeper.SetUpgradeHandler` to provide the migration logic:

-    ```go 
+```go 
 app.UpgradeKeeper.SetUpgradeHandler("adr-40", func(ctx sdk.Context, plan upgradetypes.Plan, vm module.VersionMap) (module.VersionMap, error) {

    storev2.Migrate(iavlstore, v2.store)
@@ -221,7 +222,7 @@ app.UpgradeKeeper.SetUpgradeHandler("adr-40", func(ctx sdk.Context, plan upgrade
    // with the updated module ConsensusVersions
    return app.mm.RunMigrations(ctx, vm)
 })
-    ```
+```

 The `Migrate` function will read all entries from a store/v1 DB and save them to the AD-40 combined KV store. 
 Cache layer should not be used and the operation must finish with a single Commit call.
@@ -239,21 +240,21 @@ We change the storage layout of the state machine, a storage hard fork and netwo

 ### Positive

-+ Decoupling state from state commitment introduce better engineering opportunities for further optimizations and better storage patterns.
-+ Performance improvements.
-+ Joining SMT based camp which has wider and proven adoption than IAVL. Example projects which decided on SMT: Ethereum2, Diem (Libra), Trillan, Tezos, Celestia.
-+ Multistore removal fixes a longstanding issue with the current MultiStore design.
-+ Simplifies merkle proofs - all modules, except IBC, have only one pass for merkle proof.
+* Decoupling state from state commitment introduce better engineering opportunities for further optimizations and better storage patterns.
+* Performance improvements.
+* Joining SMT based camp which has wider and proven adoption than IAVL. Example projects which decided on SMT: Ethereum2, Diem (Libra), Trillan, Tezos, Celestia.
+* Multistore removal fixes a longstanding issue with the current MultiStore design.
+* Simplifies merkle proofs - all modules, except IBC, have only one pass for merkle proof.

 ### Negative

-+ Storage migration
-+ LL SMT doesn't support pruning - we will need to add and test that functionality.
-+ `SS` keys will have an overhead of a key prefix. This doesn't impact `SC` because all keys in `SC` have same size (they are hashed).
+* Storage migration
+* LL SMT doesn't support pruning - we will need to add and test that functionality.
+* `SS` keys will have an overhead of a key prefix. This doesn't impact `SC` because all keys in `SC` have same size (they are hashed).

 ### Neutral

-+ Deprecating IAVL, which is one of the core proposals of Cosmos Whitepaper.
+* Deprecating IAVL, which is one of the core proposals of Cosmos Whitepaper.

 ## Alternative designs

@@ -277,12 +278,12 @@ We were discussing use case where modules can use a support database, which is n

 ## References

-+ [IAVL What's Next?](https://github.com/cosmos/cosmos-sdk/issues/7100)
-+ [IAVL overview](https://docs.google.com/document/d/16Z_hW2rSAmoyMENO-RlAhQjAG3mSNKsQueMnKpmcBv0/edit#heading=h.yd2th7x3o1iv) of it's state v0.15
-+ [State commitments and storage report](https://paper.dropbox.com/published/State-commitments-and-storage-review--BDvA1MLwRtOx55KRihJ5xxLbBw-KeEB7eOd11pNrZvVtqUgL3h)
-+ [Celestia (LazyLedger) SMT](https://github.com/lazyledger/smt)
-+ Facebook Diem (Libra) SMT [design](https://developers.diem.com/papers/jellyfish-merkle-tree/2021-01-14.pdf)
-+ [Trillian Revocation Transparency](https://github.com/google/trillian/blob/master/docs/papers/RevocationTransparency.pdf), [Trillian Verifiable Data Structures](https://github.com/google/trillian/blob/master/docs/papers/VerifiableDataStructures.pdf).
-+ Design and implementation [discussion](https://github.com/cosmos/cosmos-sdk/discussions/8297).
-+ [How to Upgrade IBC Chains and their Clients](https://github.com/cosmos/ibc-go/blob/main/docs/ibc/upgrades/quick-guide.md)
-+ [ADR-40 Effect on IBC](https://github.com/cosmos/ibc-go/discussions/256)
+* [IAVL What's Next?](https://github.com/cosmos/cosmos-sdk/issues/7100)
+* [IAVL overview](https://docs.google.com/document/d/16Z_hW2rSAmoyMENO-RlAhQjAG3mSNKsQueMnKpmcBv0/edit#heading=h.yd2th7x3o1iv) of it's state v0.15
+* [State commitments and storage report](https://paper.dropbox.com/published/State-commitments-and-storage-review--BDvA1MLwRtOx55KRihJ5xxLbBw-KeEB7eOd11pNrZvVtqUgL3h)
+* [Celestia (LazyLedger) SMT](https://github.com/lazyledger/smt)
+* Facebook Diem (Libra) SMT [design](https://developers.diem.com/papers/jellyfish-merkle-tree/2021-01-14.pdf)
+* [Trillian Revocation Transparency](https://github.com/google/trillian/blob/master/docs/papers/RevocationTransparency.pdf), [Trillian Verifiable Data Structures](https://github.com/google/trillian/blob/master/docs/papers/VerifiableDataStructures.pdf).
+* Design and implementation [discussion](https://github.com/cosmos/cosmos-sdk/discussions/8297).
+* [How to Upgrade IBC Chains and their Clients](https://github.com/cosmos/ibc-go/blob/main/docs/ibc/upgrades/quick-guide.md)
+* [ADR-40 Effect on IBC](https://github.com/cosmos/ibc-go/discussions/256)
@@ -2,7 +2,7 @@

 ## Changelog

- 17.02.2021: Initial Draft
+* 17.02.2021: Initial Draft

 ## Status

@@ -18,8 +18,8 @@ When a chain upgrade introduces state-breaking changes inside modules, the curre

 This procedure is cumbersome for multiple reasons:

- The procedure takes time. It can take hours to run the `export` command, plus some additional hours to run `InitChain` on the fresh chain using the migrated JSON.
- The exported JSON file can be heavy (~100MB-1GB), making it difficult to view, edit and transfer, which in turn introduces additional work to solve these problems (such as [streaming genesis](https://github.com/cosmos/cosmos-sdk/issues/6936)).
+* The procedure takes time. It can take hours to run the `export` command, plus some additional hours to run `InitChain` on the fresh chain using the migrated JSON.
+* The exported JSON file can be heavy (~100MB-1GB), making it difficult to view, edit and transfer, which in turn introduces additional work to solve these problems (such as [streaming genesis](https://github.com/cosmos/cosmos-sdk/issues/6936)).

 ## Decision

@@ -81,7 +81,7 @@ Each module's migration functions are specific to the module's store evolutions,

 We introduce a new prefix store in `x/upgrade`'s store. This store will track each module's current version, it can be modelized as a `map[string]uint64` of module name to module ConsensusVersion, and will be used when running the migrations (see next section for details). The key prefix used is `0x1`, and the key/value format is:

-```
+```text
 0x2 | {bytes(module_name)} => BigEndian(module_consensus_version)
 ```

@@ -116,10 +116,10 @@ A gRPC query endpoint to query the `VersionMap` stored in `x/upgrade`'s state wi

 Once all the migration handlers are registered inside the configurator (which happens at startup), running migrations can happen by calling the `RunMigrations` method on `module.Manager`. This function will loop through all modules, and for each module:

- Get the old ConsensusVersion of the module from its `VersionMap` argument (let's call it `M`).
- Fetch the new ConsensusVersion of the module from the `ConsensusVersion()` method on `AppModule` (call it `N`).
- If `N>M`, run all registered migrations for the module sequentially `M -> M+1 -> M+2...` until `N`.
-    - There is a special case where there is no ConsensusVersion for the module, as this means that the module has been newly added during the upgrade. In this case, no migration function is run, and the module's current ConsensusVersion is saved to `x/upgrade`'s store.
+* Get the old ConsensusVersion of the module from its `VersionMap` argument (let's call it `M`).
+* Fetch the new ConsensusVersion of the module from the `ConsensusVersion()` method on `AppModule` (call it `N`).
+* If `N>M`, run all registered migrations for the module sequentially `M -> M+1 -> M+2...` until `N`.
+    * There is a special case where there is no ConsensusVersion for the module, as this means that the module has been newly added during the upgrade. In this case, no migration function is run, and the module's current ConsensusVersion is saved to `x/upgrade`'s store.

 If a required migration is missing (e.g. if it has not been registered in the `Configurator`), then the `RunMigrations` function will error.

@@ -133,8 +133,8 @@ app.UpgradeKeeper.SetUpgradeHandler("my-plan", func(ctx sdk.Context, plan upgrad

 Assuming a chain upgrades at block `n`, the procedure should run as follows:

- the old binary will halt in `BeginBlock` when starting block `N`. In its store, the ConsensusVersions of the old binary's modules are stored.
- the new binary will start at block `N`. The UpgradeHandler is set in the new binary, so will run at `BeginBlock` of the new binary. Inside `x/upgrade`'s `ApplyUpgrade`, the `VersionMap` will be retrieved from the (old binary's) store, and passed into the `RunMigrations` functon, migrating all module stores in-place before the modules' own `BeginBlock`s.
+* the old binary will halt in `BeginBlock` when starting block `N`. In its store, the ConsensusVersions of the old binary's modules are stored.
+* the new binary will start at block `N`. The UpgradeHandler is set in the new binary, so will run at `BeginBlock` of the new binary. Inside `x/upgrade`'s `ApplyUpgrade`, the `VersionMap` will be retrieved from the (old binary's) store, and passed into the `RunMigrations` functon, migrating all module stores in-place before the modules' own `BeginBlock`s.

 ## Consequences

@@ -146,22 +146,22 @@ While modules MUST register their migration functions when bumping ConsensusVers

 ### Positive

- Perform chain upgrades without manipulating JSON files.
- While no benchmark has been made yet, it is probable that in-place store migrations will take less time than JSON migrations. The main reason supporting this claim is that both the `simd export` command on the old binary and the `InitChain` function on the new binary will be skipped.
+* Perform chain upgrades without manipulating JSON files.
+* While no benchmark has been made yet, it is probable that in-place store migrations will take less time than JSON migrations. The main reason supporting this claim is that both the `simd export` command on the old binary and the `InitChain` function on the new binary will be skipped.

 ### Negative

- Module developers MUST correctly track consensus-breaking changes in their modules. If a consensus-breaking change is introduced in a module without its corresponding `ConsensusVersion()` bump, then the `RunMigrations` function won't detect the migration, and the chain upgrade might be unsuccessful. Documentation should clearly reflect this.
+* Module developers MUST correctly track consensus-breaking changes in their modules. If a consensus-breaking change is introduced in a module without its corresponding `ConsensusVersion()` bump, then the `RunMigrations` function won't detect the migration, and the chain upgrade might be unsuccessful. Documentation should clearly reflect this.

 ### Neutral

- The Cosmos SDK will continue to support JSON migrations via the existing `simd export` and `simd migrate` commands.
- The current ADR does not allow creating, renaming or deleting stores, only modifying existing store keys and values. The Cosmos SDK already has the `StoreLoader` for those operations.
+* The Cosmos SDK will continue to support JSON migrations via the existing `simd export` and `simd migrate` commands.
+* The current ADR does not allow creating, renaming or deleting stores, only modifying existing store keys and values. The Cosmos SDK already has the `StoreLoader` for those operations.

 ## Further Discussions

 ## References

- Initial discussion: https://github.com/cosmos/cosmos-sdk/discussions/8429
- Implementation of `ConsensusVersion` and `RunMigrations`: https://github.com/cosmos/cosmos-sdk/pull/8485
- Issue discussing `x/upgrade` design: https://github.com/cosmos/cosmos-sdk/issues/8514
+* Initial discussion: <https://github.com/cosmos/cosmos-sdk/discussions/8429>
+* Implementation of `ConsensusVersion` and `RunMigrations`: <https://github.com/cosmos/cosmos-sdk/pull/8485>
+* Issue discussing `x/upgrade` design: <https://github.com/cosmos/cosmos-sdk/issues/8514>
@@ -2,7 +2,7 @@

 ## Changelog

- 2020/04/09: Initial Draft
+* 2020/04/09: Initial Draft

 ## Status

@@ -16,15 +16,15 @@ This ADR defines the `x/group` module which allows the creation and management o

 The legacy amino multi-signature mechanism of the Cosmos SDK has certain limitations:

- Key rotation is not possible, although this can be solved with [account rekeying](adr-034-account-rekeying.md).
- Thresholds can't be changed.
- UX is cumbersome for non-technical users ([#5661](https://github.com/cosmos/cosmos-sdk/issues/5661)).
- It requires `legacy_amino` sign mode ([#8141](https://github.com/cosmos/cosmos-sdk/issues/8141)).
+* Key rotation is not possible, although this can be solved with [account rekeying](adr-034-account-rekeying.md).
+* Thresholds can't be changed.
+* UX is cumbersome for non-technical users ([#5661](https://github.com/cosmos/cosmos-sdk/issues/5661)).
+* It requires `legacy_amino` sign mode ([#8141](https://github.com/cosmos/cosmos-sdk/issues/8141)).

 While the group module is not meant to be a total replacement for the current multi-signature accounts, it provides a solution to the limitations described above, with a more flexible key management system where keys can be added, updated or removed, as well as configurable thresholds.
 It's meant to be used with other access control modules such as [`x/feegrant`](./adr-029-fee-grant-module.md) ans [`x/authz`](adr-030-authz-module.md) to simplify key management for individuals and organizations.

-The proof of concept of the group module can be found in https://github.com/regen-network/regen-ledger/tree/master/proto/regen/group/v1alpha1 and https://github.com/regen-network/regen-ledger/tree/master/x/group.
+The proof of concept of the group module can be found in <https://github.com/regen-network/regen-ledger/tree/master/proto/regen/group/v1alpha1> and <https://github.com/regen-network/regen-ledger/tree/master/x/group>.

 ## Decision

@@ -187,9 +187,9 @@ passes as well as any metadata associated with the proposal. These `sdk.Msg`s ge

 Internally, a proposal also tracks:

- its current `Status`: submitted, closed or aborted
- its `Result`: unfinalized, accepted or rejected
- its `VoteState` in the form of a `Tally`, which is calculated on new votes and when executing the proposal.
+* its current `Status`: submitted, closed or aborted
+* its `Result`: unfinalized, accepted or rejected
+* its `VoteState` in the form of a `Tally`, which is calculated on new votes and when executing the proposal.

 ```proto
 // Tally represents the sum of weighted votes.
@@ -254,26 +254,26 @@ Inter-module communication introduced by [ADR-033](adr-033-protobuf-inter-module

 ### Positive

- Improved UX for multi-signature accounts allowing key rotation and custom decision policies.
+* Improved UX for multi-signature accounts allowing key rotation and custom decision policies.

 ### Negative

 ### Neutral

- It uses ADR 033 so it will need to be implemented within the Cosmos SDK, but this doesn't imply necessarily any large refactoring of existing Cosmos SDK modules.
- The current implementation of the group module uses the ORM package.
+* It uses ADR 033 so it will need to be implemented within the Cosmos SDK, but this doesn't imply necessarily any large refactoring of existing Cosmos SDK modules.
+* The current implementation of the group module uses the ORM package.

 ## Further Discussions

- Convergence of `/group` and `x/gov` as both support proposals and voting: https://github.com/cosmos/cosmos-sdk/discussions/9066
- `x/group` possible future improvements:
-    - Execute proposals on submission (https://github.com/regen-network/regen-ledger/issues/288)
-    - Withdraw a proposal (https://github.com/regen-network/cosmos-modules/issues/41)
-    - Make `Tally` more flexible and support non-binary choices
+* Convergence of `/group` and `x/gov` as both support proposals and voting: <https://github.com/cosmos/cosmos-sdk/discussions/9066>
+* `x/group` possible future improvements:
+    * Execute proposals on submission (<https://github.com/regen-network/regen-ledger/issues/288>)
+    * Withdraw a proposal (<https://github.com/regen-network/cosmos-modules/issues/41>)
+    * Make `Tally` more flexible and support non-binary choices

 ## References

- Initial specification:
-    - https://gist.github.com/aaronc/b60628017352df5983791cad30babe56#group-module
-    - [#5236](https://github.com/cosmos/cosmos-sdk/pull/5236)
- Proposal to add `x/group` into the Cosmos SDK: [#7633](https://github.com/cosmos/cosmos-sdk/issues/7633)
+* Initial specification:
+    * <https://gist.github.com/aaronc/b60628017352df5983791cad30babe56#group-module>
+    * [#5236](https://github.com/cosmos/cosmos-sdk/pull/5236)
+* Proposal to add `x/group` into the Cosmos SDK: [#7633](https://github.com/cosmos/cosmos-sdk/issues/7633)
@@ -2,8 +2,8 @@

 ## Changelog

- 2021-05-01: Initial Draft
- 2021-07-02: Review updates
+* 2021-05-01: Initial Draft
+* 2021-07-02: Review updates

 ## Status

@@ -13,22 +13,22 @@ PROPOSED

 This ADR defines the `x/nft` module which is a generic implementation of NFTs, roughly "compatible" with ERC721. **Applications using the `x/nft` module must implement the following functions**:

- `MsgNewClass` - Receive the user's request to create a class, and call the `NewClass` of the `x/nft` module.
- `MsgUpdateClass` - Receive the user's request to update a class, and call the `UpdateClass` of the `x/nft` module.
- `MsgMintNFT` - Receive the user's request to mint a nft, and call the `MintNFT` of the `x/nft` module.
- `BurnNFT` - Receive the user's request to burn a nft, and call the `BurnNFT` of the `x/nft` module.
- `UpdateNFT` - Receive the user's request to update a nft, and call the `UpdateNFT` of the `x/nft` module.
+* `MsgNewClass` - Receive the user's request to create a class, and call the `NewClass` of the `x/nft` module.
+* `MsgUpdateClass` - Receive the user's request to update a class, and call the `UpdateClass` of the `x/nft` module.
+* `MsgMintNFT` - Receive the user's request to mint a nft, and call the `MintNFT` of the `x/nft` module.
+* `BurnNFT` - Receive the user's request to burn a nft, and call the `BurnNFT` of the `x/nft` module.
+* `UpdateNFT` - Receive the user's request to update a nft, and call the `UpdateNFT` of the `x/nft` module.

 ## Context

-NFTs are more than just crypto art, which is very helpful for accruing value to the Cosmos ecosystem. As a result, Cosmos Hub should implement NFT functions and enable a unified mechanism for storing and sending the ownership representative of NFTs as discussed in https://github.com/cosmos/cosmos-sdk/discussions/9065.
+NFTs are more than just crypto art, which is very helpful for accruing value to the Cosmos ecosystem. As a result, Cosmos Hub should implement NFT functions and enable a unified mechanism for storing and sending the ownership representative of NFTs as discussed in <https://github.com/cosmos/cosmos-sdk/discussions/9065>.

 As discussed in [#9065](https://github.com/cosmos/cosmos-sdk/discussions/9065), several potential solutions can be considered:

- irismod/nft and modules/incubator/nft
- CW721
- DID NFTs
- interNFT
+* irismod/nft and modules/incubator/nft
+* CW721
+* DID NFTs
+* interNFT

 Since functions/use cases of NFTs are tightly connected with their logic, it is almost impossible to support all the NFTs' use cases in one Cosmos SDK module by defining and implementing different transaction types.

@@ -41,10 +41,10 @@ The current design is based on the work done by [IRISnet team](https://github.co

 We create a `x/nft` module, which contains the following functionality:

- Store NFTs and track their ownership.
- Expose `Keeper` interface for composing modules to transfer, mint and burn NFTs.
- Expose external `Message` interface for users to transfer ownership of their NFTs.
- Query NFTs and their supply information.
+* Store NFTs and track their ownership.
+* Expose `Keeper` interface for composing modules to transfer, mint and burn NFTs.
+* Expose external `Message` interface for users to transfer ownership of their NFTs.
+* Query NFTs and their supply information.

 The proposed module is a base module for NFT app logic. It's goal it to provide a common layer for storage, basic transfer functionality and IBC. The module should not be used as a standalone.
 Instead an app should create a specialized module to handle app specific logic (eg: NFT ID construction, royalty), user level minting and burning. Moreover an app specialized module should handle auxiliary data to support the app logic (eg indexes, ORM, business data).
@@ -54,8 +54,9 @@ All data carried over IBC must be part of the `NFT` or `Class` type described be
 ### Types

 We propose two main types:
-+ `Class` -- describes NFT class. We can think about it as a smart contract address.
-+ `NFT` -- object representing unique, non fungible asset. Each NFT is associated with a Class.
+
+* `Class` -- describes NFT class. We can think about it as a smart contract address.
+* `NFT` -- object representing unique, non fungible asset. Each NFT is associated with a Class.

 #### Class

@@ -73,13 +74,13 @@ message Class {
 }
 ```

- `id` is an alphanumeric identifier of the NFT class; it is used as the primary index for storing the class; _required_
- `name` is a descriptive name of the NFT class; _optional_
- `symbol` is the symbol usually shown on exchanges for the NFT class; _optional_
- `description` is a detailed description of the NFT class; _optional_
- `uri` is a URI for the class metadata stored off chain. It should be a JSON file that contains metadata about the NFT class and NFT data schema ([OpenSea example](https://docs.opensea.io/docs/contract-level-metadata)); _optional_
- `uri_hash` is a hash of the document pointed by uri; _optional_
- `data` is app specific metadata of the class; _optional_
+* `id` is an alphanumeric identifier of the NFT class; it is used as the primary index for storing the class; _required_
+* `name` is a descriptive name of the NFT class; _optional_
+* `symbol` is the symbol usually shown on exchanges for the NFT class; _optional_
+* `description` is a detailed description of the NFT class; _optional_
+* `uri` is a URI for the class metadata stored off chain. It should be a JSON file that contains metadata about the NFT class and NFT data schema ([OpenSea example](https://docs.opensea.io/docs/contract-level-metadata)); _optional_
+* `uri_hash` is a hash of the document pointed by uri; _optional_
+* `data` is app specific metadata of the class; _optional_

 #### NFT

@@ -95,16 +96,16 @@ message NFT {
 }
 ```

- `class_id` is the identifier of the NFT class where the NFT belongs; _required_,`[a-zA-Z][a-zA-Z0-9/:-]{2,100}`
- `id` is an alphanumeric identifier of the NFT, unique within the scope of its class. It is specified by the creator of the NFT and may be expanded to use DID in the future. `class_id` combined with `id` uniquely identifies an NFT and is used as the primary index for storing the NFT; _required_,`[a-zA-Z][a-zA-Z0-9/:-]{2,100}`
+* `class_id` is the identifier of the NFT class where the NFT belongs; _required_,`[a-zA-Z][a-zA-Z0-9/:-]{2,100}`
+* `id` is an alphanumeric identifier of the NFT, unique within the scope of its class. It is specified by the creator of the NFT and may be expanded to use DID in the future. `class_id` combined with `id` uniquely identifies an NFT and is used as the primary index for storing the NFT; _required_,`[a-zA-Z][a-zA-Z0-9/:-]{2,100}`

-  ```
+  ```text
  {class_id}/{id} --> NFT (bytes)
  ```

- `uri` is a URI for the NFT metadata stored off chain. Should point to a JSON file that contains metadata about this NFT (Ref: [ERC721 standard and OpenSea extension](https://docs.opensea.io/docs/metadata-standards)); _required_
- `uri_hash` is a hash of the document pointed by uri; _optional_
- `data` is an app specific data of the NFT. CAN be used by composing modules to specify additional properties of the NFT; _optional_
+* `uri` is a URI for the NFT metadata stored off chain. Should point to a JSON file that contains metadata about this NFT (Ref: [ERC721 standard and OpenSea extension](https://docs.opensea.io/docs/metadata-standards)); _required_
+* `uri_hash` is a hash of the document pointed by uri; _optional_
+* `data` is an app specific data of the NFT. CAN be used by composing modules to specify additional properties of the NFT; _optional_

 This ADR doesn't specify values that `data` can take; however, best practices recommend upper-level NFT modules clearly specify their contents.  Although the value of this field doesn't provide the additional context required to manage NFT records, which means that the field can technically be removed from the specification, the field's existence allows basic informational/UI functionality.

@@ -309,31 +310,31 @@ This specification conforms to the ERC-721 smart contract specification for NFT

 ### Positive

- NFT identifiers available on Cosmos Hub.
- Ability to build different NFT modules for the Cosmos Hub, e.g., ERC-721.
- NFT module which supports interoperability with IBC and other cross-chain infrastructures like Gravity Bridge
+* NFT identifiers available on Cosmos Hub.
+* Ability to build different NFT modules for the Cosmos Hub, e.g., ERC-721.
+* NFT module which supports interoperability with IBC and other cross-chain infrastructures like Gravity Bridge

 ### Negative

-+ New IBC app is required for x/nft
-+ CW721 adapter is required
+* New IBC app is required for x/nft
+* CW721 adapter is required

 ### Neutral

- Other functions need more modules. For example, a custody module is needed for NFT trading function, a collectible module is needed for defining NFT properties.
+* Other functions need more modules. For example, a custody module is needed for NFT trading function, a collectible module is needed for defining NFT properties.

 ## Further Discussions

 For other kinds of applications on the Hub, more app-specific modules can be developed in the future:

- `x/nft/custody`: custody of NFTs to support trading functionality.
- `x/nft/marketplace`: selling and buying NFTs using sdk.Coins.
- `x/fractional`: a module to split an ownership of an asset (NFT or other assets) for multiple stakeholder. `x/group`  should work for most of the cases.
+* `x/nft/custody`: custody of NFTs to support trading functionality.
+* `x/nft/marketplace`: selling and buying NFTs using sdk.Coins.
+* `x/fractional`: a module to split an ownership of an asset (NFT or other assets) for multiple stakeholder. `x/group`  should work for most of the cases.

 Other networks in the Cosmos ecosystem could design and implement their own NFT modules for specific NFT applications and use cases.

 ## References

- Initial discussion: https://github.com/cosmos/cosmos-sdk/discussions/9065
- x/nft: initialize module: https://github.com/cosmos/cosmos-sdk/pull/9174
- [ADR 033](https://github.com/cosmos/cosmos-sdk/blob/master/docs/architecture/adr-033-protobuf-inter-module-comm.md)
+* Initial discussion: <https://github.com/cosmos/cosmos-sdk/discussions/9065>
+* x/nft: initialize module: <https://github.com/cosmos/cosmos-sdk/pull/9174>
+* [ADR 033](https://github.com/cosmos/cosmos-sdk/blob/master/docs/architecture/adr-033-protobuf-inter-module-comm.md)
@@ -2,8 +2,8 @@

 ## Changelog

- 28.06.2021: Initial Draft
- 02.12.2021: Add `Since:` comment for new fields
+* 28.06.2021: Initial Draft
+* 02.12.2021: Add `Since:` comment for new fields

 ## Status

@@ -19,8 +19,8 @@ The Cosmos SDK maintains a set of [Protobuf definitions](https://github.com/cosm

 When making changes to these Protobuf definitions, the Cosmos SDK currently only follows [Buf's](https://docs.buf.build/) recommendations. We noticed however that Buf's recommendations might still result in breaking changes in the SDK in some cases. For example:

- Adding fields to `Msg`s. Adding fields is a not a Protobuf spec-breaking operation. However, when adding new fields to `Msg`s, the unknown field rejection will throw an error when sending the new `Msg` to an older node.
- Marking fields as `reserved`. Protobuf proposes the `reserved` keyword for removing fields without the need to bump the package version. However, by doing so, client backwards compatibility is broken as Protobuf doesn't generate anything for `reserved` fields. See [#9446](https://github.com/cosmos/cosmos-sdk/issues/9446) for more details on this issue.
+* Adding fields to `Msg`s. Adding fields is a not a Protobuf spec-breaking operation. However, when adding new fields to `Msg`s, the unknown field rejection will throw an error when sending the new `Msg` to an older node.
+* Marking fields as `reserved`. Protobuf proposes the `reserved` keyword for removing fields without the need to bump the package version. However, by doing so, client backwards compatibility is broken as Protobuf doesn't generate anything for `reserved` fields. See [#9446](https://github.com/cosmos/cosmos-sdk/issues/9446) for more details on this issue.

 Moreover, module developers often face other questions around Protobuf definitions such as "Can I rename a field?" or "Can I deprecate a field?" This ADR aims to answer all these questions by providing clear guidelines about allowed updates for Protobuf definitions.

@@ -28,11 +28,11 @@ Moreover, module developers often face other questions around Protobuf definitio

 We decide to keep [Buf's](https://docs.buf.build/) recommendations with the following exceptions:

- `UNARY_RPC`: the Cosmos SDK currently does not support streaming RPCs.
- `COMMENT_FIELD`: the Cosmos SDK allows fields with no comments.
- `SERVICE_SUFFIX`: we use the `Query` and `Msg` service naming convention, which doesn't use the `-Service` suffix.
- `PACKAGE_VERSION_SUFFIX`: some packages, such as `cosmos.crypto.ed25519`, don't use a version suffix.
- `RPC_REQUEST_STANDARD_NAME`: Requests for the `Msg` service don't have the `-Request` suffix to keep backwards compatibility.
+* `UNARY_RPC`: the Cosmos SDK currently does not support streaming RPCs.
+* `COMMENT_FIELD`: the Cosmos SDK allows fields with no comments.
+* `SERVICE_SUFFIX`: we use the `Query` and `Msg` service naming convention, which doesn't use the `-Service` suffix.
+* `PACKAGE_VERSION_SUFFIX`: some packages, such as `cosmos.crypto.ed25519`, don't use a version suffix.
+* `RPC_REQUEST_STANDARD_NAME`: Requests for the `Msg` service don't have the `-Request` suffix to keep backwards compatibility.

 On top of Buf's recommendations we add the following guidelines that are specific to the Cosmos SDK.

@@ -86,8 +86,8 @@ Protobuf supports the [`deprecated` field option](https://developers.google.com/

 As an example, the Cosmos SDK v0.42 to v0.43 update contained two Protobuf-breaking changes, listed below. Instead of bumping the package versions from `v1beta1` to `v1`, the SDK team decided to follow this guideline, by reverting the breaking changes, marking those changes as deprecated, and modifying the node implementation when processing messages with deprecated fields. More specifically:

- The Cosmos SDK recently removed support for [time-based software upgrades](https://github.com/cosmos/cosmos-sdk/pull/8849). As such, the `time` field has been marked as deprecated in `cosmos.upgrade.v1beta1.Plan`. Moreover, the node will reject any proposal containing an upgrade Plan whose `time` field is non-empty.
- The Cosmos SDK now supports [governance split votes](./adr-037-gov-split-vote.md). When querying for votes, the returned `cosmos.gov.v1beta1.Vote` message has its `option` field (used for 1 vote option) deprecated in favor of its `options` field (allowing multiple vote options). Whenever possible, the SDK still populates the deprecated `option` field, that is, if and only if the `len(options) == 1` and `options[0].Weight == 1.0`.
+* The Cosmos SDK recently removed support for [time-based software upgrades](https://github.com/cosmos/cosmos-sdk/pull/8849). As such, the `time` field has been marked as deprecated in `cosmos.upgrade.v1beta1.Plan`. Moreover, the node will reject any proposal containing an upgrade Plan whose `time` field is non-empty.
+* The Cosmos SDK now supports [governance split votes](./adr-037-gov-split-vote.md). When querying for votes, the returned `cosmos.gov.v1beta1.Vote` message has its `option` field (used for 1 vote option) deprecated in favor of its `options` field (allowing multiple vote options). Whenever possible, the SDK still populates the deprecated `option` field, that is, if and only if the `len(options) == 1` and `options[0].Weight == 1.0`.

 #### 4. Fields MUST NOT be renamed

@@ -97,10 +97,10 @@ Whereas the official Protobuf recommendations do not prohibit renaming fields, a

 TODO, needs architecture review. Some topics:

- Bumping versions frequency
- When bumping versions, should the Cosmos SDK support both versions?
-  - i.e. v1beta1 -> v1, should we have two folders in the Cosmos SDK, and handlers for both versions?
- mention ADR-023 Protobuf naming
+* Bumping versions frequency
+* When bumping versions, should the Cosmos SDK support both versions?
+    * i.e. v1beta1 -> v1, should we have two folders in the Cosmos SDK, and handlers for both versions?
+* mention ADR-023 Protobuf naming

 ## Consequences

@@ -112,9 +112,9 @@ TODO, needs architecture review. Some topics:

 ### Positive

- less pain to tool developers
- more compatibility in the ecosystem
- ...
+* less pain to tool developers
+* more compatibility in the ecosystem
+* ...

 ### Negative

@@ -122,7 +122,7 @@ TODO, needs architecture review. Some topics:

 ### Neutral

- more rigor in Protobuf review
+* more rigor in Protobuf review

 ## Further Discussions

@@ -134,5 +134,5 @@ Test cases for an implementation are mandatory for ADRs that are affecting conse

 ## References

- [#9445](https://github.com/cosmos/cosmos-sdk/issues/9445) Release proto definitions v1
- [#9446](https://github.com/cosmos/cosmos-sdk/issues/9446) Address v1beta1 proto breaking changes
+* [#9445](https://github.com/cosmos/cosmos-sdk/issues/9445) Release proto definitions v1
+* [#9446](https://github.com/cosmos/cosmos-sdk/issues/9446) Address v1beta1 proto breaking changes
@@ -2,8 +2,8 @@

 ## Changelog

- 20.08.2021: Initial draft.
- 07.12.2021: Update `tx.Handler` interface ([\#10693](https://github.com/cosmos/cosmos-sdk/pull/10693)).
+* 20.08.2021: Initial draft.
+* 07.12.2021: Update `tx.Handler` interface ([\#10693](https://github.com/cosmos/cosmos-sdk/pull/10693)).

 ## Status

@@ -186,7 +186,7 @@ While BaseApp simply holds a reference to a `tx.Handler`, this `tx.Handler` itse

 Then, the app developer can compose multiple middlewares on top on the base `tx.Handler`. Each middleware can run pre-and-post-processing logic around its next middleware, as described in the section above. Conceptually, as an example, given the middlewares `A`, `B`, and `C` and the base `tx.Handler` `H` the stack looks like:

-```
+```text
 A.pre
    B.pre
        C.pre
@@ -232,17 +232,17 @@ The middleware-based design builds upon the existing antehandlers design describ

 #### Similarities with Antehandlers

- Designed as chaining/composing small modular pieces.
- Allow code reuse for `{Check,Deliver}Tx` and for `Simulate`.
- Set up in `app.go`, and easily customizable by app developers.
- Order is important.
+* Designed as chaining/composing small modular pieces.
+* Allow code reuse for `{Check,Deliver}Tx` and for `Simulate`.
+* Set up in `app.go`, and easily customizable by app developers.
+* Order is important.

 #### Differences with Antehandlers

- The Antehandlers are run before `Msg` execution, whereas middlewares can run before and after.
- The middleware approach uses separate methods for `{Check,Deliver,Simulate}Tx`, whereas the antehandlers pass a `simulate bool` flag and uses the `sdkCtx.Is{Check,Recheck}Tx()` flags to determine in which transaction mode we are.
- The middleware design lets each middleware hold a reference to the next middleware, whereas the antehandlers pass a `next` argument in the `AnteHandle` method.
- The middleware design use Go's standard `context.Context`, whereas the antehandlers use `sdk.Context`.
+* The Antehandlers are run before `Msg` execution, whereas middlewares can run before and after.
+* The middleware approach uses separate methods for `{Check,Deliver,Simulate}Tx`, whereas the antehandlers pass a `simulate bool` flag and uses the `sdkCtx.Is{Check,Recheck}Tx()` flags to determine in which transaction mode we are.
+* The middleware design lets each middleware hold a reference to the next middleware, whereas the antehandlers pass a `next` argument in the `AnteHandle` method.
+* The middleware design use Go's standard `context.Context`, whereas the antehandlers use `sdk.Context`.

 ## Consequences

@@ -281,14 +281,14 @@ This ADR does not introduce any state-machine-, client- or CLI-breaking changes.

 ### Positive

- Allow custom logic to be run before an after `Msg` execution. This enables the [tips](https://github.com/cosmos/cosmos-sdk/issues/9406) and [gas refund](https://github.com/cosmos/cosmos-sdk/issues/2150) uses cases, and possibly other ones.
- Make BaseApp more lightweight, and defer complex logic to small modular components.
- Separate paths for `{Check,Deliver,Simulate}Tx` with different returns types. This allows for improved readability (replace `if sdkCtx.IsRecheckTx() && !simulate {...}` with separate methods) and more flexibility (e.g. returning a `priority` in `ResponseCheckTx`).
+* Allow custom logic to be run before an after `Msg` execution. This enables the [tips](https://github.com/cosmos/cosmos-sdk/issues/9406) and [gas refund](https://github.com/cosmos/cosmos-sdk/issues/2150) uses cases, and possibly other ones.
+* Make BaseApp more lightweight, and defer complex logic to small modular components.
+* Separate paths for `{Check,Deliver,Simulate}Tx` with different returns types. This allows for improved readability (replace `if sdkCtx.IsRecheckTx() && !simulate {...}` with separate methods) and more flexibility (e.g. returning a `priority` in `ResponseCheckTx`).

 ### Negative

- It is hard to understand at first glance the state updates that would occur after a middleware runs given the `sdk.Context` and `tx`. A middleware can have an arbitrary number of nested middleware being called within its function body, each possibly doing some pre- and post-processing before calling the next middleware on the chain. Thus to understand what a middleware is doing, one must also understand what every other middleware further along the chain is also doing, and the order of middlewares matters. This can get quite complicated to understand.
- API-breaking changes for app developers.
+* It is hard to understand at first glance the state updates that would occur after a middleware runs given the `sdk.Context` and `tx`. A middleware can have an arbitrary number of nested middleware being called within its function body, each possibly doing some pre- and post-processing before calling the next middleware on the chain. Thus to understand what a middleware is doing, one must also understand what every other middleware further along the chain is also doing, and the order of middlewares matters. This can get quite complicated to understand.
+* API-breaking changes for app developers.

 ### Neutral

@@ -296,8 +296,8 @@ No neutral consequences.

 ## Further Discussions

- [#9934](https://github.com/cosmos/cosmos-sdk/discussions/9934) Decomposing BaseApp's other ABCI methods into middlewares.
- Replace `sdk.Tx` interface with the concrete protobuf Tx type in the `tx.Handler` methods signature.
+* [#9934](https://github.com/cosmos/cosmos-sdk/discussions/9934) Decomposing BaseApp's other ABCI methods into middlewares.
+* Replace `sdk.Tx` interface with the concrete protobuf Tx type in the `tx.Handler` methods signature.

 ## Test Cases

@@ -307,5 +307,5 @@ For new middlewares, we introduce unit tests. Since middlewares are purposefully

 ## References

- Initial discussion: https://github.com/cosmos/cosmos-sdk/issues/9585
- Implementation: [#9920 BaseApp refactor](https://github.com/cosmos/cosmos-sdk/pull/9920) and [#10028 Antehandlers migration](https://github.com/cosmos/cosmos-sdk/pull/10028)
+* Initial discussion: <https://github.com/cosmos/cosmos-sdk/issues/9585>
+* Implementation: [#9920 BaseApp refactor](https://github.com/cosmos/cosmos-sdk/pull/9920) and [#10028 Antehandlers migration](https://github.com/cosmos/cosmos-sdk/pull/10028)
@@ -2,7 +2,7 @@

 ## Changelog

- Sep 22, 2021: Initial Draft
+* Sep 22, 2021: Initial Draft

 ## Status

@@ -156,20 +156,20 @@ module may be removed entirely in a future release.

 ### Positive

- Module parameters are serialized more efficiently
- Modules are able to react on parameters changes and perform additional actions.
- Special events can be emitted, allowing hooks to be triggered.
+* Module parameters are serialized more efficiently
+* Modules are able to react on parameters changes and perform additional actions.
+* Special events can be emitted, allowing hooks to be triggered.

 ### Negative

- Module parameters becomes slightly more burdensome for module developers:
-    - Modules are now responsible for persisting and retrieving parameter state
-    - Modules are now required to have unique message handlers to handle parameter
+* Module parameters becomes slightly more burdensome for module developers:
+    * Modules are now responsible for persisting and retrieving parameter state
+    * Modules are now required to have unique message handlers to handle parameter
      changes per unique parameter data structure.

 ### Neutral

- Requires [#9810](https://github.com/cosmos/cosmos-sdk/pull/9810) to be reviewed
+* Requires [#9810](https://github.com/cosmos/cosmos-sdk/pull/9810) to be reviewed
  and merged.

 <!-- ## Further Discussions
@@ -179,6 +179,6 @@ Later, this section can optionally list ideas or improvements the author or revi

 ## References

- https://github.com/cosmos/cosmos-sdk/pull/9810
- https://github.com/cosmos/cosmos-sdk/issues/9438
- https://github.com/cosmos/cosmos-sdk/discussions/9913
+* <https://github.com/cosmos/cosmos-sdk/pull/9810>
+* <https://github.com/cosmos/cosmos-sdk/issues/9438>
+* <https://github.com/cosmos/cosmos-sdk/discussions/9913>
@@ -2,7 +2,7 @@

 ## Changelog

- {date}: {changelog}
+* {date}: {changelog}

 ## Status

@@ -57,4 +57,4 @@ Test cases for an implementation are mandatory for ADRs that are affecting conse

 ## References

- {reference link}
+* {reference link}