Helper library for building super agreement

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.

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.

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()

Set a variable of type `InitData` in the contract, then call this library's functions directly `initData.functionName()`.

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.

Be aware of the app being jailed, when the word permitted is used.

Using abstract contract instead of interfaces because old solidity does not support interface inheriting other interfaces solhint-disable-next-line no-empty-blocks

ERC20 standard interface does not specify these functions, but often the token implementations have them.

A contract must implement this interface in order to support relayed transactionsIt is better to inherit the BaseRelayRecipient as its implementation

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

This is meant to be used by test framework to get the raw bytecode without compiling the origin contract

A library used for emitting missing and unaccessable events.

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

A test forwarder that can impersonate any account needed. It is obviously not secure for any production use.

A super app that can split incoming flows to multiple outgoing flows. This is used for testing CFA callbacks logic.

This contract does not hold any storage, but references the ConstantOutflowNFT contract storage.

This contract uses mint/burn interface for flow creation/deletion and holds the actual storage for both NFTs.

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.

The Superfluid host implementation. NOTE: - Please read ISuperfluid for implementation notes. - For some deeper technical notes, please visit protocol-monorepo wiki area.

This is a simple implementation where the supply is pre-minted.

This contract allows to delete multiple flows in a single transaction.

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

This deployer should only be used for local testing environments. NOTE: ERC1820 must be deployed as a prerequisite to using this contract.

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

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.

A initializable version of the governance for testing purpose

Used by the SuperfluidFrameworkDeployer to grant admin privileges to its deployer

Test ERC20 token that allows any one mint new tokens.

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.

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

External interface of AccessControl declared to support ERC165 detection.

External interface of AccessControlEnumerable declared to support ERC165 detection.

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.

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.

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] ```

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}.

Interface of the ERC20 standard as defined in the EIP.

Interface for the optional metadata functions from the ERC20 standard. _Available since v4.1._

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.

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.

Required interface of an ERC721 compliant contract.

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

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}.

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}.

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}.

Collection of functions related to the address type

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.

String operations.

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.

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.

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}.

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}.

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.

Standard math utilities missing in the Solidity language.

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.

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.

Standard signed math utilities missing in the Solidity language.

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. ====