I Thought My Cross-Chain Vault Shares Vanished -Turns Out They Were Just in a Hurry to Bridge

A 6-hour LayerZero + ERC-4626 debugging meltdown: I blamed the bridge, cursed the mocks, drank way too much coffee… only to realize my composer was doing its job perfectly.

I was building YieldZero — my little cross-chain vault dream powered by ERC-4626 + LayerZero OFTs.

The flow felt clean and obvious:

1. User sends assets from Ethereum
2. Arbitrum composer grabs them
3. Vault mints shares straight to the composer
4. Shares immediately fly back to the user on Ethereum

Test runs. Logs look pristine:

• Assets land in the vault
• totalSupply jumps exactly 1e18
• Deposit event pops with the right receiver
• No reverts. No weird gas. Nothing.

Then I check:

1
vault.balanceOf(composer)

Zero.

Not “close enough.” Not dust. Stone-cold, infuriating zero.

My brain went straight to DEFCON 1:

“Bridge ate my tokens. LayerZero bug. Mock endpoint lying. Time to open GitHub issues and cry.”

Six hours, four coffees, and one minor existential crisis later -staring at traces and OpenZeppelin source -the penny finally dropped:

The shares didn’t vanish.

They were minted perfectly… then immediately yeeted cross-chain.

That’s literally the whole design.

Here’s the messy war story, why my test lied to my face, and the one lesson worth tattooing on my arm.

The Moment Everything Felt Broken

Test output:

1
Vault totalAssets: 1000000000000000000
2
Composer share balance: 0 ← excuse me what
3
Total supply after deposit: 1000000000000000000 ← you literally just minted?!

And the dagger:

1
[FAIL: composer should have shares: 0 != 1000000000000000000]

Assets arrived. Supply increased. Event fired.

Composer? Ghosted.

I was ready to rage-quit Solidity forever.

What Was Actually Happening (The Real Flow)

Deep in VaultComposerSync lives this little monster:

1
function handleCompose(...) external payable {
2
    // decode, checks, etc.
3
    if (_oftIn == ASSET_OFT) {
4
        _depositAndSend(_composeFrom, _amount, sendParam, tx.origin, msg.value);
5
    } else {
6
        _redeemAndSend(...);
7
    }
8
}

And _depositAndSend is brutally honest:

1
function _depositAndSend(...) internal {
2
    uint256 pre = IERC20(SHARE_ERC20).balanceOf(address(this));
3

4
    // Mint shares → directly to ourselves (the composer)
5
    shareAmount = VAULT.deposit(_assetAmount, address(this));
6

7
    uint256 post = IERC20(SHARE_ERC20).balanceOf(address(this));
8
    uint256 shares = post - pre;
9

10
    _assertSlippage(shares, _sendParam.minAmountLD);
11

12
    // Pack the freshly minted babies
13
    _sendParam.amountLD = shares;
14
    _sendParam.minAmountLD = 0;
15

16
    // And… poof - off to destination chain
17
    _send(SHARE_OFT, _sendParam, _refundAddress, _msgValue);
18

19
    emit Deposited(...);
20
}

The killer line:

1
shareAmount = VAULT.deposit(_assetAmount, address(this));

Vault mints shares to the composer contract itself (address(this)).

Next breath → _send() ships them cross-chain.

Composer isn’t a vault.

It’s a temporary hot potato.

My test checked the potato after it was thrown.

Of course the balance was zero.

Why My Test Lied to My Face

This was the crime scene:

1
yieldZeroComposer_arb.lzCompose{value: ...}(...);
2

3
// ← right here the shares are already gone
4

5
assertEq(
6
    vault_arb.balanceOf(address(yieldZeroComposer_arb)),
7
    TOKENS_TO_SEND,
8
    "composer should have shares"
9
);

Wrong timing = wrong conclusion.

Better checks:

• Assert the user received shares on destination chain
• Or (debug mode) peek at composer balance before _send runs

The Side Lesson I Still Needed: super vs Explicit

Even though this wasn’t a mint bug, my original override was still risky:

1
function deposit(...) public override onlyComposer ... {
2
    shares = super.deposit(assets, receiver);  // ← blind trust
3
    emit Deposit(...);
4
}

super.deposit() delegates to the parent — which means every hook, fee skim, rebase, or redirect in the chain gets to run.

In cross-chain, yield, or composable vaults -that’s asking for trouble.

What I use now (safer, clearer):

1
function deposit(uint256 assets, address receiver)
2
    public
3
    override
4
    onlyComposer
5
    whenNotPaused
6
    returns (uint256 shares)
7
{
8
    shares = previewDeposit(assets);
9
    if (shares == 0) revert("Zero shares");
10

11
    SafeERC20.safeTransferFrom(
12
        IERC20(asset()),
13
        msg.sender,
14
        address(this),
15
        assets
16
    );
17

18
    _mint(receiver, shares);
19

20
    emit Deposit(msg.sender, receiver, assets, shares);
21
    return shares;
22
}

No hidden magic.

You see every step.

Auditors smile.

Quick Reality Check Table

Everything worked.

My mental model was just late to the party.

Quick Excalidraw sketch:

Takeaways (Steal These)

1. Custody is fleeting — middle contracts in synchronous flows hold tokens for ~1 tx.

2. Timing kills tests- one line can move your tokens before you look.

3. Avoid blind super calls in ERC-4626 — especially cross-chain.

4. Log like crazy - before & after every meaningful action.

5. Trace is truth- -vvv never gaslights you.

Ever checked a balance one line too late and thought the protocol was haunted?

Or fought a “disappearing token” bug that turned out to be intended behavior?

Drop your story in the comments — debugging horror stories are how we all get better.

Happy coding, explicit minting, and perfectly timed assertions. ☕🚀