WAIT — Single-maintainer risk — review before adopting

• Last commit today
• 3 active contributors
• AGPL-3.0 licensed
• CI configured
• Tests present
• ⚠ Small team — 3 contributors active in recent commits
• ⚠ Single-maintainer risk — top contributor 93% of recent commits
• ⚠ AGPL-3.0 is copyleft — check downstream compatibility

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests}

Bisq is a decentralized peer-to-peer bitcoin exchange that allows users to trade BTC for fiat currencies and altcoins without a central intermediary. It uses multi-signature escrow for transaction settlement, distributed order books, and human arbitration for dispute resolution—enabling non-custodial trading with privacy-first networking. Monorepo structure: core application modules under the root directory (bisq.application plugin via gradle), separate apitest/ subproject for integration testing with own build.gradle, shell/Python scripts for simulation and deployment (apitest/scripts/). Build system heavily customized via bisq.gradle plugin; resources managed through Gradle sourceSets with explicit dao-setup downloads.

Cryptocurrency traders who want to exchange bitcoin and altcoins for fiat without KYC, custodial risk, or third-party intermediaries; Bitcoin developers extending P2P trading protocols; and open-source contributors building decentralized financial infrastructure.

Bisq is production-ready and actively maintained. The codebase is substantial (~14.7MB Java), has established CI/CD workflows (.github/workflows/build.yml), comprehensive testing infrastructure (apitest/ subproject with gradle-based test harness), and clear governance (CODEOWNERS, CONTRIBUTING.md). Regular dependency updates via dependabot.yml indicate ongoing maintenance.

This is a financial application handling real bitcoin transactions, so correctness is critical. The monolithic Java codebase (14.7MB) requires careful review of changes. No visible package lock file patterns suggest potential dependency drift. The apitest/ suite is substantial but requires DAO setup files from external sources (dao-setup.gradle downloads from GitHub), creating external dependency risk. Multi-signature escrow and arbitration logic are complex security-critical paths.

Active development evident from GitHub Actions workflows (build.yml, codacy-coverage-reporter.yml), dependabot configuration for dependency updates, and Makefile for automation. Recent infrastructure: issue templates for bug reports and asset additions (new_asset.md suggests ongoing token/asset listing), stale issue management, and comprehensive test category documentation (apitest/docs/test-categories.md).

git clone https://github.com/bisq-network/bisq.git && cd bisq && ./gradlew clean build && ./gradlew :apitest:installDaoSetup (to fetch dao-setup files required for testing)

Daily commands: Regular build: ./gradlew clean build. Run API tests (requires DAO setup): ./gradlew :apitest:test -DrunApiTests=true. Simulation scenarios: ./apitest/scripts/trade-simulation.sh, ./apitest/scripts/bsqswap-simulation.sh. DAO-specific setup: ./gradlew :apitest:installDaoSetup -x test

• apitest/src/main/java/bisq/apitest/ApiTestMain.java — Entry point for the API test framework that bootstraps and manages the entire test environment including Bisq instances and Bitcoin daemon.
• apitest/src/main/java/bisq/apitest/Scaffold.java — Core test orchestration class that manages setup, teardown, and coordination of multiple Bisq application instances for integration testing.
• apitest/build.gradle — Gradle build configuration that defines dependencies, tasks, and build parameters for the entire API test module.
• apitest/src/main/java/bisq/apitest/config/ApiTestConfig.java — Configuration manager that loads and validates all API test settings, port allocations, and environment parameters.
• apitest/src/main/java/bisq/apitest/linux/BisqProcess.java — Process management wrapper that spawns, monitors, and controls Bisq daemon instances in the test environment.
• apitest/src/test/java/bisq/apitest/ApiTestCase.java — Base test class providing common setup, assertions, and utilities inherited by all API integration test suites.
• CONTRIBUTING.md — Developer contribution guidelines and workflow expectations that all contributors must follow before submitting changes.

Add a New API Method Test

1. Create a new test class extending MethodTest in apitest/src/test/java/bisq/apitest/method/ (apitest/src/test/java/bisq/apitest/method/MethodTest.java)
2. Override setUp() to initialize required state and inherit getClient() for API calls (apitest/src/test/java/bisq/apitest/ApiTestCase.java)
3. Write @Test methods calling API endpoints via inherited client, using assertions from ApiTestCase (apitest/src/test/java/bisq/apitest/ApiTestCase.java)
4. Register test class in test suite via Gradle or IDE test runner (apitest/build.gradle)

Add a New Trade Scenario Test

