9f543b1c3b
## Description
This small PR is trying to clarify the documentation that I found ambiguous when reading it.
Furthermore, it makes one error message more precise ("non-negative" --> "positive").
In particular:
- I clarified that the field `AcceptResponse.Accept` will be set to `true` when an authorization is accepted, but **will not** be set to `false` otherwise (instead, the function `Accept` will return an error).
- I clarified that the field `AcceptResponse.Updated` will not always be populated: it will be `nil` unless there are real changes to the authorization
- I changed the error message in the `send_authorization.go` function, when `IsAllPositive()` returns `false` from _spend limit cannot be negitive_ to _spend limit must be positive_. I emphasized the fact that spend limit must be positive in the documentation.
This is my first contribution to the Cosmos-SDK codebase so if I made some mistake the process (wrt the checklist), guide me patiently, pls.
---
### 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
- [x] 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))
- [ ] provided a link to the relevant issue or specification: NOTE: does not apply, these are clarification changes
- [ ] followed the guidelines for [building modules](https://github.com/cosmos/cosmos-sdk/blob/master/docs/building-modules): NOTE: does not apply, these are clarification changes
- [ ] included the necessary unit and integration [tests](https://github.com/cosmos/cosmos-sdk/blob/master/CONTRIBUTING.md#testing): NOTE: does not apply, these are clarification changes
- [ ] added a changelog entry to `CHANGELOG.md`: NOTE: does not apply, these are clarification changes
- [ ] included comments for [documenting Go code](https://blog.golang.org/godoc) NOTE: does not apply, these are clarification changes
- [x] updated the relevant documentation or specification
- [x] reviewed "Files changed" and left comments if necessary
- [ ] 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)
|
||
|---|---|---|
| .. | ||
| auth | ||
| authz | ||
| bank | ||
| capability | ||
| crisis | ||
| distribution | ||
| epoching | ||
| evidence | ||
| feegrant | ||
| genutil | ||
| gov | ||
| group | ||
| mint | ||
| nft | ||
| params | ||
| simulation | ||
| slashing | ||
| staking | ||
| upgrade | ||
| README.md | ||
README.md
List of Modules
Here are some production-grade modules that can be used in Cosmos SDK applications, along with their respective documentation:
- Auth - Authentication of accounts and transactions for Cosmos SDK applications.
- Authz - Authorization for accounts to perform actions on behalf of other accounts.
- Bank - Token transfer functionalities.
- Capability - Object capability implementation.
- Crisis - Halting the blockchain under certain circumstances (e.g. if an invariant is broken).
- Distribution - Fee distribution, and staking token provision distribution.
- Epoching - Allows modules to queue messages for execution at a certain block height.
- Evidence - Evidence handling for double signing, misbehaviour, etc.
- Feegrant - Grant fee allowances for executing transactions.
- Governance - On-chain proposals and voting.
- Mint - Creation of new units of staking token.
- Params - Globally available parameter store.
- Slashing - Validator punishment mechanisms.
- Staking - Proof-of-Stake layer for public blockchains.
- Upgrade - Software upgrades handling and coordination.
To learn more about the process of building modules, visit the building modules reference documentation.
IBC
The IBC module for the SDK has moved to its own repository.