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/openethereum/parity-ethereum 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.

WAIT — Stale — last commit 6y ago

• 35+ active contributors
• Distributed ownership (top contributor 15% of recent commits)
• Other licensed
• CI configured
• Tests present
• ⚠ Stale — last commit 6y ago
• ⚠ Non-standard license (Other) — review terms

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

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

What it runs against: a local clone of openethereum/parity-ethereum — 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 openethereum/parity-ethereum | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch v2.7.2-stable exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 2044 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of openethereum/parity-ethereum. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/openethereum/parity-ethereum.git
#   cd parity-ethereum
#
# 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 openethereum/parity-ethereum and re-run."
  exit 2
fi

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

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

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

# 4. Critical files exist
test -f "Cargo.toml" \\
  && ok "Cargo.toml" \\
  || miss "missing critical file: Cargo.toml"
test -f "ethcore/src" \\
  && ok "ethcore/src" \\
  || miss "missing critical file: ethcore/src"
test -f "accounts/ethstore/src/ethstore.rs" \\
  && ok "accounts/ethstore/src/ethstore.rs" \\
  || miss "missing critical file: accounts/ethstore/src/ethstore.rs"
test -f "accounts/ethkey/src/lib.rs" \\
  && ok "accounts/ethkey/src/lib.rs" \\
  || miss "missing critical file: accounts/ethkey/src/lib.rs"
test -f "cli-signer/src/lib.rs" \\
  && ok "cli-signer/src/lib.rs" \\
  || miss "missing critical file: cli-signer/src/lib.rs"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 2044 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~2014d)"
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/openethereum/parity-ethereum"
  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).

Parity Ethereum is a full Ethereum client implementation written in Rust, designed for high-performance synchronization and minimal resource footprint. It provides the core infrastructure for miners, exchanges, and service providers, featuring Warp Sync (synchronize in hours instead of days), a JSON-RPC HTTP server on port 8545, and WebSocket support on 8546. The codebase is modular and customizable, targeting mission-critical deployments that require fast sync and maximum uptime. Monorepo structure: ethcore/ contains the core blockchain engine and consensus logic; accounts/ (ethkey, ethstore) handles key management and account encryption; util/ has foundational libraries (blooms-db, journaldb, migration-rocksdb, network, io); miner/, cli-signer/, and secret-store/ are optional feature modules. parity/ subdirectory contains logger and CLI integration. Dependencies are workspace crates declared in root Cargo.toml with path entries.

Miners, exchange operators, and infrastructure service providers who need a high-performance Ethereum node with lower memory/storage overhead than geth. Contributors are Rust developers and blockchain engineers building or extending Ethereum infrastructure; the project is maintained by Parity Technologies.

Production-ready and actively maintained as of 2.7.2 (released before the transition to OpenEthereum). CI/CD is configured via .gitlab-ci.yml and .github workflows. The codebase is substantial (6M+ lines of Rust) with comprehensive module structure (ethcore, accounts, miner, etc.), indicating maturity. However, note this is the legacy Parity Ethereum—Parity Technologies has since shifted focus to other projects.

Significant dependency surface area via Cargo.lock with large transitive dependency trees (kvdb-rocksdb, jsonrpc-core, futures 0.1). The codebase uses older Rust async patterns (futures 0.1 instead of async/await), which may complicate maintenance. Monitor the GitHub issue backlog and commit frequency—as of the repo snapshot, this appears to be in maintenance mode rather than active feature development. GPL-3.0 license restricts commercial use without source disclosure.

As of the snapshot data, active development has slowed—this repository is the legacy 'Parity Ethereum' before the fork to OpenEthereum. The CHANGELOG.md and version 2.7.2 suggest the project stabilized; current activity is likely maintenance-focused (bug fixes, security patches) rather than new features. Check .gitlab-ci.yml and recent tags for the latest release cadence.

git clone https://github.com/openethereum/parity-ethereum.git
cd parity-ethereum
cargo build --release
cargo run --release -- --chain mainnet

