Contributing

Thank you for your interest in contributing. This document covers the license terms that apply to every contribution, how the contribution process relates to on-chain DAO governance, the practical workflow for opening a pull request, and the security disclosure policy.

OhShii Launcher is a governed protocol, not a maintainer-led project. Read the Governance precedence section before contributing — it explains the relationship between this repository and the on-chain DAO and is what makes everything that follows make sense.

License of contributions

OhShii Launcher is licensed under the GNU Affero General Public License v3.0 or later (AGPL-3.0-or-later). See the full AGPL-3.0 license text; the same text is bundled as the LICENSE file at the repository root.

By submitting a contribution to this repository — whether as a pull request, an issue containing source code, a patch sent by email, or any other channel — you agree to the following:

You hold copyright on your contribution and grant it to the public under the terms of AGPL-3.0-or-later. Each individual contributor retains copyright on their own contributions; OhShii does not require copyright reassignment.
You have the legal right to grant that license. If your contribution was developed during paid work for another entity (an employer, a client, a consultancy), you have obtained whatever permission is necessary from that entity before submitting the contribution.
Your contribution is your original work or you have correctly attributed any third-party material it contains. Third-party material incorporated into a contribution must be license-compatible with AGPL-3.0-or-later.
Network-use clause acceptance: AGPL § 13 requires that anyone running a modified version of OhShii Launcher as a network-accessible service (which a canister deployed on the Internet Computer is) offer the corresponding source to users of that service. Your contribution inherits this obligation.

