Sets the values for Governor.name and IERC777.symbol.

Both values are immutable: they can only be set once during construction.

Returns the name of the token.

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

Returns the number of decimals used to get its user 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, unless it's overridden.

NOTE: This information is only used for display purposes: it in no way affects any of the arithmetic of the contract, including IERC20.balanceOf and IERC20.transfer.

Returns the value of tokens in existence.

Returns the value of tokens owned by account.

See IERC20.transfer.

Requirements:

• to cannot be the zero address.
• the caller must have a balance of at least value.

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

This value changes when IERC6909.approve or IERC6909.transferFrom are called.

See IERC20.approve.

NOTE: If value is the maximum uint256, the allowance is not updated on transferFrom. This is semantically equivalent to an infinite approval.

Requirements:

• spender cannot be the zero address.

See IERC20.transferFrom.

Skips emitting an IERC6909.Approval event indicating an allowance update. This is not required by the ERC. See _approve.

NOTE: Does not update the allowance if the current allowance is the maximum uint256.

Requirements:

• from and to cannot be the zero address.
• from must have a balance of at least value.
• the caller must have allowance for from's tokens of at least value.

Moves a value amount of tokens from from to to.

This internal function is equivalent to IERC6909.transfer, and can be used to e.g. implement automatic token fees, slashing mechanisms, etc.

Emits a IERC6909.Transfer event.

NOTE: This function is not virtual, ERC1155._update should be overridden instead.

Transfers a value amount of tokens from from to to, or alternatively mints (or burns) if from (or to) is the zero address. All customizations to transfers, mints, and burns should be done by overriding this function.

Emits a IERC6909.Transfer event.

Creates a value amount of tokens and assigns them to account, by transferring it from address(0). Relies on the _update mechanism

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

NOTE: This function is not virtual, ERC1155._update should be overridden instead.

Destroys a value amount of tokens from account, lowering the total supply. Relies on the _update mechanism.

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

NOTE: This function is not virtual, ERC1155._update should be overridden instead

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

This internal function is equivalent to approve, and can be used to e.g. set automatic allowances for certain subsystems, etc.

Emits an IERC6909.Approval event.

Requirements:

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

Overrides to this logic should be done to the variant with an additional bool emitEvent argument.

Variant of ERC20._approve with an optional flag to enable or disable the IERC6909.Approval event.

By default (when calling ERC20._approve) the flag is set to true. On the other hand, approval changes made by _spendAllowance during the transferFrom operation set the flag to false. This saves gas by not emitting any Approval event during transferFrom operations.

Anyone who wishes to continue emitting Approval events on thetransferFrom operation can force the flag to true using the following override:

function _approve(address owner, address spender, uint256 value, bool) internal virtual override {
    super._approve(owner, spender, value, true);
}

Requirements are the same as ERC20._approve.

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

Does not update the allowance value in case of infinite allowance. Revert if not enough allowance is available.

Does not emit an IERC6909.Approval event.

Returns the value of tokens in existence.

Returns the value of tokens owned by account.

Moves a value amount of tokens from the caller's account to to.

Returns a boolean value indicating whether the operation succeeded.

Emits a IERC6909.Transfer event.

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

This value changes when IERC6909.approve or IERC6909.transferFrom are called.

Sets a value amount of tokens as the allowance of spender over the caller's tokens.

Returns a boolean value indicating whether the operation succeeded.

that someone may use both the old and the new allowance by unfortunate transaction ordering. One possible solution to mitigate this race condition is to first reduce the spender's allowance to 0 and set the desired value afterwards: https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729

Emits an IERC6909.Approval event.

Moves a value amount of tokens from from to to using the allowance mechanism. value is then deducted from the caller's allowance.

Returns a boolean value indicating whether the operation succeeded.

Emits a IERC6909.Transfer event.

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

Note that value may be zero.

Emitted when the allowance of a spender for an owner is set by a call to IERC6909.approve. value is the new allowance.

Returns true if this contract implements the interface defined by interfaceId. See the corresponding ERC section to learn more about how these ids are created.

