Code Review Policy

For: Xcavate Protocol & realXmarket App Version: 1.0 Owner: Engineering Team Leads (Protocol & App) Last Updated: 16.08.2025


1. Purpose

The purpose of this Code Review Policy is to:

  • Ensure security, correctness, and reliability of the Xcavate Protocol (on-chain smart contracts, cryptography, consensus-related code).

  • Maintain performance, scalability, and user experience in the realXmarket App.

  • Foster knowledge sharing, consistency, and high-quality engineering practices across teams.


2. Scope

This policy applies to all code contributions, including but not limited to:

  • Xcavate Protocol: Smart contracts, node infrastructure, cryptographic primitives, integrations with L1/L2 blockchains.

  • realXmarket App: Backend services, APIs, frontend UI, mobile apps, and DevOps/infra code.


3. Review Process

3.1 Pull Request (PR) Requirements

  • Every PR must be reviewed before merge (no direct commits to main or release branches).

  • Minimum reviewers:

    • Protocol: 2 reviewers (at least 1 senior/lead with protocol expertise).

    • App: 1 reviewer (2 required for major features or infra/security changes).

  • Automated checks must pass (CI/CD, linting, tests, static analysis, gas/performance benchmarks where applicable).

3.2 Review Checklist

Reviewers must verify:

For Xcavate Protocol

  • Security: No vulnerabilities (reentrancy, overflow, unchecked external calls).

  • Correctness: Logic matches spec/whitepaper, edge cases handled.

  • Gas Efficiency: No unnecessary computations or storage writes.

  • Upgradeability & Governance: If applicable, follows protocol standards.

  • Testing: Unit + property-based tests included with good coverage.

For realXmarket App

  • Functionality: Code works as intended and meets acceptance criteria.

  • Performance: APIs, queries, and rendering are optimized.

  • Security: Input validation, authentication, authorization enforced.

  • Readability & Maintainability: Clear code, proper abstractions, minimal tech debt.

  • User Impact: UI/UX logic changes validated against product design.

  • Testing: Unit, integration, and regression tests included.


4. Review Standards

  • Style & Consistency: Follow project-specific style guides (Solidity, TypeScript/Java/Kotlin/Swift).

  • Documentation: Public methods, APIs, and protocol logic must be documented.

  • Commit Hygiene: PRs should be atomic, with meaningful commit messages.

  • Size: Prefer small PRs (<400 lines changed) to ease review. Large PRs must be broken down unless unavoidable.


5. Roles & Responsibilities

  • Author: Writes code, ensures tests/docs are updated, requests review.

  • Reviewer(s): Reviews code against checklist, requests changes if necessary, approves once satisfied.

  • Maintainers/Leads: Have final authority to merge, ensure critical reviews (esp. security-related) are completed.


6. Special Protocol Rules (Xcavate)

  • Formal Verification (if applicable): Critical contracts must undergo formal verification before mainnet deployment.

  • External Audits: Smart contracts require at least one external audit before release.

  • Testnet Deployments: All new protocol features must run on testnet with community testing before mainnet upgrade.


7. Special App Rules (realXmarket)

  • Feature Flags: Major new features must ship behind feature flags.

  • Backward Compatibility: APIs and mobile app updates must maintain compatibility with existing users.

  • Error Handling: All network, blockchain, and API errors must be gracefully handled and surfaced to users.


8. Tools & Automation

  • CI/CD: Automated builds, tests, linting, type-checking.

  • Static Analysis: Slither/MythX for smart contracts; SonarQube/ESLint/Detekt for app code.

  • Code Coverage: Minimum 80% for critical modules, 60% overall.

  • Branch Protection: Enforced via GitHub/GitLab rules.


9. Exceptions

  • Hotfixes for production incidents may bypass full review but require post-merge review within 24 hours.

  • Experimental branches may skip full compliance but must not merge into main without review.


10. Continuous Improvement

  • This policy will be reviewed quarterly by engineering leadership.

  • Feedback from developers, QA, and security audits will be incorporated into revisions.

Last updated