These commitments are made under the Developer Certificate of Origin 1.1 (https://developercertificate.org/). We do not require a separate signed CLA. Sign your commits with git commit -s to attest to the DCO on every contribution.

Governance precedence

OhShii Launcher is a protocol governed by an on-chain DAO. This repository hosts the reference implementation; the canonical version of the protocol is the one deployed to the Internet Computer and controlled through DAO proposals.

The two layers and their authorities:

Layer	Surface	Authority
Repository (off-chain, GitHub)	Source code, pull requests, issues, code review	Maintainers — curate, advisory
Protocol (on-chain, IC)	Deployed canister WASM, governance config, treasury actions	DAO governance — decide, binding

What this means in practice:

Maintainers curate; the DAO decides. A maintainer’s decision to merge or decline a pull request is a quality-and-safety filter for the reference implementation; it is not the final word on what the protocol does on-chain.
The DAO can adopt code that has not been merged here — by approving a canister-upgrade proposal whose WASM hash comes from a fork or from a branch outside this repository. The DAO can equally reject code that has been merged here by refusing to approve its deployment.
Security reviews, audits, and maintainer feedback are advisory. They produce information that helps DAO voters reach informed decisions, but the binding authority on what runs on-chain is the OHSHII governance vote that approves each canister upgrade.
The repository is not the source of truth for the live protocol. The source of truth is the WASM hash currently deployed at each canister, plus the on-chain governance state. This repository is the human-readable reference for that WASM, kept in sync by maintainers but not authoritative over the DAO.

A practical consequence for contributors: when a PR is declined under the standard review process, that is not a final rejection of the change. The author can still pursue it through DAO governance — by maintaining a fork, building a deterministic WASM, and submitting a canister-upgrade proposal whose hash matches their build. If the DAO approves, the change ships, regardless of whether it was merged here.

Future re-licensing

If at some point the OhShii community decides to re-license the project (for example, to consolidate copyright in a Foundation or DAO Treasury, or to adopt a different license), that change requires the consent of all copyright holders of code present at the time of the change, OR a re-write of the affected files. AGPL-3.0-or-later does not include a unilateral re-licensing mechanism. Contributors who do not wish to grant that future consent should make their position clear in their contribution PR.

Vendored third-party code

The directory src/external_crates/ contains copies of upstream open-source crates that are NOT under AGPL-3.0. The LICENSE inside each vendored directory governs the code in that directory. Maintainers strongly prefer that contributions not modify files inside vendored crates: if a fix is genuinely needed there, report the issue upstream and bump our pinned revision once the upstream maintainers merge the fix. See src/external_crates/<crate>/VENDORED.md for the upgrade procedure.

(Like every other guideline in this document, this is a maintainer preference for the standard review process; the DAO retains authority to adopt any deviation through governance.)

Contribution workflow (standard review)

The steps below describe the recommended workflow for getting a change merged through the maintainer-curation layer. They are not the only way to get a change deployed — see Governance precedence for how the on-chain DAO can adopt changes outside this process.

Discuss before large changes. For non-trivial changes — anything that touches stable storage, governance proposal types, the verification gate, the cycle accounting, or external canister integrations — open an issue first describing the problem and the proposed approach. This avoids wasted work on PRs that need a different design.
Branch from master. Use a descriptive branch name. Keep commits focused: one logical change per commit. Sign every commit with git commit -s.
Run the project’s checks before pushing:
- Backend: cargo check --workspace --target wasm32-unknown-unknown
- Frontend: npx tsc --noEmit -p src/frontend
- Candid: if you changed any .did, run dfx generate --network ic and commit the regenerated declarations.
Open a pull request against master with a clear description: what the change does, why it’s needed, what was tested, and any migration / operator implications. Reference any issue numbers.
Respond to review feedback. PRs may sit a little while waiting for review — these are security-sensitive canisters and reviewers take their time. Review feedback is advisory: it identifies risks and suggests improvements; ultimate adoption of any change still rests with the DAO at deployment time.

Welcome contributions

The standard review process is most likely to merge:

Bug fixes (with a test or reproduction in the PR description).
Performance improvements (with measurements showing the before/after).
Documentation fixes and clarifications.
Frontend UX improvements that match the existing design language.
New features — discussed in an issue first.

What is unlikely to be accepted through standard review

The following kinds of change are typically not merged through the standard maintainer-curation process without substantial additional discussion:

Code that touches financial flows, vote gating, or stable-storage layout without a complete description of the security implications and a self-audit against the IC stable-storage / async-await / lock-audit patterns (R1–R7).
Style-only refactors that touch large surface areas without a functional reason.
Changes that introduce a closed-source or non-AGPL-compatible dependency.
Changes to vendored third-party code (see Vendored third-party code).

These guidelines describe the maintainer-curation process for this repository. They do not restrict DAO governance. Any of the changes listed above may still be adopted by the OhShii DAO through an on-chain canister-upgrade proposal, independent of the standard review outcome. The point of the standard review is to filter for code quality and safety before something reaches a DAO vote — not to override the DAO’s final authority.

Security disclosure

Please do not file public issues for security vulnerabilities. If you find a security issue affecting OhShii Launcher (canister-side exploits, fund-loss vectors, governance bypass, sybil-gate bypass, etc.):

Send a private notification to the maintainers via the contact channel published on https://github.com/ohshii-labs.
Include enough detail to reproduce the issue and an assessment of the impact.
Allow a reasonable disclosure window (typically 90 days for non-actively-exploited issues, shorter if user funds are at risk) before any public disclosure.

Responsible disclosures are acknowledged in release notes (with the reporter’s permission).

Note on the role of audits and security review. Security audits and maintainer-led security reviews on this repository are advisory — they produce information that helps DAO voters reach informed decisions about which canister-upgrade proposals to approve. Final responsibility for what runs on-chain lies with the OHSHII voters who approve the corresponding deployment proposal, not with the maintainers or auditors who reviewed the code. A favorable audit is not a guarantee of safety; an unfavorable one is not a permanent block. Both are inputs to the on-chain decision.

Code of conduct

Contributors are expected to behave professionally and respectfully. Personal attacks, harassment, or discriminatory behavior — in PRs, issues, or any project channel — will result in a contribution ban from the standard review process. The DAO can choose its own policies on governance forums independently.

Questions

For any question that does not fit the above categories, open a discussion on https://github.com/ohshii-labs or contact the maintainers through the channels listed there.