docs: delete old files and resync (#284)

* remove accounts, counter, and validate module docs

* synced

Author: technicallyty

Diff for: docs/build/abci/00-introduction.md

@@ -2,9 +2,9 @@
 
 ## What is ABCI?
 
-ABC, Application Blockchain Interface is the interface between CometBFT and the application, more information about ABCI can be found [here](https://docs.cometbft.com/v0.38/spec/abci/). Within the release of ABCI 2.0 for the 0.38 CometBFT release there were additional methods introduced.
+ABCI, Application Blockchain Interface is the interface between CometBFT and the application. More information about ABCI can be found [here](https://docs.cometbft.com/v0.38/spec/abci/). CometBFT version 0.38 included a new version of ABCI (called ABCI 2.0) which added several new methods.
 
-The 5 methods introduced during ABCI 2.0 are:
+The 5 methods introduced in ABCI 2.0 are:
 
 * `PrepareProposal`
 * `ProcessProposal`
@@ -17,11 +17,11 @@ The 5 methods introduced during ABCI 2.0 are:
 
 ## PrepareProposal
 
-Based on their voting power, CometBFT chooses a block proposer and calls `PrepareProposal` on the block proposer's application (Cosmos SDK). The selected block proposer is responsible for collecting outstanding transactions from the mempool, adhering to the application's specifications. The application can enforce custom transaction ordering and incorporate additional transactions, potentially generated from vote extensions in the previous block.
+Based on validator voting power, CometBFT chooses a block proposer and calls `PrepareProposal` on the block proposer's application (Cosmos SDK). The selected block proposer is responsible for collecting outstanding transactions from the mempool, adhering to the application's specifications. The application can enforce custom transaction ordering and incorporate additional transactions, potentially generated from vote extensions in the previous block.
 
-To perform this manipulation on the application side, a custom handler must be implemented. By default, the Cosmos SDK provides `PrepareProposalHandler`, used in conjunction with an application specific mempool. A custom handler can be written by application developer, if a noop handler provided, all transactions are considered valid. Please see [this](https://github.com/fatal-fruit/abci-workshop) tutorial for more information on custom handlers.
+To perform this manipulation on the application side, a custom handler must be implemented. By default, the Cosmos SDK provides `PrepareProposalHandler`, used in conjunction with an application specific mempool. A custom handler can be written by application developer, if a noop handler provided, all transactions are considered valid.
 
-Please note that vote extensions will only be available on the following height in which vote extensions are enabled. More information about vote extensions can be found [here](https://docs.cosmos.network/main/build/abci/03-vote-extensions.md).
+Please note that vote extensions will only be available on the following height in which vote extensions are enabled. More information about vote extensions can be found [here](https://docs.cosmos.network/main/build/abci/vote-extensions).
 
 After creating the proposal, the proposer returns it to CometBFT.
 
@@ -48,4 +48,4 @@ Additionally, applications must keep the vote extension data concise as it can d
 
 ## FinalizeBlock
 
-`FinalizeBlock` is then called and is responsible for updating the state of the blockchain and making the block available to users
+`FinalizeBlock` is then called and is responsible for updating the state of the blockchain and making the block available to users.

Diff for: docs/build/abci/01-prepare-proposal.md

@@ -24,21 +24,21 @@ it would like the block constructed.
 
 The Cosmos SDK defines the `DefaultProposalHandler` type, which provides applications with
 `PrepareProposal` and `ProcessProposal` handlers. If you decide to implement your
-own `PrepareProposal` handler, you must be sure to ensure that the transactions
+own `PrepareProposal` handler, you must ensure that the transactions
 selected DO NOT exceed the maximum block gas (if set) and the maximum bytes provided
 by `req.MaxBytes`.
 
 ```go reference
-https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/baseapp/abci_utils.go
+https://github.com/cosmos/cosmos-sdk/blob/v0.53.0-rc.2/baseapp/abci_utils.go
 ```
 
 This default implementation can be overridden by the application developer in
-favor of a custom implementation in [`app.go`](../building-apps/01-app-go-v2.md):
+favor of a custom implementation in [`app_di.go`](../building-apps/01-app-go-v2.md):
 
 ```go
 prepareOpt := func(app *baseapp.BaseApp) {
-abciPropHandler := baseapp.NewDefaultProposalHandler(mempool, app)
-app.SetPrepareProposal(abciPropHandler.PrepareProposalHandler())
+    abciPropHandler := baseapp.NewDefaultProposalHandler(mempool, app)
+    app.SetPrepareProposal(abciPropHandler.PrepareProposalHandler())
 }
 
 baseAppOptions = append(baseAppOptions, prepareOpt)

Diff for: docs/build/abci/02-process-proposal.md

@@ -1,31 +1,31 @@
 # Process Proposal
 
 `ProcessProposal` handles the validation of a proposal from `PrepareProposal`,
-which also includes a block header. Meaning, that after a block has been proposed
-the other validators have the right to vote on a block. The validator in the
+which also includes a block header. After a block has been proposed,
+the other validators have the right to accept or reject that block. The validator in the
 default implementation of `PrepareProposal` runs basic validity checks on each
 transaction.
 
-Note, `ProcessProposal` MAY NOT be non-deterministic, i.e. it must be deterministic.
+Note, `ProcessProposal` MUST be deterministic. Non-deterministic behaviors will cause apphash mismatches.
 This means if `ProcessProposal` panics or fails and we reject, all honest validator
-processes will prevote nil and the CometBFT round will proceed again until a valid
-proposal is proposed.
+processes should reject (i.e., prevote nil). If so, CometBFT will start a new round with a new block proposal and the same cycle will happen with `PrepareProposal`
+and `ProcessProposal` for the new proposal.
 
 Here is the implementation of the default implementation:
 
 ```go reference
-https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/baseapp/abci_utils.go#L153-L159
+https://github.com/cosmos/cosmos-sdk/blob/v0.53.0-rc.2/baseapp/abci_utils.go#L219-L226
 ```
 
-Like `PrepareProposal` this implementation is the default and can be modified by
-the application developer in [`app.go`](../building-apps/01-app-go-v2.md). If you decide to implement
-your own `ProcessProposal` handler, you must be sure to ensure that the transactions
+Like `PrepareProposal`, this implementation is the default and can be modified by
+the application developer in [`app_di.go`](../building-apps/01-app-go-v2.md). If you decide to implement
+your own `ProcessProposal` handler, you must ensure that the transactions
 provided in the proposal DO NOT exceed the maximum block gas and `maxtxbytes` (if set).
 
 ```go
 processOpt := func(app *baseapp.BaseApp) {
-abciPropHandler := baseapp.NewDefaultProposalHandler(mempool, app)
-app.SetProcessProposal(abciPropHandler.ProcessProposalHandler())
+    abciPropHandler := baseapp.NewDefaultProposalHandler(mempool, app)
+    app.SetProcessProposal(abciPropHandler.ProcessProposalHandler())
 }
 
 baseAppOptions = append(baseAppOptions, processOpt)

Diff for: docs/build/abci/03-vote-extensions.md

@@ -7,9 +7,8 @@ defined in ABCI++.
 
 ## Extend Vote
 
-ABCI++ allows an application to extend a pre-commit vote with arbitrary data. This
-process does NOT have to be deterministic, and the data returned can be unique to the
-validator process. The Cosmos SDK defines [`baseapp.ExtendVoteHandler`](https://github.com/cosmos/cosmos-sdk/blob/v0.50.1/types/abci.go#L26-L27):
+ABCI 2.0 (colloquially called ABCI++) allows an application to extend a pre-commit vote with arbitrary data. This process does NOT have to be deterministic, and the data returned can be unique to the
+validator process. The Cosmos SDK defines [`baseapp.ExtendVoteHandler`](https://github.com/cosmos/cosmos-sdk/blob/v0.53.0-rc.2/types/abci.go#L32):
 
 ```go
 type ExtendVoteHandler func(Context, *abci.RequestExtendVote) (*abci.ResponseExtendVote, error)
@@ -29,7 +28,7 @@ to consider the size of the vote extensions as they could increase latency in bl
 production. See [here](https://github.com/cometbft/cometbft/blob/v0.38.0-rc1/docs/qa/CometBFT-QA-38.md#vote-extensions-testbed)
 for more details.
 
-Click [here](https://docs.cosmos.network/main/user/tutorials/vote-extensions) if you would like a walkthrough of how to implement vote extensions.
+Click [here](https://docs.cosmos.network/main/build/abci/vote-extensions) if you would like a walkthrough of how to implement vote extensions.
 
 
 ## Verify Vote Extension

Diff for: docs/build/architecture/PROCESS.md

@@ -1,20 +1,20 @@
 # ADR Creation Process
 
 1. Copy the `adr-template.md` file. Use the following filename pattern: `adr-next_number-title.md`
-2. Create a draft Pull Request if you want to get an early feedback.
-3. Make sure the context and a solution is clear and well documented.
-4. Add an entry to a list in the [README](./README.md) file.
+2. Create a draft Pull Request if you want to get early feedback.
+3. Make sure the context and solution are clear and well documented.
+4. Add an entry to the list in the [README](./README.md) file.
 5. Create a Pull Request to propose a new ADR.
 
 ## What is an ADR? 
 
-An ADR is a document to document an implementation and design that may or may not have been discussed in an RFC. While an RFC is meant to replace synchoronus communication in a distributed environment, an ADR is meant to document an already made decision. An ADR wont come with much of a communication overhead because the discussion was recorded in an RFC or a synchronous discussion. If the consensus came from a synchoronus discussion then a short excerpt should be added to the ADR to explain the goals. 
+An ADR is a document to document an implementation and design that may or may not have been discussed in an RFC. While an RFC is meant to replace synchronous communication in a distributed environment, an ADR is meant to document an already made decision. An ADR won't come with much of a communication overhead because the discussion was recorded in an RFC or a synchronous discussion. If the consensus came from a synchronous discussion, then a short excerpt should be added to the ADR to explain the goals. 
 
 ## ADR life cycle
 
 ADR creation is an **iterative** process. Instead of having a high amount of communication overhead, an ADR is used when there is already a decision made and implementation details need to be added. The ADR should document what the collective consensus for the specific issue is and how to solve it. 
 
-1. Every ADR should start with either an RFC or discussion where consensus has been met. 
+1. Every ADR should start with either an RFC or a discussion where consensus has been met. 
 
 2. Once consensus is met, a GitHub Pull Request (PR) is created with a new document based on the `adr-template.md`.
 
@@ -44,12 +44,12 @@ 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.
+* `DRAFT`: [optional] an ADR which is a work in progress, not being ready for a general review. This is to present an early work and get 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 agreement yet.
+* `LAST CALL <date for the last call>`: [optional] Notify that we are close to accepting 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.
+* `SUPERSEDED 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

Diff for: docs/build/architecture/README.md

@@ -36,7 +36,7 @@ Read about the [PROCESS](./PROCESS.md).
 
 ### 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).
+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).
 
 ## ADR Table of Contents
 

Diff for: docs/build/architecture/adr-039-epoched-staking.md

@@ -39,14 +39,14 @@ Furthermore, it has become clearer over time that immediate execution of staking
 
 ### Slashing
 
-There is a design consideration for whether to apply a slash immediately or at the end of an epoch. A slash event should apply to only members who are actually staked during the time of the infraction, namely during the epoch the slash event occured.
+There is a design consideration for whether to apply a slash immediately or at the end of an epoch. A slash event should apply to only members who are actually staked during the time of the infraction, namely during the epoch the slash event occurred.
 
 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 staking derivative design, there is no issue introduced. This does not increase the state size of staking records, since whether a slash has occurred is fully queryable given the validator address.
 
 ### Token lockup
 

Diff for: docs/build/build.md

@@ -5,7 +5,7 @@ sidebar_position: 0
 # Build
 
 * [Building Apps](./building-apps/00-app-go.md) - The documentation in this section will guide you through the process of developing your dApp using the Cosmos SDK framework.
-* [Modules](./modules/README.md) - Information about the various modules available in the Cosmos SDK: Auth, Authz, Bank, Crisis, Distribution, Evidence, Feegrant, Governance, Mint, Params, Slashing, Staking, Upgrade, NFT, Consensus, Circuit, Genutil.
+* [Modules](./modules/README.md) - Information about the various modules available in the Cosmos SDK: Auth, Authz, Bank, Circuit, Consensus, Distribution, Epochs, Evidence, Feegrant, Governance, Group, Mint, NFT, Protocolpool, Slashing, Staking, Upgrade, Genutil.
 * [Migrations](./migrations/01-intro.md) - See what has been updated in each release the process of the transition between versions.
 * [Packages](./packages/README.md) - Explore a curated collection of pre-built modules and functionalities, streamlining the development process.
 * [Tooling](./tooling/README.md) - A suite of utilities designed to enhance the development workflow, optimizing the efficiency of Cosmos SDK-based projects.