GO — Healthy across the board

• Last commit today
• 26+ active contributors
• Distributed ownership (top contributor 10% of recent commits)
• Apache-2.0 licensed
• CI configured
• Tests present

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

Sui is a Layer-1 blockchain platform written in Rust that uses the Move programming language for smart contracts, enabling parallel transaction processing with high throughput and low latency. Unlike traditional blockchains that rely on consensus for every transaction, Sui uses a simpler authority-based model for common operations like payments and asset transfers, making it the first internet-scale programmable blockchain with demonstrated capacity beyond established systems. Monorepo organized as a Rust workspace. Core components live in separate crate directories: crates/sui-core contains AuthorityState and consensus logic, crates/sui-types holds transaction/object types, crates/sui-json-rpc wraps the RPC service, and the CLI client lives in crates/sui. Move language support comes from vendored external-crates/move/ with its own compiler, bytecode verifier, and runtime. Configuration uses .cargo/config.toml for build options, .config/nextest.toml for testing, and .config/hakari.toml for workspace dependency management.

Blockchain developers, validators, and infrastructure teams building on Sui who need to understand the full stack from consensus mechanics to smart contract execution. Also relevant for teams evaluating or contributing to Move language tooling, since Sui maintains a complete fork of the Move compiler and runtime under external-crates/move/.

Production-ready with active maintenance. The repo shows 40+ million lines of Rust code with comprehensive CI/CD workflows (.github/workflows/ contains bridge, cargo-llvm-cov, docs, labeler, and external tests), automated release processes, and a robust code organization with workspace configuration (.cargo/config.toml, .config/hakari.toml for build optimization). Recent commits, integration testing infrastructure, and dependabot automation indicate this is a mature, well-maintained blockchain platform in active development.

High operational complexity: Sui requires understanding distributed consensus patterns, Move language semantics, and the full validator stack. The monorepo spans 40M+ Rust lines with deep interdependencies; breaking changes to protocol or Move semantics could cascade across the entire ecosystem. Dependencies include vendored Move compiler code (external-crates/move/) which adds maintenance burden, and the reliance on Narwhal consensus and Authority aggregation patterns means infrastructure changes are non-trivial.

Active development with focus on protocol stability, Move tooling improvements, and bridge/interoperability (bridge.yml workflow present). The .claude/skills/ directory with cherry-pick, protocol-config, send-pr, and simtest-debug indicates ongoing developer experience improvements. Automated workflows for docs generation (docs-ci.yml), IDE testing (ide-tests.yml), and code coverage (cargo-llvm-cov.yml) show continuous investment in test infrastructure and documentation quality.

Clone the repo: git clone https://github.com/MystenLabs/sui.git && cd sui. Install Rust via rustup (Sui is a pure Rust project). Build the project: cargo build --release (uses workspace resolver 2). For development: cargo build for faster iteration. The .cargo/config.toml and .config/nextest.toml files pre-configure the build environment. No Node.js setup required for core; TypeScript is used only for RPC clients and tooling (under sdk/ directories, not shown in top-level file list).

Daily commands: Build: cargo build --release (full binary). Dev environment: cargo build then run locally via ./target/debug/sui CLI or sui start (if configured). To start a local test network with validators and fullnodes, use test infrastructure under crates/sui-test-transaction-checker/ and related integration test frameworks. The .github/workflows/external.yml suggests a sui start command exists for spinning up local test environment.

• Cargo.toml — Root workspace manifest defining all Sui crates, dependencies, and workspace configuration—essential to understand the project structure and build system.
• .github/workflows/rust.yml — Primary CI/CD pipeline for Rust builds and tests; contributors must understand how code is validated before merge.
• CONTRIBUTING.md — Contribution guidelines and development workflow; mandatory reading for all contributors before submitting PRs.
• .github/CODEOWNERS — Defines code ownership and review requirements per module; critical for understanding approval workflows and module responsibilities.
• .cargo/config.toml — Cargo configuration for build settings, rustflags, and optimization profiles; affects how all code is compiled and tested.
• README.md — High-level overview of Sui's architecture, purpose, and key features; foundational context for all development work.
• .github/PULL_REQUEST_TEMPLATE.md — PR submission template enforcing documentation and testing standards; sets expectations for all code contributions.

Add a New Move Smart Contract Module

1. Create a new Move package directory following the naming convention used in examples/ and bridge/ (examples/tic-tac-toe/)
2. Define module source files (*.move) in the sources/ directory (examples/tic-tac-toe/Move.toml)
3. Add Move.toml manifest with package dependencies and addresses (examples/tic-tac-toe/Move.toml)
4. Create rust-client wrapper in the same package directory to interact with deployed contracts (examples/tic-tac-toe/cli)

