Add rule B011: target chain address format validation - #893
Merged
mijinummi merged 2 commits intoJul 31, 2026
Conversation
Adds a standalone Rust crate (rules/) that parses Solidity with solang-parser and flags cross-chain outbound transfer functions that restrict their recipient parameter to a 20-byte address/address payable type instead of bytes or bytes32, which cannot safely represent non-EVM recipient addresses (Solana, Bitcoin, Cosmos, etc.). The crate is standalone, not part of any Cargo workspace, matching the existing contracts/soroban/*/Cargo.toml convention. A function is considered in-scope for the rule when its name suggests a cross-chain transfer (bridge/transfer/send/deposit/dispatch) and it has both a recipient-like parameter and a narrow uint chain-ID-like parameter, which keeps ordinary domestic functions with a "recipient" argument from being flagged. Includes test/fixtures/b011_samples.sol covering the violation case, the bytes32/bytes passing cases, and a non-cross-chain function with an address recipient param that must not be flagged, plus unit tests in rules/src/b011_address_format.rs that parse the fixture from disk and assert an exact violation count.
|
@ThatCodeBabe Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits. You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀 |
Collaborator
|
Hi, please kindly resolve conflict @ThatCodeBabe |
2 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #867
Summary
Greenfield — no
rules/crate exists in this fork (a similar-but-unrelated rule was built independently in a different contributor's fork; not present here). Standalone Rust crate atrules/, usingsolang-parser, following the same "independent crate, no shared workspace" convention ascontracts/soroban/*.bridge/transfer/send/deposit/dispatch) AND it has both a recipient-like param and a separate chain-ID-like param — then flagsaddress/address payablerecipient params (always 20 bytes, too narrow for e.g. a 32-byte Solana pubkey), passingbytes/bytes32contracts/router/BatchBridgeRouter.sol/NativeBridgeRouter.solalready usebytes32 recipientfor exactly this reason — used as grounding for a realistic fixture rather than an artificial onewithdraw(address recipient, ...)function with no chain-ID param and a non-cross-chain name is correctly left unflaggedAcceptance criteria
bytesorbytes32recipient parametersTest plan
cargo test— 6/6 passing (fixture parses; violation flagged with correct line; both safe-type cases pass; non-cross-chain case not over-flagged; exact violation count == 1)cargo build --release— cleancargo clippy --all-targets— no warnings on new code