This function call must use less than 30 000 gas.

Moves a value amount of tokens from the caller's account to to and then calls IERC1363Receiver.onTransferReceived on to. Returns a flag that indicates if the call succeeded.

Requirements:

• The target has code (i.e. is a contract).
• The target to must implement the IERC1363Receiver interface.
• The target must return the IERC1363Receiver.onTransferReceived selector to accept the transfer.
• The internal IERC6909.transfer must succeed (returned true).

Variant of IERC1363.transferAndCall that accepts an additional data parameter with no specified format.

Moves a value amount of tokens from from to to using the allowance mechanism and then calls IERC1363Receiver.onTransferReceived on to. Returns a flag that indicates if the call succeeded.

Requirements:

• The target has code (i.e. is a contract).
• The target to must implement the IERC1363Receiver interface.
• The target must return the IERC1363Receiver.onTransferReceived selector to accept the transfer.
• The internal IERC6909.transferFrom must succeed (returned true).

Variant of IERC1363.transferFromAndCall that accepts an additional data parameter with no specified format.

Sets a value amount of tokens as the allowance of spender over the caller's tokens and then calls IERC1363Spender.onApprovalReceived on spender. Returns a flag that indicates if the call succeeded.

Requirements:

• The target has code (i.e. is a contract).
• The target spender must implement the IERC1363Spender interface.
• The target must return the IERC1363Spender.onApprovalReceived selector to accept the approval.
• The internal IERC6909.approve must succeed (returned true).

Variant of IERC1363.approveAndCall that accepts an additional data parameter with no specified format.

Indicates a failure within the IERC6909.transfer part of a transferAndCall operation.

Indicates a failure within the IERC6909.transferFrom part of a transferFromAndCall operation.

Indicates a failure within the IERC6909.approve part of a approveAndCall operation.

Destroys a value amount of tokens from the caller.

See ERC20._burn.

Destroys a value amount of tokens from account, deducting from the caller's allowance.

See ERC20._burn and ERC20.allowance.

Requirements:

• the caller must have allowance for accounts's tokens of at least value.

Sets the value of the cap. This value is immutable, it can only be set once during construction.

Returns the cap on the token's total supply.

Transfers a value amount of tokens from from to to, or alternatively mints (or burns) if from (or to) is the zero address. All customizations to transfers, mints, and burns should be done by overriding this function.

Emits a IERC6909.Transfer event.

Total supply cap has been exceeded.

The supplied cap is not a valid cap.

Returns the maximum amount of tokens available for loan.

Returns the fee applied when doing flash loans. This function calls the ERC20FlashMint._flashFee function which returns the fee applied when doing flash loans.

Returns the fee applied when doing flash loans. By default this implementation has 0 fees. This function can be overloaded to make the flash loan mechanism deflationary.

Returns the receiver address of the flash fee. By default this implementation returns the address(0) which means the fee amount will be burnt. This function can be overloaded to change the fee receiver.

Performs a flash loan. New tokens are minted and sent to the receiver, who is required to implement the IERC3156FlashBorrower interface. By the end of the flash loan, the receiver is expected to own value + fee tokens and have them approved back to the token contract itself so they can be burned.

The loan token is not valid.

The requested loan exceeds the max loan value for token.

The receiver of a flashloan is not a valid IERC3156FlashBorrower.onFlashLoan implementer.

See ERC20._update.

Requirements:

• the contract must not be paused.

Initializes the EIP712 domain separator using the name parameter, and setting version to "1".

It's a good idea to use the same name that is defined as the ERC-20 token name.

Sets value as the allowance of spender over owner's tokens, given owner's signed approval.

ordering also apply here.

Emits an IERC6909.Approval event.

Requirements:

• spender cannot be the zero address.
• deadline must be a timestamp in the future.
• v, r and s must be a valid secp256k1 signature from owner over the EIP712-formatted function arguments.
• the signature must use owner's current nonce (see ERC20Permit.nonces).

For more information on the signature format, see the relevant EIP section.

CAUTION: See Security Considerations above.

Returns the current nonce for owner. This value must be included whenever a signature is generated for ERC20Permit.permit.

