External keeper/relayer not redundant
Concrete's assessment for RD-F-062 — scored yellow on the v1.7.0 rubric. The evidence below is the curator's reasoning for this score.
Evidence summary #
Concrete's pre-deposit vault system (ctStableUSDT and ctStablefrxUSD vaults on Ethereum, ~$70.5M Stable Network + ~$49.9M Berachain positions) depends on a single LayerZero message-passing path for share claim delivery. PredepostVaultOApp.sol (inherits OAppUpgradeable) calls _lzSend() to transmit claim messages to Stable Network / Berachain. ShareDistributor.sol on destination chains receives via _lzReceive() and distributes shares. No secondary messaging path confirmed. If the LayerZero endpoint becomes unavailable, fees cannot be paid, or the OApp is misconfigured, ~$120M in pre-deposit/destination assets cannot complete claim delivery. The Stable vault docs confirm the burn-and-mint claim process but do not describe fallback mechanisms.
Sources #
- GitHubShareDistributor.sol — destination-chain LayerZero receiversrc/periphery/predeposit/ShareDistributor.sol — inherits OAppUpgradeable; _lzReceive() processes MSG_TYPE_CLAIM and MSG_TYPE_BATCH_CLAIM; transfers shares to usersretrieved 2026-05-17
- Concrete Stable Vaults documentationdocs.concrete.xyz/Vaults/Stable/stable-vaults/ — 'claim your vault shares on Stable, which burns your existing vault shares on Ethereum L1 and mints the same number of new shares on the Stable Network' — confirms single-path cross-chain mechanismretrieved 2026-05-17
- PredepostVaultOApp.sol — LayerZero OApp sourcesrc/periphery/predeposit/PredepostVaultOApp.sol — inherits OAppUpgradeable; send() calls _lzSend() to LayerZero endpoint; _lzReceive() deliberately reverts (unidirectional send-only OApp)retrieved 2026-05-17
Methodology #
Determine whether the protocol depends on a single keeper or relayer (Gelato, Chainlink Automation, custom) with no redundancy or failover.
See the full factor methodology and distribution across all protocols →