Index

IERC1363Spender

onApprovalReceived

function onApprovalReceived(address owner, uint256 value, bytes data) external returns (bytes4)

Handle the approval of ERC1363 tokens

Any ERC1363 smart contract calls this function on the recipient after an `approve`. This function MAY throw to revert and reject the approval. Return of other than the magic value MUST result in the transaction being reverted. Note: the token contract address is always the message sender.

Name
Type
Description

owner

address

address The address which called `approveAndCall` function

value

uint256

uint256 The amount of tokens to be spent

data

bytes

bytes Additional data with no specified format

Name
Type
Description

[0]

bytes4

`bytes4(keccak256("onApprovalReceived(address,uint256,bytes)"))` unless throwing

IBErc20Token

mint

function mint(uint256 mintAmount) external returns (uint256)

Sender supplies assets into the market and receives cTokens in exchange

Accrues interest whether or not the operation succeeds, unless reverted

Name
Type
Description

mintAmount

uint256

The amount of the underlying asset to supply

Name
Type
Description

[0]

uint256

uint 0=success, otherwise a failure (see ErrorReporter.sol for details)

redeem

Sender redeems cTokens in exchange for the underlying asset

Accrues interest whether or not the operation succeeds, unless reverted

Name
Type
Description

redeemTokens

uint256

The number of cTokens to redeem into underlying

Name
Type
Description

[0]

uint256

uint 0=success, otherwise a failure (see ErrorReporter.sol for details)

redeemUnderlying

Sender redeems cTokens in exchange for a specified amount of underlying asset

Accrues interest whether or not the operation succeeds, unless reverted

Name
Type
Description

redeemAmount

uint256

The amount of underlying to redeem

Name
Type
Description

[0]

uint256

uint 0=success, otherwise a failure (see ErrorReporter.sol for details)

borrow

Sender borrows assets from the protocol to their own address

Name
Type
Description

borrowAmount

uint256

The amount of the underlying asset to borrow

Name
Type
Description

[0]

uint256

uint 0=success, otherwise a failure (see ErrorReporter.sol for details)

repayBorrow

Sender repays their own borrow

Name
Type
Description

repayAmount

uint256

The amount to repay

Name
Type
Description

[0]

uint256

uint 0=success, otherwise a failure (see ErrorReporter.sol for details)

repayBorrowBehalf

Sender repays a borrow belonging to borrower

Name
Type
Description

borrower

address

the account with the debt being payed off

repayAmount

uint256

The amount to repay

Name
Type
Description

[0]

uint256

uint 0=success, otherwise a failure (see ErrorReporter.sol for details)

liquidateBorrow

The sender liquidates the borrowers collateral. The collateral seized is transferred to the liquidator.

Name
Type
Description

borrower

address

The borrower of this cToken to be liquidated

repayAmount

uint256

The amount of the underlying borrowed asset to repay

cTokenCollateral

address

The market in which to seize collateral from the borrower

Name
Type
Description

[0]

uint256

uint 0=success, otherwise a failure (see ErrorReporter.sol for details)

balanceOf

Get the token balance of the `owner`

Name
Type
Description

owner

address

The address of the account to query

Name
Type
Description

[0]

uint256

The number of tokens owned by `owner`

accountTokens

Get the underlying balance of the `owner`

This also accrues interest in a transaction

Name
Type
Description

owner

address

The address of the account to query

Name
Type
Description

[0]

uint256

The amount of underlying owned by `owner`

Initializable

_This is a base contract to aid in writing upgradeable contracts, or any kind of contract that will be deployed behind a proxy. Since a proxied contract can't have a constructor, it's common to move constructor logic to an external initializer function, usually called `initialize`. It then becomes necessary to protect this initializer function so it can only be called once. The {initializer} modifier provided by this contract will have this effect.

TIP: To avoid leaving the proxy in an uninitialized state, the initializer function should be called as early as possible by providing the encoded function call as the `_data` argument to {ERC1967Proxy-constructor}.

CAUTION: When used with inheritance, manual care must be taken to not invoke a parent initializer twice, or to ensure that all initializers are idempotent. This is not verified automatically as constructors are by Solidity._

_initialized

Indicates that the contract has been initialized.

_initializing

Indicates that the contract is in the process of being initialized.

initializer

Modifier to protect an initializer function from being invoked twice.

ReentrancyGuard

_Contract module that helps prevent reentrant calls to a function.

Inheriting from `ReentrancyGuard` will make the {nonReentrant} modifier available, which can be applied to functions to make sure there are no nested (reentrant) calls to them.

Note that because there is a single `nonReentrant` guard, functions marked as `nonReentrant` may not call one another. This can be worked around by making those functions `private`, and then adding `external` `nonReentrant` entry points to them.

TIP: If you would like to learn more about reentrancy and alternative ways to protect against it, check out our blog post https://blog.openzeppelin.com/reentrancy-after-istanbul/[Reentrancy After Istanbul]._

_NOT_ENTERED

_ENTERED

_status

constructor

nonReentrant

Prevents a contract from calling itself, directly or indirectly. Calling a `nonReentrant` function from another `nonReentrant` function is not supported. It is possible to prevent this from happening by making the `nonReentrant` function external, and make it call a `private` function that does the actual work.

MerkleProof

_These functions deal with verification of Merkle Trees proofs.

The proofs can be generated using the JavaScript library https://github.com/miguelmota/merkletreejs[merkletreejs]. Note: the hashing algorithm should be keccak256 and pair sorting should be enabled.

See `test/utils/cryptography/MerkleProof.test.js` for some examples._

verify

Returns true if a `leaf` can be proved to be a part of a Merkle tree defined by `root`. For this, a `proof` must be provided, containing sibling hashes on the branch from the leaf to the root of the tree. Each pair of leaves and each pair of pre-images are assumed to be sorted.

Create2

_Helper to make usage of the `CREATE2` EVM opcode easier and safer. `CREATE2` can be used to compute in advance the address where a smart contract will be deployed, which allows for interesting new mechanisms known as 'counterfactual interactions'.

See the https://eips.ethereum.org/EIPS/eip-1014#motivation[EIP] for more information._

deploy

_Deploys a contract using `CREATE2`. The address where the contract will be deployed can be known in advance via {computeAddress}.

The bytecode for a contract can be obtained from Solidity with `type(contractName).creationCode`.

Requirements:

  • `bytecode` must not be empty.

  • `salt` must have not been used for `bytecode` already.

  • the factory must have a balance of at least `amount`.

  • if `amount` is non-zero, `bytecode` must have a `payable` constructor._

computeAddress

Returns the address where a contract will be stored if deployed via {deploy}. Any change in the `bytecodeHash` or `salt` will result in a new destination address.

computeAddress

Returns the address where a contract will be stored if deployed via {deploy} from a contract located at `deployer`. If `deployer` is this contract's address, returns the same value as {computeAddress}.

IUniswapV2Factory

PairCreated

feeTo

feeToSetter

getPair

allPairs

allPairsLength

createPair

setFeeTo

setFeeToSetter

MerkleProofUpgradeable

_These functions deal with verification of Merkle Trees proofs.

The proofs can be generated using the JavaScript library https://github.com/miguelmota/merkletreejs[merkletreejs]. Note: the hashing algorithm should be keccak256 and pair sorting should be enabled.

See `test/utils/cryptography/MerkleProof.test.js` for some examples._

verify

Returns true if a `leaf` can be proved to be a part of a Merkle tree defined by `root`. For this, a `proof` must be provided, containing sibling hashes on the branch from the leaf to the root of the tree. Each pair of leaves and each pair of pre-images are assumed to be sorted.

ClonesUpgradeable

_https://eips.ethereum.org/EIPS/eip-1167[EIP 1167] is a standard for deploying minimal proxy contracts, also known as "clones".

> To simply and cheaply clone contract functionality in an immutable way, this standard specifies > a minimal bytecode implementation that delegates all calls to a known, fixed address.

The library includes functions to deploy a proxy using either `create` (traditional deployment) or `create2` (salted deterministic deployment). It also includes functions to predict the addresses of clones deployed using the deterministic method.

Available since v3.4._

clone

_Deploys and returns the address of a clone that mimics the behaviour of `implementation`.

This function uses the create opcode, which should never revert._

cloneDeterministic

_Deploys and returns the address of a clone that mimics the behaviour of `implementation`.

This function uses the create2 opcode and a `salt` to deterministically deploy the clone. Using the same `implementation` and `salt` multiple time will revert, since the clones cannot be deployed twice at the same address._

predictDeterministicAddress

Computes the address of a clone deployed using {Clones-cloneDeterministic}.

predictDeterministicAddress

Computes the address of a clone deployed using {Clones-cloneDeterministic}.

PrimaryIndexToken

MODERATOR_ROLE

name

symbol

priceOracle

projectTokens

projectTokenInfo

lendingTokens

lendingTokenInfo

totalDepositedProjectToken

depositPosition

borrowPosition

totalBorrow

borrowLimit

Ratio

ProjectTokenInfo

LendingTokenInfo

DepositPosition

BorrowPosition

AddPrjToken

LoanToValueRatioSet

LiquidationThresholdFactorSet

LiquidationIncentiveSet

Deposit

Withdraw

Supply

Redeem

RedeemUnderlying

Borrow

RepayBorrow

Liquidate

initialize

onlyAdmin

onlyModerator

isProjectTokenListed

isLendingTokenListed

addProjectToken

removeProjectToken

addLendingToken

removeLendingToken

setPriceOracle

grandModerator

revokeModerator

setBorrowLimit

setProjectTokenInfo

setPausedProjectToken

setLendingTokenInfo

setPausedLendingToken

deposit

withdraw

supply

redeem

redeemUnderlying

borrow

repay

repayInternal

liquidate

updateInterestInBorrowPositions

pit

pitRemaining

liquidationThreshold

totalOutstanding

healthFactor

getProjectTokenEvaluation

lendingTokensLength

projectTokensLength

getPosition

decimals

PrimaryLendingPlatformProxyAdmin

minimumDelayPeriod

delayPeriod

UpgradeData

upgradeData

SetDelayPeriod

AppendUpgrade

Upgrade

constructor

setDelayPeriod

changeProxyAdmin

_Changes the admin of `proxy` to `newAdmin`.

Requirements:

  • This contract must be the current admin of `proxy`._

appendUpgrade

upgrade

_Upgrades `proxy` to `implementation`. See {TransparentUpgradeableProxy-upgradeTo}.

Requirements:

  • This contract must be the admin of `proxy`._

upgradeAndCall

_Upgrades `proxy` to `implementation` and calls a function on the new implementation. See {TransparentUpgradeableProxy-upgradeToAndCall}.

Requirements:

  • This contract must be the admin of `proxy`._

BErc20

CTokens which wrap an EIP-20 underlying

initialize

Initialize the new money market

Name
Type
Description

underlying_

address

The address of the underlying asset

comptroller_

contract Bondtroller

The address of the Comptroller

interestRateModel_

contract InterestRateModel

The address of the interest rate model

initialExchangeRateMantissa_

uint256

The initial exchange rate, scaled by 1e18

name_

string

ERC-20 name of this token

symbol_

string

ERC-20 symbol of this token

decimals_

uint8

ERC-20 decimal precision of this token

sweepToken

A public function to sweep accidental ERC-20 transfers to this contract. Tokens are sent to admin (timelock)

Name
Type
Description

token

contract EIP20NonStandardInterface

The address of the ERC-20 token to sweep

_addReserves

The sender adds to reserves.

Name
Type
Description

addAmount

uint256

The amount fo underlying token to add as reserves

Name
Type
Description

[0]

uint256

uint 0=success, otherwise a failure (see ErrorReporter.sol for details)

getCashPrior

Gets balance of this contract in terms of the underlying

This excludes the value of the current message, if any

Name
Type
Description

[0]

uint256

The quantity of underlying tokens owned by this contract

doTransferIn

_Similar to EIP20 transfer, except it handles a False result from `transferFrom` and reverts in that case. This will revert due to insufficient balance or insufficient allowance. This function returns the actual amount received, which may be less than `amount` if there is a fee attached to the transfer.

doTransferOut

_Similar to EIP20 transfer, except it handles a False success from `transfer` and returns an explanatory error code rather than reverting. If caller has not called checked protocol's balance, this may revert due to insufficient cash held in this contract. If caller has checked protocol's balance prior to this call, and verified it is >= amount, this should not revert in normal conditions.

BEther

CToken which wraps Ether

constructor

Construct a new CEther money market

Name
Type
Description

bondtroller_

contract Bondtroller

The address of the Comptroller

interestRateModel_

contract InterestRateModel

The address of the interest rate model

initialExchangeRateMantissa_

uint256

The initial exchange rate, scaled by 1e18

name_

string

ERC-20 name of this token

symbol_

string

ERC-20 symbol of this token

decimals_

uint8

ERC-20 decimal precision of this token

admin_

address payable

Address of the administrator of this token

mint

Sender supplies assets into the market and receives cTokens in exchange

Reverts upon any failure

redeem

Sender redeems cTokens in exchange for the underlying asset

Accrues interest whether or not the operation succeeds, unless reverted

Name
Type
Description

redeemTokens

uint256

The number of cTokens to redeem into underlying

Name
Type
Description

[0]

uint256

uint 0=success, otherwise a failure (see ErrorReporter.sol for details)

redeemUnderlying

Sender redeems cTokens in exchange for a specified amount of underlying asset

Accrues interest whether or not the operation succeeds, unless reverted

Name
Type
Description

redeemAmount

uint256

The amount of underlying to redeem

Name
Type
Description

[0]

uint256

uint 0=success, otherwise a failure (see ErrorReporter.sol for details)

borrow

Sender borrows assets from the protocol to their own address

Name
Type
Description

borrowAmount

uint256

The amount of the underlying asset to borrow

Name
Type
Description

[0]

uint256

uint 0=success, otherwise a failure (see ErrorReporter.sol for details)

repayBorrow

Sender repays their own borrow

Reverts upon any failure

repayBorrowBehalf

Sender repays a borrow belonging to borrower

Reverts upon any failure

Name
Type
Description

borrower

address

the account with the debt being payed off

_addReserves

The sender adds to reserves.

Name
Type
Description

[0]

uint256

uint 0=success, otherwise a failure (see ErrorReporter.sol for details)

fallback

Send Ether to CEther to mint

receive

getCashPrior

Gets balance of this contract in terms of Ether, before this message

This excludes the value of the current message, if any

Name
Type
Description

[0]

uint256

The quantity of Ether owned by this contract

doTransferIn

Perform the actual transfer in, which is a no-op

Name
Type
Description

from

address

Address sending the Ether

amount

uint256

Amount of Ether being sent

Name
Type
Description

[0]

uint256

The actual amount of Ether transferred

doTransferOut

Performs a transfer out, ideally returning an explanatory error code upon failure tather than reverting. If caller has not called checked protocol's balance, may revert due to insufficient cash held in the contract. If caller has checked protocol's balance, and verified it is >= amount, this should not revert in normal conditions. / f

requireNoError

BLendingToken

MODERATOR_ROLE

primaryIndexToken

SetPrimaryIndexToken

init

onlyAdmin

onlyPrimaryIndexToken

onlyModerator

setPrimaryIndexToken

grandModerator

revokeModerator

setReserveFactor

mintTo

redeemTo

redeemUnderlyingTo

borrowTo

repayTo

getEstimatedBorrowIndex

getEstimatedBorrowBalanceStored

BToken

Abstract base for CTokens

initialize

Initialize the money market

Name
Type
Description

bondtroller_

contract Bondtroller

The address of the Bondtroller

interestRateModel_

contract InterestRateModel

The address of the interest rate model

initialExchangeRateMantissa_

uint256

The initial exchange rate, scaled by 1e18

name_

string

EIP-20 name of this token

symbol_

string

EIP-20 symbol of this token

decimals_

uint8

EIP-20 decimal precision of this token

transferTokens

Transfer `tokens` tokens from `src` to `dst` by `spender`

Called by both `transfer` and `transferFrom` internally

Name
Type
Description

spender

address

The address of the account performing the transfer

src

address

The address of the source account

dst

address

The address of the destination account

tokens

uint256

The number of tokens to transfer

Name
Type
Description

[0]

uint256

Whether or not the transfer succeeded

transfer

Transfer `amount` tokens from `msg.sender` to `dst`

Name
Type
Description

dst

address

The address of the destination account

amount

uint256

The number of tokens to transfer

Name
Type
Description

[0]

bool

Whether or not the transfer succeeded

transferFrom

Transfer `amount` tokens from `src` to `dst`

Name
Type
Description

src

address

The address of the source account

dst

address

The address of the destination account

amount

uint256

The number of tokens to transfer

Name
Type
Description

[0]

bool

Whether or not the transfer succeeded

approve

Approve `spender` to transfer up to `amount` from `src`

This will overwrite the approval amount for `spender` and is subject to issues noted here

Name
Type
Description

spender

address

The address of the account which may transfer tokens

amount

uint256

The number of tokens that are approved (-1 means infinite)

Name
Type
Description

[0]

bool

Whether or not the approval succeeded

allowance

Get the current allowance from `owner` for `spender`

Name
Type
Description

owner

address

The address of the account which owns the tokens to be spent

spender

address

The address of the account which may transfer tokens

Name
Type
Description

[0]

uint256

The number of tokens allowed to be spent (-1 means infinite)

balanceOf

Get the token balance of the `owner`

Name
Type
Description

owner

address

The address of the account to query

Name
Type
Description

[0]

uint256

The number of tokens owned by `owner`

balanceOfUnderlying

Get the underlying balance of the `owner`

This also accrues interest in a transaction

Name
Type
Description

owner

address

The address of the account to query

Name
Type
Description

[0]

uint256

The amount of underlying owned by `owner`

balanceOfUnderlyingView

getAccountSnapshot

Get a snapshot of the account's balances, and the cached exchange rate

This is used by bondtroller to more efficiently perform liquidity checks.

Name
Type
Description

account

address

Address of the account to snapshot

Name
Type
Description

[0]

uint256

(possible error, token balance, borrow balance, exchange rate mantissa)

[1]

uint256

[2]

uint256

[3]

uint256

getBlockNumber

Function to simply retrieve block number This exists mainly for inheriting test contracts to stub this result.

borrowRatePerBlock

Returns the current per-block borrow interest rate for this cToken

Name
Type
Description

[0]

uint256

The borrow interest rate per block, scaled by 1e18

supplyRatePerBlock

Returns the current per-block supply interest rate for this cToken

Name
Type
Description

[0]

uint256

The supply interest rate per block, scaled by 1e18

totalBorrowsCurrent

Returns the current total borrows plus accrued interest

Name
Type
Description

[0]

uint256

The total borrows with interest

borrowBalanceCurrent

Accrue interest to updated borrowIndex and then calculate account's borrow balance using the updated borrowIndex

Name
Type
Description

account

address

The address whose balance should be calculated after updating borrowIndex

Name
Type
Description

[0]

uint256

The calculated balance

borrowBalanceStored

Return the borrow balance of account based on stored data

Name
Type
Description

account

address

The address whose balance should be calculated

Name
Type
Description

[0]

uint256

The calculated balance

borrowBalanceStoredInternal

Return the borrow balance of account based on stored data

Name
Type
Description

account

address

The address whose balance should be calculated

Name
Type
Description

[0]

enum CarefulMath.MathError

(error code, the calculated balance or 0 if error code is non-zero)

[1]

uint256

exchangeRateCurrent

Accrue interest then return the up-to-date exchange rate

Name
Type
Description

[0]

uint256

Calculated exchange rate scaled by 1e18

exchangeRateStored

Calculates the exchange rate from the underlying to the CToken

This function does not accrue interest before calculating the exchange rate

Name
Type
Description

[0]

uint256

Calculated exchange rate scaled by 1e18

exchangeRateStoredInternal

Calculates the exchange rate from the underlying to the CToken

This function does not accrue interest before calculating the exchange rate

Name
Type
Description

[0]

enum CarefulMath.MathError

(error code, calculated exchange rate scaled by 1e18)

[1]

uint256

getCash

Get cash balance of this cToken in the underlying asset

Name
Type
Description

[0]

uint256

The quantity of underlying asset owned by this contract

accrueInterest

Applies accrued interest to total borrows and reserves

This calculates interest accrued from the last checkpointed block up to the current block and writes new checkpoint to storage.

mintInternal

Sender supplies assets into the market and receives cTokens in exchange

Accrues interest whether or not the operation succeeds, unless reverted

Name
Type
Description

mintAmount

uint256

The amount of the underlying asset to supply

Name
Type
Description

[0]

uint256

(uint, uint) An error code (0=success, otherwise a failure, see ErrorReporter.sol), and the actual mint amount.

[1]

uint256

MintLocalVars

mintFresh

User supplies assets into the market and receives cTokens in exchange

Assumes interest has already been accrued up to the current block

Name
Type
Description

minter

address

The address of the account which is supplying the assets

mintAmount

uint256

The amount of the underlying asset to supply

Name
Type
Description

[0]

uint256

(uint, uint) An error code (0=success, otherwise a failure, see ErrorReporter.sol), and the actual mint amount.

[1]

uint256

redeemInternal

Sender redeems cTokens in exchange for the underlying asset

Accrues interest whether or not the operation succeeds, unless reverted

Name
Type
Description

redeemTokens

uint256

The number of cTokens to redeem into underlying

Name
Type
Description

[0]

uint256

uint 0=success, otherwise a failure (see ErrorReporter.sol for details)

redeemUnderlyingInternal

Sender redeems cTokens in exchange for a specified amount of underlying asset

Accrues interest whether or not the operation succeeds, unless reverted

Name
Type
Description

redeemAmount

uint256

The amount of underlying to receive from redeeming cTokens

Name
Type
Description

[0]

uint256

uint 0=success, otherwise a failure (see ErrorReporter.sol for details)

RedeemLocalVars

redeemFresh

User redeems cTokens in exchange for the underlying asset

Assumes interest has already been accrued up to the current block

Name
Type
Description

redeemer

address payable

The address of the account which is redeeming the tokens

redeemTokensIn

uint256

The number of cTokens to redeem into underlying (only one of redeemTokensIn or redeemAmountIn may be non-zero)

redeemAmountIn

uint256

The number of underlying tokens to receive from redeeming cTokens (only one of redeemTokensIn or redeemAmountIn may be non-zero)

Name
Type
Description

[0]

uint256

uint 0=success, otherwise a failure (see ErrorReporter.sol for details)

borrowInternal

Sender borrows assets from the protocol to their own address

Name
Type
Description

borrowAmount

uint256

The amount of the underlying asset to borrow

Name
Type
Description

[0]

uint256

uint 0=success, otherwise a failure (see ErrorReporter.sol for details)

BorrowLocalVars

borrowFresh

Users borrow assets from the protocol to their own address

Name
Type
Description

borrower

address payable

borrowAmount

uint256

The amount of the underlying asset to borrow

Name
Type
Description

[0]

uint256

uint 0=success, otherwise a failure (see ErrorReporter.sol for details)

repayBorrowInternal

Sender repays their own borrow

Name
Type
Description

repayAmount

uint256

The amount to repay

Name
Type
Description

[0]

uint256

(uint, uint) An error code (0=success, otherwise a failure, see ErrorReporter.sol), and the actual repayment amount.

[1]

uint256

repayBorrowBehalfInternal

Sender repays a borrow belonging to borrower

Name
Type
Description

borrower

address

the account with the debt being payed off

repayAmount

uint256

The amount to repay

Name
Type
Description

[0]

uint256

(uint, uint) An error code (0=success, otherwise a failure, see ErrorReporter.sol), and the actual repayment amount.

[1]

uint256

RepayBorrowLocalVars

repayBorrowFresh

Borrows are repaid by another user (possibly the borrower).

Name
Type
Description

payer

address

the account paying off the borrow

borrower

address

the account with the debt being payed off

repayAmount

uint256

the amount of undelrying tokens being returned

Name
Type
Description

[0]

uint256

(uint, uint) An error code (0=success, otherwise a failure, see ErrorReporter.sol), and the actual repayment amount.

[1]

uint256

_setPendingAdmin

Begins transfer of admin rights. The newPendingAdmin must call `_acceptAdmin` to finalize the transfer.

_Admin function to begin change of admin. The newPendingAdmin must call `acceptAdmin` to finalize the transfer.

Name
Type
Description

newPendingAdmin

address payable

New pending admin.

Name
Type
Description

[0]

uint256

uint 0=success, otherwise a failure (see ErrorReporter.sol for details)

_acceptAdmin

Accepts transfer of admin rights. msg.sender must be pendingAdmin

Admin function for pending admin to accept role and update admin

Name
Type
Description

[0]

uint256

uint 0=success, otherwise a failure (see ErrorReporter.sol for details)

_setBondtroller

Sets a new bondtroller for the market

Admin function to set a new bondtroller

Name
Type
Description

[0]

uint256

uint 0=success, otherwise a failure (see ErrorReporter.sol for details) /

_setReserveFactor

accrues interest and sets a new reserve factor for the protocol using _setReserveFactorFresh

Admin function to accrue interest and set a new reserve factor

Name
Type
Description

[0]

uint256

uint 0=success, otherwise a failure (see ErrorReporter.sol for details) /

_setReserveFactorFresh

Sets a new reserve factor for the protocol (*requires fresh interest accrual)

Admin function to set a new reserve factor

Name
Type
Description

[0]

uint256

uint 0=success, otherwise a failure (see ErrorReporter.sol for details) /

_addReservesInternal

Accrues interest and reduces reserves by transferring from msg.sender

Name
Type
Description

addAmount

uint256

Amount of addition to reserves

Name
Type
Description

[0]

uint256

uint 0=success, otherwise a failure (see ErrorReporter.sol for details) /

_addReservesFresh

Add reserves by transferring from caller

Requires fresh interest accrual

Name
Type
Description

addAmount

uint256

Amount of addition to reserves

Name
Type
Description

[0]

uint256

(uint, uint) An error code (0=success, otherwise a failure (see ErrorReporter.sol for details)) and the actual amount added, net token fees /

[1]

uint256

_reduceReserves

Accrues interest and reduces reserves by transferring to admin

Name
Type
Description

reduceAmount

uint256

Amount of reduction to reserves

Name
Type
Description

[0]

uint256

uint 0=success, otherwise a failure (see ErrorReporter.sol for details) /

_reduceReservesFresh

Reduces reserves by transferring to admin

Requires fresh interest accrual

Name
Type
Description

reduceAmount

uint256

Amount of reduction to reserves

Name
Type
Description

[0]

uint256

uint 0=success, otherwise a failure (see ErrorReporter.sol for details) /

_setInterestRateModel

accrues interest and updates the interest rate model using _setInterestRateModelFresh

Admin function to accrue interest and update the interest rate model

Name
Type
Description

newInterestRateModel

contract InterestRateModel

the new interest rate model to use

Name
Type
Description

[0]

uint256

uint 0=success, otherwise a failure (see ErrorReporter.sol for details) / f

_setInterestRateModelFresh

updates the interest rate model (*requires fresh interest accrual)

Admin function to update the interest rate model

Name
Type
Description

newInterestRateModel

contract InterestRateModel

the new interest rate model to use

Name
Type
Description

[0]

uint256

uint 0=success, otherwise a failure (see ErrorReporter.sol for details) / f

getCashPrior

Gets balance of this contract in terms of the underlying

This excludes the value of the current message, if any

Name
Type
Description

[0]

uint256

The quantity of underlying owned by this contract / f

doTransferIn

Performs a transfer in, reverting upon failure. Returns the amount actually transferred to the protocol, in case of a fee. This may revert due to insufficient balance or insufficient allowance. / f

doTransferOut

Performs a transfer out, ideally returning an explanatory error code upon failure tather than reverting. If caller has not called checked protocol's balance, may revert due to insufficient cash held in the contract. If caller has checked protocol's balance, and verified it is >= amount, this should not revert in normal conditions. / f

nonReentrant

Prevents a contract from calling itself, directly or indirectly. / m

BTokenStorage

_notEntered

Guard variable for re-entrancy checks

name

EIP-20 token name for this token

symbol

EIP-20 token symbol for this token

decimals

EIP-20 token decimals for this token

borrowRateMaxMantissa

Maximum borrow rate that can ever be applied (.0005% / block)

reserveFactorMaxMantissa

Maximum fraction of interest that can be set aside for reserves

admin

Administrator for this contract

pendingAdmin

Pending administrator for this contract

bondtroller

Contract which oversees inter-cToken operations

interestRateModel

Model which tells what the current interest rate should be

initialExchangeRateMantissa

Initial exchange rate used when minting the first CTokens (used when totalSupply = 0)

reserveFactorMantissa

Fraction of interest currently set aside for reserves

accrualBlockNumber

Block number that interest was last accrued at

borrowIndex

Accumulator of the total earned interest rate since the opening of the market

totalBorrows

Total amount of outstanding borrows of the underlying in this market

totalReserves

Total amount of reserves of the underlying held in this market

totalSupply

Total number of tokens in circulation

accountTokens

Official record of token balances for each account

transferAllowances

Approved token transfer amounts on behalf of others

BorrowSnapshot

accountBorrows

Mapping of account addresses to outstanding borrow balances

protocolSeizeShareMantissa

Share of seized collateral that is added to reserves

BTokenInterface

isCToken

Indicator that this is a CToken contract (for inspection)

AccrueInterest

Event emitted when interest is accrued

Mint

Event emitted when tokens are minted

Redeem

Event emitted when tokens are redeemed

Borrow

Event emitted when underlying is borrowed

RepayBorrow

Event emitted when a borrow is repaid

LiquidateBorrow

Event emitted when a borrow is liquidated

NewPendingAdmin

Event emitted when pendingAdmin is changed

NewAdmin

Event emitted when pendingAdmin is accepted, which means admin is updated

NewBondtroller

Event emitted when bondtroller is changed

NewMarketInterestRateModel

Event emitted when interestRateModel is changed

NewReserveFactor

Event emitted when the reserve factor is changed

ReservesAdded

Event emitted when the reserves are added

ReservesReduced

Event emitted when the reserves are reduced

Transfer

EIP20 Transfer event

Approval

EIP20 Approval event

transfer

Failure event

transferFrom

approve

allowance

balanceOf

balanceOfUnderlying

getAccountSnapshot

borrowRatePerBlock

supplyRatePerBlock

totalBorrowsCurrent

borrowBalanceCurrent

borrowBalanceStored

exchangeRateCurrent

exchangeRateStored

getCash

accrueInterest

_setPendingAdmin

_acceptAdmin

_setBondtroller

_setReserveFactor

_reduceReserves

_setInterestRateModel

BErc20Storage

underlying

Underlying asset for this CToken

BErc20Interface

sweepToken

_addReserves

Bondtroller

MarketListed

Emitted when an admin supports a market

MarketEntered

Emitted when an account enters a market

MarketExited

Emitted when an account exits a market

NewPriceOracle

Emitted when price oracle is changed

NewPauseGuardian

Emitted when pause guardian is changed

ActionPaused

Emitted when an action is paused globally

ActionPaused

Emitted when an action is paused on a market

NewBorrowCap

Emitted when borrow cap for a bToken is changed

NewBorrowCapGuardian

Emitted when borrow cap guardian is changed

CompGranted

Emitted when COMP is granted by admin

NewPrimaryIndexToken

primaryIndexToken

the address of primary index token

init

onlyPrimaryIndexToken

getPrimaryIndexTokenAddress

getAssetsIn

Returns the assets an account has entered

Name
Type
Description

account

address

The address of the account to pull assets for

Name
Type
Description

[0]

contract BToken[]

A dynamic list with the assets the account has entered

checkMembership

Returns whether the given account is entered in the given asset

Name
Type
Description

account

address

The address of the account to check

bToken

contract BToken

The bToken to check

Name
Type
Description

[0]

bool

True if the account is in the asset, otherwise false.

enterMarkets

Add assets to be included in account liquidity calculation

Name
Type
Description

bTokens

address[]

The list of addresses of the bToken markets to be enabled

Name
Type
Description

[0]

uint256[]

Success indicator for whether each corresponding market was entered

enterMarket

Add asset to be included in account liquidity calculation

Name
Type
Description

bToken

address

The address of the bToken markets to be enabled

borrower

address

The address of user, which enters to market

addToMarketInternal

Add the market to the borrower's "assets in" for liquidity calculations

Name
Type
Description

bToken

contract BToken

The market to enter

borrower

address

The address of the account to modify

Name
Type
Description

[0]

enum BondtrollerErrorReporter.Error

Success indicator for whether the market was entered

exitMarket

Removes asset from sender's account liquidity calculation

Sender must not have an outstanding borrow balance in the asset, or be providing necessary collateral for an outstanding borrow.

Name
Type
Description

cTokenAddress

address

The address of the asset to be removed

Name
Type
Description

[0]

uint256

Whether or not the account successfully exited the market

mintAllowed

Checks if the account should be allowed to mint tokens in the given market

Name
Type
Description

bToken

address

The market to verify the mint against

minter

address

The account which would get the minted tokens

mintAmount

uint256

The amount of underlying being supplied to the market in exchange for tokens

Name
Type
Description

[0]

uint256

0 if the mint is allowed, otherwise a semi-opaque error code (See ErrorReporter.sol) / f

mintVerify

Validates mint and reverts on rejection. May emit logs.

Name
Type
Description

bToken

address

Asset being minted

minter

address

The address minting the tokens

actualMintAmount

uint256

The amount of the underlying asset being minted

mintTokens

uint256

The number of tokens being minted / f

redeemAllowed

Checks if the account should be allowed to redeem tokens in the given market

Name
Type
Description

bToken

address

The market to verify the redeem against

redeemer

address

The account which would redeem the tokens

redeemTokens

uint256

The number of bTokens to exchange for the underlying asset in the market

Name
Type
Description

[0]

uint256

0 if the redeem is allowed, otherwise a semi-opaque error code (See ErrorReporter.sol) / f

redeemAllowedInternal

redeemVerify

Validates redeem and reverts on rejection. May emit logs.

Name
Type
Description

bToken

address

Asset being redeemed

redeemer

address

The address redeeming the tokens

redeemAmount

uint256

The amount of the underlying asset being redeemed

redeemTokens

uint256

The number of tokens being redeemed / f

borrowAllowed

Checks if the account should be allowed to borrow the underlying asset of the given market

Name
Type
Description

bToken

address

The market to verify the borrow against

borrower

address

The account which would borrow the asset

borrowAmount

uint256

The amount of underlying the account would borrow

Name
Type
Description

[0]

uint256

0 if the borrow is allowed, otherwise a semi-opaque error code (See ErrorReporter.sol) / f

borrowVerify

Validates borrow and reverts on rejection. May emit logs.

Name
Type
Description

bToken

address

Asset whose underlying is being borrowed

borrower

address

The address borrowing the underlying

borrowAmount

uint256

The amount of the underlying asset requested to borrow / f

repayBorrowAllowed

Checks if the account should be allowed to repay a borrow in the given market

Name
Type
Description

bToken

address

The market to verify the repay against

payer

address

The account which would repay the asset

borrower

address

The account which would borrowed the asset

repayAmount

uint256

The amount of the underlying asset the account would repay

Name
Type
Description

[0]

uint256

0 if the repay is allowed, otherwise a semi-opaque error code (See ErrorReporter.sol) / f

repayBorrowVerify

Validates repayBorrow and reverts on rejection. May emit logs.

Name
Type
Description

bToken

address

Asset being repaid

payer

address

The address repaying the borrow

borrower

address

The address of the borrower

actualRepayAmount

uint256

The amount of underlying being repaid / f

borrowerIndex

uint256

transferAllowed

Checks if the account should be allowed to transfer tokens in the given market

Name
Type
Description

bToken

address

The market to verify the transfer against

src

address

The account which sources the tokens

dst

address

The account which receives the tokens

transferTokens

uint256

The number of bTokens to transfer

Name
Type
Description

[0]

uint256

0 if the transfer is allowed, otherwise a semi-opaque error code (See ErrorReporter.sol) / f

transferVerify

Validates transfer and reverts on rejection. May emit logs.

Name
Type
Description

bToken

address

Asset being transferred

src

address

The account which sources the tokens

dst

address

The account which receives the tokens

transferTokens

uint256

The number of bTokens to transfer / f

setPriceOracle

Sets a new price oracle for the bondtroller

Admin function to set a new price oracle

Name
Type
Description

[0]

uint256

uint 0=success, otherwise a failure (see ErrorReporter.sol for details) / f

setPrimaryIndexTokenAddress

supportMarket

Add the market to the markets mapping and set it as listed

Admin function to set isListed and add support for the market

Name
Type
Description

bToken

contract BToken

The address of the market (token) to list

Name
Type
Description

[0]

uint256

uint 0=success, otherwise a failure. (See enum Error for details) / f

_addMarketInternal

setMarketBorrowCaps

Set the given borrow caps for the given bToken markets. Borrowing that brings total borrows to or above borrow cap will revert.

Admin or borrowCapGuardian function to set the borrow caps. A borrow cap of 0 corresponds to unlimited borrowing.

Name
Type
Description

bTokens

contract BToken[]

The addresses of the markets (tokens) to change the borrow caps for

newBorrowCaps

uint256[]

The new borrow cap values in underlying to be set. A value of 0 corresponds to unlimited borrowing. / f

setBorrowCapGuardian

Admin function to change the Borrow Cap Guardian

Name
Type
Description

newBorrowCapGuardian

address

The address of the new Borrow Cap Guardian / f

setPauseGuardian

Admin function to change the Pause Guardian

Name
Type
Description

newPauseGuardian

address

The address of the new Pause Guardian

Name
Type
Description

[0]

uint256

uint 0=success, otherwise a failure. (See enum Error for details) / f

setMintPaused

setBorrowPaused

setTransferPaused

setSeizePaused

adminOrInitializing

Checks caller is admin, or this contract is becoming the new implementation / f

getAllMarkets

Return all of the markets

The automatic getter may be used to access an individual market.

Name
Type
Description

[0]

contract BToken[]

The list of market addresses / f

isDeprecated

Returns true if the given bToken market has been deprecated

All borrows in a deprecated bToken market can be immediately liquidated

Name
Type
Description

bToken

contract BToken

The market to check if deprecated / f

getBlockNumber

BondtrollerV1Storage

isBondtroller

watermark that says that this is Bondtroller

admin

Administrator for this contract

oracle

Oracle which gives the price of any given asset

closeFactorMantissa

Multiplier used to calculate the maximum repayAmount when liquidating a borrow

liquidationIncentiveMantissa

Multiplier representing the discount on collateral that a liquidator receives

maxAssets

Max number of assets a single account can participate in (borrow or use as collateral)

accountAssets

Per-account mapping of "assets you are in", capped by maxAssets

BondtrollerV2Storage

Market

accountMembership

Per-market mapping of "accounts in this asset"

markets

Official mapping of BTokens -> Market metadata

Used e.g. to determine if a market is supported

pauseGuardian

The Pause Guardian can pause certain actions as a safety mechanism. Actions which allow users to remove their own assets cannot be paused. Liquidation / seizing / transfer can only be paused globally, not by market.

_mintGuardianPaused

_borrowGuardianPaused

transferGuardianPaused

seizeGuardianPaused

mintGuardianPaused

borrowGuardianPaused

BondtrollerV3Storage

CompMarketState

allMarkets

A list of all markets

compRate

The rate at which the flywheel distributes COMP, per block

compSpeeds

The portion of compRate that each market currently receives

compSupplyState

The COMP market supply state for each market

compBorrowState

The COMP market borrow state for each market

compSupplierIndex

The COMP borrow index for each market for each supplier as of the last time they accrued COMP

compBorrowerIndex

The COMP borrow index for each market for each borrower as of the last time they accrued COMP

compAccrued

The COMP accrued but not yet transferred to each user

BondtrollerV4Storage

borrowCapGuardian

borrowCaps

BondtrollerV5Storage

compContributorSpeeds

The portion of COMP that each contributor receives per block

lastContributorBlock

Last block at which a contributor's COMP rewards have been allocated

BaseJumpRateModelV2

Version 2 modifies Version 1 by enabling updateable parameters.

NewInterestParams

owner

The address of the owner, i.e. the Timelock contract, which can update parameters directly

blocksPerYear

The approximate number of blocks per year that is assumed by the interest rate model

multiplierPerBlock

The multiplier of utilization rate that gives the slope of the interest rate

baseRatePerBlock

The base interest rate which is the y-intercept when utilization rate is 0

jumpMultiplierPerBlock

The multiplierPerBlock after hitting a specified utilization point

kink

The utilization point at which the jump multiplier is applied

constructor

Construct an interest rate model

Name
Type
Description

baseRatePerYear

uint256

The approximate target base APR, as a mantissa (scaled by 1e18)

multiplierPerYear

uint256

The rate of increase in interest rate wrt utilization (scaled by 1e18)

jumpMultiplierPerYear

uint256

The multiplierPerBlock after hitting a specified utilization point

kink_

uint256

The utilization point at which the jump multiplier is applied

owner_

address

The address of the owner, i.e. the Timelock contract (which has the ability to update parameters directly)

updateJumpRateModel

Update the parameters of the interest rate model (only callable by owner, i.e. Timelock)

Name
Type
Description

baseRatePerYear

uint256

The approximate target base APR, as a mantissa (scaled by 1e18)

multiplierPerYear

uint256

The rate of increase in interest rate wrt utilization (scaled by 1e18)

jumpMultiplierPerYear

uint256

The multiplierPerBlock after hitting a specified utilization point

kink_

uint256

The utilization point at which the jump multiplier is applied

utilizationRate

Calculates the utilization rate of the market: `borrows / (cash + borrows - reserves)`

Name
Type
Description

cash

uint256

The amount of cash in the market

borrows

uint256

The amount of borrows in the market

reserves

uint256

The amount of reserves in the market (currently unused)

Name
Type
Description

[0]

uint256

The utilization rate as a mantissa between [0, 1e18]

getBorrowRateInternal

Calculates the current borrow rate per block, with the error code expected by the market

Name
Type
Description

cash

uint256

The amount of cash in the market

borrows

uint256

The amount of borrows in the market

reserves

uint256

The amount of reserves in the market

Name
Type
Description

[0]

uint256

The borrow rate percentage per block as a mantissa (scaled by 1e18)

getSupplyRate

Calculates the current supply rate per block

Name
Type
Description

cash

uint256

The amount of cash in the market

borrows

uint256

The amount of borrows in the market

reserves

uint256

The amount of reserves in the market

reserveFactorMantissa

uint256

The current reserve factor for the market

Name
Type
Description

[0]

uint256

The supply rate percentage per block as a mantissa (scaled by 1e18)

updateJumpRateModelInternal

Internal function to update the parameters of the interest rate model

Name
Type
Description

baseRatePerYear

uint256

The approximate target base APR, as a mantissa (scaled by 1e18)

multiplierPerYear

uint256

The rate of increase in interest rate wrt utilization (scaled by 1e18)

jumpMultiplierPerYear

uint256

The multiplierPerBlock after hitting a specified utilization point

kink_

uint256

The utilization point at which the jump multiplier is applied

FringeInterestRateModel

MODERATOR_ROLE

borrowRate

supplyRate

initialize

onlyAdmin

onlyModerator

grandModerator

revokeModerator

setBorrowRate

setSupplyRate

getBorrowRate

Calculates the current borrow rate per block

Name
Type
Description

cash

uint256

The amount of cash in the market

borrows

uint256

The amount of borrows in the market

reserves

uint256

The amount of reserves in the market

Name
Type
Description

[0]

uint256

The borrow rate percentage per block as a mantissa (scaled by 1e18)

getSupplyRate

Calculates the current supply interest rate per block

Name
Type
Description

cash

uint256

The total amount of cash the market has

borrows

uint256

The total amount of borrows the market has outstanding

reserves

uint256

The total amount of reserves the market has

reserveFactorMantissa

uint256

The current reserve factor the market has

Name
Type
Description

[0]

uint256

The supply rate per block (as a percentage, and scaled by 1e18)

InterestRateModel

isInterestRateModel

Indicator that this is an InterestRateModel contract (for inspection)

getBorrowRate

Calculates the current borrow interest rate per block

Name
Type
Description

cash

uint256

The total amount of cash the market has

borrows

uint256

The total amount of borrows the market has outstanding

reserves

uint256

The total amount of reserves the market has

Name
Type
Description

[0]

uint256

The borrow rate per block (as a percentage, and scaled by 1e18)

getSupplyRate

Calculates the current supply interest rate per block

Name
Type
Description

cash

uint256

The total amount of cash the market has

borrows

uint256

The total amount of borrows the market has outstanding

reserves

uint256

The total amount of reserves the market has

reserveFactorMantissa

uint256

The current reserve factor the market has

Name
Type
Description

[0]

uint256

The supply rate per block (as a percentage, and scaled by 1e18)

JumpRateModelV2

Supports only for V2 cTokens

getBorrowRate

Calculates the current borrow rate per block

Name
Type
Description

cash

uint256

The amount of cash in the market

borrows

uint256

The amount of borrows in the market

reserves

uint256

The amount of reserves in the market

Name
Type
Description

[0]

uint256

The borrow rate percentage per block as a mantissa (scaled by 1e18)

getSupplyRate

constructor

EIP20Interface

name

symbol

decimals

totalSupply

Get the total number of tokens in circulation

Name
Type
Description

[0]

uint256

The supply of tokens

balanceOf

Gets the balance of the specified address

Name
Type
Description

owner

address

The address from which the balance will be retrieved return The `balance`

transfer

Transfer `amount` tokens from `msg.sender` to `dst`

Name
Type
Description

dst

address

The address of the destination account

amount

uint256

The number of tokens to transfer return Whether or not the transfer succeeded

transferFrom

Transfer `amount` tokens from `src` to `dst`

Name
Type
Description

src

address

The address of the source account

dst

address

The address of the destination account

amount

uint256

The number of tokens to transfer return Whether or not the transfer succeeded

approve

Approve `spender` to transfer up to `amount` from `src`

This will overwrite the approval amount for `spender` and is subject to issues noted here

Name
Type
Description

spender

address

The address of the account which may transfer tokens

amount

uint256

The number of tokens that are approved (-1 means infinite) return Whether or not the approval succeeded

allowance

Get the current allowance from `owner` for `spender`

Name
Type
Description

owner

address

The address of the account which owns the tokens to be spent

spender

address

The address of the account which may transfer tokens return The number of tokens allowed to be spent (-1 means infinite)

Transfer

Approval

EIP20NonStandardInterface

Version of ERC20 with no return values for `transfer` and `transferFrom` See https://medium.com/coinmonks/missing-return-value-bug-at-least-130-tokens-affected-d67bf08521ca

totalSupply

Get the total number of tokens in circulation

Name
Type
Description

[0]

uint256

The supply of tokens

balanceOf

Gets the balance of the specified address

Name
Type
Description

owner

address

The address from which the balance will be retrieved

transfer

Transfer `amount` tokens from `msg.sender` to `dst`

Name
Type
Description

dst

address

The address of the destination account

amount

uint256

The number of tokens to transfer

transferFrom

Transfer `amount` tokens from `src` to `dst`

Name
Type
Description

src

address

The address of the source account

dst

address

The address of the destination account

amount

uint256

The number of tokens to transfer

approve

Approve `spender` to transfer up to `amount` from `src`

This will overwrite the approval amount for `spender` and is subject to issues noted here

Name
Type
Description

spender

address

The address of the account which may transfer tokens

amount

uint256

The number of tokens that are approved return Whether or not the approval succeeded

allowance

Get the current allowance from `owner` for `spender`

Name
Type
Description

owner

address

The address of the account which owns the tokens to be spent

spender

address

The address of the account which may transfer tokens return The number of tokens allowed to be spent

Transfer

Approval

IPriceProviderAggregator

MODERATOR_ROLE

usdDecimals

tokenPriceProvider

GrandModeratorRole

RevokeModeratorRole

SetTokenAndPriceProvider

ChangeActive

initialize

grandModerator

revokeModerator

setTokenAndPriceProvider

changeActive

getPrice

price = priceMantissa / (10 ** priceDecimals)

returns tuple (priceMantissa, priceDecimals)

Name
Type
Description

token

address

the address of token wich price is to return

getPriceSigned

returns the price of token multiplied by 10 ** priceDecimals given by price provider. price can be calculated as priceMantissa / (10 ** priceDecimals) i.e. price = priceMantissa / (10 ** priceDecimals)

Name
Type
Description

token

address

the address of token

_priceMantissa

uint256

- the price of token (used in verifying the signature)

_priceDecimals

uint8

- the price decimals (used in verifying the signature)

validTo

uint256

- the timestamp in seconds (used in verifying the signature)

signature

bytes

- the backend signature of secp256k1. length is 65 bytes

getEvaluation

returns the USD evaluation of token by its `tokenAmount`

Name
Type
Description

token

address

the address of token to evaluate

tokenAmount

uint256

the amount of token to evaluate

getEvaluationSigned

returns the USD evaluation of token by its `tokenAmount`

Name
Type
Description

token

address

the address of token

tokenAmount

uint256

the amount of token including decimals

priceMantissa

uint256

- the price of token (used in verifying the signature)

priceDecimals

uint8

- the price decimals (used in verifying the signature)

validTo

uint256

- the timestamp in seconds (used in verifying the signature)

signature

bytes

- the backend signature of secp256k1. length is 65 bytes

PRJ

init

mint

mintTo

AccessControlEnumerableUpgradeable

Extension of {AccessControl} that allows enumerating the members of each role.

__AccessControlEnumerable_init

__AccessControlEnumerable_init_unchained

_roleMembers

supportsInterface

See {IERC165-supportsInterface}.

getRoleMember

_Returns one of the accounts that have `role`. `index` must be a value between 0 and {getRoleMemberCount}, non-inclusive.

Role bearers are not sorted in any particular way, and their ordering may change at any point.

WARNING: When using {getRoleMember} and {getRoleMemberCount}, make sure you perform all queries on the same block. See the following https://forum.openzeppelin.com/t/iterating-over-elements-on-enumerableset-in-openzeppelin-contracts/2296[forum post] for more information._

getRoleMemberCount

Returns the number of accounts that have `role`. Can be used together with {getRoleMember} to enumerate all bearers of a role.

grantRole

Overload {grantRole} to track enumerable memberships

revokeRole

Overload {revokeRole} to track enumerable memberships

renounceRole

Overload {renounceRole} to track enumerable memberships

_setupRole

_Overload {setupRole} to track enumerable memberships

__gap

AccessControlUpgradeable

_Contract module that allows children to implement role-based access control mechanisms. This is a lightweight version that doesn't allow enumerating role members except through off-chain means by accessing the contract event logs. Some applications may benefit from on-chain enumerability, for those cases see {AccessControlEnumerable}.

Roles are referred to by their `bytes32` identifier. These should be exposed in the external API and be unique. The best way to achieve this is by using `public constant` hash digests:

``` bytes32 public constant MY_ROLE = keccak256("MY_ROLE"); ```

Roles can be used to represent a set of permissions. To restrict access to a function call, use {hasRole}:

``` function foo() public { require(hasRole(MY_ROLE, msg.sender)); ... } ```

Roles can be granted and revoked dynamically via the {grantRole} and {revokeRole} functions. Each role has an associated admin role, and only accounts that have a role's admin role can call {grantRole} and {revokeRole}.

By default, the admin role for all roles is `DEFAULT_ADMIN_ROLE`, which means that only accounts with this role will be able to grant or revoke other roles. More complex role relationships can be created by using {_setRoleAdmin}.

WARNING: The `DEFAULT_ADMIN_ROLE` is also its own admin: it has permission to grant and revoke this role. Extra precautions should be taken to secure accounts that have been granted it._

__AccessControl_init

__AccessControl_init_unchained

RoleData

_roles

DEFAULT_ADMIN_ROLE

onlyRole

_Modifier that checks that an account has a specific role. Reverts with a standardized message including the required role.

The format of the revert reason is given by the following regular expression:

/^AccessControl: account (0x[0-9a-f]{40}) is missing role (0x[0-9a-f]{64})$/

Available since v4.1._

supportsInterface

See {IERC165-supportsInterface}.

hasRole

Returns `true` if `account` has been granted `role`.

_checkRole

_Revert with a standard message if `account` is missing `role`.

The format of the revert reason is given by the following regular expression:

/^AccessControl: account (0x[0-9a-f]{40}) is missing role (0x[0-9a-f]{64})$/_

getRoleAdmin

_Returns the admin role that controls `role`. See {grantRole} and {revokeRole}.

To change a role's admin, use {setRoleAdmin}.

grantRole

_Grants `role` to `account`.

If `account` had not been already granted `role`, emits a {RoleGranted} event.

Requirements:

  • the caller must have ``role``'s admin role._

revokeRole

_Revokes `role` from `account`.

If `account` had been granted `role`, emits a {RoleRevoked} event.

Requirements:

  • the caller must have ``role``'s admin role._

renounceRole

_Revokes `role` from the calling account.

Roles are often managed via {grantRole} and {revokeRole}: this function's purpose is to provide a mechanism for accounts to lose their privileges if they are compromised (such as when a trusted device is misplaced).

If the calling account had been granted `role`, emits a {RoleRevoked} event.

Requirements:

  • the caller must be `account`._

_setupRole

_Grants `role` to `account`.

If `account` had not been already granted `role`, emits a {RoleGranted} event. Note that unlike {grantRole}, this function doesn't perform any checks on the calling account.

[WARNING] ==== This function should only be called from the constructor when setting up the initial roles for the system.

Using this function in any other way is effectively circumventing the admin system imposed by {AccessControl}. ====_

_setRoleAdmin

_Sets `adminRole` as ``role``'s admin role.

Emits a {RoleAdminChanged} event._

_grantRole

_revokeRole

__gap

IAccessControlEnumerableUpgradeable

External interface of AccessControlEnumerable declared to support ERC165 detection.

getRoleMember

_Returns one of the accounts that have `role`. `index` must be a value between 0 and {getRoleMemberCount}, non-inclusive.

Role bearers are not sorted in any particular way, and their ordering may change at any point.

WARNING: When using {getRoleMember} and {getRoleMemberCount}, make sure you perform all queries on the same block. See the following https://forum.openzeppelin.com/t/iterating-over-elements-on-enumerableset-in-openzeppelin-contracts/2296[forum post] for more information._

getRoleMemberCount

Returns the number of accounts that have `role`. Can be used together with {getRoleMember} to enumerate all bearers of a role.

IAccessControlUpgradeable

External interface of AccessControl declared to support ERC165 detection.

RoleAdminChanged

_Emitted when `newAdminRole` is set as ``role``'s admin role, replacing `previousAdminRole`

`DEFAULT_ADMIN_ROLE` is the starting admin for all roles, despite {RoleAdminChanged} not being emitted signaling this.

Available since v3.1._

RoleGranted

_Emitted when `account` is granted `role`.

`sender` is the account that originated the contract call, an admin role bearer except when using {AccessControl-setupRole}.

RoleRevoked

_Emitted when `account` is revoked `role`.

`sender` is the account that originated the contract call:

  • if using `revokeRole`, it is the admin role bearer

  • if using `renounceRole`, it is the role bearer (i.e. `account`)_

hasRole

Returns `true` if `account` has been granted `role`.

getRoleAdmin

_Returns the admin role that controls `role`. See {grantRole} and {revokeRole}.

To change a role's admin, use {AccessControl-setRoleAdmin}.

grantRole

_Grants `role` to `account`.

If `account` had not been already granted `role`, emits a {RoleGranted} event.

Requirements:

  • the caller must have ``role``'s admin role._

revokeRole

_Revokes `role` from `account`.

If `account` had been granted `role`, emits a {RoleRevoked} event.

Requirements:

  • the caller must have ``role``'s admin role._

renounceRole

_Revokes `role` from the calling account.

Roles are often managed via {grantRole} and {revokeRole}: this function's purpose is to provide a mechanism for accounts to lose their privileges if they are compromised (such as when a trusted device is misplaced).

If the calling account had been granted `role`, emits a {RoleRevoked} event.

Requirements:

  • the caller must be `account`._

OwnableUpgradeable

_Contract module which provides a basic access control mechanism, where there is an account (an owner) that can be granted exclusive access to specific functions.

By default, the owner account will be the one that deploys the contract. This can later be changed with {transferOwnership}.

This module is used through inheritance. It will make available the modifier `onlyOwner`, which can be applied to your functions to restrict their use to the owner._

_owner

OwnershipTransferred

__Ownable_init

Initializes the contract setting the deployer as the initial owner.

__Ownable_init_unchained

owner

Returns the address of the current owner.

onlyOwner

Throws if called by any account other than the owner.

renounceOwnership

_Leaves the contract without owner. It will not be possible to call `onlyOwner` functions anymore. Can only be called by the current owner.

NOTE: Renouncing ownership will leave the contract without an owner, thereby removing any functionality that is only available to the owner._

transferOwnership

Transfers ownership of the contract to a new account (`newOwner`). Can only be called by the current owner.

_setOwner

__gap

PaymentSplitterUpgradeable

_This contract allows to split Ether payments among a group of accounts. The sender does not need to be aware that the Ether will be split in this way, since it is handled transparently by the contract.

The split can be in equal parts or in any other arbitrary proportion. The way this is specified is by assigning each account to a number of shares. Of all the Ether that this contract receives, each account will then be able to claim an amount proportional to the percentage of total shares they were assigned.

`PaymentSplitter` follows a pull payment model. This means that payments are not automatically forwarded to the accounts but kept in this contract, and the actual transfer is triggered as a separate step by calling the {release} function._

PayeeAdded

PaymentReleased

PaymentReceived

_totalShares

_totalReleased

_shares

_released

_payees

__PaymentSplitter_init

_Creates an instance of `PaymentSplitter` where each account in `payees` is assigned the number of shares at the matching position in the `shares` array.

All addresses in `payees` must be non-zero. Both arrays must have the same non-zero length, and there must be no duplicates in `payees`._

__PaymentSplitter_init_unchained

receive

_The Ether received will be logged with {PaymentReceived} events. Note that these events are not fully reliable: it's possible for a contract to receive Ether without triggering this function. This only affects the reliability of the events, and not the actual splitting of Ether.

To learn more about this see the Solidity documentation for https://solidity.readthedocs.io/en/latest/contracts.html#fallback-function[fallback functions]._

totalShares

Getter for the total shares held by payees.

totalReleased

Getter for the total amount of Ether already released.

shares

Getter for the amount of shares held by an account.

released

Getter for the amount of Ether already released to a payee.

payee

Getter for the address of the payee number `index`.

release

Triggers a transfer to `account` of the amount of Ether they are owed, according to their percentage of the total shares and their previous withdrawals.

_addPayee

Add a new payee to the contract.

Name
Type
Description

account

address

The address of the payee to add.

shares_

uint256

The number of shares owned by the payee.

__gap

GovernorUpgradeable

_Core of the governance system, designed to be extended though various modules.

This contract is abstract and requires several function to be implemented in various modules:

  • A counting module must implement {quorum}, {_quorumReached}, {_voteSucceeded} and {_countVote}

  • A voting module must implement {getVotes}

  • Additionanly, the {votingPeriod} must also be implemented

Available since v4.3._

BALLOT_TYPEHASH

ProposalCore

_name

_proposals

onlyGovernance

_Restrict access to governor executing address. Some module might override the executor function to make sure this modifier is consistant with the execution model.

__Governor_init

Sets the value for {name} and {version}

__Governor_init_unchained

supportsInterface

See {IERC165-supportsInterface}.

name

See {IGovernor-name}.

version

See {IGovernor-version}.

hashProposal

_See {IGovernor-hashProposal}.

The proposal id is produced by hashing the RLC encoded `targets` array, the `values` array, the `calldatas` array and the descriptionHash (bytes32 which itself is the keccak256 hash of the description string). This proposal id can be produced from the proposal data which is part of the {ProposalCreated} event. It can even be computed in advance, before the proposal is submitted.

Note that the chainId and the governor address are not part of the proposal id computation. Consequently, the same proposal (with same operation and same description) will have the same id if submitted on multiple governors accross multiple networks. This also means that in order to execute the same operation twice (on the same governor) the proposer will have to change the description in order to avoid proposal id conflicts._

state

See {IGovernor-state}.

proposalSnapshot

See {IGovernor-proposalSnapshot}.

proposalDeadline

See {IGovernor-proposalDeadline}.

_quorumReached

Amount of votes already cast passes the threshold limit.

_voteSucceeded

Is the proposal successful or not.

_countVote

_Register a vote with a given support and voting weight.

Note: Support is generic and can represent various things depending on the voting system used._

propose

See {IGovernor-propose}.

execute

See {IGovernor-execute}.

_execute

Internal execution mechanism. Can be overriden to implement different execution mechanism

_cancel

_Internal cancel mechanism: locks up the proposal timer, preventing it from being re-submitted. Marks it as canceled to allow distinguishing it from executed proposals.

Emits a {IGovernor-ProposalCanceled} event._

castVote

See {IGovernor-castVote}.

castVoteWithReason

See {IGovernor-castVoteWithReason}.

castVoteBySig

See {IGovernor-castVoteBySig}.

_castVote

_Internal vote casting mechanism: Check that the vote is pending, that it has not been cast yet, retrieve voting weight using {IGovernor-getVotes} and call the {_countVote} internal function.

Emits a {IGovernor-VoteCast} event._

_executor

Address through which the governor executes action. Will be overloaded by module that execute actions through another contract such as a timelock.

__gap

IGovernorUpgradeable

_Interface of the {Governor} core.

Available since v4.3._

__IGovernor_init

__IGovernor_init_unchained

ProposalState

ProposalCreated

Emitted when a proposal is created.

ProposalCanceled

Emitted when a proposal is canceled.

ProposalExecuted

Emitted when a proposal is executed.

VoteCast

_Emitted when a vote is cast.

Note: `support` values should be seen as buckets. There interpretation depends on the voting module used._

name

module:core

Name of the governor instance (used in building the ERC712 domain separator).

version

module:core

Version of the governor instance (used in building the ERC712 domain separator). Default: "1"

COUNTING_MODE

module:voting

_A description of the possible `support` values for {castVote} and the way these votes are counted, meant to be consumed by UIs to show correct vote options and interpret the results. The string is a URL-encoded sequence of key-value pairs that each describe one aspect, for example `support=bravo&quorum=for,abstain`.

There are 2 standard keys: `support` and `quorum`.

  • `support=bravo` refers to the vote options 0 = For, 1 = Against, 2 = Abstain, as in `GovernorBravo`.

  • `quorum=bravo` means that only For votes are counted towards quorum.

  • `quorum=for,abstain` means that both For and Abstain votes are counted towards quorum.

NOTE: The string can be decoded by the standard https://developer.mozilla.org/en-US/docs/Web/API/URLSearchParams[`URLSearchParams`] JavaScript class._

hashProposal

module:core

Hashing function used to (re)build the proposal id from the proposal details..

state

module:core

Current state of a proposal, following Compound's convention

proposalSnapshot

module:core

block number used to retrieve user's votes and quorum.

proposalDeadline

module:core

timestamp at which votes close.

votingDelay

module:user-config

delay, in number of block, between the proposal is created and the vote starts. This can be increassed to leave time for users to buy voting power, of delegate it, before the voting of a proposal starts.

votingPeriod

module:user-config

_delay, in number of blocks, between the vote start and vote ends.

Note: the {votingDelay} can delay the start of the vote. This must be considered when setting the voting duration compared to the voting delay._

quorum

module:user-config

_Minimum number of cast voted required for a proposal to be successful.

Note: The `blockNumber` parameter corresponds to the snaphot used for counting vote. This allows to scale the quroum depending on values such as the totalSupply of a token at this block (see {ERC20Votes})._

getVotes

module:reputation

_Voting power of an `account` at a specific `blockNumber`.

Note: this can be implemented in a number of ways, for example by reading the delegated balance from one (or multiple), {ERC20Votes} tokens._

hasVoted

module:voting

Returns weither `account` has cast a vote on `proposalId`.

propose

_Create a new proposal. Vote start {IGovernor-votingDelay} blocks after the proposal is created and ends {IGovernor-votingPeriod} blocks after the voting starts.

Emits a {ProposalCreated} event._

execute

_Execute a successful proposal. This requires the quorum to be reached, the vote to be successful, and the deadline to be reached.

Emits a {ProposalExecuted} event.

Note: some module can modify the requirements for execution, for example by adding an additional timelock._

castVote

_Cast a vote

Emits a {VoteCast} event._

castVoteWithReason

_Cast a with a reason

Emits a {VoteCast} event._

castVoteBySig

_Cast a vote using the user cryptographic signature.

Emits a {VoteCast} event._

__gap

TimelockControllerUpgradeable

_Contract module which acts as a timelocked controller. When set as the owner of an `Ownable` smart contract, it enforces a timelock on all `onlyOwner` maintenance operations. This gives time for users of the controlled contract to exit before a potentially dangerous maintenance operation is applied.

By default, this contract is self administered, meaning administration tasks have to go through the timelock process. The proposer (resp executor) role is in charge of proposing (resp executing) operations. A common use case is to position this {TimelockController} as the owner of a smart contract, with a multisig or a DAO as the sole proposer.

Available since v3.3._

TIMELOCK_ADMIN_ROLE

PROPOSER_ROLE

EXECUTOR_ROLE

_DONE_TIMESTAMP

_timestamps

_minDelay

CallScheduled

Emitted when a call is scheduled as part of operation `id`.

CallExecuted

Emitted when a call is performed as part of operation `id`.

Cancelled

Emitted when operation `id` is cancelled.

MinDelayChange

Emitted when the minimum delay for future operations is modified.

__TimelockController_init

Initializes the contract with a given `minDelay`.

__TimelockController_init_unchained

onlyRoleOrOpenRole

Modifier to make a function callable only by a certain role. In addition to checking the sender's role, `address(0)` 's role is also considered. Granting a role to `address(0)` is equivalent to enabling this role for everyone.

receive

Contract might receive/hold ETH as part of the maintenance process.

isOperation

Returns whether an id correspond to a registered operation. This includes both Pending, Ready and Done operations.

isOperationPending

Returns whether an operation is pending or not.

isOperationReady

Returns whether an operation is ready or not.

isOperationDone

Returns whether an operation is done or not.

getTimestamp

Returns the timestamp at with an operation becomes ready (0 for unset operations, 1 for done operations).

getMinDelay

_Returns the minimum delay for an operation to become valid.

This value can be changed by executing an operation that calls `updateDelay`._

hashOperation

Returns the identifier of an operation containing a single transaction.

hashOperationBatch

Returns the identifier of an operation containing a batch of transactions.

schedule

_Schedule an operation containing a single transaction.

Emits a {CallScheduled} event.

Requirements:

  • the caller must have the 'proposer' role._

scheduleBatch

_Schedule an operation containing a batch of transactions.

Emits one {CallScheduled} event per transaction in the batch.

Requirements:

  • the caller must have the 'proposer' role._

_schedule

Schedule an operation that is to becomes valid after a given delay.

cancel

_Cancel an operation.

Requirements:

  • the caller must have the 'proposer' role._

execute

_Execute an (ready) operation containing a single transaction.

Emits a {CallExecuted} event.

Requirements:

  • the caller must have the 'executor' role._

executeBatch

_Execute an (ready) operation containing a batch of transactions.

Emits one {CallExecuted} event per transaction in the batch.

Requirements:

  • the caller must have the 'executor' role._

_beforeCall

Checks before execution of an operation's calls.

_afterCall

Checks after execution of an operation's calls.

_call

_Execute an operation's call.

Emits a {CallExecuted} event._

updateDelay

_Changes the minimum timelock duration for future operations.

Emits a {MinDelayChange} event.

Requirements:

  • the caller must be the timelock itself. This can only be achieved by scheduling and later executing an operation where the timelock is the target and the data is the ABI-encoded call to this function._

__gap

GovernorCompatibilityBravoUpgradeable

_Compatibility layer that implements GovernorBravo compatibility on to of {Governor}.

This compatibility layer includes a voting system and requires a {IGovernorTimelock} compatible module to be added through inheritance. It does not include token bindings, not does it include any variable upgrade patterns.

Available since v4.3._

__GovernorCompatibilityBravo_init

__GovernorCompatibilityBravo_init_unchained

VoteType

ProposalDetails

_proposalDetails

COUNTING_MODE

module:voting

_A description of the possible `support` values for {castVote} and the way these votes are counted, meant to be consumed by UIs to show correct vote options and interpret the results. The string is a URL-encoded sequence of key-value pairs that each describe one aspect, for example `support=bravo&quorum=for,abstain`.

There are 2 standard keys: `support` and `quorum`.

  • `support=bravo` refers to the vote options 0 = For, 1 = Against, 2 = Abstain, as in `GovernorBravo`.

  • `quorum=bravo` means that only For votes are counted towards quorum.

  • `quorum=for,abstain` means that both For and Abstain votes are counted towards quorum.

NOTE: The string can be decoded by the standard https://developer.mozilla.org/en-US/docs/Web/API/URLSearchParams[`URLSearchParams`] JavaScript class._

propose

See {IGovernor-propose}.

propose

See {IGovernorCompatibilityBravo-propose}.

queue

See {IGovernorCompatibilityBravo-queue}.

execute

See {IGovernorCompatibilityBravo-execute}.

cancel

Cancels a proposal only if sender is the proposer, or proposer delegates dropped below proposal threshold.

_encodeCalldata

Encodes calldatas with optional function signature.

_storeProposal

Store proposal metadata for later lookup

proposalThreshold

Part of the Governor Bravo's interface: "The number of votes required in order for a voter to become a proposer".

proposals

See {IGovernorCompatibilityBravo-proposals}.

getActions

See {IGovernorCompatibilityBravo-getActions}.

getReceipt

See {IGovernorCompatibilityBravo-getReceipt}.

quorumVotes

See {IGovernorCompatibilityBravo-quorumVotes}.

hasVoted

See {IGovernor-hasVoted}.

_quorumReached

_See {Governor-quorumReached}. In this module, only forVotes count toward the quorum.

_voteSucceeded

_See {Governor-voteSucceeded}. In this module, the forVotes must be scritly over the againstVotes.

_countVote

_See {Governor-countVote}. In this module, the support follows Governor Bravo.

__gap

IGovernorCompatibilityBravoUpgradeable

_Interface extension that adds missing functions to the {Governor} core to provide `GovernorBravo` compatibility.

Available since v4.3._

__IGovernorCompatibilityBravo_init

__IGovernorCompatibilityBravo_init_unchained

Proposal

Receipt

quorumVotes

Part of the Governor Bravo's interface.

proposals

Part of the Governor Bravo's interface: "The official record of all proposals ever proposed".

propose

Part of the Governor Bravo's interface: "Function used to propose a new proposal".

queue

Part of the Governor Bravo's interface: "Queues a proposal of state succeeded".

execute

Part of the Governor Bravo's interface: "Executes a queued proposal if eta has passed".

cancel

Cancels a proposal only if sender is the proposer, or proposer delegates dropped below proposal threshold.

getActions

Part of the Governor Bravo's interface: "Gets actions of a proposal".

getReceipt

Part of the Governor Bravo's interface: "Gets the receipt for a voter on a given proposal".

proposalThreshold

Part of the Governor Bravo's interface: "The number of votes required in order for a voter to become a proposer".

__gap

GovernorCountingSimpleUpgradeable

_Extension of {Governor} for simple, 3 options, vote counting.

Available since v4.3._

__GovernorCountingSimple_init

__GovernorCountingSimple_init_unchained

VoteType

ProposalVote

_proposalVotes

COUNTING_MODE

See {IGovernor-COUNTING_MODE}.

hasVoted

See {IGovernor-hasVoted}.

proposalVotes

Accessor to the internal vote counts.

_quorumReached

_See {Governor-quorumReached}.

_voteSucceeded

_See {Governor-voteSucceeded}. In this module, the forVotes must be scritly over the againstVotes.

_countVote

_See {Governor-countVote}. In this module, the support follows the `VoteType` enum (from Governor Bravo).

__gap

GovernorProposalThresholdUpgradeable

_Extension of {Governor} for proposal restriction to token holders with a minimum balance.

Available since v4.3._

__GovernorProposalThreshold_init

__GovernorProposalThreshold_init_unchained

propose

See {IGovernor-propose}.

proposalThreshold

Part of the Governor Bravo's interface: "The number of votes required in order for a voter to become a proposer".

__gap

ICompoundTimelockUpgradeable

https://github.com/compound-finance/compound-protocol/blob/master/contracts/Timelock.sol[Compound's timelock] interface

receive

GRACE_PERIOD

MINIMUM_DELAY

MAXIMUM_DELAY

admin

pendingAdmin

delay

queuedTransactions

setDelay

acceptAdmin

setPendingAdmin

queueTransaction

cancelTransaction

executeTransaction

GovernorTimelockCompoundUpgradeable

_Extension of {Governor} that binds the execution process to a Compound Timelock. This adds a delay, enforced by the external timelock to all successful proposal (in addition to the voting duration). The {Governor} needs to be the admin of the timelock for any operation to be performed. A public, unrestricted, {GovernorTimelockCompound-__acceptAdmin} is available to accept ownership of the timelock.

Using this model means the proposal will be operated by the {TimelockController} and not by the {Governor}. Thus, the assets and permissions must be attached to the {TimelockController}. Any asset sent to the {Governor} will be inaccessible.

Available since v4.3._

ProposalTimelock

_timelock

_proposalTimelocks

TimelockChange

Emitted when the timelock controller used for proposal execution is modified.

__GovernorTimelockCompound_init

Set the timelock.

__GovernorTimelockCompound_init_unchained

supportsInterface

See {IERC165-supportsInterface}.

state

Overriden version of the {Governor-state} function with added support for the `Queued` and `Expired` status.

timelock

Public accessor to check the address of the timelock

proposalEta

Public accessor to check the eta of a queued proposal

queue

Function to queue a proposal to the timelock.

_execute

Overriden execute function that run the already queued proposal through the timelock.

_cancel

_Overriden version of the {Governor-cancel} function to cancel the timelocked proposal if it as already been queued.

_executor

Address through which the governor executes action. In this case, the timelock.

__acceptAdmin

Accept admin right over the timelock.

updateTimelock

_Public endpoint to update the underlying timelock instance. Restricted to the timelock itself, so updates must be proposed, scheduled and executed using the {Governor} workflow.

For security reason, the timelock must be handed over to another admin before setting up a new one. The two operations (hand over the timelock) and do the update can be batched in a single proposal.

Note that if the timelock admin has been handed over in a previous operation, we refuse updates made through the timelock if admin of the timelock has already been accepted and the operation is executed outside the scope of governance._

_updateTimelock

__gap

GovernorTimelockControlUpgradeable

_Extension of {Governor} that binds the execution process to an instance of {TimelockController}. This adds a delay, enforced by the {TimelockController} to all successful proposal (in addition to the voting duration). The {Governor} needs the proposer (an ideally the executor) roles for the {Governor} to work properly.

Using this model means the proposal will be operated by the {TimelockController} and not by the {Governor}. Thus, the assets and permissions must be attached to the {TimelockController}. Any asset sent to the {Governor} will be inaccessible.

Available since v4.3._

_timelock

_timelockIds

TimelockChange

Emitted when the timelock controller used for proposal execution is modified.

__GovernorTimelockControl_init

Set the timelock.

__GovernorTimelockControl_init_unchained

supportsInterface

See {IERC165-supportsInterface}.

state

Overriden version of the {Governor-state} function with added support for the `Queued` status.

timelock

Public accessor to check the address of the timelock

proposalEta

Public accessor to check the eta of a queued proposal

queue

Function to queue a proposal to the timelock.

_execute

Overriden execute function that run the already queued proposal through the timelock.

_cancel

_Overriden version of the {Governor-cancel} function to cancel the timelocked proposal if it as already been queued.

_executor

Address through which the governor executes action. In this case, the timelock.

updateTimelock

Public endpoint to update the underlying timelock instance. Restricted to the timelock itself, so updates must be proposed, scheduled and executed using the {Governor} workflow.

_updateTimelock

__gap

GovernorVotesCompUpgradeable

_Extension of {Governor} for voting weight extraction from a Comp token.

Available since v4.3._

token

__GovernorVotesComp_init

__GovernorVotesComp_init_unchained

getVotes

Read the voting weight from the token's built in snapshot mechanism (see {IGovernor-getVotes}).

__gap

GovernorVotesQuorumFractionUpgradeable

_Extension of {Governor} for voting weight extraction from an {ERC20Votes} token and a quorum expressed as a fraction of the total supply.

Available since v4.3._

_quorumNumerator

QuorumNumeratorUpdated

__GovernorVotesQuorumFraction_init

__GovernorVotesQuorumFraction_init_unchained

quorumNumerator

quorumDenominator

quorum

module:user-config

_Minimum number of cast voted required for a proposal to be successful.

Note: The `blockNumber` parameter corresponds to the snaphot used for counting vote. This allows to scale the quroum depending on values such as the totalSupply of a token at this block (see {ERC20Votes})._

updateQuorumNumerator

_updateQuorumNumerator

__gap

GovernorVotesUpgradeable

_Extension of {Governor} for voting weight extraction from an {ERC20Votes} token.

Available since v4.3._

token

__GovernorVotes_init

__GovernorVotes_init_unchained

getVotes

Read the voting weight from the token's built in snapshot mechanism (see {IGovernor-getVotes}).

__gap

IGovernorTimelockUpgradeable

_Extension of the {IGovernor} for timelock supporting modules.

Available since v4.3._

__IGovernorTimelock_init

__IGovernorTimelock_init_unchained

ProposalQueued

timelock

proposalEta

queue

__gap

IERC1271Upgradeable

_Interface of the ERC1271 standard signature validation method for contracts as defined in https://eips.ethereum.org/EIPS/eip-1271[ERC-1271].

Available since v4.1._

isValidSignature

Should return whether the signature provided is valid for the provided data

Name
Type
Description

hash

bytes32

Hash of the data to be signed

signature

bytes

Signature byte array associated with _data

IERC1363Upgradeable

transferAndCall

Transfer tokens from `msg.sender` to another address and then call `onTransferReceived` on receiver

Name
Type
Description

to

address

address The address which you want to transfer to

value

uint256

uint256 The amount of tokens to be transferred

Name
Type
Description

[0]

bool

true unless throwing

transferAndCall

Transfer tokens from `msg.sender` to another address and then call `onTransferReceived` on receiver

Name
Type
Description

to

address

address The address which you want to transfer to

value

uint256

uint256 The amount of tokens to be transferred

data

bytes

bytes Additional data with no specified format, sent in call to `to`

Name
Type
Description

[0]

bool

true unless throwing

transferFromAndCall

Transfer tokens from one address to another and then call `onTransferReceived` on receiver

Name
Type
Description

from

address

address The address which you want to send tokens from

to

address

address The address which you want to transfer to

value

uint256

uint256 The amount of tokens to be transferred

Name
Type
Description

[0]

bool

true unless throwing

transferFromAndCall

Transfer tokens from one address to another and then call `onTransferReceived` on receiver

Name
Type
Description

from

address

address The address which you want to send tokens from

to

address

address The address which you want to transfer to

value

uint256

uint256 The amount of tokens to be transferred

data

bytes

bytes Additional data with no specified format, sent in call to `to`

Name
Type
Description

[0]

bool

true unless throwing

approveAndCall

Approve the passed address to spend the specified amount of tokens on behalf of msg.sender and then call `onApprovalReceived` on spender.

Name
Type
Description

spender

address

address The address which will spend the funds

value

uint256

uint256 The amount of tokens to be spent

approveAndCall

Approve the passed address to spend the specified amount of tokens on behalf of msg.sender and then call `onApprovalReceived` on spender.

Name
Type
Description

spender

address

address The address which will spend the funds

value

uint256

uint256 The amount of tokens to be spent

data

bytes

bytes Additional data with no specified format, sent in call to `spender`

IERC2981Upgradeable

Interface for the NFT Royalty Standard

royaltyInfo

Called with the sale price to determine how much royalty is owed and to whom.

Name
Type
Description

tokenId

uint256

- the NFT asset queried for royalty information

salePrice

uint256

- the sale price of the NFT asset specified by `tokenId`

Name
Type
Description

receiver

address

- address of who should be sent the royalty payment

royaltyAmount

uint256

- the royalty payment amount for `salePrice`

IERC3156FlashBorrowerUpgradeable

_Interface of the ERC3156 FlashBorrower, as defined in https://eips.ethereum.org/EIPS/eip-3156[ERC-3156].

Available since v4.1._

onFlashLoan

Receive a flash loan.

Name
Type
Description

initiator

address

The initiator of the loan.

token

address

The loan currency.

amount

uint256

The amount of tokens lent.

fee

uint256

The additional amount of tokens to repay.

data

bytes

Arbitrary data structure, intended to contain user-defined parameters.

Name
Type
Description

[0]

bytes32

The keccak256 hash of "ERC3156FlashBorrower.onFlashLoan"

IERC3156FlashLenderUpgradeable

_Interface of the ERC3156 FlashLender, as defined in https://eips.ethereum.org/EIPS/eip-3156[ERC-3156].

Available since v4.1._

maxFlashLoan

The amount of currency available to be lended.

Name
Type
Description

token

address

The loan currency.

Name
Type
Description

[0]

uint256

The amount of `token` that can be borrowed.

flashFee

The fee to be charged for a given loan.

Name
Type
Description

token

address

The loan currency.

amount

uint256

The amount of tokens lent.

Name
Type
Description

[0]

uint256

The amount of `token` to be charged for the loan, on top of the returned principal.

flashLoan

Initiate a flash loan.

Name
Type
Description

receiver

contract IERC3156FlashBorrowerUpgradeable

The receiver of the tokens in the loan, and the receiver of the callback.

token

address

The loan currency.

amount

uint256

The amount of tokens lent.

data

bytes

Arbitrary data structure, intended to contain user-defined parameters.

IERC2612Upgradeable

ERC2771ContextUpgradeable

Context variant with ERC2771 support.

_trustedForwarder

__ERC2771Context_init

__ERC2771Context_init_unchained

isTrustedForwarder

_msgSender

_msgData

__gap

MinimalForwarderUpgradeable

Simple minimal forwarder to be used together with an ERC2771 compatible contract. See {ERC2771Context}.

ForwardRequest

_TYPEHASH

_nonces

__MinimalForwarder_init

__MinimalForwarder_init_unchained

getNonce

verify

execute

__gap

ERC1967UpgradeUpgradeable

_This abstract contract provides getters and event emitting update functions for https://eips.ethereum.org/EIPS/eip-1967[EIP1967] slots.

Available since v4.1._

__ERC1967Upgrade_init

__ERC1967Upgrade_init_unchained

_ROLLBACK_SLOT

_IMPLEMENTATION_SLOT

Storage slot with the address of the current implementation. This is the keccak-256 hash of "eip1967.proxy.implementation" subtracted by 1, and is validated in the constructor.

Upgraded

Emitted when the implementation is upgraded.

_getImplementation

Returns the current implementation address.

_setImplementation

Stores a new address in the EIP1967 implementation slot.

_upgradeTo

_Perform implementation upgrade

Emits an {Upgraded} event._

_upgradeToAndCall

_Perform implementation upgrade with additional setup call.

Emits an {Upgraded} event._

_upgradeToAndCallSecure

_Perform implementation upgrade with security checks for UUPS proxies, and additional setup call.

Emits an {Upgraded} event._

_ADMIN_SLOT

Storage slot with the admin of the contract. This is the keccak-256 hash of "eip1967.proxy.admin" subtracted by 1, and is validated in the constructor.

AdminChanged

Emitted when the admin account has changed.

_getAdmin

Returns the current admin.

_setAdmin

Stores a new address in the EIP1967 admin slot.

_changeAdmin

_Changes the admin of the proxy.

Emits an {AdminChanged} event._

_BEACON_SLOT

The storage slot of the UpgradeableBeacon contract which defines the implementation for this proxy. This is bytes32(uint256(keccak256('eip1967.proxy.beacon')) - 1)) and is validated in the constructor.

BeaconUpgraded

Emitted when the beacon is upgraded.

_getBeacon

Returns the current beacon.

_setBeacon

Stores a new beacon in the EIP1967 beacon slot.

_upgradeBeaconToAndCall

_Perform beacon upgrade with additional setup call. Note: This upgrades the address of the beacon, it does not upgrade the implementation contained in the beacon (see {UpgradeableBeacon-_setImplementation} for that).

Emits a {BeaconUpgraded} event._

_functionDelegateCall

_Same as {xref-Address-functionCall-address-bytes-string-}[`functionCall`], but performing a delegate call.

Available since v3.4._

__gap

IBeaconUpgradeable

This is the interface that {BeaconProxy} expects of its beacon.

implementation

_Must return an address that can be used as a delegate call target.

{BeaconProxy} will check that this address is a contract._

Initializable

_This is a base contract to aid in writing upgradeable contracts, or any kind of contract that will be deployed behind a proxy. Since a proxied contract can't have a constructor, it's common to move constructor logic to an external initializer function, usually called `initialize`. It then becomes necessary to protect this initializer function so it can only be called once. The {initializer} modifier provided by this contract will have this effect.

TIP: To avoid leaving the proxy in an uninitialized state, the initializer function should be called as early as possible by providing the encoded function call as the `_data` argument to {ERC1967Proxy-constructor}.

CAUTION: When used with inheritance, manual care must be taken to not invoke a parent initializer twice, or to ensure that all initializers are idempotent. This is not verified automatically as constructors are by Solidity._

_initialized

Indicates that the contract has been initialized.

_initializing

Indicates that the contract is in the process of being initialized.

initializer

Modifier to protect an initializer function from being invoked twice.

UUPSUpgradeable

_An upgradeability mechanism designed for UUPS proxies. The functions included here can perform an upgrade of an {ERC1967Proxy}, when this contract is set as the implementation behind such a proxy.

A security mechanism ensures that an upgrade does not turn off upgradeability accidentally, although this risk is reinstated if the upgrade retains upgradeability but removes the security mechanism, e.g. by replacing `UUPSUpgradeable` with a custom implementation of upgrades.

The {_authorizeUpgrade} function must be overridden to include access restriction to the upgrade mechanism.

Available since v4.1._

__UUPSUpgradeable_init

__UUPSUpgradeable_init_unchained

upgradeTo

_Upgrade the implementation of the proxy to `newImplementation`.

Calls {_authorizeUpgrade}.

Emits an {Upgraded} event._

upgradeToAndCall

_Upgrade the implementation of the proxy to `newImplementation`, and subsequently execute the function call encoded in `data`.

Calls {_authorizeUpgrade}.

Emits an {Upgraded} event._

_authorizeUpgrade

_Function that should revert when `msg.sender` is not authorized to upgrade the contract. Called by {upgradeTo} and {upgradeToAndCall}.

Normally, this function will use an xref:access.adoc[access control] modifier such as {Ownable-onlyOwner}.

```solidity function authorizeUpgrade(address) internal override onlyOwner {} ```

__gap

PausableUpgradeable

_Contract module which allows children to implement an emergency stop mechanism that can be triggered by an authorized account.

This module is used through inheritance. It will make available the modifiers `whenNotPaused` and `whenPaused`, which can be applied to the functions of your contract. Note that they will not be pausable by simply including this module, only once the modifiers are put in place._

Paused

Emitted when the pause is triggered by `account`.

Unpaused

Emitted when the pause is lifted by `account`.

_paused

__Pausable_init

Initializes the contract in unpaused state.

__Pausable_init_unchained

paused

Returns true if the contract is paused, and false otherwise.

whenNotPaused

_Modifier to make a function callable only when the contract is not paused.

Requirements:

  • The contract must not be paused._

whenPaused

_Modifier to make a function callable only when the contract is paused.

Requirements:

  • The contract must be paused._

_pause

_Triggers stopped state.

Requirements:

  • The contract must not be paused._

_unpause

_Returns to normal state.

Requirements:

  • The contract must be paused._

__gap

PullPaymentUpgradeable

_Simple implementation of a https://consensys.github.io/smart-contract-best-practices/recommendations/#favor-pull-over-push-for-external-calls[pull-payment] strategy, where the paying contract doesn't interact directly with the receiver account, which must withdraw its payments itself.

Pull-payments are often considered the best practice when it comes to sending Ether, security-wise. It prevents recipients from blocking execution, and eliminates reentrancy concerns.

TIP: If you would like to learn more about reentrancy and alternative ways to protect against it, check out our blog post https://blog.openzeppelin.com/reentrancy-after-istanbul/[Reentrancy After Istanbul].

To use, derive from the `PullPayment` contract, and use {asyncTransfer} instead of Solidity's `transfer` function. Payees can query their due payments with {payments}, and retrieve them with {withdrawPayments}.

_escrow

__PullPayment_init

__PullPayment_init_unchained

withdrawPayments

_Withdraw accumulated payments, forwarding all gas to the recipient.

Note that any account can call this function, not just the `payee`. This means that contracts unaware of the `PullPayment` protocol can still receive funds this way, by having a separate account call {withdrawPayments}.

WARNING: Forwarding all gas opens the door to reentrancy vulnerabilities. Make sure you trust the recipient, or are either following the checks-effects-interactions pattern or using {ReentrancyGuard}._

Name
Type
Description

payee

address payable

Whose payments will be withdrawn.

payments

Returns the payments owed to an address.

Name
Type
Description

dest

address

The creditor's address.

_asyncTransfer

Called by the payer to store the sent amount as credit to be pulled. Funds sent in this way are stored in an intermediate {Escrow} contract, so there is no danger of them being spent before withdrawal.

Name
Type
Description

dest

address

The destination address of the funds.

amount

uint256

The amount to transfer.

__gap

ReentrancyGuardUpgradeable

_Contract module that helps prevent reentrant calls to a function.

Inheriting from `ReentrancyGuard` will make the {nonReentrant} modifier available, which can be applied to functions to make sure there are no nested (reentrant) calls to them.

Note that because there is a single `nonReentrant` guard, functions marked as `nonReentrant` may not call one another. This can be worked around by making those functions `private`, and then adding `external` `nonReentrant` entry points to them.

TIP: If you would like to learn more about reentrancy and alternative ways to protect against it, check out our blog post https://blog.openzeppelin.com/reentrancy-after-istanbul/[Reentrancy After Istanbul]._

_NOT_ENTERED

_ENTERED

_status

__ReentrancyGuard_init

__ReentrancyGuard_init_unchained

nonReentrant

Prevents a contract from calling itself, directly or indirectly. Calling a `nonReentrant` function from another `nonReentrant` function is not supported. It is possible to prevent this from happening by making the `nonReentrant` function external, and make it call a `private` function that does the actual work.

__gap

ERC1155Upgradeable

_Implementation of the basic standard multi-token. See https://eips.ethereum.org/EIPS/eip-1155 Originally based on code by Enjin: https://github.com/enjin/erc-1155

Available since v3.1._

_balances

_operatorApprovals

_uri

__ERC1155_init

_See {setURI}.

__ERC1155_init_unchained

supportsInterface

See {IERC165-supportsInterface}.

uri

_See {IERC1155MetadataURI-uri}.

This implementation returns the same URI for all token types. It relies on the token type ID substitution mechanism https://eips.ethereum.org/EIPS/eip-1155#metadata[defined in the EIP].

Clients calling this function must replace the `{id}` substring with the actual token type ID._

balanceOf

_See {IERC1155-balanceOf}.

Requirements:

  • `account` cannot be the zero address._

balanceOfBatch

_See {IERC1155-balanceOfBatch}.

Requirements:

  • `accounts` and `ids` must have the same length._

setApprovalForAll

See {IERC1155-setApprovalForAll}.

isApprovedForAll

See {IERC1155-isApprovedForAll}.

safeTransferFrom

See {IERC1155-safeTransferFrom}.

safeBatchTransferFrom

See {IERC1155-safeBatchTransferFrom}.

_safeTransferFrom

_Transfers `amount` tokens of token type `id` from `from` to `to`.

Emits a {TransferSingle} event.

Requirements:

  • `to` cannot be the zero address.

  • `from` must have a balance of tokens of type `id` of at least `amount`.

  • If `to` refers to a smart contract, it must implement {IERC1155Receiver-onERC1155Received} and return the acceptance magic value._

_safeBatchTransferFrom

_xref:ROOT:erc1155.adoc#batch-operations[Batched] version of {_safeTransferFrom}.

Emits a {TransferBatch} event.

Requirements:

  • If `to` refers to a smart contract, it must implement {IERC1155Receiver-onERC1155BatchReceived} and return the acceptance magic value._

_setURI

_Sets a new URI for all token types, by relying on the token type ID substitution mechanism https://eips.ethereum.org/EIPS/eip-1155#metadata[defined in the EIP].

By this mechanism, any occurrence of the `{id}` substring in either the URI or any of the amounts in the JSON file at said URI will be replaced by clients with the token type ID.

For example, the `https://token-cdn-domain/{id}.json` URI would be interpreted by clients as `https://token-cdn-domain/000000000000000000000000000000000000000000000000000000000004cce0.json` for token type ID 0x4cce0.

See {uri}.

Because these URIs cannot be meaningfully represented by the {URI} event, this function emits no events._

_mint

_Creates `amount` tokens of token type `id`, and assigns them to `account`.

Emits a {TransferSingle} event.

Requirements:

  • `account` cannot be the zero address.

  • If `account` refers to a smart contract, it must implement {IERC1155Receiver-onERC1155Received} and return the acceptance magic value._

_mintBatch

_xref:ROOT:erc1155.adoc#batch-operations[Batched] version of {_mint}.

Requirements:

  • `ids` and `amounts` must have the same length.

  • If `to` refers to a smart contract, it must implement {IERC1155Receiver-onERC1155BatchReceived} and return the acceptance magic value._

_burn

_Destroys `amount` tokens of token type `id` from `account`

Requirements:

  • `account` cannot be the zero address.

  • `account` must have at least `amount` tokens of token type `id`._

_burnBatch

_xref:ROOT:erc1155.adoc#batch-operations[Batched] version of {_burn}.

Requirements:

  • `ids` and `amounts` must have the same length._

_beforeTokenTransfer

_Hook that is called before any token transfer. This includes minting and burning, as well as batched variants.

The same hook is called on both single and batched variants. For single transfers, the length of the `id` and `amount` arrays will be 1.

Calling conditions (for each `id` and `amount` pair):

  • When `from` and `to` are both non-zero, `amount` of ``from``'s tokens of token type `id` will be transferred to `to`.

  • When `from` is zero, `amount` tokens of token type `id` will be minted for `to`.

  • when `to` is zero, `amount` of ``from``'s tokens of token type `id` will be burned.

  • `from` and `to` are never both zero.

  • `ids` and `amounts` have the same, non-zero length.

To learn more about hooks, head to xref:ROOT:extending-contracts.adoc#using-hooks[Using Hooks]._

_doSafeTransferAcceptanceCheck

_doSafeBatchTransferAcceptanceCheck

_asSingletonArray

__gap

IERC1155ReceiverUpgradeable

Available since v3.1.

onERC1155Received

Handles the receipt of a single ERC1155 token type. This function is called at the end of a `safeTransferFrom` after the balance has been updated. To accept the transfer, this must return `bytes4(keccak256("onERC1155Received(address,address,uint256,uint256,bytes)"))` (i.e. 0xf23a6e61, or its own function selector). @param operator The address which initiated the transfer (i.e. msg.sender) @param from The address which previously owned the token @param id The ID of the token being transferred @param value The amount of tokens being transferred @param data Additional data with no specified format @return `bytes4(keccak256("onERC1155Received(address,address,uint256,uint256,bytes)"))` if transfer is allowed

onERC1155BatchReceived

Handles the receipt of a multiple ERC1155 token types. This function is called at the end of a `safeBatchTransferFrom` after the balances have been updated. To accept the transfer(s), this must return `bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)"))` (i.e. 0xbc197c81, or its own function selector). @param operator The address which initiated the batch transfer (i.e. msg.sender) @param from The address which previously owned the token @param ids An array containing ids of each token being transferred (order and length must match values array) @param values An array containing amounts of each token being transferred (order and length must match ids array) @param data Additional data with no specified format @return `bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)"))` if transfer is allowed

IERC1155Upgradeable

_Required interface of an ERC1155 compliant contract, as defined in the https://eips.ethereum.org/EIPS/eip-1155[EIP].

Available since v3.1._

TransferSingle

Emitted when `value` tokens of token type `id` are transferred from `from` to `to` by `operator`.

TransferBatch

Equivalent to multiple {TransferSingle} events, where `operator`, `from` and `to` are the same for all transfers.

ApprovalForAll

Emitted when `account` grants or revokes permission to `operator` to transfer their tokens, according to `approved`.

URI

_Emitted when the URI for token type `id` changes to `value`, if it is a non-programmatic URI.

If an {URI} event was emitted for `id`, the standard https://eips.ethereum.org/EIPS/eip-1155#metadata-extensions[guarantees] that `value` will equal the value returned by {IERC1155MetadataURI-uri}._

balanceOf

_Returns the amount of tokens of token type `id` owned by `account`.

Requirements:

  • `account` cannot be the zero address._

balanceOfBatch

_xref:ROOT:erc1155.adoc#batch-operations[Batched] version of {balanceOf}.

Requirements:

  • `accounts` and `ids` must have the same length._

setApprovalForAll

_Grants or revokes permission to `operator` to transfer the caller's tokens, according to `approved`,

Emits an {ApprovalForAll} event.

Requirements:

  • `operator` cannot be the caller._

isApprovedForAll

_Returns true if `operator` is approved to transfer ``account``'s tokens.

See {setApprovalForAll}._

safeTransferFrom

_Transfers `amount` tokens of token type `id` from `from` to `to`.

Emits a {TransferSingle} event.

Requirements:

  • `to` cannot be the zero address.

  • If the caller is not `from`, it must be have been approved to spend ``from``'s tokens via {setApprovalForAll}.

  • `from` must have a balance of tokens of type `id` of at least `amount`.

  • If `to` refers to a smart contract, it must implement {IERC1155Receiver-onERC1155Received} and return the acceptance magic value._

safeBatchTransferFrom

_xref:ROOT:erc1155.adoc#batch-operations[Batched] version of {safeTransferFrom}.

Emits a {TransferBatch} event.

Requirements:

  • `ids` and `amounts` must have the same length.

  • If `to` refers to a smart contract, it must implement {IERC1155Receiver-onERC1155BatchReceived} and return the acceptance magic value._

ERC1155BurnableUpgradeable

_Extension of {ERC1155} that allows token holders to destroy both their own tokens and those that they have been approved to use.

Available since v3.1._

__ERC1155Burnable_init

__ERC1155Burnable_init_unchained

burn

burnBatch

__gap

ERC1155PausableUpgradeable

_ERC1155 token with pausable token transfers, minting and burning.

Useful for scenarios such as preventing trades until the end of an evaluation period, or having an emergency switch for freezing all token transfers in the event of a large bug.

Available since v3.1._

__ERC1155Pausable_init

__ERC1155Pausable_init_unchained

_beforeTokenTransfer

_See {ERC1155-_beforeTokenTransfer}.

Requirements:

  • the contract must not be paused._

__gap

ERC1155SupplyUpgradeable

_Extension of ERC1155 that adds tracking of total supply per id.

Useful for scenarios where Fungible and Non-fungible tokens have to be clearly identified. Note: While a totalSupply of 1 might mean the corresponding is an NFT, there is no guarantees that no other token with the same id are not going to be minted._

__ERC1155Supply_init

__ERC1155Supply_init_unchained

_totalSupply

totalSupply

Total amount of tokens in with a given id.

exists

Indicates weither any token exist with a given id, or not.

_mint

_See {ERC1155-mint}.

_mintBatch

_See {ERC1155-mintBatch}.

_burn

_See {ERC1155-burn}.

_burnBatch

_See {ERC1155-burnBatch}.

__gap

IERC1155MetadataURIUpgradeable

_Interface of the optional ERC1155MetadataExtension interface, as defined in the https://eips.ethereum.org/EIPS/eip-1155#metadata-extensions[EIP].

Available since v3.1._

uri

_Returns the URI for token type `id`.

If the `{id}` substring is present in the URI, it must be replaced by clients with the actual token type ID._

ERC1155PresetMinterPauserUpgradeable

_{ERC1155} token, including:

  • ability for holders to burn (destroy) their tokens

  • a minter role that allows for token minting (creation)

  • a pauser role that allows to stop all token transfers

This contract uses {AccessControl} to lock permissioned functions using the different roles - head to its documentation for details.

The account that deploys the contract will be granted the minter and pauser roles, as well as the default admin role, which will let it grant both minter and pauser roles to other accounts._

initialize

MINTER_ROLE

PAUSER_ROLE

__ERC1155PresetMinterPauser_init

Grants `DEFAULT_ADMIN_ROLE`, `MINTER_ROLE`, and `PAUSER_ROLE` to the account that deploys the contract.

__ERC1155PresetMinterPauser_init_unchained

mint

_Creates `amount` new tokens for `to`, of token type `id`.

See {ERC1155-_mint}.

Requirements:

  • the caller must have the `MINTER_ROLE`._

mintBatch

xref:ROOT:erc1155.adoc#batch-operations[Batched] variant of {mint}.

pause

_Pauses all token transfers.

See {ERC1155Pausable} and {Pausable-_pause}.

Requirements:

  • the caller must have the `PAUSER_ROLE`._

unpause

_Unpauses all token transfers.

See {ERC1155Pausable} and {Pausable-_unpause}.

Requirements:

  • the caller must have the `PAUSER_ROLE`._

supportsInterface

See {IERC165-supportsInterface}.

_beforeTokenTransfer

__gap

ERC1155HolderUpgradeable

Available since v3.1.

__ERC1155Holder_init

__ERC1155Holder_init_unchained

onERC1155Received

onERC1155BatchReceived

__gap

ERC1155ReceiverUpgradeable

Available since v3.1.

__ERC1155Receiver_init

__ERC1155Receiver_init_unchained

supportsInterface

See {IERC165-supportsInterface}.

__gap

ERC20Upgradeable

_Implementation of the {IERC20} interface.

This implementation is agnostic to the way tokens are created. This means that a supply mechanism has to be added in a derived contract using {_mint}. For a generic mechanism see {ERC20PresetMinterPauser}.

TIP: For a detailed writeup see our guide https://forum.zeppelin.solutions/t/how-to-implement-erc20-supply-mechanisms/226[How to implement supply mechanisms].

We have followed general OpenZeppelin Contracts guidelines: functions revert instead returning `false` on failure. This behavior is nonetheless conventional and does not conflict with the expectations of ERC20 applications.

Additionally, an {Approval} event is emitted on calls to {transferFrom}. This allows applications to reconstruct the allowance for all accounts just by listening to said events. Other implementations of the EIP may not emit these events, as it isn't required by the specification.

Finally, the non-standard {decreaseAllowance} and {increaseAllowance} functions have been added to mitigate the well-known issues around setting allowances. See {IERC20-approve}._

_balances

_allowances

_totalSupply

_name

_symbol

__ERC20_init

_Sets the values for {name} and {symbol}.

The default value of {decimals} is 18. To select a different value for {decimals} you should overload it.

All two of these values are immutable: they can only be set once during construction._

__ERC20_init_unchained

name

Returns the name of the token.

symbol

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

decimals

_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 value {ERC20} uses, unless this function is 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}._

totalSupply

See {IERC20-totalSupply}.

balanceOf

See {IERC20-balanceOf}.

transfer

_See {IERC20-transfer}.

Requirements:

  • `recipient` cannot be the zero address.

  • the caller must have a balance of at least `amount`._

allowance

See {IERC20-allowance}.

approve

_See {IERC20-approve}.

Requirements:

  • `spender` cannot be the zero address._

transferFrom

_See {IERC20-transferFrom}.

Emits an {Approval} event indicating the updated allowance. This is not required by the EIP. See the note at the beginning of {ERC20}.

Requirements:

  • `sender` and `recipient` cannot be the zero address.

  • `sender` must have a balance of at least `amount`.

  • the caller must have allowance for ``sender``'s tokens of at least `amount`._

increaseAllowance

_Atomically increases the allowance granted to `spender` by the caller.

This is an alternative to {approve} that can be used as a mitigation for problems described in {IERC20-approve}.

Emits an {Approval} event indicating the updated allowance.

Requirements:

  • `spender` cannot be the zero address._

decreaseAllowance

_Atomically decreases the allowance granted to `spender` by the caller.

This is an alternative to {approve} that can be used as a mitigation for problems described in {IERC20-approve}.

Emits an {Approval} event indicating the updated allowance.

Requirements:

  • `spender` cannot be the zero address.

  • `spender` must have allowance for the caller of at least `subtractedValue`._

_transfer

_Moves `amount` of tokens from `sender` to `recipient`.

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

Emits a {Transfer} event.

Requirements:

  • `sender` cannot be the zero address.

  • `recipient` cannot be the zero address.

  • `sender` must have a balance of at least `amount`._

_mint

_Creates `amount` tokens and assigns them to `account`, increasing the total supply.

Emits a {Transfer} event with `from` set to the zero address.

Requirements:

  • `account` cannot be the zero address._

_burn

_Destroys `amount` tokens from `account`, reducing the total supply.

Emits a {Transfer} event with `to` set to the zero address.

Requirements:

  • `account` cannot be the zero address.

  • `account` must have at least `amount` tokens._

_approve

_Sets `amount` 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 {Approval} event.

Requirements:

  • `owner` cannot be the zero address.

  • `spender` cannot be the zero address._

_beforeTokenTransfer

_Hook that is called before any transfer of tokens. This includes minting and burning.

Calling conditions:

  • when `from` and `to` are both non-zero, `amount` of ``from``'s tokens will be transferred to `to`.

  • when `from` is zero, `amount` tokens will be minted for `to`.

  • when `to` is zero, `amount` of ``from``'s tokens will be burned.

  • `from` and `to` are never both zero.

To learn more about hooks, head to xref:ROOT:extending-contracts.adoc#using-hooks[Using Hooks]._

_afterTokenTransfer

_Hook that is called after any transfer of tokens. This includes minting and burning.

Calling conditions:

  • when `from` and `to` are both non-zero, `amount` of ``from``'s tokens has been transferred to `to`.

  • when `from` is zero, `amount` tokens have been minted for `to`.

  • when `to` is zero, `amount` of ``from``'s tokens have been burned.

  • `from` and `to` are never both zero.

To learn more about hooks, head to xref:ROOT:extending-contracts.adoc#using-hooks[Using Hooks]._

__gap

IERC20Upgradeable

Interface of the ERC20 standard as defined in the EIP.

totalSupply

Returns the amount of tokens in existence.

balanceOf

Returns the amount of tokens owned by `account`.

transfer

_Moves `amount` tokens from the caller's account to `recipient`.

Returns a boolean value indicating whether the operation succeeded.

Emits a {Transfer} event._

allowance

_Returns the remaining number of tokens that `spender` will be allowed to spend on behalf of `owner` through {transferFrom}. This is zero by default.

This value changes when {approve} or {transferFrom} are called._

approve

_Sets `amount` as the allowance of `spender` over the caller's tokens.

Returns a boolean value indicating whether the operation succeeded.

IMPORTANT: Beware that changing an allowance with this method brings the risk 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 {Approval} event._

transferFrom

_Moves `amount` tokens from `sender` to `recipient` using the allowance mechanism. `amount` is then deducted from the caller's allowance.

Returns a boolean value indicating whether the operation succeeded.

Emits a {Transfer} event._

Transfer

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

Note that `value` may be zero._

Approval

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

ERC20BurnableUpgradeable

Extension of {ERC20} that allows token holders to destroy both their own tokens and those that they have an allowance for, in a way that can be recognized off-chain (via event analysis).

__ERC20Burnable_init

__ERC20Burnable_init_unchained

burn

_Destroys `amount` tokens from the caller.

See {ERC20-burn}.

burnFrom

_Destroys `amount` 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 `amount`._

__gap

ERC20CappedUpgradeable

Extension of {ERC20} that adds a cap to the supply of tokens.

_cap

__ERC20Capped_init

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

__ERC20Capped_init_unchained

cap

Returns the cap on the token's total supply.

_mint

_See {ERC20-mint}.

__gap

ERC20FlashMintUpgradeable

_Implementation of the ERC3156 Flash loans extension, as defined in https://eips.ethereum.org/EIPS/eip-3156[ERC-3156].

Adds the {flashLoan} method, which provides flash loan support at the token level. By default there is no fee, but this can be changed by overriding {flashFee}.

Available since v4.1._

__ERC20FlashMint_init

__ERC20FlashMint_init_unchained

_RETURN_VALUE

maxFlashLoan

Returns the maximum amount of tokens available for loan.

Name
Type
Description

token

address

The address of the token that is requested.

Name
Type
Description

[0]

uint256

The amont of token that can be loaned.

flashFee

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.

Name
Type
Description

token

address

The token to be flash loaned.

amount

uint256

The amount of tokens to be loaned.

Name
Type
Description

[0]

uint256

The fees applied to the corresponding flash loan.

flashLoan

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 amount + fee tokens and have them approved back to the token contract itself so they can be burned.

Name
Type
Description

receiver

contract IERC3156FlashBorrowerUpgradeable

The receiver of the flash loan. Should implement the {IERC3156FlashBorrower.onFlashLoan} interface.

token

address

The token to be flash loaned. Only `address(this)` is supported.

amount

uint256

The amount of tokens to be loaned.

data

bytes

An arbitrary datafield that is passed to the receiver.

Name
Type
Description

[0]

bool

`true` is the flash loan was successful.

__gap

ERC20PausableUpgradeable

_ERC20 token with pausable token transfers, minting and burning.

Useful for scenarios such as preventing trades until the end of an evaluation period, or having an emergency switch for freezing all token transfers in the event of a large bug._

__ERC20Pausable_init

__ERC20Pausable_init_unchained

_beforeTokenTransfer

_See {ERC20-_beforeTokenTransfer}.

Requirements:

  • the contract must not be paused._

__gap

ERC20SnapshotUpgradeable

_This contract extends an ERC20 token with a snapshot mechanism. When a snapshot is created, the balances and total supply at the time are recorded for later access.

This can be used to safely create mechanisms based on token balances such as trustless dividends or weighted voting. In naive implementations it's possible to perform a "double spend" attack by reusing the same balance from different accounts. By using snapshots to calculate dividends or voting power, those attacks no longer apply. It can also be used to create an efficient ERC20 forking mechanism.

Snapshots are created by the internal {_snapshot} function, which will emit the {Snapshot} event and return a snapshot id. To get the total supply at the time of a snapshot, call the function {totalSupplyAt} with the snapshot id. To get the balance of an account at the time of a snapshot, call the {balanceOfAt} function with the snapshot id and the account address.

NOTE: Snapshot policy can be customized by overriding the {_getCurrentSnapshotId} method. For example, having it return `block.number` will trigger the creation of snapshot at the begining of each new block. When overridding this function, be careful about the monotonicity of its result. Non-monotonic snapshot ids will break the contract.

Implementing snapshots for every block using this method will incur significant gas costs. For a gas-efficient alternative consider {ERC20Votes}.

==== Gas Costs

Snapshots are efficient. Snapshot creation is O(1). Retrieval of balances or total supply from a snapshot is O(log n) in the number of snapshots that have been created, although n for a specific account will generally be much smaller since identical balances in subsequent snapshots are stored as a single entry.

There is a constant overhead for normal ERC20 transfers due to the additional snapshot bookkeeping. This overhead is only significant for the first transfer that immediately follows a snapshot for a particular account. Subsequent transfers will have normal cost until the next snapshot, and so on._

__ERC20Snapshot_init

__ERC20Snapshot_init_unchained

Snapshots

_accountBalanceSnapshots

_totalSupplySnapshots

_currentSnapshotId

Snapshot

_Emitted by {snapshot} when a snapshot identified by `id` is created.

_snapshot

_Creates a new snapshot and returns its snapshot id.

Emits a {Snapshot} event that contains the same id.

{_snapshot} is `internal` and you have to decide how to expose it externally. Its usage may be restricted to a set of accounts, for example using {AccessControl}, or it may be open to the public.

[WARNING] ==== While an open way of calling {_snapshot} is required for certain trust minimization mechanisms such as forking, you must consider that it can potentially be used by attackers in two ways.

First, it can be used to increase the cost of retrieval of values from snapshots, although it will grow logarithmically thus rendering this attack ineffective in the long term. Second, it can be used to target specific accounts and increase the cost of ERC20 transfers for them, in the ways specified in the Gas Costs section above.

We haven't measured the actual numbers; if this is something you're interested in please reach out to us. ====_

_getCurrentSnapshotId

Get the current snapshotId

balanceOfAt

Retrieves the balance of `account` at the time `snapshotId` was created.

totalSupplyAt

Retrieves the total supply at the time `snapshotId` was created.

_beforeTokenTransfer

_Hook that is called before any transfer of tokens. This includes minting and burning.

Calling conditions:

  • when `from` and `to` are both non-zero, `amount` of ``from``'s tokens will be transferred to `to`.

  • when `from` is zero, `amount` tokens will be minted for `to`.

  • when `to` is zero, `amount` of ``from``'s tokens will be burned.

  • `from` and `to` are never both zero.

To learn more about hooks, head to xref:ROOT:extending-contracts.adoc#using-hooks[Using Hooks]._

_valueAt

_updateAccountSnapshot

_updateTotalSupplySnapshot

_updateSnapshot

_lastSnapshotId

__gap

ERC20VotesCompUpgradeable

_Extension of ERC20 to support Compound's voting and delegation. This version exactly matches Compound's interface, with the drawback of only supporting supply up to (2^96^ - 1).

NOTE: You should use this contract if you need exact compatibility with COMP (for example in order to use your token with Governor Alpha or Bravo) and if you are sure the supply cap of 2^96^ is enough for you. Otherwise, use the {ERC20Votes} variant of this module.

This extension keeps a history (checkpoints) of each account's vote power. Vote power can be delegated either by calling the {delegate} function directly, or by providing a signature to be used with {delegateBySig}. Voting power can be queried through the public accessors {getCurrentVotes} and {getPriorVotes}.

By default, token balance does not account for voting power. This makes transfers cheaper. The downside is that it requires users to delegate to themselves in order to activate checkpoints and have their voting power tracked. Enabling self-delegation can easily be done by overriding the {delegates} function. Keep in mind however that this will significantly increase the base gas cost of transfers.

Available since v4.2._

__ERC20VotesComp_init_unchained

getCurrentVotes

Comp version of the {getVotes} accessor, with `uint96` return type.

getPriorVotes

Comp version of the {getPastVotes} accessor, with `uint96` return type.

_maxSupply

Maximum token supply. Reduced to `type(uint96).max` (2^96^ - 1) to fit COMP interface.

__gap

ERC20VotesUpgradeable

_Extension of ERC20 to support Compound-like voting and delegation. This version is more generic than Compound's, and supports token supply up to 2^224^ - 1, while COMP is limited to 2^96^ - 1.

NOTE: If exact COMP compatibility is required, use the {ERC20VotesComp} variant of this module.

This extension keeps a history (checkpoints) of each account's vote power. Vote power can be delegated either by calling the {delegate} function directly, or by providing a signature to be used with {delegateBySig}. Voting power can be queried through the public accessors {getVotes} and {getPastVotes}.

By default, token balance does not account for voting power. This makes transfers cheaper. The downside is that it requires users to delegate to themselves in order to activate checkpoints and have their voting power tracked. Enabling self-delegation can easily be done by overriding the {delegates} function. Keep in mind however that this will significantly increase the base gas cost of transfers.

Available since v4.2._

__ERC20Votes_init_unchained

Checkpoint

_DELEGATION_TYPEHASH

_delegates

_checkpoints

_totalSupplyCheckpoints

DelegateChanged

Emitted when an account changes their delegate.

DelegateVotesChanged

Emitted when a token transfer or delegate change results in changes to an account's voting power.

checkpoints

Get the `pos`-th checkpoint for `account`.

numCheckpoints

Get number of checkpoints for `account`.

delegates

Get the address `account` is currently delegating to.

getVotes

Gets the current votes balance for `account`

getPastVotes

_Retrieve the number of votes for `account` at the end of `blockNumber`.

Requirements:

  • `blockNumber` must have been already mined_

getPastTotalSupply

_Retrieve the `totalSupply` at the end of `blockNumber`. Note, this value is the sum of all balances. It is but NOT the sum of all the delegated votes!

Requirements:

  • `blockNumber` must have been already mined_

_checkpointsLookup

Lookup a value in a list of (sorted) checkpoints.

delegate

Delegate votes from the sender to `delegatee`.

delegateBySig

Delegates votes from signer to `delegatee`

_maxSupply

Maximum token supply. Defaults to `type(uint224).max` (2^224^ - 1).

_mint

Snapshots the totalSupply after it has been increased.

_burn

Snapshots the totalSupply after it has been decreased.

_afterTokenTransfer

_Move voting power when tokens are transferred.

Emits a {DelegateVotesChanged} event._

_delegate

_Change delegation for `delegator` to `delegatee`.

Emits events {DelegateChanged} and {DelegateVotesChanged}._

_moveVotingPower

_writeCheckpoint

_add

_subtract

__gap

ERC20WrapperUpgradeable

_Extension of the ERC20 token contract to support token wrapping.

Users can deposit and withdraw "underlying tokens" and receive a matching number of "wrapped tokens". This is useful in conjunction with other modules. For example, combining this wrapping mechanism with {ERC20Votes} will allow the wrapping of an existing "basic" ERC20 into a governance token.

Available since v4.2._

underlying

__ERC20Wrapper_init

__ERC20Wrapper_init_unchained

depositFor

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

withdrawTo

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

_recover

Mint wrapped token to cover any underlyingTokens that would have been transfered by mistake. Internal function that can be exposed with access control if desired.

__gap

IERC20MetadataUpgradeable

_Interface for the optional metadata functions from the ERC20 standard.

Available since v4.1._

name

Returns the name of the token.

symbol

Returns the symbol of the token.

decimals

Returns the decimals places of the token.

ERC20PermitUpgradeable

_Implementation of the ERC20 Permit extension allowing approvals to be made via signatures, as defined in https://eips.ethereum.org/EIPS/eip-2612[EIP-2612].

Adds the {permit} method, which can be used to change an account's ERC20 allowance (see {IERC20-allowance}) by presenting a message signed by the account. By not relying on `{IERC20-approve}`, the token holder account doesn't need to send a transaction, and thus is not required to hold Ether at all.

Available since v3.4._

_nonces

_PERMIT_TYPEHASH

__ERC20Permit_init

_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 ERC20 token name._

__ERC20Permit_init_unchained

permit

See {IERC20Permit-permit}.

nonces

See {IERC20Permit-nonces}.

DOMAIN_SEPARATOR

See {IERC20Permit-DOMAIN_SEPARATOR}.

_useNonce

_"Consume a nonce": return the current value and increment.

Available since v4.1._

__gap

IERC20PermitUpgradeable

_Interface of the ERC20 Permit extension allowing approvals to be made via signatures, as defined in https://eips.ethereum.org/EIPS/eip-2612[EIP-2612].

Adds the {permit} method, which can be used to change an account's ERC20 allowance (see {IERC20-allowance}) by presenting a message signed by the account. By not relying on {IERC20-approve}, the token holder account doesn't need to send a transaction, and thus is not required to hold Ether at all._

permit

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

IMPORTANT: The same issues {IERC20-approve} has related to transaction ordering also apply here.

Emits an {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 {nonces}).

For more information on the signature format, see the https://eips.ethereum.org/EIPS/eip-2612#specification[relevant EIP section]._

nonces

_Returns the current nonce for `owner`. This value must be included whenever a signature is generated for {permit}.

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

DOMAIN_SEPARATOR

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

ERC20PresetFixedSupplyUpgradeable

_{ERC20} token, including:

  • Preminted initial supply

  • Ability for holders to burn (destroy) their tokens

  • No access control mechanism (for minting/pausing) and hence no governance

This contract uses {ERC20Burnable} to include burn capabilities - head to its documentation for details.

Available since v3.4._

initialize

__ERC20PresetFixedSupply_init

_Mints `initialSupply` amount of token and transfers them to `owner`.

See {ERC20-constructor}._

__ERC20PresetFixedSupply_init_unchained

__gap

ERC20PresetMinterPauserUpgradeable

_{ERC20} token, including:

  • ability for holders to burn (destroy) their tokens

  • a minter role that allows for token minting (creation)

  • a pauser role that allows to stop all token transfers

This contract uses {AccessControl} to lock permissioned functions using the different roles - head to its documentation for details.

The account that deploys the contract will be granted the minter and pauser roles, as well as the default admin role, which will let it grant both minter and pauser roles to other accounts._

initialize

MINTER_ROLE

PAUSER_ROLE

__ERC20PresetMinterPauser_init

_Grants `DEFAULT_ADMIN_ROLE`, `MINTER_ROLE` and `PAUSER_ROLE` to the account that deploys the contract.

See {ERC20-constructor}._

__ERC20PresetMinterPauser_init_unchained

mint

_Creates `amount` new tokens for `to`.

See {ERC20-_mint}.

Requirements:

  • the caller must have the `MINTER_ROLE`._

pause

_Pauses all token transfers.

See {ERC20Pausable} and {Pausable-_pause}.

Requirements:

  • the caller must have the `PAUSER_ROLE`._

unpause

_Unpauses all token transfers.

See {ERC20Pausable} and {Pausable-_unpause}.

Requirements:

  • the caller must have the `PAUSER_ROLE`._

_beforeTokenTransfer

__gap

SafeERC20Upgradeable

Wrappers around ERC20 operations that throw on failure (when the token contract returns false). Tokens that return no value (and instead revert or throw on failure) are also supported, non-reverting calls are assumed to be successful. To use this library you can add a `using SafeERC20 for IERC20;` statement to your contract, which allows you to call the safe operations as `token.safeTransfer(...)`, etc.

safeTransfer

safeTransferFrom

safeApprove

_Deprecated. This function has issues similar to the ones found in {IERC20-approve}, and its usage is discouraged.

Whenever possible, use {safeIncreaseAllowance} and {safeDecreaseAllowance} instead._

safeIncreaseAllowance

safeDecreaseAllowance

_callOptionalReturn

Imitates a Solidity high-level call (i.e. a regular function call to a contract), relaxing the requirement on the return value: the return value is optional (but if data is returned, it must not be false).

Name
Type
Description

token

contract IERC20Upgradeable

The token targeted by the call.

data

bytes

The call data (encoded using abi.encode or one of its variants).

TokenTimelockUpgradeable

_A token holder contract that will allow a beneficiary to extract the tokens after a given release time.

Useful for simple vesting schedules like "advisors get all of their tokens after 1 year"._

_token

_beneficiary

_releaseTime

__TokenTimelock_init

__TokenTimelock_init_unchained

token

Name
Type
Description

[0]

contract IERC20Upgradeable

the token being held.

beneficiary

Name
Type
Description

[0]

address

the beneficiary of the tokens.

releaseTime

Name
Type
Description

[0]

uint256

the time when the tokens are released.

release

Transfers tokens held by timelock to beneficiary.

__gap

ERC721Upgradeable

Implementation of https://eips.ethereum.org/EIPS/eip-721[ERC721] Non-Fungible Token Standard, including the Metadata extension, but not including the Enumerable extension, which is available separately as {ERC721Enumerable}.

_name

_symbol

_owners

_balances

_tokenApprovals

_operatorApprovals

__ERC721_init

Initializes the contract by setting a `name` and a `symbol` to the token collection.

__ERC721_init_unchained

supportsInterface

See {IERC165-supportsInterface}.

balanceOf

See {IERC721-balanceOf}.

ownerOf

See {IERC721-ownerOf}.

name

See {IERC721Metadata-name}.

symbol

See {IERC721Metadata-symbol}.

tokenURI

See {IERC721Metadata-tokenURI}.

_baseURI

Base URI for computing {tokenURI}. If set, the resulting URI for each token will be the concatenation of the `baseURI` and the `tokenId`. Empty by default, can be overriden in child contracts.

approve

See {IERC721-approve}.

getApproved

See {IERC721-getApproved}.

setApprovalForAll

See {IERC721-setApprovalForAll}.

isApprovedForAll

See {IERC721-isApprovedForAll}.

transferFrom

See {IERC721-transferFrom}.

safeTransferFrom

See {IERC721-safeTransferFrom}.

safeTransferFrom

See {IERC721-safeTransferFrom}.

_safeTransfer

_Safely transfers `tokenId` token from `from` to `to`, checking first that contract recipients are aware of the ERC721 protocol to prevent tokens from being forever locked.

`_data` is additional data, it has no specified format and it is sent in call to `to`.

This internal function is equivalent to {safeTransferFrom}, and can be used to e.g. implement alternative mechanisms to perform token transfer, such as signature-based.

Requirements:

  • `from` cannot be the zero address.

  • `to` cannot be the zero address.

  • `tokenId` token must exist and be owned by `from`.

  • If `to` refers to a smart contract, it must implement {IERC721Receiver-onERC721Received}, which is called upon a safe transfer.

Emits a {Transfer} event._

_exists

_Returns whether `tokenId` exists.

Tokens can be managed by their owner or approved accounts via {approve} or {setApprovalForAll}.

Tokens start existing when they are minted (`_mint`), and stop existing when they are burned (`burn`).

_isApprovedOrOwner

_Returns whether `spender` is allowed to manage `tokenId`.

Requirements:

  • `tokenId` must exist._

_safeMint

_Safely mints `tokenId` and transfers it to `to`.

Requirements:

  • `tokenId` must not exist.

  • If `to` refers to a smart contract, it must implement {IERC721Receiver-onERC721Received}, which is called upon a safe transfer.

Emits a {Transfer} event._

_safeMint

_Same as {xref-ERC721-_safeMint-address-uint256-}[`safeMint`], with an additional `data` parameter which is forwarded in {IERC721Receiver-onERC721Received} to contract recipients.

_mint

_Mints `tokenId` and transfers it to `to`.

WARNING: Usage of this method is discouraged, use {_safeMint} whenever possible

Requirements:

  • `tokenId` must not exist.

  • `to` cannot be the zero address.

Emits a {Transfer} event._

_burn

_Destroys `tokenId`. The approval is cleared when the token is burned.

Requirements:

  • `tokenId` must exist.

Emits a {Transfer} event._

_transfer

_Transfers `tokenId` from `from` to `to`. As opposed to {transferFrom}, this imposes no restrictions on msg.sender.

Requirements:

  • `to` cannot be the zero address.

  • `tokenId` token must be owned by `from`.

Emits a {Transfer} event._

_approve

_Approve `to` to operate on `tokenId`

Emits a {Approval} event._

_checkOnERC721Received

Internal function to invoke {IERC721Receiver-onERC721Received} on a target address. The call is not executed if the target address is not a contract.

Name
Type
Description

from

address

address representing the previous owner of the given token ID

to

address

target address that will receive the tokens

tokenId

uint256

uint256 ID of the token to be transferred

_data

bytes

bytes optional data to send along with the call

Name
Type
Description

[0]

bool

bool whether the call correctly returned the expected magic value

_beforeTokenTransfer

_Hook that is called before any token transfer. This includes minting and burning.

Calling conditions:

  • When `from` and `to` are both non-zero, ``from``'s `tokenId` will be transferred to `to`.

  • When `from` is zero, `tokenId` will be minted for `to`.

  • When `to` is zero, ``from``'s `tokenId` will be burned.

  • `from` and `to` are never both zero.

To learn more about hooks, head to xref:ROOT:extending-contracts.adoc#using-hooks[Using Hooks]._

__gap

IERC721ReceiverUpgradeable

Interface for any contract that wants to support safeTransfers from ERC721 asset contracts.

onERC721Received

_Whenever an {IERC721} `tokenId` token is transferred to this contract via {IERC721-safeTransferFrom} by `operator` from `from`, this function is called.

It must return its Solidity selector to confirm the token transfer. If any other value is returned or the interface is not implemented by the recipient, the transfer will be reverted.

The selector can be obtained in Solidity with `IERC721.onERC721Received.selector`._

IERC721Upgradeable

Required interface of an ERC721 compliant contract.

Transfer

Emitted when `tokenId` token is transferred from `from` to `to`.

Approval

Emitted when `owner` enables `approved` to manage the `tokenId` token.

ApprovalForAll

Emitted when `owner` enables or disables (`approved`) `operator` to manage all of its assets.

balanceOf

Returns the number of tokens in ``owner``'s account.

ownerOf

_Returns the owner of the `tokenId` token.

Requirements:

  • `tokenId` must exist._

safeTransferFrom

_Safely transfers `tokenId` token from `from` to `to`, checking first that contract recipients are aware of the ERC721 protocol to prevent tokens from being forever locked.

Requirements:

  • `from` cannot be the zero address.

  • `to` cannot be the zero address.

  • `tokenId` token must exist and be owned by `from`.

  • If the caller is not `from`, it must be have been allowed to move this token by either {approve} or {setApprovalForAll}.

  • If `to` refers to a smart contract, it must implement {IERC721Receiver-onERC721Received}, which is called upon a safe transfer.

Emits a {Transfer} event._

transferFrom

_Transfers `tokenId` token from `from` to `to`.

WARNING: Usage of this method is discouraged, use {safeTransferFrom} whenever possible.

Requirements:

  • `from` cannot be the zero address.

  • `to` cannot be the zero address.

  • `tokenId` token must be owned by `from`.

  • If the caller is not `from`, it must be approved to move this token by either {approve} or {setApprovalForAll}.

Emits a {Transfer} event._

approve

_Gives permission to `to` to transfer `tokenId` token to another account. The approval is cleared when the token is transferred.

Only a single account can be approved at a time, so approving the zero address clears previous approvals.

Requirements:

  • The caller must own the token or be an approved operator.

  • `tokenId` must exist.

Emits an {Approval} event._

getApproved

_Returns the account approved for `tokenId` token.

Requirements:

  • `tokenId` must exist._

setApprovalForAll

_Approve or remove `operator` as an operator for the caller. Operators can call {transferFrom} or {safeTransferFrom} for any token owned by the caller.

Requirements:

  • The `operator` cannot be the caller.

Emits an {ApprovalForAll} event._

isApprovedForAll

_Returns if the `operator` is allowed to manage all of the assets of `owner`.

See {setApprovalForAll}_

safeTransferFrom

_Safely transfers `tokenId` token from `from` to `to`.

Requirements:

  • `from` cannot be the zero address.

  • `to` cannot be the zero address.

  • `tokenId` token must exist and be owned by `from`.

  • If the caller is not `from`, it must be approved to move this token by either {approve} or {setApprovalForAll}.

  • If `to` refers to a smart contract, it must implement {IERC721Receiver-onERC721Received}, which is called upon a safe transfer.

Emits a {Transfer} event._

ERC721BurnableUpgradeable

ERC721 Token that can be irreversibly burned (destroyed).

__ERC721Burnable_init

__ERC721Burnable_init_unchained

burn

_Burns `tokenId`. See {ERC721-_burn}.

Requirements:

  • The caller must own `tokenId` or be an approved operator._

__gap

ERC721EnumerableUpgradeable

This implements an optional extension of {ERC721} defined in the EIP that adds enumerability of all the token ids in the contract as well as all token ids owned by each account.

__ERC721Enumerable_init

__ERC721Enumerable_init_unchained

_ownedTokens

_ownedTokensIndex

_allTokens

_allTokensIndex

supportsInterface

See {IERC165-supportsInterface}.

tokenOfOwnerByIndex

See {IERC721Enumerable-tokenOfOwnerByIndex}.

totalSupply

See {IERC721Enumerable-totalSupply}.

tokenByIndex

See {IERC721Enumerable-tokenByIndex}.

_beforeTokenTransfer

_Hook that is called before any token transfer. This includes minting and burning.

Calling conditions:

  • When `from` and `to` are both non-zero, ``from``'s `tokenId` will be transferred to `to`.

  • When `from` is zero, `tokenId` will be minted for `to`.

  • When `to` is zero, ``from``'s `tokenId` will be burned.

  • `from` cannot be the zero address.

  • `to` cannot be the zero address.

To learn more about hooks, head to xref:ROOT:extending-contracts.adoc#using-hooks[Using Hooks]._

_addTokenToOwnerEnumeration

Private function to add a token to this extension's ownership-tracking data structures.

Name
Type
Description

to

address

address representing the new owner of the given token ID

tokenId

uint256

uint256 ID of the token to be added to the tokens list of the given address

_addTokenToAllTokensEnumeration

Private function to add a token to this extension's token tracking data structures.

Name
Type
Description

tokenId

uint256

uint256 ID of the token to be added to the tokens list

_removeTokenFromOwnerEnumeration

_Private function to remove a token from this extension's ownership-tracking data structures. Note that while the token is not assigned a new owner, the `_ownedTokensIndex` mapping is not updated: this allows for gas optimizations e.g. when performing a transfer operation (avoiding double writes). This has O(1) time complexity, but alters the order of the ownedTokens array.

Name
Type
Description

from

address

address representing the previous owner of the given token ID

tokenId

uint256

uint256 ID of the token to be removed from the tokens list of the given address

_removeTokenFromAllTokensEnumeration

_Private function to remove a token from this extension's token tracking data structures. This has O(1) time complexity, but alters the order of the allTokens array.

Name
Type
Description

tokenId

uint256

uint256 ID of the token to be removed from the tokens list

__gap

ERC721PausableUpgradeable

_ERC721 token with pausable token transfers, minting and burning.

Useful for scenarios such as preventing trades until the end of an evaluation period, or having an emergency switch for freezing all token transfers in the event of a large bug._

__ERC721Pausable_init

__ERC721Pausable_init_unchained

_beforeTokenTransfer

_See {ERC721-_beforeTokenTransfer}.

Requirements:

  • the contract must not be paused._

__gap

ERC721URIStorageUpgradeable

ERC721 token with storage based token URI management.

__ERC721URIStorage_init

__ERC721URIStorage_init_unchained

_tokenURIs

tokenURI

See {IERC721Metadata-tokenURI}.

_setTokenURI

_Sets `_tokenURI` as the tokenURI of `tokenId`.

Requirements:

  • `tokenId` must exist._

_burn

_Destroys `tokenId`. The approval is cleared when the token is burned.

Requirements:

  • `tokenId` must exist.

Emits a {Transfer} event._

__gap

IERC721EnumerableUpgradeable

See https://eips.ethereum.org/EIPS/eip-721

totalSupply

Returns the total amount of tokens stored by the contract.

tokenOfOwnerByIndex

Returns a token ID owned by `owner` at a given `index` of its token list. Use along with {balanceOf} to enumerate all of ``owner``'s tokens.

tokenByIndex

Returns a token ID at a given `index` of all the tokens stored by the contract. Use along with {totalSupply} to enumerate all tokens.

IERC721MetadataUpgradeable

See https://eips.ethereum.org/EIPS/eip-721

name

Returns the token collection name.

symbol

Returns the token collection symbol.

tokenURI

Returns the Uniform Resource Identifier (URI) for `tokenId` token.

ERC721PresetMinterPauserAutoIdUpgradeable

_{ERC721} token, including:

  • ability for holders to burn (destroy) their tokens

  • a minter role that allows for token minting (creation)

  • a pauser role that allows to stop all token transfers

  • token ID and URI autogeneration

This contract uses {AccessControl} to lock permissioned functions using the different roles - head to its documentation for details.

The account that deploys the contract will be granted the minter and pauser roles, as well as the default admin role, which will let it grant both minter and pauser roles to other accounts._

initialize

MINTER_ROLE

PAUSER_ROLE

_tokenIdTracker

_baseTokenURI

__ERC721PresetMinterPauserAutoId_init

_Grants `DEFAULT_ADMIN_ROLE`, `MINTER_ROLE` and `PAUSER_ROLE` to the account that deploys the contract.

Token URIs will be autogenerated based on `baseURI` and their token IDs. See {ERC721-tokenURI}._

__ERC721PresetMinterPauserAutoId_init_unchained

_baseURI

Base URI for computing {tokenURI}. If set, the resulting URI for each token will be the concatenation of the `baseURI` and the `tokenId`. Empty by default, can be overriden in child contracts.

mint

_Creates a new token for `to`. Its token ID will be automatically assigned (and available on the emitted {IERC721-Transfer} event), and the token URI autogenerated based on the base URI passed at construction.

See {ERC721-_mint}.

Requirements:

  • the caller must have the `MINTER_ROLE`._

pause

_Pauses all token transfers.

See {ERC721Pausable} and {Pausable-_pause}.

Requirements:

  • the caller must have the `PAUSER_ROLE`._

unpause

_Unpauses all token transfers.

See {ERC721Pausable} and {Pausable-_unpause}.

Requirements:

  • the caller must have the `PAUSER_ROLE`._

_beforeTokenTransfer

supportsInterface

See {IERC165-supportsInterface}.

__gap

ERC721HolderUpgradeable

_Implementation of the {IERC721Receiver} interface.

Accepts all token transfers. Make sure the contract is able to use its token with {IERC721-safeTransferFrom}, {IERC721-approve} or {IERC721-setApprovalForAll}._

__ERC721Holder_init

__ERC721Holder_init_unchained

onERC721Received

_See {IERC721Receiver-onERC721Received}.

Always returns `IERC721Receiver.onERC721Received.selector`._

__gap

ERC777Upgradeable

_Implementation of the {IERC777} interface.

This implementation is agnostic to the way tokens are created. This means that a supply mechanism has to be added in a derived contract using {_mint}.

Support for ERC20 is included in this contract, as specified by the EIP: both the ERC777 and ERC20 interfaces can be safely used when interacting with it. Both {IERC777-Sent} and {IERC20-Transfer} events are emitted on token movements.

Additionally, the {IERC777-granularity} value is hard-coded to `1`, meaning that there are no special restrictions in the amount of tokens that created, moved, or destroyed. This makes integration with ERC20 applications seamless._

_ERC1820_REGISTRY

_balances

_totalSupply

_name

_symbol

_TOKENS_SENDER_INTERFACE_HASH

_TOKENS_RECIPIENT_INTERFACE_HASH

_defaultOperatorsArray

_defaultOperators

_operators

_revokedDefaultOperators

_allowances

__ERC777_init

`defaultOperators` may be an empty array.

__ERC777_init_unchained

name

See {IERC777-name}.

symbol

See {IERC777-symbol}.

decimals

_See {ERC20-decimals}.

Always returns 18, as per the ERC777 EIP._

granularity

_See {IERC777-granularity}.

This implementation always returns `1`._

totalSupply

See {IERC777-totalSupply}.

balanceOf

Returns the amount of tokens owned by an account (`tokenHolder`).

send

_See {IERC777-send}.

Also emits a {IERC20-Transfer} event for ERC20 compatibility._

transfer

_See {IERC20-transfer}.

Unlike `send`, `recipient` is not required to implement the {IERC777Recipient} interface if it is a contract.

Also emits a {Sent} event._

burn

_See {IERC777-burn}.

Also emits a {IERC20-Transfer} event for ERC20 compatibility._

isOperatorFor

See {IERC777-isOperatorFor}.

authorizeOperator

See {IERC777-authorizeOperator}.

revokeOperator

See {IERC777-revokeOperator}.

defaultOperators

See {IERC777-defaultOperators}.

operatorSend

_See {IERC777-operatorSend}.

Emits {Sent} and {IERC20-Transfer} events._

operatorBurn

_See {IERC777-operatorBurn}.

Emits {Burned} and {IERC20-Transfer} events._

allowance

_See {IERC20-allowance}.

Note that operator and allowance concepts are orthogonal: operators may not have allowance, and accounts with allowance may not be operators themselves._

approve

_See {IERC20-approve}.

Note that accounts cannot have allowance issued by their operators._

transferFrom

_See {IERC20-transferFrom}.

Note that operator and allowance concepts are orthogonal: operators cannot call `transferFrom` (unless they have allowance), and accounts with allowance cannot call `operatorSend` (unless they are operators).

Emits {Sent}, {IERC20-Transfer} and {IERC20-Approval} events._

_mint

_Creates `amount` tokens and assigns them to `account`, increasing the total supply.

If a send hook is registered for `account`, the corresponding function will be called with `operator`, `data` and `operatorData`.

See {IERC777Sender} and {IERC777Recipient}.

Emits {Minted} and {IERC20-Transfer} events.

Requirements

  • `account` cannot be the zero address.

  • if `account` is a contract, it must implement the {IERC777Recipient} interface._

_mint

_Creates `amount` tokens and assigns them to `account`, increasing the total supply.

If `requireReceptionAck` is set to true, and if a send hook is registered for `account`, the corresponding function will be called with `operator`, `data` and `operatorData`.

See {IERC777Sender} and {IERC777Recipient}.

Emits {Minted} and {IERC20-Transfer} events.

Requirements

  • `account` cannot be the zero address.

  • if `account` is a contract, it must implement the {IERC777Recipient} interface._

_send

Send tokens

Name
Type
Description

from

address

address token holder address

to

address

address recipient address

amount

uint256

uint256 amount of tokens to transfer

userData

bytes

bytes extra information provided by the token holder (if any)

operatorData

bytes

bytes extra information provided by the operator (if any)

requireReceptionAck

bool

if true, contract recipients are required to implement ERC777TokensRecipient

_burn

Burn tokens

Name
Type
Description

from

address

address token holder address

amount

uint256

uint256 amount of tokens to burn

data

bytes

bytes extra information provided by the token holder

operatorData

bytes

bytes extra information provided by the operator (if any)

_move

_approve

_See {ERC20-_approve}.

Note that accounts cannot have allowance issued by their operators._

_callTokensToSend

Call from.tokensToSend() if the interface is registered

Name
Type
Description

operator

address

address operator requesting the transfer

from

address

address token holder address

to

address

address recipient address

amount

uint256

uint256 amount of tokens to transfer

userData

bytes

bytes extra information provided by the token holder (if any)

operatorData

bytes

bytes extra information provided by the operator (if any)

_callTokensReceived

Call to.tokensReceived() if the interface is registered. Reverts if the recipient is a contract but tokensReceived() was not registered for the recipient

Name
Type
Description

operator

address

address operator requesting the transfer

from

address

address token holder address

to

address

address recipient address

amount

uint256

uint256 amount of tokens to transfer

userData

bytes

bytes extra information provided by the token holder (if any)

operatorData

bytes

bytes extra information provided by the operator (if any)

requireReceptionAck

bool

if true, contract recipients are required to implement ERC777TokensRecipient

_beforeTokenTransfer

_Hook that is called before any token transfer. This includes calls to {send}, {transfer}, {operatorSend}, minting and burning.

Calling conditions:

  • when `from` and `to` are both non-zero, `amount` of ``from``'s tokens will be to transferred to `to`.

  • when `from` is zero, `amount` tokens will be minted for `to`.

  • when `to` is zero, `amount` of ``from``'s tokens will be burned.

  • `from` and `to` are never both zero.

To learn more about hooks, head to xref:ROOT:extending-contracts.adoc#using-hooks[Using Hooks]._

__gap

IERC777RecipientUpgradeable

_Interface of the ERC777TokensRecipient standard as defined in the EIP.

Accounts can be notified of {IERC777} tokens being sent to them by having a contract implement this interface (contract holders can be their own implementer) and registering it on the https://eips.ethereum.org/EIPS/eip-1820[ERC1820 global registry].

See {IERC1820Registry} and {ERC1820Implementer}._

tokensReceived

_Called by an {IERC777} token contract whenever tokens are being moved or created into a registered account (`to`). The type of operation is conveyed by `from` being the zero address or not.

This call occurs after the token contract's state is updated, so {IERC777-balanceOf}, etc., can be used to query the post-operation state.

This function may revert to prevent the operation from being executed._

IERC777SenderUpgradeable

_Interface of the ERC777TokensSender standard as defined in the EIP.

{IERC777} Token holders can be notified of operations performed on their tokens by having a contract implement this interface (contract holders can be their own implementer) and registering it on the https://eips.ethereum.org/EIPS/eip-1820[ERC1820 global registry].

See {IERC1820Registry} and {ERC1820Implementer}._

tokensToSend

_Called by an {IERC777} token contract whenever a registered holder's (`from`) tokens are about to be moved or destroyed. The type of operation is conveyed by `to` being the zero address or not.

This call occurs before the token contract's state is updated, so {IERC777-balanceOf}, etc., can be used to query the pre-operation state.

This function may revert to prevent the operation from being executed._

IERC777Upgradeable

_Interface of the ERC777Token standard as defined in the EIP.

This contract uses the https://eips.ethereum.org/EIPS/eip-1820[ERC1820 registry standard] to let token holders and recipients react to token movements by using setting implementers for the associated interfaces in said registry. See {IERC1820Registry} and {ERC1820Implementer}._

name

Returns the name of the token.

symbol

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

granularity

_Returns the smallest part of the token that is not divisible. This means all token operations (creation, movement and destruction) must have amounts that are a multiple of this number.

For most token contracts, this value will equal 1._

totalSupply

Returns the amount of tokens in existence.

balanceOf

Returns the amount of tokens owned by an account (`owner`).

send

_Moves `amount` tokens from the caller's account to `recipient`.

If send or receive hooks are registered for the caller and `recipient`, the corresponding functions will be called with `data` and empty `operatorData`. See {IERC777Sender} and {IERC777Recipient}.

Emits a {Sent} event.

Requirements

  • the caller must have at least `amount` tokens.

  • `recipient` cannot be the zero address.

  • if `recipient` is a contract, it must implement the {IERC777Recipient} interface._

burn

_Destroys `amount` tokens from the caller's account, reducing the total supply.

If a send hook is registered for the caller, the corresponding function will be called with `data` and empty `operatorData`. See {IERC777Sender}.

Emits a {Burned} event.

Requirements

  • the caller must have at least `amount` tokens._

isOperatorFor

_Returns true if an account is an operator of `tokenHolder`. Operators can send and burn tokens on behalf of their owners. All accounts are their own operator.

See {operatorSend} and {operatorBurn}._

authorizeOperator

_Make an account an operator of the caller.

See {isOperatorFor}.

Emits an {AuthorizedOperator} event.

Requirements

  • `operator` cannot be calling address._

revokeOperator

_Revoke an account's operator status for the caller.

See {isOperatorFor} and {defaultOperators}.

Emits a {RevokedOperator} event.

Requirements

  • `operator` cannot be calling address._

defaultOperators

_Returns the list of default operators. These accounts are operators for all token holders, even if {authorizeOperator} was never called on them.

This list is immutable, but individual holders may revoke these via {revokeOperator}, in which case {isOperatorFor} will return false._

operatorSend

_Moves `amount` tokens from `sender` to `recipient`. The caller must be an operator of `sender`.

If send or receive hooks are registered for `sender` and `recipient`, the corresponding functions will be called with `data` and `operatorData`. See {IERC777Sender} and {IERC777Recipient}.

Emits a {Sent} event.

Requirements

  • `sender` cannot be the zero address.

  • `sender` must have at least `amount` tokens.

  • the caller must be an operator for `sender`.

  • `recipient` cannot be the zero address.

  • if `recipient` is a contract, it must implement the {IERC777Recipient} interface._

operatorBurn

_Destroys `amount` tokens from `account`, reducing the total supply. The caller must be an operator of `account`.

If a send hook is registered for `account`, the corresponding function will be called with `data` and `operatorData`. See {IERC777Sender}.

Emits a {Burned} event.

Requirements

  • `account` cannot be the zero address.

  • `account` must have at least `amount` tokens.

  • the caller must be an operator for `account`._

Sent

Minted

Burned

AuthorizedOperator

RevokedOperator

ERC777PresetFixedSupplyUpgradeable

_{ERC777} token, including:

  • Preminted initial supply

  • No access control mechanism (for minting/pausing) and hence no governance

Available since v3.4._

initialize

__ERC777PresetFixedSupply_init

_Mints `initialSupply` amount of token and transfers them to `owner`.

See {ERC777-constructor}._

__ERC777PresetFixedSupply_init_unchained

__gap

AddressUpgradeable

Collection of functions related to the address type

isContract

_Returns true if `account` is a contract.

[IMPORTANT] ==== It is unsafe to assume that an address for which this function returns false is an externally-owned account (EOA) and not a contract.

Among others, `isContract` will return false for the following types of addresses:

  • an externally-owned account

  • a contract in construction

  • an address where a contract will be created

  • an address where a contract lived, but was destroyed ====_

sendValue

_Replacement for Solidity's `transfer`: sends `amount` wei to `recipient`, forwarding all available gas and reverting on errors.

https://eips.ethereum.org/EIPS/eip-1884[EIP1884] increases the gas cost of certain opcodes, possibly making contracts go over the 2300 gas limit imposed by `transfer`, making them unable to receive funds via `transfer`. {sendValue} removes this limitation.

https://diligence.consensys.net/posts/2019/09/stop-using-soliditys-transfer-now/[Learn more].

IMPORTANT: because control is transferred to `recipient`, care must be taken to not create reentrancy vulnerabilities. Consider using {ReentrancyGuard} or the https://solidity.readthedocs.io/en/v0.5.11/security-considerations.html#use-the-checks-effects-interactions-pattern[checks-effects-interactions pattern]._

functionCall

_Performs a Solidity function call using a low level `call`. A plain `call` is an unsafe replacement for a function call: use this function instead.

If `target` reverts with a revert reason, it is bubbled up by this function (like regular Solidity function calls).

Returns the raw returned data. To convert to the expected return value, use https://solidity.readthedocs.io/en/latest/units-and-global-variables.html?highlight=abi.decode#abi-encoding-and-decoding-functions[`abi.decode`].

Requirements:

  • `target` must be a contract.

  • calling `target` with `data` must not revert.

Available since v3.1._

functionCall

_Same as {xref-Address-functionCall-address-bytes-}[`functionCall`], but with `errorMessage` as a fallback revert reason when `target` reverts.

Available since v3.1._

functionCallWithValue

_Same as {xref-Address-functionCall-address-bytes-}[`functionCall`], but also transferring `value` wei to `target`.

Requirements:

  • the calling contract must have an ETH balance of at least `value`.

  • the called Solidity function must be `payable`.

Available since v3.1._

functionCallWithValue

_Same as {xref-Address-functionCallWithValue-address-bytes-uint256-}[`functionCallWithValue`], but with `errorMessage` as a fallback revert reason when `target` reverts.

Available since v3.1._

functionStaticCall

_Same as {xref-Address-functionCall-address-bytes-}[`functionCall`], but performing a static call.

Available since v3.3._

functionStaticCall

_Same as {xref-Address-functionCall-address-bytes-string-}[`functionCall`], but performing a static call.

Available since v3.3._

verifyCallResult

_Tool to verifies that a low level call was successful, and revert if it wasn't, either by bubbling the revert reason using the provided one.

Available since v4.3._

ArraysUpgradeable

Collection of functions related to array types.

findUpperBound

_Searches a sorted `array` and returns the first index that contains a value greater or equal to `element`. If no such index exists (i.e. all values in the array are strictly less than `element`), the array length is returned. Time complexity O(log n).

`array` is expected to be sorted in ascending order, and to contain no repeated elements._

ContextUpgradeable

_Provides information about the current execution context, including the sender of the transaction and its data. While these are generally available via msg.sender and msg.data, they should not be accessed in such a direct manner, since when dealing with meta-transactions the account sending and paying for execution may not be the actual sender (as far as an application is concerned).

This contract is only required for intermediate, library-like contracts._

__Context_init

__Context_init_unchained

_msgSender

_msgData

__gap

CountersUpgradeable

_Provides counters that can only be incremented, decremented or reset. This can be used e.g. to track the number of elements in a mapping, issuing ERC721 ids, or counting request ids.

Include with `using Counters for Counters.Counter;`_

Counter

current

increment

decrement

reset

MulticallUpgradeable

_Provides a function to batch together multiple calls in a single external call.

Available since v4.1._

__Multicall_init

__Multicall_init_unchained

multicall

Receives and executes a batch of function calls on this contract.

_functionDelegateCall

_Same as {xref-Address-functionCall-address-bytes-string-}[`functionCall`], but performing a delegate call.

Available since v3.4._

__gap

StorageSlotUpgradeable

_Library for reading and writing primitive types to specific storage slots.

Storage slots are often used to avoid storage conflict when dealing with upgradeable contracts. This library helps with reading and writing to such slots without the need for inline assembly.

The functions in this library return Slot structs that contain a `value` member that can be used to read or write.

Example usage to set ERC1967 implementation slot: ``` contract ERC1967 { bytes32 internal constant _IMPLEMENTATION_SLOT = 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc;

} ```

Available since v4.1 for `address`, `bool`, `bytes32`, and `uint256`._

AddressSlot

BooleanSlot

Bytes32Slot

Uint256Slot

getAddressSlot

Returns an `AddressSlot` with member `value` located at `slot`.

getBooleanSlot

Returns an `BooleanSlot` with member `value` located at `slot`.

getBytes32Slot

Returns an `Bytes32Slot` with member `value` located at `slot`.

getUint256Slot

Returns an `Uint256Slot` with member `value` located at `slot`.

StringsUpgradeable

String operations.

_HEX_SYMBOLS

toString

Converts a `uint256` to its ASCII `string` decimal representation.

toHexString

Converts a `uint256` to its ASCII `string` hexadecimal representation.

toHexString

Converts a `uint256` to its ASCII `string` hexadecimal representation with fixed length.

TimersUpgradeable

Tooling for timepoints, timers and delays

Timestamp

getDeadline

setDeadline

reset

isUnset

isStarted

isPending

isExpired

BlockNumber

getDeadline

setDeadline

reset

isUnset

isStarted

isPending

isExpired

ECDSAUpgradeable

_Elliptic Curve Digital Signature Algorithm (ECDSA) operations.

These functions can be used to verify that a message was signed by the holder of the private keys of a given address._

RecoverError

_throwError

tryRecover

_Returns the address that signed a hashed message (`hash`) with `signature` or error string. This address can then be used for verification purposes.

The `ecrecover` EVM opcode allows for malleable (non-unique) signatures: this function rejects them by requiring the `s` value to be in the lower half order, and the `v` value to be either 27 or 28.

IMPORTANT: `hash` must be the result of a hash operation for the verification to be secure: it is possible to craft signatures that recover to arbitrary addresses for non-hashed data. A safe way to ensure this is by receiving a hash of the original message (which may otherwise be too long), and then calling {toEthSignedMessageHash} on it.

Documentation for signature generation:

  • with https://web3js.readthedocs.io/en/v1.3.4/web3-eth-accounts.html#sign[Web3.js]

  • with https://docs.ethers.io/v5/api/signer/#Signer-signMessage[ethers]

Available since v4.3._

recover

_Returns the address that signed a hashed message (`hash`) with `signature`. This address can then be used for verification purposes.

The `ecrecover` EVM opcode allows for malleable (non-unique) signatures: this function rejects them by requiring the `s` value to be in the lower half order, and the `v` value to be either 27 or 28.

IMPORTANT: `hash` must be the result of a hash operation for the verification to be secure: it is possible to craft signatures that recover to arbitrary addresses for non-hashed data. A safe way to ensure this is by receiving a hash of the original message (which may otherwise be too long), and then calling {toEthSignedMessageHash} on it._

tryRecover

_Overload of {ECDSA-tryRecover} that receives the `r` and `vs` short-signature fields separately.

See https://eips.ethereum.org/EIPS/eip-2098[EIP-2098 short signatures]

Available since v4.3._

recover

_Overload of {ECDSA-recover} that receives the `r and `vs` short-signature fields separately.

Available since v4.2._

tryRecover

_Overload of {ECDSA-tryRecover} that receives the `v`, `r` and `s` signature fields separately.

Available since v4.3._

recover

Overload of {ECDSA-recover} that receives the `v`, `r` and `s` signature fields separately. /

toEthSignedMessageHash

_Returns an Ethereum Signed Message, created from a `hash`. This produces hash corresponding to the one signed with the https://eth.wiki/json-rpc/API#eth_sign[`eth_sign`] JSON-RPC method as part of EIP-191.

See {recover}. /_

toTypedDataHash

_Returns an Ethereum Signed Typed Data, created from a `domainSeparator` and a `structHash`. This produces hash corresponding to the one signed with the https://eips.ethereum.org/EIPS/eip-712[`eth_signTypedData`] JSON-RPC method as part of EIP-712.

See {recover}. /_

SignatureCheckerUpgradeable

_Signature verification helper: Provide a single mechanism to verify both private-key (EOA) ECDSA signature and ERC1271 contract sigantures. Using this instead of ECDSA.recover in your contract will make them compatible with smart contract wallets such as Argent and Gnosis.

Note: unlike ECDSA signatures, contract signature's are revocable, and the outcome of this function can thus change through time. It could return true at block N and false at block N+1 (or the opposite).

Available since v4.1._

isValidSignatureNow

EIP712Upgradeable

_https://eips.ethereum.org/EIPS/eip-712[EIP 712] is a standard for hashing and signing of typed structured data.

The encoding specified in the EIP is very generic, and such a generic implementation in Solidity is not feasible, thus this contract does not implement the encoding itself. Protocols need to implement the type-specific encoding they need in their contracts using a combination of `abi.encode` and `keccak256`.

This contract implements the EIP 712 domain separator ({_domainSeparatorV4}) that is used as part of the encoding scheme, and the final step of the encoding to obtain the message digest that is then signed via ECDSA ({_hashTypedDataV4}).

The implementation of the domain separator was designed to be as efficient as possible while still properly updating the chain id to protect against replay attacks on an eventual fork of the chain.

NOTE: This contract implements the version of the encoding known as "v4", as implemented by the JSON RPC method https://docs.metamask.io/guide/signing-data.html[`eth_signTypedDataV4` in MetaMask].

Available since v3.4._

_HASHED_NAME

_HASHED_VERSION

_TYPE_HASH

__EIP712_init

_Initializes the domain separator and parameter caches.

The meaning of `name` and `version` is specified in https://eips.ethereum.org/EIPS/eip-712#definition-of-domainseparator[EIP 712]:

  • `name`: the user readable name of the signing domain, i.e. the name of the DApp or the protocol.

  • `version`: the current major version of the signing domain.

NOTE: These parameters cannot be changed except through a xref:learn::upgrading-smart-contracts.adoc[smart contract upgrade]._

__EIP712_init_unchained

_domainSeparatorV4

Returns the domain separator for the current chain.

_buildDomainSeparator

_hashTypedDataV4

_Given an already https://eips.ethereum.org/EIPS/eip-712#definition-of-hashstruct[hashed struct], this function returns the hash of the fully encoded EIP712 message for this domain.

This hash can be used together with {ECDSA-recover} to obtain the signer of a message. For example:

```solidity bytes32 digest = hashTypedDataV4(keccak256(abi.encode( keccak256("Mail(address to,string contents)"), mailTo, keccak256(bytes(mailContents)) ))); address signer = ECDSA.recover(digest, signature); ```

_EIP712NameHash

_The hash of the name parameter for the EIP712 domain.

NOTE: This function reads from storage by default, but can be redefined to return a constant value if gas costs are a concern._

_EIP712VersionHash

_The hash of the version parameter for the EIP712 domain.

NOTE: This function reads from storage by default, but can be redefined to return a constant value if gas costs are a concern._

__gap

ConditionalEscrowUpgradeable

Base abstract escrow to only allow withdrawal if a condition is met. Intended usage: See {Escrow}. Same usage guidelines apply here.

__ConditionalEscrow_init

__ConditionalEscrow_init_unchained

withdrawalAllowed

Returns whether an address is allowed to withdraw their funds. To be implemented by derived contracts.

Name
Type
Description

payee

address

The destination address of the funds.

withdraw

_Withdraw accumulated balance for a payee, forwarding all gas to the recipient.

WARNING: Forwarding all gas opens the door to reentrancy vulnerabilities. Make sure you trust the recipient, or are either following the checks-effects-interactions pattern or using {ReentrancyGuard}._

Name
Type
Description

payee

address payable

The address whose funds will be withdrawn and transferred to.

__gap

EscrowUpgradeable

_Base escrow contract, holds funds designated for a payee until they withdraw them.

Intended usage: This contract (and derived escrow contracts) should be a standalone contract, that only interacts with the contract that instantiated it. That way, it is guaranteed that all Ether will be handled according to the `Escrow` rules, and there is no need to check for payable functions or transfers in the inheritance tree. The contract that uses the escrow as its payment method should be its owner, and provide public methods redirecting to the escrow's deposit and withdraw._

initialize

__Escrow_init

__Escrow_init_unchained

Deposited

Withdrawn

_deposits

depositsOf

deposit

Stores the sent amount as credit to be withdrawn.

Name
Type
Description

payee

address

The destination address of the funds.

withdraw

_Withdraw accumulated balance for a payee, forwarding all gas to the recipient.

WARNING: Forwarding all gas opens the door to reentrancy vulnerabilities. Make sure you trust the recipient, or are either following the checks-effects-interactions pattern or using {ReentrancyGuard}._

Name
Type
Description

payee

address payable

The address whose funds will be withdrawn and transferred to.

__gap

RefundEscrowUpgradeable

Escrow that holds funds for a beneficiary, deposited from multiple parties. Intended usage: See {Escrow}. Same usage guidelines apply here. The owner account (that is, the contract that instantiates this contract) may deposit, close the deposit period, and allow for either withdrawal by the beneficiary, or refunds to the depositors. All interactions with `RefundEscrow` will be made through the owner contract.

State

RefundsClosed

RefundsEnabled

_state

_beneficiary

__RefundEscrow_init

Constructor.

Name
Type
Description

beneficiary_

address payable

The beneficiary of the deposits.

__RefundEscrow_init_unchained

state

Name
Type
Description

[0]

enum RefundEscrowUpgradeable.State

The current state of the escrow.

beneficiary

Name
Type
Description

[0]

address payable

The beneficiary of the escrow.

deposit

Stores funds that may later be refunded.

Name
Type
Description

refundee

address

The address funds will be sent to if a refund occurs.

close

Allows for the beneficiary to withdraw their funds, rejecting further deposits.

enableRefunds

Allows for refunds to take place, rejecting further deposits.

beneficiaryWithdraw

Withdraws the beneficiary's funds.

withdrawalAllowed

Returns whether refundees can withdraw their deposits (be refunded). The overridden function receives a 'payee' argument, but we ignore it here since the condition is global, not per-payee.

__gap

ERC165CheckerUpgradeable

_Library used to query support of an interface declared via {IERC165}.

Note that these functions return the actual result of the query: they do not `revert` if an interface is not supported. It is up to the caller to decide what to do in these cases._

_INTERFACE_ID_INVALID

supportsERC165

Returns true if `account` supports the {IERC165} interface,

supportsInterface

_Returns true if `account` supports the interface defined by `interfaceId`. Support for {IERC165} itself is queried automatically.

See {IERC165-supportsInterface}._

getSupportedInterfaces

_Returns a boolean array where each value corresponds to the interfaces passed in and whether they're supported or not. This allows you to batch check interfaces for a contract where your expectation is that some interfaces may not be supported.

See {IERC165-supportsInterface}.

Available since v3.4._

supportsAllInterfaces

_Returns true if `account` supports all the interfaces defined in `interfaceIds`. Support for {IERC165} itself is queried automatically.

Batch-querying can lead to gas savings by skipping repeated checks for {IERC165} support.

See {IERC165-supportsInterface}._

_supportsERC165Interface

Query if a contract implements an interface, does not check ERC165 support

Assumes that account contains a contract that supports ERC165, otherwise the behavior of this method is undefined. This precondition can be checked with {supportsERC165}. Interface identification is specified in ERC-165.

Name
Type
Description

account

address

The address of the contract to query for support of an interface

interfaceId

bytes4

The interface identifier, as specified in ERC-165

Name
Type
Description

[0]

bool

true if the contract at account indicates support of the interface with identifier interfaceId, false otherwise

ERC165StorageUpgradeable

_Storage based implementation of the {IERC165} interface.

Contracts may inherit from this and call {registerInterface} to declare their support of an interface.

__ERC165Storage_init

__ERC165Storage_init_unchained

_supportedInterfaces

Mapping of interface ids to whether or not it's supported.

supportsInterface

See {IERC165-supportsInterface}.

_registerInterface

_Registers the contract as an implementer of the interface defined by `interfaceId`. Support of the actual ERC165 interface is automatic and registering its interface id is not required.

See {IERC165-supportsInterface}.

Requirements:

  • `interfaceId` cannot be the ERC165 invalid interface (`0xffffffff`)._

__gap

ERC165Upgradeable

_Implementation of the {IERC165} interface.

Contracts that want to implement ERC165 should inherit from this contract and override {supportsInterface} to check for the additional interface id that will be supported. For example:

```solidity function supportsInterface(bytes4 interfaceId) public view virtual override returns (bool) { return interfaceId == type(MyInterface).interfaceId || super.supportsInterface(interfaceId); } ```

Alternatively, {ERC165Storage} provides an easier to use but more expensive implementation._

__ERC165_init

__ERC165_init_unchained

supportsInterface

See {IERC165-supportsInterface}.

__gap

ERC1820ImplementerUpgradeable

_Implementation of the {IERC1820Implementer} interface.

Contracts may inherit from this and call {registerInterfaceForAddress} to declare their willingness to be implementers. {IERC1820Registry-setInterfaceImplementer} should then be called for the registration to be complete.

__ERC1820Implementer_init

__ERC1820Implementer_init_unchained

_ERC1820_ACCEPT_MAGIC

_supportedInterfaces

canImplementInterfaceForAddress

See {IERC1820Implementer-canImplementInterfaceForAddress}.

_registerInterfaceForAddress

_Declares the contract as willing to be an implementer of `interfaceHash` for `account`.

See {IERC1820Registry-setInterfaceImplementer} and {IERC1820Registry-interfaceHash}._

__gap

IERC165Upgradeable

_Interface of the ERC165 standard, as defined in the https://eips.ethereum.org/EIPS/eip-165[EIP].

Implementers can declare support of contract interfaces, which can then be queried by others ({ERC165Checker}).

For an implementation, see {ERC165}._

supportsInterface

_Returns true if this contract implements the interface defined by `interfaceId`. See the corresponding https://eips.ethereum.org/EIPS/eip-165#how-interfaces-are-identified[EIP section] to learn more about how these ids are created.

This function call must use less than 30 000 gas._

IERC1820ImplementerUpgradeable

Interface for an ERC1820 implementer, as defined in the https://eips.ethereum.org/EIPS/eip-1820#interface-implementation-erc1820implementerinterface[EIP]. Used by contracts that will be registered as implementers in the {IERC1820Registry}.

canImplementInterfaceForAddress

_Returns a special value (`ERC1820_ACCEPT_MAGIC`) if this contract implements `interfaceHash` for `account`.

See {IERC1820Registry-setInterfaceImplementer}._

IERC1820RegistryUpgradeable

_Interface of the global ERC1820 Registry, as defined in the https://eips.ethereum.org/EIPS/eip-1820[EIP]. Accounts may register implementers for interfaces in this registry, as well as query support.

Implementers may be shared by multiple accounts, and can also implement more than a single interface for each account. Contracts can implement interfaces for themselves, but externally-owned accounts (EOA) must delegate this to a contract.

{IERC165} interfaces can also be queried via the registry.

For an in-depth explanation and source code analysis, see the EIP text._

setManager

_Sets `newManager` as the manager for `account`. A manager of an account is able to set interface implementers for it.

By default, each account is its own manager. Passing a value of `0x0` in `newManager` will reset the manager to this initial state.

Emits a {ManagerChanged} event.

Requirements:

  • the caller must be the current manager for `account`._

getManager

_Returns the manager for `account`.

See {setManager}._

setInterfaceImplementer

_Sets the `implementer` contract as ``account``'s implementer for `interfaceHash`.

`account` being the zero address is an alias for the caller's address. The zero address can also be used in `implementer` to remove an old one.

See {interfaceHash} to learn how these are created.

Emits an {InterfaceImplementerSet} event.

Requirements:

  • the caller must be the current manager for `account`.

  • `interfaceHash` must not be an {IERC165} interface id (i.e. it must not end in 28 zeroes).

  • `implementer` must implement {IERC1820Implementer} and return true when queried for support, unless `implementer` is the caller. See {IERC1820Implementer-canImplementInterfaceForAddress}._

getInterfaceImplementer

_Returns the implementer of `interfaceHash` for `account`. If no such implementer is registered, returns the zero address.

If `interfaceHash` is an {IERC165} interface id (i.e. it ends with 28 zeroes), `account` will be queried for support of it.

`account` being the zero address is an alias for the caller's address._

interfaceHash

Returns the interface hash for an `interfaceName`, as defined in the corresponding https://eips.ethereum.org/EIPS/eip-1820#interface-name[section of the EIP].

updateERC165Cache

Updates the cache with whether the contract implements an ERC165 interface or not.

Name
Type
Description

account

address

Address of the contract for which to update the cache.

interfaceId

bytes4

ERC165 interface for which to update the cache.

implementsERC165Interface

Checks whether a contract implements an ERC165 interface or not. If the result is not cached a direct lookup on the contract address is performed. If the result is not cached or the cached value is out-of-date, the cache MUST be updated manually by calling {updateERC165Cache} with the contract address.

Name
Type
Description

account

address

Address of the contract to check.

interfaceId

bytes4

ERC165 interface to check.

Name
Type
Description

[0]

bool

True if `account` implements `interfaceId`, false otherwise.

implementsERC165InterfaceNoCache

Checks whether a contract implements an ERC165 interface or not without using nor updating the cache.

Name
Type
Description

account

address

Address of the contract to check.

interfaceId

bytes4

ERC165 interface to check.

Name
Type
Description

[0]

bool

True if `account` implements `interfaceId`, false otherwise.

InterfaceImplementerSet

ManagerChanged

MathUpgradeable

Standard math utilities missing in the Solidity language.

max

Returns the largest of two numbers.

min

Returns the smallest of two numbers.

average

Returns the average of two numbers. The result is rounded towards zero.

ceilDiv

_Returns the ceiling of the division of two numbers.

This differs from standard division with `/` in that it rounds up instead of rounding down._

SafeCastUpgradeable

_Wrappers over Solidity's uintXX/intXX casting operators with added overflow checks.

Downcasting from uint256/int256 in Solidity does not revert on overflow. This can easily result in undesired exploitation or bugs, since developers usually assume that overflows raise errors. `SafeCast` restores this intuition by reverting the transaction when such an operation overflows.

Using this library instead of the unchecked operations eliminates an entire class of bugs, so it's recommended to use it always.

Can be combined with {SafeMath} and {SignedSafeMath} to extend it to smaller types, by performing all math on `uint256` and `int256` and then downcasting._

toUint224

_Returns the downcasted uint224 from uint256, reverting on overflow (when the input is greater than largest uint224).

Counterpart to Solidity's `uint224` operator.

Requirements:

  • input must fit into 224 bits_

toUint128

_Returns the downcasted uint128 from uint256, reverting on overflow (when the input is greater than largest uint128).

Counterpart to Solidity's `uint128` operator.

Requirements:

  • input must fit into 128 bits_

toUint96

_Returns the downcasted uint96 from uint256, reverting on overflow (when the input is greater than largest uint96).

Counterpart to Solidity's `uint96` operator.

Requirements:

  • input must fit into 96 bits_

toUint64

_Returns the downcasted uint64 from uint256, reverting on overflow (when the input is greater than largest uint64).

Counterpart to Solidity's `uint64` operator.

Requirements:

  • input must fit into 64 bits_

toUint32

_Returns the downcasted uint32 from uint256, reverting on overflow (when the input is greater than largest uint32).

Counterpart to Solidity's `uint32` operator.

Requirements:

  • input must fit into 32 bits_

toUint16

_Returns the downcasted uint16 from uint256, reverting on overflow (when the input is greater than largest uint16).

Counterpart to Solidity's `uint16` operator.

Requirements:

  • input must fit into 16 bits_

toUint8

_Returns the downcasted uint8 from uint256, reverting on overflow (when the input is greater than largest uint8).

Counterpart to Solidity's `uint8` operator.

Requirements:

  • input must fit into 8 bits._

toUint256

_Converts a signed int256 into an unsigned uint256.

Requirements:

  • input must be greater than or equal to 0._

toInt128

_Returns the downcasted int128 from int256, reverting on overflow (when the input is less than smallest int128 or greater than largest int128).

Counterpart to Solidity's `int128` operator.

Requirements:

  • input must fit into 128 bits

Available since v3.1._

toInt64

_Returns the downcasted int64 from int256, reverting on overflow (when the input is less than smallest int64 or greater than largest int64).

Counterpart to Solidity's `int64` operator.

Requirements:

  • input must fit into 64 bits

Available since v3.1._

toInt32

_Returns the downcasted int32 from int256, reverting on overflow (when the input is less than smallest int32 or greater than largest int32).

Counterpart to Solidity's `int32` operator.

Requirements:

  • input must fit into 32 bits

Available since v3.1._

toInt16

_Returns the downcasted int16 from int256, reverting on overflow (when the input is less than smallest int16 or greater than largest int16).

Counterpart to Solidity's `int16` operator.

Requirements:

  • input must fit into 16 bits

Available since v3.1._

toInt8

_Returns the downcasted int8 from int256, reverting on overflow (when the input is less than smallest int8 or greater than largest int8).

Counterpart to Solidity's `int8` operator.

Requirements:

  • input must fit into 8 bits.

Available since v3.1._

toInt256

_Converts an unsigned uint256 into a signed int256.

Requirements:

  • input must be less than or equal to maxInt256._

SafeMathUpgradeable

_Wrappers over Solidity's arithmetic operations.

NOTE: `SafeMath` is no longer needed starting with Solidity 0.8. The compiler now has built in overflow checking._

tryAdd

_Returns the addition of two unsigned integers, with an overflow flag.

Available since v3.4._

trySub

_Returns the substraction of two unsigned integers, with an overflow flag.

Available since v3.4._

tryMul

_Returns the multiplication of two unsigned integers, with an overflow flag.

Available since v3.4._

tryDiv

_Returns the division of two unsigned integers, with a division by zero flag.

Available since v3.4._

tryMod

_Returns the remainder of dividing two unsigned integers, with a division by zero flag.

Available since v3.4._

add

_Returns the addition of two unsigned integers, reverting on overflow.

Counterpart to Solidity's `+` operator.

Requirements:

  • Addition cannot overflow._

sub

_Returns the subtraction of two unsigned integers, reverting on overflow (when the result is negative).

Counterpart to Solidity's `-` operator.

Requirements:

  • Subtraction cannot overflow._

mul

_Returns the multiplication of two unsigned integers, reverting on overflow.

Counterpart to Solidity's `*` operator.

Requirements:

  • Multiplication cannot overflow._

div

_Returns the integer division of two unsigned integers, reverting on division by zero. The result is rounded towards zero.

Counterpart to Solidity's `/` operator.

Requirements:

  • The divisor cannot be zero._

mod

_Returns the remainder of dividing two unsigned integers. (unsigned integer modulo), reverting when dividing by zero.

Counterpart to Solidity's `%` operator. This function uses a `revert` opcode (which leaves remaining gas untouched) while Solidity uses an invalid opcode to revert (consuming all remaining gas).

Requirements:

  • The divisor cannot be zero._

sub

_Returns the subtraction of two unsigned integers, reverting with custom message on overflow (when the result is negative).

CAUTION: This function is deprecated because it requires allocating memory for the error message unnecessarily. For custom revert reasons use {trySub}.

Counterpart to Solidity's `-` operator.

Requirements:

  • Subtraction cannot overflow._

div

_Returns the integer division of two unsigned integers, reverting with custom message on division by zero. The result is rounded towards zero.

Counterpart to Solidity's `/` operator. Note: this function uses a `revert` opcode (which leaves remaining gas untouched) while Solidity uses an invalid opcode to revert (consuming all remaining gas).

Requirements:

  • The divisor cannot be zero._

mod

_Returns the remainder of dividing two unsigned integers. (unsigned integer modulo), reverting with custom message when dividing by zero.

CAUTION: This function is deprecated because it requires allocating memory for the error message unnecessarily. For custom revert reasons use {tryMod}.

Counterpart to Solidity's `%` operator. This function uses a `revert` opcode (which leaves remaining gas untouched) while Solidity uses an invalid opcode to revert (consuming all remaining gas).

Requirements:

  • The divisor cannot be zero._

EnumerableMapUpgradeable

_Library for managing an enumerable variant of Solidity's https://solidity.readthedocs.io/en/latest/types.html#mapping-types[`mapping`] type.

Maps have the following properties:

  • Entries are added, removed, and checked for existence in constant time (O(1)).

  • Entries are enumerated in O(n). No guarantees are made on the ordering.

``` contract Example { // Add the library methods using EnumerableMap for EnumerableMap.UintToAddressMap;

} ```

As of v3.0.0, only maps of type `uint256 -> address` (`UintToAddressMap`) are supported._

Map

_set

_Adds a key-value pair to a map, or updates the value for an existing key. O(1).

Returns true if the key was added to the map, that is if it was not already present._

_remove

_Removes a key-value pair from a map. O(1).

Returns true if the key was removed from the map, that is if it was present._

_contains

Returns true if the key is in the map. O(1).

_length

Returns the number of key-value pairs in the map. O(1).

_at

_Returns the key-value pair stored at position `index` in the map. O(1).

Note that there are no guarantees on the ordering of entries inside the array, and it may change when more entries are added or removed.

Requirements:

  • `index` must be strictly less than {length}._

_tryGet

Tries to returns the value associated with `key`. O(1). Does not revert if `key` is not in the map.

_get

_Returns the value associated with `key`. O(1).

Requirements:

  • `key` must be in the map._

_get

_Same as {_get}, with a custom error message when `key` is not in the map.

CAUTION: This function is deprecated because it requires allocating memory for the error message unnecessarily. For custom revert reasons use {tryGet}.

UintToAddressMap

set

_Adds a key-value pair to a map, or updates the value for an existing key. O(1).

Returns true if the key was added to the map, that is if it was not already present._

remove

_Removes a value from a set. O(1).

Returns true if the key was removed from the map, that is if it was present._

contains

Returns true if the key is in the map. O(1).

length

Returns the number of elements in the map. O(1).

at

_Returns the element stored at position `index` in the set. O(1). Note that there are no guarantees on the ordering of values inside the array, and it may change when more values are added or removed.

Requirements:

  • `index` must be strictly less than {length}._

tryGet

_Tries to returns the value associated with `key`. O(1). Does not revert if `key` is not in the map.

Available since v3.4._

get

_Returns the value associated with `key`. O(1).

Requirements:

  • `key` must be in the map._

get

_Same as {get}, with a custom error message when `key` is not in the map.

CAUTION: This function is deprecated because it requires allocating memory for the error message unnecessarily. For custom revert reasons use {tryGet}._

EnumerableSetUpgradeable

Library for managing https://en.wikipedia.org/wiki/Set(abstract_data_type)[sets] of primitive types.

Sets have the following properties:

  • Elements are added, removed, and checked for existence in constant time (O(1)).

  • Elements are enumerated in O(n). No guarantees are made on the ordering.

``` contract Example { // Add the library methods using EnumerableSet for EnumerableSet.AddressSet;

} ```

As of v3.3.0, sets of type `bytes32` (`Bytes32Set`), `address` (`AddressSet`) and `uint256` (`UintSet`) are supported._

Set

_add

_Add a value to a set. O(1).

Returns true if the value was added to the set, that is if it was not already present._

_remove

_Removes a value from a set. O(1).

Returns true if the value was removed from the set, that is if it was present._

_contains

Returns true if the value is in the set. O(1).

_length

Returns the number of values on the set. O(1).

_at

_Returns the value stored at position `index` in the set. O(1).

Note that there are no guarantees on the ordering of values inside the array, and it may change when more values are added or removed.

Requirements:

  • `index` must be strictly less than {length}._

_values

_Return the entire set in an array

WARNING: This operation will copy the entire storage to memory, which can be quite expensive. This is designed to mostly be used by view accessors that are queried without any gas fees. Developers should keep in mind that this function has an unbounded cost, and using it as part of a state-changing function may render the function uncallable if the set grows to a point where copying to memory consumes too much gas to fit in a block._

Bytes32Set

add

_Add a value to a set. O(1).

Returns true if the value was added to the set, that is if it was not already present._

remove

_Removes a value from a set. O(1).

Returns true if the value was removed from the set, that is if it was present._

contains

Returns true if the value is in the set. O(1).

length

Returns the number of values in the set. O(1).

at

_Returns the value stored at position `index` in the set. O(1).

Note that there are no guarantees on the ordering of values inside the array, and it may change when more values are added or removed.

Requirements:

  • `index` must be strictly less than {length}._

values

_Return the entire set in an array

WARNING: This operation will copy the entire storage to memory, which can be quite expensive. This is designed to mostly be used by view accessors that are queried without any gas fees. Developers should keep in mind that this function has an unbounded cost, and using it as part of a state-changing function may render the function uncallable if the set grows to a point where copying to memory consumes too much gas to fit in a block._

AddressSet

add

_Add a value to a set. O(1).

Returns true if the value was added to the set, that is if it was not already present._

remove

_Removes a value from a set. O(1).

Returns true if the value was removed from the set, that is if it was present._

contains

Returns true if the value is in the set. O(1).

length

Returns the number of values in the set. O(1).

at

_Returns the value stored at position `index` in the set. O(1).

Note that there are no guarantees on the ordering of values inside the array, and it may change when more values are added or removed.

Requirements:

  • `index` must be strictly less than {length}._

values

_Return the entire set in an array

WARNING: This operation will copy the entire storage to memory, which can be quite expensive. This is designed to mostly be used by view accessors that are queried without any gas fees. Developers should keep in mind that this function has an unbounded cost, and using it as part of a state-changing function may render the function uncallable if the set grows to a point where copying to memory consumes too much gas to fit in a block._

UintSet

add

_Add a value to a set. O(1).

Returns true if the value was added to the set, that is if it was not already present._

remove

_Removes a value from a set. O(1).

Returns true if the value was removed from the set, that is if it was present._

contains

Returns true if the value is in the set. O(1).

length

Returns the number of values on the set. O(1).

at

_Returns the value stored at position `index` in the set. O(1).

Note that there are no guarantees on the ordering of values inside the array, and it may change when more values are added or removed.

Requirements:

  • `index` must be strictly less than {length}._

values

_Return the entire set in an array

WARNING: This operation will copy the entire storage to memory, which can be quite expensive. This is designed to mostly be used by view accessors that are queried without any gas fees. Developers should keep in mind that this function has an unbounded cost, and using it as part of a state-changing function may render the function uncallable if the set grows to a point where copying to memory consumes too much gas to fit in a block._

AccessControl

_Contract module that allows children to implement role-based access control mechanisms. This is a lightweight version that doesn't allow enumerating role members except through off-chain means by accessing the contract event logs. Some applications may benefit from on-chain enumerability, for those cases see {AccessControlEnumerable}.

Roles are referred to by their `bytes32` identifier. These should be exposed in the external API and be unique. The best way to achieve this is by using `public constant` hash digests:

``` bytes32 public constant MY_ROLE = keccak256("MY_ROLE"); ```

Roles can be used to represent a set of permissions. To restrict access to a function call, use {hasRole}:

``` function foo() public { require(hasRole(MY_ROLE, msg.sender)); ... } ```

Roles can be granted and revoked dynamically via the {grantRole} and {revokeRole} functions. Each role has an associated admin role, and only accounts that have a role's admin role can call {grantRole} and {revokeRole}.

By default, the admin role for all roles is `DEFAULT_ADMIN_ROLE`, which means that only accounts with this role will be able to grant or revoke other roles. More complex role relationships can be created by using {_setRoleAdmin}.

WARNING: The `DEFAULT_ADMIN_ROLE` is also its own admin: it has permission to grant and revoke this role. Extra precautions should be taken to secure accounts that have been granted it._

RoleData

_roles

DEFAULT_ADMIN_ROLE

onlyRole

_Modifier that checks that an account has a specific role. Reverts with a standardized message including the required role.

The format of the revert reason is given by the following regular expression:

/^AccessControl: account (0x[0-9a-f]{40}) is missing role (0x[0-9a-f]{64})$/

Available since v4.1._

supportsInterface

See {IERC165-supportsInterface}.

hasRole

Returns `true` if `account` has been granted `role`.

_checkRole

_Revert with a standard message if `account` is missing `role`.

The format of the revert reason is given by the following regular expression:

/^AccessControl: account (0x[0-9a-f]{40}) is missing role (0x[0-9a-f]{64})$/_

getRoleAdmin

_Returns the admin role that controls `role`. See {grantRole} and {revokeRole}.

To change a role's admin, use {setRoleAdmin}.

grantRole

_Grants `role` to `account`.

If `account` had not been already granted `role`, emits a {RoleGranted} event.

Requirements:

  • the caller must have ``role``'s admin role._

revokeRole

_Revokes `role` from `account`.

If `account` had been granted `role`, emits a {RoleRevoked} event.

Requirements:

  • the caller must have ``role``'s admin role._

renounceRole

_Revokes `role` from the calling account.

Roles are often managed via {grantRole} and {revokeRole}: this function's purpose is to provide a mechanism for accounts to lose their privileges if they are compromised (such as when a trusted device is misplaced).

If the calling account had been granted `role`, emits a {RoleRevoked} event.

Requirements:

  • the caller must be `account`._

_setupRole

_Grants `role` to `account`.

If `account` had not been already granted `role`, emits a {RoleGranted} event. Note that unlike {grantRole}, this function doesn't perform any checks on the calling account.

[WARNING] ==== This function should only be called from the constructor when setting up the initial roles for the system.

Using this function in any other way is effectively circumventing the admin system imposed by {AccessControl}. ====_

_setRoleAdmin

_Sets `adminRole` as ``role``'s admin role.

Emits a {RoleAdminChanged} event._

_grantRole

_revokeRole

AccessControlEnumerable

Extension of {AccessControl} that allows enumerating the members of each role.

_roleMembers

supportsInterface

See {IERC165-supportsInterface}.

getRoleMember

_Returns one of the accounts that have `role`. `index` must be a value between 0 and {getRoleMemberCount}, non-inclusive.

Role bearers are not sorted in any particular way, and their ordering may change at any point.

WARNING: When using {getRoleMember} and {getRoleMemberCount}, make sure you perform all queries on the same block. See the following https://forum.openzeppelin.com/t/iterating-over-elements-on-enumerableset-in-openzeppelin-contracts/2296[forum post] for more information._

getRoleMemberCount

Returns the number of accounts that have `role`. Can be used together with {getRoleMember} to enumerate all bearers of a role.

grantRole

Overload {grantRole} to track enumerable memberships

revokeRole

Overload {revokeRole} to track enumerable memberships

renounceRole

Overload {renounceRole} to track enumerable memberships

_setupRole

_Overload {setupRole} to track enumerable memberships

IAccessControl

External interface of AccessControl declared to support ERC165 detection.

RoleAdminChanged

_Emitted when `newAdminRole` is set as ``role``'s admin role, replacing `previousAdminRole`

`DEFAULT_ADMIN_ROLE` is the starting admin for all roles, despite {RoleAdminChanged} not being emitted signaling this.

Available since v3.1._

RoleGranted

_Emitted when `account` is granted `role`.

`sender` is the account that originated the contract call, an admin role bearer except when using {AccessControl-setupRole}.

RoleRevoked

_Emitted when `account` is revoked `role`.

`sender` is the account that originated the contract call:

  • if using `revokeRole`, it is the admin role bearer

  • if using `renounceRole`, it is the role bearer (i.e. `account`)_

hasRole

Returns `true` if `account` has been granted `role`.

getRoleAdmin

_Returns the admin role that controls `role`. See {grantRole} and {revokeRole}.

To change a role's admin, use {AccessControl-setRoleAdmin}.

grantRole

_Grants `role` to `account`.

If `account` had not been already granted `role`, emits a {RoleGranted} event.

Requirements:

  • the caller must have ``role``'s admin role._

revokeRole

_Revokes `role` from `account`.

If `account` had been granted `role`, emits a {RoleRevoked} event.

Requirements:

  • the caller must have ``role``'s admin role._

renounceRole

_Revokes `role` from the calling account.

Roles are often managed via {grantRole} and {revokeRole}: this function's purpose is to provide a mechanism for accounts to lose their privileges if they are compromised (such as when a trusted device is misplaced).

If the calling account had been granted `role`, emits a {RoleRevoked} event.

Requirements:

  • the caller must be `account`._

IAccessControlEnumerable

External interface of AccessControlEnumerable declared to support ERC165 detection.

getRoleMember

_Returns one of the accounts that have `role`. `index` must be a value between 0 and {getRoleMemberCount}, non-inclusive.

Role bearers are not sorted in any particular way, and their ordering may change at any point.

WARNING: When using {getRoleMember} and {getRoleMemberCount}, make sure you perform all queries on the same block. See the following https://forum.openzeppelin.com/t/iterating-over-elements-on-enumerableset-in-openzeppelin-contracts/2296[forum post] for more information._

getRoleMemberCount

Returns the number of accounts that have `role`. Can be used together with {getRoleMember} to enumerate all bearers of a role.

Ownable

_Contract module which provides a basic access control mechanism, where there is an account (an owner) that can be granted exclusive access to specific functions.

By default, the owner account will be the one that deploys the contract. This can later be changed with {transferOwnership}.

This module is used through inheritance. It will make available the modifier `onlyOwner`, which can be applied to your functions to restrict their use to the owner._

_owner

OwnershipTransferred

constructor

Initializes the contract setting the deployer as the initial owner.

owner

Returns the address of the current owner.

onlyOwner

Throws if called by any account other than the owner.

renounceOwnership

_Leaves the contract without owner. It will not be possible to call `onlyOwner` functions anymore. Can only be called by the current owner.

NOTE: Renouncing ownership will leave the contract without an owner, thereby removing any functionality that is only available to the owner._

transferOwnership

Transfers ownership of the contract to a new account (`newOwner`). Can only be called by the current owner.

_setOwner

PaymentSplitter

_This contract allows to split Ether payments among a group of accounts. The sender does not need to be aware that the Ether will be split in this way, since it is handled transparently by the contract.

The split can be in equal parts or in any other arbitrary proportion. The way this is specified is by assigning each account to a number of shares. Of all the Ether that this contract receives, each account will then be able to claim an amount proportional to the percentage of total shares they were assigned.

`PaymentSplitter` follows a pull payment model. This means that payments are not automatically forwarded to the accounts but kept in this contract, and the actual transfer is triggered as a separate step by calling the {release} function._

PayeeAdded

PaymentReleased

PaymentReceived

_totalShares

_totalReleased

_shares

_released

_payees

constructor

_Creates an instance of `PaymentSplitter` where each account in `payees` is assigned the number of shares at the matching position in the `shares` array.

All addresses in `payees` must be non-zero. Both arrays must have the same non-zero length, and there must be no duplicates in `payees`._

receive

_The Ether received will be logged with {PaymentReceived} events. Note that these events are not fully reliable: it's possible for a contract to receive Ether without triggering this function. This only affects the reliability of the events, and not the actual splitting of Ether.

To learn more about this see the Solidity documentation for https://solidity.readthedocs.io/en/latest/contracts.html#fallback-function[fallback functions]._

totalShares

Getter for the total shares held by payees.

totalReleased

Getter for the total amount of Ether already released.

shares

Getter for the amount of shares held by an account.

released

Getter for the amount of Ether already released to a payee.

payee

Getter for the address of the payee number `index`.

release

Triggers a transfer to `account` of the amount of Ether they are owed, according to their percentage of the total shares and their previous withdrawals.

_addPayee

Add a new payee to the contract.

Name
Type
Description

account

address

The address of the payee to add.

shares_

uint256

The number of shares owned by the payee.

Governor

_Core of the governance system, designed to be extended though various modules.

This contract is abstract and requires several function to be implemented in various modules:

  • A counting module must implement {quorum}, {_quorumReached}, {_voteSucceeded} and {_countVote}

  • A voting module must implement {getVotes}

  • Additionanly, the {votingPeriod} must also be implemented

Available since v4.3._

BALLOT_TYPEHASH

ProposalCore

_name

_proposals

onlyGovernance

_Restrict access to governor executing address. Some module might override the executor function to make sure this modifier is consistant with the execution model.

constructor

Sets the value for {name} and {version}

supportsInterface

See {IERC165-supportsInterface}.

name

See {IGovernor-name}.

version

See {IGovernor-version}.

hashProposal

_See {IGovernor-hashProposal}.

The proposal id is produced by hashing the RLC encoded `targets` array, the `values` array, the `calldatas` array and the descriptionHash (bytes32 which itself is the keccak256 hash of the description string). This proposal id can be produced from the proposal data which is part of the {ProposalCreated} event. It can even be computed in advance, before the proposal is submitted.

Note that the chainId and the governor address are not part of the proposal id computation. Consequently, the same proposal (with same operation and same description) will have the same id if submitted on multiple governors accross multiple networks. This also means that in order to execute the same operation twice (on the same governor) the proposer will have to change the description in order to avoid proposal id conflicts._

state

See {IGovernor-state}.

proposalSnapshot

See {IGovernor-proposalSnapshot}.

proposalDeadline

See {IGovernor-proposalDeadline}.

_quorumReached

Amount of votes already cast passes the threshold limit.

_voteSucceeded

Is the proposal successful or not.

_countVote

_Register a vote with a given support and voting weight.

Note: Support is generic and can represent various things depending on the voting system used._

propose

See {IGovernor-propose}.

execute

See {IGovernor-execute}.

_execute

Internal execution mechanism. Can be overriden to implement different execution mechanism

_cancel

_Internal cancel mechanism: locks up the proposal timer, preventing it from being re-submitted. Marks it as canceled to allow distinguishing it from executed proposals.

Emits a {IGovernor-ProposalCanceled} event._

castVote

See {IGovernor-castVote}.

castVoteWithReason

See {IGovernor-castVoteWithReason}.

castVoteBySig

See {IGovernor-castVoteBySig}.

_castVote

_Internal vote casting mechanism: Check that the vote is pending, that it has not been cast yet, retrieve voting weight using {IGovernor-getVotes} and call the {_countVote} internal function.

Emits a {IGovernor-VoteCast} event._

_executor

Address through which the governor executes action. Will be overloaded by module that execute actions through another contract such as a timelock.

IGovernor

_Interface of the {Governor} core.

Available since v4.3._

ProposalState

ProposalCreated

Emitted when a proposal is created.

ProposalCanceled

Emitted when a proposal is canceled.

ProposalExecuted

Emitted when a proposal is executed.

VoteCast

_Emitted when a vote is cast.

Note: `support` values should be seen as buckets. There interpretation depends on the voting module used._

name

module:core

Name of the governor instance (used in building the ERC712 domain separator).

version

module:core

Version of the governor instance (used in building the ERC712 domain separator). Default: "1"

COUNTING_MODE

module:voting

_A description of the possible `support` values for {castVote} and the way these votes are counted, meant to be consumed by UIs to show correct vote options and interpret the results. The string is a URL-encoded sequence of key-value pairs that each describe one aspect, for example `support=bravo&quorum=for,abstain`.

There are 2 standard keys: `support` and `quorum`.

  • `support=bravo` refers to the vote options 0 = For, 1 = Against, 2 = Abstain, as in `GovernorBravo`.

  • `quorum=bravo` means that only For votes are counted towards quorum.

  • `quorum=for,abstain` means that both For and Abstain votes are counted towards quorum.

NOTE: The string can be decoded by the standard https://developer.mozilla.org/en-US/docs/Web/API/URLSearchParams[`URLSearchParams`] JavaScript class._

hashProposal

module:core

Hashing function used to (re)build the proposal id from the proposal details..

state

module:core

Current state of a proposal, following Compound's convention

proposalSnapshot

module:core

block number used to retrieve user's votes and quorum.

proposalDeadline

module:core

timestamp at which votes close.

votingDelay

module:user-config

delay, in number of block, between the proposal is created and the vote starts. This can be increassed to leave time for users to buy voting power, of delegate it, before the voting of a proposal starts.

votingPeriod

module:user-config

_delay, in number of blocks, between the vote start and vote ends.

Note: the {votingDelay} can delay the start of the vote. This must be considered when setting the voting duration compared to the voting delay._

quorum

module:user-config

_Minimum number of cast voted required for a proposal to be successful.

Note: The `blockNumber` parameter corresponds to the snaphot used for counting vote. This allows to scale the quroum depending on values such as the totalSupply of a token at this block (see {ERC20Votes})._

getVotes

module:reputation

_Voting power of an `account` at a specific `blockNumber`.

Note: this can be implemented in a number of ways, for example by reading the delegated balance from one (or multiple), {ERC20Votes} tokens._

hasVoted

module:voting

Returns weither `account` has cast a vote on `proposalId`.

propose

_Create a new proposal. Vote start {IGovernor-votingDelay} blocks after the proposal is created and ends {IGovernor-votingPeriod} blocks after the voting starts.

Emits a {ProposalCreated} event._

execute

_Execute a successful proposal. This requires the quorum to be reached, the vote to be successful, and the deadline to be reached.

Emits a {ProposalExecuted} event.

Note: some module can modify the requirements for execution, for example by adding an additional timelock._

castVote

_Cast a vote

Emits a {VoteCast} event._

castVoteWithReason

_Cast a with a reason

Emits a {VoteCast} event._

castVoteBySig

_Cast a vote using the user cryptographic signature.

Emits a {VoteCast} event._

TimelockController

_Contract module which acts as a timelocked controller. When set as the owner of an `Ownable` smart contract, it enforces a timelock on all `onlyOwner` maintenance operations. This gives time for users of the controlled contract to exit before a potentially dangerous maintenance operation is applied.

By default, this contract is self administered, meaning administration tasks have to go through the timelock process. The proposer (resp executor) role is in charge of proposing (resp executing) operations. A common use case is to position this {TimelockController} as the owner of a smart contract, with a multisig or a DAO as the sole proposer.

Available since v3.3._

TIMELOCK_ADMIN_ROLE

PROPOSER_ROLE

EXECUTOR_ROLE

_DONE_TIMESTAMP

_timestamps

_minDelay

CallScheduled

Emitted when a call is scheduled as part of operation `id`.

CallExecuted

Emitted when a call is performed as part of operation `id`.

Cancelled

Emitted when operation `id` is cancelled.

MinDelayChange

Emitted when the minimum delay for future operations is modified.

constructor

Initializes the contract with a given `minDelay`.

onlyRoleOrOpenRole

Modifier to make a function callable only by a certain role. In addition to checking the sender's role, `address(0)` 's role is also considered. Granting a role to `address(0)` is equivalent to enabling this role for everyone.

receive

Contract might receive/hold ETH as part of the maintenance process.

isOperation

Returns whether an id correspond to a registered operation. This includes both Pending, Ready and Done operations.

isOperationPending

Returns whether an operation is pending or not.

isOperationReady

Returns whether an operation is ready or not.

isOperationDone

Returns whether an operation is done or not.

getTimestamp

Returns the timestamp at with an operation becomes ready (0 for unset operations, 1 for done operations).

getMinDelay

_Returns the minimum delay for an operation to become valid.

This value can be changed by executing an operation that calls `updateDelay`._

hashOperation

Returns the identifier of an operation containing a single transaction.

hashOperationBatch

Returns the identifier of an operation containing a batch of transactions.

schedule

_Schedule an operation containing a single transaction.

Emits a {CallScheduled} event.

Requirements:

  • the caller must have the 'proposer' role._

scheduleBatch

_Schedule an operation containing a batch of transactions.

Emits one {CallScheduled} event per transaction in the batch.

Requirements:

  • the caller must have the 'proposer' role._

_schedule

Schedule an operation that is to becomes valid after a given delay.

cancel

_Cancel an operation.

Requirements:

  • the caller must have the 'proposer' role._

execute

_Execute an (ready) operation containing a single transaction.

Emits a {CallExecuted} event.

Requirements:

  • the caller must have the 'executor' role._

executeBatch

_Execute an (ready) operation containing a batch of transactions.

Emits one {CallExecuted} event per transaction in the batch.

Requirements:

  • the caller must have the 'executor' role._

_beforeCall

Checks before execution of an operation's calls.

_afterCall

Checks after execution of an operation's calls.

_call

_Execute an operation's call.

Emits a {CallExecuted} event._

updateDelay

_Changes the minimum timelock duration for future operations.

Emits a {MinDelayChange} event.

Requirements:

  • the caller must be the timelock itself. This can only be achieved by scheduling and later executing an operation where the timelock is the target and the data is the ABI-encoded call to this function._

GovernorCompatibilityBravo

_Compatibility layer that implements GovernorBravo compatibility on to of {Governor}.

This compatibility layer includes a voting system and requires a {IGovernorTimelock} compatible module to be added through inheritance. It does not include token bindings, not does it include any variable upgrade patterns.

Available since v4.3._

VoteType

ProposalDetails

_proposalDetails

COUNTING_MODE

module:voting

_A description of the possible `support` values for {castVote} and the way these votes are counted, meant to be consumed by UIs to show correct vote options and interpret the results. The string is a URL-encoded sequence of key-value pairs that each describe one aspect, for example `support=bravo&quorum=for,abstain`.

There are 2 standard keys: `support` and `quorum`.

  • `support=bravo` refers to the vote options 0 = For, 1 = Against, 2 = Abstain, as in `GovernorBravo`.

  • `quorum=bravo` means that only For votes are counted towards quorum.

  • `quorum=for,abstain` means that both For and Abstain votes are counted towards quorum.

NOTE: The string can be decoded by the standard https://developer.mozilla.org/en-US/docs/Web/API/URLSearchParams[`URLSearchParams`] JavaScript class._

propose

See {IGovernor-propose}.

propose

See {IGovernorCompatibilityBravo-propose}.

queue

See {IGovernorCompatibilityBravo-queue}.

execute

See {IGovernorCompatibilityBravo-execute}.

cancel

Cancels a proposal only if sender is the proposer, or proposer delegates dropped below proposal threshold.

_encodeCalldata

Encodes calldatas with optional function signature.

_storeProposal

Store proposal metadata for later lookup

proposalThreshold

Part of the Governor Bravo's interface: "The number of votes required in order for a voter to become a proposer".

proposals

See {IGovernorCompatibilityBravo-proposals}.

getActions

See {IGovernorCompatibilityBravo-getActions}.

getReceipt

See {IGovernorCompatibilityBravo-getReceipt}.

quorumVotes

See {IGovernorCompatibilityBravo-quorumVotes}.

hasVoted

See {IGovernor-hasVoted}.

_quorumReached

_See {Governor-quorumReached}. In this module, only forVotes count toward the quorum.

_voteSucceeded

_See {Governor-voteSucceeded}. In this module, the forVotes must be scritly over the againstVotes.

_countVote

_See {Governor-countVote}. In this module, the support follows Governor Bravo.

IGovernorCompatibilityBravo

_Interface extension that adds missing functions to the {Governor} core to provide `GovernorBravo` compatibility.

Available since v4.3._

Proposal

Receipt

quorumVotes

Part of the Governor Bravo's interface.

proposals

Part of the Governor Bravo's interface: "The official record of all proposals ever proposed".

propose

Part of the Governor Bravo's interface: "Function used to propose a new proposal".

queue

Part of the Governor Bravo's interface: "Queues a proposal of state succeeded".

execute

Part of the Governor Bravo's interface: "Executes a queued proposal if eta has passed".

cancel

Cancels a proposal only if sender is the proposer, or proposer delegates dropped below proposal threshold.

getActions

Part of the Governor Bravo's interface: "Gets actions of a proposal".

getReceipt

Part of the Governor Bravo's interface: "Gets the receipt for a voter on a given proposal".

proposalThreshold

Part of the Governor Bravo's interface: "The number of votes required in order for a voter to become a proposer".

GovernorCountingSimple

_Extension of {Governor} for simple, 3 options, vote counting.

Available since v4.3._

VoteType

ProposalVote

_proposalVotes

COUNTING_MODE

See {IGovernor-COUNTING_MODE}.

hasVoted

See {IGovernor-hasVoted}.

proposalVotes

Accessor to the internal vote counts.

_quorumReached

_See {Governor-quorumReached}.

_voteSucceeded

_See {Governor-voteSucceeded}. In this module, the forVotes must be scritly over the againstVotes.

_countVote

_See {Governor-countVote}. In this module, the support follows the `VoteType` enum (from Governor Bravo).

GovernorProposalThreshold

_Extension of {Governor} for proposal restriction to token holders with a minimum balance.

Available since v4.3._

propose

See {IGovernor-propose}.

proposalThreshold

Part of the Governor Bravo's interface: "The number of votes required in order for a voter to become a proposer".

ICompoundTimelock

https://github.com/compound-finance/compound-protocol/blob/master/contracts/Timelock.sol[Compound's timelock] interface

receive

GRACE_PERIOD

MINIMUM_DELAY

MAXIMUM_DELAY

admin

pendingAdmin

delay

queuedTransactions

setDelay

acceptAdmin

setPendingAdmin

queueTransaction

cancelTransaction

executeTransaction

GovernorTimelockCompound

_Extension of {Governor} that binds the execution process to a Compound Timelock. This adds a delay, enforced by the external timelock to all successful proposal (in addition to the voting duration). The {Governor} needs to be the admin of the timelock for any operation to be performed. A public, unrestricted, {GovernorTimelockCompound-__acceptAdmin} is available to accept ownership of the timelock.

Using this model means the proposal will be operated by the {TimelockController} and not by the {Governor}. Thus, the assets and permissions must be attached to the {TimelockController}. Any asset sent to the {Governor} will be inaccessible.

Available since v4.3._

ProposalTimelock

_timelock

_proposalTimelocks

TimelockChange

Emitted when the timelock controller used for proposal execution is modified.

constructor

Set the timelock.

supportsInterface

See {IERC165-supportsInterface}.

state

Overriden version of the {Governor-state} function with added support for the `Queued` and `Expired` status.

timelock

Public accessor to check the address of the timelock

proposalEta

Public accessor to check the eta of a queued proposal

queue

Function to queue a proposal to the timelock.

_execute

Overriden execute function that run the already queued proposal through the timelock.

_cancel

_Overriden version of the {Governor-cancel} function to cancel the timelocked proposal if it as already been queued.

_executor

Address through which the governor executes action. In this case, the timelock.

__acceptAdmin

Accept admin right over the timelock.

updateTimelock

_Public endpoint to update the underlying timelock instance. Restricted to the timelock itself, so updates must be proposed, scheduled and executed using the {Governor} workflow.

For security reason, the timelock must be handed over to another admin before setting up a new one. The two operations (hand over the timelock) and do the update can be batched in a single proposal.

Note that if the timelock admin has been handed over in a previous operation, we refuse updates made through the timelock if admin of the timelock has already been accepted and the operation is executed outside the scope of governance._

_updateTimelock

GovernorTimelockControl

_Extension of {Governor} that binds the execution process to an instance of {TimelockController}. This adds a delay, enforced by the {TimelockController} to all successful proposal (in addition to the voting duration). The {Governor} needs the proposer (an ideally the executor) roles for the {Governor} to work properly.

Using this model means the proposal will be operated by the {TimelockController} and not by the {Governor}. Thus, the assets and permissions must be attached to the {TimelockController}. Any asset sent to the {Governor} will be inaccessible.

Available since v4.3._

_timelock

_timelockIds

TimelockChange

Emitted when the timelock controller used for proposal execution is modified.

constructor

Set the timelock.

supportsInterface

See {IERC165-supportsInterface}.

state

Overriden version of the {Governor-state} function with added support for the `Queued` status.

timelock

Public accessor to check the address of the timelock

proposalEta

Public accessor to check the eta of a queued proposal

queue

Function to queue a proposal to the timelock.

_execute

Overriden execute function that run the already queued proposal through the timelock.

_cancel

_Overriden version of the {Governor-cancel} function to cancel the timelocked proposal if it as already been queued.

_executor

Address through which the governor executes action. In this case, the timelock.

updateTimelock

Public endpoint to update the underlying timelock instance. Restricted to the timelock itself, so updates must be proposed, scheduled and executed using the {Governor} workflow.

_updateTimelock

GovernorVotes

_Extension of {Governor} for voting weight extraction from an {ERC20Votes} token.

Available since v4.3._

token

constructor

getVotes

Read the voting weight from the token's built in snapshot mechanism (see {IGovernor-getVotes}).

GovernorVotesComp

_Extension of {Governor} for voting weight extraction from a Comp token.

Available since v4.3._

token

constructor

getVotes

Read the voting weight from the token's built in snapshot mechanism (see {IGovernor-getVotes}).

GovernorVotesQuorumFraction

_Extension of {Governor} for voting weight extraction from an {ERC20Votes} token and a quorum expressed as a fraction of the total supply.

Available since v4.3._

_quorumNumerator

QuorumNumeratorUpdated

constructor

quorumNumerator

quorumDenominator

quorum

module:user-config

_Minimum number of cast voted required for a proposal to be successful.

Note: The `blockNumber` parameter corresponds to the snaphot used for counting vote. This allows to scale the quroum depending on values such as the totalSupply of a token at this block (see {ERC20Votes})._

updateQuorumNumerator

_updateQuorumNumerator

IGovernorTimelock

_Extension of the {IGovernor} for timelock supporting modules.

Available since v4.3._

ProposalQueued

timelock

proposalEta

queue

IERC1271

_Interface of the ERC1271 standard signature validation method for contracts as defined in https://eips.ethereum.org/EIPS/eip-1271[ERC-1271].

Available since v4.1._

isValidSignature

Should return whether the signature provided is valid for the provided data

Name
Type
Description

hash

bytes32

Hash of the data to be signed

signature

bytes

Signature byte array associated with _data

IERC1363

transferAndCall

Transfer tokens from `msg.sender` to another address and then call `onTransferReceived` on receiver

Name
Type
Description

to

address

address The address which you want to transfer to

value

uint256

uint256 The amount of tokens to be transferred

Name
Type
Description

[0]

bool

true unless throwing

transferAndCall

Transfer tokens from `msg.sender` to another address and then call `onTransferReceived` on receiver

Name
Type
Description

to

address

address The address which you want to transfer to

value

uint256

uint256 The amount of tokens to be transferred

data

bytes

bytes Additional data with no specified format, sent in call to `to`

Name
Type
Description

[0]

bool

true unless throwing

transferFromAndCall

Transfer tokens from one address to another and then call `onTransferReceived` on receiver

Name
Type
Description

from

address

address The address which you want to send tokens from

to

address

address The address which you want to transfer to

value

uint256

uint256 The amount of tokens to be transferred

Name
Type
Description

[0]

bool

true unless throwing

transferFromAndCall

Transfer tokens from one address to another and then call `onTransferReceived` on receiver

Name
Type
Description

from

address

address The address which you want to send tokens from

to

address

address The address which you want to transfer to

value

uint256

uint256 The amount of tokens to be transferred

data

bytes

bytes Additional data with no specified format, sent in call to `to`

Name
Type
Description

[0]

bool

true unless throwing

approveAndCall

Approve the passed address to spend the specified amount of tokens on behalf of msg.sender and then call `onApprovalReceived` on spender.

Name
Type
Description

spender

address

address The address which will spend the funds

value

uint256

uint256 The amount of tokens to be spent

approveAndCall

Approve the passed address to spend the specified amount of tokens on behalf of msg.sender and then call `onApprovalReceived` on spender.

Name
Type
Description

spender

address

address The address which will spend the funds

value

uint256

uint256 The amount of tokens to be spent

data

bytes

bytes Additional data with no specified format, sent in call to `spender`

IERC2981

Interface for the NFT Royalty Standard

royaltyInfo

Called with the sale price to determine how much royalty is owed and to whom.

Name
Type
Description

tokenId

uint256

- the NFT asset queried for royalty information

salePrice

uint256

- the sale price of the NFT asset specified by `tokenId`

Name
Type
Description

receiver

address

- address of who should be sent the royalty payment

royaltyAmount

uint256

- the royalty payment amount for `salePrice`

IERC3156FlashBorrower

_Interface of the ERC3156 FlashBorrower, as defined in https://eips.ethereum.org/EIPS/eip-3156[ERC-3156].

Available since v4.1._

onFlashLoan

Receive a flash loan.

Name
Type
Description

initiator

address

The initiator of the loan.

token

address

The loan currency.

amount

uint256

The amount of tokens lent.

fee

uint256

The additional amount of tokens to repay.

data

bytes

Arbitrary data structure, intended to contain user-defined parameters.

Name
Type
Description

[0]

bytes32

The keccak256 hash of "ERC3156FlashBorrower.onFlashLoan"

IERC3156FlashLender

_Interface of the ERC3156 FlashLender, as defined in https://eips.ethereum.org/EIPS/eip-3156[ERC-3156].

Available since v4.1._

maxFlashLoan

The amount of currency available to be lended.

Name
Type
Description

token

address

The loan currency.

Name
Type
Description

[0]

uint256

The amount of `token` that can be borrowed.

flashFee

The fee to be charged for a given loan.

Name
Type
Description

token

address

The loan currency.

amount

uint256

The amount of tokens lent.

Name
Type
Description

[0]

uint256

The amount of `token` to be charged for the loan, on top of the returned principal.

flashLoan

Initiate a flash loan.

Name
Type
Description

receiver

contract IERC3156FlashBorrower

The receiver of the tokens in the loan, and the receiver of the callback.

token

address

The loan currency.

amount

uint256

The amount of tokens lent.

data

bytes

Arbitrary data structure, intended to contain user-defined parameters.

IERC2612

ERC2771Context

Context variant with ERC2771 support.

_trustedForwarder

constructor

isTrustedForwarder

_msgSender

_msgData

MinimalForwarder

Simple minimal forwarder to be used together with an ERC2771 compatible contract. See {ERC2771Context}.

ForwardRequest

_TYPEHASH

_nonces

constructor

getNonce

verify

execute

ERC1967Proxy

This contract implements an upgradeable proxy. It is upgradeable because calls are delegated to an implementation address that can be changed. This address is stored in storage in the location specified by https://eips.ethereum.org/EIPS/eip-1967[EIP1967], so that it doesn't conflict with the storage layout of the implementation behind the proxy.

constructor

_Initializes the upgradeable proxy with an initial implementation specified by `_logic`.

If `_data` is nonempty, it's used as data in a delegate call to `logic`. This will typically be an encoded function call, and allows initializating the storage of the proxy like a Solidity constructor.

_implementation

Returns the current implementation address.

ERC1967Upgrade

_This abstract contract provides getters and event emitting update functions for https://eips.ethereum.org/EIPS/eip-1967[EIP1967] slots.

Available since v4.1._

_ROLLBACK_SLOT

_IMPLEMENTATION_SLOT

Storage slot with the address of the current implementation. This is the keccak-256 hash of "eip1967.proxy.implementation" subtracted by 1, and is validated in the constructor.

Upgraded

Emitted when the implementation is upgraded.

_getImplementation

Returns the current implementation address.

_setImplementation

Stores a new address in the EIP1967 implementation slot.

_upgradeTo

_Perform implementation upgrade

Emits an {Upgraded} event._

_upgradeToAndCall

_Perform implementation upgrade with additional setup call.

Emits an {Upgraded} event._

_upgradeToAndCallSecure

_Perform implementation upgrade with security checks for UUPS proxies, and additional setup call.

Emits an {Upgraded} event._

_ADMIN_SLOT

Storage slot with the admin of the contract. This is the keccak-256 hash of "eip1967.proxy.admin" subtracted by 1, and is validated in the constructor.

AdminChanged

Emitted when the admin account has changed.

_getAdmin

Returns the current admin.

_setAdmin

Stores a new address in the EIP1967 admin slot.

_changeAdmin

_Changes the admin of the proxy.

Emits an {AdminChanged} event._

_BEACON_SLOT

The storage slot of the UpgradeableBeacon contract which defines the implementation for this proxy. This is bytes32(uint256(keccak256('eip1967.proxy.beacon')) - 1)) and is validated in the constructor.

BeaconUpgraded

Emitted when the beacon is upgraded.

_getBeacon

Returns the current beacon.

_setBeacon

Stores a new beacon in the EIP1967 beacon slot.

_upgradeBeaconToAndCall

_Perform beacon upgrade with additional setup call. Note: This upgrades the address of the beacon, it does not upgrade the implementation contained in the beacon (see {UpgradeableBeacon-_setImplementation} for that).

Emits a {BeaconUpgraded} event._

Proxy

_This abstract contract provides a fallback function that delegates all calls to another contract using the EVM instruction `delegatecall`. We refer to the second contract as the implementation behind the proxy, and it has to be specified by overriding the virtual {_implementation} function.

Additionally, delegation to the implementation can be triggered manually through the {_fallback} function, or to a different contract through the {_delegate} function.

The success and return data of the delegated call will be returned back to the caller of the proxy._

_delegate

_Delegates the current call to `implementation`.

This function does not return to its internall call site, it will return directly to the external caller._

_implementation

_This is a virtual function that should be overriden so it returns the address to which the fallback function and {fallback} should delegate.

_fallback

_Delegates the current call to the address returned by `_implementation()`.

This function does not return to its internall call site, it will return directly to the external caller._

fallback

_Fallback function that delegates calls to the address returned by `implementation()`. Will run if no other function in the contract matches the call data.

receive

_Fallback function that delegates calls to the address returned by `implementation()`. Will run if call data is empty.

_beforeFallback

_Hook that is called before falling back to the implementation. Can happen as part of a manual `_fallback` call, or as part of the Solidity `fallback` or `receive` functions.

If overriden should call `super.beforeFallback()`.

BeaconProxy

_This contract implements a proxy that gets the implementation address for each call from a {UpgradeableBeacon}.

The beacon address is stored in storage slot `uint256(keccak256('eip1967.proxy.beacon')) - 1`, so that it doesn't conflict with the storage layout of the implementation behind the proxy.

Available since v3.4._

constructor

_Initializes the proxy with `beacon`.

If `data` is nonempty, it's used as data in a delegate call to the implementation returned by the beacon. This will typically be an encoded function call, and allows initializating the storage of the proxy like a Solidity constructor.

Requirements:

  • `beacon` must be a contract with the interface {IBeacon}._

_beacon

Returns the current beacon address.

_implementation

Returns the current implementation address of the associated beacon.

_setBeacon

_Changes the proxy to use a new beacon. Deprecated: see {_upgradeBeaconToAndCall}.

If `data` is nonempty, it's used as data in a delegate call to the implementation returned by the beacon.

Requirements:

  • `beacon` must be a contract.

  • The implementation returned by `beacon` must be a contract._

IBeacon

This is the interface that {BeaconProxy} expects of its beacon.

implementation

_Must return an address that can be used as a delegate call target.

{BeaconProxy} will check that this address is a contract._

UpgradeableBeacon

_This contract is used in conjunction with one or more instances of {BeaconProxy} to determine their implementation contract, which is where they will delegate all function calls.

An owner is able to change the implementation the beacon points to, thus upgrading the proxies that use this beacon._

_implementation

Upgraded

Emitted when the implementation returned by the beacon is changed.

constructor

Sets the address of the initial implementation, and the deployer account as the owner who can upgrade the beacon.

implementation

Returns the current implementation address.

upgradeTo

_Upgrades the beacon to a new implementation.

Emits an {Upgraded} event.

Requirements:

  • msg.sender must be the owner of the contract.

  • `newImplementation` must be a contract._

_setImplementation

_Sets the implementation contract address for this beacon

Requirements:

  • `newImplementation` must be a contract._

ProxyAdmin

This is an auxiliary contract meant to be assigned as the admin of a {TransparentUpgradeableProxy}. For an explanation of why you would want to use this see the documentation for {TransparentUpgradeableProxy}.

getProxyImplementation

_Returns the current implementation of `proxy`.

Requirements:

  • This contract must be the admin of `proxy`._

getProxyAdmin

_Returns the current admin of `proxy`.

Requirements:

  • This contract must be the admin of `proxy`._

changeProxyAdmin

_Changes the admin of `proxy` to `newAdmin`.

Requirements:

  • This contract must be the current admin of `proxy`._

upgrade

_Upgrades `proxy` to `implementation`. See {TransparentUpgradeableProxy-upgradeTo}.

Requirements:

  • This contract must be the admin of `proxy`._

upgradeAndCall

_Upgrades `proxy` to `implementation` and calls a function on the new implementation. See {TransparentUpgradeableProxy-upgradeToAndCall}.

Requirements:

  • This contract must be the admin of `proxy`._

TransparentUpgradeableProxy

_This contract implements a proxy that is upgradeable by an admin.

To avoid https://medium.com/nomic-labs-blog/malicious-backdoors-in-ethereum-proxies-62629adf3357[proxy selector clashing], which can potentially be used in an attack, this contract uses the https://blog.openzeppelin.com/the-transparent-proxy-pattern/[transparent proxy pattern]. This pattern implies two things that go hand in hand:

  1. If any account other than the admin calls the proxy, the call will be forwarded to the implementation, even if that call matches one of the admin functions exposed by the proxy itself.

  2. If the admin calls the proxy, it can access the admin functions, but its calls will never be forwarded to the implementation. If the admin tries to call a function on the implementation it will fail with an error that says "admin cannot fallback to proxy target".

These properties mean that the admin account can only be used for admin actions like upgrading the proxy or changing the admin, so it's best if it's a dedicated account that is not used for anything else. This will avoid headaches due to sudden errors when trying to call a function from the proxy implementation.

Our recommendation is for the dedicated account to be an instance of the {ProxyAdmin} contract. If set up this way, you should think of the `ProxyAdmin` instance as the real administrative interface of your proxy._

constructor

_Initializes an upgradeable proxy managed by `_admin`, backed by the implementation at `_logic`, and optionally initialized with `data` as explained in {ERC1967Proxy-constructor}.

ifAdmin

Modifier used internally that will delegate the call to the implementation unless the sender is the admin.

admin

_Returns the current admin.

NOTE: Only the admin can call this function. See {ProxyAdmin-getProxyAdmin}.

TIP: To get this value clients can read directly from the storage slot shown below (specified by EIP1967) using the https://eth.wiki/json-rpc/API#eth_getstorageat[`eth_getStorageAt`] RPC call. `0xb53127684a568b3173ae13b9f8a6016e243e63b6e8ee1178d6a717850b5d6103`_

implementation

_Returns the current implementation.

NOTE: Only the admin can call this function. See {ProxyAdmin-getProxyImplementation}.

TIP: To get this value clients can read directly from the storage slot shown below (specified by EIP1967) using the https://eth.wiki/json-rpc/API#eth_getstorageat[`eth_getStorageAt`] RPC call. `0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc`_

changeAdmin

_Changes the admin of the proxy.

Emits an {AdminChanged} event.

NOTE: Only the admin can call this function. See {ProxyAdmin-changeProxyAdmin}._

upgradeTo

_Upgrade the implementation of the proxy.

NOTE: Only the admin can call this function. See {ProxyAdmin-upgrade}._

upgradeToAndCall

_Upgrade the implementation of the proxy, and then call a function from the new implementation as specified by `data`, which should be an encoded function call. This is useful to initialize new storage variables in the proxied contract.

NOTE: Only the admin can call this function. See {ProxyAdmin-upgradeAndCall}._

_admin

Returns the current admin.

_beforeFallback

_Makes sure the admin cannot access the fallback function. See {Proxy-beforeFallback}.

UUPSUpgradeable

_An upgradeability mechanism designed for UUPS proxies. The functions included here can perform an upgrade of an {ERC1967Proxy}, when this contract is set as the implementation behind such a proxy.

A security mechanism ensures that an upgrade does not turn off upgradeability accidentally, although this risk is reinstated if the upgrade retains upgradeability but removes the security mechanism, e.g. by replacing `UUPSUpgradeable` with a custom implementation of upgrades.

The {_authorizeUpgrade} function must be overridden to include access restriction to the upgrade mechanism.

Available since v4.1._

upgradeTo

_Upgrade the implementation of the proxy to `newImplementation`.

Calls {_authorizeUpgrade}.

Emits an {Upgraded} event._

upgradeToAndCall

_Upgrade the implementation of the proxy to `newImplementation`, and subsequently execute the function call encoded in `data`.

Calls {_authorizeUpgrade}.

Emits an {Upgraded} event._

_authorizeUpgrade

_Function that should revert when `msg.sender` is not authorized to upgrade the contract. Called by {upgradeTo} and {upgradeToAndCall}.

Normally, this function will use an xref:access.adoc[access control] modifier such as {Ownable-onlyOwner}.

```solidity function authorizeUpgrade(address) internal override onlyOwner {} ```

Pausable

_Contract module which allows children to implement an emergency stop mechanism that can be triggered by an authorized account.

This module is used through inheritance. It will make available the modifiers `whenNotPaused` and `whenPaused`, which can be applied to the functions of your contract. Note that they will not be pausable by simply including this module, only once the modifiers are put in place._

Paused

Emitted when the pause is triggered by `account`.

Unpaused

Emitted when the pause is lifted by `account`.

_paused

constructor

Initializes the contract in unpaused state.

paused

Returns true if the contract is paused, and false otherwise.

whenNotPaused

_Modifier to make a function callable only when the contract is not paused.

Requirements:

  • The contract must not be paused._

whenPaused

_Modifier to make a function callable only when the contract is paused.

Requirements:

  • The contract must be paused._

_pause

_Triggers stopped state.

Requirements:

  • The contract must not be paused._

_unpause

_Returns to normal state.

Requirements:

  • The contract must be paused._

PullPayment

_Simple implementation of a https://consensys.github.io/smart-contract-best-practices/recommendations/#favor-pull-over-push-for-external-calls[pull-payment] strategy, where the paying contract doesn't interact directly with the receiver account, which must withdraw its payments itself.

Pull-payments are often considered the best practice when it comes to sending Ether, security-wise. It prevents recipients from blocking execution, and eliminates reentrancy concerns.

TIP: If you would like to learn more about reentrancy and alternative ways to protect against it, check out our blog post https://blog.openzeppelin.com/reentrancy-after-istanbul/[Reentrancy After Istanbul].

To use, derive from the `PullPayment` contract, and use {asyncTransfer} instead of Solidity's `transfer` function. Payees can query their due payments with {payments}, and retrieve them with {withdrawPayments}.

_escrow

constructor

withdrawPayments

_Withdraw accumulated payments, forwarding all gas to the recipient.

Note that any account can call this function, not just the `payee`. This means that contracts unaware of the `PullPayment` protocol can still receive funds this way, by having a separate account call {withdrawPayments}.

WARNING: Forwarding all gas opens the door to reentrancy vulnerabilities. Make sure you trust the recipient, or are either following the checks-effects-interactions pattern or using {ReentrancyGuard}._

Name
Type
Description

payee

address payable

Whose payments will be withdrawn.

payments

Returns the payments owed to an address.

Name
Type
Description

dest

address

The creditor's address.

_asyncTransfer

Called by the payer to store the sent amount as credit to be pulled. Funds sent in this way are stored in an intermediate {Escrow} contract, so there is no danger of them being spent before withdrawal.

Name
Type
Description

dest

address

The destination address of the funds.

amount

uint256

The amount to transfer.

ERC1155

_Implementation of the basic standard multi-token. See https://eips.ethereum.org/EIPS/eip-1155 Originally based on code by Enjin: https://github.com/enjin/erc-1155

Available since v3.1._

_balances

_operatorApprovals

_uri

constructor

_See {setURI}.

supportsInterface

See {IERC165-supportsInterface}.

uri

_See {IERC1155MetadataURI-uri}.

This implementation returns the same URI for all token types. It relies on the token type ID substitution mechanism https://eips.ethereum.org/EIPS/eip-1155#metadata[defined in the EIP].

Clients calling this function must replace the `{id}` substring with the actual token type ID._

balanceOf

_See {IERC1155-balanceOf}.

Requirements:

  • `account` cannot be the zero address._

balanceOfBatch

_See {IERC1155-balanceOfBatch}.

Requirements:

  • `accounts` and `ids` must have the same length._

setApprovalForAll

See {IERC1155-setApprovalForAll}.

isApprovedForAll

See {IERC1155-isApprovedForAll}.

safeTransferFrom

See {IERC1155-safeTransferFrom}.

safeBatchTransferFrom

See {IERC1155-safeBatchTransferFrom}.

_safeTransferFrom

_Transfers `amount` tokens of token type `id` from `from` to `to`.

Emits a {TransferSingle} event.

Requirements:

  • `to` cannot be the zero address.

  • `from` must have a balance of tokens of type `id` of at least `amount`.

  • If `to` refers to a smart contract, it must implement {IERC1155Receiver-onERC1155Received} and return the acceptance magic value._

_safeBatchTransferFrom

_xref:ROOT:erc1155.adoc#batch-operations[Batched] version of {_safeTransferFrom}.

Emits a {TransferBatch} event.

Requirements:

  • If `to` refers to a smart contract, it must implement {IERC1155Receiver-onERC1155BatchReceived} and return the acceptance magic value._

_setURI

_Sets a new URI for all token types, by relying on the token type ID substitution mechanism https://eips.ethereum.org/EIPS/eip-1155#metadata[defined in the EIP].

By this mechanism, any occurrence of the `{id}` substring in either the URI or any of the amounts in the JSON file at said URI will be replaced by clients with the token type ID.

For example, the `https://token-cdn-domain/{id}.json` URI would be interpreted by clients as `https://token-cdn-domain/000000000000000000000000000000000000000000000000000000000004cce0.json` for token type ID 0x4cce0.

See {uri}.

Because these URIs cannot be meaningfully represented by the {URI} event, this function emits no events._

_mint

_Creates `amount` tokens of token type `id`, and assigns them to `account`.

Emits a {TransferSingle} event.

Requirements:

  • `account` cannot be the zero address.

  • If `account` refers to a smart contract, it must implement {IERC1155Receiver-onERC1155Received} and return the acceptance magic value._

_mintBatch

_xref:ROOT:erc1155.adoc#batch-operations[Batched] version of {_mint}.

Requirements:

  • `ids` and `amounts` must have the same length.

  • If `to` refers to a smart contract, it must implement {IERC1155Receiver-onERC1155BatchReceived} and return the acceptance magic value._

_burn

_Destroys `amount` tokens of token type `id` from `account`

Requirements:

  • `account` cannot be the zero address.

  • `account` must have at least `amount` tokens of token type `id`._

_burnBatch

_xref:ROOT:erc1155.adoc#batch-operations[Batched] version of {_burn}.

Requirements:

  • `ids` and `amounts` must have the same length._

_beforeTokenTransfer

_Hook that is called before any token transfer. This includes minting and burning, as well as batched variants.

The same hook is called on both single and batched variants. For single transfers, the length of the `id` and `amount` arrays will be 1.

Calling conditions (for each `id` and `amount` pair):

  • When `from` and `to` are both non-zero, `amount` of ``from``'s tokens of token type `id` will be transferred to `to`.

  • When `from` is zero, `amount` tokens of token type `id` will be minted for `to`.

  • when `to` is zero, `amount` of ``from``'s tokens of token type `id` will be burned.

  • `from` and `to` are never both zero.

  • `ids` and `amounts` have the same, non-zero length.

To learn more about hooks, head to xref:ROOT:extending-contracts.adoc#using-hooks[Using Hooks]._

_doSafeTransferAcceptanceCheck

_doSafeBatchTransferAcceptanceCheck

_asSingletonArray

IERC1155

_Required interface of an ERC1155 compliant contract, as defined in the https://eips.ethereum.org/EIPS/eip-1155[EIP].

Available since v3.1._

TransferSingle

Emitted when `value` tokens of token type `id` are transferred from `from` to `to` by `operator`.

TransferBatch

Equivalent to multiple {TransferSingle} events, where `operator`, `from` and `to` are the same for all transfers.

ApprovalForAll

Emitted when `account` grants or revokes permission to `operator` to transfer their tokens, according to `approved`.

URI

_Emitted when the URI for token type `id` changes to `value`, if it is a non-programmatic URI.

If an {URI} event was emitted for `id`, the standard https://eips.ethereum.org/EIPS/eip-1155#metadata-extensions[guarantees] that `value` will equal the value returned by {IERC1155MetadataURI-uri}._

balanceOf

_Returns the amount of tokens of token type `id` owned by `account`.

Requirements:

  • `account` cannot be the zero address._

balanceOfBatch

_xref:ROOT:erc1155.adoc#batch-operations[Batched] version of {balanceOf}.

Requirements:

  • `accounts` and `ids` must have the same length._

setApprovalForAll

_Grants or revokes permission to `operator` to transfer the caller's tokens, according to `approved`,

Emits an {ApprovalForAll} event.

Requirements:

  • `operator` cannot be the caller._

isApprovedForAll

_Returns true if `operator` is approved to transfer ``account``'s tokens.

See {setApprovalForAll}._

safeTransferFrom

_Transfers `amount` tokens of token type `id` from `from` to `to`.

Emits a {TransferSingle} event.

Requirements:

  • `to` cannot be the zero address.

  • If the caller is not `from`, it must be have been approved to spend ``from``'s tokens via {setApprovalForAll}.

  • `from` must have a balance of tokens of type `id` of at least `amount`.

  • If `to` refers to a smart contract, it must implement {IERC1155Receiver-onERC1155Received} and return the acceptance magic value._

safeBatchTransferFrom

_xref:ROOT:erc1155.adoc#batch-operations[Batched] version of {safeTransferFrom}.

Emits a {TransferBatch} event.

Requirements:

  • `ids` and `amounts` must have the same length.

  • If `to` refers to a smart contract, it must implement {IERC1155Receiver-onERC1155BatchReceived} and return the acceptance magic value._

IERC1155Receiver

Available since v3.1.

onERC1155Received

Handles the receipt of a single ERC1155 token type. This function is called at the end of a `safeTransferFrom` after the balance has been updated. To accept the transfer, this must return `bytes4(keccak256("onERC1155Received(address,address,uint256,uint256,bytes)"))` (i.e. 0xf23a6e61, or its own function selector). @param operator The address which initiated the transfer (i.e. msg.sender) @param from The address which previously owned the token @param id The ID of the token being transferred @param value The amount of tokens being transferred @param data Additional data with no specified format @return `bytes4(keccak256("onERC1155Received(address,address,uint256,uint256,bytes)"))` if transfer is allowed

onERC1155BatchReceived

Handles the receipt of a multiple ERC1155 token types. This function is called at the end of a `safeBatchTransferFrom` after the balances have been updated. To accept the transfer(s), this must return `bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)"))` (i.e. 0xbc197c81, or its own function selector). @param operator The address which initiated the batch transfer (i.e. msg.sender) @param from The address which previously owned the token @param ids An array containing ids of each token being transferred (order and length must match values array) @param values An array containing amounts of each token being transferred (order and length must match ids array) @param data Additional data with no specified format @return `bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)"))` if transfer is allowed

ERC1155Burnable

_Extension of {ERC1155} that allows token holders to destroy both their own tokens and those that they have been approved to use.

Available since v3.1._

burn

burnBatch

ERC1155Pausable

_ERC1155 token with pausable token transfers, minting and burning.

Useful for scenarios such as preventing trades until the end of an evaluation period, or having an emergency switch for freezing all token transfers in the event of a large bug.

Available since v3.1._

_beforeTokenTransfer

_See {ERC1155-_beforeTokenTransfer}.

Requirements:

  • the contract must not be paused._

ERC1155Supply

_Extension of ERC1155 that adds tracking of total supply per id.

Useful for scenarios where Fungible and Non-fungible tokens have to be clearly identified. Note: While a totalSupply of 1 might mean the corresponding is an NFT, there is no guarantees that no other token with the same id are not going to be minted._

_totalSupply

totalSupply

Total amount of tokens in with a given id.

exists

Indicates weither any token exist with a given id, or not.

_mint

_See {ERC1155-mint}.

_mintBatch

_See {ERC1155-mintBatch}.

_burn

_See {ERC1155-burn}.

_burnBatch

_See {ERC1155-burnBatch}.

IERC1155MetadataURI

_Interface of the optional ERC1155MetadataExtension interface, as defined in the https://eips.ethereum.org/EIPS/eip-1155#metadata-extensions[EIP].

Available since v3.1._

uri

_Returns the URI for token type `id`.

If the `{id}` substring is present in the URI, it must be replaced by clients with the actual token type ID._

ERC1155PresetMinterPauser

_{ERC1155} token, including:

  • ability for holders to burn (destroy) their tokens

  • a minter role that allows for token minting (creation)

  • a pauser role that allows to stop all token transfers

This contract uses {AccessControl} to lock permissioned functions using the different roles - head to its documentation for details.

The account that deploys the contract will be granted the minter and pauser roles, as well as the default admin role, which will let it grant both minter and pauser roles to other accounts._

MINTER_ROLE

PAUSER_ROLE

constructor

Grants `DEFAULT_ADMIN_ROLE`, `MINTER_ROLE`, and `PAUSER_ROLE` to the account that deploys the contract.

mint

_Creates `amount` new tokens for `to`, of token type `id`.

See {ERC1155-_mint}.

Requirements:

  • the caller must have the `MINTER_ROLE`._

mintBatch

xref:ROOT:erc1155.adoc#batch-operations[Batched] variant of {mint}.

pause

_Pauses all token transfers.

See {ERC1155Pausable} and {Pausable-_pause}.

Requirements:

  • the caller must have the `PAUSER_ROLE`._

unpause

_Unpauses all token transfers.

See {ERC1155Pausable} and {Pausable-_unpause}.

Requirements:

  • the caller must have the `PAUSER_ROLE`._

supportsInterface

See {IERC165-supportsInterface}.

_beforeTokenTransfer

ERC1155Holder

Available since v3.1.

onERC1155Received

onERC1155BatchReceived

ERC1155Receiver

Available since v3.1.

supportsInterface

See {IERC165-supportsInterface}.

ERC20

_Implementation of the {IERC20} interface.

This implementation is agnostic to the way tokens are created. This means that a supply mechanism has to be added in a derived contract using {_mint}. For a generic mechanism see {ERC20PresetMinterPauser}.

TIP: For a detailed writeup see our guide https://forum.zeppelin.solutions/t/how-to-implement-erc20-supply-mechanisms/226[How to implement supply mechanisms].

We have followed general OpenZeppelin Contracts guidelines: functions revert instead returning `false` on failure. This behavior is nonetheless conventional and does not conflict with the expectations of ERC20 applications.

Additionally, an {Approval} event is emitted on calls to {transferFrom}. This allows applications to reconstruct the allowance for all accounts just by listening to said events. Other implementations of the EIP may not emit these events, as it isn't required by the specification.

Finally, the non-standard {decreaseAllowance} and {increaseAllowance} functions have been added to mitigate the well-known issues around setting allowances. See {IERC20-approve}._

_balances

_allowances

_totalSupply

_name

_symbol

constructor

_Sets the values for {name} and {symbol}.

The default value of {decimals} is 18. To select a different value for {decimals} you should overload it.

All two of these values are immutable: they can only be set once during construction._

name

Returns the name of the token.

symbol

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

decimals

_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 value {ERC20} uses, unless this function is 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}._

totalSupply

See {IERC20-totalSupply}.

balanceOf

See {IERC20-balanceOf}.

transfer

_See {IERC20-transfer}.

Requirements:

  • `recipient` cannot be the zero address.

  • the caller must have a balance of at least `amount`._

allowance

See {IERC20-allowance}.

approve

_See {IERC20-approve}.

Requirements:

  • `spender` cannot be the zero address._

transferFrom

_See {IERC20-transferFrom}.

Emits an {Approval} event indicating the updated allowance. This is not required by the EIP. See the note at the beginning of {ERC20}.

Requirements:

  • `sender` and `recipient` cannot be the zero address.

  • `sender` must have a balance of at least `amount`.

  • the caller must have allowance for ``sender``'s tokens of at least `amount`._

increaseAllowance

_Atomically increases the allowance granted to `spender` by the caller.

This is an alternative to {approve} that can be used as a mitigation for problems described in {IERC20-approve}.

Emits an {Approval} event indicating the updated allowance.

Requirements:

  • `spender` cannot be the zero address._

decreaseAllowance

_Atomically decreases the allowance granted to `spender` by the caller.

This is an alternative to {approve} that can be used as a mitigation for problems described in {IERC20-approve}.

Emits an {Approval} event indicating the updated allowance.

Requirements:

  • `spender` cannot be the zero address.

  • `spender` must have allowance for the caller of at least `subtractedValue`._

_transfer

_Moves `amount` of tokens from `sender` to `recipient`.

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

Emits a {Transfer} event.

Requirements:

  • `sender` cannot be the zero address.

  • `recipient` cannot be the zero address.

  • `sender` must have a balance of at least `amount`._

_mint

_Creates `amount` tokens and assigns them to `account`, increasing the total supply.

Emits a {Transfer} event with `from` set to the zero address.

Requirements:

  • `account` cannot be the zero address._

_burn

_Destroys `amount` tokens from `account`, reducing the total supply.

Emits a {Transfer} event with `to` set to the zero address.

Requirements:

  • `account` cannot be the zero address.

  • `account` must have at least `amount` tokens._

_approve

_Sets `amount` 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 {Approval} event.

Requirements:

  • `owner` cannot be the zero address.

  • `spender` cannot be the zero address._

_beforeTokenTransfer

_Hook that is called before any transfer of tokens. This includes minting and burning.

Calling conditions:

  • when `from` and `to` are both non-zero, `amount` of ``from``'s tokens will be transferred to `to`.

  • when `from` is zero, `amount` tokens will be minted for `to`.

  • when `to` is zero, `amount` of ``from``'s tokens will be burned.

  • `from` and `to` are never both zero.

To learn more about hooks, head to xref:ROOT:extending-contracts.adoc#using-hooks[Using Hooks]._

_afterTokenTransfer

_Hook that is called after any transfer of tokens. This includes minting and burning.

Calling conditions:

  • when `from` and `to` are both non-zero, `amount` of ``from``'s tokens has been transferred to `to`.

  • when `from` is zero, `amount` tokens have been minted for `to`.

  • when `to` is zero, `amount` of ``from``'s tokens have been burned.

  • `from` and `to` are never both zero.

To learn more about hooks, head to xref:ROOT:extending-contracts.adoc#using-hooks[Using Hooks]._

IERC20

Interface of the ERC20 standard as defined in the EIP.

totalSupply

Returns the amount of tokens in existence.

balanceOf

Returns the amount of tokens owned by `account`.

transfer

_Moves `amount` tokens from the caller's account to `recipient`.

Returns a boolean value indicating whether the operation succeeded.

Emits a {Transfer} event._

allowance

_Returns the remaining number of tokens that `spender` will be allowed to spend on behalf of `owner` through {transferFrom}. This is zero by default.

This value changes when {approve} or {transferFrom} are called._

approve

_Sets `amount` as the allowance of `spender` over the caller's tokens.

Returns a boolean value indicating whether the operation succeeded.

IMPORTANT: Beware that changing an allowance with this method brings the risk 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 {Approval} event._

transferFrom

_Moves `amount` tokens from `sender` to `recipient` using the allowance mechanism. `amount` is then deducted from the caller's allowance.

Returns a boolean value indicating whether the operation succeeded.

Emits a {Transfer} event._

Transfer

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

Note that `value` may be zero._

Approval

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

ERC20Burnable

Extension of {ERC20} that allows token holders to destroy both their own tokens and those that they have an allowance for, in a way that can be recognized off-chain (via event analysis).

burn

_Destroys `amount` tokens from the caller.

See {ERC20-burn}.

burnFrom

_Destroys `amount` 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 `amount`._

ERC20Capped

Extension of {ERC20} that adds a cap to the supply of tokens.

_cap

constructor

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

cap

Returns the cap on the token's total supply.

_mint

_See {ERC20-mint}.

ERC20FlashMint

_Implementation of the ERC3156 Flash loans extension, as defined in https://eips.ethereum.org/EIPS/eip-3156[ERC-3156].

Adds the {flashLoan} method, which provides flash loan support at the token level. By default there is no fee, but this can be changed by overriding {flashFee}.

Available since v4.1._

_RETURN_VALUE

maxFlashLoan

Returns the maximum amount of tokens available for loan.

Name
Type
Description

token

address

The address of the token that is requested.

Name
Type
Description

[0]

uint256

The amont of token that can be loaned.

flashFee

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.

Name
Type
Description

token

address

The token to be flash loaned.

amount

uint256

The amount of tokens to be loaned.

Name
Type
Description

[0]

uint256

The fees applied to the corresponding flash loan.

flashLoan

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 amount + fee tokens and have them approved back to the token contract itself so they can be burned.

Name
Type
Description

receiver

contract IERC3156FlashBorrower

The receiver of the flash loan. Should implement the {IERC3156FlashBorrower.onFlashLoan} interface.

token

address

The token to be flash loaned. Only `address(this)` is supported.

amount

uint256

The amount of tokens to be loaned.

data

bytes

An arbitrary datafield that is passed to the receiver.

Name
Type
Description

[0]

bool

`true` is the flash loan was successful.

ERC20Pausable

_ERC20 token with pausable token transfers, minting and burning.

Useful for scenarios such as preventing trades until the end of an evaluation period, or having an emergency switch for freezing all token transfers in the event of a large bug._

_beforeTokenTransfer

_See {ERC20-_beforeTokenTransfer}.

Requirements:

  • the contract must not be paused._

ERC20Snapshot

_This contract extends an ERC20 token with a snapshot mechanism. When a snapshot is created, the balances and total supply at the time are recorded for later access.

This can be used to safely create mechanisms based on token balances such as trustless dividends or weighted voting. In naive implementations it's possible to perform a "double spend" attack by reusing the same balance from different accounts. By using snapshots to calculate dividends or voting power, those attacks no longer apply. It can also be used to create an efficient ERC20 forking mechanism.

Snapshots are created by the internal {_snapshot} function, which will emit the {Snapshot} event and return a snapshot id. To get the total supply at the time of a snapshot, call the function {totalSupplyAt} with the snapshot id. To get the balance of an account at the time of a snapshot, call the {balanceOfAt} function with the snapshot id and the account address.

NOTE: Snapshot policy can be customized by overriding the {_getCurrentSnapshotId} method. For example, having it return `block.number` will trigger the creation of snapshot at the begining of each new block. When overridding this function, be careful about the monotonicity of its result. Non-monotonic snapshot ids will break the contract.

Implementing snapshots for every block using this method will incur significant gas costs. For a gas-efficient alternative consider {ERC20Votes}.

==== Gas Costs

Snapshots are efficient. Snapshot creation is O(1). Retrieval of balances or total supply from a snapshot is O(log n) in the number of snapshots that have been created, although n for a specific account will generally be much smaller since identical balances in subsequent snapshots are stored as a single entry.

There is a constant overhead for normal ERC20 transfers due to the additional snapshot bookkeeping. This overhead is only significant for the first transfer that immediately follows a snapshot for a particular account. Subsequent transfers will have normal cost until the next snapshot, and so on._

Snapshots

_accountBalanceSnapshots

_totalSupplySnapshots

_currentSnapshotId

Snapshot

_Emitted by {snapshot} when a snapshot identified by `id` is created.

_snapshot

_Creates a new snapshot and returns its snapshot id.

Emits a {Snapshot} event that contains the same id.

{_snapshot} is `internal` and you have to decide how to expose it externally. Its usage may be restricted to a set of accounts, for example using {AccessControl}, or it may be open to the public.

[WARNING] ==== While an open way of calling {_snapshot} is required for certain trust minimization mechanisms such as forking, you must consider that it can potentially be used by attackers in two ways.

First, it can be used to increase the cost of retrieval of values from snapshots, although it will grow logarithmically thus rendering this attack ineffective in the long term. Second, it can be used to target specific accounts and increase the cost of ERC20 transfers for them, in the ways specified in the Gas Costs section above.

We haven't measured the actual numbers; if this is something you're interested in please reach out to us. ====_

_getCurrentSnapshotId

Get the current snapshotId

balanceOfAt

Retrieves the balance of `account` at the time `snapshotId` was created.

totalSupplyAt

Retrieves the total supply at the time `snapshotId` was created.

_beforeTokenTransfer

_Hook that is called before any transfer of tokens. This includes minting and burning.

Calling conditions:

  • when `from` and `to` are both non-zero, `amount` of ``from``'s tokens will be transferred to `to`.

  • when `from` is zero, `amount` tokens will be minted for `to`.

  • when `to` is zero, `amount` of ``from``'s tokens will be burned.

  • `from` and `to` are never both zero.

To learn more about hooks, head to xref:ROOT:extending-contracts.adoc#using-hooks[Using Hooks]._

_valueAt

_updateAccountSnapshot

_updateTotalSupplySnapshot

_updateSnapshot

_lastSnapshotId

ERC20Votes

_Extension of ERC20 to support Compound-like voting and delegation. This version is more generic than Compound's, and supports token supply up to 2^224^ - 1, while COMP is limited to 2^96^ - 1.

NOTE: If exact COMP compatibility is required, use the {ERC20VotesComp} variant of this module.

This extension keeps a history (checkpoints) of each account's vote power. Vote power can be delegated either by calling the {delegate} function directly, or by providing a signature to be used with {delegateBySig}. Voting power can be queried through the public accessors {getVotes} and {getPastVotes}.

By default, token balance does not account for voting power. This makes transfers cheaper. The downside is that it requires users to delegate to themselves in order to activate checkpoints and have their voting power tracked. Enabling self-delegation can easily be done by overriding the {delegates} function. Keep in mind however that this will significantly increase the base gas cost of transfers.

Available since v4.2._

Checkpoint

_DELEGATION_TYPEHASH

_delegates

_checkpoints

_totalSupplyCheckpoints

DelegateChanged

Emitted when an account changes their delegate.

DelegateVotesChanged

Emitted when a token transfer or delegate change results in changes to an account's voting power.

checkpoints

Get the `pos`-th checkpoint for `account`.

numCheckpoints

Get number of checkpoints for `account`.

delegates

Get the address `account` is currently delegating to.

getVotes

Gets the current votes balance for `account`

getPastVotes

_Retrieve the number of votes for `account` at the end of `blockNumber`.

Requirements:

  • `blockNumber` must have been already mined_

getPastTotalSupply

_Retrieve the `totalSupply` at the end of `blockNumber`. Note, this value is the sum of all balances. It is but NOT the sum of all the delegated votes!

Requirements:

  • `blockNumber` must have been already mined_

_checkpointsLookup

Lookup a value in a list of (sorted) checkpoints.

delegate

Delegate votes from the sender to `delegatee`.

delegateBySig

Delegates votes from signer to `delegatee`

_maxSupply

Maximum token supply. Defaults to `type(uint224).max` (2^224^ - 1).

_mint

Snapshots the totalSupply after it has been increased.

_burn

Snapshots the totalSupply after it has been decreased.

_afterTokenTransfer

_Move voting power when tokens are transferred.

Emits a {DelegateVotesChanged} event._

_delegate

_Change delegation for `delegator` to `delegatee`.

Emits events {DelegateChanged} and {DelegateVotesChanged}._

_moveVotingPower

_writeCheckpoint

_add

_subtract

ERC20VotesComp

_Extension of ERC20 to support Compound's voting and delegation. This version exactly matches Compound's interface, with the drawback of only supporting supply up to (2^96^ - 1).

NOTE: You should use this contract if you need exact compatibility with COMP (for example in order to use your token with Governor Alpha or Bravo) and if you are sure the supply cap of 2^96^ is enough for you. Otherwise, use the {ERC20Votes} variant of this module.

This extension keeps a history (checkpoints) of each account's vote power. Vote power can be delegated either by calling the {delegate} function directly, or by providing a signature to be used with {delegateBySig}. Voting power can be queried through the public accessors {getCurrentVotes} and {getPriorVotes}.

By default, token balance does not account for voting power. This makes transfers cheaper. The downside is that it requires users to delegate to themselves in order to activate checkpoints and have their voting power tracked. Enabling self-delegation can easily be done by overriding the {delegates} function. Keep in mind however that this will significantly increase the base gas cost of transfers.

Available since v4.2._

getCurrentVotes

Comp version of the {getVotes} accessor, with `uint96` return type.

getPriorVotes

Comp version of the {getPastVotes} accessor, with `uint96` return type.

_maxSupply

Maximum token supply. Reduced to `type(uint96).max` (2^96^ - 1) to fit COMP interface.

ERC20Wrapper

_Extension of the ERC20 token contract to support token wrapping.

Users can deposit and withdraw "underlying tokens" and receive a matching number of "wrapped tokens". This is useful in conjunction with other modules. For example, combining this wrapping mechanism with {ERC20Votes} will allow the wrapping of an existing "basic" ERC20 into a governance token.

Available since v4.2._

underlying

constructor

depositFor

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

withdrawTo

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

_recover

Mint wrapped token to cover any underlyingTokens that would have been transfered by mistake. Internal function that can be exposed with access control if desired.

IERC20Metadata

_Interface for the optional metadata functions from the ERC20 standard.

Available since v4.1._

name

Returns the name of the token.

symbol

Returns the symbol of the token.

decimals

Returns the decimals places of the token.

ERC20Permit

_Implementation of the ERC20 Permit extension allowing approvals to be made via signatures, as defined in https://eips.ethereum.org/EIPS/eip-2612[EIP-2612].

Adds the {permit} method, which can be used to change an account's ERC20 allowance (see {IERC20-allowance}) by presenting a message signed by the account. By not relying on `{IERC20-approve}`, the token holder account doesn't need to send a transaction, and thus is not required to hold Ether at all.

Available since v3.4._

_nonces

_PERMIT_TYPEHASH

constructor

_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 ERC20 token name._

permit

See {IERC20Permit-permit}.

nonces

See {IERC20Permit-nonces}.

DOMAIN_SEPARATOR

See {IERC20Permit-DOMAIN_SEPARATOR}.

_useNonce

_"Consume a nonce": return the current value and increment.

Available since v4.1._

IERC20Permit

_Interface of the ERC20 Permit extension allowing approvals to be made via signatures, as defined in https://eips.ethereum.org/EIPS/eip-2612[EIP-2612].

Adds the {permit} method, which can be used to change an account's ERC20 allowance (see {IERC20-allowance}) by presenting a message signed by the account. By not relying on {IERC20-approve}, the token holder account doesn't need to send a transaction, and thus is not required to hold Ether at all._

permit

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

IMPORTANT: The same issues {IERC20-approve} has related to transaction ordering also apply here.

Emits an {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 {nonces}).

For more information on the signature format, see the https://eips.ethereum.org/EIPS/eip-2612#specification[relevant EIP section]._

nonces

_Returns the current nonce for `owner`. This value must be included whenever a signature is generated for {permit}.

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

DOMAIN_SEPARATOR

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

ERC20PresetFixedSupply

_{ERC20} token, including:

  • Preminted initial supply

  • Ability for holders to burn (destroy) their tokens

  • No access control mechanism (for minting/pausing) and hence no governance

This contract uses {ERC20Burnable} to include burn capabilities - head to its documentation for details.

Available since v3.4._

constructor

_Mints `initialSupply` amount of token and transfers them to `owner`.

See {ERC20-constructor}._

ERC20PresetMinterPauser

_{ERC20} token, including:

  • ability for holders to burn (destroy) their tokens

  • a minter role that allows for token minting (creation)

  • a pauser role that allows to stop all token transfers

This contract uses {AccessControl} to lock permissioned functions using the different roles - head to its documentation for details.

The account that deploys the contract will be granted the minter and pauser roles, as well as the default admin role, which will let it grant both minter and pauser roles to other accounts._

MINTER_ROLE

PAUSER_ROLE

constructor

_Grants `DEFAULT_ADMIN_ROLE`, `MINTER_ROLE` and `PAUSER_ROLE` to the account that deploys the contract.

See {ERC20-constructor}._

mint

_Creates `amount` new tokens for `to`.

See {ERC20-_mint}.

Requirements:

  • the caller must have the `MINTER_ROLE`._

pause

_Pauses all token transfers.

See {ERC20Pausable} and {Pausable-_pause}.

Requirements:

  • the caller must have the `PAUSER_ROLE`._

unpause

_Unpauses all token transfers.

See {ERC20Pausable} and {Pausable-_unpause}.

Requirements:

  • the caller must have the `PAUSER_ROLE`._

_beforeTokenTransfer

SafeERC20

Wrappers around ERC20 operations that throw on failure (when the token contract returns false). Tokens that return no value (and instead revert or throw on failure) are also supported, non-reverting calls are assumed to be successful. To use this library you can add a `using SafeERC20 for IERC20;` statement to your contract, which allows you to call the safe operations as `token.safeTransfer(...)`, etc.

safeTransfer

safeTransferFrom

safeApprove

_Deprecated. This function has issues similar to the ones found in {IERC20-approve}, and its usage is discouraged.

Whenever possible, use {safeIncreaseAllowance} and {safeDecreaseAllowance} instead._

safeIncreaseAllowance

safeDecreaseAllowance

_callOptionalReturn

Imitates a Solidity high-level call (i.e. a regular function call to a contract), relaxing the requirement on the return value: the return value is optional (but if data is returned, it must not be false).

Name
Type
Description

token

contract IERC20

The token targeted by the call.

data

bytes

The call data (encoded using abi.encode or one of its variants).

TokenTimelock

_A token holder contract that will allow a beneficiary to extract the tokens after a given release time.

Useful for simple vesting schedules like "advisors get all of their tokens after 1 year"._

_token

_beneficiary

_releaseTime

constructor

token

Name
Type
Description

[0]

contract IERC20

the token being held.

beneficiary

Name
Type
Description

[0]

address

the beneficiary of the tokens.

releaseTime

Name
Type
Description

[0]

uint256

the time when the tokens are released.

release

Transfers tokens held by timelock to beneficiary.

ERC721

Implementation of https://eips.ethereum.org/EIPS/eip-721[ERC721] Non-Fungible Token Standard, including the Metadata extension, but not including the Enumerable extension, which is available separately as {ERC721Enumerable}.

_name

_symbol

_owners

_balances

_tokenApprovals

_operatorApprovals

constructor

Initializes the contract by setting a `name` and a `symbol` to the token collection.

supportsInterface

See {IERC165-supportsInterface}.

balanceOf

See {IERC721-balanceOf}.

ownerOf

See {IERC721-ownerOf}.

name

See {IERC721Metadata-name}.

symbol

See {IERC721Metadata-symbol}.

tokenURI

See {IERC721Metadata-tokenURI}.

_baseURI

Base URI for computing {tokenURI}. If set, the resulting URI for each token will be the concatenation of the `baseURI` and the `tokenId`. Empty by default, can be overriden in child contracts.

approve

See {IERC721-approve}.

getApproved

See {IERC721-getApproved}.

setApprovalForAll

See {IERC721-setApprovalForAll}.

isApprovedForAll

See {IERC721-isApprovedForAll}.

transferFrom

See {IERC721-transferFrom}.

safeTransferFrom

See {IERC721-safeTransferFrom}.

safeTransferFrom

See {IERC721-safeTransferFrom}.

_safeTransfer

_Safely transfers `tokenId` token from `from` to `to`, checking first that contract recipients are aware of the ERC721 protocol to prevent tokens from being forever locked.

`_data` is additional data, it has no specified format and it is sent in call to `to`.

This internal function is equivalent to {safeTransferFrom}, and can be used to e.g. implement alternative mechanisms to perform token transfer, such as signature-based.

Requirements:

  • `from` cannot be the zero address.

  • `to` cannot be the zero address.

  • `tokenId` token must exist and be owned by `from`.

  • If `to` refers to a smart contract, it must implement {IERC721Receiver-onERC721Received}, which is called upon a safe transfer.

Emits a {Transfer} event._

_exists

_Returns whether `tokenId` exists.

Tokens can be managed by their owner or approved accounts via {approve} or {setApprovalForAll}.

Tokens start existing when they are minted (`_mint`), and stop existing when they are burned (`burn`).

_isApprovedOrOwner

_Returns whether `spender` is allowed to manage `tokenId`.

Requirements:

  • `tokenId` must exist._

_safeMint

_Safely mints `tokenId` and transfers it to `to`.

Requirements:

  • `tokenId` must not exist.

  • If `to` refers to a smart contract, it must implement {IERC721Receiver-onERC721Received}, which is called upon a safe transfer.

Emits a {Transfer} event._

_safeMint

_Same as {xref-ERC721-_safeMint-address-uint256-}[`safeMint`], with an additional `data` parameter which is forwarded in {IERC721Receiver-onERC721Received} to contract recipients.

_mint

_Mints `tokenId` and transfers it to `to`.

WARNING: Usage of this method is discouraged, use {_safeMint} whenever possible

Requirements:

  • `tokenId` must not exist.

  • `to` cannot be the zero address.

Emits a {Transfer} event._

_burn

_Destroys `tokenId`. The approval is cleared when the token is burned.

Requirements:

  • `tokenId` must exist.

Emits a {Transfer} event._

_transfer

_Transfers `tokenId` from `from` to `to`. As opposed to {transferFrom}, this imposes no restrictions on msg.sender.

Requirements:

  • `to` cannot be the zero address.

  • `tokenId` token must be owned by `from`.

Emits a {Transfer} event._

_approve

_Approve `to` to operate on `tokenId`

Emits a {Approval} event._

_checkOnERC721Received

Internal function to invoke {IERC721Receiver-onERC721Received} on a target address. The call is not executed if the target address is not a contract.

Name
Type
Description

from

address

address representing the previous owner of the given token ID

to

address

target address that will receive the tokens

tokenId

uint256

uint256 ID of the token to be transferred

_data

bytes

bytes optional data to send along with the call

Name
Type
Description

[0]

bool

bool whether the call correctly returned the expected magic value

_beforeTokenTransfer

_Hook that is called before any token transfer. This includes minting and burning.

Calling conditions:

  • When `from` and `to` are both non-zero, ``from``'s `tokenId` will be transferred to `to`.

  • When `from` is zero, `tokenId` will be minted for `to`.

  • When `to` is zero, ``from``'s `tokenId` will be burned.

  • `from` and `to` are never both zero.

To learn more about hooks, head to xref:ROOT:extending-contracts.adoc#using-hooks[Using Hooks]._

IERC721

Required interface of an ERC721 compliant contract.

Transfer

Emitted when `tokenId` token is transferred from `from` to `to`.

Approval

Emitted when `owner` enables `approved` to manage the `tokenId` token.

ApprovalForAll

Emitted when `owner` enables or disables (`approved`) `operator` to manage all of its assets.

balanceOf

Returns the number of tokens in ``owner``'s account.

ownerOf

_Returns the owner of the `tokenId` token.

Requirements:

  • `tokenId` must exist._

safeTransferFrom

_Safely transfers `tokenId` token from `from` to `to`, checking first that contract recipients are aware of the ERC721 protocol to prevent tokens from being forever locked.

Requirements:

  • `from` cannot be the zero address.

  • `to` cannot be the zero address.

  • `tokenId` token must exist and be owned by `from`.

  • If the caller is not `from`, it must be have been allowed to move this token by either {approve} or {setApprovalForAll}.

  • If `to` refers to a smart contract, it must implement {IERC721Receiver-onERC721Received}, which is called upon a safe transfer.

Emits a {Transfer} event._

transferFrom

_Transfers `tokenId` token from `from` to `to`.

WARNING: Usage of this method is discouraged, use {safeTransferFrom} whenever possible.

Requirements:

  • `from` cannot be the zero address.

  • `to` cannot be the zero address.

  • `tokenId` token must be owned by `from`.

  • If the caller is not `from`, it must be approved to move this token by either {approve} or {setApprovalForAll}.

Emits a {Transfer} event._

approve

_Gives permission to `to` to transfer `tokenId` token to another account. The approval is cleared when the token is transferred.

Only a single account can be approved at a time, so approving the zero address clears previous approvals.

Requirements:

  • The caller must own the token or be an approved operator.

  • `tokenId` must exist.

Emits an {Approval} event._

getApproved

_Returns the account approved for `tokenId` token.

Requirements:

  • `tokenId` must exist._

setApprovalForAll

_Approve or remove `operator` as an operator for the caller. Operators can call {transferFrom} or {safeTransferFrom} for any token owned by the caller.

Requirements:

  • The `operator` cannot be the caller.

Emits an {ApprovalForAll} event._

isApprovedForAll

_Returns if the `operator` is allowed to manage all of the assets of `owner`.

See {setApprovalForAll}_

safeTransferFrom

_Safely transfers `tokenId` token from `from` to `to`.

Requirements:

  • `from` cannot be the zero address.

  • `to` cannot be the zero address.

  • `tokenId` token must exist and be owned by `from`.

  • If the caller is not `from`, it must be approved to move this token by either {approve} or {setApprovalForAll}.

  • If `to` refers to a smart contract, it must implement {IERC721Receiver-onERC721Received}, which is called upon a safe transfer.

Emits a {Transfer} event._

IERC721Receiver

Interface for any contract that wants to support safeTransfers from ERC721 asset contracts.

onERC721Received

_Whenever an {IERC721} `tokenId` token is transferred to this contract via {IERC721-safeTransferFrom} by `operator` from `from`, this function is called.

It must return its Solidity selector to confirm the token transfer. If any other value is returned or the interface is not implemented by the recipient, the transfer will be reverted.

The selector can be obtained in Solidity with `IERC721.onERC721Received.selector`._

ERC721Burnable

ERC721 Token that can be irreversibly burned (destroyed).

burn

_Burns `tokenId`. See {ERC721-_burn}.

Requirements:

  • The caller must own `tokenId` or be an approved operator._

ERC721Enumerable

This implements an optional extension of {ERC721} defined in the EIP that adds enumerability of all the token ids in the contract as well as all token ids owned by each account.

_ownedTokens

_ownedTokensIndex

_allTokens

_allTokensIndex

supportsInterface

See {IERC165-supportsInterface}.

tokenOfOwnerByIndex

See {IERC721Enumerable-tokenOfOwnerByIndex}.

totalSupply

See {IERC721Enumerable-totalSupply}.

tokenByIndex

See {IERC721Enumerable-tokenByIndex}.

_beforeTokenTransfer

_Hook that is called before any token transfer. This includes minting and burning.

Calling conditions:

  • When `from` and `to` are both non-zero, ``from``'s `tokenId` will be transferred to `to`.

  • When `from` is zero, `tokenId` will be minted for `to`.

  • When `to` is zero, ``from``'s `tokenId` will be burned.

  • `from` cannot be the zero address.

  • `to` cannot be the zero address.

To learn more about hooks, head to xref:ROOT:extending-contracts.adoc#using-hooks[Using Hooks]._

_addTokenToOwnerEnumeration

Private function to add a token to this extension's ownership-tracking data structures.

Name
Type
Description

to

address

address representing the new owner of the given token ID

tokenId

uint256

uint256 ID of the token to be added to the tokens list of the given address

_addTokenToAllTokensEnumeration

Private function to add a token to this extension's token tracking data structures.

Name
Type
Description

tokenId

uint256

uint256 ID of the token to be added to the tokens list

_removeTokenFromOwnerEnumeration

_Private function to remove a token from this extension's ownership-tracking data structures. Note that while the token is not assigned a new owner, the `_ownedTokensIndex` mapping is not updated: this allows for gas optimizations e.g. when performing a transfer operation (avoiding double writes). This has O(1) time complexity, but alters the order of the ownedTokens array.

Name
Type
Description

from

address

address representing the previous owner of the given token ID

tokenId

uint256

uint256 ID of the token to be removed from the tokens list of the given address

_removeTokenFromAllTokensEnumeration

_Private function to remove a token from this extension's token tracking data structures. This has O(1) time complexity, but alters the order of the allTokens array.

Name
Type
Description

tokenId

uint256

uint256 ID of the token to be removed from the tokens list

ERC721Pausable

_ERC721 token with pausable token transfers, minting and burning.

Useful for scenarios such as preventing trades until the end of an evaluation period, or having an emergency switch for freezing all token transfers in the event of a large bug._

_beforeTokenTransfer

_See {ERC721-_beforeTokenTransfer}.

Requirements:

  • the contract must not be paused._

ERC721URIStorage

ERC721 token with storage based token URI management.

_tokenURIs

tokenURI

See {IERC721Metadata-tokenURI}.

_setTokenURI

_Sets `_tokenURI` as the tokenURI of `tokenId`.

Requirements:

  • `tokenId` must exist._

_burn

_Destroys `tokenId`. The approval is cleared when the token is burned.

Requirements:

  • `tokenId` must exist.

Emits a {Transfer} event._

IERC721Enumerable

See https://eips.ethereum.org/EIPS/eip-721

totalSupply

Returns the total amount of tokens stored by the contract.

tokenOfOwnerByIndex

Returns a token ID owned by `owner` at a given `index` of its token list. Use along with {balanceOf} to enumerate all of ``owner``'s tokens.

tokenByIndex

Returns a token ID at a given `index` of all the tokens stored by the contract. Use along with {totalSupply} to enumerate all tokens.

IERC721Metadata

See https://eips.ethereum.org/EIPS/eip-721

name

Returns the token collection name.

symbol

Returns the token collection symbol.

tokenURI

Returns the Uniform Resource Identifier (URI) for `tokenId` token.

ERC721PresetMinterPauserAutoId

_{ERC721} token, including:

  • ability for holders to burn (destroy) their tokens

  • a minter role that allows for token minting (creation)

  • a pauser role that allows to stop all token transfers

  • token ID and URI autogeneration

This contract uses {AccessControl} to lock permissioned functions using the different roles - head to its documentation for details.

The account that deploys the contract will be granted the minter and pauser roles, as well as the default admin role, which will let it grant both minter and pauser roles to other accounts._

MINTER_ROLE

PAUSER_ROLE

_tokenIdTracker

_baseTokenURI

constructor

_Grants `DEFAULT_ADMIN_ROLE`, `MINTER_ROLE` and `PAUSER_ROLE` to the account that deploys the contract.

Token URIs will be autogenerated based on `baseURI` and their token IDs. See {ERC721-tokenURI}._

_baseURI

Base URI for computing {tokenURI}. If set, the resulting URI for each token will be the concatenation of the `baseURI` and the `tokenId`. Empty by default, can be overriden in child contracts.

mint

_Creates a new token for `to`. Its token ID will be automatically assigned (and available on the emitted {IERC721-Transfer} event), and the token URI autogenerated based on the base URI passed at construction.

See {ERC721-_mint}.

Requirements:

  • the caller must have the `MINTER_ROLE`._

pause

_Pauses all token transfers.

See {ERC721Pausable} and {Pausable-_pause}.

Requirements:

  • the caller must have the `PAUSER_ROLE`._

unpause

_Unpauses all token transfers.

See {ERC721Pausable} and {Pausable-_unpause}.

Requirements:

  • the caller must have the `PAUSER_ROLE`._

_beforeTokenTransfer

supportsInterface

See {IERC165-supportsInterface}.

ERC721Holder

_Implementation of the {IERC721Receiver} interface.

Accepts all token transfers. Make sure the contract is able to use its token with {IERC721-safeTransferFrom}, {IERC721-approve} or {IERC721-setApprovalForAll}._

onERC721Received

_See {IERC721Receiver-onERC721Received}.

Always returns `IERC721Receiver.onERC721Received.selector`._

ERC777

_Implementation of the {IERC777} interface.

This implementation is agnostic to the way tokens are created. This means that a supply mechanism has to be added in a derived contract using {_mint}.

Support for ERC20 is included in this contract, as specified by the EIP: both the ERC777 and ERC20 interfaces can be safely used when interacting with it. Both {IERC777-Sent} and {IERC20-Transfer} events are emitted on token movements.

Additionally, the {IERC777-granularity} value is hard-coded to `1`, meaning that there are no special restrictions in the amount of tokens that created, moved, or destroyed. This makes integration with ERC20 applications seamless._

_ERC1820_REGISTRY

_balances

_totalSupply

_name

_symbol

_TOKENS_SENDER_INTERFACE_HASH

_TOKENS_RECIPIENT_INTERFACE_HASH

_defaultOperatorsArray

_defaultOperators

_operators

_revokedDefaultOperators

_allowances

constructor

`defaultOperators` may be an empty array.

name

See {IERC777-name}.

symbol

See {IERC777-symbol}.

decimals

_See {ERC20-decimals}.

Always returns 18, as per the ERC777 EIP._

granularity

_See {IERC777-granularity}.

This implementation always returns `1`._

totalSupply

See {IERC777-totalSupply}.

balanceOf

Returns the amount of tokens owned by an account (`tokenHolder`).

send

_See {IERC777-send}.

Also emits a {IERC20-Transfer} event for ERC20 compatibility._

transfer

_See {IERC20-transfer}.

Unlike `send`, `recipient` is not required to implement the {IERC777Recipient} interface if it is a contract.

Also emits a {Sent} event._

burn

_See {IERC777-burn}.

Also emits a {IERC20-Transfer} event for ERC20 compatibility._

isOperatorFor

See {IERC777-isOperatorFor}.

authorizeOperator

See {IERC777-authorizeOperator}.

revokeOperator

See {IERC777-revokeOperator}.

defaultOperators

See {IERC777-defaultOperators}.

operatorSend

_See {IERC777-operatorSend}.

Emits {Sent} and {IERC20-Transfer} events._

operatorBurn

_See {IERC777-operatorBurn}.

Emits {Burned} and {IERC20-Transfer} events._

allowance

_See {IERC20-allowance}.

Note that operator and allowance concepts are orthogonal: operators may not have allowance, and accounts with allowance may not be operators themselves._

approve

_See {IERC20-approve}.

Note that accounts cannot have allowance issued by their operators._

transferFrom

_See {IERC20-transferFrom}.

Note that operator and allowance concepts are orthogonal: operators cannot call `transferFrom` (unless they have allowance), and accounts with allowance cannot call `operatorSend` (unless they are operators).

Emits {Sent}, {IERC20-Transfer} and {IERC20-Approval} events._

_mint

_Creates `amount` tokens and assigns them to `account`, increasing the total supply.

If a send hook is registered for `account`, the corresponding function will be called with `operator`, `data` and `operatorData`.

See {IERC777Sender} and {IERC777Recipient}.

Emits {Minted} and {IERC20-Transfer} events.

Requirements

  • `account` cannot be the zero address.

  • if `account` is a contract, it must implement the {IERC777Recipient} interface._

_mint

_Creates `amount` tokens and assigns them to `account`, increasing the total supply.

If `requireReceptionAck` is set to true, and if a send hook is registered for `account`, the corresponding function will be called with `operator`, `data` and `operatorData`.

See {IERC777Sender} and {IERC777Recipient}.

Emits {Minted} and {IERC20-Transfer} events.

Requirements

  • `account` cannot be the zero address.

  • if `account` is a contract, it must implement the {IERC777Recipient} interface._

_send

Send tokens

Name
Type
Description

from

address

address token holder address

to

address

address recipient address

amount

uint256

uint256 amount of tokens to transfer

userData

bytes

bytes extra information provided by the token holder (if any)

operatorData

bytes

bytes extra information provided by the operator (if any)

requireReceptionAck

bool

if true, contract recipients are required to implement ERC777TokensRecipient

_burn

Burn tokens

Name
Type
Description

from

address

address token holder address

amount

uint256

uint256 amount of tokens to burn

data

bytes

bytes extra information provided by the token holder

operatorData

bytes

bytes extra information provided by the operator (if any)

_move

_approve

_See {ERC20-_approve}.

Note that accounts cannot have allowance issued by their operators._

_callTokensToSend

Call from.tokensToSend() if the interface is registered

Name
Type
Description

operator

address

address operator requesting the transfer

from

address

address token holder address

to

address

address recipient address

amount

uint256

uint256 amount of tokens to transfer

userData

bytes

bytes extra information provided by the token holder (if any)

operatorData

bytes

bytes extra information provided by the operator (if any)

_callTokensReceived

Call to.tokensReceived() if the interface is registered. Reverts if the recipient is a contract but tokensReceived() was not registered for the recipient

Name
Type
Description

operator

address

address operator requesting the transfer

from

address

address token holder address

to

address

address recipient address

amount

uint256

uint256 amount of tokens to transfer

userData

bytes

bytes extra information provided by the token holder (if any)

operatorData

bytes

bytes extra information provided by the operator (if any)

requireReceptionAck

bool

if true, contract recipients are required to implement ERC777TokensRecipient

_beforeTokenTransfer

_Hook that is called before any token transfer. This includes calls to {send}, {transfer}, {operatorSend}, minting and burning.

Calling conditions:

  • when `from` and `to` are both non-zero, `amount` of ``from``'s tokens will be to transferred to `to`.

  • when `from` is zero, `amount` tokens will be minted for `to`.

  • when `to` is zero, `amount` of ``from``'s tokens will be burned.

  • `from` and `to` are never both zero.

To learn more about hooks, head to xref:ROOT:extending-contracts.adoc#using-hooks[Using Hooks]._

IERC777

_Interface of the ERC777Token standard as defined in the EIP.

This contract uses the https://eips.ethereum.org/EIPS/eip-1820[ERC1820 registry standard] to let token holders and recipients react to token movements by using setting implementers for the associated interfaces in said registry. See {IERC1820Registry} and {ERC1820Implementer}._

name

Returns the name of the token.

symbol

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

granularity

_Returns the smallest part of the token that is not divisible. This means all token operations (creation, movement and destruction) must have amounts that are a multiple of this number.

For most token contracts, this value will equal 1._

totalSupply

Returns the amount of tokens in existence.

balanceOf

Returns the amount of tokens owned by an account (`owner`).

send

_Moves `amount` tokens from the caller's account to `recipient`.

If send or receive hooks are registered for the caller and `recipient`, the corresponding functions will be called with `data` and empty `operatorData`. See {IERC777Sender} and {IERC777Recipient}.

Emits a {Sent} event.

Requirements

  • the caller must have at least `amount` tokens.

  • `recipient` cannot be the zero address.

  • if `recipient` is a contract, it must implement the {IERC777Recipient} interface._

burn

_Destroys `amount` tokens from the caller's account, reducing the total supply.

If a send hook is registered for the caller, the corresponding function will be called with `data` and empty `operatorData`. See {IERC777Sender}.

Emits a {Burned} event.

Requirements

  • the caller must have at least `amount` tokens._

isOperatorFor

_Returns true if an account is an operator of `tokenHolder`. Operators can send and burn tokens on behalf of their owners. All accounts are their own operator.

See {operatorSend} and {operatorBurn}._

authorizeOperator

_Make an account an operator of the caller.

See {isOperatorFor}.

Emits an {AuthorizedOperator} event.

Requirements

  • `operator` cannot be calling address._

revokeOperator

_Revoke an account's operator status for the caller.

See {isOperatorFor} and {defaultOperators}.

Emits a {RevokedOperator} event.

Requirements

  • `operator` cannot be calling address._

defaultOperators

_Returns the list of default operators. These accounts are operators for all token holders, even if {authorizeOperator} was never called on them.

This list is immutable, but individual holders may revoke these via {revokeOperator}, in which case {isOperatorFor} will return false._

operatorSend

_Moves `amount` tokens from `sender` to `recipient`. The caller must be an operator of `sender`.

If send or receive hooks are registered for `sender` and `recipient`, the corresponding functions will be called with `data` and `operatorData`. See {IERC777Sender} and {IERC777Recipient}.

Emits a {Sent} event.

Requirements

  • `sender` cannot be the zero address.

  • `sender` must have at least `amount` tokens.

  • the caller must be an operator for `sender`.

  • `recipient` cannot be the zero address.

  • if `recipient` is a contract, it must implement the {IERC777Recipient} interface._

operatorBurn

_Destroys `amount` tokens from `account`, reducing the total supply. The caller must be an operator of `account`.

If a send hook is registered for `account`, the corresponding function will be called with `data` and `operatorData`. See {IERC777Sender}.

Emits a {Burned} event.

Requirements

  • `account` cannot be the zero address.

  • `account` must have at least `amount` tokens.

  • the caller must be an operator for `account`._

Sent

Minted

Burned

AuthorizedOperator

RevokedOperator

IERC777Recipient

_Interface of the ERC777TokensRecipient standard as defined in the EIP.

Accounts can be notified of {IERC777} tokens being sent to them by having a contract implement this interface (contract holders can be their own implementer) and registering it on the https://eips.ethereum.org/EIPS/eip-1820[ERC1820 global registry].

See {IERC1820Registry} and {ERC1820Implementer}._

tokensReceived

_Called by an {IERC777} token contract whenever tokens are being moved or created into a registered account (`to`). The type of operation is conveyed by `from` being the zero address or not.

This call occurs after the token contract's state is updated, so {IERC777-balanceOf}, etc., can be used to query the post-operation state.

This function may revert to prevent the operation from being executed._

IERC777Sender

_Interface of the ERC777TokensSender standard as defined in the EIP.

{IERC777} Token holders can be notified of operations performed on their tokens by having a contract implement this interface (contract holders can be their own implementer) and registering it on the https://eips.ethereum.org/EIPS/eip-1820[ERC1820 global registry].

See {IERC1820Registry} and {ERC1820Implementer}._

tokensToSend

_Called by an {IERC777} token contract whenever a registered holder's (`from`) tokens are about to be moved or destroyed. The type of operation is conveyed by `to` being the zero address or not.

This call occurs before the token contract's state is updated, so {IERC777-balanceOf}, etc., can be used to query the pre-operation state.

This function may revert to prevent the operation from being executed._

ERC777PresetFixedSupply

_{ERC777} token, including:

  • Preminted initial supply

  • No access control mechanism (for minting/pausing) and hence no governance

Available since v3.4._

constructor

_Mints `initialSupply` amount of token and transfers them to `owner`.

See {ERC777-constructor}._

Address

Collection of functions related to the address type

isContract

_Returns true if `account` is a contract.

[IMPORTANT] ==== It is unsafe to assume that an address for which this function returns false is an externally-owned account (EOA) and not a contract.

Among others, `isContract` will return false for the following types of addresses:

  • an externally-owned account

  • a contract in construction

  • an address where a contract will be created

  • an address where a contract lived, but was destroyed ====_

sendValue

_Replacement for Solidity's `transfer`: sends `amount` wei to `recipient`, forwarding all available gas and reverting on errors.

https://eips.ethereum.org/EIPS/eip-1884[EIP1884] increases the gas cost of certain opcodes, possibly making contracts go over the 2300 gas limit imposed by `transfer`, making them unable to receive funds via `transfer`. {sendValue} removes this limitation.

https://diligence.consensys.net/posts/2019/09/stop-using-soliditys-transfer-now/[Learn more].

IMPORTANT: because control is transferred to `recipient`, care must be taken to not create reentrancy vulnerabilities. Consider using {ReentrancyGuard} or the https://solidity.readthedocs.io/en/v0.5.11/security-considerations.html#use-the-checks-effects-interactions-pattern[checks-effects-interactions pattern]._

functionCall

_Performs a Solidity function call using a low level `call`. A plain `call` is an unsafe replacement for a function call: use this function instead.

If `target` reverts with a revert reason, it is bubbled up by this function (like regular Solidity function calls).

Returns the raw returned data. To convert to the expected return value, use https://solidity.readthedocs.io/en/latest/units-and-global-variables.html?highlight=abi.decode#abi-encoding-and-decoding-functions[`abi.decode`].

Requirements:

  • `target` must be a contract.

  • calling `target` with `data` must not revert.

Available since v3.1._

functionCall

_Same as {xref-Address-functionCall-address-bytes-}[`functionCall`], but with `errorMessage` as a fallback revert reason when `target` reverts.

Available since v3.1._

functionCallWithValue

_Same as {xref-Address-functionCall-address-bytes-}[`functionCall`], but also transferring `value` wei to `target`.

Requirements:

  • the calling contract must have an ETH balance of at least `value`.

  • the called Solidity function must be `payable`.

Available since v3.1._

functionCallWithValue

_Same as {xref-Address-functionCallWithValue-address-bytes-uint256-}[`functionCallWithValue`], but with `errorMessage` as a fallback revert reason when `target` reverts.

Available since v3.1._

functionStaticCall

_Same as {xref-Address-functionCall-address-bytes-}[`functionCall`], but performing a static call.

Available since v3.3._

functionStaticCall

_Same as {xref-Address-functionCall-address-bytes-string-}[`functionCall`], but performing a static call.

Available since v3.3._

functionDelegateCall

_Same as {xref-Address-functionCall-address-bytes-}[`functionCall`], but performing a delegate call.

Available since v3.4._

functionDelegateCall

_Same as {xref-Address-functionCall-address-bytes-string-}[`functionCall`], but performing a delegate call.

Available since v3.4._

verifyCallResult

_Tool to verifies that a low level call was successful, and revert if it wasn't, either by bubbling the revert reason using the provided one.

Available since v4.3._

Arrays

Collection of functions related to array types.

findUpperBound

_Searches a sorted `array` and returns the first index that contains a value greater or equal to `element`. If no such index exists (i.e. all values in the array are strictly less than `element`), the array length is returned. Time complexity O(log n).

`array` is expected to be sorted in ascending order, and to contain no repeated elements._

Context

_Provides information about the current execution context, including the sender of the transaction and its data. While these are generally available via msg.sender and msg.data, they should not be accessed in such a direct manner, since when dealing with meta-transactions the account sending and paying for execution may not be the actual sender (as far as an application is concerned).

This contract is only required for intermediate, library-like contracts._

_msgSender

_msgData

Counters

_Provides counters that can only be incremented, decremented or reset. This can be used e.g. to track the number of elements in a mapping, issuing ERC721 ids, or counting request ids.

Include with `using Counters for Counters.Counter;`_

Counter

current

increment

decrement

reset

Multicall

_Provides a function to batch together multiple calls in a single external call.

Available since v4.1._

multicall

Receives and executes a batch of function calls on this contract.

StorageSlot

_Library for reading and writing primitive types to specific storage slots.

Storage slots are often used to avoid storage conflict when dealing with upgradeable contracts. This library helps with reading and writing to such slots without the need for inline assembly.

The functions in this library return Slot structs that contain a `value` member that can be used to read or write.

Example usage to set ERC1967 implementation slot: ``` contract ERC1967 { bytes32 internal constant _IMPLEMENTATION_SLOT = 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc;

} ```

Available since v4.1 for `address`, `bool`, `bytes32`, and `uint256`._

AddressSlot

BooleanSlot

Bytes32Slot

Uint256Slot

getAddressSlot

Returns an `AddressSlot` with member `value` located at `slot`.

getBooleanSlot

Returns an `BooleanSlot` with member `value` located at `slot`.

getBytes32Slot

Returns an `Bytes32Slot` with member `value` located at `slot`.

getUint256Slot

Returns an `Uint256Slot` with member `value` located at `slot`.

Strings

String operations.

_HEX_SYMBOLS

toString

Converts a `uint256` to its ASCII `string` decimal representation.

toHexString

Converts a `uint256` to its ASCII `string` hexadecimal representation.

toHexString

Converts a `uint256` to its ASCII `string` hexadecimal representation with fixed length.

Timers

Tooling for timepoints, timers and delays

Timestamp

getDeadline

setDeadline

reset

isUnset

isStarted

isPending

isExpired

BlockNumber

getDeadline

setDeadline

reset

isUnset

isStarted

isPending

isExpired

ECDSA

_Elliptic Curve Digital Signature Algorithm (ECDSA) operations.

These functions can be used to verify that a message was signed by the holder of the private keys of a given address._

RecoverError

_throwError

tryRecover

_Returns the address that signed a hashed message (`hash`) with `signature` or error string. This address can then be used for verification purposes.

The `ecrecover` EVM opcode allows for malleable (non-unique) signatures: this function rejects them by requiring the `s` value to be in the lower half order, and the `v` value to be either 27 or 28.

IMPORTANT: `hash` must be the result of a hash operation for the verification to be secure: it is possible to craft signatures that recover to arbitrary addresses for non-hashed data. A safe way to ensure this is by receiving a hash of the original message (which may otherwise be too long), and then calling {toEthSignedMessageHash} on it.

Documentation for signature generation:

  • with https://web3js.readthedocs.io/en/v1.3.4/web3-eth-accounts.html#sign[Web3.js]

  • with https://docs.ethers.io/v5/api/signer/#Signer-signMessage[ethers]

Available since v4.3._

recover

_Returns the address that signed a hashed message (`hash`) with `signature`. This address can then be used for verification purposes.

The `ecrecover` EVM opcode allows for malleable (non-unique) signatures: this function rejects them by requiring the `s` value to be in the lower half order, and the `v` value to be either 27 or 28.

IMPORTANT: `hash` must be the result of a hash operation for the verification to be secure: it is possible to craft signatures that recover to arbitrary addresses for non-hashed data. A safe way to ensure this is by receiving a hash of the original message (which may otherwise be too long), and then calling {toEthSignedMessageHash} on it._

tryRecover

_Overload of {ECDSA-tryRecover} that receives the `r` and `vs` short-signature fields separately.

See https://eips.ethereum.org/EIPS/eip-2098[EIP-2098 short signatures]

Available since v4.3._

recover

_Overload of {ECDSA-recover} that receives the `r and `vs` short-signature fields separately.

Available since v4.2._

tryRecover

_Overload of {ECDSA-tryRecover} that receives the `v`, `r` and `s` signature fields separately.

Available since v4.3._

recover

Overload of {ECDSA-recover} that receives the `v`, `r` and `s` signature fields separately. /

toEthSignedMessageHash

_Returns an Ethereum Signed Message, created from a `hash`. This produces hash corresponding to the one signed with the https://eth.wiki/json-rpc/API#eth_sign[`eth_sign`] JSON-RPC method as part of EIP-191.

See {recover}. /_

toTypedDataHash

_Returns an Ethereum Signed Typed Data, created from a `domainSeparator` and a `structHash`. This produces hash corresponding to the one signed with the https://eips.ethereum.org/EIPS/eip-712[`eth_signTypedData`] JSON-RPC method as part of EIP-712.

See {recover}. /_

SignatureChecker

_Signature verification helper: Provide a single mechanism to verify both private-key (EOA) ECDSA signature and ERC1271 contract sigantures. Using this instead of ECDSA.recover in your contract will make them compatible with smart contract wallets such as Argent and Gnosis.

Note: unlike ECDSA signatures, contract signature's are revocable, and the outcome of this function can thus change through time. It could return true at block N and false at block N+1 (or the opposite).

Available since v4.1._

isValidSignatureNow

EIP712

_https://eips.ethereum.org/EIPS/eip-712[EIP 712] is a standard for hashing and signing of typed structured data.

The encoding specified in the EIP is very generic, and such a generic implementation in Solidity is not feasible, thus this contract does not implement the encoding itself. Protocols need to implement the type-specific encoding they need in their contracts using a combination of `abi.encode` and `keccak256`.

This contract implements the EIP 712 domain separator ({_domainSeparatorV4}) that is used as part of the encoding scheme, and the final step of the encoding to obtain the message digest that is then signed via ECDSA ({_hashTypedDataV4}).

The implementation of the domain separator was designed to be as efficient as possible while still properly updating the chain id to protect against replay attacks on an eventual fork of the chain.

NOTE: This contract implements the version of the encoding known as "v4", as implemented by the JSON RPC method https://docs.metamask.io/guide/signing-data.html[`eth_signTypedDataV4` in MetaMask].

Available since v3.4._

_CACHED_DOMAIN_SEPARATOR

_CACHED_CHAIN_ID

_HASHED_NAME

_HASHED_VERSION

_TYPE_HASH

constructor

_Initializes the domain separator and parameter caches.

The meaning of `name` and `version` is specified in https://eips.ethereum.org/EIPS/eip-712#definition-of-domainseparator[EIP 712]:

  • `name`: the user readable name of the signing domain, i.e. the name of the DApp or the protocol.

  • `version`: the current major version of the signing domain.

NOTE: These parameters cannot be changed except through a xref:learn::upgrading-smart-contracts.adoc[smart contract upgrade]._

_domainSeparatorV4

Returns the domain separator for the current chain.

_buildDomainSeparator

_hashTypedDataV4

_Given an already https://eips.ethereum.org/EIPS/eip-712#definition-of-hashstruct[hashed struct], this function returns the hash of the fully encoded EIP712 message for this domain.

This hash can be used together with {ECDSA-recover} to obtain the signer of a message. For example:

```solidity bytes32 digest = hashTypedDataV4(keccak256(abi.encode( keccak256("Mail(address to,string contents)"), mailTo, keccak256(bytes(mailContents)) ))); address signer = ECDSA.recover(digest, signature); ```

ConditionalEscrow

Base abstract escrow to only allow withdrawal if a condition is met. Intended usage: See {Escrow}. Same usage guidelines apply here.

withdrawalAllowed

Returns whether an address is allowed to withdraw their funds. To be implemented by derived contracts.

Name
Type
Description

payee

address

The destination address of the funds.

withdraw

_Withdraw accumulated balance for a payee, forwarding all gas to the recipient.

WARNING: Forwarding all gas opens the door to reentrancy vulnerabilities. Make sure you trust the recipient, or are either following the checks-effects-interactions pattern or using {ReentrancyGuard}._

Name
Type
Description

payee

address payable

The address whose funds will be withdrawn and transferred to.

Escrow

_Base escrow contract, holds funds designated for a payee until they withdraw them.

Intended usage: This contract (and derived escrow contracts) should be a standalone contract, that only interacts with the contract that instantiated it. That way, it is guaranteed that all Ether will be handled according to the `Escrow` rules, and there is no need to check for payable functions or transfers in the inheritance tree. The contract that uses the escrow as its payment method should be its owner, and provide public methods redirecting to the escrow's deposit and withdraw._

Deposited

Withdrawn

_deposits

depositsOf

deposit

Stores the sent amount as credit to be withdrawn.

Name
Type
Description

payee

address

The destination address of the funds.

withdraw

_Withdraw accumulated balance for a payee, forwarding all gas to the recipient.

WARNING: Forwarding all gas opens the door to reentrancy vulnerabilities. Make sure you trust the recipient, or are either following the checks-effects-interactions pattern or using {ReentrancyGuard}._

Name
Type
Description

payee

address payable

The address whose funds will be withdrawn and transferred to.

RefundEscrow

Escrow that holds funds for a beneficiary, deposited from multiple parties. Intended usage: See {Escrow}. Same usage guidelines apply here. The owner account (that is, the contract that instantiates this contract) may deposit, close the deposit period, and allow for either withdrawal by the beneficiary, or refunds to the depositors. All interactions with `RefundEscrow` will be made through the owner contract.

State

RefundsClosed

RefundsEnabled

_state

_beneficiary

constructor

Constructor.

Name
Type
Description

beneficiary_

address payable

The beneficiary of the deposits.

state

Name
Type
Description

[0]

enum RefundEscrow.State

The current state of the escrow.

beneficiary

Name
Type
Description

[0]

address payable

The beneficiary of the escrow.

deposit

Stores funds that may later be refunded.

Name
Type
Description

refundee

address

The address funds will be sent to if a refund occurs.

close

Allows for the beneficiary to withdraw their funds, rejecting further deposits.

enableRefunds

Allows for refunds to take place, rejecting further deposits.

beneficiaryWithdraw

Withdraws the beneficiary's funds.

withdrawalAllowed

Returns whether refundees can withdraw their deposits (be refunded). The overridden function receives a 'payee' argument, but we ignore it here since the condition is global, not per-payee.

ERC165

_Implementation of the {IERC165} interface.

Contracts that want to implement ERC165 should inherit from this contract and override {supportsInterface} to check for the additional interface id that will be supported. For example:

```solidity function supportsInterface(bytes4 interfaceId) public view virtual override returns (bool) { return interfaceId == type(MyInterface).interfaceId || super.supportsInterface(interfaceId); } ```

Alternatively, {ERC165Storage} provides an easier to use but more expensive implementation._

supportsInterface

See {IERC165-supportsInterface}.

ERC165Checker

_Library used to query support of an interface declared via {IERC165}.

Note that these functions return the actual result of the query: they do not `revert` if an interface is not supported. It is up to the caller to decide what to do in these cases._

_INTERFACE_ID_INVALID

supportsERC165

Returns true if `account` supports the {IERC165} interface,

supportsInterface

_Returns true if `account` supports the interface defined by `interfaceId`. Support for {IERC165} itself is queried automatically.

See {IERC165-supportsInterface}._

getSupportedInterfaces

_Returns a boolean array where each value corresponds to the interfaces passed in and whether they're supported or not. This allows you to batch check interfaces for a contract where your expectation is that some interfaces may not be supported.

See {IERC165-supportsInterface}.

Available since v3.4._

supportsAllInterfaces

_Returns true if `account` supports all the interfaces defined in `interfaceIds`. Support for {IERC165} itself is queried automatically.

Batch-querying can lead to gas savings by skipping repeated checks for {IERC165} support.

See {IERC165-supportsInterface}._

_supportsERC165Interface

Query if a contract implements an interface, does not check ERC165 support

Assumes that account contains a contract that supports ERC165, otherwise the behavior of this method is undefined. This precondition can be checked with {supportsERC165}. Interface identification is specified in ERC-165.

Name
Type
Description

account

address

The address of the contract to query for support of an interface

interfaceId

bytes4

The interface identifier, as specified in ERC-165

Name
Type
Description

[0]

bool

true if the contract at account indicates support of the interface with identifier interfaceId, false otherwise

ERC165Storage

_Storage based implementation of the {IERC165} interface.

Contracts may inherit from this and call {registerInterface} to declare their support of an interface.

_supportedInterfaces

Mapping of interface ids to whether or not it's supported.

supportsInterface

See {IERC165-supportsInterface}.

_registerInterface

_Registers the contract as an implementer of the interface defined by `interfaceId`. Support of the actual ERC165 interface is automatic and registering its interface id is not required.

See {IERC165-supportsInterface}.

Requirements:

  • `interfaceId` cannot be the ERC165 invalid interface (`0xffffffff`)._

IERC165

_Interface of the ERC165 standard, as defined in the https://eips.ethereum.org/EIPS/eip-165[EIP].

Implementers can declare support of contract interfaces, which can then be queried by others ({ERC165Checker}).

For an implementation, see {ERC165}._

supportsInterface

_Returns true if this contract implements the interface defined by `interfaceId`. See the corresponding https://eips.ethereum.org/EIPS/eip-165#how-interfaces-are-identified[EIP section] to learn more about how these ids are created.

This function call must use less than 30 000 gas._

IERC1820Registry

_Interface of the global ERC1820 Registry, as defined in the https://eips.ethereum.org/EIPS/eip-1820[EIP]. Accounts may register implementers for interfaces in this registry, as well as query support.

Implementers may be shared by multiple accounts, and can also implement more than a single interface for each account. Contracts can implement interfaces for themselves, but externally-owned accounts (EOA) must delegate this to a contract.

{IERC165} interfaces can also be queried via the registry.

For an in-depth explanation and source code analysis, see the EIP text._

setManager

_Sets `newManager` as the manager for `account`. A manager of an account is able to set interface implementers for it.

By default, each account is its own manager. Passing a value of `0x0` in `newManager` will reset the manager to this initial state.

Emits a {ManagerChanged} event.

Requirements:

  • the caller must be the current manager for `account`._

getManager

_Returns the manager for `account`.

See {setManager}._

setInterfaceImplementer

_Sets the `implementer` contract as ``account``'s implementer for `interfaceHash`.

`account` being the zero address is an alias for the caller's address. The zero address can also be used in `implementer` to remove an old one.

See {interfaceHash} to learn how these are created.

Emits an {InterfaceImplementerSet} event.

Requirements:

  • the caller must be the current manager for `account`.

  • `interfaceHash` must not be an {IERC165} interface id (i.e. it must not end in 28 zeroes).

  • `implementer` must implement {IERC1820Implementer} and return true when queried for support, unless `implementer` is the caller. See {IERC1820Implementer-canImplementInterfaceForAddress}._

getInterfaceImplementer

_Returns the implementer of `interfaceHash` for `account`. If no such implementer is registered, returns the zero address.

If `interfaceHash` is an {IERC165} interface id (i.e. it ends with 28 zeroes), `account` will be queried for support of it.

`account` being the zero address is an alias for the caller's address._

interfaceHash

Returns the interface hash for an `interfaceName`, as defined in the corresponding https://eips.ethereum.org/EIPS/eip-1820#interface-name[section of the EIP].

updateERC165Cache

Updates the cache with whether the contract implements an ERC165 interface or not.

Name
Type
Description

account

address

Address of the contract for which to update the cache.

interfaceId

bytes4

ERC165 interface for which to update the cache.

implementsERC165Interface

Checks whether a contract implements an ERC165 interface or not. If the result is not cached a direct lookup on the contract address is performed. If the result is not cached or the cached value is out-of-date, the cache MUST be updated manually by calling {updateERC165Cache} with the contract address.

Name
Type
Description

account

address

Address of the contract to check.

interfaceId

bytes4

ERC165 interface to check.

Name
Type
Description

[0]

bool

True if `account` implements `interfaceId`, false otherwise.

implementsERC165InterfaceNoCache

Checks whether a contract implements an ERC165 interface or not without using nor updating the cache.

Name
Type
Description

account

address

Address of the contract to check.

interfaceId

bytes4

ERC165 interface to check.

Name
Type
Description

[0]

bool

True if `account` implements `interfaceId`, false otherwise.

InterfaceImplementerSet

ManagerChanged

Math

Standard math utilities missing in the Solidity language.

max

Returns the largest of two numbers.

min

Returns the smallest of two numbers.

average

Returns the average of two numbers. The result is rounded towards zero.

ceilDiv

_Returns the ceiling of the division of two numbers.

This differs from standard division with `/` in that it rounds up instead of rounding down._

SafeCast

_Wrappers over Solidity's uintXX/intXX casting operators with added overflow checks.

Downcasting from uint256/int256 in Solidity does not revert on overflow. This can easily result in undesired exploitation or bugs, since developers usually assume that overflows raise errors. `SafeCast` restores this intuition by reverting the transaction when such an operation overflows.

Using this library instead of the unchecked operations eliminates an entire class of bugs, so it's recommended to use it always.

Can be combined with {SafeMath} and {SignedSafeMath} to extend it to smaller types, by performing all math on `uint256` and `int256` and then downcasting._

toUint224

_Returns the downcasted uint224 from uint256, reverting on overflow (when the input is greater than largest uint224).

Counterpart to Solidity's `uint224` operator.

Requirements:

  • input must fit into 224 bits_

toUint128

_Returns the downcasted uint128 from uint256, reverting on overflow (when the input is greater than largest uint128).

Counterpart to Solidity's `uint128` operator.

Requirements:

  • input must fit into 128 bits_

toUint96

_Returns the downcasted uint96 from uint256, reverting on overflow (when the input is greater than largest uint96).

Counterpart to Solidity's `uint96` operator.

Requirements:

  • input must fit into 96 bits_

toUint64

_Returns the downcasted uint64 from uint256, reverting on overflow (when the input is greater than largest uint64).

Counterpart to Solidity's `uint64` operator.

Requirements:

  • input must fit into 64 bits_

toUint32

_Returns the downcasted uint32 from uint256, reverting on overflow (when the input is greater than largest uint32).

Counterpart to Solidity's `uint32` operator.

Requirements:

  • input must fit into 32 bits_

toUint16

_Returns the downcasted uint16 from uint256, reverting on overflow (when the input is greater than largest uint16).

Counterpart to Solidity's `uint16` operator.

Requirements:

  • input must fit into 16 bits_

toUint8

_Returns the downcasted uint8 from uint256, reverting on overflow (when the input is greater than largest uint8).

Counterpart to Solidity's `uint8` operator.

Requirements:

  • input must fit into 8 bits._

toUint256

_Converts a signed int256 into an unsigned uint256.

Requirements:

  • input must be greater than or equal to 0._

toInt128

_Returns the downcasted int128 from int256, reverting on overflow (when the input is less than smallest int128 or greater than largest int128).

Counterpart to Solidity's `int128` operator.

Requirements:

  • input must fit into 128 bits

Available since v3.1._

toInt64

_Returns the downcasted int64 from int256, reverting on overflow (when the input is less than smallest int64 or greater than largest int64).

Counterpart to Solidity's `int64` operator.

Requirements:

  • input must fit into 64 bits

Available since v3.1._

toInt32

_Returns the downcasted int32 from int256, reverting on overflow (when the input is less than smallest int32 or greater than largest int32).

Counterpart to Solidity's `int32` operator.

Requirements:

  • input must fit into 32 bits

Available since v3.1._

toInt16

_Returns the downcasted int16 from int256, reverting on overflow (when the input is less than smallest int16 or greater than largest int16).

Counterpart to Solidity's `int16` operator.

Requirements:

  • input must fit into 16 bits

Available since v3.1._

toInt8

_Returns the downcasted int8 from int256, reverting on overflow (when the input is less than smallest int8 or greater than largest int8).

Counterpart to Solidity's `int8` operator.

Requirements:

  • input must fit into 8 bits.

Available since v3.1._

toInt256

_Converts an unsigned uint256 into a signed int256.

Requirements:

  • input must be less than or equal to maxInt256._

SafeMath

_Wrappers over Solidity's arithmetic operations.

NOTE: `SafeMath` is no longer needed starting with Solidity 0.8. The compiler now has built in overflow checking._

tryAdd

_Returns the addition of two unsigned integers, with an overflow flag.

Available since v3.4._

trySub

_Returns the substraction of two unsigned integers, with an overflow flag.

Available since v3.4._

tryMul

_Returns the multiplication of two unsigned integers, with an overflow flag.

Available since v3.4._

tryDiv

_Returns the division of two unsigned integers, with a division by zero flag.

Available since v3.4._

tryMod

_Returns the remainder of dividing two unsigned integers, with a division by zero flag.

Available since v3.4._

add

_Returns the addition of two unsigned integers, reverting on overflow.

Counterpart to Solidity's `+` operator.

Requirements:

  • Addition cannot overflow._

sub

_Returns the subtraction of two unsigned integers, reverting on overflow (when the result is negative).

Counterpart to Solidity's `-` operator.

Requirements:

  • Subtraction cannot overflow._

mul

_Returns the multiplication of two unsigned integers, reverting on overflow.

Counterpart to Solidity's `*` operator.

Requirements:

  • Multiplication cannot overflow._

div

_Returns the integer division of two unsigned integers, reverting on division by zero. The result is rounded towards zero.

Counterpart to Solidity's `/` operator.

Requirements:

  • The divisor cannot be zero._

mod

_Returns the remainder of dividing two unsigned integers. (unsigned integer modulo), reverting when dividing by zero.

Counterpart to Solidity's `%` operator. This function uses a `revert` opcode (which leaves remaining gas untouched) while Solidity uses an invalid opcode to revert (consuming all remaining gas).

Requirements:

  • The divisor cannot be zero._

sub

_Returns the subtraction of two unsigned integers, reverting with custom message on overflow (when the result is negative).

CAUTION: This function is deprecated because it requires allocating memory for the error message unnecessarily. For custom revert reasons use {trySub}.

Counterpart to Solidity's `-` operator.

Requirements:

  • Subtraction cannot overflow._

div

_Returns the integer division of two unsigned integers, reverting with custom message on division by zero. The result is rounded towards zero.

Counterpart to Solidity's `/` operator. Note: this function uses a `revert` opcode (which leaves remaining gas untouched) while Solidity uses an invalid opcode to revert (consuming all remaining gas).

Requirements:

  • The divisor cannot be zero._

mod

_Returns the remainder of dividing two unsigned integers. (unsigned integer modulo), reverting with custom message when dividing by zero.

CAUTION: This function is deprecated because it requires allocating memory for the error message unnecessarily. For custom revert reasons use {tryMod}.

Counterpart to Solidity's `%` operator. This function uses a `revert` opcode (which leaves remaining gas untouched) while Solidity uses an invalid opcode to revert (consuming all remaining gas).

Requirements:

  • The divisor cannot be zero._

EnumerableMap

_Library for managing an enumerable variant of Solidity's https://solidity.readthedocs.io/en/latest/types.html#mapping-types[`mapping`] type.

Maps have the following properties:

  • Entries are added, removed, and checked for existence in constant time (O(1)).

  • Entries are enumerated in O(n). No guarantees are made on the ordering.

``` contract Example { // Add the library methods using EnumerableMap for EnumerableMap.UintToAddressMap;

} ```

As of v3.0.0, only maps of type `uint256 -> address` (`UintToAddressMap`) are supported._

Map

_set

_Adds a key-value pair to a map, or updates the value for an existing key. O(1).

Returns true if the key was added to the map, that is if it was not already present._

_remove

_Removes a key-value pair from a map. O(1).

Returns true if the key was removed from the map, that is if it was present._

_contains

Returns true if the key is in the map. O(1).

_length

Returns the number of key-value pairs in the map. O(1).

_at

_Returns the key-value pair stored at position `index` in the map. O(1).

Note that there are no guarantees on the ordering of entries inside the array, and it may change when more entries are added or removed.

Requirements:

  • `index` must be strictly less than {length}._

_tryGet

Tries to returns the value associated with `key`. O(1). Does not revert if `key` is not in the map.

_get

_Returns the value associated with `key`. O(1).

Requirements:

  • `key` must be in the map._

_get

_Same as {_get}, with a custom error message when `key` is not in the map.

CAUTION: This function is deprecated because it requires allocating memory for the error message unnecessarily. For custom revert reasons use {tryGet}.

UintToAddressMap

set

_Adds a key-value pair to a map, or updates the value for an existing key. O(1).

Returns true if the key was added to the map, that is if it was not already present._

remove

_Removes a value from a set. O(1).

Returns true if the key was removed from the map, that is if it was present._

contains

Returns true if the key is in the map. O(1).

length

Returns the number of elements in the map. O(1).

at

_Returns the element stored at position `index` in the set. O(1). Note that there are no guarantees on the ordering of values inside the array, and it may change when more values are added or removed.

Requirements:

  • `index` must be strictly less than {length}._

tryGet

_Tries to returns the value associated with `key`. O(1). Does not revert if `key` is not in the map.

Available since v3.4._

get

_Returns the value associated with `key`. O(1).

Requirements:

  • `key` must be in the map._

get

_Same as {get}, with a custom error message when `key` is not in the map.

CAUTION: This function is deprecated because it requires allocating memory for the error message unnecessarily. For custom revert reasons use {tryGet}._

EnumerableSet

Library for managing https://en.wikipedia.org/wiki/Set(abstract_data_type)[sets] of primitive types.

Sets have the following properties:

  • Elements are added, removed, and checked for existence in constant time (O(1)).

  • Elements are enumerated in O(n). No guarantees are made on the ordering.

``` contract Example { // Add the library methods using EnumerableSet for EnumerableSet.AddressSet;

} ```

As of v3.3.0, sets of type `bytes32` (`Bytes32Set`), `address` (`AddressSet`) and `uint256` (`UintSet`) are supported._

Set

_add

_Add a value to a set. O(1).

Returns true if the value was added to the set, that is if it was not already present._

_remove

_Removes a value from a set. O(1).

Returns true if the value was removed from the set, that is if it was present._

_contains

Returns true if the value is in the set. O(1).

_length

Returns the number of values on the set. O(1).

_at

_Returns the value stored at position `index` in the set. O(1).

Note that there are no guarantees on the ordering of values inside the array, and it may change when more values are added or removed.

Requirements:

  • `index` must be strictly less than {length}._

_values

_Return the entire set in an array

WARNING: This operation will copy the entire storage to memory, which can be quite expensive. This is designed to mostly be used by view accessors that are queried without any gas fees. Developers should keep in mind that this function has an unbounded cost, and using it as part of a state-changing function may render the function uncallable if the set grows to a point where copying to memory consumes too much gas to fit in a block._

Bytes32Set

add

_Add a value to a set. O(1).

Returns true if the value was added to the set, that is if it was not already present._

remove

_Removes a value from a set. O(1).

Returns true if the value was removed from the set, that is if it was present._

contains

Returns true if the value is in the set. O(1).

length

Returns the number of values in the set. O(1).

at

_Returns the value stored at position `index` in the set. O(1).

Note that there are no guarantees on the ordering of values inside the array, and it may change when more values are added or removed.

Requirements:

  • `index` must be strictly less than {length}._

values

_Return the entire set in an array

WARNING: This operation will copy the entire storage to memory, which can be quite expensive. This is designed to mostly be used by view accessors that are queried without any gas fees. Developers should keep in mind that this function has an unbounded cost, and using it as part of a state-changing function may render the function uncallable if the set grows to a point where copying to memory consumes too much gas to fit in a block._

AddressSet

add

_Add a value to a set. O(1).

Returns true if the value was added to the set, that is if it was not already present._

remove

_Removes a value from a set. O(1).

Returns true if the value was removed from the set, that is if it was present._

contains

Returns true if the value is in the set. O(1).

length

Returns the number of values in the set. O(1).

at

_Returns the value stored at position `index` in the set. O(1).

Note that there are no guarantees on the ordering of values inside the array, and it may change when more values are added or removed.

Requirements:

  • `index` must be strictly less than {length}._

values

_Return the entire set in an array

WARNING: This operation will copy the entire storage to memory, which can be quite expensive. This is designed to mostly be used by view accessors that are queried without any gas fees. Developers should keep in mind that this function has an unbounded cost, and using it as part of a state-changing function may render the function uncallable if the set grows to a point where copying to memory consumes too much gas to fit in a block._

UintSet

add

_Add a value to a set. O(1).

Returns true if the value was added to the set, that is if it was not already present._

remove

_Removes a value from a set. O(1).

Returns true if the value was removed from the set, that is if it was present._

contains

Returns true if the value is in the set. O(1).

length

Returns the number of values on the set. O(1).

at

_Returns the value stored at position `index` in the set. O(1).

Note that there are no guarantees on the ordering of values inside the array, and it may change when more values are added or removed.

Requirements:

  • `index` must be strictly less than {length}._

values

_Return the entire set in an array

WARNING: This operation will copy the entire storage to memory, which can be quite expensive. This is designed to mostly be used by view accessors that are queried without any gas fees. Developers should keep in mind that this function has an unbounded cost, and using it as part of a state-changing function may render the function uncallable if the set grows to a point where copying to memory consumes too much gas to fit in a block._

PriceProviderAggregator

MODERATOR_ROLE

usdDecimals

tokenPriceProvider

PriceProviderInfo

GrandModeratorRole

RevokeModeratorRole

SetTokenAndPriceProvider

ChangeActive

initialize

onlyAdmin

onlyModerator

grandModerator

revokeModerator

setTokenAndPriceProvider

sets price provider to `token`

Name
Type
Description

token

address

the address of token

priceProvider

address

the address of price provider. Should implememnt the interface of `PriceProvider`

hasFunctionWithSign

bool

true - if price provider has function with signatures false - if price provider does not have function with signatures

changeActive

getPrice

price = priceMantissa / (10 ** priceDecimals)

returns tuple (priceMantissa, priceDecimals)

Name
Type
Description

token

address

the address of token wich price is to return

getPriceSigned

returns the tupple (priceMantissa, priceDecimals) of token multiplied by 10 ** priceDecimals given by price provider. price can be calculated as priceMantissa / (10 ** priceDecimals) i.e. price = priceMantissa / (10 ** priceDecimals)

Name
Type
Description

token

address

the address of token

priceMantissa

uint256

- the price of token (used in verifying the signature)

validTo

uint256

- the timestamp in seconds (used in verifying the signature)

signature

bytes

- the backend signature of secp256k1. length is 65 bytes

getEvaluation

returns the USD evaluation of token by its `tokenAmount`

Name
Type
Description

token

address

the address of token to evaluate

tokenAmount

uint256

the amount of token to evaluate

getEvaluationSigned

returns the USD evaluation of token by its `tokenAmount`

Name
Type
Description

token

address

the address of token

tokenAmount

uint256

the amount of token including decimals

priceMantissa

uint256

- the price of token (used in verifying the signature)

validTo

uint256

- the timestamp in seconds (used in verifying the signature)

signature

bytes

- the backend signature of secp256k1. length is 65 bytes

BackendPriceProvider

Backend price verifier.

TRUSTED_BACKEND_ROLE

DESCRIPTION

usdDecimals

backendMetadata

BackendMetadata

GrandTrustedBackendRole

RevokeTrustedBackendRole

SetToken

ChangeActive

initialize

onlyAdmin

onlyTrustedBackend

grandTrustedBackendRole

revokeTrustedBackendRole

setToken

changeActive

getMessageHash

  1. step. Backend creates offchain data and get hash of this data. This data calls message.

returns the keccak256 of concatenated input data

Name
Type
Description

token

address

the address of asset

priceMantissa

uint256

the price of asset that include decimals

validTo

uint256

the unix timestamp in seconds that define the validity of given price to `validTo` timestamp

getEthSignedMessageHash

  1. step. Backend formatting the message and get hash of this message.

returns the keccak256 of formatted message

Name
Type
Description

messageHash

bytes32

the keccak256 of message

verify

  1. step. Smart contract verify the message (tuple)

returns true if the message is signed by trusted backend. Else returns false.

Name
Type
Description

token

address

the address of asset

priceMantissa

uint256

the price of asset that include decimals

validTo

uint256

the unix timestamp in seconds that define the validity of given price to `validTo` timestamp

signature

bytes

the sign of message.

recoverSigner

returns the signer of `ethSignedMessageHash`

isListed

isActive

getPrice

Returns the latest asset price and price decimals

Name
Type
Description

token

address

the token address

getPriceSigned

getEvaluation

getEvaluationSigned

return the evaluation in $ of `tokenAmount` with signed price

Name
Type
Description

token

address

the address of token to get evaluation in $

tokenAmount

uint256

the amount of token to get evaluation. Amount is scaled by 10 in power token decimals

priceMantissa

uint256

the price multiplied by priceDecimals. The dimension of priceMantissa should be $/token

validTo

uint256

the timestamp in seconds, when price is gonna be not valid.

signature

bytes

the ECDSA sign on eliptic curve secp256k1.

getPriceDecimals

ChainlinkPriceProvider

Chainlink price provider

MODERATOR_ROLE

DESCRIPTION

usdDecimals

chainlinkMetadata

ChainlinkMetadata

GrandModeratorRole

RevokeModeratorRole

SetTokenAndAggregator

ChangeActive

initialize

onlyAdmin

onlyModerator

grandModerator

revokeModerator

setTokenAndAggregator

changeActive

isListed

isActive

getPrice

Returns the latest asset price mantissa and price decimals [price] = USD/token

First step is get priceMantissa with priceDecimals by this formula: price = 1 * 10 ** tokenDecimals * (chainlinkPrice_1 / 10 ** priceDecimals_1) * ... * (chainlinkPrice_n / 10 ** priceDecimals_n) = = 10 ** tokenDecimals (chainlinkPrice_1 * ... * chainlinkPrice_n) / 10 ** (priceDecimals_1 + ... + priceDecimals_n) Second step is scale priceMantissa to usdDecimals

Name
Type
Description

token

address

the token address

getEvaluation

returns the equivalent amount in USD

Name
Type
Description

token

address

the address of token

tokenAmount

uint256

the amount of token

getPriceDecimals

PriceProvider

changeActive

isActive

isListed

getPrice

getPriceSigned

getEvaluation

getEvaluationSigned

return the evaluation in $ of `tokenAmount` with signed price

Name
Type
Description

token

address

the address of token to get evaluation in $

tokenAmount

uint256

the amount of token to get evaluation. Amount is scaled by 10 in power token decimals

priceMantissa

uint256

the price multiplied by priceDecimals. The dimension of priceMantissa should be $/token

validTo

uint256

the timestamp in seconds, when price is gonna be not valid.

signature

bytes

the ECDSA sign on eliptic curve secp256k1.

getPriceDecimals

UniswapV2PriceProvider

UniswapV2 price provider This implementation can be affected by price manipulation due to not using TWAP For development purposes only

MODERATOR_ROLE

DESCRIPTION

usdDecimals

uniswapV2Metadata

UniswapV2Metadata

GrandModeratorRole

RevokeModeratorRole

SetTokenAndPair

ChangeActive

initialize

onlyAdmin

onlyModerator

grandModerator

revokeModerator

setTokenAndPair

changeActive

isListed

isActive

getPrice

getEvaluation

getReserves

getPriceDecimals

AggregatorV3Interface

decimals

description

version

getRoundData

latestRoundData

latestAnswer

IUniswapV2Pair

Approval

Transfer

name

symbol

decimals

totalSupply

balanceOf

allowance

approve

transfer

transferFrom

DOMAIN_SEPARATOR

PERMIT_TYPEHASH

nonces

permit

Mint

Burn

Swap

Sync

MINIMUM_LIQUIDITY

factory

token0

token1

getReserves

price0CumulativeLast

price1CumulativeLast

kLast

mint

burn

swap

skim

sync

initialize

SafeMath

_Wrappers over Solidity's arithmetic operations.

NOTE: `SafeMath` is generally not needed starting with Solidity 0.8, since the compiler now has built in overflow checking._

tryAdd

_Returns the addition of two unsigned integers, with an overflow flag.

Available since v3.4._

trySub

_Returns the substraction of two unsigned integers, with an overflow flag.

Available since v3.4._

tryMul

_Returns the multiplication of two unsigned integers, with an overflow flag.

Available since v3.4._

tryDiv

_Returns the division of two unsigned integers, with a division by zero flag.

Available since v3.4._

tryMod

_Returns the remainder of dividing two unsigned integers, with a division by zero flag.

Available since v3.4._

add

_Returns the addition of two unsigned integers, reverting on overflow.

Counterpart to Solidity's `+` operator.

Requirements:

  • Addition cannot overflow._

sub

_Returns the subtraction of two unsigned integers, reverting on overflow (when the result is negative).

Counterpart to Solidity's `-` operator.

Requirements:

  • Subtraction cannot overflow._

mul

_Returns the multiplication of two unsigned integers, reverting on overflow.

Counterpart to Solidity's `*` operator.

Requirements:

  • Multiplication cannot overflow._

div

_Returns the integer division of two unsigned integers, reverting on division by zero. The result is rounded towards zero.

Counterpart to Solidity's `/` operator.

Requirements:

  • The divisor cannot be zero._

mod

_Returns the remainder of dividing two unsigned integers. (unsigned integer modulo), reverting when dividing by zero.

Counterpart to Solidity's `%` operator. This function uses a `revert` opcode (which leaves remaining gas untouched) while Solidity uses an invalid opcode to revert (consuming all remaining gas).

Requirements:

  • The divisor cannot be zero._

sub

_Returns the subtraction of two unsigned integers, reverting with custom message on overflow (when the result is negative).

CAUTION: This function is deprecated because it requires allocating memory for the error message unnecessarily. For custom revert reasons use {trySub}.

Counterpart to Solidity's `-` operator.

Requirements:

  • Subtraction cannot overflow._

div

_Returns the integer division of two unsigned integers, reverting with custom message on division by zero. The result is rounded towards zero.

Counterpart to Solidity's `/` operator. Note: this function uses a `revert` opcode (which leaves remaining gas untouched) while Solidity uses an invalid opcode to revert (consuming all remaining gas).

Requirements:

  • The divisor cannot be zero._

mod

_Returns the remainder of dividing two unsigned integers. (unsigned integer modulo), reverting with custom message when dividing by zero.

CAUTION: This function is deprecated because it requires allocating memory for the error message unnecessarily. For custom revert reasons use {tryMod}.

Counterpart to Solidity's `%` operator. This function uses a `revert` opcode (which leaves remaining gas untouched) while Solidity uses an invalid opcode to revert (consuming all remaining gas).

Requirements:

  • The divisor cannot be zero._

UniswapV2Library

sortTokens

pairFor

getReserves

quote

getAmountOut

getAmountIn

getAmountsOut

getAmountsIn

CarefulMath

Derived from OpenZeppelin's SafeMath library https://github.com/OpenZeppelin/openzeppelin-solidity/blob/master/contracts/math/SafeMath.sol

MathError

mulUInt

Multiplies two numbers, returns an error on overflow.

divUInt

Integer division of two numbers, truncating the quotient.

subUInt

Subtracts two numbers, returns an error on overflow (i.e. if subtrahend is greater than minuend).

addUInt

Adds two numbers, returns an error on overflow.

addThenSubUInt

add a and b and then subtract c

BondtrollerErrorReporter

Error

FailureInfo

Failure

`error` corresponds to enum Error; `info` corresponds to enum FailureInfo, and `detail` is an arbitrary contract-specific code that enables us to report opaque error codes from upgradeable contracts.

fail

use this when reporting a known error from the money market or a non-upgradeable collaborator

failOpaque

use this when reporting an opaque error from an upgradeable collaborator contract

TokenErrorReporter

Error

FailureInfo

Failure

`error` corresponds to enum Error; `info` corresponds to enum FailureInfo, and `detail` is an arbitrary contract-specific code that enables us to report opaque error codes from upgradeable contracts.

fail

use this when reporting a known error from the money market or a non-upgradeable collaborator

failOpaque

use this when reporting an opaque error from an upgradeable collaborator contract

Exponential

Exp is a struct which stores decimals with a fixed precision of 18 decimal places. Thus, if we wanted to store the 5.1, mantissa would store 5.1e18. That is: `Exp({mantissa: 5100000000000000000})`.

Legacy contract for compatibility reasons with existing contracts that still use MathError

getExp

Creates an exponential from numerator and denominator values. Note: Returns an error if (`num` * 10e18) > MAX_INT, or if `denom` is zero.

addExp

Adds two exponentials, returning a new exponential.

subExp

Subtracts two exponentials, returning a new exponential.

mulScalar

Multiply an Exp by a scalar, returning a new Exp.

mulScalarTruncate

Multiply an Exp by a scalar, then truncate to return an unsigned integer.

mulScalarTruncateAddUInt

Multiply an Exp by a scalar, truncate, then add an to an unsigned integer, returning an unsigned integer.

divScalar

Divide an Exp by a scalar, returning a new Exp.

divScalarByExp

Divide a scalar by an Exp, returning a new Exp.

divScalarByExpTruncate

Divide a scalar by an Exp, then truncate to return an unsigned integer.

mulExp

Multiplies two exponentials, returning a new exponential.

mulExp

Multiplies two exponentials given their mantissas, returning a new exponential.

mulExp3

Multiplies three exponentials, returning a new exponential.

divExp

Divides two exponentials, returning a new exponential. (a/scale) / (b/scale) = (a/scale) * (scale/b) = a/b, which we can scale as an Exp by calling getExp(a.mantissa, b.mantissa)

ExponentialNoError

Exp is a struct which stores decimals with a fixed precision of 18 decimal places. Thus, if we wanted to store the 5.1, mantissa would store 5.1e18. That is: `Exp({mantissa: 5100000000000000000})`.

expScale

doubleScale

halfExpScale

mantissaOne

Exp

Double

truncate

Truncates the given exp to a whole number value. For example, truncate(Exp{mantissa: 15 * expScale}) = 15

mul_ScalarTruncate

Multiply an Exp by a scalar, then truncate to return an unsigned integer.

mul_ScalarTruncateAddUInt

Multiply an Exp by a scalar, truncate, then add an to an unsigned integer, returning an unsigned integer.

lessThanExp

Checks if first Exp is less than second Exp.

lessThanOrEqualExp

Checks if left Exp <= right Exp.

greaterThanExp

Checks if left Exp > right Exp.

isZeroExp

returns true if Exp is exactly zero

safe224

safe32

add_

add_

add_

add_

sub_

sub_

sub_

sub_

mul_

mul_

mul_

mul_

mul_

mul_

mul_

mul_

div_

div_

div_

div_

div_

div_

div_

div_

fraction

console

CONSOLE_ADDRESS

_sendLogPayload

log

logInt

logUint

logString

logBool

logAddress

logBytes

logBytes1

logBytes2

logBytes3

logBytes4

logBytes5

logBytes6

logBytes7

logBytes8

logBytes9

logBytes10

logBytes11

logBytes12

logBytes13

logBytes14

logBytes15

logBytes16

logBytes17

logBytes18

logBytes19

logBytes20

logBytes21

logBytes22

logBytes23

logBytes24

logBytes25

logBytes26

logBytes27

logBytes28

logBytes29

logBytes30

logBytes31

logBytes32

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

log

IPRJ

name

Returns the name of the token.

symbol

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

decimals

_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 value {ERC20} uses, unless this function is 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}._

totalSupply

Returns the amount of tokens in existence.

balanceOf

Returns the amount of tokens owned by `account`.

transfer

_Moves `amount` tokens from the caller's account to `recipient`.

Returns a boolean value indicating whether the operation succeeded.

Emits a {Transfer} event._

allowance

_Returns the remaining number of tokens that `spender` will be allowed to spend on behalf of `owner` through {transferFrom}. This is zero by default.

This value changes when {approve} or {transferFrom} are called._

approve

_Sets `amount` as the allowance of `spender` over the caller's tokens.

Returns a boolean value indicating whether the operation succeeded.

IMPORTANT: Beware that changing an allowance with this method brings the risk 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 {Approval} event._

transferFrom

_Moves `amount` tokens from `sender` to `recipient` using the allowance mechanism. `amount` is then deducted from the caller's allowance.

Returns a boolean value indicating whether the operation succeeded.

Emits a {Transfer} event._

mint

mints Project tokens to msg.sender

Name
Type
Description

amount

uint256

- the amount of project tokens to mint

mintTo

mints Project tokens to `to`

Name
Type
Description

to

address

- address of user that receive the Project Token

amount

uint256

- the amount of project tokens to mint

IUSDCTest

name

Returns the name of the token.

symbol

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

decimals

_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 value {ERC20} uses, unless this function is 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}._

totalSupply

Returns the amount of tokens in existence.

balanceOf

Returns the amount of tokens owned by `account`.

transfer

_Moves `amount` tokens from the caller's account to `recipient`.

Returns a boolean value indicating whether the operation succeeded.

Emits a {Transfer} event._

allowance

_Returns the remaining number of tokens that `spender` will be allowed to spend on behalf of `owner` through {transferFrom}. This is zero by default.

This value changes when {approve} or {transferFrom} are called._

approve

_Sets `amount` as the allowance of `spender` over the caller's tokens.

Returns a boolean value indicating whether the operation succeeded.

IMPORTANT: Beware that changing an allowance with this method brings the risk 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 {Approval} event._

transferFrom

_Moves `amount` tokens from `sender` to `recipient` using the allowance mechanism. `amount` is then deducted from the caller's allowance.

Returns a boolean value indicating whether the operation succeeded.

Emits a {Transfer} event._

mint

mints Project tokens to msg.sender

Name
Type
Description

amount

uint256

- the amount of project tokens to mint

mintTo

mints Project tokens to `to`

Name
Type
Description

to

address

- address of user that receive the Project Token

amount

uint256

- the amount of project tokens to mint

SignedSafeMathUpgradeable

_Wrappers over Solidity's arithmetic operations.

NOTE: `SignedSafeMath` is no longer needed starting with Solidity 0.8. The compiler now has built in overflow checking._

mul

_Returns the multiplication of two signed integers, reverting on overflow.

Counterpart to Solidity's `*` operator.

Requirements:

  • Multiplication cannot overflow._

div

_Returns the integer division of two signed integers. Reverts on division by zero. The result is rounded towards zero.

Counterpart to Solidity's `/` operator.

Requirements:

  • The divisor cannot be zero._

sub

_Returns the subtraction of two signed integers, reverting on overflow.

Counterpart to Solidity's `-` operator.

Requirements:

  • Subtraction cannot overflow._

add

_Returns the addition of two signed integers, reverting on overflow.

Counterpart to Solidity's `+` operator.

Requirements:

  • Addition cannot overflow._

IBLendingToken

mintTo

Sender supplies assets into the market and receives cTokens in exchange

Accrues interest whether or not the operation succeeds, unless reverted

Name
Type
Description

minter

address

the address of account which earn liquidity

mintAmount

uint256

The amount of the underlying asset to supply to minter return uint 0=success, otherwise a failure (see ErrorReporter.sol for details) return uint minted amount

redeemTo

Sender redeems cTokens in exchange for the underlying asset

Accrues interest whether or not the operation succeeds, unless reverted

Name
Type
Description

redeemer

address

redeemTokens

uint256

The number of cTokens to redeem into underlying

Name
Type
Description

[0]

uint256

uint 0=success, otherwise a failure (see ErrorReporter.sol for details)

redeemUnderlyingTo

Sender redeems cTokens in exchange for a specified amount of underlying asset

Accrues interest whether or not the operation succeeds, unless reverted

Name
Type
Description

redeemer

address

redeemAmount

uint256

The amount of underlying to redeem

Name
Type
Description

[0]

uint256

uint 0=success, otherwise a failure (see ErrorReporter.sol for details)

borrowTo

repayBorrowTo

repayBorrowToBorrower

balanceOf

Get the token balance of the `owner`

Name
Type
Description

owner

address

The address of the account to query

Name
Type
Description

[0]

uint256

The number of tokens owned by `owner`

borrowBalanceCurrent

borrowBalanceStored

totalSupply

totalBorrows

exchangeRateStored

IPrimaryIndexToken

MODERATOR_ROLE

return keccak("MODERATOR_ROLE")

priceOracle

return address of price oracle with interface of PriceProviderAggregator

projectTokens

return address project token in array `projectTokens`

Name
Type
Description

projectTokenId

uint256

- index of project token in array `projectTokens`. Numetates from 0 to array length - 1

projectTokenInfo

return info of project token, that declared in struct ProjectTokenInfo

Name
Type
Description

projectToken

address

- address of project token in array `projectTokens`. Numetates from 0 to array length - 1

lendingTokens

return address lending token in array `lendingTokens`

Name
Type
Description

lendingTokenId

uint256

- index of lending token in array `lendingTokens`. Numetates from 0 to array length - 1

lendingTokenInfo

return info of lending token, that declared in struct LendingTokenInfo

Name
Type
Description

lendingToken

address

- address of project token in array `projectTokens`. Numetates from 0 to array length - 1

totalDepositedProjectToken

depositPosition

borrowPosition

totalBorrow

borrowLimit

Ratio

ProjectTokenInfo

LendingTokenInfo

DepositPosition

BorrowPosition

AddPrjToken

LoanToValueRatioSet

LiquidationThresholdFactorSet

Deposit

Withdraw

Supply

Redeem

RedeemUnderlying

Borrow

RepayBorrow

Liquidate

initialize

addProjectToken

removeProjectToken

addLendingToken

removeLendingToken

setPriceOracle

grandModerator

revokeModerator

setBorrowLimit

setProjectTokenInfo

setPausedProjectToken

setLendingTokenInfo

setPausedLendingToken

deposit

withdraw

supply

redeem

redeemUnderlying

borrow

repay

liquidate

updateInterestInBorrowPosition

pit

pitRemaining

liquidationThreshold

totalOutstanding

healthFactor

getProjectTokenEvaluation

lendingTokensLength

projectTokensLength

getPosition

decimals

IBPrimaryIndexToken

mintTo

Sender supplies assets into the market and receives cTokens in exchange

Accrues interest whether or not the operation succeeds, unless reverted

Name
Type
Description

minter

address

the address of account which earn liquidity

mintAmount

uint256

The amount of the underlying asset to supply to minter return uint 0=success, otherwise a failure (see ErrorReporter.sol for details) return uint minted amount

redeemTo

Sender redeems cTokens in exchange for the underlying asset

Accrues interest whether or not the operation succeeds, unless reverted

Name
Type
Description

redeemer

address

redeemTokens

uint256

The number of cTokens to redeem into underlying

Name
Type
Description

[0]

uint256

uint 0=success, otherwise a failure (see ErrorReporter.sol for details)

redeemUnderlyingTo

Sender redeems cTokens in exchange for a specified amount of underlying asset

Accrues interest whether or not the operation succeeds, unless reverted

Name
Type
Description

redeemAmount

uint256

The amount of underlying to redeem

Name
Type
Description

[0]

uint256

uint 0=success, otherwise a failure (see ErrorReporter.sol for details)

balanceOf

Get the token balance of the `owner`

Name
Type
Description

owner

address

The address of the account to query

Name
Type
Description

[0]

uint256

The number of tokens owned by `owner`

IUniswapV2Router02

factory

WETH

addLiquidity

addLiquidityETH

removeLiquidity

removeLiquidityETH

removeLiquidityWithPermit

removeLiquidityETHWithPermit

swapExactTokensForTokens

swapTokensForExactTokens

swapExactETHForTokens

swapTokensForExactETH

swapExactTokensForETH

swapETHForExactTokens

quote

getAmountOut

getAmountIn

getAmountsOut

getAmountsIn

removeLiquidityETHSupportingFeeOnTransferTokens

removeLiquidityETHWithPermitSupportingFeeOnTransferTokens

swapExactTokensForTokensSupportingFeeOnTransferTokens

swapExactETHForTokensSupportingFeeOnTransferTokens

swapExactTokensForETHSupportingFeeOnTransferTokens

BitMaps

Library for managing uint256 to bool mapping in a compact and efficient way, providing the keys are sequential. Largelly inspired by Uniswap's https://github.com/Uniswap/merkle-distributor/blob/master/contracts/MerkleDistributor.sol[merkle-distributor].

BitMap

get

Returns whether the bit at `index` is set.

setTo

Sets the bit at `index` to the boolean `value`.

set

Sets the bit at `index`.

unset

Unsets the bit at `index`.

SignedSafeMath

_Wrappers over Solidity's arithmetic operations.

NOTE: `SignedSafeMath` is no longer needed starting with Solidity 0.8. The compiler now has built in overflow checking._

mul

_Returns the multiplication of two signed integers, reverting on overflow.

Counterpart to Solidity's `*` operator.

Requirements:

  • Multiplication cannot overflow._

div

_Returns the integer division of two signed integers. Reverts on division by zero. The result is rounded towards zero.

Counterpart to Solidity's `/` operator.

Requirements:

  • The divisor cannot be zero._

sub

_Returns the subtraction of two signed integers, reverting on overflow.

Counterpart to Solidity's `-` operator.

Requirements:

  • Subtraction cannot overflow._

add

_Returns the addition of two signed integers, reverting on overflow.

Counterpart to Solidity's `+` operator.

Requirements:

  • Addition cannot overflow._

Create2Upgradeable

_Helper to make usage of the `CREATE2` EVM opcode easier and safer. `CREATE2` can be used to compute in advance the address where a smart contract will be deployed, which allows for interesting new mechanisms known as 'counterfactual interactions'.

See the https://eips.ethereum.org/EIPS/eip-1014#motivation[EIP] for more information._

deploy

_Deploys a contract using `CREATE2`. The address where the contract will be deployed can be known in advance via {computeAddress}.

The bytecode for a contract can be obtained from Solidity with `type(contractName).creationCode`.

Requirements:

  • `bytecode` must not be empty.

  • `salt` must have not been used for `bytecode` already.

  • the factory must have a balance of at least `amount`.

  • if `amount` is non-zero, `bytecode` must have a `payable` constructor._

computeAddress

Returns the address where a contract will be stored if deployed via {deploy}. Any change in the `bytecodeHash` or `salt` will result in a new destination address.

computeAddress

Returns the address where a contract will be stored if deployed via {deploy} from a contract located at `deployer`. If `deployer` is this contract's address, returns the same value as {computeAddress}.

Clones

_https://eips.ethereum.org/EIPS/eip-1167[EIP 1167] is a standard for deploying minimal proxy contracts, also known as "clones".

> To simply and cheaply clone contract functionality in an immutable way, this standard specifies > a minimal bytecode implementation that delegates all calls to a known, fixed address.

The library includes functions to deploy a proxy using either `create` (traditional deployment) or `create2` (salted deterministic deployment). It also includes functions to predict the addresses of clones deployed using the deterministic method.

Available since v3.4._

clone

_Deploys and returns the address of a clone that mimics the behaviour of `implementation`.

This function uses the create opcode, which should never revert._

cloneDeterministic

_Deploys and returns the address of a clone that mimics the behaviour of `implementation`.

This function uses the create2 opcode and a `salt` to deterministically deploy the clone. Using the same `implementation` and `salt` multiple time will revert, since the clones cannot be deployed twice at the same address._

predictDeterministicAddress

Computes the address of a clone deployed using {Clones-cloneDeterministic}.

predictDeterministicAddress

Computes the address of a clone deployed using {Clones-cloneDeterministic}.

IERC1363ReceiverUpgradeable

onTransferReceived

Handle the receipt of ERC1363 tokens

Any ERC1363 smart contract calls this function on the recipient after a `transfer` or a `transferFrom`. This function MAY throw to revert and reject the transfer. Return of other than the magic value MUST result in the transaction being reverted. Note: the token contract address is always the message sender.

Name
Type
Description

operator

address

address The address which called `transferAndCall` or `transferFromAndCall` function

from

address

address The address which are token transferred from

value

uint256

uint256 The amount of tokens transferred

data

bytes

bytes Additional data with no specified format

Name
Type
Description

[0]

bytes4

`bytes4(keccak256("onTransferReceived(address,address,uint256,bytes)"))` unless throwing

IComptroller

isComptroller

Indicator that this is a Comptroller contract (for inspection)

getAssetsIn

getAccountLiquidity

checkMembership

getPrimaryIndexTokenAddress

enterMarkets

enterMarket

exitMarket

mintAllowed

mintVerify

redeemAllowed

redeemVerify

borrowAllowed

borrowVerify

repayBorrowAllowed

repayBorrowVerify

liquidateBorrowAllowed

liquidateBorrowVerify

seizeAllowed

seizeVerify

transferAllowed

transferVerify

liquidateCalculateSeizeTokens

IERC1363SpenderUpgradeable

onApprovalReceived

Handle the approval of ERC1363 tokens

Any ERC1363 smart contract calls this function on the recipient after an `approve`. This function MAY throw to revert and reject the approval. Return of other than the magic value MUST result in the transaction being reverted. Note: the token contract address is always the message sender.

Name
Type
Description

owner

address

address The address which called `approveAndCall` function

value

uint256

uint256 The amount of tokens to be spent

data

bytes

bytes Additional data with no specified format

Name
Type
Description

[0]

bytes4

`bytes4(keccak256("onApprovalReceived(address,uint256,bytes)"))` unless throwing

ISimplePriceOracle

PricePosted

getUnderlyingPrice

setUnderlyingPrice

setDirectPrice

assetPrices

IERC1363Receiver

onTransferReceived

Handle the receipt of ERC1363 tokens

Any ERC1363 smart contract calls this function on the recipient after a `transfer` or a `transferFrom`. This function MAY throw to revert and reject the transfer. Return of other than the magic value MUST result in the transaction being reverted. Note: the token contract address is always the message sender.

Name
Type
Description

operator

address

address The address which called `transferAndCall` or `transferFromAndCall` function

from

address

address The address which are token transferred from

value

uint256

uint256 The amount of tokens transferred

data

bytes

bytes Additional data with no specified format

Name
Type
Description

[0]

bytes4

`bytes4(keccak256("onTransferReceived(address,address,uint256,bytes)"))` unless throwing

BitMapsUpgradeable

Library for managing uint256 to bool mapping in a compact and efficient way, providing the keys are sequential. Largelly inspired by Uniswap's https://github.com/Uniswap/merkle-distributor/blob/master/contracts/MerkleDistributor.sol[merkle-distributor].

BitMap

get

Returns whether the bit at `index` is set.

setTo

Sets the bit at `index` to the boolean `value`.

set

Sets the bit at `index`.

unset

Unsets the bit at `index`.

ERC1820Implementer

_Implementation of the {IERC1820Implementer} interface.

Contracts may inherit from this and call {registerInterfaceForAddress} to declare their willingness to be implementers. {IERC1820Registry-setInterfaceImplementer} should then be called for the registration to be complete.

_ERC1820_ACCEPT_MAGIC

_supportedInterfaces

canImplementInterfaceForAddress

See {IERC1820Implementer-canImplementInterfaceForAddress}.

_registerInterfaceForAddress

_Declares the contract as willing to be an implementer of `interfaceHash` for `account`.

See {IERC1820Registry-setInterfaceImplementer} and {IERC1820Registry-interfaceHash}._

IERC1820Implementer

Interface for an ERC1820 implementer, as defined in the https://eips.ethereum.org/EIPS/eip-1820#interface-implementation-erc1820implementerinterface[EIP]. Used by contracts that will be registered as implementers in the {IERC1820Registry}.

canImplementInterfaceForAddress

_Returns a special value (`ERC1820_ACCEPT_MAGIC`) if this contract implements `interfaceHash` for `account`.

See {IERC1820Registry-setInterfaceImplementer}._

Last updated