Get Involved

Contribution Guidelines

Thanks for your interest in contributing to IBC! We welcome contributions to IBC's open-source repos and to our security program.

Contributing to IBC's Open-Source Repositories

Contributing to the IBC repositories can include opening an issue, contributing to fixing/closing issues, or proposing changes to the protocol. To ensure a smooth workflow for all contributors, we request contributors to follow the below workflows.

Feel free to open an issue to raise a question, explain a concern, or discuss a possible future feature, protocol change, or standard.

Make sure first that the issue does not already exist.
Participate in thoughtful discussion on the issue.

If you would like to contribute in fixing / closing an issue:

If the issue is a proposal, ensure that the proposal has been accepted.
Ensure that nobody else has already begun working on this issue. If they have, make sure to contact them to collaborate.
If nobody has been assigned for the issue and you would like to work on it, make a comment on the issue to inform the community of your intentions to begin work.
Follow standard Github best practices: fork the repo, branch from the HEAD of master, make some commits, and submit a PR to master.
Be sure to submit the PR early in Draft mode, even if it's incomplete as this indicates to the community you're working on something and allows them to provide comments at an early stage.
When the PR is complete it can be marked Ready for Review.

If you would like to propose a new standard for inclusion in the IBC standards, please take a look at PROCESS.md for a detailed description of the standardisation process.

To start a new standardisation document, copy the template and open a PR.

Pull Request Procedures

To accommodate the review process we suggest that PRs are categorically broken up. Each PR should address only a single issue and a single standard. The PR name should be prefixed by the standard number, e.g., ICS4: Some improvements should contain only changes to ICS 4. If fixing an issue requires changes to multiple standards, create multiple PRs and mention the inter-dependencies.

Process for reviewing PRs

All PRs require an approval from at least two members of the standardisation committee before merge. The PRs submitted by one of the members of the standardisation committee require an approval from only one other member before merge. When reviewing PRs please use the following review explanations:

Approval through the GH UI means that you understand all the changes proposed in the PR. In addition:
- You must also think through anything which ought to be included but is not.
- You must think through any potential security issues or incentive-compatibility flaws introduced by the changes.
- The changes must be consistent with the other IBC standards, especially the core IBC standards.
- The modified standard must be consistent with the description from ICS 1.
If you are only making "surface level" reviews, submit any notes as Comments without adding a review.

PR Targeting

Ensure that you base and target your PR on the master branch.

Development Procedure

The latest state of development is on master.
Create a development branch either on github.com/cosmos/ibc or your fork (using git remote add fork).
- To ensure a clear ownership of branches on the ibc repo, branches must be named with the convention {moniker}/{issue#}-branch-name
Before submitting a pull request, begin git rebase on top of master. Since standards cannot be compiled, make sure that the changes in your PR remains consistent with the new commits on the master branch.

Pull Merge Procedure

Ensure all github requirements pass.
Squash and merge pull request.

Reporting Bugs and Security Vulnerabilities

If you believe you have found a security vulnerability in IBC, you can report it to our primary vulnerability disclosure channel, the Cosmos HackerOne Bug Bounty program.

If you prefer to report an issue via email, you may send a bug report to security@interchain.io with the issue details, reproduction, impact, and other information. Please submit only one unique email thread per vulnerability. Any issues reported via email are ineligible for bounty rewards.

Artifacts from an email report are saved at the time the email is triaged. Please note: our team is not able to monitor dynamic content (e.g. a Google Docs link that is edited after receipt) throughout the lifecycle of a report. If you would like to share additional information or modify previous information, please include it in an additional reply as an additional attachment.

Please DO NOT file a public issue in a repository to report a security vulnerability.

Coordinated Vulnerability Disclosure Policy and Safe Harbor

For the most up-to-date version of the policies that govern vulnerability disclosure, please consult the HackerOne program page.

The policy hosted on HackerOne is the official Coordinated Vulnerability Disclosure policy and Safe Harbor for the Interchain Stack, and the teams and infrastructure it supports, and it supersedes previous security policies that have been used in the past by individual teams and projects with targets in scope of the program.