For development builds (faster iteration): cargo build omits --release. See CONTRIBUTING.md for development workflows.

Daily commands: Development:

cargo build
cargo run -- --chain mainnet --jsonrpc-port 8545

Production:

cargo build --release
./target/release/parity --chain mainnet --pruning fast

Custom chain (private network):

./target/release/parity --chain ./my-spec.json --datadir ./my-data

Test suite:

cargo test --lib
cargo test --test '*'  # Integration tests in accounts/ethstore/cli/tests/cli.rs, etc.

• Cargo.toml — Root workspace manifest defining all dependencies, workspace members, and the parity-ethereum client version; essential for understanding build targets and external crate versions.
• ethcore/src — Core Ethereum execution engine implementation; every contributor must understand this layer as it contains consensus, transaction processing, and state management.
• accounts/ethstore/src/ethstore.rs — Account storage and key management system; critical for understanding how private keys, wallets, and account signing are handled.
• accounts/ethkey/src/lib.rs — Cryptographic key generation and derivation library; foundational for account creation and key derivation logic.
• cli-signer/src/lib.rs — CLI-based transaction signing interface; entry point for understanding how the client signs and submits transactions.
• .gitlab-ci.yml — CI/CD pipeline configuration; critical for understanding build validation and release processes.
• README.md — Project overview, architecture description, and contribution guidelines; must-read for understanding project scope and goals.

Add a New Account Derivation Method

1. Implement the derivation algorithm in a new module (e.g., brain_custom.rs) (accounts/ethkey/src/brain_custom.rs)
2. Export the new method from the public library interface (accounts/ethkey/src/lib.rs)
3. Add corresponding CLI command handler (accounts/ethkey/cli/src/main.rs)
4. Add integration tests using test fixtures (accounts/ethkey/tests/integration.rs)

Add a New Consensus Engine (e.g., Custom PoA)

1. Create a new engine module implementing the Engine trait (ethcore/engine/src/custom_engine.rs)
2. Register the engine factory in the engine module (ethcore/engine/src/lib.rs)
3. Define chain spec JSON for the custom network with the new engine (chainspec/src/main.rs)
4. Add validator/state machine logic for consensus rules (ethcore/engine/src/custom_engine/validator.rs)

Extend Account Store with a New Backend

1. Implement the AccountsDir trait for the new backend (e.g., cloud storage) (accounts/ethstore/src/accounts_dir/cloud.rs)
2. Register the backend in the accounts_dir module factory (accounts/ethstore/src/accounts_dir/mod.rs)
3. Add configuration parsing for the new backend type (accounts/ethstore/src/lib.rs)
4. Add integration tests with the test fixtures (accounts/ethstore/tests/api.rs)

Add a New RPC Signer Method

1. Define the new JSON-RPC method in the signer client (cli-signer/rpc-client/src/signer_client.rs)
2. Implement the handler in the main CLI signer library (cli-signer/src/lib.rs)
3. Integrate with the JSON-RPC client communication layer (cli-signer/rpc-client/src/client.rs)

• Rust — Memory safety, performance, and low-level systems control for blockchain execution and cryptography without garbage collection pauses.
• ECDSA (secp256k1) — Industry standard for Ethereum transaction signing and account derivation; cryptographic compatibility with Geth and other clients.
• Scrypt + AES-128-CTR — Slow key derivation function (KDF) and symmetric encryption for secure account storage resistant to brute-force attacks.
• JSON-RPC 2.0 — Standard Ethereum RPC protocol for node communication, backward compatible with web3 clients and wallets.
• Pluggable Consensus Engines — Support for PoW, PoA, and Aura to enable private/custom networks while maintaining a single codebase.

• CLI-based signing (separate process) vs. built-in signer

  • Why: Enhanced security by isolating key management from the main node process
  • Consequence: Adds network RPC overhead (~50-100ms per signature) but eliminates in-memory key exposure during normal node operation.

