Build a Multi-Compiler Solidity Compatibility and Diagnostic Matrix

[Nanle-code]

Summary

Implement a production-grade a multi-compiler solidity compatibility and diagnostic matrix for StellarChainproofs/ChainProof. This issue is a complete engineering track rather than a narrow detector patch: it requires durable TypeScript architecture, integrated workflows, comprehensive validation, tests, fixtures, and documentation.

Problem statement

Contracts often target multiple compiler ranges, and vulnerabilities or AST shapes can change across Solidity releases. ChainProof needs explicit compatibility testing instead of silently assuming one parser interpretation.

Required scope

• Define a supported compiler matrix with version capabilities, syntax changes, known code-generation hazards, and detector compatibility.
• Resolve pragma constraints across imports and identify unsatisfiable, overly broad, floating, or security-sensitive version ranges.
• Compile projects against selected compatible versions through a sandboxed adapter and normalize diagnostics and artifacts.
• Compare ABI, storage layout, bytecode, warnings, and analysis findings across compiler versions.
• Add chainproof compiler inspect, matrix, compare, and audit commands with stable JSON output.
• Test old and current compiler families, nightly or unknown versions, incompatible imports, optimizer differences, timeouts, and cached compiler integrity.

Acceptance criteria

• The capability is exposed through coherent @chainproof/core APIs and appropriate CLI, server, editor, action, or plugin surfaces with stable versioned output.
• Analysis behavior is deterministic by default, bounded against adversarial input, and accompanied by precise source locations, evidence paths, assumptions, and confidence where applicable.
• Core logic is separated from transport and presentation layers and does not require external network services in CI.
• New configuration, caches, databases, manifests, or report formats are versioned and include validation, migration, and corruption handling.
• Errors preserve actionable context without leaking source, credentials, local paths, provider data, or other sensitive information.
• Tests include vulnerable and secure fixtures, false-positive controls, malformed input, boundary conditions, failure recovery, and performance safeguards.
• Public APIs and CLI behavior are documented with security assumptions, compatibility constraints, examples, and operational troubleshooting.

Required deliverables

• Production TypeScript implementation placed in the appropriate packages/core, packages/cli, packages/server, packages/vscode-extension, packages/github-action, or clearly justified new workspace package.
• Typed public interfaces, structured diagnostics, deterministic serialization, resource limits, cancellation, and recovery behavior appropriate to the feature.
• Unit, integration, CLI, adversarial, and regression tests plus vulnerable and secure Solidity fixtures or protocol test doubles.
• Documentation for users, rule authors, integrators, and maintainers, including threat model, limitations, compatibility, migration, and troubleshooting.
• A pull-request description explaining architecture, precision/recall considerations, security boundaries, performance measurements, test evidence, and follow-up work.

Integration boundaries

The implementation must not download or execute compilers without explicit configuration and checksum verification.

Avoid unrelated rewrites, placeholder detectors, hidden live-network dependencies, dead code, and changes that weaken existing rules, type safety, security controls, or test coverage.

Minimum implementation requirement

This is intentionally a substantial contributor project. A mergeable pull request must add at least 1,000 lines of meaningful production implementation code for this issue. The minimum excludes tests, documentation, comments-only changes, generated output, vendored code, Solidity fixtures, snapshots, lockfiles, formatting-only churn, and unrelated refactors. Do not pad the implementation to reach the threshold; the required behavior must justify the code through cohesive, maintainable functionality.

CI and conflict-free merge gate

A pull request must not be merged until every required CI check passes on the final commit. At minimum, contributors must preserve a green result for the repository's applicable gates:

• npm ci
• npm run lint
• npm run build
• npm run test
• npm run test:ci --workspace=packages/core
• Package-specific build and test commands for every affected workspace
• The existing ChainProof audit workflow and API documentation build when applicable

Any new workspace, command, detector, report format, plugin capability, server route, compiler adapter, or CI provider integration requires targeted automated coverage. Contributors may not disable tests, relax type or lint rules, reduce coverage, suppress legitimate failures, or alter CI merely to obtain a passing result.

The final PR branch must be updated against the target branch and have no merge conflicts. If rebasing or updating changes the final commit, all required CI checks must run again and pass before merge.

[agnesnaomiolim-cloud]

I would love to work on this issue and provide and implementation that will fully resolve it

[covenantalade]

I’d like to contribute to #76 — Build a Multi-Compiler Solidity Compatibility and Diagnostic Matrix.

My experience with Solidity development, smart-contract auditing, Foundry-based testing, and security analysis makes this issue a strong fit for my background. Compiler-version differences are particularly important for security tooling because changes in parsing, AST structure, optimizer behavior, bytecode generation, and diagnostics can directly affect whether an analysis is correct.

I would approach this by building a well-defined compiler abstraction rather than coupling ChainProof to individual compiler versions. The implementation would include:

• A typed compiler capability matrix covering supported Solidity versions, syntax changes, known compatibility considerations, and detector support.
• Pragma resolution across the complete import graph, including detection of conflicting, unsatisfiable, floating, and security-sensitive version constraints.
• Sandboxed compiler adapters with bounded execution, deterministic diagnostics, and normalized artifacts.
• Cross-version comparison of ABI, storage layouts, bytecode, compiler warnings, and ChainProof analysis findings.
• Stable CLI workflows for chainproof compiler inspect, matrix, compare, and audit.
• Integrity verification for compiler binaries, with explicit configuration and checksum validation before any compiler is executed.
• Caching designed around verified compiler artifacts rather than trusting arbitrary local or downloaded binaries.
• Regression fixtures covering older compiler families, optimizer variations, incompatible imports, unknown/nightly versions, timeouts, malformed configurations, and compiler-cache corruption.

I’m particularly interested in the security boundary around compiler execution. Compiler binaries should never be implicitly downloaded or executed, and failures should provide actionable diagnostics without leaking local paths, source contents, credentials, or other sensitive information.

For testing, I would keep the matrix deterministic through pinned fixtures and controlled compiler adapters where possible, while separating compiler execution from the core comparison and diagnostic logic. I’ll also ensure that differences between compiler versions are represented explicitly rather than incorrectly treating every diagnostic or artifact difference as a vulnerability.

I’m comfortable working within the existing TypeScript workspace architecture and will preserve the current ChainProof analysis behavior while adding the compatibility layer incrementally. I’ll maintain coverage across unit, integration, CLI, adversarial, and regression cases and ensure all applicable CI, audit, and documentation checks remain green.

I’d be glad to take this on and build the compiler matrix as reliable infrastructure that ChainProof can use for security analysis across real-world Solidity projects and compiler ranges.

[grantfox-oss]

🦊 GrantFox — @covenantalade has been assigned to this issue as part of the Third Campaign campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #76)
2. Your PR will be reviewed by the StellarChainproof maintainers

Good luck! Track your progress on GrantFox.

[grantfox-oss]

🎉 This issue has been marked as completed on GrantFox as part of the Third Campaign campaign!

@covenantalade's PR #113 was approved and merged by @Nanle-code.

🏆 @covenantalade: You earned 35 FoxPoints for this contribution! Your current tier: Explorer (389 total points). Track your full progress on GrantFox.

👏 Great work, @covenantalade! Keep contributing to StellarChainproof.