FLOW-14: Withdraw and Close Requests Are Encoded as Native-only Exits

[liobrasil]

Severity: Informational

Files Affected

• solidity/src/FlowYieldVaultsRequests.sol

Description

createYieldVault() and depositToYieldVault() let users specify the deposited asset via tokenAddress, and this value is persisted in Request.tokenAddress.

In contrast, both exit entrypoints hardcode tokenAddress to NATIVE_FLOW when creating the request: withdrawFromYieldVault() and closeYieldVault() call _createRequest(..., NATIVE_FLOW, ...). As a result, from the EVM request data perspective, all withdrawals/closures are represented as "native FLOW exits", regardless of the original deposit asset.

This may be an intentional design decision (e.g., the Cadence side always settles exits in FlowToken / native FLOW, even if the position was funded via ERC20 on the EVM side). If so, this is fine, but the behavior is not enforced or made explicit at request creation, and it can be confusing for integrators/users who assume exit requests can specify the asset being returned.

Recommendation

Consider:

• Documenting explicitly that withdrawals/closures are always requested/settled as native FLOW (NATIVE_FLOW) if that is the intended design
• If exits are not intended to be native-only, adding a tokenAddress parameter to withdrawFromYieldVault/closeYieldVault, or persisting an "exit asset" per yieldVaultId at registration

---

Parent Issue: #15

[liobrasil]

Fixed in commit c95e149

Summary: YieldVaults now track their deposit token, and withdraw/close requests use the stored token instead of hardcoding NATIVE_FLOW.

Changes:

• Added yieldVaultTokens mapping to store the token address used when creating each YieldVault
• withdrawFromYieldVault() and closeYieldVault() now look up and use the stored token
• depositToYieldVault() validates that the deposit token matches the YieldVault's original token
• Added test coverage for ERC20 YieldVaults using the correct token on withdraw/close