@superfluid-finance/ethereum-contracts 1.1.2-dev.6e6d5ef.0 → 1.1.2-dev.9b08025.0

package/README.md

@@ -28,7 +28,7 @@
 
 ## Usage
 
-If you're building a dapp using existing protocol or Super Token contracts, then you should use [`@superfluid-finance/js-sdk`](/packages/js-sdk). [Here](https://docs.superfluid.finance/superfluid/networks/networks) you can find a list of networks where the Superfluid protocol is already deployed.
+If you're building a dapp using existing protocol or Super Token contracts, then you should use [`@superfluid-finance/sdk-core`](/packages/sdk-core). [Here](https://docs.superfluid.finance/superfluid/networks/networks) you can find a list of networks where the Superfluid protocol is already deployed.
 
 If you're building a smart contract that uses Superfluid protocol, or even your own [SuperApp](https://docs.superfluid.finance/), then great! This is definitely the place to be.
 
@@ -81,8 +81,9 @@ contract("My Test", accounts => {
             from: admin
         });
     });
+}
 ```
-In order to write concise testing code, we further recommend the use of [`@superfluid-finance/js-sdk`](/packages/js-sdk) not only in your UI code, but also in JS contract tests.
+In order to write concise testing code, we further recommend the use of [`@superfluid-finance/sdk-core`](/packages/sdk-core) not only in your UI code, but also in JS contract tests.
 
 ### Examples
 
@@ -163,53 +164,24 @@ yarn test
 Run a specific test using the [exclusive tests](https://mochajs.org/#exclusive-tests) feature of MochaJS:
 ```sh
 yarn pretest
-npx truffle test test/contracts/agreements/ConstantFlowAgreementV1.test.js
+npx hardhat test test/contracts/agreements/ConstantFlowAgreementV1.test.js
 yarn posttest
 ```
 
 Run the test suite for core contracts:
 ```sh
-yarn pretest
-npx truffle test testsuites/superfluid-core.js
-yarn posttest
+npx hardhat test testsuites/superfluid-core.js
 ```
 
 The `pretest` script starts a ganache instance with deterministic accounts in the background, the `posttest` script stops it.
 When running tests with `yarn test`, those get executed automatically (see [npm docs](https://docs.npmjs.com/cli/v7/using-npm/scripts#pre--post-scripts)).
+> NOTE: You don't need to run the `pretest` and `posttest` scripts when running hardhat tests, but you do when running tests with truffle.
 
 ### TDD Session
 
 When working on the contracts, a test driven approach is recommended.
-In order to facilitate that, you can easily set up a test environment which uses ganache with snapshots for much faster test executions and thus iterations:
-
-First, start ganache configured as needed in a terminal window:
-```sh
-yarn testenv:start
-```
-
-Then open another terminal window and continue there.
-If you're not planning to modify core contracts, set an environment variable:
-```sh
-export TESTENV_SNAPSHOT_VARS=testenv.ignore.vars
-```
-This env variable will be used by the deploy script executed in the next step to persist a resolver address and a ganache snapshot id to the configured file.
-Without this variable set, the protocol contracts will be re-deployed for every new test run, making the process considerably slower.
-Note: if you want to modify core contracts, you **need** to have them re-deployed after every change, thus should **not** set this env variable.
-
-Next, deploy a test environment:
-```sh
-yarn testenv:deploy
-```
-This will deploy the protocol contracts and a Super Token named _TEST_ (which is needed by many test cases).
-If you have set the env `TESTENV_SNAPSHOT_VARS` before, the file it's set to should now exist and look something like this:
-```sh
-$ cat testenv.ignore.vars
-RESOLVER_ADDRESS=0xF12b5dd4EAD5F743C6BaA640B0216200e89B60Da
-TESTENV_EVM_SNAPSHOT_ID=0x1
-```
-
-Next, you should choose the tests relevant for what you're working on using the [only keyword](https://mochajs.org/#exclusive-tests).
-You can put the `only` keyword at any level between whole test suites (`only` appended to a top level `describe`) and individual testcases (`it`).
+You should choose the tests relevant for what you're working on using the [only keyword](https://mochajs.org/#exclusive-tests).
+You can put the `only` keyword at any level between whole test suites (`only` appended to a top level `describe`, e.g. `describe.only`) and individual testcases (`it`, e.g. `it.only`).
 With the testing scope defined, run:
 ```
 yarn dev
