← Inferno

Contributing to Inferno Protocol

Open-source contributions welcome — from bug reports to code contributions.

How to Contribute

Bug Reports

Check the existing issues to avoid duplicates.
Open a new issue with a clear title and detailed description.
Include steps to reproduce, expected behavior, and actual behavior.
Attach relevant logs, screenshots, or transaction hashes if applicable.

Feature Requests

Open an issue with the feature-request label.
Describe the problem you are trying to solve, not just the solution.
Explain how the feature fits into the existing architecture (see Smart Contracts and Integration Guide).

Code Contributions

Fork the repository and create a feature branch from main.
Write your code following the standards described below.
Add or update tests to cover your changes.
Run the full test suite before submitting:
```
npx hardhat test
```
Open a Pull Request against main with a clear description of what changed and why.

Code Standards

Solidity

pragma solidity ^0.8.20; — minimum compiler version.
Use OpenZeppelin v5 contracts for all base functionality.
NatSpec comments (@notice, @param, @return) on all public/external functions.
Slither static analysis must pass with 0 High / 0 Critical findings.
Use ReentrancyGuard for all contracts that handle token transfers.
Follow Checks-Effects-Interactions (CEI) pattern.
Emit events for all state changes.

TypeScript / JavaScript

Strict mode enabled — no implicit any.
Use Jest or Hardhat Chai matchers for all tests.
ethers.js v5 syntax with 9 decimals: ethers.utils.parseUnits("1000", 9).
All app code lives under apps/ with its own package.json.

Git Conventions

Commit Message Prefixes

Prefix	Usage
`feat:`	New feature or functionality
`fix:`	Bug fix
`docs:`	Documentation changes only
`test:`	Adding or updating tests
`ops:`	CI/CD, deployment, infrastructure
`refactor:`	Code restructuring without behavior change

Forbidden Actions

NEVER force-push to main. No git push --force, no git rebase on pushed commits, no git commit --amend on already-pushed commits. History is immutable once pushed.

Smart Contract Changes

Modifying deployed contracts requires special care. Follow these steps:

Deploy a new version — never modify deployed bytecode. Deployed contracts are immutable.
Governance proposal — any parameter change on existing contracts must go through the 48h Timelock governance process (see Governance).
Full test coverage — new contracts must have comprehensive unit tests. Target: 95%+ statement coverage.
Slither clean — run slither . and resolve all High/Critical findings before submission.
Update documentation — update README.md, docs/DOCS.md, and relevant wiki pages to reflect the new contract.

Review Process

Pull Requests are reviewed within 48 hours.
Security-related changes may require additional review time.
All CI checks must pass before merge (tests, linting, Slither).
Mainnet-affecting changes require two independent reviews.
Reviewers check for correctness, test coverage, documentation updates, and adherence to code standards.

Code of Conduct

Be respectful and constructive in all interactions.
Focus on technical merit — no personal attacks or dismissive language.
Credit contributors appropriately in commit messages and changelogs.
Report security vulnerabilities privately via the Security page — never in public issues.

Links

Contribute on GitHub