• Disk-based account storage with encryption at rest

  • Why: Persistence and offline account management without requiring external key management services
  • Consequence: Slower account unlocking (scrypt KDF ~100-500ms) but better for air-gapped setups and self-custody.

• Monolithic engine trait vs. modular consensus layers

  • Why: Simplified consensus swapping and faster prototyping of new consensus rules
  • Consequence: Tightly coupled engine logic; harder to test consensus rules in isolation from block execution.

• Support for custom chain specs (JSON) vs. code-generated chains

  • Why: Enable permissionless network creation and client deployment without recompilation
  • Consequence: Chain spec parsing/validation logic adds complexity; potential for misconfiguration in production networks.

• Does not provide a light client protocol (relies on full node execution).
• Does not support cross-chain atomic swaps or interoperability protocols.
• Does not include a built-in smart contract IDE or compiler (integrates with external tools).
• Does not manage private key backups or cloud-based key recovery (delegated to user/wallet responsibility).
• Does not implement sharding or Layer 2 scaling solutions.
• Does not provide a UI/dashboard (command-line and RPC only).

1. Futures 0.1 async model: This codebase predates Rust async/await and uses futures 0.1 combinators. Modern async patterns won't compile directly—you must use the futures ecosystem present in Cargo.lock.

2. Pruning strategy implications: journaldb's pruning modes (fast, archive, recent) drastically affect storage and runtime performance. Default is 'fast,' but tests or special deployments may require 'archive' mode, which will not prune old state.

3. RocksDB data format is not portable: kvdb-rocksdb creates a RocksDB database in datadir; moving the database between architectures or RocksDB versions may cause corruption. Always specify --pruning and --datadir consistently.

4. Optional features can silently fail: Features like secretstore, ethcore-accounts, and ethcore-call-contract are optional (optional = true in Cargo.toml). Building without them works but functionality is absent; tests may be skipped. Use cargo build --features "secretstore" to enable.

5. GPL-3.0 license: Linking this library into closed-source projects requires source disclosure; be aware of license obligations.

6. Version mismatch in util/version/Cargo.toml: The note in root Cargo.toml states version bumps must also update util/version/Cargo.toml—forgetting this will cause version mismatch bugs in reporting.

7. No built-in auto-update: The codebase has updater/hash-fetch (parity-hash-fetch) but auto-update is not enabled by default; manual binary updates are the norm.

• Warp Sync — Parity Ethereum's signature feature for fast blockchain synchronization by downloading only recent state snapshots instead of replaying all history; critical to understanding the sync module (ethcore/sync/) and its performance claims.
• Bloom Filters (for transaction logs) — The blooms-db crate uses Bloom filters to index transaction logs by topics; essential for understanding how eth_getLogs queries are fast without full-text search, and why the Bloom database is separate from the main state DB.
• Journal Database / Journaldb — Parity's abstraction over RocksDB that supports multiple pruning strategies (fast, archive, recent); critical for understanding state storage optimization and why different deployment profiles exist.
• Key Derivation Function (KDF) in Account Encryption — ethstore uses KDF (Pbkdf2, Scrypt, Argon2) to derive keys from passwords; understanding accounts/ethstore/src/account/kdf.rs is essential for account security and password-based key recovery.
• Consensus Engine Pluggability — Parity Ethereum abstracts consensus via ethcore/engine/src/ with implementations for Ethash (PoW), Aura (PoA), and Clique (PoA)—understanding the Engine trait is necessary for running private blockchains or adding custom consensus.
• Sparse Merkle Tree (SMT) for State — Ethereum's state is stored as a Merkle tree in the ethcore/blockchain module; Warp Sync exploits tree structure to download only changed branches. Understanding trie proofs is necessary for light client features.

