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/EOSIO/eos 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.

GO — Healthy across all four use cases

• 14 active contributors
• Distributed ownership (top contributor 47% of recent commits)
• MIT licensed
• CI configured
• Tests present
• ⚠ Stale — last commit 4y ago

_{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 EOSIO/eos repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/EOSIO/eos.

What it runs against: a local clone of EOSIO/eos — 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 EOSIO/eos | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | Last commit ≤ 1413 days ago | Catches sudden abandonment since generation |

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

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

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT 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"

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

EOSIO is an open-source blockchain infrastructure platform that enables deployment of smart contracts compiled to WebAssembly. It provides free rate-limited transactions, 0.5-second block confirmation, Byzantine fault tolerance, and hierarchical role-based permissions—designed for parallel execution and inter-blockchain communication at scale. Monolithic C++ project with CMake build system (CMakeLists.txt + CMakeModules/). Core consensus and smart contract runtime in main source tree; multi-stage CI/CD pipeline in .cicd/ (base-images.yml → build-scripts.yml → test.sh); platform-specific configurations split into pinned/ (reproducible builds) and unpinned/ (latest dependencies) Dockerfiles and shell scripts. WebAssembly contracts compiled via custom ASM-LLVMWAR compiler (CMakeModules/CMakeDetermineASM-LLVMWARCompiler.cmake).

Blockchain developers and node operators building decentralized applications; block producers deploying and maintaining EOSIO-based blockchain networks; enterprise teams needing high-performance smart contract execution without transaction fees per operation.

Production-ready. The codebase shows extensive CI/CD infrastructure (.cicd/ directory with multi-platform Docker builds, Buildkite integration), pinned dependencies for 8+ OS versions (Ubuntu 16.04-20.04, CentOS 7-8, Amazon Linux 2, macOS 10.14-10.15), and official package distribution via Homebrew. Last activity visible in GitHub workflows (.github/workflows/main.yml) and active submodule management.

Moderate production risk. The C++ codebase (9.2M LOC) has complex build dependencies across 8+ platforms requiring careful dependency pinning (see .cicd/platforms/pinned/ for environment specifications). Risk of breaking changes during major version updates; dependency on WebAssembly toolchain (llvm-wasm compiler, custom CMAKE ASM modules). Repository appears community-maintained post Block.one disclaimer, which may affect long-term support trajectory.

Active multi-platform CI/CD maintenance: recent work on GitHub Actions (.github/workflows/main.yml) alongside legacy GitLab CI (.gitlab-ci.yml); platform support expanded to Ubuntu 20.04 and CentOS 8; submodule regression testing (submodule-regression-check.sh) suggesting dependency stability work. Docker-based binary distribution via create-docker-from-binary.sh.

Clone and build:

git clone https://github.com/EOSIO/eos.git
cd eos
git submodule update --init --recursive
mkdir build && cd build
cmake -DCMAKE_BUILD_TYPE=Release ..
make -j$(nproc)

Or use pinned platform image for reproducibility: docker build -f .cicd/platforms/pinned/ubuntu-20.04-pinned.dockerfile .

Daily commands: Build from source: cmake && make. Run tests: .cicd/test.sh (orchestrates platform-specific test suites). Deploy node: compiled binaries in build/programs/ (typically nodeos for validator node, cleos for CLI). Development: modify C++ source, rebuild with make, execute .cicd/test.sh to validate.

• CMakeLists.txt: Root build configuration; defines all compile flags, dependencies, and platform-specific behavior for the entire C++ codebase
• .cicd/build.sh: Central CI/CD entry point; orchestrates Docker image building, compilation, and binary packaging across all supported platforms
• .cicd/platforms/pinned/ubuntu-20.04-pinned.dockerfile: Exemplar of reproducible build environment; shows exact dependency versions and toolchain config for a primary target platform
• CMakeModules/CMakeDetermineASM-LLVMWARCompiler.cmake: Custom WebAssembly compiler configuration; critical for compiling smart contracts to wasm bytecode
• .cicd/test.sh: Test orchestration script; defines all validation gates and test suite execution for CI/CD pipeline
• .gitmodules: Submodule dependency manifest; reveals external dependencies and their versions critical to build reproducibility

Smart contract changes: modify WebAssembly modules in libraries/wasm-* (compiled via ASM-LLVMWAR). Core consensus/network logic: edit source files under main project tree, rebuild CMake. CI/CD updates: .cicd/ directory (build-scripts.yml for pipeline logic, .cicd/platforms/* for platform-specific setup). Testing: .cicd/test.sh orchestrates; add test cases to test scripts (Python-based).

Platform pinning required: Must use pinned Dockerfiles (.cicd/platforms/pinned/*) for reproducible builds; unpinned versions may have incompatible dependency versions. WebAssembly toolchain: Requires custom llvm-wasm (ASM-LLVMWAR compiler) not in standard LLVM repos; build fails silently if missing. Submodule synchronization: .gitmodules has pinned submodule refs; git submodule update --init --recursive is mandatory or compilation fails with missing headers. CMake version: Complex CMakeModules/ assume recent CMake (3.5+); older versions fail on custom compiler detection. macOS Catalina linking: README explicitly warns of Homebrew install breakage on macOS 10.15; requires manual workaround. No build caching: Docker-based CI rebuilds from scratch; first build takes 30+ minutes on weak hardware.

• Delegated Proof of Stake (DPoS) — EOSIO's consensus mechanism—tokenholders vote for producers; understanding DPoS is essential to grasping how block validation and network security work
• WebAssembly (Wasm) Smart Contracts — EOSIO's execution engine uses Wasm bytecode compiled from C++ instead of Ethereum-style bytecode; critical to understanding contract compilation pipeline (llvm-wasm toolchain in CMakeModules/)
• Byzantine Fault Tolerance (BFT) — EOSIO provides low-latency BFT finality for transaction certainty; core to understanding the guarantees provided by the consensus layer
• Inter-Blockchain Communication (IBC) — EOSIO is designed for IBC; understanding cross-chain message passing is essential for building multi-chain applications
• Context-Free Validation Logic — EOSIO optimizes transaction processing by separating context-free validation (signature checks) from stateful execution; critical to understanding parallel transaction processing design
• Rate-Limited Transactions — EOSIO provides free transactions within rate limits per account; differs from Ethereum's per-operation gas model—understanding resource allocation (NET, CPU, RAM) is essential for contract deployment
• Custom CMake Compiler Detection — EOSIO implements custom ASM-LLVMWAR compiler via CMake modules (CMakeDetermineASM-LLVMWARCompiler.cmake); understanding this pattern is necessary to modify build system or add new compilation targets

• hyperledger/fabric — Alternative enterprise blockchain platform with smart contract support; provides comparison on consensus mechanism (PBFT vs EOSIO's BFT) and Wasm vs Chaincode approach
• ethereum/go-ethereum — Competing smart contract platform; Solidity + EVM vs EOSIO's Wasm; shows different approach to transaction fees and block confirmation
• EOSIO/eosio.cdt — Official EOSIO smart contract development toolkit; contains Wasm compiler toolchain and contract templates that pair with this node implementation
• EOSIO/eosio.contracts — Reference implementations of core system contracts (token, voting, resource management) that deploy on top of this node software
• tezos/tezos — Proof-of-stake blockchain with formal verification; alternative to EOSIO's delegated PoS model; shows different approach to on-chain governance

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 platform-specific integration tests for Docker base image builds

The .cicd/platforms directory contains pinned and unpinned Dockerfiles for 8+ platforms (Ubuntu 16/18/20, CentOS 7.7/8, Amazon Linux 2, macOS 10.14/10.15), but there's no CI workflow validating that builds succeed on each platform. The .github/workflows/main.yml likely doesn't test multi-platform builds. Adding a GitHub Actions matrix workflow to build and smoke-test the Docker images would catch platform-specific regressions early and prevent broken builds from reaching release.

• [ ] Review existing .github/workflows/main.yml to identify current build coverage
• [ ] Create new GitHub Actions workflow with matrix strategy for each .cicd/platforms/pinned/*.dockerfile
• [ ] Add build step using docker build for each platform file
• [ ] Add smoke tests (e.g., verify clang version, cmake version inside built images)
• [ ] Document new workflow in .cicd/README.md

Create unit test suite for CMakeModules build helpers

The CMakeModules directory contains critical build utilities (VersionUtils.cmake, utils.cmake, InstallDirectoryPermissions.cmake, MASSigning.cmake) that lack corresponding test files. These modules are imported by CMakeLists.txt and used across the build system but have no test coverage. Adding tests in a tests/cmake directory would catch regressions in version parsing, permission handling, and signing logic before they break builds for contributors on different platforms.

• [ ] Create tests/cmake directory structure
• [ ] Add test cases for CMakeModules/VersionUtils.cmake (version string parsing/comparison)
• [ ] Add test cases for CMakeModules/utils.cmake (utility functions)
• [ ] Add test cases for CMakeModules/InstallDirectoryPermissions.cmake (permission logic)
• [ ] Integrate cmake unit tests into .cicd/test.sh for CI pipeline

Document and add regression tests for .cicd/helpers/multi_eos_docker.py multi-version builds

The multi_eos_docker.py script appears to orchestrate multi-version Docker builds (referenced in .cicd/multiversion.sh) but lacks documentation and integration tests. Contributors cannot easily understand how to safely add new versions or test multi-version workflows. Adding a test file (tests/cicd/test_multiversion.py) with fixtures for version matrix validation and adding usage docs in .cicd/README.md would reduce contributor friction and prevent version skew bugs.

• [ ] Review .cicd/multiversion.sh and .cicd/helpers/multi_eos_docker.py to document current version strategy
• [ ] Create tests/cicd/test_multiversion.py with pytest fixtures for version matrix scenarios
• [ ] Add tests for version ordering, dockerfile selection, and tag generation logic
• [ ] Add 'Multi-Version Builds' section to .cicd/README.md with examples
• [ ] Update .gitlab-ci.yml to run multiversion tests on merge requests

• Add integration test for inter-blockchain communication (IBC) feature mentioned in README; no test file visible in .cicd/test.sh for this core capability—write Python test harness in .cicd/
• Document missing CMakeModules/additionalPlugins.cmake usage in README; file exists but no docs explain how contributors add custom plugins—add example in contributing guide
• Extend platform support to Ubuntu 22.04: create .cicd/platforms/pinned/ubuntu-22.04-pinned.dockerfile following existing 20.04 pattern, update .cicd/base-images.yml to include new platform in CI matrix

• High · Potential Insecure Dependency Management in CI/CD Pipelines — .cicd/platforms/unpinned/. Multiple Dockerfile configurations exist for different platforms (ubuntu, centos, amazon linux, macos) with both 'pinned' and 'unpinned' versions. The unpinned versions may pull arbitrary package versions, including vulnerable dependencies, without hash verification. This is particularly concerning for a blockchain/smart contract platform where supply chain attacks are critical threats. Fix: Enforce pinned dependency versions in all CI/CD pipelines. Implement hash verification for all downloaded packages. Use tools like Dependabot or Snyk to continuously scan for vulnerable dependencies. Consider using a private package mirror for additional control.
• High · Docker Image Build Security Concerns — .cicd/docker-tag.sh, .cicd/create-docker-from-binary.sh. The presence of docker image creation scripts (.cicd/create-docker-from-binary.sh, .cicd/docker-tag.sh) without visible security scanning or signing mechanisms indicates potential risks in container supply chain. No evidence of image scanning, signing, or vulnerability assessment in the provided structure. Fix: Implement container image scanning (using tools like Trivy, Clair, or Anchore) in the CI/CD pipeline. Sign all built images with Docker Content Trust or similar. Use minimal base images and implement multi-stage builds. Document image provenance and maintain an SBOM (Software Bill of Materials).
• High · Submodule Regression Check - Potential Man-in-the-Middle Risk — .cicd/submodule-regression-check.sh, .gitmodules. The file .cicd/submodule-regression-check.sh suggests use of git submodules. Submodules can be vulnerable to compromise if not properly secured, especially if pointing to HTTP endpoints or unverified repositories. The script existence indicates submodule usage but doesn't guarantee secure verification. Fix: Verify all submodule sources use HTTPS with certificate pinning. Implement GPG signature verification for submodule commits. Use git submodule security scanning tools. Consider alternative dependency management strategies (vendoring, monorepo) for critical dependencies.
• Medium · Missing Security Headers and Hardening in CI/CD Scripts — .cicd/build.sh, .cicd/test.sh, .cicd/package.sh, .cicd/helpers/general.sh. Shell scripts in .cicd directory (build.sh, test.sh, package.sh, etc.) lack visible security hardening practices such as set -euo pipefail, input validation, and secure temporary file handling. These could be exploited if CI/CD environment is compromised. Fix: Add defensive shell scripting practices: 'set -euo pipefail' at script start, quote all variables, validate all inputs, use mktemp for temporary files, avoid eval, implement secure logging without exposing secrets.
• Medium · Potential Credential Exposure in CI/CD Configuration — .github/workflows/main.yml, .gitlab-ci.yml. The .github/workflows/main.yml and .gitlab-ci.yml files are referenced but not shown. CI/CD configuration files commonly contain secrets management configurations. Without visibility, cannot verify if secrets are properly stored in secure vaults rather than as plaintext environment variables. Fix: Use platform-specific secret management (GitHub Secrets, GitLab CI/CD Variables). Never commit secrets to repository. Implement secret scanning tools (GitGuardian, TruffleHog) in pre-commit hooks. Rotate all credentials regularly. Use short-lived tokens and STS for AWS access.
• Medium · Unclear Input Validation in Helper Scripts — .cicd/helpers/file-hash.sh, .cicd/helpers/multi_eos_docker.py. Helper scripts like .cicd/helpers/file-hash.sh and .cicd/helpers/multi_eos_docker.py process file paths and external inputs without visible sanitization. Could be vulnerable to path traversal or command injection if user input is not properly validated. Fix: Implement strict input validation for all external inputs. Use allow-lists for file paths and parameters. Validate hash formats before use. In Python, use subprocess with shell=False and argument lists. Add comprehensive error handling.
• Medium · Smart Contract Security - No Visible Audit Trail — undefined. Smart contract files in /contracts directory (eosio.bios, eosio 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.