Vault: add reentrancy-equivalent test using a malicious mock token on deduct

[greatest0fallt1me]

Description

The vault performs external USDC transfer calls in deduct, batch_deduct, withdraw, and distribute. There is no test exercising a hostile token contract that attempts to re-enter the vault during the transfer. Add a malicious mock token and assert that state effects (meta.balance) cannot be corrupted by re-entry.

Requirements and Context

• Implement a mock token whose transfer calls back into CalloraVault::deduct.
• Assert the re-entrant call either fails (auth/pause) or cannot double-spend balance.
• Cover both single deduct and batch_deduct.
• Must be secure, tested, and documented
• Should be efficient and easy to review

Suggested Execution

1. Fork the repo and create a branch

   git checkout -b task/vault-reentrancy-mock-token

2. Implement changes
   • contracts/vault/src/test.rs — malicious token mock + re-entry tests
3. Test and commit
   • cargo test -p callora-vault
   • Assert no balance corruption and deterministic revert
   • Include test output and notes in the PR

Example commit message

test: add reentrancy-equivalent mock token tests to vault

Acceptance Criteria

• Malicious mock token re-enters during transfer
• Balance cannot be double-spent
• Both deduct and batch_deduct covered
• Tests pass deterministically

Guidelines

• .rs under contracts/vault/src/, cargo test, /// docs, minimum 95% line coverage, no unwrap() in prod paths
• Clear documentation and inline comments
• Timeframe: 96 hours

[ChukwuemekaP1]

@ChukwuemekaP1 has applied to work on this issue as part of the Stellar Wave Program's 5th wave.

GM, my name is Paul, a full-stack developer.

I will implement a reentrancy-equivalent safety test for the vault by introducing a malicious mock token that attempts to call back into CalloraVault::deduct during an external transfer. The goal is to validate that the vault remains state-consistent under hostile contract behavior.

The test will simulate re-entry during both deduct and batch_deduct, asserting that either the call is properly rejected (via auth/pause/guard conditions) or that balance state cannot be double-spent under any execution path. I’ll explicitly verify that meta.balance remains deterministic and unchanged after the attempted re-entrant flow.

All logic will be confined to contracts/vault/src/test.rs, using a controlled mock token that triggers the re-entry attempt. The tests will ensure clean failure modes and no hidden state corruption, with full coverage of both single and batch operations.

ETA: under 48 hours.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @ChukwuemekaP1 to this issue.

[drips-wave]

Congratulations, @ChukwuemekaP1! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on June 2, 2026.

🧑‍💻 @ChukwuemekaP1: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