Bridge tracks nonce-consumed mapping
Concrete's assessment for RD-F-153 — scored yellow on the v1.7.0 rubric. The evidence below is the curator's reasoning for this score.
Evidence summary #
ShareDistributor.sol contains NO application-level nonce-consumed mapping. The _lzReceive() function dispatches on MSG_TYPE without any idempotency check or replay guard at the contract level. The claimedShares[user] += shares accumulator is additive — a duplicate message delivery would execute the share transfer twice. Replay protection is delegated entirely to the LZ v2 infrastructure (endpoint-level ordered nonce delivery via allowInitializePath() / nonce commit system). This is not auditable from Concrete's own contract source. While LZ v2's ordered delivery design makes duplicate delivery unlikely under normal operation, absence of application-level defence is a yellow finding per the taxonomy's requirement for contracts to track nonce-consumed mappings.
Sources #
- GitHubShareDistributor.sol — no application-level nonce-consumed mappingsrc/periphery/predeposit/ShareDistributor.sol — _lzReceive() has no nonce mapping, no replay guard; claimedShares[user] += shares is additive not idempotent; no custom nonce tracking anywhere in contractretrieved 2026-05-17
- LayerZero v2 OAppReceiver.sol — nonce ordering at infra layer onlyLayerZero-Labs/LayerZero-v2 OAppReceiver.sol — allowInitializePath() implements path-level nonce ordering at the infrastructure layer (not in ShareDistributor itself)retrieved 2026-05-17
Methodology #
Determine whether the bridge inbox maintains a nonce-consumed mapping and rejects replay of used nonces.
See the full factor methodology and distribution across all protocols →