Every accepted crosschain command must be bound to its intended destination, preserve accounted value, and have a terminal path back to progress.
The answer in 30 seconds
Yieldcoin engaged Zealynx directly through the Season 1 Audit Grants program to review Yieldcoin v2, a five-chain stablecoin yield system built by Contract Level. A ParentVault maintained accounting while ChildVaults deployed capital through Aave and Compound adapters. Chainlink CRE drove settlement and rebalancing commands, and Chainlink CCIP moved assets and messages between chains.[1][2][3]
The pivotal lesson was that asynchronous recovery is safe only when the failed operation can eventually become valid. The review found several cases where the system stored an exact retry for a condition that could never clear. It also found that a valid signed CRE report was not bound to its intended receiver and that a successful CCIP send did not prove the destination received the amount used for share accounting.[1][2]
The two-week review covered 2,610 lines of Solidity and reported 11 findings: one Critical, one High, six Medium, and three Low. The public record reports eight fixed, two mitigated, and one accepted. Nine findings were backed by executed tests, including tests against pinned deployed upstream bytecode rather than mocks.[1][2]
This is a technical engagement narrative based on the public report, public audit record, and public source repository. It does not claim exploitation, production loss, money saved, or complete security outside the reviewed revision.
The buyer decision: can an asynchronous vault always return to progress?
Yieldcoin v2 separated accounting from capital deployment. Users queued deposits and withdrawals on a parent chain. Epoch close fixed the price per share, while remote ChildVaults supplied or withdrew funds from external lending markets. CRE issued signed commands and CCIP carried value and completion messages between chains.[1][2][3]
That architecture creates a different security question from a single-chain vault:
If a remote action fails after another chain has already committed state, can the system distinguish a temporary delay from a permanently impossible operation and safely reconcile the result?
A retry mechanism is not automatically a recovery mechanism. It restores liveness only when the reason for failure can change. If the stored parameters can never become acceptable, exact replay converts a local adapter error into a protocol-wide terminal state.
The review therefore tested one connected invariant:
Every accepted crosschain command must be intended for this chain and receiver, every accounting result must match the value that actually arrived, and every asynchronous failure must have a valid terminal path back to progress.
The dangerous assumption: every failed operation is eventually replayable
The reviewed ChildVault stored failed operations for permissionless retry. This was a meaningful strength: progress did not depend on a privileged operator being available. It was also incomplete as a state machine.[1][2]
Some failures are transient:
- a temporary fee spike;
- short-lived market illiquidity;
- a dependency that becomes available later.
Others are terminal for the stored parameters:
- a one-unit deposit that an upstream market will always round to zero shares;
- an amount above a hard capacity boundary;
- a duplicated epoch message that the ParentVault has already finalized;
- a nominal transfer amount that differs permanently from what arrived.
Replaying the same operation is correct for the first category. For the second, it proves only that the system can reproduce the deadlock.
How Zealynx investigated the system
1. Follow commands across trust domains
The review traced each command from CRE signatures through the Keystone forwarder, WorkflowRouter, ChildVault, adapter, CCIP message, and ParentVault completion path. The goal was to identify not only whether a signature was valid, but what destination, chain, generation, nonce, and state transition that signature actually authorized.[1]
2. Test real dependency semantics
Several questions could not be answered safely from local mocks. The review used pinned fork state and deployed upstream behavior to test Aave share conversion, CCIP transfer semantics, and receiver execution. This mattered because a locally successful call could still produce a different economic result or a permanently rejected downstream state.[1][2]
3. Model failures by whether their preconditions can change
For every stored recovery, Zealynx asked:
- What exact condition caused the failure?
- Can time, liquidity, capacity, governance, or a later message make that condition valid?
- Does the retry alter any of those inputs?
- If not, what state transition aborts, reconciles, or reroutes the operation?
This separated temporary recovery from terminal failure instead of treating every caught revert alike.
4. Reconcile accounting to outcomes, not attempted actions
A successful send means the transport accepted a message. It does not necessarily prove the destination received the nominal amount, deposited it successfully, or reached the state assumed by share accounting. The review compared requested value, delivered value, strategy value, shares issued, and ParentVault completion state.[1][2]
The pivotal finding cluster
A signed command was valid at the wrong receiver
The Critical finding began with a valid CRE report. Keystone signatures covered the report and context, but not the caller-selected receiver. Multiple ChildVault routers accepted the same workflow identity. A signed withdrawal intended for one child could therefore be replayed through another child whose local nonce had not yet advanced past that historical epoch.[1]
The second ChildVault could withdraw assets from its currently active strategy and send an old-epoch CCIP message. The ParentVault had already made that epoch claimable, so it permanently rejected the duplicate completion. CCIP retry could repeat the delivery, but it could not make the ParentVault accept an already-finalized epoch.[1]
Verified consequence: an unprivileged caller could redirect an authentic historical command, displace assets from a later active strategy, and strand the resulting message behind a terminal ParentVault state.
Recorded resolution: reports now include a signed envelope naming the target chain and router. A report redirected to another receiver is rejected.[1][2]
One base unit could create an unrecoverable epoch
Epoch netting could reduce otherwise valid user intents to a remote deposit of one base unit of USDC. The real Aave v4 Hub rounded that amount to zero shares and rejected it. The ChildVault caught the adapter failure and stored the same one-unit deposit for recovery.[1]
The retry could never work. Aave's share conversion would not improve through waiting, while the pending recovery blocked later ChildVault work and the executing epoch blocked ParentVault progress.[1]
Verified consequence: a small, reachable net-flow boundary could stop claims, cancellations, later epochs, and rebalancing for the affected strategy.
Recorded resolution: the adapter now previews conversion and keeps unrepresentable amounts as capped, tracked assets rather than sending them into an upstream call that must reject them.[1][2]
A successful crosschain send could still underback shares
CCIP token pools can apply transfer fees. The reviewed deposit flow calculated shares from the nominal amount and treated a successful ccipSend as evidence that the requested value reached the destination. Under fee-enabled pool semantics, the destination could receive less while every external call still succeeded.[1]
That creates a silent accounting divergence: users receive shares calculated from the attempted amount, but the remote strategy receives less backing. Unlike a revert, no recovery state or failure alert exposes the mismatch.[1]
Verified consequence: existing and newly issued shares could be backed by less value than the ParentVault accounting assumed.
Recorded resolution: epoch completion now receives the delivered amount, rejects values above the expected net, and reduces epoch allocation and total shares when delivery is short.[1][2]
Before, intervention, and verified after-state
| Before the review | Zealynx intervention | Verified after-state in the public record |
|---|---|---|
| Valid CRE signatures were not bound to the intended chain and receiver | Replayed an authentic report across ChildVault receivers and traced the resulting duplicate epoch path | Signed report envelopes now identify the target chain and router; finding marked fixed |
| Every caught deposit failure became exact replay recovery | Tested the real Aave v4 zero-share boundary and proved that waiting could not change it | Unrepresentable amounts remain capped and tracked rather than entering impossible recovery; finding marked fixed |
| Share accounting used the nominal CCIP send amount | Traced token-pool fees through delivery, strategy deposit, and epoch completion | Completion reconciles shares to the delivered amount; finding marked fixed |
| Recovery represented both temporary and permanent failures with the same retry shape | Classified failure preconditions and tested whether retries could alter them | Eight findings fixed, two mitigated, and one accepted with its residual condition documented |
The recorded result is mixed by design. outcomeStatus: mitigated reflects the engagement-level outcome rather than implying every issue was fixed. One finding remained accepted and two were mitigated, so the page preserves that distinction.[1][2]
What crosschain vault teams can reuse
Before launching an asynchronous vault, bridge, or strategy router, test these questions:
- Destination binding: Does every signed command cover the target chain, target contract, action, and relevant generation?
- Replay domain: Is replay protection global where commands are global and local only where commands are destination-specific?
- Outcome acknowledgement: Does the source learn what the destination actually received and applied, rather than only that a message was accepted?
- Rounding boundaries: Can batching or netting produce amounts below an adapter's minimum representable unit?
- Recovery classification: Which failures are transient, terminal, or ambiguous, and how does each class exit?
- Abort semantics: Can an operation safely stand down without falsely marking the intended destination state complete?
- Rerouting: Can capital return to the previous strategy or move elsewhere when the chosen target becomes permanently invalid?
- Accounting reconciliation: Are shares, liabilities, and price-per-share updated from delivered value rather than requested value?
- Dependency drift: Can an upstream pool, cap, exchange rate, or fee configuration change the meaning of a previously valid operation?
- Fork evidence: Which assumptions require testing against deployed upstream bytecode and live configuration instead of mocks?
The transferable lesson is simple: in an asynchronous protocol, a retry is safe only when the system can explain why the same operation may succeed later. Otherwise the design needs abort, reconcile, or reroute semantics.
Impact and evidence limits
The public report supports the mechanisms, severity classifications, tests, and recorded remediation statuses summarized here. It also documents the reviewed commit, scope, exclusions, and mitigation review.[1][2]
This case study does not use Yieldcoin's future TVL, target market, or possible strategy size as money protected. It does not claim that any finding was exploited, that funds were lost, or that a specific deployment was secured. The defensible result is narrower: the engagement identified command-domain, recovery-liveness, and delivered-value accounting failures in the reviewed code, then recorded eight fixes, two mitigations, and one accepted residual risk.
Evidence and attribution
- Direct engagement: Yieldcoin engaged Zealynx through the Season 1 Zealynx Audit Grants program.[2]
- Canonical technical record: the public report documents scope, commits, findings, proof standards, recommendations, and mitigation status.[1]
- Public audit record: Zealynx's audit page summarizes the architecture, 11 findings, executed-test evidence, and final status distribution.[2]
- Client-controlled source context: Contract Level's public repository describes Yieldcoin v2 as crosschain yield infrastructure using Chainlink CRE and CCIP.[3]
- Evidence cutoff: the September 15, 2026 public report and recorded mitigation review.
Building a crosschain vault or asynchronous strategy system?
Zealynx tests whether command authorization, remote execution, recovery, and accounting preserve one coherent state machine across chains and dependencies. Explore our smart contract security audits or request a crosschain review.
Frequently asked questions
What did Zealynx audit for Yieldcoin?
Zealynx reviewed 2,610 lines of Solidity covering the ParentVault, ChildVault, epoch and CCIP libraries, WorkflowRouter, adapter registry, Aave v3 and v4 adapters, Compound v3 adapter, and YieldcoinShare token across a five-chain architecture.[1][2]
Why was receiver binding necessary if the report had valid signatures?
The signatures proved that the report came from the authorized workflow, but they did not bind the caller-selected receiver. Because multiple ChildVault routers trusted the same workflow identity, a valid report intended for one receiver could be accepted by another until the target chain and router became part of the signed envelope.[1]
Why could the one-unit recovery never succeed?
The deployed Aave v4 conversion rounded one base unit of USDC to zero shares and rejected the supply. The stored recovery retried exactly the same amount without changing the condition that caused rejection. Waiting therefore could not make the operation valid.[1]
Why was a successful CCIP send insufficient evidence?
A token pool could deduct a configured transfer fee and still complete the send successfully. The destination would receive less than the nominal amount. Share accounting therefore had to reconcile against delivered value rather than interpreting transport success as full-value delivery.[1]
Were all findings fixed?
No. The public record reports eight fixed, two mitigated, and one accepted out of 11 findings. This case study uses an engagement-level outcome of mitigated to preserve that distinction.[1][2]
How much value did the audit protect?
The public evidence does not establish a dated monetary amount directly exposed across the reviewed findings. Zealynx therefore makes no claim about TVL protected, money saved, or loss avoided.
Sources
[1] https://raw.githubusercontent.com/ZealynxSecurity/audits/main/web3/2026-09-zealynx-yieldcoin-v2.pdf - Yieldcoin v2 Crosschain Vaults security report [2] https://zealynx.io/audits/yieldcoin/crosschain-vaults-q3-2026 - Zealynx public audit record [3] https://github.com/contractlevel/yield-v2 - Yieldcoin v2 public source repository