@@ -217,14 +189,14 @@ yarn dev
 This has [testsuites/all-contracts.js](testsuites/all-contracts.js) as its entrypoint, but if there's an `only` keyword at any nesting level in any of the tests traversed, only that selected subset of tests will be executed.
 The selected test(s) will run once when starting the session and re-run everytime you save changes in a relevant file.
 
-After finishing the session, you can stop the ganache instance you started in the first step (Ctrl-C).
+After finishing the session, you can stop the hardhat instance you started in the first step (Ctrl-C).
 Also, don't forget to remove `only` keywords from test files before making git commits.
 
-To generate jpeg image charts from the test output run first install these dependencies: numpy , pandas , plotly and kaleido by running:
+To generate jpeg image charts from the test output run first install these dependencies: numpy, pandas, plotly and kaleido by running:
 ```
 python3 -m pip install -U libraryName
 ```
-After that is done , just simply run the testDataToCharts script and put the folder containing the csv files as the first argument e.g
+After that is done, just simply run the testDataToCharts script and put the folder containing the csv files as the first argument e.g
 ```
 python3 testDataToCharts.py output
 ```

package/build/contracts/AccessControl.json

@@ -7906,7 +7906,7 @@
   },
   "networks": {},
   "schemaVersion": "3.4.4",
-  "updatedAt": "2022-03-24T16:33:05.506Z",
+  "updatedAt": "2022-04-07T10:25:44.088Z",
   "devdoc": {
     "details": "Contract module that allows children to implement role-based access control mechanisms. This is a lightweight version that doesn't allow enumerating role members except through off-chain means by accessing the contract event logs. Some applications may benefit from on-chain enumerability, for those cases see {AccessControlEnumerable}. Roles are referred to by their `bytes32` identifier. These should be exposed in the external API and be unique. The best way to achieve this is by using `public constant` hash digests: ``` bytes32 public constant MY_ROLE = keccak256(\"MY_ROLE\"); ``` Roles can be used to represent a set of permissions. To restrict access to a function call, use {hasRole}: ``` function foo() public {     require(hasRole(MY_ROLE, msg.sender));     ... } ``` Roles can be granted and revoked dynamically via the {grantRole} and {revokeRole} functions. Each role has an associated admin role, and only accounts that have a role's admin role can call {grantRole} and {revokeRole}. By default, the admin role for all roles is `DEFAULT_ADMIN_ROLE`, which means that only accounts with this role will be able to grant or revoke other roles. More complex role relationships can be created by using {_setRoleAdmin}. WARNING: The `DEFAULT_ADMIN_ROLE` is also its own admin: it has permission to grant and revoke this role. Extra precautions should be taken to secure accounts that have been granted it.",
     "kind": "dev",

package/build/contracts/AccessControlEnumerable.json

@@ -3223,7 +3223,7 @@
   },
   "networks": {},
   "schemaVersion": "3.4.4",
-  "updatedAt": "2022-03-24T16:33:05.510Z",
+  "updatedAt": "2022-04-07T10:25:44.091Z",
   "devdoc": {
     "details": "Extension of {AccessControl} that allows enumerating the members of each role.",
     "kind": "dev",

package/build/contracts/Address.json

@@ -7923,7 +7923,7 @@
   },
   "networks": {},
   "schemaVersion": "3.4.4",
-  "updatedAt": "2022-03-24T16:33:05.554Z",
+  "updatedAt": "2022-04-07T10:25:44.144Z",
   "devdoc": {
     "details": "Collection of functions related to the address type",
     "kind": "dev",

package/build/contracts/AgreementBase.json

@@ -1470,7 +1470,7 @@
   },
   "networks": {},
   "schemaVersion": "3.4.4",
-  "updatedAt": "2022-03-24T16:33:05.610Z",
+  "updatedAt": "2022-04-07T10:25:44.195Z",
   "devdoc": {
     "author": "Superfluid",
     "kind": "dev",

package/build/contracts/AgreementLibrary.json

@@ -13727,7 +13727,7 @@
   },
   "networks": {},
   "schemaVersion": "3.4.4",