Every successful call to ERC20Permit.permit increases owner's nonce by one. This prevents a signature from being used multiple times.

Returns the domain separator used in the encoding of the signature for ERC20Permit.permit, as defined by EIP712.

Permit deadline has expired.

Mismatched signature.

Maximum token supply. Defaults to type(uint208).max (2^208^ - 1).

This maximum is enforced in ERC1155._update. It limits the total supply of the token, which is otherwise a uint256, so that checkpoints can be stored in the Trace208 structure used by Votes. Increasing this value will not remove the underlying limitation, and will cause ERC1155._update to fail because of a math overflow in Votes._transferVotingUnits. An override could be used to further restrict the total supply (to a lower value) if additional logic requires it. When resolving override conflicts on this function, the minimum should be returned.

Move voting power when tokens are transferred.

Emits a IVotes.DelegateVotesChanged event.

Returns the voting units of an account.

ERC20Votes assumes tokens map to voting units 1:1 and this is not easy to change.

Get number of checkpoints for account.

Get the pos-th checkpoint for account.

Total supply cap has been exceeded, introducing a risk of votes overflowing.

Returns the address of the underlying ERC-20 token that is being wrapped.

Allow a user to deposit underlying tokens and mint the corresponding number of wrapped tokens.

Allow a user to burn a number of wrapped tokens and withdraw the corresponding number of underlying tokens.

Mint wrapped token to cover any underlyingTokens that would have been transferred by mistake or acquired from rebasing mechanisms. Internal function that can be exposed with access control if desired.

The underlying token couldn't be wrapped.

Set the underlying asset contract. This must be an ERC20-compatible contract (ERC-20 or ERC-777).

Decimals are computed by adding the decimal offset on top of the underlying asset's decimals. This "original" value is cached during construction of the vault contract. If this read operation fails (e.g., the asset has not been created yet), a default of 18 is used to represent the underlying asset's decimals.

See IERC20Metadata.decimals.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Allows an on-chain or off-chain user to simulate the effects of their redemption 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.

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.

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.

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.

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.

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

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

Deposit/mint common workflow.

Withdraw/redeem common workflow.

Attempted to deposit more assets than the max amount for receiver.

Attempted to mint more shares than the max amount for receiver.

Attempted to withdraw more assets than the max amount for receiver.

Attempted to redeem more shares than the max amount for receiver.

Returns the name of the token.

Returns the symbol of the token.

Returns the decimals places of the token.

Sets value as the allowance of spender over owner's tokens, given owner's signed approval.

ordering also apply here.

Emits an IERC6909.Approval event.

Requirements:

• spender cannot be the zero address.
• deadline must be a timestamp in the future.
• v, r and s must be a valid secp256k1 signature from owner over the EIP712-formatted function arguments.
• the signature must use owner's current nonce (see ERC20Permit.nonces).

For more information on the signature format, see the relevant EIP section.

CAUTION: See Security Considerations above.

Returns the current nonce for owner. This value must be included whenever a signature is generated for ERC20Permit.permit.

Every successful call to ERC20Permit.permit increases owner's nonce by one. This prevents a signature from being used multiple times.

Returns the domain separator used in the encoding of the signature for ERC20Permit.permit, as defined by EIP712.

Modifier to restrict access to the token bridge.

Returns true if this contract implements the interface defined by interfaceId. See the corresponding ERC section to learn more about how these ids are created.

This function call must use less than 30 000 gas.

See IERC7802.crosschainMint. Emits a IERC7802.CrosschainMint event.

See IERC7802.crosschainBurn. Emits a IERC7802.CrosschainBurn event.

Checks if the caller is a trusted token bridge. MUST revert otherwise.

Developers should implement this function using an access control mechanism that allows customizing the list of allowed senders. Consider using AccessControl or AccessManaged.

IERC6909.allowance override that includes the temporary allowance when looking up the current allowance. If adding up the persistent and the temporary allowances result in an overflow, type(uint256).max is returned.

Internal getter for the current temporary allowance that spender has over owner tokens.