• ethereum/go-ethereum — Go implementation of Ethereum (geth); primary competing full node client with similar featureset (RPC, sync, consensus). Users often compare geth vs Parity for performance and resource usage.
• hyperledger/besu — Enterprise-focused Ethereum client in Java; another mature alternative to Parity, especially for consortium/private blockchain deployments.
• openethereum/openethereum — Direct successor to this Parity Ethereum repository; the community fork after Parity Technologies shifted focus. If you're using legacy Parity, migration to OpenEthereum is the recommended upgrade path.
• paritytech/substrate — Parity's next-generation blockchain framework (Rust-based); many design patterns and cryptographic primitives from Parity Ethereum influenced Substrate's architecture.
• paritytech/polkadot — Polkadot network implementation using Substrate; represents Parity's evolution beyond Ethereum toward multi-chain interoperability, using Rust architecture lessons from this codebase.

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 ethstore account cipher and crypto modules

The accounts/ethstore/src/account/ directory contains critical security-sensitive code (cipher.rs, crypto.rs, kdf.rs) but there are no visible unit tests in the file structure. Given this handles key derivation and encryption, comprehensive tests are essential. The accounts/ethstore/cli/tests/cli.rs shows integration tests exist, but unit tests for the core cryptographic operations are missing.

• [ ] Create accounts/ethstore/src/account/cipher.rs tests module with test cases for all cipher operations
• [ ] Create accounts/ethstore/src/account/crypto.rs tests covering encryption/decryption roundtrips
• [ ] Create accounts/ethstore/src/account/kdf.rs tests for key derivation functions with known test vectors
• [ ] Run 'cargo test --lib' in accounts/ethstore to verify coverage and ensure all security paths are tested

Add GitHub Actions workflow for automated security audits on accounts/ crate

The repo uses .gitlab-ci.yml but lacks GitHub Actions workflows. The accounts/ crate (ethkey and ethstore) handles sensitive cryptographic operations and private key management. A dedicated security audit CI workflow would catch potential vulnerabilities early. Given the SECURITY.md file exists, a formal security CI pipeline is a natural next step.

• [ ] Create .github/workflows/security-audit.yml workflow that runs 'cargo audit' on the accounts/ethkey and accounts/ethstore crates
• [ ] Add dependency checking with 'cargo outdated' to identify stale crypto dependencies
• [ ] Configure the workflow to run on pull requests affecting accounts/ files and on schedule (weekly)
• [ ] Document in SECURITY.md the process for vulnerability reporting and how security PRs trigger the workflow

Refactor ethstore vault management into separate module structure

The accounts/ethstore/src/accounts_dir/ directory has vault.rs mixed with disk.rs and memory.rs storage backends. Vault functionality (vault_file.rs, vault_key_file.rs in json/) is scattered across the json module. This creates maintenance friction. Extract vault operations into a dedicated accounts/ethstore/src/vault/ module to improve organization, testability, and encapsulation of vault-specific logic.

• [ ] Create accounts/ethstore/src/vault/ directory and create vault/mod.rs with public API
• [ ] Move vault-specific logic from accounts_dir/vault.rs into vault/mod.rs and create vault/operations.rs for vault creation/unlock logic
• [ ] Create vault/json_adapter.rs to consolidate json/vault_file.rs and json/vault_key_file.rs handling
• [ ] Update accounts_dir/mod.rs to use the new vault module as a dependency and remove vault.rs
• [ ] Add unit tests in vault/ and update integration tests in accounts/ethstore/cli/tests/ to verify refactoring

• Add integration tests for ethstore account decryption edge cases: The accounts/ethstore/cli/tests/ directory only has cli.rs. Add tests in accounts/ethstore/src/account/tests/ for crypto.rs and kdf.rs covering invalid passwords, corrupted cipher data, and KDF parameter variations. This improves security test coverage without requiring deep blockchain knowledge.
• Improve journaldb documentation and add pruning mode comparison: util/journaldb/README.md (if it exists) likely lacks clarity on the performance/storage tradeoffs between 'fast', 'archive', and 'recent' modes. Write a doc with benchmarks showing datadir size and sync time for each mode on a live network, then link it from CONTRIBUTING.md.
• Add metrics/logging to Warp Sync progress: ethcore/sync/src/ contains Warp Sync logic but users have no visibility into sync progress. Instrument the sync state machine with progress counters and log them periodically (e.g., 'Downloaded 45/100 manifest chunks'). This improves user experience and is a good networking/observability task for a junior contributor.