1. Extend AbstractTradeTest in apitest/src/test/java/bisq/apitest/method/trade/ (apitest/src/test/java/bisq/apitest/method/trade/AbstractTradeTest.java)
2. Use Scaffold to get separate Bisq instances (buyer/seller) via scaffold.trader(role) (apitest/src/main/java/bisq/apitest/Scaffold.java)
3. Call offer creation, offer taking, and trade progress APIs; validate ExpectedProtocolStatus states (apitest/src/test/java/bisq/apitest/method/trade/ExpectedProtocolStatus.java)
4. Verify final trade state and asset balances after completion (apitest/src/test/java/bisq/apitest/ApiTestCase.java)

Add Support for a New Asset Type

1. Create new test class extending CreateOfferUsingFixedPriceTest for the asset (apitest/src/test/java/bisq/apitest/method/offer/CreateOfferUsingFixedPriceTest.java)
2. Configure asset-specific payment methods and account requirements (apitest/src/test/java/bisq/apitest/method/payment/AbstractPaymentAccountTest.java)
3. Add asset-specific test cases for BSQ Swaps or XMR trades following existing patterns (apitest/src/test/java/bisq/apitest/method/offer/CreateXMROffersTest.java)
4. Update documentation in apitest/docs/ with asset-specific test instructions (apitest/docs/test-categories.md)

Add a New Automated Test Simulation Script

1. Create bash script in apitest/scripts/ following naming convention (e.g., your-simulation.sh) (apitest/scripts/trade-simulation.sh)
2. Source trade-simulation-env.sh for common variables and utility functions (apitest/scripts/trade-simulation-env.sh)
3. Use provided bash utilities and BitcoinCli wrapper to orchestrate test flow (apitest/src/test/java/bisq/apitest/method/BitcoinCliHelper.java)
4. Reference script in documentation and CI workflows (.github/workflows/build.yml) (.github/workflows/build.yml)

• Java + Gradle — Matches core Bisq codebase language and build system for seamless integration and shared dependency management
• gRPC/REST API testing — Tests the actual Bisq daemon API surface that users and third-party integrations consume
• Multi-process orchestration (Scaffold) — Enables realistic peer-to-peer trading scenarios with isolated Bisq instances simulating separate market participants
• Bitcoin regtest daemon — Provides deterministic, fast blockchain environment for testing without external dependencies or mainnet risk
• Bash simulation scripts — Automates realistic trading workflows with multiple operations in sequence, useful for load testing and scenario validation

• Multi-process test instances instead of mocking
  • Why:
  • Consequence: undefined

DAO setup files must be downloaded via gradle task (apitest/dao-setup.gradle) before running integration tests—they are not committed to git. Tests are disabled by default (test.enabled = false) and require -DrunApiTests=true flag to execute. Logback configuration path is hardcoded for apitest (apitest/build/resources/main/logback.xml). Some scripts (editf2faccountform.py) suggest Python 2/3 compatibility issues—verify Python version. Regtest simulations use multiple localhost ports; check apitest/docs/regtest-port-conflicts.md for port requirements.

• Multi-signature escrow — Core mechanism in Bisq for non-custodial settlement; two traders and an arbitrator must sign off on fund release, preventing theft by any single party
• P2P order book (distributed consensus) — Bisq replicates order books across all peers without a central server; understanding eventual consistency and conflict resolution is critical for trading logic
• Atomic swaps / HTLCs (Hash Time-Locked Contracts) — Enables trustless cross-chain trading; Bisq uses cryptographic guarantees instead of arbitration for certain trade types (implied by bsqswap-simulation.sh)
• Tor integration for P2P networking — Bisq users connect via Tor for privacy; the codebase must handle onion addressing, exit node selection, and connection establishment robustly
• DAO governance (decentralized autonomous organization) — Bisq operates as a DAO for protocol upgrades and dispute resolution; dao-setup.gradle and DAO-related tests indicate complex governance state management
• Gradle plugin architecture (custom bisq.gradle plugin) — Build system is highly customized; understanding the bisq.gradle plugin is essential for modifying dependencies, packaging, or test execution
• Bitcoin UTXO model & transaction signing — Bisq constructs, signs, and broadcasts Bitcoin transactions for escrow and settlement; incorrect UTXO handling or signing logic could cause fund loss