-  "updatedAt": "2022-03-24T16:33:05.611Z",
+  "updatedAt": "2022-04-07T10:25:44.196Z",
   "devdoc": {
     "author": "Superfluid",
     "details": "Helper library for building super agreement",

package/build/contracts/BaseRelayRecipient.json

@@ -1156,7 +1156,7 @@
   },
   "networks": {},
   "schemaVersion": "3.4.4",
-  "updatedAt": "2022-03-24T16:33:06.666Z",
+  "updatedAt": "2022-04-07T10:25:45.171Z",
   "devdoc": {
     "author": "Superfluid",
     "details": "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",

package/build/contracts/BatchLiquidator.json

@@ -7551,7 +7551,7 @@
   },
   "networks": {},
   "schemaVersion": "3.4.4",
-  "updatedAt": "2022-03-24T16:33:06.623Z",
+  "updatedAt": "2022-04-07T10:25:45.130Z",
   "devdoc": {
     "author": "Superfluid",
     "kind": "dev",

package/build/contracts/BatchOperation.json

@@ -10399,7 +10399,7 @@
   },
   "networks": {},
   "schemaVersion": "3.4.4",
-  "updatedAt": "2022-03-24T16:33:05.792Z",
+  "updatedAt": "2022-04-07T10:25:44.372Z",
   "devdoc": {
     "author": "Superfluid",
     "kind": "dev",

package/build/contracts/CFAv1Library.json

@@ -22413,7 +22413,7 @@
   },
   "networks": {},
   "schemaVersion": "3.4.4",
-  "updatedAt": "2022-03-24T16:33:05.732Z",
+  "updatedAt": "2022-04-07T10:25:44.313Z",
   "devdoc": {
     "author": "Superfluid",
     "details": "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()",

package/build/contracts/CallUtils.json

@@ -4929,7 +4929,7 @@
   },
   "networks": {},
   "schemaVersion": "3.4.4",
-  "updatedAt": "2022-03-24T16:33:05.835Z",
+  "updatedAt": "2022-04-07T10:25:44.412Z",
   "devdoc": {
     "author": "Superfluid",
     "kind": "dev",

package/build/contracts/ClosingOnUpdateFlowTestApp.json

@@ -31558,7 +31558,7 @@
   },
   "networks": {},
   "schemaVersion": "3.4.4",
-  "updatedAt": "2022-03-24T16:33:05.863Z",
+  "updatedAt": "2022-04-07T10:25:44.439Z",
   "devdoc": {
     "details": "This is CFA SuperApp that closes an updated flow.",
     "kind": "dev",

package/build/contracts/ConstantFlowAgreementV1.json

@@ -95421,7 +95421,7 @@
   },
   "networks": {},
   "schemaVersion": "3.4.4",
-  "updatedAt": "2022-03-24T16:33:05.618Z",
+  "updatedAt": "2022-04-07T10:25:44.203Z",
   "devdoc": {
     "author": "Superfluid",
     "details": "Please read IConstantFlowAgreementV1 for implementation notes.For more technical notes, please visit protocol-monorepo wiki area.",

package/build/contracts/Context.json

@@ -493,7 +493,7 @@
   },
   "networks": {},
   "schemaVersion": "3.4.4",
-  "updatedAt": "2022-03-24T16:33:05.558Z",
+  "updatedAt": "2022-04-07T10:25:44.148Z",
   "devdoc": {
     "details": "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.",
     "kind": "dev",

package/build/contracts/ContextDefinitions.json

@@ -10399,7 +10399,7 @@
   },
   "networks": {},
   "schemaVersion": "3.4.4",
-  "updatedAt": "2022-03-24T16:33:05.796Z",
+  "updatedAt": "2022-04-07T10:25:44.376Z",
   "devdoc": {
     "author": "Superfluid",
     "kind": "dev",

package/build/contracts/Create2.json

@@ -3231,7 +3231,7 @@
   },
   "networks": {},
   "schemaVersion": "3.4.4",
