git.stevedylan.dev

contracts/lib/forge-std/src/interfaces/IERC7575.sol 12.3 K raw

// SPDX-License-Identifier: MIT
pragma solidity >=0.6.2;

import {IERC165} from "./IERC165.sol";

/// @dev Interface of the ERC7575 "Multi-Asset ERC-4626 Vaults", as defined in
/// https://eips.ethereum.org/EIPS/eip-7575
interface IERC7575 is IERC165 {
    event Deposit(address indexed sender, address indexed owner, uint256 assets, uint256 shares);
    event Withdraw(
        address indexed sender, address indexed receiver, address indexed owner, uint256 assets, uint256 shares
    );

    /**
     * @dev Returns the address of the underlying token used for the Vault for accounting, depositing, and withdrawing.
     *
     * - MUST be an ERC-20 token contract.
     * - MUST NOT revert.
     */
    function asset() external view returns (address assetTokenAddress);

    /**
     * @dev Returns the address of the share token
     *
     * - MUST be an ERC-20 token contract.
     * - MUST NOT revert.
     */
    function share() external view returns (address shareTokenAddress);

    /**
     * @dev Returns the amount of shares that the Vault would exchange for the amount of assets provided, in an ideal
     * scenario where all the conditions are met.
     *
     * - MUST NOT be inclusive of any fees that are charged against assets in the Vault.
     * - MUST NOT show any variations depending on the caller.
     * - MUST NOT reflect slippage or other on-chain conditions, when performing the actual exchange.
     * - MUST NOT revert.
     *
     * NOTE: This calculation MAY NOT reflect the “per-user” price-per-share, and instead should reflect the
     * “average-user’s” price-per-share, meaning what the average user should expect to see when exchanging to and
     * from.
     */
    function convertToShares(uint256 assets) external view returns (uint256 shares);

    /**
     * @dev Returns the amount of assets that the Vault would exchange for the amount of shares provided, in an ideal
     * scenario where all the conditions are met.
     *
     * - MUST NOT be inclusive of any fees that are charged against assets in the Vault.
     * - MUST NOT show any variations depending on the caller.
     * - MUST NOT reflect slippage or other on-chain conditions, when performing the actual exchange.
     * - MUST NOT revert.
     *
     * NOTE: This calculation MAY NOT reflect the “per-user” price-per-share, and instead should reflect the
     * “average-user’s” price-per-share, meaning what the average user should expect to see when exchanging to and
     * from.
     */
    function convertToAssets(uint256 shares) external view returns (uint256 assets);

    /**
     * @dev Returns the total amount of the underlying asset that is “managed” by Vault.
     *
     * - SHOULD include any compounding that occurs from yield.
     * - MUST be inclusive of any fees that are charged against assets in the Vault.
     * - MUST NOT revert.
     */
    function totalAssets() external view returns (uint256 totalManagedAssets);

    /**
     * @dev Returns the maximum amount of the underlying asset that can be deposited into the Vault for the receiver,
     * through a deposit call.
     *
     * - MUST return a limited value if receiver is subject to some deposit limit.
     * - MUST return 2 ** 256 - 1 if there is no limit on the maximum amount of assets that may be deposited.
     * - MUST NOT revert.
     */
    function maxDeposit(address receiver) external view returns (uint256 maxAssets);

    /**
     * @dev Allows an on-chain or off-chain user to simulate the effects of their deposit at the current block, given
     * current on-chain conditions.
     *
     * - MUST return as close to and no more than the exact amount of Vault shares that would be minted in a deposit
     *   call in the same transaction. I.e. deposit should return the same or more shares as previewDeposit if called
     *   in the same transaction.
     * - MUST NOT account for deposit limits like those returned from maxDeposit and should always act as though the
     *   deposit would be accepted, regardless if the user has enough tokens approved, etc.
     * - MUST be inclusive of deposit fees. Integrators should be aware of the existence of deposit fees.
     * - MUST NOT revert.
     *
     * NOTE: any unfavorable discrepancy between convertToShares and previewDeposit SHOULD be considered slippage in
     * share price or some other type of condition, meaning the depositor will lose assets by depositing.
     */
    function previewDeposit(uint256 assets) external view returns (uint256 shares);

    /**
     * @dev Mints shares Vault shares to receiver by depositing exactly amount of underlying tokens.
     *
     * - MUST emit the Deposit event.
     * - MAY support an additional flow in which the underlying tokens are owned by the Vault contract before the
     *   deposit execution, and are accounted for during deposit.
     * - MUST revert if all of assets cannot be deposited (due to deposit limit being reached, slippage, the user not
     *   approving enough underlying tokens to the Vault contract, etc).
     *
     * NOTE: most implementations will require pre-approval of the Vault with the Vault’s underlying asset token.
     */
    function deposit(uint256 assets, address receiver) external returns (uint256 shares);