Add a New CI/CD Workflow

1. Create a new YAML workflow file in .github/workflows/ following the naming pattern (e.g., my-check.yml) (.github/workflows/rust.yml)
2. Reference common GitHub Actions from .github/actions/ such as setup-sccache for build optimization (.github/actions/setup-sccache/action.yml)
3. Use cargo test or nextest for test execution via .config/nextest.toml configuration (.config/nextest.toml)
4. Add labeling rules in .github/labeler.yml to auto-tag PRs triggered by the workflow (.github/labeler.yml)

Add a New Indexer or Custom Integration

1. Create a new project directory under examples/rust/ following the pattern (e.g., my-custom-indexer/) (examples/rust/basic-sui-indexer)
2. Define Cargo.toml with dependencies on Sui RPC client and data processing libraries (examples/rust/basic-sui-indexer)
3. Implement indexer logic to subscribe to on-chain events via JSON-RPC or direct node connection (examples/rust/clickhouse-sui-indexer)
4. Add integration tests in the tests/ directory and reference in .github/workflows/ for automated validation (.github/workflows/ci-docs.yml)

Add a New Bridge Contract Component

1. Create a new Solidity contract file in bridge/evm/contracts/ (e.g., MyBridgeComponent.sol) (bridge/evm/contracts/BridgeCommittee.sol)
2. Define the contract interface in bridge/evm/contracts/interfaces/ (e.g., IMyBridgeComponent.sol) (bridge/evm/contracts/interfaces/IBridgeCommittee.sol)
3. Integrate with existing bridge infrastructure via BridgeConfig or BridgeLimiter for initialization (bridge/evm/contracts/BridgeConfig.sol)
4. Add unit tests and update bridge/evm/.env.example with new configuration parameters (bridge/evm/.env.example)

• Rust + Move Language — Rust provides memory safety and performance for the node implementation; Move ensures smart contract safety and asset-oriented programming model.
• Cargo workspace with monorepo structure — Enables unified dependency management, consistent versioning, and atomic releases across protocol, consensus, and client libraries.
• JSON-RPC via external-crates/move/crates/jsonrpc — Standard interface for external client communication and third-party dApp integration without exposing internal node complexity.
• GitHub Actions CI/CD with sccache — Enables hermetic, reproducible builds; sccache distributes compilation cache across workers to reduce build time.
• Solidity smart contracts for EVM bridge (bridge/evm/) — Allows cross-chain asset transfers by deploying trustless bridge contracts on Ethereum and other EVM chains.

• Monorepo with 600+ files and heavy Cargo.lock

  • Why: Atomic versioning and dependency coherence across protocol layers simplify release coordination.
  • Consequence: Slower CI times and larger initial clone; mitigated by sccache and incremental compilation.

• Move VM as primary smart contract layer instead of EVM-compatible bytecode

  • Why: Move's asset-oriented model and static type system prevent re-entrancy and other common vulnerabilities.
  • Consequence: Requires developers to learn a new language; offset by superior security and developer experience.

• Bytecode verifier with fuzzing harness (bytecode-verifier-libfuzzer)

  • Why: Catches edge-case bugs in bytecode verification before they reach mainnet.
  • Consequence: Adds complexity to test suite and CI time; critical for protocol safety.

• Bridge contracts split across Sui (Move) and EVM (Solidity) layers

  • Why: Allows native asset representation on both chains without a unified intermediate layer.
  • Consequence: Requires dual verification and testing; complexity balanced by bridging benefits.

• Ethereum Virtual Machine (EVM) compatibility—Sui uses Move, not Solidity, for primary smart contracts
• Proof-of-Work consensus—Sui uses delegated Byzantine Fault Tolerance (dBFT), not PoW
• Sharding at the protocol level—throughput scales via parallel execution of independent transactions, not explicit shards
• Backward compatibility with mainnet forks—Sui protocol changes require validator consensus, not hard forks

Move compiler fork isolation: Changes to Move semantics live in external-crates/move/, not the main crates/ tree; PRs touching Move must be aware this is a vendored fork. Narwhal consensus: The consensus layer uses Narwhal DAG ordering (not traditional Tendermint/PBFT); understanding DAG ordering is required for protocol-level changes. Object model: Sui uses object-centric state (not accounts); transactions must reference object IDs explicitly; this breaks assumptions from EVM-like chains. Authority setup: Local testing requires starting multiple Authority instances with Narwhal mempool nodes; see .github/workflows/external.yml for test setup patterns. Build optimization: First cargo build is very slow due to monorepo size; use sccache or follow .github/actions/setup-sccache/ pattern. No .env file: Sui stores network config in ~/.sui/sui_config/; creating testnet validators requires manual config generation, not env vars.