-  "updatedAt": "2022-03-24T16:33:05.559Z",
+  "updatedAt": "2022-04-07T10:25:44.149Z",
   "devdoc": {
     "details": "Helper to make usage of the `CREATE2` EVM opcode easier and safer. `CREATE2` can be used to compute in advance the address where a smart contract will be deployed, which allows for interesting new mechanisms known as 'counterfactual interactions'. See the https://eips.ethereum.org/EIPS/eip-1014#motivation[EIP] for more information.",
     "kind": "dev",

package/build/contracts/CustomSuperTokenBase.json

@@ -279,7 +279,7 @@
   },
   "networks": {},
   "schemaVersion": "3.4.4",
-  "updatedAt": "2022-03-24T16:33:05.792Z",
+  "updatedAt": "2022-04-07T10:25:44.371Z",
   "devdoc": {
     "author": "Superfluid NOTE: - Because of how solidity lays out its storage variables and how custom   super tokens inherit the SuperToken standard implementation, it is   required that the custom token proxy pads its implementation   with reserved storage used by the Super Token implementation. - You will need to append your own proxy implementation after the base   - Refer to SETH.sol for an example how it is used.",
     "kind": "dev",

package/build/contracts/ERC165.json

@@ -603,7 +603,7 @@
   },
   "networks": {},
   "schemaVersion": "3.4.4",
-  "updatedAt": "2022-03-24T16:33:05.590Z",
+  "updatedAt": "2022-04-07T10:25:44.177Z",
   "devdoc": {
     "details": "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.",
     "kind": "dev",

package/build/contracts/ERC1820Implementer.json

@@ -1887,7 +1887,7 @@
   },
   "networks": {},
   "schemaVersion": "3.4.4",
-  "updatedAt": "2022-03-24T16:33:05.590Z",
+  "updatedAt": "2022-04-07T10:25:44.177Z",
   "devdoc": {
     "details": "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.",
     "kind": "dev",

package/build/contracts/ERC20.json

@@ -20792,7 +20792,7 @@
   },
   "networks": {},
   "schemaVersion": "3.4.4",
-  "updatedAt": "2022-03-24T16:33:05.517Z",
+  "updatedAt": "2022-04-07T10:25:44.098Z",
   "devdoc": {
     "details": "Implementation of the {IERC20} interface. This implementation is agnostic to the way tokens are created. This means that a supply mechanism has to be added in a derived contract using {_mint}. For a generic mechanism see {ERC20PresetMinterPauser}. TIP: For a detailed writeup see our guide https://forum.zeppelin.solutions/t/how-to-implement-erc20-supply-mechanisms/226[How to implement supply mechanisms]. We have followed general OpenZeppelin Contracts guidelines: functions revert instead returning `false` on failure. This behavior is nonetheless conventional and does not conflict with the expectations of ERC20 applications. Additionally, an {Approval} event is emitted on calls to {transferFrom}. This allows applications to reconstruct the allowance for all accounts just by listening to said events. Other implementations of the EIP may not emit these events, as it isn't required by the specification. Finally, the non-standard {decreaseAllowance} and {increaseAllowance} functions have been added to mitigate the well-known issues around setting allowances. See {IERC20-approve}.",
     "kind": "dev",

package/build/contracts/ERC20WithTokenInfo.json

@@ -506,7 +506,7 @@
   },
   "networks": {},
   "schemaVersion": "3.4.4",
-  "updatedAt": "2022-03-24T16:33:05.827Z",
+  "updatedAt": "2022-04-07T10:25:44.405Z",
   "devdoc": {
     "author": "Superfluid",
     "details": "Using abstract contract instead of interfaces because old solidity      does not support interface inheriting other interfaces solhint-disable-next-line no-empty-blocks",

package/build/contracts/ERC721.json

@@ -33164,7 +33164,7 @@
   },
   "networks": {},
   "schemaVersion": "3.4.4",
-  "updatedAt": "2022-03-24T16:33:05.532Z",
+  "updatedAt": "2022-04-07T10:25:44.123Z",
   "devdoc": {
     "details": "Implementation of https://eips.ethereum.org/EIPS/eip-721[ERC721] Non-Fungible Token Standard, including the Metadata extension, but not including the Enumerable extension, which is available separately as {ERC721Enumerable}.",
     "kind": "dev",

package/build/contracts/ERC777Helper.json

@@ -6243,7 +6243,7 @@
   },
   "networks": {},
   "schemaVersion": "3.4.4",
