WIP: ERC7540 by ernestognw · Pull Request #6399 · OpenZeppelin/openzeppelin-contracts

ernestognw · 2026-03-09T14:45:56Z

PR Checklist

Tests
Documentation
Changeset entry (run npx changeset add)

changeset-bot · 2026-03-09T14:46:07Z

⚠️ No Changeset found

Latest commit: 8788d2b

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

hieronx

Really like the overall setup of the contracts!

hieronx · 2026-03-18T07:55:40Z

contracts/token/ERC20/extensions/ERC7540Redeem.sol

+    /**
+     * @dev Performs a transfer in of shares. By default, it takes the shares from the owner.
+     * Used by {requestRedeem}.
+     *
+     * IMPORTANT: If overriding to burn shares immediately (instead of holding them in the vault),
+     * you must ALSO override {_fulfillRedeem} to use a snapshotted exchange rate, since the
+     * shares will no longer exist in `totalSupply()` at fulfillment time. Simply overriding
+     * {_completeSharesIn} to do nothing is not sufficient.
+     */
+    function _lockSharesIn(uint256 shares, address owner) internal virtual {
+        _update(owner, address(this), shares);
+    }
+
+    /// @dev Performs a fulfillment of a redeem request. By default, it burns the shares. Used by {_fulfillRedeem}.
+    function _completeSharesIn(uint256 shares, address /* controller */) internal virtual {
+        _burn(address(this), shares);
+    }


This is neat, nice design @ernestognw !

hieronx · 2026-03-18T07:57:08Z

contracts/token/ERC20/extensions/ERC20Vault.sol

+    /// @inheritdoc IERC20Vault
+    function asset() public view virtual returns (address);
+


My suggestion would be to just add the share() function here.

It will instantly make all ERC-4626 vaults also ERC-7575 compatible.

Suggested change

/// @inheritdoc IERC20Vault

function asset() public view virtual returns (address);

/// @inheritdoc IERC20Vault

function asset() public view virtual returns (address);

/// @inheritdoc IERC20Vault

function share() public view virtual returns (address) {

return address(this);

}

Yes, this is a good idea. I'm still debating whether it makes sense because the function might suggest a developer that if they override it with another token address, then all the share transfer logic will be externalized, when in reality, they'd need to override other functions.

I'd prefer adding the share() function once we start with 7575

hieronx · 2026-03-18T07:58:57Z

contracts/token/ERC20/extensions/ERC7540Operator.sol

