Repository navigation
Implement External Call Return-Value and Returndata Safety Analysis #81
Description
Summary
Implement a production-grade external call return-value and returndata safety analysis 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
Low-level calls and non-standard tokens can fail silently, return malformed data, or trigger unsafe decoding paths that are missed by simple call-name checks.
Required scope
- Model call, callcode, delegatecall, staticcall, send, transfer, and interface-call success and returndata flows.
- Detect ignored success flags, overwritten results, unchecked boolean token returns, unsafe ABI decoding, stale returndata, and partial batch failures.
- Recognize SafeERC20-style wrappers, Address utilities, explicit bubbling, try/catch, and validated assembly patterns.
- Trace failure handling through internal wrappers and modifiers to the final state-changing effect.
- Merge equivalent Slither findings while preserving richer ChainProof evidence and stable identities.
- Test no-return and false-return tokens, malformed returndata, proxy calls, assembly wrappers, multicalls, optional failures, and guarded patterns.
Acceptance criteria
- The capability is exposed through coherent
@chainproof/coreAPIs 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 rule must distinguish intentionally optional calls from security-critical ignored failures through explicit evidence.
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 cinpm run lintnpm run buildnpm run testnpm 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.
Activity
Santia2004 commentedon Aug 25, 2026
Hi! I would like to work on this issue. I have solid experience with TypeScript/JavaScript, backend architectures, and Soroban/Stellar integrations, and I have recently contributed clean, merged implementations across campaign repositories. Please feel free to assign it to me. Thanks!
tunmisedasa commentedon Aug 29, 2026
Summary
Implement a production-grade external call return-value and returndata safety analysis 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
Low-level calls and non-standard tokens can fail silently, return malformed data, or trigger unsafe decoding paths that are missed by simple call-name checks.
Required scope
Model call, callcode, delegatecall, staticcall, send, transfer, and interface-call success and returndata flows.
Detect ignored success flags, overwritten results, unchecked boolean token returns, unsafe ABI decoding, stale returndata, and partial batch failures.
Recognize SafeERC20-style wrappers, Address utilities, explicit bubbling, try/catch, and validated assembly patterns.
Trace failure handling through internal wrappers and modifiers to the final state-changing effect.
Merge equivalent Slither findings while preserving richer ChainProof evidence and stable identities.
Test no-return and false-return tokens, malformed returndata, proxy calls, assembly wrappers, multicalls, optional failures, and guarded patterns.
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 rule must distinguish intentionally optional calls from security-critical ignored failures through explicit evidence.
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.
grantfox-oss commentedon Aug 29, 2026
🦊 GrantFox — @tunmisedasa has been assigned to this issue as part of the Third Campaign campaign!
Next steps:
Closes #81)Good luck! Track your progress on GrantFox.
grantfox-oss commentedon Aug 30, 2026
🎉 This issue has been marked as completed on GrantFox as part of the Third Campaign campaign!
@tunmisedasa's PR #110 was approved and merged by @Manuelshub.
🏆 @tunmisedasa: You earned 35 FoxPoints for this contribution! Your current tier: Explorer (223 total points). Track your full progress on GrantFox.
👏 Great work, @tunmisedasa! Keep contributing to StellarChainproof.