-  "updatedAt": "2022-03-24T16:33:05.837Z",
+  "updatedAt": "2022-04-07T10:25:44.415Z",
   "devdoc": {
     "author": "Superfluid",
     "kind": "dev",

package/build/contracts/ERC777RecipientDrainingGas.json

@@ -17678,7 +17678,7 @@
   },
   "networks": {},
   "schemaVersion": "3.4.4",
-  "updatedAt": "2022-03-24T16:33:06.006Z",
+  "updatedAt": "2022-04-07T10:25:44.567Z",
   "devdoc": {
     "kind": "dev",
     "methods": {},

package/build/contracts/ERC777RecipientReverting.json

@@ -17787,7 +17787,7 @@
   },
   "networks": {},
   "schemaVersion": "3.4.4",
-  "updatedAt": "2022-03-24T16:33:06.013Z",
+  "updatedAt": "2022-04-07T10:25:44.573Z",
   "devdoc": {
     "kind": "dev",
     "methods": {},

package/build/contracts/EnumerableSet.json

@@ -14101,7 +14101,7 @@
   },
   "networks": {},
   "schemaVersion": "3.4.4",
-  "updatedAt": "2022-03-24T16:33:05.603Z",
+  "updatedAt": "2022-04-07T10:25:44.189Z",
   "devdoc": {
     "details": "Library for managing https://en.wikipedia.org/wiki/Set_(abstract_data_type)[sets] of primitive types. Sets have the following properties: - Elements are added, removed, and checked for existence in constant time (O(1)). - Elements are enumerated in O(n). No guarantees are made on the ordering. ``` contract Example {     // Add the library methods     using EnumerableSet for EnumerableSet.AddressSet;     // 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.",
     "kind": "dev",

package/build/contracts/ExclusiveInflowTestApp.json

@@ -31712,7 +31712,7 @@
   },
   "networks": {},
   "schemaVersion": "3.4.4",
-  "updatedAt": "2022-03-24T16:33:05.876Z",
+  "updatedAt": "2022-04-07T10:25:44.451Z",
   "devdoc": {
     "details": "This is a CFA SuperApp that maintains at most one inflow from a sender at any moment. This can test the deposit allowance logic in the deleteFlow as a recipient.",
     "kind": "dev",

package/build/contracts/FixedSizeData.json

@@ -3659,7 +3659,7 @@
   },
   "networks": {},
   "schemaVersion": "3.4.4",
-  "updatedAt": "2022-03-24T16:33:05.840Z",
+  "updatedAt": "2022-04-07T10:25:44.418Z",
   "devdoc": {
     "author": "Superfluid  When using solidity dynamic array, first word is used to store the length of the array. For use cases that the length doesn't change, it is better to use a fixed size data premitive. To use this library: - The pointer to the storage is `slot`, the user could use `keccak256(abi.encode(...))`   scheme to create collision-free slot ID for locating the data. - To load data, or erase data and get all gas refund, data length is always required.",
     "kind": "dev",

package/build/contracts/FlowExchangeTestApp.json

@@ -32343,7 +32343,7 @@
   },
   "networks": {},
   "schemaVersion": "3.4.4",
-  "updatedAt": "2022-03-24T16:33:05.892Z",
+  "updatedAt": "2022-04-07T10:25:44.466Z",
   "devdoc": {
     "kind": "dev",
     "methods": {},

package/build/contracts/FullUpgradableSuperTokenProxy.json

@@ -2811,7 +2811,7 @@
   },
   "networks": {},
   "schemaVersion": "3.4.4",
-  "updatedAt": "2022-03-24T16:33:06.610Z",
+  "updatedAt": "2022-04-07T10:25:45.118Z",
   "devdoc": {
     "author": "Superfluid",
     "kind": "dev",

package/build/contracts/IAccessControl.json

@@ -1882,7 +1882,7 @@
   },
   "networks": {},
   "schemaVersion": "3.4.4",