• btcpayserver/btcpayserver — Bitcoin payment processor; solves similar P2P payment problems but for merchant checkouts rather than peer trading
• lightning-network/lightning-rfc — Layer 2 payment channel protocol; Bisq could integrate Lightning for faster settlement or cross-chain atomic swaps
• bitcoinj/bitcoinj — Java Bitcoin library; likely used by Bisq for transaction creation, signing, and blockchain interaction
• bisq-network/bisq-website — Official Bisq documentation and marketing site; complements this repo with user-facing guides and API docs
• monero-project/monero — Monero cryptocurrency; Bisq supports XMR trading (evident from trade-xmr-simulation.sh), making this a key supported asset

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive unit tests for ApiTestConfig and BisqAppConfig classes

The apitest/src/main/java/bisq/apitest/config directory contains critical configuration classes (ApiTestConfig.java, BisqAppConfig.java, ApiTestRateMeterInterceptorConfig.java) that lack visible unit test coverage in the file structure. These classes are essential for the API testing framework's reliability. Adding unit tests would validate configuration parsing, environment variable handling, and edge cases before tests run.

• [ ] Create apitest/src/test/java/bisq/apitest/config directory structure
• [ ] Write ApiTestConfigTest.java covering initialization, validation, and property loading scenarios
• [ ] Write BisqAppConfigTest.java testing app version detection and resource file resolution
• [ ] Write ApiTestRateMeterInterceptorConfigTest.java validating rate limiting configuration
• [ ] Ensure tests use JUnit and follow existing project conventions from apitest build.gradle

Add unit tests for Linux process management classes (AbstractLinuxProcess, BashCommand, SystemCommandExecutor)

The apitest/src/main/java/bisq/apitest/linux directory contains critical OS-level process management code (AbstractLinuxProcess.java, BashCommand.java, SystemCommandExecutor.java, ThreadedStreamHandler.java) that directly spawns Bisq instances and bitcoin daemons. These are high-risk areas prone to platform-specific bugs. Unit tests would validate command execution, error handling, stream processing, and timeout behavior without requiring actual bitcoind or Bisq instances.

• [ ] Create apitest/src/test/java/bisq/apitest/linux directory
• [ ] Write SystemCommandExecutorTest.java with mocked Process objects to test command execution and error streams
• [ ] Write BashCommandTest.java validating shell script escaping and command building
• [ ] Write ThreadedStreamHandlerTest.java testing concurrent stream reading and line buffering
• [ ] Add integration test helpers to mock ProcessBuilder for isolated testing

Create GitHub Actions workflow to run API tests on schedule and validate dao-setup installation

The current .github/workflows (build.yml, codacy-coverage-reporter.yml, stale.yml) don't include automated API testing. The apitest module has complex DAO setup requirements (dao-setup.gradle, installDaoSetup task) and multiple simulation scripts (trade-simulation.sh, bsqswap-simulation.sh) that currently rely on manual execution. A scheduled workflow would catch regressions in API compatibility and DAO setup processes without blocking regular builds (test.enabled is disabled by default).

• [ ] Create .github/workflows/apitest.yml as a scheduled workflow (e.g., nightly)
• [ ] Add job to download dao-setup files using gradle :apitest:installDaoSetup task
• [ ] Add job to run gradle :apitest:test -DrunApiTests=true with proper error reporting
• [ ] Configure workflow to only run on schedule or manual trigger to avoid blocking main build.yml
• [ ] Add step to archive test reports and upload to Codacy for coverage tracking

• Add unit tests for the multi-signature escrow contract logic (no explicit test file visible for core escrow.* modules)—start by exploring core package structure and writing JUnit tests in apitest/src/test
• Document the P2P networking protocol for order book synchronization (implied by 'distributed order books' but no docs visible in top 60 files)—contribute to apitest/docs/ with protocol diagrams and message flow examples
• Create a shell script wrapper to simplify the test setup process (currently requires manual installDaoSetup + test flags)—add to apitest/scripts/ as test-setup-and-run.sh that abstracts the gradle commands

The Bisq codebase shows a generally good security posture for a decentralized exchange project, with clear separation of concerns and modular build configuration. However, several areas need attention: (1) API test execution is not enforced by default, which could weaken CI/CD coverage; (2) dependency management practices are not fully visible in the provided snippet; (3) no explicit security policy or responsible disclosure process is documented; (4) external resource downloads lack visible integrity verification. The project would benefit from implementing dependency locking, creating a SECURITY.md file, ensuring API tests always run in CI, and documenting security best practices for contributors. No hardcoded credentials or critical infrastructure misconfigurations were detected in the provided file structure.