Alternative to IERC6909.approve that sets a value amount of tokens as the temporary allowance of spender over the caller's tokens.

Returns a boolean value indicating whether the operation succeeded.

Requirements:

• spender cannot be the zero address.

Does NOT emit an IERC6909.Approval event.

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

This internal function is equivalent to temporaryApprove, and can be used to e.g. set automatic allowances for certain subsystems, etc.

Requirements:

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

Does NOT emit an IERC6909.Approval event.

ERC20._spendAllowance override that consumes the temporary allowance (if any) before eventually falling back to consuming the persistent allowance. NOTE: This function skips calling super._spendAllowance if the temporary allowance is enough to cover the spending.

Performs a call to IERC1363Receiver.onTransferReceived on a target address.

Requirements:

• The target has code (i.e. is a contract).
• The target to must implement the IERC1363Receiver interface.
• The target must return the IERC1363Receiver.onTransferReceived selector to accept the transfer.

Performs a call to IERC1363Spender.onApprovalReceived on a target address.

Requirements:

• The target has code (i.e. is a contract).
• The target spender must implement the IERC1363Spender interface.
• The target must return the IERC1363Spender.onApprovalReceived selector to accept the approval.

Indicates a failure with the token receiver. Used in transfers.

Indicates a failure with the token spender. Used in approvals.

Transfer value amount of token from the calling contract to to. If token returns no value, non-reverting calls are assumed to be successful.

Transfer value amount of token from from to to, spending the approval given by from to the calling contract. If token returns no value, non-reverting calls are assumed to be successful.

Variant of SafeERC20.safeTransfer that returns a bool instead of reverting if the operation is not successful.

Variant of ERC1155.safeTransferFrom that returns a bool instead of reverting if the operation is not successful.

Increase the calling contract's allowance toward spender by value. If token returns no value, non-reverting calls are assumed to be successful.

smart contract uses ERC-7674 to set temporary allowances, then the "client" smart contract should avoid using this function. Performing a SafeERC20.safeIncreaseAllowance or SafeERC20.safeDecreaseAllowance operation on a token contract that has a non-zero temporary allowance (for that particular owner-spender) will result in unexpected behavior.

Decrease the calling contract's allowance toward spender by requestedDecrease. If token returns no value, non-reverting calls are assumed to be successful.

smart contract uses ERC-7674 to set temporary allowances, then the "client" smart contract should avoid using this function. Performing a SafeERC20.safeIncreaseAllowance or SafeERC20.safeDecreaseAllowance operation on a token contract that has a non-zero temporary allowance (for that particular owner-spender) will result in unexpected behavior.

Set the calling contract's allowance toward spender to value. If token returns no value, non-reverting calls are assumed to be successful. Meant to be used with tokens that require the approval to be set to zero before setting it to a non-zero value, such as USDT.

NOTE: If the token implements ERC-7674, this function will not modify any temporary allowance. This function only sets the "standard" allowance. Any temporary allowance will remain active, in addition to the value being set here.

Performs an ERC1363 transferAndCall, with a fallback to the simple ERC20 transfer if the target has no code. This can be used to implement an ERC721-like safe transfer that rely on ERC1363 checks when targeting contracts.

Reverts if the returned value is other than true.

Performs an ERC1363 transferFromAndCall, with a fallback to the simple ERC20 transferFrom if the target has no code. This can be used to implement an ERC721-like safe transfer that rely on ERC1363 checks when targeting contracts.

Reverts if the returned value is other than true.

Performs an ERC1363 approveAndCall, with a fallback to the simple ERC20 approve if the target has no code. This can be used to implement an ERC721-like safe transfer that rely on ERC1363 checks when targeting contracts.

NOTE: When the recipient address (to) has no code (i.e. is an EOA), this function behaves as SafeERC20.forceApprove. Opposedly, when the recipient address (to) has code, this function only attempts to call ERC1363.approveAndCall once without retrying, and relies on the returned value to be true.

Reverts if the returned value is other than true.

An operation with an ERC-20 token failed.

Indicates a failed decreaseAllowance request.