• DAG-Based Consensus (Narwhal) — Sui's core differentiator from traditional blockchains; it uses Narwhal's DAG ordering instead of linear consensus, enabling parallel transaction execution and lower latency — critical to understand for any protocol-level change
• Move Language Asset Model — Sui smart contracts are written in Move, an asset-oriented language where resources are first-class and enforced at compile time; different from EVM's account model and essential for writing safe Sui contracts
• Object-Centric State (vs. Account-Based) — Sui models blockchain state as owned objects with IDs rather than accounts with balances; enables parallel execution via object-level granularity and is foundational to transaction routing and finality
• Authority Aggregator Pattern — Clients collect signatures from Byzantine-tolerant subsets of validators via the AuthorityAggregator; understanding quorum mechanics and signature aggregation is critical for RPC and transaction finality logic
• Byzantine Fault Tolerance (BFT) with f+1 Quorum — Sui requires 2f+1 out of 3f+1 validators to finalize transactions; the math underlying quorum size and how authority aggregation handles byzantine validators is non-obvious and critical for consensus safety proofs
• Bytecode Verifier & Type Safety in Move — The Move bytecode verifier (external-crates/move/crates/move-bytecode-verifier/) enforces resource safety and type invariants at compile-time; understanding this is essential for security audits and Move language stability
• Transactional Tests Framework — Sui uses a transactional test format for Move and protocol changes (referenced via crates/sui-transactional-tests/); this is not standard Rust testing and requires learning the DSL for effective test contribution

• move-language/move — Upstream Move language repository; Sui vendored a fork in external-crates/move/, so understanding the original is important for tracking divergence
• aptos-labs/aptos-core — Sister Diem/Move-based blockchain also running Move VMs; useful for comparing design decisions on object models and consensus
• MystenLabs/walrus — Sui ecosystem project for decentralized storage integration; examples/rust/walrus-attributes-indexer/ shows Walrus integration patterns
• MystenLabs/sui-typescript-sdk — Official TypeScript SDK for Sui; referenced in RPC client architecture; essential companion for off-chain application development
• narwhals-dev/narwhals — Narwhal consensus engine that powers Sui's DAG-based ordering; understanding Narwhal mempool and DAG processing is foundational to Sui protocol

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 missing test coverage for GitHub Actions in .github/workflows

