├── .codespellignore ├── .github ├── CODEOWNERS ├── ISSUE_TEMPLATES │ └── ISSUE_TEMPLATE.md ├── PULL_REQUEST_TEMPLATE.md │ └── PULL_REQUEST_TEMPLATE.md └── workflows │ └── ci.yml ├── .gitignore ├── README.md ├── assets └── css │ └── style.scss ├── cip-template.md ├── cips ├── README.md ├── cip-X.md └── process.md ├── config ├── .markdownlint.yaml └── mlc_config.json └── website ├── .gitignore ├── README.md ├── babel.config.js ├── docusaurus.config.js ├── package-lock.json ├── package.json ├── sidebars.js ├── src ├── css │ └── custom.css └── pages │ └── index.module.css ├── static ├── .nojekyll └── img │ ├── CIP-process.png │ └── favicon.ico ├── tsconfig.json └── yarn.lock /.codespellignore: -------------------------------------------------------------------------------- 1 | uint 2 | ith 3 | nd 4 | mitre 5 | readded 6 | crate 7 | developper 8 | ist 9 | iam 10 | espace 11 | acn 12 | ende 13 | cip 14 | cips 15 | CIPS 16 | -------------------------------------------------------------------------------- /.github/CODEOWNERS: -------------------------------------------------------------------------------- 1 | # Primary repo maintainers 2 | 3 | * @cosmos/sdk-core-dev 4 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATES/ISSUE_TEMPLATE.md: -------------------------------------------------------------------------------- 1 | 2 | # ATTENTION 3 | 4 | If you would like to submit an CIP and it has already been written as a draft (see the [template](https://github.com/cosmos/CIPs/blob/main/cip-template.md) for an example), please submit it as a [Pull Request](https://github.com/cosmos/CIPs/pulls). 5 | 6 | If you are considering a proposal but would like to get some feedback on the idea before submitting a draft, then continue opening an Issue as a thread for discussion. Note that the more clearly and completely you state your idea the higher the quality of the feedback you are likely to receive. 7 | 8 | Keep in mind the following guidelines from [CIP-Process](./process.md): 9 | 10 | > Each CIP must have a champion - someone who writes the CIP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. The CIP champion (a.k.a. Author) should first attempt to ascertain whether the idea is CIP-able. Posting to the the Protocol Discussion forum or opening an Issue is the best way to go about this. 11 | 12 | > Vetting an idea publicly before going as far as writing a CIP is meant to save the potential author time. Asking the Cosmos community first if an idea is original helps prevent too much time being spent on something that is guaranteed to be rejected based on prior discussions (searching the Internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will work for most people in most areas where Cosmos is used. 13 | 14 | > Once the champion has asked the Cosmos community as to whether an idea has any chance of acceptance, a draft CIP should be presented as a Pull Request. This gives the author a chance to flesh out the draft CIP to make properly formatted, of high quality, and to address initial concerns about the proposal. 15 | -------------------------------------------------------------------------------- /.github/PULL_REQUEST_TEMPLATE.md/PULL_REQUEST_TEMPLATE.md: -------------------------------------------------------------------------------- 1 | When opening a pull request to submit a new CIP, please use the suggested template: https://github.com/cosmos/CIPs/blob/main/cip-template.md 2 | 3 | We have a GitHub bot that automatically merges some PRs. It will merge yours immediately if certain criteria are met: 4 | 5 | - The PR edits only existing draft PRs. 6 | - The build passes. 7 | - Your GitHub username or email address is listed in the 'author' header of all affected PRs, inside . 8 | - If matching on email address, the email address is the one publicly listed on your GitHub profile. 9 | -------------------------------------------------------------------------------- /.github/workflows/ci.yml: -------------------------------------------------------------------------------- 1 | name: Continuous Integration 2 | 3 | on: 4 | pull_request: 5 | types: 6 | - opened 7 | - reopened 8 | - synchronize 9 | - ready_for_review 10 | - edited 11 | 12 | concurrency: 13 | group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }} 14 | cancel-in-progress: true 15 | 16 | jobs: 17 | save-pr: 18 | name: Save PR Number 19 | runs-on: ubuntu-latest 20 | 21 | steps: 22 | - name: Save PR number 23 | env: 24 | PR_NUMBER: ${{ github.event.number }} 25 | PR_SHA: ${{ github.event.pull_request.head.sha }} 26 | MERGE_SHA: ${{ github.sha }} 27 | run: | 28 | mkdir -p ./pr 29 | echo $PR_NUMBER > ./pr/pr_number 30 | echo $PR_SHA > ./pr/pr_sha 31 | echo $MERGE_SHA > ./pr/merge_sha 32 | 33 | - name: Upload PR Number 34 | uses: actions/upload-artifact@65d862660abb392b8c4a3d1195a2108db131dd05 35 | with: 36 | name: pr_number 37 | path: pr/ 38 | 39 | codespell: 40 | name: CodeSpell 41 | runs-on: ubuntu-latest 42 | 43 | steps: 44 | - name: Checkout CIP Repository 45 | uses: actions/checkout@v3 46 | 47 | - name: Get Changed Files 48 | id: changed 49 | continue-on-error: true 50 | run: | 51 | echo "CHANGED_FILES<> $GITHUB_ENV 52 | gh pr diff ${{ github.event.number }} --name-only | sed -e 's|$|,|' | xargs -i echo "{}" >> $GITHUB_ENV 53 | echo "EOF" >> $GITHUB_ENV 54 | env: 55 | GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} 56 | 57 | - name: Run CodeSpell 58 | uses: codespell-project/actions-codespell@v2 59 | if: steps.changed.outcome == 'success' 60 | with: 61 | check_filenames: true 62 | path: ${{ env.CHANGED_FILES }} 63 | skip: .git,Gemfile.lock,**/*.png,**/*.gif,**/*.jpg,**/*.svg,vendor,_site,_config.yml,style.css 64 | ignore_words_file: .codespellignore 65 | 66 | markdownlint: 67 | name: Markdown Linter 68 | runs-on: ubuntu-latest 69 | steps: 70 | - name: Checkout CIP Repository 71 | uses: actions/checkout@v3 72 | 73 | - name: Get Changed Files 74 | id: changed 75 | continue-on-error: true 76 | run: | 77 | echo "CHANGED_FILES<> $GITHUB_ENV 78 | gh pr diff ${{ github.event.number }} --name-only | grep -E -x '[^/]+\.md|CIPS/cip-[0-9]+\.md' >> $GITHUB_ENV 79 | echo "EOF" >> $GITHUB_ENV 80 | env: 81 | GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} 82 | 83 | - name: Lint 84 | uses: DavidAnson/markdownlint-cli2-action@v10 85 | if: steps.changed.outcome == 'success' 86 | with: 87 | command: config 88 | globs: | 89 | config/.markdownlint.yaml 90 | ${{ env.CHANGED_FILES }} 91 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | .vscode 2 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Cosmos Improvement Proposals (CIPs) 2 | 3 |
4 | 5 | License: Apache-2.0 6 | 7 | 8 | Discord 9 | 10 |
11 | 12 | Cosmos Improvement Proposals (CIPs) describe standards for the Cosmos platform, including core protocol specifications, client APIs, and module and IBC standards. 13 | 14 | **Before you initiate a pull request**, please read the [CIP Process](./cips/process.md) document. Ideas should be thoroughly discussed prior to opening a pull request, 15 | such as on the [Cosmos Discussion Boards](https://github.com/orgs/cosmos/discussions/categories/cip) , or in a [GitHub issue in this repository](https://github.com/cosmos/cips/issues). CIPs should begin by copying the 16 | [cip-template](./cip-template.md). 17 | 18 | Browse all current and draft CIPs on the official CIP site (Coming Soon..) 19 | 20 | (TODO: setup this bot): Once your first PR is merged, we have a bot that helps out by automatically merging PRs to draft CIPs. For this to work, it has to be able to tell that you own the draft being edited. Make sure that the 'author' line of your CIP contains either your GitHub username or your email address inside . If you use your email address, that address must be the one publicly shown on [your GitHub profile](https://github.com/settings/profile). 21 | 22 | ## Project Goal 23 | 24 | The Cosmos Improvement Proposals repository exists as a place to share concrete proposals with potential users of the proposal and the Cosmos community at large. 25 | 26 | ## CIPs 27 | 28 | | Number | Title | Author | Type | Status | 29 | |--------|-------|--------|------|--------| 30 | -------------------------------------------------------------------------------- /assets/css/style.scss: -------------------------------------------------------------------------------- 1 | --- 2 | # Only the main Sass file needs front matter (the dashes are enough) 3 | --- 4 | 5 | @import 'minima'; 6 | 7 | .page-content { 8 | a.anchor-link { 9 | width: 16px; 10 | height: 16px; 11 | display: inline-block; 12 | margin-left: -22px; 13 | &:hover { 14 | background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' class='anchor-link-icon' viewBox='0 0 16 16' version='1.1' width='16' height='16' aria-hidden='true'%3E%3Cpath fill-rule='evenodd' d='M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z'%3E%3C/path%3E%3C/svg%3E"); 15 | } 16 | } 17 | } 18 | 19 | main.page-content { 20 | div.wrapper { 21 | max-width: calc(1280px - (30px * 2)); 22 | } 23 | } 24 | -------------------------------------------------------------------------------- /cip-template.md: -------------------------------------------------------------------------------- 1 | --- 2 | cip: 3 | title: 4 | author: , FirstName (@GitHubUsername) and GitHubUsername (@GitHubUsername)> 5 | discussions-to: 6 | status: Draft 7 | type: 8 | category (only required for Standards Track): 9 | created: 10 | requires (optional): 11 | replaces (optional): 12 | --- 13 | 14 | This is the suggested template for new CIPs. 15 | 16 | Note that an CIP number will be assigned by an editor. When opening a pull request to submit your CIP, please use an abbreviated title in the filename, `cip-draft_title_abbrev.md`. 17 | 18 | The title should be 44 characters or less. 19 | 20 | ## Simple Summary 21 | 22 | "If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the CIP. Imagine an email subject line, GitHub PR title, or forum post title. 23 | 24 | ## Abstract 25 | 26 | A short (~200 word) description of the technical issue being addressed. This should be a very terse and human-readable version of the specification section. Someone should be able to read only the abstract to get the gist of what this specification does. 27 | 28 | ## Motivation 29 | 30 | The motivation section should describe the "why" of this CIP. What problem does it solve? Why should someone want to implement this standard? What benefit does it provide to the Cosmos ecosystem? What use cases does this CIP address? 31 | 32 | ## Documentation 33 | 34 | Explain the proposal as if it was already deployed on the network and you were documenting it for another Cosmos user. That generally means: 35 | 36 | - Introducing new named concepts. 37 | - Explaining the feature largely in terms of examples. 38 | - Explaining how Cosmos users should think about the feature, and how it should impact the way they use Cosmos. It should explain the impact as concretely as possible. 39 | - If applicable, provide sample error messages, deprecation warnings, or migration guidance. 40 | - If applicable, describe the differences between teaching this to existing Cosmos users and new Cosmos users. 41 | 42 | ## Specification 43 | 44 | This is the technical portion of the CIP. Explain the design in sufficient detail that: 45 | 46 | - Its interaction with other features is clear. 47 | - It is reasonably clear how the feature would be implemented. 48 | - Corner cases are dissected by example. 49 | 50 | The section should return to the examples given in the previous section, 51 | and explain more fully how the detailed proposal makes those examples work. 52 | The specification should be detailed enough to allow competing, interoperable 53 | implementations for any of the Cosmos components (eg. tendermint, tendermint-rs, 54 | ibc-go, ibc-rs, etc. TODO a link for all these) 55 | 56 | ## Drawbacks 57 | 58 | Why should we not do this? 59 | 60 | ## Rationale 61 | 62 | The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. It should address: 63 | 64 | - Why is this design the best in the space of possible designs? 65 | - What other designs have been considered and what is the rationale for not choosing them? 66 | - What is the impact of not doing this? 67 | 68 | ## Prior Art 69 | 70 | Discuss prior art, both the good and the bad, in relation to this proposal. For 71 | instance, 72 | 73 | - Does this feature exist in other blockchain networks and what experience have their 74 | community had? 75 | - What lessons can we learn from what others have done? 76 | - Are there papers to cite with relevant theoretical background? 77 | 78 | This section is intended to encourage you as an author to think about the lessons from other networks, provide readers of your CIP with a fuller picture. 79 | 80 | ## Unresolved Questions 81 | 82 | - What parts of the design do you expect to resolve through the CIP process before this gets approved? 83 | - What parts of the design do you expect to resolve through the implementation of this feature before stabilization? 84 | - What related issues do you consider out of scope for this CIP that could be addressed in the future independently of the solution that comes out of this CIP? 85 | 86 | ## Backwards Compatibility 87 | 88 | All CIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The CIP must explain how the author proposes to deal with these incompatibilities. CIP submissions without a sufficient backwards compatibility treatise may be rejected outright. 89 | 90 | ## Test Cases 91 | 92 | Test cases for an implementation are mandatory for CIPs that are affecting consensus changes. Other CIPs can choose to include links to test cases if applicable. 93 | 94 | ## Reference Implementation 95 | 96 | An optional section that contains a reference/example implementation that people can use to assist in understanding or implementing this specification. If the implementation is too large to reasonably be included inline, then consider adding it as one or more files in `../assets/cip-####/`. 97 | 98 | ## Security Considerations 99 | 100 | All CIPs must contain a section that discusses the security implications/considerations relevant to the proposed change. Include information that might be important for security discussions, surfaces risks and can be used throughout the life cycle of the proposal. E.g. include security-relevant design decisions, concerns, important discussions, implementation-specific guidance and pitfalls, an outline of threats and risks and how they are being addressed. CIP submissions missing the "Security Considerations" section will be rejected. An CIP cannot proceed to status "Final" without a Security Considerations discussion deemed sufficient by the reviewers. 101 | 102 | ## Future Possibilities 103 | 104 | Think about what the natural extension and evolution of your proposal would be and how it would affect the network and project as a whole in a holistic way. 105 | Try to use this section as a tool to more fully consider all possible interactions with the project and network in your proposal. 106 | Also consider how this all fits into the roadmap for the project and of the relevant sub-team. 107 | 108 | This is also a good place to "dump ideas", if they are out of scope for the RFC you are writing but otherwise related. 109 | 110 | If you have tried and cannot think of any future possibilities, you may simply state that you cannot think of anything. 111 | 112 | Note that having something written down in the future-possibilities section is not a reason to accept the current or a future CIP; such notes should be in the section on motivation or rationale in this or subsequent CIPs. The section merely provides additional information. 113 | 114 | ## Copyright 115 | 116 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 117 | -------------------------------------------------------------------------------- /cips/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | sidebar_position: 1 3 | --- 4 | 5 | # Cosmos Improvement Proposals (CIPs) 6 | 7 | The Cosmos software powers over 50 independent blockchains, and is used by thousands of developers and users. The Cosmos Improvement Proposals (CIPs) repository exists as a place to standardize interfaces related to clients (wallets & block explorers), modules, and IBC. 8 | -------------------------------------------------------------------------------- /cips/cip-X.md: -------------------------------------------------------------------------------- 1 | --- 2 | cip: 3 | title: Off-chain Messages Signing 4 | author: @JulianToledano 5 | status: Draft 6 | type: Standards Track 7 | created: 2023-10-10 8 | --- 9 | 10 | ## Simple Summary 11 | 12 | This is a convention for signing arbitrary messages. We propose this specification as a method for signing and 13 | verifying off-chain arbitrary messages. 14 | 15 | ## Abstract 16 | 17 | This CIP addresses the need for arbitrary message signing. These messages can be used for application sign-in by 18 | providing proof of wallet ownership, but their use is not limited to this case. They can also be utilized for signing 19 | files, text, and more. 20 | 21 | There is no requirement for these messages to be posted to the network. That's why a set of off-chain messages is 22 | defined with specific characteristics that prevent them from being processed as on-chain transactions. 23 | 24 | This CIP defines two different messages. The first one allows users to sign any arbitrary data, including files, text, 25 | objects, and more. The second one provides a way for application sign-in by defining a standard human-readable message 26 | format that is parameterized by scope, session details, and security mechanisms. 27 | 28 | ## Motivation 29 | 30 | Having the ability to sign messages off-chain has proven to be a fundamental aspect of nearly any blockchain. 31 | The notion of signing messages off-chain has many added benefits, such as smart accounts where off-chain signing allows 32 | for application layer authorizations saving on computational costs and reducing transaction throughput and overhead. 33 | Within the context of the Cosmos ecosystem, some of the major applications of signing such data include, but are not 34 | limited to, providing a cryptographically secure and verifiable means of proving validator identity and possibly 35 | associating it with some other framework or organization. Additionally, having the ability to sign Cosmos messages 36 | with a Ledger or similar HSM device. 37 | 38 | ## Documentation 39 | 40 | This CIP introduces the concept of off-chain messages. Off-chain messages are messages that are not and cannot be 41 | submitted to the network. 42 | 43 | It opens the door to sign-in in dApps and webs and signing of files, text and objects. 44 | 45 | Command-line applications will allow users to sign and verify files with commands like: 46 | 47 | + `simd keys sign [file] --from [key_name] > signed_file.json` 48 | + `simd keys verify [file]` 49 | 50 | 51 | Websites and applications will be able to prove account ownership with a human-readable message instead of a random challenge. 52 | An example format might look like this: 53 | 54 | ``` 55 | Prove account ownership to 56 | https://myApp.com 57 | 58 | "appDomain": "myApp", 59 | "uri": "https://myApp.com/", 60 | "signerAddress": "cosmos1hftz5ugqmpg9243xeegsqqav62f8hnywsjr4xr", 61 | "nonce": "14368412", 62 | "issued-at": "2023-10-10T10:10:10Z" 63 | ``` 64 | 65 | This approach is an improvement over the current state, as it allows for the signing of arbitrary data like files and 66 | offers a more user-friendly sign-in process, replacing non-human-readable random challenges. 67 | 68 | ## Specification 69 | 70 | Off-chain signed messages should resemble Cosmos SDK transactions but **must not** constitute a valid on-chain transaction. 71 | `chain-id`, `account_number`, and `sequence` must all be assigned invalid values. 72 | 73 | An off-chain transaction follows these rules: 74 | 75 | + the memo must be empty 76 | + nonce, sequence number must be equal to 0 77 | + chain-id must be equal to “” 78 | + fee gas must be equal to 0 79 | + fee amount must be an empty array 80 | 81 | Verification of an off-chain transaction follows the same rules as an on-chain one, except for the specification 82 | differences highlighted above. 83 | 84 | As messages in Cosmos are defined as proto definitions, different messages can be defined for different off-chain 85 | use cases, such as Sign-In, proof of wallet ownership or the ability to sign arbitrary data. 86 | 87 | All off-chain messages will be of the type `offchain/messageKind`. 88 | 89 | ### MsgSignArbitraryData 90 | 91 | The first message added to the `offchain` package is `MsgSignArbitraryData`. 92 | 93 | `MsgSignArbitraryData` enables developers to sign arbitrary bytes that are valid only in an off-chain context. Here, 94 | `AppDomain` represents the application requesting off-chain message signing, while `signerAddress` is the account address of 95 | the signer. `Data` consists of a string with valid UTF-8 text that can represent various forms of data, including text, files, or 96 | objects. The decision on how to deserialize, serialize, and interpret `Data` is left to the application developers, 97 | depending on their specific use case. It is important to note that some signers are not capable of signing 98 | arbitrary-length messages. 99 | 100 | Application developers have the discretion to determine how `Data` should be handled. This includes defining the 101 | serialization and deserialization processes and specifying the object that Data represents within their context. 102 | 103 | Proto definition: 104 | 105 | ```protobuf 106 | // MsgSignArbitraryData defines an arbitrary, general-purpose, off-chain message 107 | message MsgSignArbitraryData { 108 | option (cosmos.msg.v1.signer) = "signerAddress"; 109 | // AppDomain is the application requesting off-chain message signing 110 | string appDomain = 1; 111 | // Signer is the sdk.AccAddress of the message signer 112 | string signerAddress = 2 [(cosmos_proto.scalar) = "cosmos.AddressString"]; 113 | // Data represents the raw bytes of the content that is signed (text, json, etc) 114 | string data = 3 [(gogoproto.jsontag) = "data"]; 115 | } 116 | ``` 117 | 118 | Signed MsgSignArbitraryData json example: 119 | 120 | ```json 121 | { 122 | "type": "cosmos-sdk/StdTx", 123 | "value": { 124 | "msg": [ 125 | { 126 | "type": "offchain/MsgSignArbitraryData", 127 | "value": { 128 | "appDomain": "simd", 129 | "signerAddress": "cosmos1hftz5ugqmpg9243xeegsqqav62f8hnywsjr4xr", 130 | "data": "cmFuZG9t" 131 | } 132 | } 133 | ], 134 | "fee": { 135 | "amount": [], 136 | "gas": "0" 137 | }, 138 | "signatures": [ 139 | { 140 | "pub_key": { 141 | "type": "tendermint/PubKeySecp256k1", 142 | "value": "AqnDSiRoFmTPfq97xxEb2VkQ/Hm28cPsqsZm9jEVsYK9" 143 | }, 144 | "signature": "8y8i34qJakkjse9pOD2De+dnlc4KvFgh0wQpes4eydN66D9kv7cmCEouRrkka9tlW9cAkIL52ErB+6ye7X5aEg==" 145 | } 146 | ], 147 | "memo": "" 148 | } 149 | } 150 | ``` 151 | 152 | ### MsgProveIdentity 153 | 154 | The second message added to the `offchain` package is `MsgProveIdentity`. 155 | 156 | `MsgProveIdentity` enables the proof of wallet ownership for applications sign-in. In this context, `AppDomain` is the 157 | application requesting off-chain message signing. `URI` refers to the resource that is the subject of the signing. 158 | `signerAddress` is the account address of the signer. `Nonce` is a random string typically chosen by the relying on party and 159 | used to prevent replay attacks. `Issued-at` the time when the message was generated. 160 | 161 | Proto definition: 162 | 163 | ```protobuf 164 | // MsgProveIdentity defines an arbitrary, general-purpose, off-chain message 165 | message MsgProveIdentity { 166 | option (cosmos.msg.v1.signer) = "signerAddress"; 167 | // AppDomain is the application requesting off-chain message signing 168 | string appDomain = 1; 169 | // Uri is the resource that is the subject of the signing 170 | string uri = 2; 171 | // Signer is the sdk.AccAddress of the message signer 172 | string signerAddress = 3 [(cosmos_proto.scalar) = "cosmos.AddressString"]; 173 | // Nonce is a random string 174 | string nonce = 4; 175 | // Issued-at is the time when the message was generated 176 | google.protobuf.Timestamp issued-at = 5; 177 | } 178 | ``` 179 | 180 | Signed MsgProveIdentity JSON example: 181 | 182 | ```json 183 | { 184 | "type": "cosmos-sdk/StdTx", 185 | "value": { 186 | "msg": [ 187 | { 188 | "type": "offchain/MsgProveIdentity", 189 | "value": { 190 | "appDomain": "exampleSwap", 191 | "uri": "https://exampleSwap.com/login", 192 | "signerAddress": "cosmos1hftz5ugqmpg9243xeegsqqav62f8hnywsjr4xr", 193 | "nonce": "14368412", 194 | "issued-at": "2023-10-10T16:25:24Z" 195 | } 196 | } 197 | ], 198 | "fee": { 199 | "amount": [], 200 | "gas": "0" 201 | }, 202 | "signatures": [ 203 | { 204 | "pub_key": { 205 | "type": "tendermint/PubKeySecp256k1", 206 | "value": "AqnDSiRoFmTPfq97xxEb2VkQ/Hm28cPsqsZm9jEVsYK9" 207 | }, 208 | "signature": "8y8i34qJakkjse9pOD2De+dnlc4KvFgh0wQpes4eydN66D9kv7cmCEouRrkka9tlW9cAkIL52ErB+6ye7X5aEg==" 209 | } 210 | ], 211 | "memo": "" 212 | } 213 | } 214 | ``` 215 | 216 | ## Drawbacks 217 | 218 | This CIP requires a fixed relationship between an account address and a public key. That means it won't work if [ADR-034](https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-rc.1/docs/architecture/adr-034-account-rekeying.md) 219 | is implemented. This is because we cannot assume that `Address = Hash(PubKey)` anymore. This is not problematic for 220 | everything that needs to be verified on-chain, but it is for off-chain. If a signer has changed its public key, how can 221 | that be verified off-chain? Even if the message is enriched with a `chain-id` field, who is responsible for matching 222 | `chain-id` and the node's IP? 223 | 224 | It'd work with current multisigs as they are deterministic but on chain multisigs would not work here. 225 | 226 | ## Rationale 227 | 228 | By creating different messages for different use cases, this design fulfills the current demands of the community for 229 | [arbitrary data signing](https://github.com/cosmos/cosmos-sdk/issues/4581) and [human-readable sign-in message](https://github.com/cosmos/cosmos-sdk/pull/7896#issuecomment-1125254734). 230 | 231 | Implementing this design aligns with the long-standing requests from the community. Several zones have implemented their 232 | own arbitrary messages based on ADR-036: 233 | 234 | + [Sommelier](https://github.com/cosmos/cosmos-sdk/pull/7727#issuecomment-821201911) 235 | + [Aleph.im](https://github.com/cosmos/cosmos-sdk/pull/7727#issuecomment-821776061) 236 | + [Secret](https://github.com/scrtlabs/cosmos-sdk/compare/v0.9.1-scrt...v0.9.2-scrt) 237 | 238 | Even some work have been done on [cosmjs](https://github.com/cosmos/cosmjs/pull/847). 239 | 240 | There are zones and applications that prove account ownership by signing a random challenge with ADR-036 specification. 241 | 242 | ## Prior Art 243 | 244 | Other blockchains such as Ethereum with [eip-4361](https://eips.ethereum.org/EIPS/eip-4361) or Solana with its 245 | [Off-chain message signing](https://docs.solana.com/proposals/off-chain-message-signing) offer standard methods for 246 | application sign-in. 247 | 248 | There was a prior attempt to implement this in the sdk with [ADR-036](https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-rc.1/docs/architecture/adr-036-arbitrary-signature.md). 249 | However, a consensus was not achieved on ADR-036, as the community demanded a way for sign-in method that ADR-036 250 | did not provide. This is the main reason for defining two different messages in this CIP. One for arbitrary data and 251 | the other for sing-in. 252 | 253 | 254 | ## Unresolved Questions 255 | 256 | + Is defining different messages per use case the best approach, or could a protobuf with a `oneof` be sufficient? 257 | + Should `Data` in `MsgSignArbitraryData` have a max length? 258 | 259 | ## Backwards Compatibility 260 | 261 | Backwards compatibility is guaranteed as this CIP introduces new messages but does not modify any prior work. Although 262 | it won't be compatible with ADR-036 as it defines different messages. 263 | 264 | ## Security Considerations 265 | 266 | It is important to notice that the `Data` field in `MsgSignArbitraryData` consists of a valid UTF-8 string, this does 267 | not mean that the string is printable or that the signing device would be capable of printing it. Examples of such valid 268 | strings are NULL, [BELL](https://en.wikipedia.org/wiki/Bell_character), emojis or unicode in the 269 | [Private Use Areas](https://en.wikipedia.org/wiki/Private_Use_Areas). 270 | 271 | There are no more security considerations as the messages will not be on-chain. 272 | 273 | ## Future Possibilities 274 | 275 | This opens the possibility to create new off-chain messages for future use cases. 276 | 277 | ## Copyright 278 | 279 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 280 | -------------------------------------------------------------------------------- /cips/process.md: -------------------------------------------------------------------------------- 1 | --- 2 | sidebar_position: 2 3 | title: CIP Process - Purpose and Guidelines 4 | --- 5 | 6 | ## Simple Summary 7 | 8 | A process for reviewing and finalizing changes to Cosmos using Cosmos 9 | Improvement Proposals (CIPs). 10 | 11 | A CIP is a design document providing information to the Cosmos community, or describing a new feature or major change for Cosmos or its processes or environment. 12 | The CIP should provide a concise technical specification of the feature or change and a clear rationale. 13 | The CIP author is responsible for building consensus within the community and documenting dissenting opinions. 14 | 15 | ## Abstract 16 | 17 | The CIP process draws heavily from Ethereum's EIP process and Rust's RFC 18 | process. It pertains primarily to the protocol and APIs of the Cosmos Hub 19 | blockchain (Cosmos, for short), including Tendermint, Cosmos-SDK, IBC, and other modules. 20 | Ideas for a change to the Cosmos protocols or APIs are first vetted in the 21 | Cosmos forums and channels, and then formalized as a CIP, detailing clearly the 22 | proposed change. The CIP includes all information necessary to implement the 23 | change, including detailed specification and rationale. CIPs are checked for 24 | correctnes and process adherence by a select group of CIP editors, though 25 | finalization of a CIP does not equate to acceptance into Cosmos. For that, CIP 26 | authors must turn to Cosmos Governance. 27 | 28 | ## Motivation 29 | 30 | As the Cosmos ecosystem is growing and maturing, it is becoming increasingly concerning that standards around APIs and changes are not being canocilised, this can lead to a fragmented ecosystem in which users and wallets are unsure which api to use, and developers are unsure which api to implement. 31 | 32 | ### CIP Workflow 33 | 34 | #### Shepherding a CIP 35 | 36 | Parties involved in the process are you, the champion or *CIP author*, the *CODEOWNERS*, and the *Cosmos Core Developers*. 37 | 38 | Before you begin writing a formal CIP, you should vet your idea. Ask the Cosmos community first if an idea is original to avoid wasting time on something that will be rejected based on prior research. It is thus recommended to open a discussion thread on [the Cosmos discussion board](https://github.com/orgs/cosmos/discussions/categories/product-feedback) to do this, but you can also use an [the Issues section of this repository]. 39 | 40 | Once the idea has been vetted, your next responsibility will be to present (by means of a CIP) the idea to the reviewers and all interested parties, invite editors, developers, and the community to give feedback on the aforementioned channels. You should try and gauge whether the interest in your CIP is commensurate with both the work involved in implementing it and how many parties will have to conform to it. For example, the work required for implementing a Core CIP will be much greater than for an Interface and the CIP will need sufficient interest from the Cosmos development teams. Negative community feedback will be taken into consideration and may prevent your CIP from moving past the Draft stage. 41 | 42 | #### CIP Process 43 | 44 | The following is the standardization process for all CIPs in all tracks: 45 | 46 | ![CIP Status Diagram](../website/static/img/CIP-process.png) 47 | 48 | **Idea** - An idea that is pre-draft. This is not tracked within the CIP Repository. 49 | 50 | **Draft** - The first formally tracked stage of a CIP in development. A CIP is merged by a CIP Editor into the CIP repository when properly formatted. 51 | 52 | **Review** - A CIP Author marks a CIP as ready for and requesting Peer Review. 53 | 54 | **Last Call** - This is the final review window for a CIP before moving to `FINAL`. A CIP editor will assign `Last Call` status and set a review end date (review-period-end), typically 14 days later. 55 | 56 | If this period results in necessary normative changes it will revert the CIP to `REVIEW`. 57 | 58 | **Final** - This CIP represents the final standard. A Final CIP exists in a state of finality and should only be updated to correct errata and add non-normative clarifications. 59 | 60 | **Stagnant** - Any CIP in `DRAFT` or `REVIEW` if inactive for a period of 6 months or greater is moved to `STAGNANT`. A CIP may be resurrected from this state by Authors or CIP Editors through moving it back to `DRAFT`. 61 | 62 | >*CIP Authors are notified of any algorithmic change to the status of their CIP* 63 | 64 | **Withdrawn** - The CIP Author(s) have withdrawn the proposed CIP. This state has finality and can no longer be resurrected using this CIP number. If the idea is pursued at later date it is considered a new proposal. 65 | 66 | **Living** - A special status for CIPs that are designed to be continually updated and not reach a state of finality. This includes most notably CIP-1. Any changes to these CIPs will move between `REVIEW` and `LIVING` states. 67 | 68 | #### Submitting a CIP 69 | 70 | To create a CIP: 71 | 72 | - Fork this repository 73 | - Copy `cip-template.md` to `CIPS/cip-X.md` (don't assign a CIP number yet) 74 | - Fill in the CIP template with a first draft of the CIP 75 | - Submit a pull request back to this repo. When formatted correctly, Draft CIPs are given a CIP number and merged to the 76 | repo by a CIP editor. 77 | 78 | At this point, the CIP officially exists in Draft form with a designated CIP 79 | number. The process continues as follows: 80 | 81 | - Submit additional pull requests to improve the Draft. 82 | - Submit a pull request to change the CIP Status from Draft to Review. At this 83 | point, the CIP is officially ready for wider peer review from the Cosmos 84 | developers. They will open issues to further discuss elements of the CIP, or submit PRs to make changes. 85 | - Eventually, a CIP editor will change the status to Last Call, setting a 86 | deadling for further review, following which they will change the status to 87 | Final. 88 | - At this point, the CIP is finalized and should not be changed other than for cosmetic purposes. 89 | - The CIP can now be submitted to the [Cosmos Governance] process for 90 | acceptance onto the network. 91 | 92 | ### What belongs in a successful CIP? 93 | 94 | Each CIP should have the following parts: 95 | 96 | - Preamble - RFC 822 style headers containing metadata about the CIP, including the CIP number, a short descriptive title (limited to a maximum of 44 characters), and the author details. See [below](#cip-header-preamble) for details. 97 | - Simple Summary - simplified and layman-accessible explanation of the CIP. Imagine an email subject line, GitHub PR title, or forum post title. 98 | - Abstract - A short (~200 word) description of the technical issue being addressed. 99 | - Motivation - A motivation section is critical for CIPs that want to change the Cosmos protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the CIP solves. CIP submissions without sufficient motivation may be rejected outright. 100 | - Documentation - Explain the proposal as if it was already deployed on the network and you were documenting it for another Cosmos user. 101 | - Specification - The technical specification should describe the syntax and semantics of any new feature in detail. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Cosmos components. 102 | - Drawbacks - Why should we not do this? 103 | - Rationale - The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion. 104 | - Prior Art - Discuss prior art, both the good and the bad, in relation to this proposal 105 | - Unresolved Questions - What will be resolved through the CIP process, what 106 | will be resolved during implementation, and what related issues are out of 107 | scope? 108 | - Backwards Compatibility - All CIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The CIP must explain how the author proposes to deal with these incompatibilities. CIP submissions without a sufficient backwards compatibility treatise may be rejected outright. 109 | - Test Cases - Test cases for an implementation are mandatory for CIPs that are affecting consensus changes. Tests should either be inlined in the CIP as data (such as input/expected output pairs, or included in `../assets/cip-###/`. 110 | - Reference Implementation - An optional section that contains a reference/example implementation that people can use to assist in understanding or implementing this specification. 111 | - Security Considerations - All CIPs must contain a section that discusses the security implications/considerations relevant to the proposed change. Include information that might be important for security discussions, surfaces risks and can be used throughout the life-cycle of the proposal. E.g. include security-relevant design decisions, concerns, important discussions, implementation-specific guidance and pitfalls, an outline of threats and risks and how they are being addressed. CIP submissions missing the "Security Considerations" section will be rejected. A CIP cannot proceed to status "Final" without a Security Considerations discussion deemed sufficient by the reviewers. 112 | - Future Possibilities - Think about what the natural extension and evolution 113 | of your proposal would be and how it would affect the network and project as a 114 | whole in a holistic way. 115 | - Copyright Waiver - All CIPs must be in the public domain. See the bottom of this CIP for an example copyright waiver. 116 | 117 | ### CIP Formatting 118 | 119 | CIPs should be written in [markdown] format. There is a [template](https://github.com/cosmos/CIPs/blob/main/cip-template.md) to follow. 120 | 121 | #### CIP Header Preamble 122 | 123 | Each CIP must begin with an [RFC 822](https://www.ietf.org/rfc/rfc822.txt) style header preamble, preceded and followed by three hyphens (`---`). The headers must appear in the following order. Headers marked with "*" are optional and are described below. All other headers are required. 124 | 125 | `cip:` *CIP number* (this is determined by the CIP editor) 126 | 127 | `title:` *CIP title* 128 | 129 | `author:` *a list of the author's or authors' name(s) and/or username(s), or name(s) and email(s). Details are below.* 130 | 131 | `* discussions-to:` *a url pointing to the official discussion thread* 132 | 133 | `status:` *Draft, Review, Last Call, Final, Stagnant, Withdrawn, Living* 134 | 135 | `* review-period-end:` *date review period ends* 136 | 137 | `type:` *Standards Track, Meta, or Informational* 138 | 139 | `* category:` *Core or Interface* (fill out for Standards Track CIPs only) 140 | 141 | `created:` *date created on* 142 | 143 | `* updated:` *comma separated list of dates* 144 | 145 | `* requires:` *CIP number(s)* 146 | 147 | `* replaces:` *CIP number(s)* 148 | 149 | `* superseded-by:` *CIP number(s)* 150 | 151 | `* resolution:` *a url pointing to the resolution of this CIP* 152 | 153 | Headers that permit lists must separate elements with commas. 154 | 155 | Headers requiring dates will always do so in the format of ISO 8601 (yyyy-mm-dd). 156 | 157 | ##### `author` header 158 | 159 | The `author` header lists the names, email addresses or usernames of the authors/owners of the CIP. Those who prefer anonymity may use a username only, or a first name and a username. The format of the `author` header value must be: 160 | 161 | > Random J. User <> 162 | 163 | or 164 | 165 | > Random J. User (@username) 166 | 167 | if the email address or GitHub username is included, and 168 | 169 | > Random J. User 170 | 171 | if the email address is not given. 172 | 173 | It is not possible to use both an email and a GitHub username at the same time. If important to include both, one could include their name twice, once with the GitHub username, and once with the email. 174 | 175 | At least one author must use a GitHub username, in order to get notified on change requests and have the capability to approve or reject them. 176 | 177 | ##### `resolution` header 178 | 179 | The `resolution` header is required for Standards Track CIPs only. It contains a URL that should point to an email message or other web resource where the pronouncement about the CIP is made. 180 | 181 | ##### `discussions-to` header 182 | 183 | While a CIP is a draft, a `discussions-to` header will indicate the mailing list or URL where the CIP is being discussed. As mentioned above, examples for places to discuss your CIP include [the Cosmos Discord], an issue in this repo or in a fork of this repo, [the Cosmos forum] (this is suitable for CIPs that may be contentious or have a strong governance aspect), and [Reddit r/cosmosnetwork](https://www.reddit.com/r/cosmosnetwork/). 184 | 185 | No `discussions-to` header is necessary if the CIP is being discussed privately with the author. 186 | 187 | As a single exception, `discussions-to` cannot point to GitHub pull requests. 188 | 189 | ##### `type` header 190 | 191 | The `type` header specifies the type of CIP: Standards Track, Meta, or Informational. If the track is Standards please include the subcategory (core, networking, or interface). 192 | 193 | ##### `category` header 194 | 195 | The `category` header specifies the CIP's category. This is required for standards-track CIPs only. 196 | 197 | ##### `created` header 198 | 199 | The `created` header records the date that the CIP was assigned a number. Both headers should be in yyyy-mm-dd format, e.g. 2001-08-14. 200 | 201 | ##### `updated` header 202 | 203 | The `updated` header records the date(s) when the CIP was updated with "substantial" changes. This header is only valid for CIPs of Draft and Active status. 204 | 205 | ##### `requires` header 206 | 207 | CIPs may have a `requires` header, indicating the CIP numbers that this CIP depends on. 208 | 209 | ##### `superseded-by` and `replaces` headers 210 | 211 | CIPs may also have a `superseded-by` header indicating that a CIP has been rendered obsolete by a later document; the value is the number of the CIP that replaces the current document. The newer CIP must have a `replaces` header containing the number of the CIP that it rendered obsolete. 212 | 213 | #### Linking to other CIPs 214 | 215 | References to other CIPs should follow the format `CIP-N` where `N` is the CIP number you are referring to. Each CIP that is referenced in a CIP **MUST** be accompanied by a relative markdown link the first time it is referenced, and **MAY** be accompanied by a link on subsequent references. The link **MUST** always be done via relative paths so that the links work in this GitHub repository, forks of this repository, the main CIPs site, mirrors of the main CIP site, etc. For example, you would link to this CIP with `[CIP-1](./cip-1.md)`. 216 | 217 | #### Auxiliary Files 218 | 219 | Images, diagrams and auxiliary files should be included in a subdirectory of the `assets` folder for that CIP as follows: `assets/cip-N` (where **N** is to be replaced with the CIP number). When linking to an image in the CIP, use relative links such as `../website/static/process/image.png`. 220 | 221 | #### Style Guide 222 | 223 | When referring to a CIP by number, it should be written in the hyphenated form `CIP-X` where `X` is the CIP's assigned number. 224 | 225 | ### CIP Ownership 226 | 227 | It occasionally becomes necessary to transfer ownership of CIPs to a new champion. In general, we'd like to retain the original author as a co-author of the transferred CIP, but that's really up to the original author. A good reason to transfer ownership is because the original author no longer has the time or interest in updating it or following through with the CIP process, or has fallen off the face of the 'net (i.e. is unreachable or isn't responding to email). A bad reason to transfer ownership is because you don't agree with the direction of the CIP. We try to build consensus around a CIP, but if that's not possible, you can always submit a competing CIP. 228 | 229 | If you are interested in assuming ownership of a CIP, send a message asking to take over, addressed to both the original author and the CIP editor. If the original author doesn't respond to the email in a timely manner, the CIP editor will make a unilateral decision (it's not like such decisions can't be reversed :)). 230 | 231 | ### CIP Editors 232 | 233 | TODO - see [Unresolved Questions](#unresolved-questions). 234 | 235 | The current CIP editors are 236 | 237 | - Ethan Buchman (@ebuchman) 238 | - ... 239 | 240 | #### CIP Editor Responsibilities 241 | 242 | For each new CIP that comes in, an editor does the following: 243 | 244 | - Read the CIP to check if it is ready: sound and complete. The ideas must make technical sense, even if they don't seem likely to get to final status. 245 | - The title should accurately describe the content. 246 | - Check the CIP for language (spelling, grammar, sentence structure, etc.), markup (GitHub flavored Markdown), code style 247 | 248 | If the CIP isn't ready, the editor will send it back to the author for revision, with specific instructions. 249 | 250 | Once the CIP is ready for the repository, the CIP editor will: 251 | 252 | - Assign a CIP number (generally the PR number or, if preferred by the author, the Issue # if there was discussion in the Issues section of this repository about this CIP) 253 | 254 | - Merge the corresponding pull request 255 | 256 | - Send a message back to the CIP author with the next step. 257 | 258 | Many CIPs are written and maintained by developers with write access to the Cosmos codebase. The CIP editors monitor CIP changes, and correct any structure, grammar, spelling, or markup mistakes we see. 259 | 260 | The editors don't pass judgment on CIPs. We merely do the administrative & editorial part. 261 | 262 | ## Drawbacks 263 | 264 | The CIP process outlined here requires a number of existing repos and projects 265 | to change their own processes and/or move them to this repository. There will be 266 | new overhead to maintaining and governing this new process. There may also be 267 | some redundancy as specifiction and design documents may be duplicated within 268 | the CIP repo and other repos. It's also one more repo to keep track off. 269 | 270 | ## Rationale 271 | 272 | This is a well worn process in the Ethereum and Rust communities. 273 | A single canonical place and standardized process across the Cosmos stack is 274 | necessary to unite the efforts of the many Cosmos components and to provide 275 | greater visibility into protocol and API changes to everyone. 276 | 277 | ## Prior Art 278 | 279 | This document was derived heavily from [Ethereum's EIP-1], which was derived heavily from [Bitcoin's BIP-0001] written by Amir Taaki which in turn was derived from [Python's PEP-0001]. 280 | It is also inspired by the [Rust RFC process](https://github.com/rust-lang/rfcs), especially their 281 | [RFC Template](https://github.com/rust-lang/rfcs/blob/master/0000-template.md) and 282 | [rfc-0002](https://github.com/rust-lang/rfcs/blob/master/text/0002-rfc-process.md). 283 | The bulk of the text was copied from [Ethereum's EIP-1] and modified as necessary. 284 | 285 | Although the PEP-0001 text was written by Barry Warsaw, Jeremy Hylton, and David Goodger, 286 | they are not responsible for its use in the Cosmos Improvement Process, and should not be bothered with technical questions specific to Cosmos or the CIP. 287 | Please direct all comments to the CIP editors. 288 | 289 | ## Unresolved Questions 290 | 291 | - Should we further decompose the "Core" category into perhaps Tendermint and 292 | State Machine, or even further, with distinctions like IBC, and more? Perhaps 293 | Tendermint and State Machine is the best place to start. 294 | - What is the full scope of APIs that CIPs should cover? Certainly any protocol 295 | breaking change to the blockchain or its state machine should have a CIP, but 296 | what about API changes that don't involve a protocol breaking change or new 297 | protocol feature? 298 | - Who are the initial editors and how are they chosen? 299 | - How exactly will this CIP process interact with other design and specification 300 | processes across Cosmos 301 | - What do we use as our equivalent of Ethereum's AllCoreDevs designation and 302 | process ? 303 | - This repo is a fork of the Ethereum EIP process and includes a Jekyll site, 304 | which is all pretty simple, but the Rust process and seems more advanced and 305 | there may be more worth adopting from their bots and build pipelines 306 | - What license should we use? EIPs use CC0 for everything (ie. no license, 307 | copyright is just waived!), but Rust RFCs are licensed dual Apache/MIT, 308 | which means anything we copy from Rust needs to respect those licenses (and 309 | thus can't use CC0 - you can't waive someone else's copyright). Should we just license 310 | everything here Apache 2.0 then? This document contains virtually nothing 311 | copied verbatim from Rust RFC, but the current cip-template.md does. 312 | -------------------------------------------------------------------------------- /config/.markdownlint.yaml: -------------------------------------------------------------------------------- 1 | # Rule details can be found at https://github.com/DavidAnson/markdownlint/blob/main/doc/Rules.md 2 | 3 | default: false 4 | 5 | # MD001/heading-increment/header-increment - Heading levels should only increment by one level at a time 6 | MD001: true 7 | # MD002/first-heading-h1/first-header-h1 - First heading should be a top-level heading (deprecated) 8 | MD002: false 9 | 10 | # MD003/heading-style/header-style - Heading style 11 | MD003: 12 | # Heading style 13 | style: "atx" 14 | 15 | # MD004/ul-style - Unordered list style 16 | MD004: 17 | # List style 18 | style: "consistent" 19 | 20 | # MD005/list-indent - Inconsistent indentation for list items at the same level 21 | MD005: true 22 | 23 | # MD006/ul-start-left - Consider starting bulleted lists at the beginning of the line (deprecated) 24 | MD006: false 25 | # MD007/ul-indent - Unordered list indentation 26 | MD007: false 27 | # MD009/no-trailing-spaces - Trailing spaces 28 | MD009: false 29 | 30 | # MD010/no-hard-tabs - Hard tabs 31 | MD010: false 32 | 33 | # MD011/no-reversed-links - Reversed link syntax 34 | MD011: true 35 | 36 | # MD012/no-multiple-blanks - Multiple consecutive blank lines 37 | MD012: false 38 | 39 | # MD013/line-length - Line length 40 | # Changed from default so we can allow the paragraphs to be a single line 41 | MD013: false 42 | 43 | # MD014/commands-show-output - Dollar signs used before commands without showing output 44 | MD014: false 45 | 46 | # MD018/no-missing-space-atx - No space after hash on atx style heading 47 | MD018: true 48 | 49 | # MD019/no-multiple-space-atx - Multiple spaces after hash on atx style heading 50 | MD019: true 51 | 52 | # MD020/no-missing-space-closed-atx - No space inside hashes on closed atx style heading 53 | MD020: true 54 | 55 | # MD021/no-multiple-space-closed-atx - Multiple spaces inside hashes on closed atx style heading 56 | MD021: true 57 | 58 | # MD022/blanks-around-headings/blanks-around-headers - Headings should be surrounded by blank lines 59 | MD022: true 60 | 61 | # MD023/heading-start-left/header-start-left - Headings must start at the beginning of the line 62 | MD023: true 63 | 64 | # MD024/no-duplicate-heading/no-duplicate-header - Multiple headings with the same content 65 | MD024: 66 | # Only check sibling headings 67 | siblings_only: true 68 | 69 | # MD025/single-title/single-h1 - Multiple top-level headings in the same document 70 | MD025: 71 | # Heading level 72 | level: 1 73 | # RegExp for matching title in front matter 74 | front_matter_title: "^\\s*title\\s*[:=]" 75 | 76 | # MD026/no-trailing-punctuation - Trailing punctuation in heading 77 | MD026: false 78 | 79 | # MD027/no-multiple-space-blockquote - Multiple spaces after blockquote symbol 80 | MD027: false 81 | 82 | # MD028/no-blanks-blockquote - Blank line inside blockquote 83 | MD028: true 84 | 85 | # MD029/ol-prefix - Ordered list item prefix 86 | MD029: false 87 | 88 | # MD030/list-marker-space - Spaces after list markers 89 | MD030: 90 | # Spaces for single-line unordered list items 91 | ul_single: 1 92 | # Spaces for single-line ordered list items 93 | ol_single: 1 94 | # Spaces for multi-line unordered list items 95 | ul_multi: 1 96 | # Spaces for multi-line ordered list items 97 | ol_multi: 1 98 | 99 | # MD031/blanks-around-fences - Fenced code blocks should be surrounded by blank lines 100 | MD031: 101 | # Include list items 102 | list_items: true 103 | 104 | # MD032/blanks-around-lists - Lists should be surrounded by blank lines 105 | MD032: true 106 | 107 | # MD033/no-inline-html - Inline HTML 108 | MD033: false 109 | 110 | # MD034/no-bare-urls - Bare URL used 111 | MD034: false 112 | 113 | # MD035/hr-style - Horizontal rule style 114 | MD035: 115 | # Horizontal rule style 116 | style: "consistent" 117 | 118 | # MD036/no-emphasis-as-heading/no-emphasis-as-header - Emphasis used instead of a heading 119 | MD036: false 120 | 121 | # MD037/no-space-in-emphasis - Spaces inside emphasis markers 122 | MD037: false 123 | 124 | # MD038/no-space-in-code - Spaces inside code span elements 125 | MD038: true 126 | 127 | # MD039/no-space-in-links - Spaces inside link text 128 | MD039: false 129 | 130 | # MD040/fenced-code-language - Fenced code blocks should have a language specified 131 | MD040: false 132 | 133 | # MD041/first-line-heading/first-line-h1 - First line in a file should be a top-level heading 134 | # NOTE: Since this uses Jekyll, this setting only applies to freestanding markdown files, such as those in the assets folder 135 | MD041: 136 | # Heading level 137 | level: 1 138 | # RegExp for matching title in front matter 139 | front_matter_title: "^\\s*title\\s*[:=]" 140 | 141 | # MD042/no-empty-links - No empty links 142 | MD042: true 143 | 144 | # MD043/required-headings/required-headers - Required heading structure 145 | # Handled by EIP Walidator 146 | MD043: false 147 | 148 | # MD044/proper-names - Proper names should have the correct capitalization 149 | MD044: 150 | # List of proper names 151 | names: [] 152 | # Include code blocks 153 | code_blocks: true 154 | # Include HTML elements 155 | html_elements: true 156 | 157 | # MD045/no-alt-text - Images should have alternate text (alt text) 158 | MD045: false 159 | 160 | # MD046/code-block-style - Code block style 161 | MD046: 162 | # Block style 163 | style: "consistent" 164 | 165 | # MD047/single-trailing-newline - Files should end with a single newline character 166 | MD047: true 167 | 168 | # MD048/code-fence-style - Code fence style 169 | MD048: 170 | # Code fence style 171 | style: "consistent" 172 | 173 | # MD049/emphasis-style - Emphasis style should be consistent 174 | MD049: 175 | # Emphasis style should be consistent 176 | style: "consistent" 177 | 178 | # MD050/strong-style - Strong style should be consistent 179 | MD050: 180 | # Strong style should be consistent 181 | style: "consistent" 182 | 183 | # MD051/link-fragments - Link fragments should be valid 184 | MD051: true 185 | 186 | # MD052/reference-links-images - Reference links and images should use a label that is defined 187 | MD052: true 188 | 189 | # MD053/link-image-reference-definitions - Link and image reference definitions should be needed 190 | MD053: true 191 | -------------------------------------------------------------------------------- /config/mlc_config.json: -------------------------------------------------------------------------------- 1 | { 2 | "ignorePatterns": [ 3 | "[`]*csl-json" 4 | ], 5 | "replacementPatterns": [ 6 | { 7 | "pattern": "^/", 8 | "replacement": "/github/workspace/" 9 | } 10 | ], 11 | "aliveStatusCodes": [ 12 | 200, 13 | 429 14 | ] 15 | } 16 | -------------------------------------------------------------------------------- /website/.gitignore: -------------------------------------------------------------------------------- 1 | # Dependencies 2 | /node_modules 3 | 4 | # Production 5 | /build 6 | 7 | # Generated files 8 | .docusaurus 9 | .cache-loader 10 | 11 | # Misc 12 | .DS_Store 13 | .env.local 14 | .env.development.local 15 | .env.test.local 16 | .env.production.local 17 | 18 | npm-debug.log* 19 | yarn-debug.log* 20 | yarn-error.log* 21 | -------------------------------------------------------------------------------- /website/README.md: -------------------------------------------------------------------------------- 1 | # Website 2 | 3 | This website is built using [Docusaurus 2](https://docusaurus.io/), a modern static website generator. 4 | 5 | ### Installation 6 | 7 | ``` 8 | $ yarn 9 | ``` 10 | 11 | ### Local Development 12 | 13 | ``` 14 | $ yarn start 15 | ``` 16 | 17 | This command starts a local development server and opens up a browser window. Most changes are reflected live without having to restart the server. 18 | 19 | ### Build 20 | 21 | ``` 22 | $ yarn build 23 | ``` 24 | 25 | This command generates static content into the `build` directory and can be served using any static contents hosting service. 26 | 27 | ### Deployment 28 | 29 | Using SSH: 30 | 31 | ``` 32 | $ USE_SSH=true yarn deploy 33 | ``` 34 | 35 | Not using SSH: 36 | 37 | ``` 38 | $ GIT_USER= yarn deploy 39 | ``` 40 | 41 | If you are using GitHub pages for hosting, this command is a convenient way to build the website and push to the `gh-pages` branch. 42 | -------------------------------------------------------------------------------- /website/babel.config.js: -------------------------------------------------------------------------------- 1 | module.exports = { 2 | presets: [require.resolve('@docusaurus/core/lib/babel/preset')], 3 | }; 4 | -------------------------------------------------------------------------------- /website/docusaurus.config.js: -------------------------------------------------------------------------------- 1 | // @ts-check 2 | // Note: type annotations allow type checking and IDEs autocompletion 3 | 4 | const lightCodeTheme = require("prism-react-renderer/themes/github"); 5 | const darkCodeTheme = require("prism-react-renderer/themes/dracula"); 6 | 7 | /** @type {import('@docusaurus/types').Config} */ 8 | const config = { 9 | title: "Cosmos Improvement Proposals", 10 | tagline: "Cosmos Improvement Proposals", 11 | favicon: "img/favicon.ico", 12 | 13 | // Set the production url of your site here 14 | url: "https://your-docusaurus-test-site.com", 15 | // Set the // pathname under which your site is served 16 | // For GitHub pages deployment, it is often '//' 17 | baseUrl: "/", 18 | 19 | // GitHub pages deployment config. 20 | // If you aren't using GitHub pages, you don't need these. 21 | organizationName: "Cosmos", // Usually your GitHub org/user name. 22 | projectName: "CIPs", // Usually your repo name. 23 | 24 | onBrokenLinks: "throw", 25 | onBrokenMarkdownLinks: "warn", 26 | 27 | // Even if you don't use internalization, you can use this field to set useful 28 | // metadata like html lang. For example, if your site is Chinese, you may want 29 | // to replace "en" with "zh-Hans". 30 | i18n: { 31 | defaultLocale: "en", 32 | locales: ["en"], 33 | }, 34 | 35 | presets: [ 36 | [ 37 | "classic", 38 | /** @type {import('@docusaurus/preset-classic').Options} */ 39 | ({ 40 | docs: { 41 | sidebarPath: require.resolve("./sidebars.js"), 42 | editUrl: "https://github.com/cosmos/CIPs/edit/master/website", 43 | showLastUpdateAuthor: true, 44 | showLastUpdateTime: true, 45 | path: "../cips", 46 | routeBasePath: "/", 47 | }, 48 | theme: { 49 | customCss: require.resolve("./src/css/custom.css"), 50 | }, 51 | }), 52 | ], 53 | ], 54 | themeConfig: 55 | /** @type {import('@docusaurus/preset-classic').ThemeConfig} */ 56 | ({ 57 | // image: "img/banner.jpg", 58 | docs: { 59 | sidebar: { 60 | autoCollapseCategories: true, 61 | }, 62 | }, 63 | navbar: { 64 | title: "Cosmos CIPs", 65 | hideOnScroll: false, 66 | logo: { 67 | alt: "Cosmos CIPs Logo", 68 | src: "img/logo-sdk.svg", 69 | href: "/", 70 | target: "_self", 71 | }, 72 | items: [], 73 | }, 74 | footer: { 75 | links: [ 76 | { 77 | items: [ 78 | { 79 | html: `Cosmos Logo`, 80 | }, 81 | ], 82 | }, 83 | { 84 | title: "Documentation", 85 | items: [ 86 | { 87 | label: "Cosmos SDK", 88 | href: "https://docs.cosmos.network", 89 | }, 90 | { 91 | label: "Cosmos Hub", 92 | href: "https://hub.cosmos.network", 93 | }, 94 | { 95 | label: "CometBFT", 96 | href: "https://docs.cometbft.com", 97 | }, 98 | { 99 | label: "IBC Go", 100 | href: "https://ibc.cosmos.network", 101 | }, 102 | ], 103 | }, 104 | { 105 | title: "Community", 106 | items: [ 107 | { 108 | label: "Blog", 109 | href: "https://blog.cosmos.network", 110 | }, 111 | { 112 | label: "Forum", 113 | href: "https://forum.cosmos.network", 114 | }, 115 | { 116 | label: "Discord", 117 | href: "https://discord.gg/cosmosnetwork", 118 | }, 119 | { 120 | label: "Reddit", 121 | href: "https://reddit.com/r/cosmosnetwork", 122 | }, 123 | ], 124 | }, 125 | { 126 | title: "Social", 127 | items: [ 128 | { 129 | label: "Discord", 130 | href: "https://discord.gg/cosmosnetwork", 131 | }, 132 | { 133 | label: "Twitter", 134 | href: "https://twitter.com/cosmos", 135 | }, 136 | { 137 | label: "Youtube", 138 | href: "https://www.youtube.com/c/CosmosProject", 139 | }, 140 | { 141 | label: "Telegram", 142 | href: "https://t.me/cosmosproject", 143 | }, 144 | ], 145 | }, 146 | ], 147 | // copyright: `

The development of the Cosmos SDK is led primarily by Interchain Core Teams. Funding for this development comes primarily from the Interchain Foundation, a Swiss non-profit.

`, 148 | }, 149 | // prism: { 150 | // theme: lightCodeTheme, 151 | // darkTheme: darkCodeTheme, 152 | // additionalLanguages: ["protobuf", "go-module"], // https://prismjs.com/#supported-languages 153 | // }, 154 | // algolia: { 155 | // appId: "QLS2QSP47E", 156 | // apiKey: "4d9feeb481e3cfef8f91bbc63e090042", 157 | // indexName: "cosmos_network", 158 | // contextualSearch: false, 159 | // }, 160 | }), 161 | plugins: [ 162 | // async function myPlugin(context, options) { 163 | // return { 164 | // name: "docusaurus-tailwindcss", 165 | // configurePostCss(postcssOptions) { 166 | // postcssOptions.plugins.push(require("postcss-import")); 167 | // postcssOptions.plugins.push(require("tailwindcss/nesting")); 168 | // postcssOptions.plugins.push(require("tailwindcss")); 169 | // postcssOptions.plugins.push(require("autoprefixer")); 170 | // return postcssOptions; 171 | // }, 172 | // }; 173 | // }, 174 | [ 175 | "@docusaurus/plugin-google-analytics", 176 | { 177 | trackingID: "UA-51029217-2", 178 | anonymizeIP: true, 179 | }, 180 | ], 181 | ], 182 | }; 183 | 184 | module.exports = config; 185 | -------------------------------------------------------------------------------- /website/package.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "website", 3 | "version": "0.0.0", 4 | "private": true, 5 | "scripts": { 6 | "docusaurus": "docusaurus", 7 | "start": "docusaurus start", 8 | "build": "docusaurus build", 9 | "swizzle": "docusaurus swizzle", 10 | "deploy": "docusaurus deploy", 11 | "clear": "docusaurus clear", 12 | "serve": "docusaurus serve", 13 | "write-translations": "docusaurus write-translations", 14 | "write-heading-ids": "docusaurus write-heading-ids", 15 | "typecheck": "tsc" 16 | }, 17 | "dependencies": { 18 | "@docusaurus/core": "2.4.1", 19 | "@docusaurus/preset-classic": "2.4.1", 20 | "@mdx-js/react": "^1.6.22", 21 | "clsx": "^1.2.1", 22 | "prism-react-renderer": "^1.3.5", 23 | "react": "^17.0.2", 24 | "react-dom": "^17.0.2" 25 | }, 26 | "devDependencies": { 27 | "@docusaurus/module-type-aliases": "2.4.1", 28 | "@tsconfig/docusaurus": "^1.0.5", 29 | "typescript": "^4.7.4" 30 | }, 31 | "browserslist": { 32 | "production": [ 33 | ">0.5%", 34 | "not dead", 35 | "not op_mini all" 36 | ], 37 | "development": [ 38 | "last 1 chrome version", 39 | "last 1 firefox version", 40 | "last 1 safari version" 41 | ] 42 | }, 43 | "engines": { 44 | "node": ">=16.14" 45 | } 46 | } 47 | -------------------------------------------------------------------------------- /website/sidebars.js: -------------------------------------------------------------------------------- 1 | /** 2 | * Creating a sidebar enables you to: 3 | - create an ordered group of docs 4 | - render a sidebar for each doc of that group 5 | - provide next/previous navigation 6 | 7 | The sidebars can be generated from the filesystem, or explicitly defined here. 8 | 9 | Create as many sidebars as you want. 10 | */ 11 | 12 | // @ts-check 13 | 14 | /** @type {import('@docusaurus/plugin-content-docs').SidebarsConfig} */ 15 | const sidebars = { 16 | // By default, Docusaurus generates a sidebar from the docs folder structure 17 | tutorialSidebar: [{type: 'autogenerated', dirName: '.'}], 18 | 19 | // But you can create a sidebar manually 20 | /* 21 | tutorialSidebar: [ 22 | 'intro', 23 | 'hello', 24 | { 25 | type: 'category', 26 | label: 'Tutorial', 27 | items: ['tutorial-basics/create-a-document'], 28 | }, 29 | ], 30 | */ 31 | }; 32 | 33 | module.exports = sidebars; 34 | -------------------------------------------------------------------------------- /website/src/css/custom.css: -------------------------------------------------------------------------------- 1 | /** 2 | * Any CSS included here will be global. The classic template 3 | * bundles Infima by default. Infima is a CSS framework designed to 4 | * work well for content-centric websites. 5 | */ 6 | 7 | /* You can override the default Infima variables here. */ 8 | :root { 9 | --ifm-color-primary: #2e8555; 10 | --ifm-color-primary-dark: #29784c; 11 | --ifm-color-primary-darker: #277148; 12 | --ifm-color-primary-darkest: #205d3b; 13 | --ifm-color-primary-light: #33925d; 14 | --ifm-color-primary-lighter: #359962; 15 | --ifm-color-primary-lightest: #3cad6e; 16 | --ifm-code-font-size: 95%; 17 | --docusaurus-highlighted-code-line-bg: rgba(0, 0, 0, 0.1); 18 | } 19 | 20 | /* For readability concerns, you should choose a lighter palette in dark mode. */ 21 | [data-theme='dark'] { 22 | --ifm-color-primary: #25c2a0; 23 | --ifm-color-primary-dark: #21af90; 24 | --ifm-color-primary-darker: #1fa588; 25 | --ifm-color-primary-darkest: #1a8870; 26 | --ifm-color-primary-light: #29d5b0; 27 | --ifm-color-primary-lighter: #32d8b4; 28 | --ifm-color-primary-lightest: #4fddbf; 29 | --docusaurus-highlighted-code-line-bg: rgba(0, 0, 0, 0.3); 30 | } 31 | -------------------------------------------------------------------------------- /website/src/pages/index.module.css: -------------------------------------------------------------------------------- 1 | /** 2 | * CSS files with the .module.css suffix will be treated as CSS modules 3 | * and scoped locally. 4 | */ 5 | 6 | .heroBanner { 7 | padding: 4rem 0; 8 | text-align: center; 9 | position: relative; 10 | overflow: hidden; 11 | } 12 | 13 | @media screen and (max-width: 996px) { 14 | .heroBanner { 15 | padding: 2rem; 16 | } 17 | } 18 | 19 | .buttons { 20 | display: flex; 21 | align-items: center; 22 | justify-content: center; 23 | } 24 | -------------------------------------------------------------------------------- /website/static/.nojekyll: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cosmos/cips/5f06ca8de8db1d0ca4ed983df7351879d21e3aaa/website/static/.nojekyll -------------------------------------------------------------------------------- /website/static/img/CIP-process.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cosmos/cips/5f06ca8de8db1d0ca4ed983df7351879d21e3aaa/website/static/img/CIP-process.png -------------------------------------------------------------------------------- /website/static/img/favicon.ico: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cosmos/cips/5f06ca8de8db1d0ca4ed983df7351879d21e3aaa/website/static/img/favicon.ico -------------------------------------------------------------------------------- /website/tsconfig.json: -------------------------------------------------------------------------------- 1 | { 2 | // This file is not used in compilation. It is here just for a nice editor experience. 3 | "extends": "@tsconfig/docusaurus/tsconfig.json", 4 | "compilerOptions": { 5 | "baseUrl": "." 6 | } 7 | } 8 | --------------------------------------------------------------------------------