• Medium · Test Execution Configuration Weakness — apitest/build.gradle (line: test.enabled = System.getProperty("runApiTests") == "true"). API tests are disabled by default and only run when explicitly enabled via system property 'runApiTests=true'. This could lead to incomplete test coverage in CI/CD pipelines if not properly configured, potentially allowing bugs to slip through. Fix: Ensure CI/CD pipeline explicitly enables API tests. Consider making this the default behavior or using a more explicit configuration mechanism. Document the test execution requirements clearly in CONTRIBUTING.md.
• Low · Missing Dependency Lock File — apitest/build.gradle and root build configuration. The Gradle build configuration shown does not include dependency lock files or version pinning strategies. This could lead to supply chain vulnerabilities if transitive dependencies receive compromised updates. Fix: Implement Gradle dependency locking (gradle.lockfile) to lock transitive dependencies. Review and audit all dependencies regularly using tools like OWASP Dependency-Check.
• Low · Logback Configuration Exposure — apitest/build.gradle (applicationDefaultJvmArgs with logback.configurationFile). The application uses an external logback configuration file specified via system property. If improperly secured, this could allow log injection or information disclosure attacks. Fix: Ensure logback.xml is stored securely and not accessible to untrusted users. Validate that sensitive data (credentials, private keys) is not logged. Review logback configuration in apitest/src/main/resources/logback.xml for security settings.
• Low · Missing Security Policy Documentation — Repository root (missing SECURITY.md). No SECURITY.md or security policy file is evident in the repository structure. This makes it difficult for security researchers to report vulnerabilities responsibly. Fix: Create a SECURITY.md file documenting responsible disclosure procedures, security contacts, and vulnerability reporting guidelines per GitHub recommendations.
• Low · Incomplete Build Configuration Review — apitest/build.gradle (incomplete view). The provided build.gradle snippet is incomplete and doesn't show the full dependency declarations, version constraints, or dependency management strategies that would be needed for complete security analysis. Fix: Review the complete build.gradle files and any shared dependency management (parent pom, build-conventions, etc.) for vulnerable dependency versions using tools like 'gradle dependencyReport' and OWASP Dependency-Check.
• Low · External Resource Download Without Integrity Verification — apitest/dao-setup.gradle (referenced but not shown). The dao-setup.gradle applies external tasks that download files from GitHub raw content. These downloads should verify integrity and use HTTPS, but no explicit verification mechanism is documented. Fix: Implement checksum verification for downloaded files. Use gradle dependency management instead of raw downloads when possible. Document the download sources and verification procedures.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/bisq-network/bisq shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live bisq-network/bisq repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/bisq-network/bisq.

What it runs against: a local clone of bisq-network/bisq — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in bisq-network/bisq | Confirms the artifact applies here, not a fork | | 2 | License is still AGPL-3.0 | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 30 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of bisq-network/bisq. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/bisq-network/bisq.git
#   cd bisq
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of bisq-network/bisq and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "bisq-network/bisq(\\.git)?\\b" \\
  && ok "origin remote is bisq-network/bisq" \\
  || miss "origin remote is not bisq-network/bisq (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(AGPL-3\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"AGPL-3\\.0\"" package.json 2>/dev/null) \\
  && ok "license is AGPL-3.0" \\
  || miss "license drift — was AGPL-3.0 at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "apitest/src/main/java/bisq/apitest/ApiTestMain.java" \\
  && ok "apitest/src/main/java/bisq/apitest/ApiTestMain.java" \\
  || miss "missing critical file: apitest/src/main/java/bisq/apitest/ApiTestMain.java"
test -f "apitest/src/main/java/bisq/apitest/Scaffold.java" \\
  && ok "apitest/src/main/java/bisq/apitest/Scaffold.java" \\
  || miss "missing critical file: apitest/src/main/java/bisq/apitest/Scaffold.java"
test -f "apitest/build.gradle" \\
  && ok "apitest/build.gradle" \\
  || miss "missing critical file: apitest/build.gradle"
test -f "apitest/src/main/java/bisq/apitest/config/ApiTestConfig.java" \\
  && ok "apitest/src/main/java/bisq/apitest/config/ApiTestConfig.java" \\
  || miss "missing critical file: apitest/src/main/java/bisq/apitest/config/ApiTestConfig.java"
test -f "apitest/src/main/java/bisq/apitest/linux/BisqProcess.java" \\
  && ok "apitest/src/main/java/bisq/apitest/linux/BisqProcess.java" \\
  || miss "missing critical file: apitest/src/main/java/bisq/apitest/linux/BisqProcess.java"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 30 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~0d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/bisq-network/bisq"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.