Request form
Contracts
Protocols
Discord
SuperFluid
Streaming
Payments
Protocol
Audited
Info
Docs
Source
ChefGPT

Welcome to superfluid protocol-monorepo 👋

npm GitHub package.json version (subfolder of monorepo) npm npm npm GitHub package.json version (subfolder of monorepo)
Twitter: Superfluid_HQ

Contracts and resources for the Superfluid Protocol

🏠 Homepage

✨ Superfluid App

📖 Docs

The Superfluid Protocol is a framework that realizes the real-time finance vision where user accounts are connected together, and transactions can happen between user accounts instantaneously as a result.

This repository implements the superfluid protocol as Ethereum contracts. It also contains a Javascript SDK for developing Web3 applications using the superfluid protocol.

For technical document, references and tutorials, etc, refer to the docs site.

Packages

@superfluid-finance/ethereum-contracts

Version License: AGPLv3

EVM contracts implementation for the Superfluid Protocol.

If you're interest in peeking under the hood, then check out the contracts package.

@superfluid-finance/metadata

Version License: MIT

Contract addresses, subgraph URLs, and other metadata for the Superfluid Protocol.

@superfluid-finance/sdk-core

Version License: MIT

SDK-Core is an application framework for interacting with the Superfluid Protocol without Solidity knowledge.

@superfluid-finance/sdk-redux

Version License: MIT

SDK-Redux is an application framework for building front-end applications that interact with the Superfluid Protocol.

@superfluid-finance/hot-fuzz

License: AGPLv3

Hot-fuzz is a wrapper of Echidna with additional helper for fuzzing your Superfluid smart contracts applications, including Super Apps.

@superfluid-finance/subgraph

License: AGPLv3

Official subgraph for the Superfluid Protocol.

@superfluid-finance/js-sdk

Version License: MIT

:warning: This package is fully deprecated, use sdk-core instead :warning:

You can get the last release of js-sdk at the branch here.

Javascript SDK for building with Superfluid Protocol.

Bug Bounty

Click here for more information regarding our Bug Bounty.

Examples

See our examples repo for some Superfluid app examples.

Contributing

Contributions, issues, and feature suggestions are welcome! See CONTRIBUTING.md to get started.

Contributors ✨

Thanks goes to these wonderful people (🐸):

Joshua Trujillo
Joshua Trujillo

💻
Manav Darji
Manav Darji

💻
Drew Fisher
Drew Fisher

💻
Didi
Didi

💻
Omidiora Samuel
Omidiora Samuel

💻
Prafful
Prafful

💻
mjaago
mjaago

💻
markcarey
markcarey

💻
Bertrand Juglas
Bertrand Juglas

👀
Shreyas Papinwar
Shreyas Papinwar

💻

This project follows the all-contributors specification. Contributions of any kind welcome!

Programmable Cashflows. Handle subscriptions, salaries, rewards and any composable stream of value, with continuous settlement and per-second netting for extreme capital efficiency.