    /**
     * @dev Returns the maximum amount of the Vault shares that can be minted for the receiver, through a mint call.
     * - MUST return a limited value if receiver is subject to some mint limit.
     * - MUST return 2 ** 256 - 1 if there is no limit on the maximum amount of shares that may be minted.
     * - MUST NOT revert.
     */
    function maxMint(address receiver) external view returns (uint256 maxShares);

    /**
     * @dev Allows an on-chain or off-chain user to simulate the effects of their mint at the current block, given
     * current on-chain conditions.
     *
     * - MUST return as close to and no fewer than the exact amount of assets that would be deposited in a mint call
     *   in the same transaction. I.e. mint should return the same or fewer assets as previewMint if called in the
     *   same transaction.
     * - MUST NOT account for mint limits like those returned from maxMint and should always act as though the mint
     *   would be accepted, regardless if the user has enough tokens approved, etc.
     * - MUST be inclusive of deposit fees. Integrators should be aware of the existence of deposit fees.
     * - MUST NOT revert.
     *
     * NOTE: any unfavorable discrepancy between convertToAssets and previewMint SHOULD be considered slippage in
     * share price or some other type of condition, meaning the depositor will lose assets by minting.
     */
    function previewMint(uint256 shares) external view returns (uint256 assets);

    /**
     * @dev Mints exactly shares Vault shares to receiver by depositing amount of underlying tokens.
     *
     * - MUST emit the Deposit event.
     * - MAY support an additional flow in which the underlying tokens are owned by the Vault contract before the mint
     *   execution, and are accounted for during mint.
     * - MUST revert if all of shares cannot be minted (due to deposit limit being reached, slippage, the user not
     *   approving enough underlying tokens to the Vault contract, etc).
     *
     * NOTE: most implementations will require pre-approval of the Vault with the Vault’s underlying asset token.
     */
    function mint(uint256 shares, address receiver) external returns (uint256 assets);

    /**
     * @dev Returns the maximum amount of the underlying asset that can be withdrawn from the owner balance in the
     * Vault, through a withdraw call.
     *
     * - MUST return a limited value if owner is subject to some withdrawal limit or timelock.
     * - MUST NOT revert.
     */
    function maxWithdraw(address owner) external view returns (uint256 maxAssets);

    /**
     * @dev Allows an on-chain or off-chain user to simulate the effects of their withdrawal at the current block,
     * given current on-chain conditions.
     *
     * - MUST return as close to and no fewer than the exact amount of Vault shares that would be burned in a withdraw
     *   call in the same transaction. I.e. withdraw should return the same or fewer shares as previewWithdraw if
     *   called
     *   in the same transaction.
     * - MUST NOT account for withdrawal limits like those returned from maxWithdraw and should always act as though
     *   the withdrawal would be accepted, regardless if the user has enough shares, etc.
     * - MUST be inclusive of withdrawal fees. Integrators should be aware of the existence of withdrawal fees.
     * - MUST NOT revert.
     *
     * NOTE: any unfavorable discrepancy between convertToShares and previewWithdraw SHOULD be considered slippage in
     * share price or some other type of condition, meaning the depositor will lose assets by depositing.
     */
    function previewWithdraw(uint256 assets) external view returns (uint256 shares);

    /**
     * @dev Burns shares from owner and sends exactly assets of underlying tokens to receiver.
     *
     * - MUST emit the Withdraw event.
     * - MAY support an additional flow in which the underlying tokens are owned by the Vault contract before the
     *   withdraw execution, and are accounted for during withdraw.
     * - MUST revert if all of assets cannot be withdrawn (due to withdrawal limit being reached, slippage, the owner
     *   not having enough shares, etc).
     *
     * Note that some implementations will require pre-requesting to the Vault before a withdrawal may be performed.
     * Those methods should be performed separately.
     */
    function withdraw(uint256 assets, address receiver, address owner) external returns (uint256 shares);

    /**
     * @dev Returns the maximum amount of Vault shares that can be redeemed from the owner balance in the Vault,
     * through a redeem call.
     *
     * - MUST return a limited value if owner is subject to some withdrawal limit or timelock.
     * - MUST return balanceOf(owner) if owner is not subject to any withdrawal limit or timelock.
     * - MUST NOT revert.
     */
    function maxRedeem(address owner) external view returns (uint256 maxShares);