+ * Users should only approve operators they fully trust with both their assets and shares.
+ * ====
+ */
+abstract contract ERC7540Operator is ERC165, ERC20Vault, IERC7540Operator {


I wonder if you could have a abstract contract OperatorControl which implements setOperator, isOperator, and supportsInterface, which is then used by both ERC7540 as well as ERC6909. The inspiration for this feature set came from ERC6909 and it's almost a one to one match.

Do you mean using ERC-7741? I think it's not a bad idea and it would abstract away the interface from ERC-6909 as well.

@arr00, do you have any thoughts on this?

I didn't mean adding full ERC-7741. Rather just moving setOperator, isOperator and supportsInterface to an abstract contract that is reused by ERC7540 and ERC6909 implementations.

hieronx · 2026-03-18T08:02:57Z

contracts/token/ERC20/extensions/ERC7540Redeem.sol

+        uint256 pendingShares = pendingRedeemRequest(requestId, controller);
+        require(shares <= pendingShares, ERC7540RedeemInsufficientPendingShares(shares, pendingShares));
+
+        uint256 assets = convertToAssets(shares);


By always using convertToAssets here, I think you limit the ability to add fees specific to one side, i.e. charging an additional fee on redeem fulfillment that does not apply to deposit fulfillment.

Would it make sense to introduce separate _redeemPrice and _depositPrice internal methods, which by default just call convertToAssets?

Yes, it does make sense! I didn't consider additional fees on redeem or deposit fulfillment where a common step to override with extra logic. The _redeemPrice and _depositPrice functions give developers a clean function to hook on.

hieronx · 2026-03-18T08:40:12Z

contracts/token/ERC20/extensions/ERC7540Redeem.sol

+        _completeSharesIn(shares, controller);
+        _setClaimableRedeem(controller, claimableAssets + assets, claimableShares + shares);
+        _setPendingRedeem(controller, pendingShares - shares);
+        return assets;


In the Centrifuge implementation we added DepositClaimable and RedeemClaimable events (https://github.com/centrifuge/protocol/blob/882b984111150b664e7a1982f80e0975ecc1975a/src/vaults/interfaces/IAsyncVault.sol#L41). These aren't standardized because not all implementations can emit these on claimable transition, but I think they are very valuable for offchain indexers, so worth considering to add.

I was hesitant on adding an event here because _completeSharesIn (in redeem) and _mint (in deposit) would emit an event themselves and it felt redundant. I guess the DepositClaimable and RedeemClaimable events allow indexing the operator and request id. Is that its main purpose?

To be clear, I like the idea of using both events as in Centrifuge's implementation, but I'm curious on your thoughts about emitting more than 1 event in this function.

You mean Transfer(from=..., to=address(0)) in _completeSharesIn (in redeem)?

I personally think that's quite opaque. There could be other reasons for burning shares in the implementing contract. So would add a specific event for the fulfillment/claimable state of shares.

ernestognw · 2026-03-25T21:59:51Z

contracts/token/ERC20/extensions/ERC7540.sol

+    /// @inheritdoc IERC4626
+    function previewWithdraw(uint256 /* assets */) public view virtual returns (uint256) {
+        revert ERC7540PreviewNotAvailable();
+    }
+
+    /// @inheritdoc IERC4626
+    function previewRedeem(uint256 /* shares */) public view virtual returns (uint256) {
+        revert ERC7540PreviewNotAvailable();
+    }


Perhaps these should go in ERC7540Redeem instead of here

ernestognw · 2026-03-25T22:00:02Z

contracts/token/ERC20/extensions/ERC7540.sol

+    function previewDeposit(uint256 /* assets */) public view virtual returns (uint256) {
+        revert ERC7540PreviewNotAvailable();
+    }
+
+    /// @inheritdoc IERC4626
+    function previewMint(uint256 /* shares */) public view virtual returns (uint256) {
+        revert ERC7540PreviewNotAvailable();
+    }


And these in ERC7540Deposit

arr00 · 2026-03-26T14:35:36Z

contracts/interfaces/IERC4626.sol

-     * - MUST return as close to and no fewer than the exact amount of assets that would be deposited in a mint call
+     * * MUST return as close to and no fewer than the exact amount of assets that would be deposited in a mint call


What's going on here?

The - bullets don't render in the docs, but * do. I just updated accordingly but it's not strictly needed for ERC-7540

The - generally renders just fine in our system?

True. After we migrated to the new engine it works. This was true for AsciiDoc

WIP: ERC7540

fde4bcc

hieronx reviewed Mar 18, 2026

View reviewed changes

ernestognw commented Mar 25, 2026

View reviewed changes

nit

d6f41b5

arr00 reviewed Mar 26, 2026

View reviewed changes

Update bullets

8788d2b

		/// @inheritdoc IERC20Vault
		function asset() public view virtual returns (address);

		* - MUST return as close to and no fewer than the exact amount of assets that would be deposited in a mint call
		* * MUST return as close to and no fewer than the exact amount of assets that would be deposited in a mint call

Conversation

ernestognw commented Mar 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Checklist

Uh oh!

changeset-bot bot commented Mar 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

⚠️ No Changeset found

Uh oh!

hieronx left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

ernestognw commented Mar 9, 2026 •

edited

Loading

changeset-bot bot commented Mar 9, 2026 •

edited

Loading