-  "updatedAt": "2022-03-24T16:33:05.512Z",
+  "updatedAt": "2022-04-07T10:25:44.093Z",
   "devdoc": {
     "details": "External interface of AccessControl declared to support ERC165 detection.",
     "events": {

package/build/contracts/IAccessControlEnumerable.json

@@ -805,7 +805,7 @@
   },
   "networks": {},
   "schemaVersion": "3.4.4",
-  "updatedAt": "2022-03-24T16:33:05.513Z",
+  "updatedAt": "2022-04-07T10:25:44.094Z",
   "devdoc": {
     "details": "External interface of AccessControlEnumerable declared to support ERC165 detection.",
     "kind": "dev",

package/build/contracts/IConstantFlowAgreementV1.json

@@ -5137,7 +5137,7 @@
   },
   "networks": {},
   "schemaVersion": "3.4.4",
-  "updatedAt": "2022-03-24T16:33:05.784Z",
+  "updatedAt": "2022-04-07T10:25:44.364Z",
   "devdoc": {
     "author": "Superfluid",
     "events": {

package/build/contracts/IDAv1Library.json

@@ -35541,7 +35541,7 @@
   },
   "networks": {},
   "schemaVersion": "3.4.4",
-  "updatedAt": "2022-03-24T16:33:05.744Z",
+  "updatedAt": "2022-04-07T10:25:44.324Z",
   "devdoc": {
     "author": "Superfluid",
     "details": "Set a variable of type `InitData` in the contract, then call this library's functions directly `initData.functionName()`.",

package/build/contracts/IERC165.json

@@ -317,7 +317,7 @@
   },
   "networks": {},
   "schemaVersion": "3.4.4",
-  "updatedAt": "2022-03-24T16:33:05.591Z",
+  "updatedAt": "2022-04-07T10:25:44.178Z",
   "devdoc": {
     "details": "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}.",
     "kind": "dev",

package/build/contracts/IERC1820Implementer.json

@@ -378,7 +378,7 @@
   },
   "networks": {},
   "schemaVersion": "3.4.4",
-  "updatedAt": "2022-03-24T16:33:05.592Z",
+  "updatedAt": "2022-04-07T10:25:44.179Z",
   "devdoc": {
     "details": "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}.",
     "kind": "dev",

package/build/contracts/IERC1820Registry.json

@@ -2341,7 +2341,7 @@
   },
   "networks": {},
   "schemaVersion": "3.4.4",
-  "updatedAt": "2022-03-24T16:33:05.592Z",
+  "updatedAt": "2022-04-07T10:25:44.179Z",
   "devdoc": {
     "details": "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.",
     "kind": "dev",

package/build/contracts/IERC20.json

@@ -2031,7 +2031,7 @@
   },
   "networks": {},
   "schemaVersion": "3.4.4",
-  "updatedAt": "2022-03-24T16:33:05.526Z",
+  "updatedAt": "2022-04-07T10:25:44.118Z",
   "devdoc": {
     "details": "Interface of the ERC20 standard as defined in the EIP.",
     "events": {

package/build/contracts/IERC20Metadata.json

@@ -766,7 +766,7 @@
   },
   "networks": {},
   "schemaVersion": "3.4.4",
-  "updatedAt": "2022-03-24T16:33:05.528Z",
+  "updatedAt": "2022-04-07T10:25:44.119Z",
   "devdoc": {
     "details": "Interface for the optional metadata functions from the ERC20 standard. _Available since v4.1._",
     "kind": "dev",

package/build/contracts/IERC721.json

@@ -2999,7 +2999,7 @@
   },
   "networks": {},
   "schemaVersion": "3.4.4",
-  "updatedAt": "2022-03-24T16:33:05.547Z",
+  "updatedAt": "2022-04-07T10:25:44.138Z",
   "devdoc": {
     "details": "Required interface of an ERC721 compliant contract.",
     "events": {

package/build/contracts/IERC721Metadata.json

@@ -938,7 +938,7 @@
   },
   "networks": {},
   "schemaVersion": "3.4.4",
-  "updatedAt": "2022-03-24T16:33:05.550Z",
+  "updatedAt": "2022-04-07T10:25:44.141Z",
   "devdoc": {
     "details": "See https://eips.ethereum.org/EIPS/eip-721",
     "kind": "dev",

package/build/contracts/IERC721Receiver.json

@@ -498,7 +498,7 @@
   },
   "networks": {},
   "schemaVersion": "3.4.4",
-  "updatedAt": "2022-03-24T16:33:05.549Z",
+  "updatedAt": "2022-04-07T10:25:44.140Z",
   "devdoc": {
     "details": "Interface for any contract that wants to support safeTransfers from ERC721 asset contracts.",
     "kind": "dev",

package/build/contracts/IERC777.json

@@ -4143,7 +4143,7 @@
   },
   "networks": {},
   "schemaVersion": "3.4.4",
-  "updatedAt": "2022-03-24T16:33:05.551Z",
+  "updatedAt": "2022-04-07T10:25:44.141Z",
   "devdoc": {
     "details": "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}.",
     "kind": "dev",

package/build/contracts/IERC777Recipient.json

@@ -556,7 +556,7 @@
   },
   "networks": {},
   "schemaVersion": "3.4.4",
-  "updatedAt": "2022-03-24T16:33:05.553Z",
+  "updatedAt": "2022-04-07T10:25:44.143Z",
   "devdoc": {
     "details": "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}.",
     "kind": "dev",

package/build/contracts/IERC777Sender.json

@@ -556,7 +556,7 @@
   },
   "networks": {},
   "schemaVersion": "3.4.4",
-  "updatedAt": "2022-03-24T16:33:05.553Z",
+  "updatedAt": "2022-04-07T10:25:44.144Z",
   "devdoc": {
     "details": "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}.",
     "kind": "dev",

package/build/contracts/IInstantDistributionAgreementV1.json

@@ -10332,7 +10332,7 @@
   },
   "networks": {},
   "schemaVersion": "3.4.4",
-  "updatedAt": "2022-03-24T16:33:05.787Z",
+  "updatedAt": "2022-04-07T10:25:44.366Z",
   "devdoc": {
     "author": "Superfluid Notes:   - A publisher can create as many as indices as possibly identifiable with `indexId`.     - `indexId` is deliberately limited to 32 bits, to avoid the chance for sha-3 collision.       Despite knowing sha-3 collision is only theoretical.   - A publisher can create a subscription to an index for any subscriber.   - A subscription consists of:     - The index it subscribes to.     - Number of units subscribed.   - An index consists of:     - Current value as `uint128 indexValue`.     - Total units of the approved subscriptions as `uint128 totalUnitsApproved`.     - Total units of the non approved subscription as `uint128 totalUnitsPending`.   - A publisher can update an index with a new value that doesn't decrease.   - A publisher can update a subscription with any number of units.   - A publisher or a subscriber can delete a subscription and reset its units to zero.   - A subscriber must approve the index in order to receive distributions from the publisher     each time the index is updated.     - The amount distributed is $$\\Delta{index} * units$$   - Distributions to a non approved subscription stays in the publisher's deposit until:     - the subscriber approves the subscription (side effect),     - the publisher updates the subscription (side effect),     - the subscriber deletes the subscription even if it is never approved (side effect),     - or the subscriber can explicitly claim them.",
     "events": {

package/build/contracts/IMaticBridgedNativeSuperToken.json

@@ -2446,7 +2446,7 @@
   },
   "networks": {},
   "schemaVersion": "3.4.4",
-  "updatedAt": "2022-03-24T16:33:05.828Z",
+  "updatedAt": "2022-04-07T10:25:44.406Z",
   "devdoc": {
     "author": "Superfluid",
     "details": "Matic Bridged Native SuperToken full interface",

package/build/contracts/IMaticBridgedNativeSuperTokenCustom.json

@@ -877,7 +877,7 @@
   },
   "networks": {},
   "schemaVersion": "3.4.4",
-  "updatedAt": "2022-03-24T16:33:05.829Z",
+  "updatedAt": "2022-04-07T10:25:44.407Z",
   "devdoc": {
     "author": "Superfluid",
     "details": "Functionality specific for Matic Bridged Native Super Tokens",

package/build/contracts/IMultiSigWallet.json

@@ -425,7 +425,7 @@
   },
   "networks": {},
   "schemaVersion": "3.4.4",
-  "updatedAt": "2022-03-24T16:33:05.791Z",
+  "updatedAt": "2022-04-07T10:25:44.371Z",
   "devdoc": {
     "author": "Superfluid",
     "kind": "dev",