AgreementLibrary :
Helper library for building super agreement
ConstantFlowAgreementV1 :
Please read IConstantFlowAgreementV1 for implementation notes.For more technical notes, please visit protocol-monorepo wiki area. Storage Layout Notes Agreement State NOTE The Agreement State slot is computed with the following function: keccak256(abi.encode("AgreementState", msg.sender, account, slotId)) slotId = 0 msg.sender = address of CFAv1 account = context.msgSender Flow Agreement State stores the global FlowData state for an account. Agreement Data NOTE The Agreement Data slot is calculated with the following function: keccak256(abi.encode("AgreementData", agreementClass, agreementId)) agreementClass = address of CFAv1 agreementId = FlowId | FlowOperatorId FlowId = keccak256(abi.encode(flowSender, flowReceiver)) FlowId stores FlowData between a flowSender and flowReceiver. FlowOperatorId = keccak256(abi.encode("flowOperator", flowSender, flowOperator)) FlowOperatorId stores FlowOperatorData between a flowSender and flowOperator.
agreementType() :
ISuperAgreement.agreementType implementation
authorizeFlowOperatorWithFullControl(address,address,bytes) :
IConstantFlowAgreementV1.authorizeFlowOperatorWithFullControl implementation
createFlow(address,address,int96,bytes) :
IConstantFlowAgreementV1.createFlow implementation
createFlowByOperator(address,address,address,int96,bytes) :
IConstantFlowAgreementV1.createFlowByOperator implementation
decreaseFlowRateAllowance(address,address,int96,bytes) :
IConstantFlowAgreementV1.decreaseFlowRateAllowance implementation
deleteFlow(address,address,address,bytes) :
IConstantFlowAgreementV1.deleteFlow implementation
deleteFlowByOperator(address,address,address,bytes) :
IConstantFlowAgreementV1.deleteFlowByOperator implementation
getAccountFlowInfo(address,address) :
IConstantFlowAgreementV1.getAccountFlowInfo implementation
getCodeAddress() :
Get current implementation code address.
getDepositRequiredForFlowRate(address,int96) :
IConstantFlowAgreementV1.getDepositRequiredForFlowRate implementation
getFlow(address,address,address) :
IConstantFlowAgreementV1.getFlow implementation
getFlowByID(address,bytes32) :
IConstantFlowAgreementV1.getFlow implementation
getFlowOperatorData(address,address,address) :
IConstantFlowAgreementV1.getFlowOperatorData implementation
getFlowOperatorDataByID(address,bytes32) :
IConstantFlowAgreementV1.getFlowOperatorDataByID implementation
getMaximumFlowRateFromDeposit(address,uint256) :
IConstantFlowAgreementV1.getMaximumFlowRateFromDeposit implementation
getNetFlow(address,address) :
IConstantFlowAgreementV1.getNetFlow implementation
increaseFlowRateAllowance(address,address,int96,bytes) :
IConstantFlowAgreementV1.increaseFlowRateAllowance implementation
isPatricianPeriod(address,address,uint256) :
Returns whether it is the patrician period based on timestamp
isPatricianPeriodNow(address,address) :
Returns whether it is the patrician period based on host.getNow()
proxiableUUID() :
Proxiable UUID marker function, this would help to avoid wrong logic contract to be used for upgrading. NOTE: The semantics of the UUID deviates from the actual UUPS standard, where it is equivalent of _IMPLEMENTATION_SLOT.
realtimeBalanceOf(address,address,uint256) :
ISuperAgreement.realtimeBalanceOf implementation
revokeFlowOperatorWithFullControl(address,address,bytes) :
IConstantFlowAgreementV1.revokeFlowOperatorWithFullControl implementation
updateFlow(address,address,int96,bytes) :
IConstantFlowAgreementV1.updateFlow implementation
updateFlowByOperator(address,address,address,int96,bytes) :
IConstantFlowAgreementV1.updateFlowByOperator implementation
updateFlowOperatorPermissions(address,address,uint8,int96,bytes) :
IConstantFlowAgreementV1.updateFlowOperatorPermissions implementation
InstantDistributionAgreementV1 :
Please read IInstantDistributionAgreementV1 for implementation notes.For more technical notes, please visit protocol-monorepo wiki area. Storage Layout Notes Agreement State NOTE The Agreement State slot is computed with the following function: keccak256(abi.encode("AgreementState", msg.sender, account, slotId)) Publisher Deposit State Slot slotId = _PUBLISHER_DEPOSIT_STATE_SLOT_ID or 1 << 32 or 4294967296 msg.sender = address of IDAv1 account = context.msgSender Publisher Deposit State stores deposit state for a publisher, this is the pending value. Subscriber Subscription Data Slot Id Start slotId = _SUBSCRIBER_SUB_DATA_STATE_SLOT_ID_START or 1 << 128 or 340282366920938463463374607431768211456 msg.sender = address of IDAv1 account = context.msgSender Subscriber Subscription Data Slot Id Start indicates the starting slot for where we begin to store the indexes a subscriber is a part of. Slots Bitmap Data Slot slotId = _SUBSCRIBER_SUBS_BITMAP_STATE_SLOT_ID or 0 msg.sender = address of IDAv1 account = context.msgSender Slots Bitmap Data Slot stores the bitmap of the slots that are "enabled" for a subscriber. This is used as an optimization to only get the data (index id's) for the slots that are "enabled". Agreement Data NOTE The Agreement Data slot is calculated with the following function: keccak256(abi.encode("AgreementData", agreementClass, agreementId)) agreementClass = address of IDAv1 agreementId = PublisherId | SubscriptionId PublisherId = keccak256(abi.encode("publisher", publisher, indexId)) publisher = "owner" of the index indexId = arbitrary value for allowing multiple indexes by the same token-publisher pair PublisherId stores IndexData for an Index. SubscriptionId = keccak256(abi.encode("subscriber", subscriber, iId)) iId = PublisherId, the index this particular subscriber is subscribed to SubscriptionId stores SubscriptionData for a subscriber to an Index.
agreementType() :
ISuperAgreement.agreementType implementation
approveSubscription(address,address,uint32,bytes) :
IInstantDistributionAgreementV1.approveSubscription implementation
calculateDistribution(address,address,uint32,uint256) :
IInstantDistributionAgreementV1.calculateDistribution implementation
claim(address,address,uint32,address,bytes) :
Claim pending distributions
createIndex(address,uint32,bytes) :
IInstantDistributionAgreementV1.createIndex implementation
deleteSubscription(address,address,uint32,address,bytes) :
IInstantDistributionAgreementV1.deleteSubscription implementation
distribute(address,uint32,uint256,bytes) :
IInstantDistributionAgreementV1.distribute implementation
getCodeAddress() :
Get current implementation code address.
getIndex(address,address,uint32) :
IInstantDistributionAgreementV1.getIndex implementation
getSubscription(address,address,uint32,address) :
IInstantDistributionAgreementV1.getSubscription implementation
getSubscriptionByID(address,bytes32) :
IInstantDistributionAgreementV1.getSubscriptionByID implementation
listSubscriptions(address,address) :
IInstantDistributionAgreementV1.listSubscriptions implementation
proxiableUUID() :
Proxiable UUID marker function, this would help to avoid wrong logic contract to be used for upgrading. NOTE: The semantics of the UUID deviates from the actual UUPS standard, where it is equivalent of _IMPLEMENTATION_SLOT.
realtimeBalanceOf(address,address,uint256) :
ISuperAgreement.realtimeBalanceOf implementation
revokeSubscription(address,address,uint32,bytes) :
IInstantDistributionAgreementV1.revokeSubscription implementation
updateIndex(address,uint32,uint128,bytes) :
IInstantDistributionAgreementV1.updateIndex implementation
updateSubscription(address,uint32,address,uint128,bytes) :
IInstantDistributionAgreementV1.updateSubscription implementation
CFAv1Library :
for working with the constant flow agreement within soliditythe first set of functions are each for callAgreement()the second set of functions are each for use in callAgreementWithContext()
IDAv1Library :
Set a variable of type `InitData` in the contract, then call this library's functions directly `initData.functionName()`.
SuperTokenV1Library :
Set `using for ISuperToken` in including file, and call any of these functions on an instance of ISuperToken. Note that it is important to "warm up" the cache and cache the host, cfa, ida before calling, this is only applicable to Foundry tests where the vm.expectRevert() will not work as expected.
ISuperApp :
Be aware of the app being jailed, when the word permitted is used.
afterAgreementCreated(address,address,bytes32,bytes,bytes,bytes) :
Callback after a new agreement is created.
afterAgreementTerminated(address,address,bytes32,bytes,bytes,bytes) :
Callback after a new agreement is terminated.
afterAgreementUpdated(address,address,bytes32,bytes,bytes,bytes) :
Callback after a new agreement is updated.
beforeAgreementCreated(address,address,bytes32,bytes,bytes) :
Callback before a new agreement is created.
beforeAgreementTerminated(address,address,bytes32,bytes,bytes) :
Callback before a new agreement is terminated.
beforeAgreementUpdated(address,address,bytes32,bytes,bytes) :
Callback before a new agreement is updated.
ERC20WithTokenInfo :
Using abstract contract instead of interfaces because old solidity does not support interface inheriting other interfaces solhint-disable-next-line no-empty-blocks
allowance(address,address) :
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(address,uint256) :
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.
balanceOf(address) :
Returns the amount of tokens owned by `account`.
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 {_setupDecimals} is called. 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}.
name() :
Returns the name of the token.
symbol() :
Returns the symbol of the token, usually a shorter version of the name.
totalSupply() :
Returns the amount of tokens in existence.
transfer(address,uint256) :
Moves `amount` tokens from the caller's account to `to`. Returns a boolean value indicating whether the operation succeeded. Emits a {Transfer} event.
transferFrom(address,address,uint256) :
Moves `amount` tokens from `from` to `to` 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.
TokenInfo :
ERC20 standard interface does not specify these functions, but often the token implementations have them.
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 {_setupDecimals} is called. 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}.
name() :
Returns the name of the token.
symbol() :
Returns the symbol of the token, usually a shorter version of the name.
IRelayRecipient :
A contract must implement this interface in order to support relayed transactionsIt is better to inherit the BaseRelayRecipient as its implementation
isTrustedForwarder(address) :
the forwarder is required to verify the sender's signature, and verify the call is not a replay.
versionRecipient() :
EIP 2771 version NOTE: - It is not clear if it is actually from the EIP 2771.... - https://docs.biconomy.io/guides/enable-gasless-transactions/eip-2771
BaseRelayRecipient :
A base contract to be inherited by any contract that want to receive relayed transactions A subclass must use "_msgSender()" instead of "msg.sender" MODIFIED FROM: https://github.com/opengsn/forwarder/blob/master/contracts/BaseRelayRecipient.sol
isTrustedForwarder(address) :
Check if the forwarder is trusted
versionRecipient() :
EIP 2771 version NOTE: - It is not clear if it is actually from the EIP 2771.... - https://docs.biconomy.io/guides/enable-gasless-transactions/eip-2771
ERC1820RegistryCompiled :
This is meant to be used by test framework to get the raw bytecode without compiling the origin contract
EventsEmitter :
A library used for emitting missing and unaccessable events.
SlotsBitmapLibrary :
A library implements slots bitmap on Superfluid Token storage NOTE: - A slots bitmap allows you to iterate through a list of data efficiently. - A data slot can be enabled or disabled with the help of bitmap. - MAX_NUM_SLOTS is 256 in this implementation (using one uint256) - Superfluid token storage usage: - getAgreementStateSlot(bitmapStateSlotId) stores the bitmap of enabled data slots - getAgreementStateSlot(dataStateSlotIDStart + stotId) stores the data of the slot
ForwarderMock :
A test forwarder that can impersonate any account needed. It is obviously not secure for any production use.
MultiFlowTesterApp :
A super app that can split incoming flows to multiple outgoing flows. This is used for testing CFA callbacks logic.
ConstantInflowNFT :
This contract does not hold any storage, but references the ConstantOutflowNFT contract storage.
approve(address,uint256) :
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.
balanceOf(address) :
We always return 1 to avoid the need for additional mapping
burn(uint256) :
We don't modify storage as this is handled in ConstantOutflowNFT.sol and this function's sole purpose is to inform clients that search for events. Only callable by ConstantOutflowNFT
getApproved(uint256) :
Returns the account approved for `tokenId` token. Requirements: - `tokenId` must exist.
getCodeAddress() :
Get current implementation code address.
getTokenId(address,address,address) :
tokenId = uint256(keccak256(abi.encode(block.chainId, superToken, flowSender, flowReceiver)))
isApprovedForAll(address,address) :
Returns if the `operator` is allowed to manage all of the assets of `owner`. See {setApprovalForAll}
mint(address,uint256) :
We don't modify storage as this is handled in ConstantOutflowNFT.sol and this function's sole purpose is to inform clients that search for events. Only callable by ConstantOutflowNFT
name() :
Should follow the naming convention: TOKENx Constant Outflow/Inflow NFT
ownerOf(uint256) :
Returns the owner of the `tokenId` token. Requirements: - `tokenId` must exist.
proxiableUUID() :
Proxiable UUID marker function, this would help to avoid wrong logic contract to be used for upgrading. NOTE: The semantics of the UUID deviates from the actual UUPS standard, where it is equivalent of _IMPLEMENTATION_SLOT.
safeTransferFrom(address,address,uint256) :
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 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.
safeTransferFrom(address,address,uint256,bytes) :
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.
setApprovalForAll(address,bool) :
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.
supportsInterface(bytes4) :
This is part of the Standard Interface Detection EIP: https://eips.ethereum.org/EIPS/eip-165
symbol() :
Should follow the naming convention: TOKENx(COF/CIF)
transferFrom(address,address,uint256) :
Transfers `tokenId` token from `from` to `to`. WARNING: Note that the caller is responsible to confirm that the recipient is capable of receiving ERC721 or else they may be permanently lost. Usage of {safeTransferFrom} prevents loss, though the caller must understand this adds an external call which potentially creates a reentrancy vulnerability. 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.
triggerMetadataUpdate(uint256) :
Callable by anyone.
ConstantOutflowNFT :
This contract uses mint/burn interface for flow creation/deletion and holds the actual storage for both NFTs.
approve(address,uint256) :
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.
balanceOf(address) :
We always return 1 to avoid the need for additional mapping
flowDataByTokenId(uint256) :
getApproved(uint256) :
Returns the account approved for `tokenId` token. Requirements: - `tokenId` must exist.
getCodeAddress() :
Get current implementation code address.
getTokenId(address,address,address) :
tokenId = uint256(keccak256(abi.encode(block.chainId, superToken, flowSender, flowReceiver)))
isApprovedForAll(address,address) :
Returns if the `operator` is allowed to manage all of the assets of `owner`. See {setApprovalForAll}
name() :
Should follow the naming convention: TOKENx Constant Outflow/Inflow NFT
onCreate(address,address,address) :
This function mints the COF NFT to the flow sender and mints the CIF NFT to the flow receiver
onDelete(address,address,address) :
This function burns the COF NFT and burns the CIF NFT
onUpdate(address,address,address) :
This function triggers the metadata update of both COF and CIF NFTs
ownerOf(uint256) :
Returns the owner of the `tokenId` token. Requirements: - `tokenId` must exist.
proxiableUUID() :
Proxiable UUID marker function, this would help to avoid wrong logic contract to be used for upgrading. NOTE: The semantics of the UUID deviates from the actual UUPS standard, where it is equivalent of _IMPLEMENTATION_SLOT.
safeTransferFrom(address,address,uint256) :
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 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.
safeTransferFrom(address,address,uint256,bytes) :
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.
setApprovalForAll(address,bool) :
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.
supportsInterface(bytes4) :
This is part of the Standard Interface Detection EIP: https://eips.ethereum.org/EIPS/eip-165
symbol() :
Should follow the naming convention: TOKENx(COF/CIF)
transferFrom(address,address,uint256) :
Transfers `tokenId` token from `from` to `to`. WARNING: Note that the caller is responsible to confirm that the recipient is capable of receiving ERC721 or else they may be permanently lost. Usage of {safeTransferFrom} prevents loss, though the caller must understand this adds an external call which potentially creates a reentrancy vulnerability. 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.
triggerMetadataUpdate(uint256) :
Callable by anyone.
FlowNFTBase :
This contract inherits from IFlowNFTBase which inherits from IERC721Metadata and holds shared storage and functions for the two NFT contracts. This contract is upgradeable and it inherits from our own ad-hoc UUPSProxiable contract which allows. NOTE: the storage gap allows us to add an additional 16 storage variables to this contract without breaking child COFNFT or CIFNFT storage.
approve(address,uint256) :
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.
balanceOf(address) :
We always return 1 to avoid the need for additional mapping
flowDataByTokenId(uint256) :
Returns the flow data of the `tokenId`. Does NOT revert if token doesn't exist.
getApproved(uint256) :
Returns the account approved for `tokenId` token. Requirements: - `tokenId` must exist.
getCodeAddress() :
Get current implementation code address.
getTokenId(address,address,address) :
tokenId = uint256(keccak256(abi.encode(block.chainId, superToken, flowSender, flowReceiver)))
isApprovedForAll(address,address) :
Returns if the `operator` is allowed to manage all of the assets of `owner`. See {setApprovalForAll}
name() :
Should follow the naming convention: TOKENx Constant Outflow/Inflow NFT
ownerOf(uint256) :
Returns the owner of the `tokenId` token. Requirements: - `tokenId` must exist.
proxiableUUID() :
Proxiable UUID marker function, this would help to avoid wrong logic contract to be used for upgrading. NOTE: The semantics of the UUID deviates from the actual UUPS standard, where it is equivalent of _IMPLEMENTATION_SLOT.
safeTransferFrom(address,address,uint256) :
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 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.
safeTransferFrom(address,address,uint256,bytes) :
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.
setApprovalForAll(address,bool) :
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.
supportsInterface(bytes4) :
This is part of the Standard Interface Detection EIP: https://eips.ethereum.org/EIPS/eip-165
symbol() :
Should follow the naming convention: TOKENx(COF/CIF)
tokenURI(uint256) :
Returns the Uniform Resource Identifier (URI) for `tokenId` token.
transferFrom(address,address,uint256) :
Transfers `tokenId` token from `from` to `to`. WARNING: Note that the caller is responsible to confirm that the recipient is capable of receiving ERC721 or else they may be permanently lost. Usage of {safeTransferFrom} prevents loss, though the caller must understand this adds an external call which potentially creates a reentrancy vulnerability. 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.
triggerMetadataUpdate(uint256) :
Callable by anyone.
Superfluid :
The Superfluid host implementation. NOTE: - Please read ISuperfluid for implementation notes. - For some deeper technical notes, please visit protocol-monorepo wiki area.
addToAgreementClassesBitmap(uint256,bytes32) :
agreementType is the keccak256 hash of: "org.superfluid-finance.agreements.<AGREEMENT_NAME>.<VERSION>"
allowCompositeApp(address) :
Whitelist the target app for app composition for the source app (msg.sender)
appCallbackPop(bytes,int256) :
(For agreements) Pop from the current app callback stack
appCallbackPush(bytes,address,uint256,int256,address) :
(For agreements) Create a new callback stack
batchCall((uint32,address,bytes)[]) :
ISuperfluid.batchCall implementation
callAgreement(address,bytes,bytes) :
Call agreement function
callAppAction(address,bytes) :
Main use case is calling app action in a batch call via the host
callAppAfterCallback(address,bytes,bool,bytes) :
(For agreements) Call the app after callback
callAppBeforeCallback(address,bytes,bool,bytes) :
(For agreements) StaticCall the app before callback
ctxUseCredit(bytes,int256) :
(For agreements) Use app credit.
forwardBatchCall((uint32,address,bytes)[]) :
ISuperfluid.forwardBatchCall implementation
getAgreementClass(bytes32) :
agreementType is the keccak256 hash of: "org.superfluid-finance.agreements.<AGREEMENT_NAME>.<VERSION>"
getAppManifest(address) :
Get the manifest of the super app
getCodeAddress() :
Get current implementation code address.
getGovernance() :
Get the current governance address of the Superfluid host
getSuperTokenFactory() :
Get the super token factory
getSuperTokenFactoryLogic() :
Get the super token factory logic (applicable to upgradable deployment)
isAgreementClassListed(address) :
Check if the agreement class is whitelisted
isAgreementTypeListed(bytes32) :
agreementType is the keccak256 hash of: "org.superfluid-finance.agreements.<AGREEMENT_NAME>.<VERSION>"
isApp(address) :
Query if the app is registered
isAppJailed(address) :
Query if the app has been jailed
isCompositeAppAllowed(address,address) :
Query if source app is allowed to call the target app as downstream app
isTrustedForwarder(address) :
BaseRelayRecipient.isTrustedForwarder implementation
jailApp(bytes,address,uint256) :
(For agreements) Jail the app.
mapAgreementClasses(uint256) :
Map list of the agreement classes using a bitmap
proxiableUUID() :
Proxiable UUID marker function, this would help to avoid wrong logic contract to be used for upgrading. NOTE: The semantics of the UUID deviates from the actual UUPS standard, where it is equivalent of _IMPLEMENTATION_SLOT.
registerAgreementClass(address) :
Register a new agreement class to the system
registerApp(uint256) :
registerAppByFactory(address,uint256) :
Message sender (must be a contract) declares app as a super app
registerAppWithKey(uint256,string) :
Message sender declares itself as a super app.
removeFromAgreementClassesBitmap(uint256,bytes32) :
agreementType is the keccak256 hash of: "org.superfluid-finance.agreements.<AGREEMENT_NAME>.<VERSION>"
replaceGovernance(address) :
Replace the current governance with a new one
updateAgreementClass(address) :
Update code of an agreement class
updateSuperTokenFactory(address) :
Update super token factory
updateSuperTokenLogic(address) :
Refer to ISuperTokenFactory.Upgradability for expected behaviours
versionRecipient() :
IRelayRecipient.isTrustedForwarder implementation
PureSuperToken :
This is a simple implementation where the supply is pre-minted.
initializeProxy(address) :
Proxy initialization function. This should only be called once and it is permission-less.
BatchLiquidator :
This contract allows to delete multiple flows in a single transaction.
deleteFlows(address,address[],address[]) :
Delete flows in batch
Resolver :
A simple implementation of IResolver using OZ AccessControl NOTE: Relevant events for indexing: - OZ Access Control events `RoleGranted`/`RoleRevoked`: admin add/remove - IResolver event `Set`: resolver name updates
get(string) :
Get address by name
getRoleAdmin(bytes32) :
Returns the admin role that controls `role`. See {grantRole} and {revokeRole}. To change a role's admin, use {_setRoleAdmin}.
getRoleMember(bytes32,uint256) :
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(bytes32) :
Returns the number of accounts that have `role`. Can be used together with {getRoleMember} to enumerate all bearers of a role.
grantRole(bytes32,address) :
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. May emit a {RoleGranted} event.
hasRole(bytes32,address) :
Returns `true` if `account` has been granted `role`.
renounceRole(bytes32,address) :
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 revoked `role`, emits a {RoleRevoked} event. Requirements: - the caller must be `account`. May emit a {RoleRevoked} event.
revokeRole(bytes32,address) :
Revokes `role` from `account`. If `account` had been granted `role`, emits a {RoleRevoked} event. Requirements: - the caller must have ``role``'s admin role. May emit a {RoleRevoked} event.
set(string,address) :
Set resolver address name
supportsInterface(bytes4) :
See {IERC165-supportsInterface}.
SuperfluidFrameworkDeployer :
This deployer should only be used for local testing environments. NOTE: ERC1820 must be deployed as a prerequisite to using this contract.
deployAgreementContracts() :
Deploys Superfluid agreement contracts NOTE: This requires the core contracts to be deployed first.
deployCoreContracts((bool,bool,address[],address,uint256,uint256,uint256)) :
Host and Governance
deployCoreContracts() :
Host and Governance
deployNativeAssetSuperToken(string,string) :
e.g. ETHx, MATICx, AVAXx, etc. The underlying is the Native Asset.
deployPeripheralContracts((bool,bool,address[],address,uint256,uint256,uint256)) :
Deploys Resolver, SuperfluidLoaderV1, CFAv1Forwarder, TOGA, BatchLiquidator contracts
deployPeripheralContracts() :
Deploys Resolver, SuperfluidLoaderV1, CFAv1Forwarder, TOGA, BatchLiquidator contracts
deployPureSuperToken(string,string,uint256) :
We specify the initial supply (because non-downgradeable) on creation and send it to the deployer
deploySuperTokenContracts() :
Deploys NFT Proxy and Logic, SuperToken Logic, SuperTokenFactory Proxy and Logic contracts
deployTestFramework() :
This uses default configurations for the framework. NOTE: ERC1820 must be deployed as a prerequisite before calling this function.
deployWrapperSuperToken(string,string,uint8,uint256) :
SuperToken name and symbol format: `Super ${_underlyingSymbol}` and `${_underlyingSymbol}x`, respectively
transferOwnership(address) :
This function allows you to transfer ownership of TestGovernance when testing
SuperfluidFrameworkDeploymentSteps :
This was necessary because of the contract size limit of the deployed contract which is an issue when deploying the original framework with Hardhat. https://github.com/NomicFoundation/hardhat/issues/3404#issuecomment-1346849400
transferOwnership(address) :
This function allows you to transfer ownership of TestGovernance when testing
SuperfluidLoader :
A on-chain utility contract for loading framework objects in one view function. NOTE: Q: Why don't we just use https://www.npmjs.com/package/ethereum-multicall? A: Well, no strong reason other than also allowing on-chain one view function loading.
loadFramework(string) :
Load framework objects
TestGovernance :
A initializable version of the governance for testing purpose
authorizeAppFactory(address,address) :
allows the given factory to register new apps without requiring onetime keys
batchUpdateSuperTokenLogic(address,address[]) :
Update supertoken logic contract to the latest that is managed by the super token factory
clearConfig(address,address,bytes32) :
Clear configuration
getConfigAsAddress(address,address,bytes32) :
Get configuration as address value
getConfigAsUint256(address,address,bytes32) :
Get configuration as uint256 value
isAuthorizedAppFactory(address,address) :
tells if the given factory is authorized to register apps
owner() :
Returns the address of the current owner.
registerAgreementClass(address,address) :
Register a new agreement class
renounceOwnership() :
Leaves the contract without owner. It will not be possible to call `onlyOwner` functions. Can only be called by the current owner. NOTE: Renouncing ownership will leave the contract without an owner, thereby disabling any functionality that is only available to the owner.
setConfig(address,address,bytes32,address) :
Set configuration as address value
setConfig(address,address,bytes32,uint256) :
Set configuration as uint256 value
transferOwnership(address) :
Transfers ownership of the contract to a new account (`newOwner`). Can only be called by the current owner.
unauthorizeAppFactory(address,address) :
withdraws authorization from a factory to register new apps. Doesn't affect apps previously registered by the factory.
updateContracts(address,address,address[],address) :
Update logics of the contracts
TestResolver :
Used by the SuperfluidFrameworkDeployer to grant admin privileges to its deployer
get(string) :
Get address by name
getRoleAdmin(bytes32) :
Returns the admin role that controls `role`. See {grantRole} and {revokeRole}. To change a role's admin, use {_setRoleAdmin}.
getRoleMember(bytes32,uint256) :
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(bytes32) :
Returns the number of accounts that have `role`. Can be used together with {getRoleMember} to enumerate all bearers of a role.
grantRole(bytes32,address) :
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. May emit a {RoleGranted} event.
hasRole(bytes32,address) :
Returns `true` if `account` has been granted `role`.
renounceRole(bytes32,address) :
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 revoked `role`, emits a {RoleRevoked} event. Requirements: - the caller must be `account`. May emit a {RoleRevoked} event.
revokeRole(bytes32,address) :
Revokes `role` from `account`. If `account` had been granted `role`, emits a {RoleRevoked} event. Requirements: - the caller must have ``role``'s admin role. May emit a {RoleRevoked} event.
set(string,address) :
Set resolver address name
supportsInterface(bytes4) :
See {IERC165-supportsInterface}.
TestToken :
Test ERC20 token that allows any one mint new tokens.
allowance(address,address) :
See {IERC20-allowance}.
approve(address,uint256) :
See {IERC20-approve}. NOTE: If `amount` is the maximum `uint256`, the allowance is not updated on `transferFrom`. This is semantically equivalent to an infinite approval. Requirements: - `spender` cannot be the zero address.
balanceOf(address) :
See {IERC20-balanceOf}.
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 default value returned by this function, unless it's overridden. NOTE: This information is only used for _display_ purposes: it in no way affects any of the arithmetic of the contract, including {IERC20-balanceOf} and {IERC20-transfer}.
decreaseAllowance(address,uint256) :
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`.
increaseAllowance(address,uint256) :
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.
mint(address,uint256) :
See {ERC20-_mint}.
name() :
Returns the name of the token.
symbol() :
Returns the symbol of the token, usually a shorter version of the name.
totalSupply() :
See {IERC20-totalSupply}.
transfer(address,uint256) :
See {IERC20-transfer}. Requirements: - `to` cannot be the zero address. - the caller must have a balance of at least `amount`.
transferFrom(address,address,uint256) :
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}. NOTE: Does not update the allowance if the current allowance is the maximum `uint256`. Requirements: - `from` and `to` cannot be the zero address. - `from` must have a balance of at least `amount`. - the caller must have allowance for ``from``'s tokens of at least `amount`.
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: ```solidity 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}: ```solidity 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. We recommend using {AccessControlDefaultAdminRules} to enforce additional security measures for this role.
getRoleAdmin(bytes32) :
Returns the admin role that controls `role`. See {grantRole} and {revokeRole}. To change a role's admin, use {_setRoleAdmin}.
grantRole(bytes32,address) :
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. May emit a {RoleGranted} event.
hasRole(bytes32,address) :
Returns `true` if `account` has been granted `role`.
renounceRole(bytes32,address) :
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 revoked `role`, emits a {RoleRevoked} event. Requirements: - the caller must be `account`. May emit a {RoleRevoked} event.
revokeRole(bytes32,address) :
Revokes `role` from `account`. If `account` had been granted `role`, emits a {RoleRevoked} event. Requirements: - the caller must have ``role``'s admin role. May emit a {RoleRevoked} event.
supportsInterface(bytes4) :
See {IERC165-supportsInterface}.
AccessControlEnumerable :
Extension of {AccessControl} that allows enumerating the members of each role.
getRoleAdmin(bytes32) :
Returns the admin role that controls `role`. See {grantRole} and {revokeRole}. To change a role's admin, use {_setRoleAdmin}.
getRoleMember(bytes32,uint256) :
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(bytes32) :
Returns the number of accounts that have `role`. Can be used together with {getRoleMember} to enumerate all bearers of a role.
grantRole(bytes32,address) :
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. May emit a {RoleGranted} event.
hasRole(bytes32,address) :
Returns `true` if `account` has been granted `role`.
renounceRole(bytes32,address) :
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 revoked `role`, emits a {RoleRevoked} event. Requirements: - the caller must be `account`. May emit a {RoleRevoked} event.
revokeRole(bytes32,address) :
Revokes `role` from `account`. If `account` had been granted `role`, emits a {RoleRevoked} event. Requirements: - the caller must have ``role``'s admin role. May emit a {RoleRevoked} event.
supportsInterface(bytes4) :
See {IERC165-supportsInterface}.
IAccessControl :
External interface of AccessControl declared to support ERC165 detection.
getRoleAdmin(bytes32) :
Returns the admin role that controls `role`. See {grantRole} and {revokeRole}. To change a role's admin, use {AccessControl-_setRoleAdmin}.
grantRole(bytes32,address) :
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.
hasRole(bytes32,address) :
Returns `true` if `account` has been granted `role`.
renounceRole(bytes32,address) :
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`.
revokeRole(bytes32,address) :
Revokes `role` from `account`. If `account` had been granted `role`, emits a {RoleRevoked} event. Requirements: - the caller must have ``role``'s admin role.
IAccessControlEnumerable :
External interface of AccessControlEnumerable declared to support ERC165 detection.
getRoleAdmin(bytes32) :
Returns the admin role that controls `role`. See {grantRole} and {revokeRole}. To change a role's admin, use {AccessControl-_setRoleAdmin}.
getRoleMember(bytes32,uint256) :
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(bytes32) :
Returns the number of accounts that have `role`. Can be used together with {getRoleMember} to enumerate all bearers of a role.
grantRole(bytes32,address) :
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.
hasRole(bytes32,address) :
Returns `true` if `account` has been granted `role`.
renounceRole(bytes32,address) :
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`.
revokeRole(bytes32,address) :
Revokes `role` from `account`. If `account` had been granted `role`, emits a {RoleRevoked} event. Requirements: - the caller must have ``role``'s admin 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.
constructor :
Initializes the contract setting the deployer as the initial owner.
owner() :
Returns the address of the current owner.
renounceOwnership() :
Leaves the contract without owner. It will not be possible to call `onlyOwner` functions. Can only be called by the current owner. NOTE: Renouncing ownership will leave the contract without an owner, thereby disabling any functionality that is only available to the owner.
transferOwnership(address) :
Transfers ownership of the contract to a new account (`newOwner`). Can only be called by the current owner.
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.
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 proxied contracts do not make use of 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. The initialization functions use a version number. Once a version number is used, it is consumed and cannot be reused. This mechanism prevents re-execution of each "step" but allows the creation of new initialization steps in case an upgrade adds a module that needs to be initialized. For example: [.hljs-theme-light.nopadding] ```solidity contract MyToken is ERC20Upgradeable { function initialize() initializer public { __ERC20_init("MyToken", "MTK"); } } contract MyTokenV2 is MyToken, ERC20PermitUpgradeable { function initializeV2() reinitializer(2) public { __ERC20Permit_init("MyToken"); } } ``` 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. [CAUTION] ==== Avoid leaving a contract uninitialized. An uninitialized contract can be taken over by an attacker. This applies to both a proxy and its implementation contract, which may impact the proxy. To prevent the implementation contract from being used, you should invoke the {_disableInitializers} function in the constructor to automatically lock it when it is deployed: [.hljs-theme-light.nopadding] ```
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.openzeppelin.com/t/how-to-implement-erc20-supply-mechanisms/226[How to implement supply mechanisms]. The default value of {decimals} is 18. To change this, you should override this function so it returns a different value. 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}.
allowance(address,address) :
See {IERC20-allowance}.
approve(address,uint256) :
See {IERC20-approve}. NOTE: If `amount` is the maximum `uint256`, the allowance is not updated on `transferFrom`. This is semantically equivalent to an infinite approval. Requirements: - `spender` cannot be the zero address.
balanceOf(address) :
See {IERC20-balanceOf}.
constructor :
Sets the values for {name} and {symbol}. All two of these values are immutable: they can only be set once during construction.
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 default value returned by this function, unless it's overridden. NOTE: This information is only used for _display_ purposes: it in no way affects any of the arithmetic of the contract, including {IERC20-balanceOf} and {IERC20-transfer}.
decreaseAllowance(address,uint256) :
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`.
increaseAllowance(address,uint256) :
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.
name() :
Returns the name of the token.
symbol() :
Returns the symbol of the token, usually a shorter version of the name.
totalSupply() :
See {IERC20-totalSupply}.
transfer(address,uint256) :
See {IERC20-transfer}. Requirements: - `to` cannot be the zero address. - the caller must have a balance of at least `amount`.
transferFrom(address,address,uint256) :
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}. NOTE: Does not update the allowance if the current allowance is the maximum `uint256`. Requirements: - `from` and `to` cannot be the zero address. - `from` must have a balance of at least `amount`. - the caller must have allowance for ``from``'s tokens of at least `amount`.
IERC20 :
Interface of the ERC20 standard as defined in the EIP.
allowance(address,address) :
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(address,uint256) :
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.
balanceOf(address) :
Returns the amount of tokens owned by `account`.
totalSupply() :
Returns the amount of tokens in existence.
transfer(address,uint256) :
Moves `amount` tokens from the caller's account to `to`. Returns a boolean value indicating whether the operation succeeded. Emits a {Transfer} event.
transferFrom(address,address,uint256) :
Moves `amount` tokens from `from` to `to` 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.
IERC20Metadata :
Interface for the optional metadata functions from the ERC20 standard. _Available since v4.1._
allowance(address,address) :
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(address,uint256) :
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.
balanceOf(address) :
Returns the amount of tokens owned by `account`.
decimals() :
Returns the decimals places of the token.
name() :
Returns the name of the token.
symbol() :
Returns the symbol of the token.
totalSupply() :
Returns the amount of tokens in existence.
transfer(address,uint256) :
Moves `amount` tokens from the caller's account to `to`. Returns a boolean value indicating whether the operation succeeded. Emits a {Transfer} event.
transferFrom(address,address,uint256) :
Moves `amount` tokens from `from` to `to` 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.
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.
DOMAIN_SEPARATOR() :
Returns the domain separator used in the encoding of the signature for {permit}, as defined by {EIP712}.
nonces(address) :
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.
permit(address,address,uint256,uint256,uint8,bytes32,bytes32) :
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].
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.
IERC721 :
Required interface of an ERC721 compliant contract.
approve(address,uint256) :
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.
balanceOf(address) :
Returns the number of tokens in ``owner``'s account.
getApproved(uint256) :
Returns the account approved for `tokenId` token. Requirements: - `tokenId` must exist.
isApprovedForAll(address,address) :
Returns if the `operator` is allowed to manage all of the assets of `owner`. See {setApprovalForAll}
ownerOf(uint256) :
Returns the owner of the `tokenId` token. Requirements: - `tokenId` must exist.
safeTransferFrom(address,address,uint256) :
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 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.
safeTransferFrom(address,address,uint256,bytes) :
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.
setApprovalForAll(address,bool) :
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.
supportsInterface(bytes4) :
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.
transferFrom(address,address,uint256) :
Transfers `tokenId` token from `from` to `to`. WARNING: Note that the caller is responsible to confirm that the recipient is capable of receiving ERC721 or else they may be permanently lost. Usage of {safeTransferFrom} prevents loss, though the caller must understand this adds an external call which potentially creates a reentrancy vulnerability. 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.
IERC721Metadata :
See https://eips.ethereum.org/EIPS/eip-721
approve(address,uint256) :
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.
balanceOf(address) :
Returns the number of tokens in ``owner``'s account.
getApproved(uint256) :
Returns the account approved for `tokenId` token. Requirements: - `tokenId` must exist.
isApprovedForAll(address,address) :
Returns if the `operator` is allowed to manage all of the assets of `owner`. See {setApprovalForAll}
name() :
Returns the token collection name.
ownerOf(uint256) :
Returns the owner of the `tokenId` token. Requirements: - `tokenId` must exist.
safeTransferFrom(address,address,uint256) :
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 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.
safeTransferFrom(address,address,uint256,bytes) :
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.
setApprovalForAll(address,bool) :
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.
supportsInterface(bytes4) :
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.
symbol() :
Returns the token collection symbol.
tokenURI(uint256) :
Returns the Uniform Resource Identifier (URI) for `tokenId` token.
transferFrom(address,address,uint256) :
Transfers `tokenId` token from `from` to `to`. WARNING: Note that the caller is responsible to confirm that the recipient is capable of receiving ERC721 or else they may be permanently lost. Usage of {safeTransferFrom} prevents loss, though the caller must understand this adds an external call which potentially creates a reentrancy vulnerability. 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.
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}.
authorizeOperator(address) :
Make an account an operator of the caller. See {isOperatorFor}. Emits an {AuthorizedOperator} event. Requirements - `operator` cannot be calling address.
balanceOf(address) :
Returns the amount of tokens owned by an account (`owner`).
burn(uint256,bytes) :
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.
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.
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.
isOperatorFor(address,address) :
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}.
name() :
Returns the name of the token.
operatorBurn(address,uint256,bytes,bytes) :
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`.
operatorSend(address,address,uint256,bytes,bytes) :
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.
revokeOperator(address) :
Revoke an account's operator status for the caller. See {isOperatorFor} and {defaultOperators}. Emits a {RevokedOperator} event. Requirements - `operator` cannot be calling address.
send(address,uint256,bytes) :
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.
symbol() :
Returns the symbol of the token, usually a shorter version of the name.
totalSupply() :
Returns the amount of tokens in existence.
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(address,address,address,uint256,bytes,bytes) :
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(address,address,address,uint256,bytes,bytes) :
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.
Address :
Collection of functions related to the address type
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.
Strings :
String operations.
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(bytes4) :
See {IERC165-supportsInterface}.
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. CAUTION: This file is deprecated as of v4.9 and will be removed in the next major release.
canImplementInterfaceForAddress(bytes32,address) :
See {IERC1820Implementer-canImplementInterfaceForAddress}.
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(bytes4) :
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.
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(bytes32,address) :
Returns a special value (`ERC1820_ACCEPT_MAGIC`) if this contract implements `interfaceHash` for `account`. See {IERC1820Registry-setInterfaceImplementer}.
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.
getInterfaceImplementer(address,bytes32) :
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.
getManager(address) :
Returns the manager for `account`. See {setManager}.
implementsERC165Interface(address,bytes4) :
implementsERC165InterfaceNoCache(address,bytes4) :
interfaceHash(string) :
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].
setInterfaceImplementer(address,bytes32,address) :
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}.
setManager(address,address) :
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`.
updateERC165Cache(address,bytes4) :
Math :
Standard math utilities missing in the Solidity language.
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.
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.
SignedMath :
Standard signed math utilities missing in the Solidity language.
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. ```solidity contract Example { // Add the library methods using EnumerableSet for EnumerableSet.AddressSet; // Declare a set state variable EnumerableSet.AddressSet private mySet; } ``` As of v3.3.0, sets of type `bytes32` (`Bytes32Set`), `address` (`AddressSet`) and `uint256` (`UintSet`) are supported. [WARNING] ==== Trying to delete such a structure from storage will likely result in data corruption, rendering the structure unusable. See https://github.com/ethereum/solidity/pull/11843[ethereum/solidity#11843] for more info. In order to clean an EnumerableSet, you can either remove all elements one by one or create a fresh instance using an array of EnumerableSet. ====
AgreementBase.sol
AgreementLibrary.sol
ConstantFlowAgreementV1.sol
InstantDistributionAgreementV1.sol
CFAv1Library.sol
IDAv1Library.sol
SuperAppBase.sol
SuperAppBaseFlow.sol
SuperTokenV1Library.sol
SuperfluidLoaderLibrary.sol
SuperfluidGovernanceBase.sol
SuperfluidGovernanceII.sol
IConstantFlowAgreementV1.sol
IInstantDistributionAgreementV1.sol
CustomSuperTokenBase.sol
Definitions.sol
IConstantInflowNFT.sol
IConstantOutflowNFT.sol
IFlowNFTBase.sol
IPoolAdminNFT.sol
IPoolMemberNFT.sol
ISuperAgreement.sol
ISuperApp.sol
ISuperToken.sol
ISuperTokenFactory.sol
ISuperfluid.sol
ISuperfluidGovernance.sol
ISuperfluidToken.sol
ERC20WithTokenInfo.sol
IPureSuperToken.sol
ISETH.sol
TokenInfo.sol
IMultiSigWallet.sol
IRelayRecipient.sol
IResolver.sol
BaseRelayRecipient.sol
CallUtils.sol
ERC1820RegistryCompiled.sol
ERC777Helper.sol
EventsEmitter.sol
FixedSizeData.sol
SafeGasLibrary.sol
SlotsBitmapLibrary.sol
AgreementMock.sol
CFAAppMocks.sol
CFALibraryMock.sol
CFAv1NFTMock.sol
CFAv1NFTUpgradabilityMock.sol
CallUtilsMock.sol
CallUtilsTester.sol
CustomSuperTokenMock.sol
ERC777SenderRecipientMock.sol
FakeSuperfluidMock.sol
ForwarderMock.sol
IDASuperAppTester.sol
IDAv1LibraryMock.sol
MockSmartWallet.sol
MultiFlowTesterApp.sol
StreamRedirector.sol
SuperAppBaseFlowTester.sol
SuperAppMocks.sol
SuperTokenFactoryMock.sol
SuperTokenLibraryV1Mock.sol
SuperTokenMock.sol
SuperfluidDestructorMock.sol
SuperfluidGovernanceIIMock.sol
SuperfluidMock.sol
UUPSProxiableMock.sol
ConstantInflowNFT.sol
ConstantOutflowNFT.sol
FlowNFTBase.sol
FullUpgradableSuperTokenProxy.sol
SuperToken.sol
SuperTokenFactory.sol
Superfluid.sol
SuperfluidToken.sol
PureSuperToken.sol
SETH.sol
UUPSProxiable.sol
UUPSProxy.sol
UUPSUtils.sol
BatchLiquidator.sol
CFAv1Forwarder.sol
ForwarderBase.sol
IDAv1Forwarder.sol
Resolver.sol
SuperUpgrader.sol
SuperfluidFrameworkDeployer.sol
SuperfluidFrameworkDeploymentSteps.sol
SuperfluidLoader.sol
TOGA.sol
TestGovernance.sol
TestResolver.sol
TestToken.sol
AccessControl.sol
AccessControlEnumerable.sol
IAccessControl.sol
IAccessControlEnumerable.sol
Ownable.sol
Proxy.sol
Initializable.sol
ERC20.sol
IERC20.sol
IERC20Metadata.sol
IERC20Permit.sol
SafeERC20.sol
IERC721.sol
IERC721Metadata.sol
IERC777.sol
IERC777Recipient.sol
IERC777Sender.sol
Address.sol
Context.sol
Strings.sol
ERC165.sol
ERC1820Implementer.sol
IERC165.sol
IERC1820Implementer.sol
IERC1820Registry.sol
Math.sol
SafeCast.sol
SafeMath.sol
SignedMath.sol
EnumerableSet.sol
New Discussion

TVL

$1.23M

14 downloads

Chains

Authors

SuperFluid
Streaming
Payments
Protocol
Audited
Info
Source
ChefGPT
Expand
Share

Welcome to superfluid protocol-monorepo 👋

npm GitHub package.json version (subfolder of monorepo) npm npm npm GitHub package.json version (subfolder of monorepo)
Twitter: Superfluid_HQ

Contracts and resources for the Superfluid Protocol

🏠 Homepage

✨ Superfluid App

📖 Docs

The Superfluid Protocol is a framework that realizes the real-time finance vision where user accounts are connected together, and transactions can happen between user accounts instantaneously as a result.

This repository implements the superfluid protocol as Ethereum contracts. It also contains a Javascript SDK for developing Web3 applications using the superfluid protocol.

For technical document, references and tutorials, etc, refer to the docs site.

Packages

@superfluid-finance/ethereum-contracts

Version License: AGPLv3

EVM contracts implementation for the Superfluid Protocol.

If you're interest in peeking under the hood, then check out the contracts package.

@superfluid-finance/metadata

Version License: MIT

Contract addresses, subgraph URLs, and other metadata for the Superfluid Protocol.

@superfluid-finance/sdk-core

Version License: MIT

SDK-Core is an application framework for interacting with the Superfluid Protocol without Solidity knowledge.

@superfluid-finance/sdk-redux

Version License: MIT

SDK-Redux is an application framework for building front-end applications that interact with the Superfluid Protocol.

@superfluid-finance/hot-fuzz

License: AGPLv3

Hot-fuzz is a wrapper of Echidna with additional helper for fuzzing your Superfluid smart contracts applications, including Super Apps.

@superfluid-finance/subgraph

License: AGPLv3

Official subgraph for the Superfluid Protocol.

@superfluid-finance/js-sdk

Version License: MIT

:warning: This package is fully deprecated, use sdk-core instead :warning:

You can get the last release of js-sdk at the branch here.

Javascript SDK for building with Superfluid Protocol.

Bug Bounty

Click here for more information regarding our Bug Bounty.

Examples

See our examples repo for some Superfluid app examples.

Contributing

Contributions, issues, and feature suggestions are welcome! See CONTRIBUTING.md to get started.

Contributors ✨

Thanks goes to these wonderful people (🐸):

Joshua Trujillo
Joshua Trujillo

💻
Manav Darji
Manav Darji

💻
Drew Fisher
Drew Fisher

💻
Didi
Didi

💻
Omidiora Samuel
Omidiora Samuel

💻
Prafful
Prafful

💻
mjaago
mjaago

💻
markcarey
markcarey

💻
Bertrand Juglas
Bertrand Juglas

👀
Shreyas Papinwar
Shreyas Papinwar

💻

This project follows the all-contributors specification. Contributions of any kind welcome!

Programmable Cashflows. Handle subscriptions, salaries, rewards and any composable stream of value, with continuous settlement and per-second netting for extreme capital efficiency.
AgreementLibrary :
Helper library for building super agreement
ConstantFlowAgreementV1 :
Please read IConstantFlowAgreementV1 for implementation notes.For more technical notes, please visit protocol-monorepo wiki area. Storage Layout Notes Agreement State NOTE The Agreement State slot is computed with the following function: keccak256(abi.encode("AgreementState", msg.sender, account, slotId)) slotId = 0 msg.sender = address of CFAv1 account = context.msgSender Flow Agreement State stores the global FlowData state for an account. Agreement Data NOTE The Agreement Data slot is calculated with the following function: keccak256(abi.encode("AgreementData", agreementClass, agreementId)) agreementClass = address of CFAv1 agreementId = FlowId | FlowOperatorId FlowId = keccak256(abi.encode(flowSender, flowReceiver)) FlowId stores FlowData between a flowSender and flowReceiver. FlowOperatorId = keccak256(abi.encode("flowOperator", flowSender, flowOperator)) FlowOperatorId stores FlowOperatorData between a flowSender and flowOperator.
agreementType() :
ISuperAgreement.agreementType implementation
authorizeFlowOperatorWithFullControl(address,address,bytes) :
IConstantFlowAgreementV1.authorizeFlowOperatorWithFullControl implementation
createFlow(address,address,int96,bytes) :
IConstantFlowAgreementV1.createFlow implementation
createFlowByOperator(address,address,address,int96,bytes) :
IConstantFlowAgreementV1.createFlowByOperator implementation
decreaseFlowRateAllowance(address,address,int96,bytes) :
IConstantFlowAgreementV1.decreaseFlowRateAllowance implementation
deleteFlow(address,address,address,bytes) :
IConstantFlowAgreementV1.deleteFlow implementation
deleteFlowByOperator(address,address,address,bytes) :
IConstantFlowAgreementV1.deleteFlowByOperator implementation
getAccountFlowInfo(address,address) :
IConstantFlowAgreementV1.getAccountFlowInfo implementation
getCodeAddress() :
Get current implementation code address.
getDepositRequiredForFlowRate(address,int96) :
IConstantFlowAgreementV1.getDepositRequiredForFlowRate implementation
getFlow(address,address,address) :
IConstantFlowAgreementV1.getFlow implementation
getFlowByID(address,bytes32) :
IConstantFlowAgreementV1.getFlow implementation
getFlowOperatorData(address,address,address) :
IConstantFlowAgreementV1.getFlowOperatorData implementation
getFlowOperatorDataByID(address,bytes32) :
IConstantFlowAgreementV1.getFlowOperatorDataByID implementation
getMaximumFlowRateFromDeposit(address,uint256) :
IConstantFlowAgreementV1.getMaximumFlowRateFromDeposit implementation
getNetFlow(address,address) :
IConstantFlowAgreementV1.getNetFlow implementation
increaseFlowRateAllowance(address,address,int96,bytes) :
IConstantFlowAgreementV1.increaseFlowRateAllowance implementation
isPatricianPeriod(address,address,uint256) :
Returns whether it is the patrician period based on timestamp
isPatricianPeriodNow(address,address) :
Returns whether it is the patrician period based on host.getNow()
proxiableUUID() :
Proxiable UUID marker function, this would help to avoid wrong logic contract to be used for upgrading. NOTE: The semantics of the UUID deviates from the actual UUPS standard, where it is equivalent of _IMPLEMENTATION_SLOT.
realtimeBalanceOf(address,address,uint256) :
ISuperAgreement.realtimeBalanceOf implementation
revokeFlowOperatorWithFullControl(address,address,bytes) :
IConstantFlowAgreementV1.revokeFlowOperatorWithFullControl implementation
updateFlow(address,address,int96,bytes) :
IConstantFlowAgreementV1.updateFlow implementation
updateFlowByOperator(address,address,address,int96,bytes) :
IConstantFlowAgreementV1.updateFlowByOperator implementation
updateFlowOperatorPermissions(address,address,uint8,int96,bytes) :
IConstantFlowAgreementV1.updateFlowOperatorPermissions implementation
InstantDistributionAgreementV1 :
Please read IInstantDistributionAgreementV1 for implementation notes.For more technical notes, please visit protocol-monorepo wiki area. Storage Layout Notes Agreement State NOTE The Agreement State slot is computed with the following function: keccak256(abi.encode("AgreementState", msg.sender, account, slotId)) Publisher Deposit State Slot slotId = _PUBLISHER_DEPOSIT_STATE_SLOT_ID or 1 << 32 or 4294967296 msg.sender = address of IDAv1 account = context.msgSender Publisher Deposit State stores deposit state for a publisher, this is the pending value. Subscriber Subscription Data Slot Id Start slotId = _SUBSCRIBER_SUB_DATA_STATE_SLOT_ID_START or 1 << 128 or 340282366920938463463374607431768211456 msg.sender = address of IDAv1 account = context.msgSender Subscriber Subscription Data Slot Id Start indicates the starting slot for where we begin to store the indexes a subscriber is a part of. Slots Bitmap Data Slot slotId = _SUBSCRIBER_SUBS_BITMAP_STATE_SLOT_ID or 0 msg.sender = address of IDAv1 account = context.msgSender Slots Bitmap Data Slot stores the bitmap of the slots that are "enabled" for a subscriber. This is used as an optimization to only get the data (index id's) for the slots that are "enabled". Agreement Data NOTE The Agreement Data slot is calculated with the following function: keccak256(abi.encode("AgreementData", agreementClass, agreementId)) agreementClass = address of IDAv1 agreementId = PublisherId | SubscriptionId PublisherId = keccak256(abi.encode("publisher", publisher, indexId)) publisher = "owner" of the index indexId = arbitrary value for allowing multiple indexes by the same token-publisher pair PublisherId stores IndexData for an Index. SubscriptionId = keccak256(abi.encode("subscriber", subscriber, iId)) iId = PublisherId, the index this particular subscriber is subscribed to SubscriptionId stores SubscriptionData for a subscriber to an Index.
agreementType() :
ISuperAgreement.agreementType implementation
approveSubscription(address,address,uint32,bytes) :
IInstantDistributionAgreementV1.approveSubscription implementation
calculateDistribution(address,address,uint32,uint256) :
IInstantDistributionAgreementV1.calculateDistribution implementation
claim(address,address,uint32,address,bytes) :
Claim pending distributions
createIndex(address,uint32,bytes) :
IInstantDistributionAgreementV1.createIndex implementation
deleteSubscription(address,address,uint32,address,bytes) :
IInstantDistributionAgreementV1.deleteSubscription implementation
distribute(address,uint32,uint256,bytes) :
IInstantDistributionAgreementV1.distribute implementation
getCodeAddress() :
Get current implementation code address.
getIndex(address,address,uint32) :
IInstantDistributionAgreementV1.getIndex implementation
getSubscription(address,address,uint32,address) :
IInstantDistributionAgreementV1.getSubscription implementation
getSubscriptionByID(address,bytes32) :
IInstantDistributionAgreementV1.getSubscriptionByID implementation
listSubscriptions(address,address) :
IInstantDistributionAgreementV1.listSubscriptions implementation
proxiableUUID() :
Proxiable UUID marker function, this would help to avoid wrong logic contract to be used for upgrading. NOTE: The semantics of the UUID deviates from the actual UUPS standard, where it is equivalent of _IMPLEMENTATION_SLOT.
realtimeBalanceOf(address,address,uint256) :
ISuperAgreement.realtimeBalanceOf implementation
revokeSubscription(address,address,uint32,bytes) :
IInstantDistributionAgreementV1.revokeSubscription implementation
updateIndex(address,uint32,uint128,bytes) :
IInstantDistributionAgreementV1.updateIndex implementation
updateSubscription(address,uint32,address,uint128,bytes) :
IInstantDistributionAgreementV1.updateSubscription implementation
CFAv1Library :
for working with the constant flow agreement within soliditythe first set of functions are each for callAgreement()the second set of functions are each for use in callAgreementWithContext()
IDAv1Library :
Set a variable of type `InitData` in the contract, then call this library's functions directly `initData.functionName()`.
SuperTokenV1Library :
Set `using for ISuperToken` in including file, and call any of these functions on an instance of ISuperToken. Note that it is important to "warm up" the cache and cache the host, cfa, ida before calling, this is only applicable to Foundry tests where the vm.expectRevert() will not work as expected.
ISuperApp :
Be aware of the app being jailed, when the word permitted is used.
afterAgreementCreated(address,address,bytes32,bytes,bytes,bytes) :
Callback after a new agreement is created.
afterAgreementTerminated(address,address,bytes32,bytes,bytes,bytes) :
Callback after a new agreement is terminated.
afterAgreementUpdated(address,address,bytes32,bytes,bytes,bytes) :
Callback after a new agreement is updated.
beforeAgreementCreated(address,address,bytes32,bytes,bytes) :
Callback before a new agreement is created.
beforeAgreementTerminated(address,address,bytes32,bytes,bytes) :
Callback before a new agreement is terminated.
beforeAgreementUpdated(address,address,bytes32,bytes,bytes) :
Callback before a new agreement is updated.
ERC20WithTokenInfo :
Using abstract contract instead of interfaces because old solidity does not support interface inheriting other interfaces solhint-disable-next-line no-empty-blocks
allowance(address,address) :
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(address,uint256) :
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.
balanceOf(address) :
Returns the amount of tokens owned by `account`.
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 {_setupDecimals} is called. 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}.
name() :
Returns the name of the token.
symbol() :
Returns the symbol of the token, usually a shorter version of the name.
totalSupply() :
Returns the amount of tokens in existence.
transfer(address,uint256) :
Moves `amount` tokens from the caller's account to `to`. Returns a boolean value indicating whether the operation succeeded. Emits a {Transfer} event.
transferFrom(address,address,uint256) :
Moves `amount` tokens from `from` to `to` 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.
TokenInfo :
ERC20 standard interface does not specify these functions, but often the token implementations have them.
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 {_setupDecimals} is called. 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}.
name() :
Returns the name of the token.
symbol() :
Returns the symbol of the token, usually a shorter version of the name.
IRelayRecipient :
A contract must implement this interface in order to support relayed transactionsIt is better to inherit the BaseRelayRecipient as its implementation
isTrustedForwarder(address) :
the forwarder is required to verify the sender's signature, and verify the call is not a replay.
versionRecipient() :
EIP 2771 version NOTE: - It is not clear if it is actually from the EIP 2771.... - https://docs.biconomy.io/guides/enable-gasless-transactions/eip-2771
BaseRelayRecipient :
A base contract to be inherited by any contract that want to receive relayed transactions A subclass must use "_msgSender()" instead of "msg.sender" MODIFIED FROM: https://github.com/opengsn/forwarder/blob/master/contracts/BaseRelayRecipient.sol
isTrustedForwarder(address) :
Check if the forwarder is trusted
versionRecipient() :
EIP 2771 version NOTE: - It is not clear if it is actually from the EIP 2771.... - https://docs.biconomy.io/guides/enable-gasless-transactions/eip-2771
ERC1820RegistryCompiled :
This is meant to be used by test framework to get the raw bytecode without compiling the origin contract
EventsEmitter :
A library used for emitting missing and unaccessable events.
SlotsBitmapLibrary :
A library implements slots bitmap on Superfluid Token storage NOTE: - A slots bitmap allows you to iterate through a list of data efficiently. - A data slot can be enabled or disabled with the help of bitmap. - MAX_NUM_SLOTS is 256 in this implementation (using one uint256) - Superfluid token storage usage: - getAgreementStateSlot(bitmapStateSlotId) stores the bitmap of enabled data slots - getAgreementStateSlot(dataStateSlotIDStart + stotId) stores the data of the slot
ForwarderMock :
A test forwarder that can impersonate any account needed. It is obviously not secure for any production use.
MultiFlowTesterApp :
A super app that can split incoming flows to multiple outgoing flows. This is used for testing CFA callbacks logic.
ConstantInflowNFT :
This contract does not hold any storage, but references the ConstantOutflowNFT contract storage.
approve(address,uint256) :
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.
balanceOf(address) :
We always return 1 to avoid the need for additional mapping
burn(uint256) :
We don't modify storage as this is handled in ConstantOutflowNFT.sol and this function's sole purpose is to inform clients that search for events. Only callable by ConstantOutflowNFT
getApproved(uint256) :
Returns the account approved for `tokenId` token. Requirements: - `tokenId` must exist.
getCodeAddress() :
Get current implementation code address.
getTokenId(address,address,address) :
tokenId = uint256(keccak256(abi.encode(block.chainId, superToken, flowSender, flowReceiver)))
isApprovedForAll(address,address) :
Returns if the `operator` is allowed to manage all of the assets of `owner`. See {setApprovalForAll}
mint(address,uint256) :
We don't modify storage as this is handled in ConstantOutflowNFT.sol and this function's sole purpose is to inform clients that search for events. Only callable by ConstantOutflowNFT
name() :
Should follow the naming convention: TOKENx Constant Outflow/Inflow NFT
ownerOf(uint256) :
Returns the owner of the `tokenId` token. Requirements: - `tokenId` must exist.
proxiableUUID() :
Proxiable UUID marker function, this would help to avoid wrong logic contract to be used for upgrading. NOTE: The semantics of the UUID deviates from the actual UUPS standard, where it is equivalent of _IMPLEMENTATION_SLOT.
safeTransferFrom(address,address,uint256) :
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 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.
safeTransferFrom(address,address,uint256,bytes) :
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.
setApprovalForAll(address,bool) :
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.
supportsInterface(bytes4) :
This is part of the Standard Interface Detection EIP: https://eips.ethereum.org/EIPS/eip-165
symbol() :
Should follow the naming convention: TOKENx(COF/CIF)
transferFrom(address,address,uint256) :
Transfers `tokenId` token from `from` to `to`. WARNING: Note that the caller is responsible to confirm that the recipient is capable of receiving ERC721 or else they may be permanently lost. Usage of {safeTransferFrom} prevents loss, though the caller must understand this adds an external call which potentially creates a reentrancy vulnerability. 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.
triggerMetadataUpdate(uint256) :
Callable by anyone.
ConstantOutflowNFT :
This contract uses mint/burn interface for flow creation/deletion and holds the actual storage for both NFTs.
approve(address,uint256) :
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.
balanceOf(address) :
We always return 1 to avoid the need for additional mapping
flowDataByTokenId(uint256) :
getApproved(uint256) :
Returns the account approved for `tokenId` token. Requirements: - `tokenId` must exist.
getCodeAddress() :
Get current implementation code address.
getTokenId(address,address,address) :
tokenId = uint256(keccak256(abi.encode(block.chainId, superToken, flowSender, flowReceiver)))
isApprovedForAll(address,address) :
Returns if the `operator` is allowed to manage all of the assets of `owner`. See {setApprovalForAll}
name() :
Should follow the naming convention: TOKENx Constant Outflow/Inflow NFT
onCreate(address,address,address) :
This function mints the COF NFT to the flow sender and mints the CIF NFT to the flow receiver
onDelete(address,address,address) :
This function burns the COF NFT and burns the CIF NFT
onUpdate(address,address,address) :
This function triggers the metadata update of both COF and CIF NFTs
ownerOf(uint256) :
Returns the owner of the `tokenId` token. Requirements: - `tokenId` must exist.
proxiableUUID() :
Proxiable UUID marker function, this would help to avoid wrong logic contract to be used for upgrading. NOTE: The semantics of the UUID deviates from the actual UUPS standard, where it is equivalent of _IMPLEMENTATION_SLOT.
safeTransferFrom(address,address,uint256) :
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 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.
safeTransferFrom(address,address,uint256,bytes) :
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.
setApprovalForAll(address,bool) :
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.
supportsInterface(bytes4) :
This is part of the Standard Interface Detection EIP: https://eips.ethereum.org/EIPS/eip-165
symbol() :
Should follow the naming convention: TOKENx(COF/CIF)
transferFrom(address,address,uint256) :
Transfers `tokenId` token from `from` to `to`. WARNING: Note that the caller is responsible to confirm that the recipient is capable of receiving ERC721 or else they may be permanently lost. Usage of {safeTransferFrom} prevents loss, though the caller must understand this adds an external call which potentially creates a reentrancy vulnerability. 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.
triggerMetadataUpdate(uint256) :
Callable by anyone.
FlowNFTBase :
This contract inherits from IFlowNFTBase which inherits from IERC721Metadata and holds shared storage and functions for the two NFT contracts. This contract is upgradeable and it inherits from our own ad-hoc UUPSProxiable contract which allows. NOTE: the storage gap allows us to add an additional 16 storage variables to this contract without breaking child COFNFT or CIFNFT storage.
approve(address,uint256) :
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.
balanceOf(address) :
We always return 1 to avoid the need for additional mapping
flowDataByTokenId(uint256) :
Returns the flow data of the `tokenId`. Does NOT revert if token doesn't exist.
getApproved(uint256) :
Returns the account approved for `tokenId` token. Requirements: - `tokenId` must exist.
getCodeAddress() :
Get current implementation code address.
getTokenId(address,address,address) :
tokenId = uint256(keccak256(abi.encode(block.chainId, superToken, flowSender, flowReceiver)))
isApprovedForAll(address,address) :
Returns if the `operator` is allowed to manage all of the assets of `owner`. See {setApprovalForAll}
name() :
Should follow the naming convention: TOKENx Constant Outflow/Inflow NFT
ownerOf(uint256) :
Returns the owner of the `tokenId` token. Requirements: - `tokenId` must exist.
proxiableUUID() :
Proxiable UUID marker function, this would help to avoid wrong logic contract to be used for upgrading. NOTE: The semantics of the UUID deviates from the actual UUPS standard, where it is equivalent of _IMPLEMENTATION_SLOT.
safeTransferFrom(address,address,uint256) :
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 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.
safeTransferFrom(address,address,uint256,bytes) :
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.
setApprovalForAll(address,bool) :
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.
supportsInterface(bytes4) :
This is part of the Standard Interface Detection EIP: https://eips.ethereum.org/EIPS/eip-165
symbol() :
Should follow the naming convention: TOKENx(COF/CIF)
tokenURI(uint256) :
Returns the Uniform Resource Identifier (URI) for `tokenId` token.
transferFrom(address,address,uint256) :
Transfers `tokenId` token from `from` to `to`. WARNING: Note that the caller is responsible to confirm that the recipient is capable of receiving ERC721 or else they may be permanently lost. Usage of {safeTransferFrom} prevents loss, though the caller must understand this adds an external call which potentially creates a reentrancy vulnerability. 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.
triggerMetadataUpdate(uint256) :
Callable by anyone.
Superfluid :
The Superfluid host implementation. NOTE: - Please read ISuperfluid for implementation notes. - For some deeper technical notes, please visit protocol-monorepo wiki area.
addToAgreementClassesBitmap(uint256,bytes32) :
agreementType is the keccak256 hash of: "org.superfluid-finance.agreements.<AGREEMENT_NAME>.<VERSION>"
allowCompositeApp(address) :
Whitelist the target app for app composition for the source app (msg.sender)
appCallbackPop(bytes,int256) :
(For agreements) Pop from the current app callback stack
appCallbackPush(bytes,address,uint256,int256,address) :
(For agreements) Create a new callback stack
batchCall((uint32,address,bytes)[]) :
ISuperfluid.batchCall implementation
callAgreement(address,bytes,bytes) :
Call agreement function
callAppAction(address,bytes) :
Main use case is calling app action in a batch call via the host
callAppAfterCallback(address,bytes,bool,bytes) :
(For agreements) Call the app after callback
callAppBeforeCallback(address,bytes,bool,bytes) :
(For agreements) StaticCall the app before callback
ctxUseCredit(bytes,int256) :
(For agreements) Use app credit.
forwardBatchCall((uint32,address,bytes)[]) :
ISuperfluid.forwardBatchCall implementation
getAgreementClass(bytes32) :
agreementType is the keccak256 hash of: "org.superfluid-finance.agreements.<AGREEMENT_NAME>.<VERSION>"
getAppManifest(address) :
Get the manifest of the super app
getCodeAddress() :
Get current implementation code address.
getGovernance() :
Get the current governance address of the Superfluid host
getSuperTokenFactory() :
Get the super token factory
getSuperTokenFactoryLogic() :
Get the super token factory logic (applicable to upgradable deployment)
isAgreementClassListed(address) :
Check if the agreement class is whitelisted
isAgreementTypeListed(bytes32) :
agreementType is the keccak256 hash of: "org.superfluid-finance.agreements.<AGREEMENT_NAME>.<VERSION>"
isApp(address) :
Query if the app is registered
isAppJailed(address) :
Query if the app has been jailed
isCompositeAppAllowed(address,address) :
Query if source app is allowed to call the target app as downstream app
isTrustedForwarder(address) :
BaseRelayRecipient.isTrustedForwarder implementation
jailApp(bytes,address,uint256) :
(For agreements) Jail the app.
mapAgreementClasses(uint256) :
Map list of the agreement classes using a bitmap
proxiableUUID() :
Proxiable UUID marker function, this would help to avoid wrong logic contract to be used for upgrading. NOTE: The semantics of the UUID deviates from the actual UUPS standard, where it is equivalent of _IMPLEMENTATION_SLOT.
registerAgreementClass(address) :
Register a new agreement class to the system
registerApp(uint256) :
registerAppByFactory(address,uint256) :
Message sender (must be a contract) declares app as a super app
registerAppWithKey(uint256,string) :
Message sender declares itself as a super app.
removeFromAgreementClassesBitmap(uint256,bytes32) :
agreementType is the keccak256 hash of: "org.superfluid-finance.agreements.<AGREEMENT_NAME>.<VERSION>"
replaceGovernance(address) :
Replace the current governance with a new one
updateAgreementClass(address) :
Update code of an agreement class
updateSuperTokenFactory(address) :
Update super token factory
updateSuperTokenLogic(address) :
Refer to ISuperTokenFactory.Upgradability for expected behaviours
versionRecipient() :
IRelayRecipient.isTrustedForwarder implementation
PureSuperToken :
This is a simple implementation where the supply is pre-minted.
initializeProxy(address) :
Proxy initialization function. This should only be called once and it is permission-less.
BatchLiquidator :
This contract allows to delete multiple flows in a single transaction.
deleteFlows(address,address[],address[]) :
Delete flows in batch
Resolver :
A simple implementation of IResolver using OZ AccessControl NOTE: Relevant events for indexing: - OZ Access Control events `RoleGranted`/`RoleRevoked`: admin add/remove - IResolver event `Set`: resolver name updates
get(string) :
Get address by name
getRoleAdmin(bytes32) :
Returns the admin role that controls `role`. See {grantRole} and {revokeRole}. To change a role's admin, use {_setRoleAdmin}.
getRoleMember(bytes32,uint256) :
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(bytes32) :
Returns the number of accounts that have `role`. Can be used together with {getRoleMember} to enumerate all bearers of a role.
grantRole(bytes32,address) :
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. May emit a {RoleGranted} event.
hasRole(bytes32,address) :
Returns `true` if `account` has been granted `role`.
renounceRole(bytes32,address) :
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 revoked `role`, emits a {RoleRevoked} event. Requirements: - the caller must be `account`. May emit a {RoleRevoked} event.
revokeRole(bytes32,address) :
Revokes `role` from `account`. If `account` had been granted `role`, emits a {RoleRevoked} event. Requirements: - the caller must have ``role``'s admin role. May emit a {RoleRevoked} event.
set(string,address) :
Set resolver address name
supportsInterface(bytes4) :
See {IERC165-supportsInterface}.
SuperfluidFrameworkDeployer :
This deployer should only be used for local testing environments. NOTE: ERC1820 must be deployed as a prerequisite to using this contract.
deployAgreementContracts() :
Deploys Superfluid agreement contracts NOTE: This requires the core contracts to be deployed first.
deployCoreContracts((bool,bool,address[],address,uint256,uint256,uint256)) :
Host and Governance
deployCoreContracts() :
Host and Governance
deployNativeAssetSuperToken(string,string) :
e.g. ETHx, MATICx, AVAXx, etc. The underlying is the Native Asset.
deployPeripheralContracts((bool,bool,address[],address,uint256,uint256,uint256)) :
Deploys Resolver, SuperfluidLoaderV1, CFAv1Forwarder, TOGA, BatchLiquidator contracts
deployPeripheralContracts() :
Deploys Resolver, SuperfluidLoaderV1, CFAv1Forwarder, TOGA, BatchLiquidator contracts
deployPureSuperToken(string,string,uint256) :
We specify the initial supply (because non-downgradeable) on creation and send it to the deployer
deploySuperTokenContracts() :
Deploys NFT Proxy and Logic, SuperToken Logic, SuperTokenFactory Proxy and Logic contracts
deployTestFramework() :
This uses default configurations for the framework. NOTE: ERC1820 must be deployed as a prerequisite before calling this function.
deployWrapperSuperToken(string,string,uint8,uint256) :
SuperToken name and symbol format: `Super ${_underlyingSymbol}` and `${_underlyingSymbol}x`, respectively
transferOwnership(address) :
This function allows you to transfer ownership of TestGovernance when testing
SuperfluidFrameworkDeploymentSteps :
This was necessary because of the contract size limit of the deployed contract which is an issue when deploying the original framework with Hardhat. https://github.com/NomicFoundation/hardhat/issues/3404#issuecomment-1346849400
transferOwnership(address) :
This function allows you to transfer ownership of TestGovernance when testing
SuperfluidLoader :
A on-chain utility contract for loading framework objects in one view function. NOTE: Q: Why don't we just use https://www.npmjs.com/package/ethereum-multicall? A: Well, no strong reason other than also allowing on-chain one view function loading.
loadFramework(string) :
Load framework objects
TestGovernance :
A initializable version of the governance for testing purpose
authorizeAppFactory(address,address) :
allows the given factory to register new apps without requiring onetime keys
batchUpdateSuperTokenLogic(address,address[]) :
Update supertoken logic contract to the latest that is managed by the super token factory
clearConfig(address,address,bytes32) :
Clear configuration
getConfigAsAddress(address,address,bytes32) :
Get configuration as address value
getConfigAsUint256(address,address,bytes32) :
Get configuration as uint256 value
isAuthorizedAppFactory(address,address) :
tells if the given factory is authorized to register apps
owner() :
Returns the address of the current owner.
registerAgreementClass(address,address) :
Register a new agreement class
renounceOwnership() :
Leaves the contract without owner. It will not be possible to call `onlyOwner` functions. Can only be called by the current owner. NOTE: Renouncing ownership will leave the contract without an owner, thereby disabling any functionality that is only available to the owner.
setConfig(address,address,bytes32,address) :
Set configuration as address value
setConfig(address,address,bytes32,uint256) :
Set configuration as uint256 value
transferOwnership(address) :
Transfers ownership of the contract to a new account (`newOwner`). Can only be called by the current owner.
unauthorizeAppFactory(address,address) :
withdraws authorization from a factory to register new apps. Doesn't affect apps previously registered by the factory.
updateContracts(address,address,address[],address) :
Update logics of the contracts
TestResolver :
Used by the SuperfluidFrameworkDeployer to grant admin privileges to its deployer
get(string) :
Get address by name
getRoleAdmin(bytes32) :
Returns the admin role that controls `role`. See {grantRole} and {revokeRole}. To change a role's admin, use {_setRoleAdmin}.
getRoleMember(bytes32,uint256) :
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(bytes32) :
Returns the number of accounts that have `role`. Can be used together with {getRoleMember} to enumerate all bearers of a role.
grantRole(bytes32,address) :
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. May emit a {RoleGranted} event.
hasRole(bytes32,address) :
Returns `true` if `account` has been granted `role`.
renounceRole(bytes32,address) :
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 revoked `role`, emits a {RoleRevoked} event. Requirements: - the caller must be `account`. May emit a {RoleRevoked} event.
revokeRole(bytes32,address) :
Revokes `role` from `account`. If `account` had been granted `role`, emits a {RoleRevoked} event. Requirements: - the caller must have ``role``'s admin role. May emit a {RoleRevoked} event.
set(string,address) :
Set resolver address name
supportsInterface(bytes4) :
See {IERC165-supportsInterface}.
TestToken :
Test ERC20 token that allows any one mint new tokens.
allowance(address,address) :
See {IERC20-allowance}.
approve(address,uint256) :
See {IERC20-approve}. NOTE: If `amount` is the maximum `uint256`, the allowance is not updated on `transferFrom`. This is semantically equivalent to an infinite approval. Requirements: - `spender` cannot be the zero address.
balanceOf(address) :
See {IERC20-balanceOf}.
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 default value returned by this function, unless it's overridden. NOTE: This information is only used for _display_ purposes: it in no way affects any of the arithmetic of the contract, including {IERC20-balanceOf} and {IERC20-transfer}.
decreaseAllowance(address,uint256) :
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`.
increaseAllowance(address,uint256) :
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.
mint(address,uint256) :
See {ERC20-_mint}.
name() :
Returns the name of the token.
symbol() :
Returns the symbol of the token, usually a shorter version of the name.
totalSupply() :
See {IERC20-totalSupply}.
transfer(address,uint256) :
See {IERC20-transfer}. Requirements: - `to` cannot be the zero address. - the caller must have a balance of at least `amount`.
transferFrom(address,address,uint256) :
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}. NOTE: Does not update the allowance if the current allowance is the maximum `uint256`. Requirements: - `from` and `to` cannot be the zero address. - `from` must have a balance of at least `amount`. - the caller must have allowance for ``from``'s tokens of at least `amount`.
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: ```solidity 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}: ```solidity 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. We recommend using {AccessControlDefaultAdminRules} to enforce additional security measures for this role.
getRoleAdmin(bytes32) :
Returns the admin role that controls `role`. See {grantRole} and {revokeRole}. To change a role's admin, use {_setRoleAdmin}.
grantRole(bytes32,address) :
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. May emit a {RoleGranted} event.
hasRole(bytes32,address) :
Returns `true` if `account` has been granted `role`.
renounceRole(bytes32,address) :
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 revoked `role`, emits a {RoleRevoked} event. Requirements: - the caller must be `account`. May emit a {RoleRevoked} event.
revokeRole(bytes32,address) :
Revokes `role` from `account`. If `account` had been granted `role`, emits a {RoleRevoked} event. Requirements: - the caller must have ``role``'s admin role. May emit a {RoleRevoked} event.
supportsInterface(bytes4) :
See {IERC165-supportsInterface}.
AccessControlEnumerable :
Extension of {AccessControl} that allows enumerating the members of each role.
getRoleAdmin(bytes32) :
Returns the admin role that controls `role`. See {grantRole} and {revokeRole}. To change a role's admin, use {_setRoleAdmin}.
getRoleMember(bytes32,uint256) :
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(bytes32) :
Returns the number of accounts that have `role`. Can be used together with {getRoleMember} to enumerate all bearers of a role.
grantRole(bytes32,address) :
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. May emit a {RoleGranted} event.
hasRole(bytes32,address) :
Returns `true` if `account` has been granted `role`.
renounceRole(bytes32,address) :
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 revoked `role`, emits a {RoleRevoked} event. Requirements: - the caller must be `account`. May emit a {RoleRevoked} event.
revokeRole(bytes32,address) :
Revokes `role` from `account`. If `account` had been granted `role`, emits a {RoleRevoked} event. Requirements: - the caller must have ``role``'s admin role. May emit a {RoleRevoked} event.
supportsInterface(bytes4) :
See {IERC165-supportsInterface}.
IAccessControl :
External interface of AccessControl declared to support ERC165 detection.
getRoleAdmin(bytes32) :
Returns the admin role that controls `role`. See {grantRole} and {revokeRole}. To change a role's admin, use {AccessControl-_setRoleAdmin}.
grantRole(bytes32,address) :
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.
hasRole(bytes32,address) :
Returns `true` if `account` has been granted `role`.
renounceRole(bytes32,address) :
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`.
revokeRole(bytes32,address) :
Revokes `role` from `account`. If `account` had been granted `role`, emits a {RoleRevoked} event. Requirements: - the caller must have ``role``'s admin role.
IAccessControlEnumerable :
External interface of AccessControlEnumerable declared to support ERC165 detection.
getRoleAdmin(bytes32) :
Returns the admin role that controls `role`. See {grantRole} and {revokeRole}. To change a role's admin, use {AccessControl-_setRoleAdmin}.
getRoleMember(bytes32,uint256) :
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(bytes32) :
Returns the number of accounts that have `role`. Can be used together with {getRoleMember} to enumerate all bearers of a role.
grantRole(bytes32,address) :
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.
hasRole(bytes32,address) :
Returns `true` if `account` has been granted `role`.
renounceRole(bytes32,address) :
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`.
revokeRole(bytes32,address) :
Revokes `role` from `account`. If `account` had been granted `role`, emits a {RoleRevoked} event. Requirements: - the caller must have ``role``'s admin 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.
constructor :
Initializes the contract setting the deployer as the initial owner.
owner() :
Returns the address of the current owner.
renounceOwnership() :
Leaves the contract without owner. It will not be possible to call `onlyOwner` functions. Can only be called by the current owner. NOTE: Renouncing ownership will leave the contract without an owner, thereby disabling any functionality that is only available to the owner.
transferOwnership(address) :
Transfers ownership of the contract to a new account (`newOwner`). Can only be called by the current owner.
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.
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 proxied contracts do not make use of 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. The initialization functions use a version number. Once a version number is used, it is consumed and cannot be reused. This mechanism prevents re-execution of each "step" but allows the creation of new initialization steps in case an upgrade adds a module that needs to be initialized. For example: [.hljs-theme-light.nopadding] ```solidity contract MyToken is ERC20Upgradeable { function initialize() initializer public { __ERC20_init("MyToken", "MTK"); } } contract MyTokenV2 is MyToken, ERC20PermitUpgradeable { function initializeV2() reinitializer(2) public { __ERC20Permit_init("MyToken"); } } ``` 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. [CAUTION] ==== Avoid leaving a contract uninitialized. An uninitialized contract can be taken over by an attacker. This applies to both a proxy and its implementation contract, which may impact the proxy. To prevent the implementation contract from being used, you should invoke the {_disableInitializers} function in the constructor to automatically lock it when it is deployed: [.hljs-theme-light.nopadding] ```
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.openzeppelin.com/t/how-to-implement-erc20-supply-mechanisms/226[How to implement supply mechanisms]. The default value of {decimals} is 18. To change this, you should override this function so it returns a different value. 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}.
allowance(address,address) :
See {IERC20-allowance}.
approve(address,uint256) :
See {IERC20-approve}. NOTE: If `amount` is the maximum `uint256`, the allowance is not updated on `transferFrom`. This is semantically equivalent to an infinite approval. Requirements: - `spender` cannot be the zero address.
balanceOf(address) :
See {IERC20-balanceOf}.
constructor :
Sets the values for {name} and {symbol}. All two of these values are immutable: they can only be set once during construction.
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 default value returned by this function, unless it's overridden. NOTE: This information is only used for _display_ purposes: it in no way affects any of the arithmetic of the contract, including {IERC20-balanceOf} and {IERC20-transfer}.
decreaseAllowance(address,uint256) :
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`.
increaseAllowance(address,uint256) :
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.
name() :
Returns the name of the token.
symbol() :
Returns the symbol of the token, usually a shorter version of the name.
totalSupply() :
See {IERC20-totalSupply}.
transfer(address,uint256) :
See {IERC20-transfer}. Requirements: - `to` cannot be the zero address. - the caller must have a balance of at least `amount`.
transferFrom(address,address,uint256) :
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}. NOTE: Does not update the allowance if the current allowance is the maximum `uint256`. Requirements: - `from` and `to` cannot be the zero address. - `from` must have a balance of at least `amount`. - the caller must have allowance for ``from``'s tokens of at least `amount`.
IERC20 :
Interface of the ERC20 standard as defined in the EIP.
allowance(address,address) :
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(address,uint256) :
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.
balanceOf(address) :
Returns the amount of tokens owned by `account`.
totalSupply() :
Returns the amount of tokens in existence.
transfer(address,uint256) :
Moves `amount` tokens from the caller's account to `to`. Returns a boolean value indicating whether the operation succeeded. Emits a {Transfer} event.
transferFrom(address,address,uint256) :
Moves `amount` tokens from `from` to `to` 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.
IERC20Metadata :
Interface for the optional metadata functions from the ERC20 standard. _Available since v4.1._
allowance(address,address) :
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(address,uint256) :
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.
balanceOf(address) :
Returns the amount of tokens owned by `account`.
decimals() :
Returns the decimals places of the token.
name() :
Returns the name of the token.
symbol() :
Returns the symbol of the token.
totalSupply() :
Returns the amount of tokens in existence.
transfer(address,uint256) :
Moves `amount` tokens from the caller's account to `to`. Returns a boolean value indicating whether the operation succeeded. Emits a {Transfer} event.
transferFrom(address,address,uint256) :
Moves `amount` tokens from `from` to `to` 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.
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.
DOMAIN_SEPARATOR() :
Returns the domain separator used in the encoding of the signature for {permit}, as defined by {EIP712}.
nonces(address) :
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.
permit(address,address,uint256,uint256,uint8,bytes32,bytes32) :
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].
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.
IERC721 :
Required interface of an ERC721 compliant contract.
approve(address,uint256) :
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.
balanceOf(address) :
Returns the number of tokens in ``owner``'s account.
getApproved(uint256) :
Returns the account approved for `tokenId` token. Requirements: - `tokenId` must exist.
isApprovedForAll(address,address) :
Returns if the `operator` is allowed to manage all of the assets of `owner`. See {setApprovalForAll}
ownerOf(uint256) :
Returns the owner of the `tokenId` token. Requirements: - `tokenId` must exist.
safeTransferFrom(address,address,uint256) :
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 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.
safeTransferFrom(address,address,uint256,bytes) :
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.
setApprovalForAll(address,bool) :
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.
supportsInterface(bytes4) :
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.
transferFrom(address,address,uint256) :
Transfers `tokenId` token from `from` to `to`. WARNING: Note that the caller is responsible to confirm that the recipient is capable of receiving ERC721 or else they may be permanently lost. Usage of {safeTransferFrom} prevents loss, though the caller must understand this adds an external call which potentially creates a reentrancy vulnerability. 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.
IERC721Metadata :
See https://eips.ethereum.org/EIPS/eip-721
approve(address,uint256) :
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.
balanceOf(address) :
Returns the number of tokens in ``owner``'s account.
getApproved(uint256) :
Returns the account approved for `tokenId` token. Requirements: - `tokenId` must exist.
isApprovedForAll(address,address) :
Returns if the `operator` is allowed to manage all of the assets of `owner`. See {setApprovalForAll}
name() :
Returns the token collection name.
ownerOf(uint256) :
Returns the owner of the `tokenId` token. Requirements: - `tokenId` must exist.
safeTransferFrom(address,address,uint256) :
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 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.
safeTransferFrom(address,address,uint256,bytes) :
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.
setApprovalForAll(address,bool) :
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.
supportsInterface(bytes4) :
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.
symbol() :
Returns the token collection symbol.
tokenURI(uint256) :
Returns the Uniform Resource Identifier (URI) for `tokenId` token.
transferFrom(address,address,uint256) :
Transfers `tokenId` token from `from` to `to`. WARNING: Note that the caller is responsible to confirm that the recipient is capable of receiving ERC721 or else they may be permanently lost. Usage of {safeTransferFrom} prevents loss, though the caller must understand this adds an external call which potentially creates a reentrancy vulnerability. 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.
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}.
authorizeOperator(address) :
Make an account an operator of the caller. See {isOperatorFor}. Emits an {AuthorizedOperator} event. Requirements - `operator` cannot be calling address.
balanceOf(address) :
Returns the amount of tokens owned by an account (`owner`).
burn(uint256,bytes) :
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.
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.
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.
isOperatorFor(address,address) :
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}.
name() :
Returns the name of the token.
operatorBurn(address,uint256,bytes,bytes) :
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`.
operatorSend(address,address,uint256,bytes,bytes) :
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.
revokeOperator(address) :
Revoke an account's operator status for the caller. See {isOperatorFor} and {defaultOperators}. Emits a {RevokedOperator} event. Requirements - `operator` cannot be calling address.
send(address,uint256,bytes) :
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.
symbol() :
Returns the symbol of the token, usually a shorter version of the name.
totalSupply() :
Returns the amount of tokens in existence.
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(address,address,address,uint256,bytes,bytes) :
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(address,address,address,uint256,bytes,bytes) :
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.
Address :
Collection of functions related to the address type
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.
Strings :
String operations.
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(bytes4) :
See {IERC165-supportsInterface}.
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. CAUTION: This file is deprecated as of v4.9 and will be removed in the next major release.
canImplementInterfaceForAddress(bytes32,address) :
See {IERC1820Implementer-canImplementInterfaceForAddress}.
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(bytes4) :
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.
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(bytes32,address) :
Returns a special value (`ERC1820_ACCEPT_MAGIC`) if this contract implements `interfaceHash` for `account`. See {IERC1820Registry-setInterfaceImplementer}.
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.
getInterfaceImplementer(address,bytes32) :
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.
getManager(address) :
Returns the manager for `account`. See {setManager}.
implementsERC165Interface(address,bytes4) :
implementsERC165InterfaceNoCache(address,bytes4) :
interfaceHash(string) :
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].
setInterfaceImplementer(address,bytes32,address) :
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}.
setManager(address,address) :
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`.
updateERC165Cache(address,bytes4) :
Math :
Standard math utilities missing in the Solidity language.
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.
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.
SignedMath :
Standard signed math utilities missing in the Solidity language.
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. ```solidity contract Example { // Add the library methods using EnumerableSet for EnumerableSet.AddressSet; // Declare a set state variable EnumerableSet.AddressSet private mySet; } ``` As of v3.3.0, sets of type `bytes32` (`Bytes32Set`), `address` (`AddressSet`) and `uint256` (`UintSet`) are supported. [WARNING] ==== Trying to delete such a structure from storage will likely result in data corruption, rendering the structure unusable. See https://github.com/ethereum/solidity/pull/11843[ethereum/solidity#11843] for more info. In order to clean an EnumerableSet, you can either remove all elements one by one or create a fresh instance using an array of EnumerableSet. ====
AgreementBase.sol
AgreementLibrary.sol
ConstantFlowAgreementV1.sol
InstantDistributionAgreementV1.sol
CFAv1Library.sol
IDAv1Library.sol
SuperAppBase.sol
SuperAppBaseFlow.sol
SuperTokenV1Library.sol
SuperfluidLoaderLibrary.sol
SuperfluidGovernanceBase.sol
SuperfluidGovernanceII.sol
IConstantFlowAgreementV1.sol
IInstantDistributionAgreementV1.sol
CustomSuperTokenBase.sol
Definitions.sol
IConstantInflowNFT.sol
IConstantOutflowNFT.sol
IFlowNFTBase.sol
IPoolAdminNFT.sol
IPoolMemberNFT.sol
ISuperAgreement.sol
ISuperApp.sol
ISuperToken.sol
ISuperTokenFactory.sol
ISuperfluid.sol
ISuperfluidGovernance.sol
ISuperfluidToken.sol
ERC20WithTokenInfo.sol
IPureSuperToken.sol
ISETH.sol
TokenInfo.sol
IMultiSigWallet.sol
IRelayRecipient.sol
IResolver.sol
BaseRelayRecipient.sol
CallUtils.sol
ERC1820RegistryCompiled.sol
ERC777Helper.sol
EventsEmitter.sol
FixedSizeData.sol
SafeGasLibrary.sol
SlotsBitmapLibrary.sol
AgreementMock.sol
CFAAppMocks.sol
CFALibraryMock.sol
CFAv1NFTMock.sol
CFAv1NFTUpgradabilityMock.sol
CallUtilsMock.sol
CallUtilsTester.sol
CustomSuperTokenMock.sol
ERC777SenderRecipientMock.sol
FakeSuperfluidMock.sol
ForwarderMock.sol
IDASuperAppTester.sol
IDAv1LibraryMock.sol
MockSmartWallet.sol
MultiFlowTesterApp.sol
StreamRedirector.sol
SuperAppBaseFlowTester.sol
SuperAppMocks.sol
SuperTokenFactoryMock.sol
SuperTokenLibraryV1Mock.sol
SuperTokenMock.sol
SuperfluidDestructorMock.sol
SuperfluidGovernanceIIMock.sol
SuperfluidMock.sol
UUPSProxiableMock.sol
ConstantInflowNFT.sol
ConstantOutflowNFT.sol
FlowNFTBase.sol
FullUpgradableSuperTokenProxy.sol
SuperToken.sol
SuperTokenFactory.sol
Superfluid.sol
SuperfluidToken.sol
PureSuperToken.sol
SETH.sol
UUPSProxiable.sol
UUPSProxy.sol
UUPSUtils.sol
BatchLiquidator.sol
CFAv1Forwarder.sol
ForwarderBase.sol
IDAv1Forwarder.sol
Resolver.sol
SuperUpgrader.sol
SuperfluidFrameworkDeployer.sol
SuperfluidFrameworkDeploymentSteps.sol
SuperfluidLoader.sol
TOGA.sol
TestGovernance.sol
TestResolver.sol
TestToken.sol
AccessControl.sol
AccessControlEnumerable.sol
IAccessControl.sol
IAccessControlEnumerable.sol
Ownable.sol
Proxy.sol
Initializable.sol
ERC20.sol
IERC20.sol
IERC20Metadata.sol
IERC20Permit.sol
SafeERC20.sol
IERC721.sol
IERC721Metadata.sol
IERC777.sol
IERC777Recipient.sol
IERC777Sender.sol
Address.sol
Context.sol
Strings.sol
ERC165.sol
ERC1820Implementer.sol
IERC165.sol
IERC1820Implementer.sol
IERC1820Registry.sol
Math.sol
SafeCast.sol
SafeMath.sol
SignedMath.sol
EnumerableSet.sol

Get Cookin'

copy iconOpen in VSCode
copy iconDownload Source

TVL

$1.23M

14 downloads

Chains

Authors