    /**
     * @dev Allows an on-chain or off-chain user to simulate the effects of their redeemption at the current block,
     * given current on-chain conditions.
     *
     * - MUST return as close to and no more than the exact amount of assets that would be withdrawn in a redeem call
     *   in the same transaction. I.e. redeem should return the same or more assets as previewRedeem if called in the
     *   same transaction.
     * - MUST NOT account for redemption limits like those returned from maxRedeem and should always act as though the
     *   redemption would be accepted, regardless if the user has enough shares, etc.
     * - MUST be inclusive of withdrawal fees. Integrators should be aware of the existence of withdrawal fees.
     * - MUST NOT revert.
     *
     * NOTE: any unfavorable discrepancy between convertToAssets and previewRedeem SHOULD be considered slippage in
     * share price or some other type of condition, meaning the depositor will lose assets by redeeming.
     */
    function previewRedeem(uint256 shares) external view returns (uint256 assets);

    /**
     * @dev Burns exactly shares from owner and sends assets of underlying tokens to receiver.
     *
     * - MUST emit the Withdraw event.
     * - MAY support an additional flow in which the underlying tokens are owned by the Vault contract before the
     *   redeem execution, and are accounted for during redeem.
     * - MUST revert if all of shares cannot be redeemed (due to withdrawal limit being reached, slippage, the owner
     *   not having enough shares, etc).
     *
     * NOTE: some implementations will require pre-requesting to the Vault before a withdrawal may be performed.
     * Those methods should be performed separately.
     */
    function redeem(uint256 shares, address receiver, address owner) external returns (uint256 assets);
}

/// @dev Interface of the ERC20 share token, as defined in
/// https://eips.ethereum.org/EIPS/eip-7575
interface IERC7575Share is IERC165 {
    event VaultUpdate(address indexed asset, address vault);

    /**
     * @dev Returns the address of the Vault for the given asset.
     *
     * @param asset the ERC-20 token to deposit with into the Vault
     */
    function vault(address asset) external view returns (address);
}

