Create an AI system that deeply understands smart contract logic and can answer complex questions:
- Logic Comprehension: Understand business logic and contract purpose
- Question Answering: Answer natural language questions about contract behavior
- Behavior Prediction: Predict contract behavior under various conditions
- State Machine Extraction: Extract and visualize state machines
- Dependency Analysis: Understand dependencies between contracts and external protocols
- Documentation Generation: Generate comprehensive documentation from code
- Code Summarization: Provide summaries of complex contract logic
- Comparison: Compare different contract implementations and their tradeoffs
Requirements:
- Train models on large corpus of smart contracts with documentation
- Implement natural language question answering
- Build state machine extraction and visualization
- Create dependency graph analysis
- Implement documentation generation algorithms
- Build code summarization systems
- Create contract comparison and analysis
- Implement integration with external protocol data
- Build API for programmatic access to understanding
- Create user interface for querying contracts
Acceptance Criteria:
- Answer natural language questions with 85%+ accuracy
- Extract state machines with 90% accuracy
- Generate documentation comparable to human-written docs
- Code summaries capture key functionality
- Contract comparison identifies meaningful differences
- API response time <2 seconds for typical queries
- Integration with existing ChainProof system
Difficulty: High - Requires NLP expertise, code understanding models
Maintainer Scope Upgrade
This issue is being expanded into a substantial, production-quality ChainProof enhancement. The implementation should be designed as maintainable platform work, not as a narrow proof of concept. A successful pull request must provide a cohesive user-facing capability, typed internal APIs, robust tests, documentation, and CI-safe behavior.
Expanded Objective
Build a smart-contract understanding layer that summarizes architecture, roles, flows, and risks. The feature should fit the existing monorepo architecture, reuse current scanner/report/CLI patterns where appropriate, and avoid introducing ad hoc subsystems that are difficult to test or maintain.
Required Implementation Depth
This issue is intentionally scoped to require more than 700 lines of meaningful implementation work. The line count expectation applies to purposeful source, tests, fixtures, and documentation that are necessary to deliver the feature. It must not be satisfied through generated output, lockfile churn, formatting-only changes, duplicated boilerplate, or artificial padding.
Expected work includes:
- AST/import-graph analysis for contracts, inheritance, state variables, permissions, and external integrations.
- Structured summaries for CLI, reports, and downstream AI workflows.
- Tests over single-file, inherited, proxy-style, and multi-contract fixtures.
- Public or internal types/interfaces where they clarify behavior and reduce future integration risk.
- Failure-mode handling for invalid input, missing configuration, unavailable optional dependencies, and degraded execution paths.
- Documentation updates that explain how maintainers and users should operate the new capability in local and CI environments.
Professional Quality Bar
The implementation must be production-ready and reviewable in isolation. Contributors should include clear separation between parsing, analysis, reporting, CLI/action integration, and persistence or provider code where those concerns apply. The code should follow existing ChainProof conventions, keep behavior deterministic in tests, and avoid coupling core analysis to network-only services unless explicitly optional and mocked.
Acceptance Criteria
- The delivered PR contains more than 700 meaningful lines of implementation across source, tests, fixtures, and docs, excluding generated files and lockfile-only changes.
- The feature is integrated into the relevant package entrypoints, CLI commands, report formats, GitHub Action behavior, or documentation as appropriate for this issue.
- Unit tests cover normal operation, edge cases, invalid inputs, and at least one realistic fixture or end-to-end workflow.
- Any optional external service, model provider, database, or platform integration has deterministic mocks or fallbacks so CI does not depend on secrets or network availability.
- User-facing output is documented and stable enough for downstream automation.
- Backward compatibility is preserved unless the PR explicitly documents a migration path and the maintainer approves it.
Mandatory CI and Merge Requirements
A PR resolving this issue must not be merged until all repository CI checks pass. At minimum, reviewers should verify the following from a clean checkout:
npm ci
npm run lint
npm run build --workspaces --if-present
npm run test:ci --workspace=packages/core
npm test --workspaces --if-present
npm run build --workspace=packages/core && npm run docs --workspace=packages/core
- Any package-specific tests, examples, validators, or integration checks introduced by the PR
If the PR adds a GitHub Action, report format, dashboard, persistence layer, or external integration, it must also include CI coverage or a documented local verification command for that path. Known warnings are acceptable only when they are documented and do not hide failures.
Review Expectations
Reviewers should reject PRs that only stub APIs, add superficial wrappers, omit tests for critical behavior, rely on live secrets in CI, or meet the line-count target through non-functional bulk changes. The preferred solution is a focused but complete vertical slice that leaves ChainProof more reliable, easier to operate, and easier to extend.
Create an AI system that deeply understands smart contract logic and can answer complex questions:
Requirements:
Acceptance Criteria:
Difficulty: High - Requires NLP expertise, code understanding models
Maintainer Scope Upgrade
This issue is being expanded into a substantial, production-quality ChainProof enhancement. The implementation should be designed as maintainable platform work, not as a narrow proof of concept. A successful pull request must provide a cohesive user-facing capability, typed internal APIs, robust tests, documentation, and CI-safe behavior.
Expanded Objective
Build a smart-contract understanding layer that summarizes architecture, roles, flows, and risks. The feature should fit the existing monorepo architecture, reuse current scanner/report/CLI patterns where appropriate, and avoid introducing ad hoc subsystems that are difficult to test or maintain.
Required Implementation Depth
This issue is intentionally scoped to require more than 700 lines of meaningful implementation work. The line count expectation applies to purposeful source, tests, fixtures, and documentation that are necessary to deliver the feature. It must not be satisfied through generated output, lockfile churn, formatting-only changes, duplicated boilerplate, or artificial padding.
Expected work includes:
Professional Quality Bar
The implementation must be production-ready and reviewable in isolation. Contributors should include clear separation between parsing, analysis, reporting, CLI/action integration, and persistence or provider code where those concerns apply. The code should follow existing ChainProof conventions, keep behavior deterministic in tests, and avoid coupling core analysis to network-only services unless explicitly optional and mocked.
Acceptance Criteria
Mandatory CI and Merge Requirements
A PR resolving this issue must not be merged until all repository CI checks pass. At minimum, reviewers should verify the following from a clean checkout:
npm cinpm run lintnpm run build --workspaces --if-presentnpm run test:ci --workspace=packages/corenpm test --workspaces --if-presentnpm run build --workspace=packages/core && npm run docs --workspace=packages/coreIf the PR adds a GitHub Action, report format, dashboard, persistence layer, or external integration, it must also include CI coverage or a documented local verification command for that path. Known warnings are acceptable only when they are documented and do not hide failures.
Review Expectations
Reviewers should reject PRs that only stub APIs, add superficial wrappers, omit tests for critical behavior, rely on live secrets in CI, or meet the line-count target through non-functional bulk changes. The preferred solution is a focused but complete vertical slice that leaves ChainProof more reliable, easier to operate, and easier to extend.