The repo has 20+ complex GitHub Actions workflows (.github/workflows/*.yml) but no validation workflow to lint, validate, or test them. Adding actionlint configuration validation and a CI job would catch YAML syntax errors and workflow issues before they break CI. This is especially valuable given the complexity of workflows like rust.yml, release.yml, and simulator-nightly.yml.

• [ ] Create .github/workflows/actionlint.yml workflow that runs actionlint on all .github/workflows/*.yml files
• [ ] Reference existing .github/actionlint.yaml config file and extend it with any missing rules
• [ ] Add workflow validation step to ensure all workflow files reference valid actions from .github/actions/
• [ ] Document the actionlint setup in CONTRIBUTING.md or similar (if it exists)

Add TypeScript/JavaScript linting to CI for examples/ and sdk/ directories

The repo has .eslintrc.js configuration but no dedicated CI workflow for linting JavaScript/TypeScript code. With TypeScript SDK examples and potential web3 tooling in the codebase, a ts-lint workflow would catch code quality issues early. The .github/actions/ts-e2e/ action exists but there's no complementary lint action.

• [ ] Create .github/workflows/ts-lint.yml that runs eslint on .eslintrc.js configured paths
• [ ] Add TypeScript compilation check (tsc --noEmit) to catch type errors
• [ ] Configure the workflow to run on TypeScript/JavaScript file changes in examples/, sdk/, and TypeScript package directories
• [ ] Add lint results as GitHub check annotations for better developer feedback

Add comprehensive protocol-config validation tests in crates/

The repo has .claude/skills/protocol-config/SKILL.md documenting protocol configuration management, but there's likely no dedicated test suite validating protocol config changes. Given Sui's protocol-critical nature, adding tests that validate config schema, migrations, and backward compatibility would prevent deployment issues.

• [ ] Locate the protocol config definition crates (likely sui-protocol-config or similar in crates/)
• [ ] Create integration tests in crates/sui-protocol-config/tests/ validating: config schema validation, version migrations, and compatibility checks
• [ ] Add property-based tests using proptest to verify config serialization/deserialization
• [ ] Add a CI job in .github/workflows/rust.yml to specifically test protocol config changes on every commit affecting that crate

• Add missing integration tests for the RPC JSON-RPC 2.0 client (crates/sui-json-rpc/src/) — compare implemented methods against Sui JSON-RPC spec and flag untested endpoints
• Expand Move bytecode verifier tests (external-crates/move/crates/move-bytecode-verifier/) by adding cases for recent Move 2.0 features like enum types; current test coverage has gaps in new syntax
• Document protocol-config changes in a dedicated guide under docs/ — the .claude/skills/protocol-config/ skill exists but no end-user guide explains how to upgrade protocol versions across validators

The Sui codebase demonstrates a well-structured approach to security with a formal bug bounty program and centralized vulnerability reporting through HackenProof. However, several areas require attention: (1) the SECURITY.md documentation appears incomplete, limiting the effectiveness of vulnerability reporting; (2) environment configuration handling lacks visible security guidelines; (3) the complex multi-workflow CI/CD architecture increases configuration management risk; (4) no visible supply chain security measures like SBOM generation are documented. The project shows good security hygiene with proper exclusions and modular organization, but should strengthen documentation, dependency tracking, and configuration management practices for a blockchain platform handling digital assets.

• Medium · Incomplete SECURITY.md - Missing Contact Information — SECURITY.md. The SECURITY.md file appears truncated and is missing the complete contact details and vulnerability disclosure procedures. The file ends abruptly with 'DO NOT include attachments or provide detail re' suggesting critical information is missing or incomplete. Fix: Complete the SECURITY.md file with full vulnerability reporting procedures, contact information, and response SLAs. Ensure the document provides clear guidance on reporting security issues.
• Medium · Environment Configuration Template Without Security Guidelines — bridge/evm/.env.example. The file '.env.example' exists in the bridge/evm directory, but there's no visible documentation on what secrets should be protected or how to manage environment variables securely in a blockchain context. Fix: Document all environment variables with clear security classifications. Add guidelines for rotating secrets and never commit actual .env files. Consider using a secrets management tool for production deployments.
• Low · Workspace Exclusions May Hide Potential Issues — Cargo.toml - [workspace] exclude section. The Cargo.toml excludes many external Move crates and examples. While necessary for workspace management, some excluded paths like 'bytecode-verifier-libfuzzer' and 'invalid-mutations' may contain security-relevant code that isn't included in primary CI/CD pipelines. Fix: Ensure excluded crates are still subject to security audits and supply chain verification. Document why each crate is excluded and verify they don't contain production-critical security code.
• Low · Multiple CI/CD Workflows - Potential Configuration Drift — .github/workflows/. The .github/workflows directory contains many specialized workflows (bridge.yml, cargo-llvm-cov.yml, release.yml, etc.). Multiple entry points increase the surface area for misconfigurations or security bypasses. Fix: Implement a centralized workflow validation system. Use workflow linting tools to ensure all CI/CD workflows follow security best practices. Document the purpose and required approvals for each workflow.
• Low · Lack of Visible SBOM or Dependency Tracking — Repository root. No Software Bill of Materials (SBOM) file or dependency audit configuration is visible in the provided file structure. For a smart contract platform handling financial assets, supply chain security is critical. Fix: Implement automated SBOM generation (using tools like cargo-sbom or cyclonedx). Include dependency audit in CI/CD pipeline with 'cargo audit' and regular security advisories review.

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

What it runs against: a local clone of MystenLabs/sui — 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 MystenLabs/sui | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch main 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 MystenLabs/sui. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/MystenLabs/sui.git
#   cd sui
#
# 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 MystenLabs/sui and re-run."
  exit 2
fi

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

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

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

# 4. Critical files exist
test -f "Cargo.toml" \\
  && ok "Cargo.toml" \\
  || miss "missing critical file: Cargo.toml"
test -f ".github/workflows/rust.yml" \\
  && ok ".github/workflows/rust.yml" \\
  || miss "missing critical file: .github/workflows/rust.yml"
test -f "CONTRIBUTING.md" \\
  && ok "CONTRIBUTING.md" \\
  || miss "missing critical file: CONTRIBUTING.md"
test -f ".github/CODEOWNERS" \\
  && ok ".github/CODEOWNERS" \\
  || miss "missing critical file: .github/CODEOWNERS"
test -f ".cargo/config.toml" \\
  && ok ".cargo/config.toml" \\
  || miss "missing critical file: .cargo/config.toml"

# 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/MystenLabs/sui"
  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.