Yieldcoin v2 Crosschain Vaults
Zealynx audited Yieldcoin v2, the crosschain stablecoin yield infrastructure built by Contract Level, as a Season 1 Zealynx Audit Grant engagement. A single ParentVault holds the accounting while ChildVaults on other chains hold the position, capital moves between them over Chainlink CCIP, and deposits and withdrawals are batched into epochs settled at one price per epoch by a Chainlink CRE workflow. The two-week review identified 11 issues: a Critical where a signed report could be replayed at a receiver it was never intended for and drain a later active strategy, a High where one base unit of USDC could permanently freeze the protocol, 6 Medium and 3 Low. Nine are backed by an executed test, several forking mainnet at a pinned block against deployed upstream bytecode rather than mocks. Effort concentrated on the seams - adapter integration and the parent/child boundary - which produced seven of the eleven findings. At the mitigation review, eight findings were fixed, two mitigated with documented residuals, and one accepted as a known issue.
Total findings
11
8 fixed · 2 mitigated · 1 acknowledged
Critical
01
High
01
Medium
06
Low + Info
03
02
Scope
22 files · 2,610 SLOCRepository
Initial commit
a08ecdfdb5aa
Platform
Arbitrum · Ethereum · Base · Optimism · Avalanche · Solidity
Methodology
Out of scope
Chainlink CRE Go workflow, off-chain services, deployment scripts, tests, third-party dependencies
File
evm/src/vaults/ParentVault.sol
evm/src/vaults/ChildVault.sol
evm/src/vaults/BaseVault.sol
evm/src/libraries/vaults/ParentVaultEpochLib.sol
evm/src/libraries/vaults/ParentVaultUserEpochLib.sol
evm/src/libraries/vaults/ParentVaultCcipLib.sol
evm/src/libraries/vaults/ParentVaultRebalanceLib.sol
evm/src/libraries/vaults/ParentVaultFeesLib.sol
evm/src/libraries/vaults/ParentVaultMathLib.sol
evm/src/libraries/vaults/ParentVaultConfigLib.sol
evm/src/libraries/vaults/BaseVaultCcipLib.sol
evm/src/libraries/vaults/BaseVaultConfigLib.sol
evm/src/libraries/vaults/BaseVaultStrategyLib.sol
evm/src/modules/WorkflowRouter.sol
evm/src/modules/ProtocolAdapter.sol
evm/src/modules/AdapterRegistry.sol
evm/src/modules/adapters/AaveV3Adapter.sol
evm/src/modules/adapters/AaveV4Adapter.sol
evm/src/modules/adapters/CompoundV3Adapter.sol
evm/src/token/YieldcoinShare.sol
evm/src/libraries/Types.sol
evm/src/libraries/Roles.sol
03
Findings
click any row for the full write-upSeverity
ID
Finding
Status
04
Key Findings
- A signed report could be replayed at a receiver it was never intended for. The forwarder took the receiver as a call argument rather than a signed field, so the same signatures were valid at any router. A report authorising a withdrawal on one child could be redirected to drain a different, larger position.
- One base unit of USDC could permanently freeze the protocol. Epoch netting can produce a one-unit remote deposit, which the destination lending market rejects because it converts to zero shares. The rejection was stored as replayable recovery, so every retry met the same permanent boundary while recovery exclusivity blocked all other work.
- Shares were minted against value that never arrived. A successful cross-chain send established that a message was accepted, not that the amount was delivered. Where a token pool deducted a transfer fee, existing holders absorbed the shortfall silently, with no revert, no recovery and nothing to alert on.
- Recovery treated every failure as temporary. Three findings share one design decision: typed recovery replays the original operation with its original parameters, which is correct for a fee spike or a temporarily illiquid market and unrecoverable when the obstacle can never clear.
05
Architectural Security Observations
- Recovery classified every caught failure as transient. A transfer above a lane's capacity, a supply that rounds to zero shares, and a deposit blocked by a cap the vault itself consumed each produced stored recovery that was not a path back to progress but a guarantee that the vault could not leave the state it was in.
- The right distinction already existed in the code.
ChildVault._ccipSenddeliberately hoists its validation outside thetryso that configuration errors revert instead of being stored as recovery. The line was drawn one step too early: a permanently unsatisfiable operation is a configuration error in every sense that matters. - A call that returned successfully was treated as an outcome that completed. A successful send means a message was accepted, not that value arrived.
- Guards were asymmetric between mirrored operations. A deposit floor had no withdrawal counterpart, and withdraw settlement reconciled to delivered value while deposit settlement did not.
06
Security Strengths Observed
- Permissionless recovery. Making
executeRecoverycallable by anyone means no privileged party is required to unstick funds, materially reducing dependence on operator availability. - A reasoned split between atomic and stored failure. The parent reverts atomically while the child stores recovery, justified in writing on the grounds that parent-side failures leave no cross-chain state another party is waiting on.
- Careful nonce discipline. It defeated an attack path during the engagement: a candidate finding was withdrawn because the completion function derives the nonce itself and rejects any argument that does not match.
- Bound inbound paths. Inbound messages validate the source chain before touching value, senders are bound to registered counterpart vaults, and adapters are bound to their vault and reject a mismatched asset.
- Load-bearing security documentation. The strongest encountered on a first external audit. Several of the most valuable findings exist because the team wrote down what the system assumes, including accepted residual risks, which made those assumptions testable.
07
Team & approval
Lead Auditor
Carlos (Bloqarl)
@TheBlockChainer
08
Disclaimer
This audit is not an endorsement and does not constitute investment advice. Zealynx reviewed the codebase at the commits listed in section 02 over the engagement window. Findings are limited to issues identified within that scope and do not preclude the existence of other vulnerabilities. Subsequent code changes are not covered by this report unless the engagement is explicitly extended.