1	// SPDX-License-Identifier: MIT
2	pragma solidity >=0.6.2;
3
4	import {IERC165} from "./IERC165.sol";
5
6	/// @dev Interface of the ERC7575 "Multi-Asset ERC-4626 Vaults", as defined in
7	/// https://eips.ethereum.org/EIPS/eip-7575
8	interface IERC7575 is IERC165 {
9	event Deposit(address indexed sender, address indexed owner, uint256 assets, uint256 shares);
10	event Withdraw(
11	address indexed sender, address indexed receiver, address indexed owner, uint256 assets, uint256 shares
12	);
13
14	/**
15	* @dev Returns the address of the underlying token used for the Vault for accounting, depositing, and withdrawing.
16	*
17	* - MUST be an ERC-20 token contract.
18	* - MUST NOT revert.
19	*/
20	function asset() external view returns (address assetTokenAddress);
21
22	/**
23	* @dev Returns the address of the share token
24	*
25	* - MUST be an ERC-20 token contract.
26	* - MUST NOT revert.
27	*/
28	function share() external view returns (address shareTokenAddress);
29
30	/**
31	* @dev Returns the amount of shares that the Vault would exchange for the amount of assets provided, in an ideal
32	* scenario where all the conditions are met.
33	*
34	* - MUST NOT be inclusive of any fees that are charged against assets in the Vault.
35	* - MUST NOT show any variations depending on the caller.
36	* - MUST NOT reflect slippage or other on-chain conditions, when performing the actual exchange.
37	* - MUST NOT revert.
38	*
39	* NOTE: This calculation MAY NOT reflect the “per-user” price-per-share, and instead should reflect the
40	* “average-user’s” price-per-share, meaning what the average user should expect to see when exchanging to and
41	* from.
42	*/
43	function convertToShares(uint256 assets) external view returns (uint256 shares);
44
45	/**
46	* @dev Returns the amount of assets that the Vault would exchange for the amount of shares provided, in an ideal
47	* scenario where all the conditions are met.
48	*
49	* - MUST NOT be inclusive of any fees that are charged against assets in the Vault.
50	* - MUST NOT show any variations depending on the caller.
51	* - MUST NOT reflect slippage or other on-chain conditions, when performing the actual exchange.
52	* - MUST NOT revert.
53	*
54	* NOTE: This calculation MAY NOT reflect the “per-user” price-per-share, and instead should reflect the
55	* “average-user’s” price-per-share, meaning what the average user should expect to see when exchanging to and
56	* from.
57	*/
58	function convertToAssets(uint256 shares) external view returns (uint256 assets);
59
60	/**
61	* @dev Returns the total amount of the underlying asset that is “managed” by Vault.
62	*
63	* - SHOULD include any compounding that occurs from yield.
64	* - MUST be inclusive of any fees that are charged against assets in the Vault.
65	* - MUST NOT revert.
66	*/
67	function totalAssets() external view returns (uint256 totalManagedAssets);
68
69	/**
70	* @dev Returns the maximum amount of the underlying asset that can be deposited into the Vault for the receiver,
71	* through a deposit call.
72	*
73	* - MUST return a limited value if receiver is subject to some deposit limit.
74	* - MUST return 2 ** 256 - 1 if there is no limit on the maximum amount of assets that may be deposited.
75	* - MUST NOT revert.
76	*/
77	function maxDeposit(address receiver) external view returns (uint256 maxAssets);
78
79	/**
80	* @dev Allows an on-chain or off-chain user to simulate the effects of their deposit at the current block, given
81	* current on-chain conditions.
82	*
83	* - MUST return as close to and no more than the exact amount of Vault shares that would be minted in a deposit
84	* call in the same transaction. I.e. deposit should return the same or more shares as previewDeposit if called
85	* in the same transaction.
86	* - MUST NOT account for deposit limits like those returned from maxDeposit and should always act as though the
87	* deposit would be accepted, regardless if the user has enough tokens approved, etc.
88	* - MUST be inclusive of deposit fees. Integrators should be aware of the existence of deposit fees.
89	* - MUST NOT revert.
90	*
91	* NOTE: any unfavorable discrepancy between convertToShares and previewDeposit SHOULD be considered slippage in
92	* share price or some other type of condition, meaning the depositor will lose assets by depositing.
93	*/
94	function previewDeposit(uint256 assets) external view returns (uint256 shares);
95
96	/**
97	* @dev Mints shares Vault shares to receiver by depositing exactly amount of underlying tokens.
98	*
99	* - MUST emit the Deposit event.
100	* - MAY support an additional flow in which the underlying tokens are owned by the Vault contract before the
101	* deposit execution, and are accounted for during deposit.
102	* - MUST revert if all of assets cannot be deposited (due to deposit limit being reached, slippage, the user not
103	* approving enough underlying tokens to the Vault contract, etc).
104	*
105	* NOTE: most implementations will require pre-approval of the Vault with the Vault’s underlying asset token.
106	*/
107	function deposit(uint256 assets, address receiver) external returns (uint256 shares);
108
109	/**
110	* @dev Returns the maximum amount of the Vault shares that can be minted for the receiver, through a mint call.
111	* - MUST return a limited value if receiver is subject to some mint limit.
112	* - MUST return 2 ** 256 - 1 if there is no limit on the maximum amount of shares that may be minted.
113	* - MUST NOT revert.
114	*/
115	function maxMint(address receiver) external view returns (uint256 maxShares);
116
117	/**
118	* @dev Allows an on-chain or off-chain user to simulate the effects of their mint at the current block, given
119	* current on-chain conditions.
120	*
121	* - MUST return as close to and no fewer than the exact amount of assets that would be deposited in a mint call
122	* in the same transaction. I.e. mint should return the same or fewer assets as previewMint if called in the
123	* same transaction.
124	* - MUST NOT account for mint limits like those returned from maxMint and should always act as though the mint
125	* would be accepted, regardless if the user has enough tokens approved, etc.
126	* - MUST be inclusive of deposit fees. Integrators should be aware of the existence of deposit fees.
127	* - MUST NOT revert.
128	*
129	* NOTE: any unfavorable discrepancy between convertToAssets and previewMint SHOULD be considered slippage in
130	* share price or some other type of condition, meaning the depositor will lose assets by minting.
131	*/
132	function previewMint(uint256 shares) external view returns (uint256 assets);
133
134	/**
135	* @dev Mints exactly shares Vault shares to receiver by depositing amount of underlying tokens.
136	*
137	* - MUST emit the Deposit event.
138	* - MAY support an additional flow in which the underlying tokens are owned by the Vault contract before the mint
139	* execution, and are accounted for during mint.
140	* - MUST revert if all of shares cannot be minted (due to deposit limit being reached, slippage, the user not
141	* approving enough underlying tokens to the Vault contract, etc).
142	*
143	* NOTE: most implementations will require pre-approval of the Vault with the Vault’s underlying asset token.
144	*/
145	function mint(uint256 shares, address receiver) external returns (uint256 assets);
146
147	/**
148	* @dev Returns the maximum amount of the underlying asset that can be withdrawn from the owner balance in the
149	* Vault, through a withdraw call.
150	*
151	* - MUST return a limited value if owner is subject to some withdrawal limit or timelock.
152	* - MUST NOT revert.
153	*/
154	function maxWithdraw(address owner) external view returns (uint256 maxAssets);
155
156	/**
157	* @dev Allows an on-chain or off-chain user to simulate the effects of their withdrawal at the current block,
158	* given current on-chain conditions.
159	*
160	* - MUST return as close to and no fewer than the exact amount of Vault shares that would be burned in a withdraw
161	* call in the same transaction. I.e. withdraw should return the same or fewer shares as previewWithdraw if
162	* called
163	* in the same transaction.
164	* - MUST NOT account for withdrawal limits like those returned from maxWithdraw and should always act as though
165	* the withdrawal would be accepted, regardless if the user has enough shares, etc.
166	* - MUST be inclusive of withdrawal fees. Integrators should be aware of the existence of withdrawal fees.
167	* - MUST NOT revert.
168	*
169	* NOTE: any unfavorable discrepancy between convertToShares and previewWithdraw SHOULD be considered slippage in
170	* share price or some other type of condition, meaning the depositor will lose assets by depositing.
171	*/
172	function previewWithdraw(uint256 assets) external view returns (uint256 shares);
173
174	/**
175	* @dev Burns shares from owner and sends exactly assets of underlying tokens to receiver.
176	*
177	* - MUST emit the Withdraw event.
178	* - MAY support an additional flow in which the underlying tokens are owned by the Vault contract before the
179	* withdraw execution, and are accounted for during withdraw.
180	* - MUST revert if all of assets cannot be withdrawn (due to withdrawal limit being reached, slippage, the owner
181	* not having enough shares, etc).
182	*
183	* Note that some implementations will require pre-requesting to the Vault before a withdrawal may be performed.
184	* Those methods should be performed separately.
185	*/
186	function withdraw(uint256 assets, address receiver, address owner) external returns (uint256 shares);
187
188	/**
189	* @dev Returns the maximum amount of Vault shares that can be redeemed from the owner balance in the Vault,
190	* through a redeem call.
191	*
192	* - MUST return a limited value if owner is subject to some withdrawal limit or timelock.
193	* - MUST return balanceOf(owner) if owner is not subject to any withdrawal limit or timelock.
194	* - MUST NOT revert.
195	*/
196	function maxRedeem(address owner) external view returns (uint256 maxShares);
197
198	/**
199	* @dev Allows an on-chain or off-chain user to simulate the effects of their redeemption at the current block,
200	* given current on-chain conditions.
201	*
202	* - MUST return as close to and no more than the exact amount of assets that would be withdrawn in a redeem call
203	* in the same transaction. I.e. redeem should return the same or more assets as previewRedeem if called in the
204	* same transaction.
205	* - MUST NOT account for redemption limits like those returned from maxRedeem and should always act as though the
206	* redemption would be accepted, regardless if the user has enough shares, etc.
207	* - MUST be inclusive of withdrawal fees. Integrators should be aware of the existence of withdrawal fees.
208	* - MUST NOT revert.
209	*
210	* NOTE: any unfavorable discrepancy between convertToAssets and previewRedeem SHOULD be considered slippage in
211	* share price or some other type of condition, meaning the depositor will lose assets by redeeming.
212	*/
213	function previewRedeem(uint256 shares) external view returns (uint256 assets);
214
215	/**
216	* @dev Burns exactly shares from owner and sends assets of underlying tokens to receiver.
217	*
218	* - MUST emit the Withdraw event.
219	* - MAY support an additional flow in which the underlying tokens are owned by the Vault contract before the
220	* redeem execution, and are accounted for during redeem.
221	* - MUST revert if all of shares cannot be redeemed (due to withdrawal limit being reached, slippage, the owner
222	* not having enough shares, etc).
223	*
224	* NOTE: some implementations will require pre-requesting to the Vault before a withdrawal may be performed.
225	* Those methods should be performed separately.
226	*/
227	function redeem(uint256 shares, address receiver, address owner) external returns (uint256 assets);
228	}
229
230	/// @dev Interface of the ERC20 share token, as defined in
231	/// https://eips.ethereum.org/EIPS/eip-7575
232	interface IERC7575Share is IERC165 {
233	event VaultUpdate(address indexed asset, address vault);
234
235	/**
236	* @dev Returns the address of the Vault for the given asset.
237	*
238	* @param asset the ERC-20 token to deposit with into the Vault
239	*/
240	function vault(address asset) external view returns (address);
241	}