Skip to content

Conversation

@ravinagill15
Copy link
Contributor

In this PR:

  • reverting on redeem
  • will be used for vaults that have a cooldown period which means async txs, so redemptions should be disabled
  • in the future we can implement a version of the composer that checks if the cooldown period is off before allowing redemption

@ravinagill15 ravinagill15 changed the title Deposit-only vault Deposit-only vault composer Oct 24, 2025
) VaultComposerSync(_vault, _assetOFT, _shareOFT) {}

/**
* @notice Cross-chain redemptions are disabled for this vault
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* @notice Cross-chain redemptions are disabled for this vault
* @notice Redemptions are disabled for this vault

bytes32 /*_redeemer*/,
uint256 /*_shareAmount*/
) internal pure override returns (uint256 /*assetAmount*/) {
// Disable redemption to prevent cross-chain redemptions
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// Disable redemption to prevent cross-chain redemptions
/// @dev Disable all redemptions


/**
* @notice Cross-chain redemptions are disabled for this vault
* @dev Users should interact with the vault directly for redemption
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd add a comment about redeemAndSend reverting atomically, and lzCompose calls refunding to the original chain.

@@ -0,0 +1,43 @@
// SPDX-License-Identifier: UNLICENSED
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does it have to be unlicensed? Should we make it MIT?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@TRileySchwarz thoughts?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be same as the regular vault composer

Comment on lines 19 to 25
/**
* @notice Creates a new cross-chain vault composer
* @dev Initializes the composer with vault and OFT contracts for omnichain operations
* @param _vault The vault contract implementing ERC4626 for deposit/redeem operations
* @param _assetOFT The OFT contract for cross-chain asset transfers
* @param _shareOFT The OFT contract for cross-chain share transfers
*/
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also super nit.

I would stick to the VaultComposerSync NatSpec comment.

    /**
     * @notice Initializes the VaultComposerSyncDepositOnly contract with vault and OFT token addresses
     * @param _vault The address of the ERC4626 vault contract
     * @param _assetOFT The address of the asset OFT (Omnichain Fungible Token) contract
     * @param _shareOFT The address of the share OFT contract (must be an adapter)
     *
     * Requirements:
     * - Share token must be the vault itself
     * - Asset token should match the vault's underlying asset (overridable behavior)
     * - Share OFT must be an adapter (approvalRequired() returns true)
     */

Again, I'm ok with this as is.

@ravinagill15 ravinagill15 requested a review from tinom9 October 24, 2025 01:33
@ravinagill15 ravinagill15 requested a review from lzErfan October 24, 2025 03:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants