ERC20

Returns the amount of tokens in existence.

Returns the amount of tokens owned by account.

Returns the remaining number of tokens that spender is allowed to spend on behalf of owner through transfer_from. This is zero by default.

This value changes when approve or transfer_from are called.

Moves amount tokens from the caller's token balance to to. Returns true on success, reverts otherwise.

Emits a Transfer event.

Moves amount tokens from sender to recipient using the allowance mechanism. amount is then deducted from the caller's allowance. Returns true on success, reverts otherwise.

Emits a Transfer event.

Sets amount as the allowance of spender over the caller's tokens. Returns true on success, reverts otherwise.

Emits an Approval event.

Emitted when value tokens are moved from one address (from) to another (to).

Note that value may be zero.

Emitted when the allowance of a spender for an owner is set. value is the new allowance.

Returns the name of the token.

Returns the ticker symbol of the token.

Returns the number of decimals the token uses - e.g. 8 means to divide the token amount by 100000000 to get its user-readable representation.

For example, if decimals equals 2, a balance of 505 tokens should be displayed to a user as 5.05 (505 / 10 ** 2).

Tokens usually opt for a value of 18, imitating the relationship between Ether and Wei. This is the default value returned by this function. To create a custom decimals implementation, see Customizing decimals.

This information is only used for display purposes: it in no way affects any of the arithmetic of the contract.

Sets amount as the allowance of spender over owner's tokens after validating the signature.

Returns the current nonce of owner. A nonce value must be included whenever a signature for permit call is generated.

Returns the domain separator used in generating a message hash for permit signature. The domain hashing logic follows the SNIP12 standard.

Returns the address of the underlying token used for the Vault for accounting, depositing, and withdrawing.

Requirements:

• MUST be an ERC20 token contract.
• MUST NOT panic.

Returns the total amount of the underlying asset that is "managed" by Vault.

Requirements:

• SHOULD include any compounding that occurs from yield.
• MUST be inclusive of any fees that are charged against assets in the Vault.
• MUST NOT panic.

Returns the amount of shares that the Vault would exchange for the amount of assets provided irrespective of slippage or fees.

Requirements:

• 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 panic unless due to integer overflow caused by an unreasonably large input.
• MUST round down towards 0.

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.

Returns the amount of assets that the Vault would exchange for the amount of shares provided irrespective of slippage or fees.

Requirements:

• 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 panic unless due to integer overflow caused by an unreasonably large input.
• MUST round down towards 0.

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.

Returns the maximum amount of the underlying asset that can be deposited into the Vault for receiver, through a deposit call.

Requirements:

• 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 panic.

Allows an on-chain or off-chain user to simulate the effects of their deposit at the current block, given current on-chain conditions.

Requirements:

• 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. IERC4626::deposit should return the same or more shares as preview_deposit if called in the same transaction.
• MUST NOT account for deposit limits like those returned from IERC4626::max_deposit 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 panic.

Any unfavorable discrepancy between IERC4626::convert_to_shares and preview_deposit SHOULD be considered slippage in share price or some other type of condition, meaning the depositor will lose assets by depositing.

Mints Vault shares to receiver by depositing exactly amount of assets.

Requirements:

• MUST emit the IERC4626::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 panic 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).

Most implementations will require pre-approval of the Vault with the Vault's underlying asset token.

Returns the maximum amount of the Vault shares that can be minted for the receiver, through a mint call.

Requirements:

• 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 panic.

Allows an on-chain or off-chain user to simulate the effects of their mint at the current block, given current on-chain conditions.

Requirements:

• 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. IERC4626::mint should return the same or fewer assets as preview_mint if called in the same transaction.
• MUST NOT account for mint limits like those returned from IERC4626::max_mint 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 panic.

Any unfavorable discrepancy between IERC4626::convert_to_assets and preview_mint SHOULD be considered slippage in share price or some other type of condition, meaning the depositor will lose assets by minting.

Mints exactly shares Vault shares to receiver by depositing amount of underlying tokens.

Requirements:

• MUST emit the IERC4626::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 panic 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).

Most implementations will require pre-approval of the Vault with the Vault's underlying asset token.

Returns the maximum amount of the underlying asset that can be withdrawn from the owner balance in the Vault, through a withdraw call.

Requirements:

• MUST return a limited value if owner is subject to some withdrawal limit or timelock.
• MUST NOT panic.

Allows an on-chain or off-chain user to simulate the effects of their withdrawal at the current block, given current on-chain conditions.

Requirements:

• 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. IERC4626::withdraw should return the same or fewer shares as preview_withdraw if called in the same transaction.
• MUST NOT account for withdrawal limits like those returned from IERC4626::max_withdraw 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 panic.

Any unfavorable discrepancy between IERC4626::convert_to_shares and preview_withdraw SHOULD be considered slippage in share price or some other type of condition, meaning the depositor will lose assets by depositing.

Burns shares from owner and sends exactly assets of underlying tokens to receiver.

Requirements:

• MUST emit the IERC4626::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).

Some implementations will require pre-requesting to the Vault before a withdrawal may be performed. Those methods should be performed separately.

Returns the maximum amount of Vault shares that can be redeemed from the owner balance in the Vault, through a redeem call.

Requirements:

• MUST return a limited value if owner is subject to some withdrawal limit or timelock.
• MUST return ERC20::balance_of(owner) if owner is not subject to any withdrawal limit or timelock.
• MUST NOT panic.

Allows an on-chain or off-chain user to simulate the effects of their redeemption at the current block, given current on-chain conditions.

Requirements:

• 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. IERC4626::redeem should return the same or more assets as preview_redeem if called in the same transaction.
• MUST NOT account for redemption limits like those returned from IERC4626::max_redeem 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 panic.

Any unfavorable discrepancy between IERC4626::convert_to_assets and preview_redeem SHOULD be considered slippage in share price or some other type of condition, meaning the depositor will lose assets by redeeming.

Burns exactly shares from owner and sends assets of underlying tokens to receiver.

Requirements:

• MUST emit the IERC4626::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).

Some implementations will require pre-requesting to the Vault before a withdrawal may be performed. Those methods should be performed separately.

Emitted when sender exchanges assets for shares and transfers those shares to owner.

Emitted when sender exchanges shares, owned by owner, for assets and transfers those assets to receiver.

Function executed at the beginning of the update function prior to any other logic.

Function executed at the end of the update function.

See IERC20::total_supply.

See IERC20::balance_of.

See IERC20::allowance.

See IERC20::transfer.

Requirements:

• recipient cannot be the zero address.
• The caller must have a balance of at least amount.

See IERC20::transfer_from.

Requirements:

• sender cannot be the zero address.
• sender must have a balance of at least amount.
• recipient cannot be the zero address.
• The caller must have allowance for sender's tokens of at least amount.

See IERC20::approve.

Requirements:

• spender cannot be the zero address.

See IERC20Metadata::name.

See IERC20Metadata::symbol.

See IERC20Metadata::decimals.

See IERC20::total_supply.

Supports the Cairo v0 convention of writing external methods in camelCase as discussed here.

See IERC20::balance_of.

Supports the Cairo v0 convention of writing external methods in camelCase as discussed here.

See IERC20::transfer_from.

Supports the Cairo v0 convention of writing external methods in camelCase as discussed here.

Sets amount as the allowance of spender over owner's tokens after validating the signature.

Requirements:

• owner is a deployed account contract.
• spender is not the zero address.
• deadline is not a timestamp in the past.
• signature is a valid signature that can be validated with a call to owner account.
• signature must use the current nonce of the owner.

Emits an Approval event. Every successful call increases `owner's nonce by one.

Returns the current nonce of owner. A nonce value must be included whenever a signature for permit call is generated.

Returns the domain separator used in generating a message hash for permit signature. The domain hashing logic follows the SNIP12 standard.

Returns the domain name and version used to generate the message hash for permit signature.

The returned tuple contains:

• t.0: The name used in the SNIP12Metadata implementation.
• t.1: The version used in the SNIP12Metadata implementation.

Initializes the contract by setting the token name and symbol. This should be used inside of the contract's constructor.

Creates an amount number of tokens and assigns them to recipient.

Emits a Transfer event with from being the zero address.

Requirements:

• recipient cannot be the zero address.

Destroys amount number of tokens from account.

Emits a Transfer event with to set to the zero address.

Requirements:

• account cannot be the zero address.

Transfers an amount of tokens from from to to, or alternatively mints (or burns) if from (or to) is the zero address.

This function can be extended using the ERC20HooksTrait, to add functionality before and/or after the transfer, mint, or burn.

Emits a Transfer event.

Moves amount of tokens from from to to.

This internal function does not check for access permissions but can be useful as a building block, for example to implement automatic token fees, slashing mechanisms, etc.

Emits a Transfer event.

Requirements:

• from cannot be the zero address.
• to cannot be the zero address.
• from must have a balance of at least amount.

Sets amount as the allowance of spender over owner's tokens.

This internal function does not check for access permissions but can be useful as a building block, for example to implement automatic allowances on behalf of other addresses.

Emits an Approval event.

Requirements:

• owner cannot be the zero address.
• spender cannot be the zero address.

Updates owner's allowance for spender based on spent amount.

This internal function does not update the allowance value in the case of infinite allowance.

Possibly emits an Approval event.

See IERC20::Transfer.

See IERC20::Approval.

Should match the underlying asset's decimals. The default value is 18.

Corresponds to the representational offset between UNDERLYING_DECIMALS and the vault decimals. The greater the offset, the more expensive it is for attackers to execute an inflation attack.

Validates the given implementation of the contract's configuration.

Requirements:

• UNDERLYING_DECIMALS + DECIMALS_OFFSET cannot exceed 255 (max u8).

This function is called by the contract's initializer.

Calculates the entry fee for a deposit during preview_deposit. The returned fee affects the final asset and share amounts. Fees are not transferred automatically and must be handled in the after_deposit hook: asset fees should be transferred from the vault's management to the fee recipient, while share fees should be minted to the fee recipient.

Calculates the entry fee for a mint during preview_mint. The returned fee affects the final asset and share amounts. Fees are not transferred automatically and must be handled in the after_deposit hook: asset fees should be transferred from the vault's management to the fee recipient, while share fees should be minted to the fee recipient.

Calculates the exit fee for a withdraw during preview_withdraw. The returned fee affects the final asset and share amounts. Fees are not transferred automatically and must be handled in the before_withdraw hook: asset fees should be transferred from the vault's management to the fee recipient, while share fees should be transferred from the owner to the fee recipient.

Calculates the exit fee for a redeem during preview_redeem. The returned fee affects the final asset and share amounts. Fees are not transferred automatically and must be handled in the before_withdraw hook: asset fees should be transferred from the vault's management to the fee recipient, while share fees should be transferred from the owner to the fee recipient.

The max deposit allowed.

Defaults (Option::None) to 2 ** 256 - 1.

The max mint allowed.

Defaults (Option::None) to 2 ** 256 - 1.

The max withdraw allowed.

Defaults (Option::None) to the full asset balance of owner converted from shares.

The max redeem allowed.

Defaults (Option::None) to the full asset balance of owner.

Hooks into _deposit.

Executes logic before transferring assets and minting shares. The fee is calculated via FeeConfigTrait. Assets and shares represent the actual amounts the user will spend and receive, respectively. Asset fees are included in assets; share fees are excluded from shares.

Hooks into _deposit.

Executes logic after transferring assets and minting shares. The fee is calculated via FeeConfigTrait. Assets and shares represent the actual amounts the user will spend and receive, respectively. Asset fees are included in assets; share fees are excluded from shares.

Hooks into _withdraw.

Executes logic before burning shares and transferring assets. The fee is calculated via FeeConfigTrait. Assets and shares represent the actual amounts the user will receive and spend, respectively. Asset fees are excluded from assets; share fees are included in shares.

Hooks into _withdraw.

Executes logic after burning shares and transferring assets. The fee is calculated via FeeConfigTrait. Assets and shares represent the actual amounts the user will receive and spend, respectively. Asset fees are excluded from assets; share fees are included in shares.

Returns the total amount of underlying assets under the vault's management. Used for share price calculations and determining the vault's total value.

This method should return the actual amount of assets that the vault controls and that can be used to satisfy withdrawal requests. For self-managed vaults, this is typically the vault contract's token balance. For external vaults, this should include any assets deposited in external protocols, minus any that are locked or unredeemable.

The accuracy of this method is critical for proper vault operation: - Overreporting can lead to share dilution and user losses. - Underreporting can lead to share inflation and potential economic attacks.

Transfers assets from an external address into the vault's management. Called during deposit and mint operations.

This method should handle the actual transfer of underlying assets from the from address into the vault's control. For self-managed vaults, this typically means transferring tokens to the vault contract's address. For external vaults, this might involve transferring into an external contract.

Requirements:

• MUST transfer exactly assets amount of the underlying token.
• SHOULD revert if the transfer fails or insufficient allowance/balance.

Transfers assets from the vault's management to an external address. Called during withdraw and redeem operations.

This method should handle the actual transfer of underlying assets from the vault's control to the to address. For self-managed vaults, this typically means transferring tokens from the vault contract's address. For external vaults, this might involve withdrawing from an external contract first.

Requirements:

• MUST transfer exactly assets amount of the underlying token.
• SHOULD revert if insufficient assets are available or transfer fails.

Returns the address of the underlying token used for the Vault for accounting, depositing, and withdrawing.

Returns the total amount of the underlying asset that is "managed" by Vault.

Returns the amount of shares that the Vault would exchange for the amount of assets provided irrespective of slippage or fees.

As per the EIP-4626 spec, this may panic only if there's an overflow from an unreasonably large input.

Returns the amount of assets that the Vault would exchange for the amount of shares provided irrespective of slippage or fees.

As per the EIP-4626 spec, this may panic only if there's an overflow from an unreasonably large input.

Returns the maximum amount of the underlying asset that can be deposited into the Vault for the receiver, through a deposit call.

The default max deposit value is 2 ** 256 - 1.

This can be changed in the implementing contract by defining custom logic in LimitConfigTrait::deposit_limit.

Allows an on-chain or off-chain user to simulate the effects of their deposit at the current block, given current on-chain conditions.

The default deposit preview value is the full amount of shares. This can be changed to account for fees, for example, in the implementing contract by defining custom logic in FeeConfigTrait::calculate_deposit_fee.

This method must be inclusive of entry fees to be compliant with the EIP-4626 spec.

Mints Vault shares to receiver by depositing exactly assets of underlying tokens. Returns the amount of newly-minted shares.

Requirements:

• assets is less than or equal to the max deposit amount for receiver.

Emits a Deposit event.

Returns the maximum amount of the Vault shares that can be minted for receiver through a mint call.

The default max mint value is 2 ** 256 - 1.

This can be changed in the implementing contract by defining custom logic in LimitConfigTrait::mint_limit.

Allows an on-chain or off-chain user to simulate the effects of their mint at the current block, given current on-chain conditions.

The default mint preview value is the full amount of assets. This can be changed to account for fees, for example, in the implementing contract by defining custom logic in FeeConfigTrait::calculate_mint_fee.

This method must be inclusive of entry fees to be compliant with the EIP-4626 spec.

Mints exactly Vault shares to receiver by depositing amount of underlying tokens. Returns the amount deposited assets.

Requirements:

• shares is less than or equal to the max shares amount for receiver.

Emits a Deposit event.

Returns the maximum amount of the underlying asset that can be withdrawn from the owner balance in the Vault, through a withdraw call.

The default max withdraw value is the full balance of assets for owner (converted from shares). This can be changed in the implementing contract by defining custom logic in LimitConfigTrait::withdraw_limit.

With customized limits, the maximum withdraw amount will either be the custom limit itself or owner's total asset balance, whichever value is less.

Allows an on-chain or off-chain user to simulate the effects of their withdrawal at the current block, given current on-chain conditions.

The default withdraw preview value is the full amount of shares. This can be changed to account for fees, for example, in the implementing contract by defining custom logic in FeeConfigTrait::calculate_withdraw_fee.

This method must be inclusive of exit fees to be compliant with the EIP-4626 spec.

Burns shares from owner and sends exactly assets of underlying tokens to receiver.

Requirements:

• assets is less than or equal to the max withdraw amount of owner.

Emits a Withdraw event.

Returns the maximum amount of Vault shares that can be redeemed from the owner balance in the Vault, through a redeem call.

The default max redeem value is the full balance of assets for owner. This can be changed in the implementing contract by defining custom logic in LimitConfigTrait::redeem_limit.

With customized limits, the maximum redeem amount will either be the custom limit itself or owner's total asset balance, whichever value is less.

Allows an on-chain or off-chain user to simulate the effects of their redeemption at the current block, given current on-chain conditions.

The default redeem preview value is the full amount of assets. This can be changed to account for fees, for example, in the implementing contract by defining custom logic in FeeConfigTrait::calculate_redeem_fee.

This method must be inclusive of exit fees to be compliant with the EIP-4626 spec.

Burns exactly shares from owner and sends assets of underlying tokens to receiver.

Requirements:

• shares is less than or equal to the max redeem amount of owner.

Emits a Withdraw event.

Returns the name of the token.

Returns the ticker symbol of the token, usually a shorter version of the name.

Returns the cumulative number of decimals which includes both UNDERLYING_DECIMALS and OFFSET_DECIMALS. Both of which must be defined in the ImmutableConfig inside the implementing contract.

Validates the ImmutableConfig constants and sets the asset_address to the vault. This should be set in the contract's constructor.

Requirements:

• asset_address cannot be the zero address.

Internal logic for deposit and mint.

Transfers assets from caller to the Vault contract then mints shares to receiver. Fees can be transferred in the ERC4626Hooks::after_deposit hook which is executed after assets are transferred and shares are minted.

Requirements:

• ERC20::transfer_from must return true.

Emits two ERC20::Transfer events (ERC20::mint and ERC20::transfer_from).

Emits a Deposit event.

Internal logic for withdraw and redeem.

Burns shares from owner and then transfers assets to receiver. Fees can be transferred in the ERC4626Hooks::before_withdraw hook which is executed before shares are burned and assets are transferred.

Requirements:

• ERC20::transfer must return true.

Emits two ERC20::Transfer events (ERC20::burn and ERC20::transfer).

Emits a Withdraw event.

Internal conversion function (from assets to shares) with support for rounding direction.

Internal conversion function (from shares to assets) with support for rounding direction.

Sets the name and symbol and mints fixed_supply tokens to recipient. Assigns owner as the contract owner with permissions to upgrade.

Upgrades the contract to a new implementation given by new_class_hash.

Requirements:

• The caller is the contract owner.
• new_class_hash cannot be zero.