• High · Outdated Cryptographic Dependencies — Cargo.toml - parity-crypto, keccak-hash, and related dependencies. The codebase uses parity-crypto 0.4.2 which may contain known vulnerabilities. Additionally, keccak-hash 0.4.0 and other crypto-related dependencies appear to be from older versions that may lack security patches for cryptographic operations. Fix: Audit all cryptographic dependencies for known CVEs. Update to the latest stable versions of parity-crypto, keccak-hash, and other crypto libraries. Run cargo audit to identify known vulnerabilities in dependencies.
• High · Deprecated Async Runtime (futures 0.1) — Cargo.toml - futures = 0.1. The codebase uses futures 0.1, which is significantly outdated and no longer maintained. This can expose the code to unknown security issues and compatibility problems with modern Rust security tooling. Fix: Migrate to futures 0.3 or prefer tokio/async-std for modern async operations. Update all async/await code to use current async runtime standards.
• High · Insecure Password Handling in ethkey — accounts/ethkey/src/brain.rs, accounts/ethkey/src/password.rs, accounts/ethkey/src/brain_prefix.rs, accounts/ethkey/src/brain_recover.rs. The accounts/ethkey module contains password.rs and brain.rs which may handle private keys and passwords. Brain wallet implementations are known to be cryptographically weak and susceptible to dictionary attacks. Fix: Audit brain wallet implementations for cryptographic weaknesses. Consider deprecating brain wallet functionality or implementing additional entropy requirements. Use constant-time comparisons for sensitive data. Implement rate limiting on password attempts.
• Medium · Potential Private Key Storage Vulnerabilities — accounts/ethstore/src/account/cipher.rs, accounts/ethstore/src/account/kdf.rs, accounts/ethstore/src/accounts_dir/vault.rs. The ethstore module handles encrypted key storage with vault.rs and cipher.rs. Improper implementation of encryption, key derivation functions (KDF), or storage could expose private keys. Fix: Conduct a security audit of KDF implementations (ensure PBKDF2 or scrypt with adequate iterations). Verify cipher implementations use authenticated encryption (AES-GCM preferred). Ensure private keys are never logged or exposed in error messages. Implement secure memory wiping for sensitive data.
• Medium · Unsafe CLI Command Line Argument Handling — accounts/ethstore/cli/src/crack.rs, accounts/ethstore/cli/src/main.rs. The ethstore CLI (accounts/ethstore/cli/src/crack.rs) implements account cracking functionality. This could be misused for unauthorized access if the binary is compromised or falls into wrong hands. Fix: Add warnings about the sensitive nature of this tool. Implement audit logging for all crack/recovery operations. Consider restricting compilation of this tool or adding runtime guards. Document the security implications clearly.
• Medium · Potential JSON Deserialization Vulnerabilities — accounts/ethstore/src/json/. The json module extensively deserializes wallet and vault files. Malicious JSON files could potentially cause DoS or other attacks if not validated properly. Fix: Implement strict JSON schema validation. Add file size limits for JSON parsing. Use serde with deny_unknown_fields to prevent unexpected attributes. Add comprehensive error handling and logging for deserialization failures.
• Medium · Missing Input Validation in Keyfile Handling — accounts/ethstore/tests/res/geth_keystore/, accounts/ethstore/src/import.rs. Key files are imported and parsed from external sources (geth_keystore tests reference external keyfiles). Insufficient validation could allow malformed files to cause issues. Fix: Implement comprehensive validation of imported keyfiles. Verify all required fields are present and correctly formatted. Add strict type checking. Implement file integrity checks (checksums/signatures).
• Low · Test Resources May Contain Sensitive Data — ``. Test keystore files in accounts/ethstore/tests/res/ are committed to the repository. Even if these are test keys, this could confuse users or create security awareness issues. Fix: undefined

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

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

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