@superfluid-finance/ethereum-contracts 1.2.2 → 1.2.3-dev.c960cdd.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/build/contracts/AccessControl.json +1 -1
- package/build/contracts/AccessControlEnumerable.json +1 -1
- package/build/contracts/Address.json +1 -1
- package/build/contracts/AgreementBase.json +1 -1
- package/build/contracts/AgreementLibrary.json +1 -1
- package/build/contracts/BaseRelayRecipient.json +1 -1
- package/build/contracts/BatchLiquidator.json +1 -1
- package/build/contracts/BatchOperation.json +1 -1
- package/build/contracts/CFAv1Library.json +1 -1
- package/build/contracts/CallUtils.json +1 -1
- package/build/contracts/ClosingOnUpdateFlowTestApp.json +1 -1
- package/build/contracts/ConstantFlowAgreementV1.json +1 -1
- package/build/contracts/Context.json +1 -1
- package/build/contracts/ContextDefinitions.json +1 -1
- package/build/contracts/Create2.json +1 -1
- package/build/contracts/CustomSuperTokenBase.json +1 -1
- package/build/contracts/ERC165.json +1 -1
- package/build/contracts/ERC1820Implementer.json +1 -1
- package/build/contracts/ERC1820RegistryCompiled.json +1 -1
- package/build/contracts/ERC20.json +1 -1
- package/build/contracts/ERC20Burnable.json +1 -1
- package/build/contracts/ERC20Pausable.json +1 -1
- package/build/contracts/ERC20PresetMinterPauser.json +1 -1
- package/build/contracts/ERC20WithTokenInfo.json +1 -1
- package/build/contracts/ERC721.json +1 -1
- package/build/contracts/ERC777Helper.json +1 -1
- package/build/contracts/ERC777RecipientDrainingGas.json +1 -1
- package/build/contracts/ERC777RecipientReverting.json +1 -1
- package/build/contracts/EnumerableSet.json +1 -1
- package/build/contracts/ExclusiveInflowTestApp.json +1 -1
- package/build/contracts/FixedSizeData.json +1 -1
- package/build/contracts/FlowExchangeTestApp.json +1 -1
- package/build/contracts/FlowOperatorDefinitions.json +1 -1
- package/build/contracts/FullUpgradableSuperTokenProxy.json +1 -1
- package/build/contracts/IAccessControl.json +1 -1
- package/build/contracts/IAccessControlEnumerable.json +1 -1
- package/build/contracts/IConstantFlowAgreementV1.json +1 -1
- package/build/contracts/IDAv1Library.json +1 -1
- package/build/contracts/IERC165.json +1 -1
- package/build/contracts/IERC1820Implementer.json +1 -1
- package/build/contracts/IERC1820Registry.json +1 -1
- package/build/contracts/IERC20.json +1 -1
- package/build/contracts/IERC20Metadata.json +1 -1
- package/build/contracts/IERC721.json +1 -1
- package/build/contracts/IERC721Metadata.json +1 -1
- package/build/contracts/IERC721Receiver.json +1 -1
- package/build/contracts/IERC777.json +1 -1
- package/build/contracts/IERC777Recipient.json +1 -1
- package/build/contracts/IERC777Sender.json +1 -1
- package/build/contracts/IInstantDistributionAgreementV1.json +1 -1
- package/build/contracts/IMaticBridgedNativeSuperToken.json +1 -1
- package/build/contracts/IMaticBridgedNativeSuperTokenCustom.json +1 -1
- package/build/contracts/IMultiSigWallet.json +1 -1
- package/build/contracts/IPureSuperToken.json +1 -1
- package/build/contracts/IPureSuperTokenCustom.json +1 -1
- package/build/contracts/IRelayRecipient.json +1 -1
- package/build/contracts/IResolver.json +1 -1
- package/build/contracts/ISETH.json +1 -1
- package/build/contracts/ISETHCustom.json +1 -1
- package/build/contracts/ISuperAgreement.json +1 -1
- package/build/contracts/ISuperApp.json +1 -1
- package/build/contracts/ISuperToken.json +1 -1
- package/build/contracts/ISuperTokenFactory.json +1 -1
- package/build/contracts/ISuperfluid.json +1 -1
- package/build/contracts/ISuperfluidGovernance.json +1 -1
- package/build/contracts/ISuperfluidToken.json +1 -1
- package/build/contracts/ITOGAv1.json +1 -1
- package/build/contracts/ITOGAv2.json +1 -1
- package/build/contracts/Initializable.json +1 -1
- package/build/contracts/InstantDistributionAgreementV1.json +1 -1
- package/build/contracts/Int96SafeMath.json +1 -1
- package/build/contracts/MaticBridgedNativeSuperTokenProxy.json +1 -1
- package/build/contracts/NonClosableOutflowTestApp.json +1 -1
- package/build/contracts/Ownable.json +1 -1
- package/build/contracts/Pausable.json +1 -1
- package/build/contracts/Proxy.json +1 -1
- package/build/contracts/PureSuperToken.json +1 -1
- package/build/contracts/Resolver.json +1 -1
- package/build/contracts/SETHProxy.json +1 -1
- package/build/contracts/SafeCast.json +1 -1
- package/build/contracts/SafeERC20.json +1 -1
- package/build/contracts/SafeMath.json +1 -1
- package/build/contracts/SelfDeletingFlowTestApp.json +1 -1
- package/build/contracts/SlotsBitmapLibrary.json +1 -1
- package/build/contracts/Strings.json +1 -1
- package/build/contracts/SuperAppBase.json +1 -1
- package/build/contracts/SuperAppDefinitions.json +1 -1
- package/build/contracts/SuperToken.json +1 -1
- package/build/contracts/SuperTokenFactory.json +1 -1
- package/build/contracts/SuperTokenFactoryBase.json +1 -1
- package/build/contracts/SuperTokenFactoryHelper.json +1 -1
- package/build/contracts/SuperUpgrader.json +1 -1
- package/build/contracts/Superfluid.json +1 -1
- package/build/contracts/SuperfluidFrameworkDeployer.json +1 -1
- package/build/contracts/SuperfluidGovernanceBase.json +1 -1
- package/build/contracts/SuperfluidGovernanceConfigs.json +1 -1
- package/build/contracts/SuperfluidGovernanceII.json +1 -1
- package/build/contracts/SuperfluidGovernanceIIProxy.json +1 -1
- package/build/contracts/SuperfluidLoader.json +1 -1
- package/build/contracts/SuperfluidToken.json +1 -1
- package/build/contracts/TOGA.json +1 -1
- package/build/contracts/TestGovernance.json +1 -1
- package/build/contracts/TestToken.json +1 -1
- package/build/contracts/TokenCustodian.json +1 -1
- package/build/contracts/TokenInfo.json +1 -1
- package/build/contracts/UInt128SafeMath.json +1 -1
- package/build/contracts/UUPSProxiable.json +1 -1
- package/build/contracts/UUPSProxy.json +1 -1
- package/build/contracts/UUPSUtils.json +1 -1
- package/package.json +2 -2
|
@@ -4064,7 +4064,7 @@
|
|
|
4064
4064
|
},
|
|
4065
4065
|
"networks": {},
|
|
4066
4066
|
"schemaVersion": "3.4.7",
|
|
4067
|
-
"updatedAt": "2022-05-
|
|
4067
|
+
"updatedAt": "2022-05-09T18:30:11.498Z",
|
|
4068
4068
|
"devdoc": {
|
|
4069
4069
|
"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.",
|
|
4070
4070
|
"kind": "dev",
|
|
@@ -1744,7 +1744,7 @@
|
|
|
1744
1744
|
},
|
|
1745
1745
|
"networks": {},
|
|
1746
1746
|
"schemaVersion": "3.4.7",
|
|
1747
|
-
"updatedAt": "2022-05-
|
|
1747
|
+
"updatedAt": "2022-05-09T18:30:11.500Z",
|
|
1748
1748
|
"devdoc": {
|
|
1749
1749
|
"details": "Extension of {AccessControl} that allows enumerating the members of each role.",
|
|
1750
1750
|
"kind": "dev",
|
|
@@ -3970,7 +3970,7 @@
|
|
|
3970
3970
|
},
|
|
3971
3971
|
"networks": {},
|
|
3972
3972
|
"schemaVersion": "3.4.7",
|
|
3973
|
-
"updatedAt": "2022-05-
|
|
3973
|
+
"updatedAt": "2022-05-09T18:30:11.539Z",
|
|
3974
3974
|
"devdoc": {
|
|
3975
3975
|
"details": "Collection of functions related to the address type",
|
|
3976
3976
|
"kind": "dev",
|
|
@@ -7122,7 +7122,7 @@
|
|
|
7122
7122
|
},
|
|
7123
7123
|
"networks": {},
|
|
7124
7124
|
"schemaVersion": "3.4.7",
|
|
7125
|
-
"updatedAt": "2022-05-
|
|
7125
|
+
"updatedAt": "2022-05-09T18:30:11.553Z",
|
|
7126
7126
|
"devdoc": {
|
|
7127
7127
|
"author": "Superfluid",
|
|
7128
7128
|
"details": "Helper library for building super agreement",
|
|
@@ -603,7 +603,7 @@
|
|
|
603
603
|
},
|
|
604
604
|
"networks": {},
|
|
605
605
|
"schemaVersion": "3.4.7",
|
|
606
|
-
"updatedAt": "2022-05-
|
|
606
|
+
"updatedAt": "2022-05-09T18:30:11.673Z",
|
|
607
607
|
"devdoc": {
|
|
608
608
|
"author": "Superfluid",
|
|
609
609
|
"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",
|
|
@@ -11215,7 +11215,7 @@
|
|
|
11215
11215
|
},
|
|
11216
11216
|
"networks": {},
|
|
11217
11217
|
"schemaVersion": "3.4.7",
|
|
11218
|
-
"updatedAt": "2022-05-
|
|
11218
|
+
"updatedAt": "2022-05-09T18:30:11.618Z",
|
|
11219
11219
|
"devdoc": {
|
|
11220
11220
|
"author": "Superfluid",
|
|
11221
11221
|
"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()",
|
|
@@ -20287,7 +20287,7 @@
|
|
|
20287
20287
|
},
|
|
20288
20288
|
"networks": {},
|
|
20289
20289
|
"schemaVersion": "3.4.7",
|
|
20290
|
-
"updatedAt": "2022-05-
|
|
20290
|
+
"updatedAt": "2022-05-09T18:30:11.694Z",
|
|
20291
20291
|
"devdoc": {
|
|
20292
20292
|
"details": "This is CFA SuperApp that closes an updated flow.",
|
|
20293
20293
|
"kind": "dev",
|
|
@@ -79814,7 +79814,7 @@
|
|
|
79814
79814
|
},
|
|
79815
79815
|
"networks": {},
|
|
79816
79816
|
"schemaVersion": "3.4.7",
|
|
79817
|
-
"updatedAt": "2022-05-
|
|
79817
|
+
"updatedAt": "2022-05-09T18:30:11.556Z",
|
|
79818
79818
|
"devdoc": {
|
|
79819
79819
|
"author": "Superfluid",
|
|
79820
79820
|
"details": "Please read IConstantFlowAgreementV1 for implementation notes.For more technical notes, please visit protocol-monorepo wiki area.",
|
|
@@ -255,7 +255,7 @@
|
|
|
255
255
|
},
|
|
256
256
|
"networks": {},
|
|
257
257
|
"schemaVersion": "3.4.7",
|
|
258
|
-
"updatedAt": "2022-05-
|
|
258
|
+
"updatedAt": "2022-05-09T18:30:11.541Z",
|
|
259
259
|
"devdoc": {
|
|
260
260
|
"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.",
|
|
261
261
|
"kind": "dev",
|
|
@@ -1624,7 +1624,7 @@
|
|
|
1624
1624
|
},
|
|
1625
1625
|
"networks": {},
|
|
1626
1626
|
"schemaVersion": "3.4.7",
|
|
1627
|
-
"updatedAt": "2022-05-
|
|
1627
|
+
"updatedAt": "2022-05-09T18:30:11.541Z",
|
|
1628
1628
|
"devdoc": {
|
|
1629
1629
|
"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.",
|
|
1630
1630
|
"kind": "dev",
|
|
@@ -148,7 +148,7 @@
|
|
|
148
148
|
},
|
|
149
149
|
"networks": {},
|
|
150
150
|
"schemaVersion": "3.4.7",
|
|
151
|
-
"updatedAt": "2022-05-
|
|
151
|
+
"updatedAt": "2022-05-09T18:30:11.646Z",
|
|
152
152
|
"devdoc": {
|
|
153
153
|
"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.",
|
|
154
154
|
"kind": "dev",
|
|
@@ -320,7 +320,7 @@
|
|
|
320
320
|
},
|
|
321
321
|
"networks": {},
|
|
322
322
|
"schemaVersion": "3.4.7",
|
|
323
|
-
"updatedAt": "2022-05-
|
|
323
|
+
"updatedAt": "2022-05-09T18:30:11.543Z",
|
|
324
324
|
"devdoc": {
|
|
325
325
|
"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.",
|
|
326
326
|
"kind": "dev",
|
|
@@ -1185,7 +1185,7 @@
|
|
|
1185
1185
|
},
|
|
1186
1186
|
"networks": {},
|
|
1187
1187
|
"schemaVersion": "3.4.7",
|
|
1188
|
-
"updatedAt": "2022-05-
|
|
1188
|
+
"updatedAt": "2022-05-09T18:30:11.544Z",
|
|
1189
1189
|
"devdoc": {
|
|
1190
1190
|
"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.",
|
|
1191
1191
|
"kind": "dev",
|
|
@@ -241,7 +241,7 @@
|
|
|
241
241
|
},
|
|
242
242
|
"networks": {},
|
|
243
243
|
"schemaVersion": "3.4.7",
|
|
244
|
-
"updatedAt": "2022-05-
|
|
244
|
+
"updatedAt": "2022-05-09T18:30:11.675Z",
|
|
245
245
|
"devdoc": {
|
|
246
246
|
"details": "This is meant to be used by test framework to get the raw bytecode without compiling the origin contract",
|
|
247
247
|
"kind": "dev",
|
|
@@ -13401,7 +13401,7 @@
|
|
|
13401
13401
|
},
|
|
13402
13402
|
"networks": {},
|
|
13403
13403
|
"schemaVersion": "3.4.7",
|
|
13404
|
-
"updatedAt": "2022-05-
|
|
13404
|
+
"updatedAt": "2022-05-09T18:30:11.505Z",
|
|
13405
13405
|
"devdoc": {
|
|
13406
13406
|
"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}.",
|
|
13407
13407
|
"kind": "dev",
|
|
@@ -858,7 +858,7 @@
|
|
|
858
858
|
},
|
|
859
859
|
"networks": {},
|
|
860
860
|
"schemaVersion": "3.4.7",
|
|
861
|
-
"updatedAt": "2022-05-
|
|
861
|
+
"updatedAt": "2022-05-09T18:30:11.510Z",
|
|
862
862
|
"devdoc": {
|
|
863
863
|
"details": "Extension of {ERC20} that allows token holders to destroy both their own tokens and those that they have an allowance for, in a way that can be recognized off-chain (via event analysis).",
|
|
864
864
|
"kind": "dev",
|
|
@@ -788,7 +788,7 @@
|
|
|
788
788
|
},
|
|
789
789
|
"networks": {},
|
|
790
790
|
"schemaVersion": "3.4.7",
|
|
791
|
-
"updatedAt": "2022-05-
|
|
791
|
+
"updatedAt": "2022-05-09T18:30:11.511Z",
|
|
792
792
|
"devdoc": {
|
|
793
793
|
"details": "ERC20 token with pausable token transfers, minting and burning. Useful for scenarios such as preventing trades until the end of an evaluation period, or having an emergency switch for freezing all token transfers in the event of a large bug.",
|
|
794
794
|
"kind": "dev",
|
|
@@ -12786,7 +12786,7 @@
|
|
|
12786
12786
|
},
|
|
12787
12787
|
"networks": {},
|
|
12788
12788
|
"schemaVersion": "3.4.7",
|
|
12789
|
-
"updatedAt": "2022-05-
|
|
12789
|
+
"updatedAt": "2022-05-09T18:30:11.512Z",
|
|
12790
12790
|
"devdoc": {
|
|
12791
12791
|
"details": "{ERC20} token, including: - ability for holders to burn (destroy) their tokens - a minter role that allows for token minting (creation) - a pauser role that allows to stop all token transfers This contract uses {AccessControl} to lock permissioned functions using the different roles - head to its documentation for details. The account that deploys the contract will be granted the minter and pauser roles, as well as the default admin role, which will let it grant both minter and pauser roles to other accounts. _Deprecated in favor of https://wizard.openzeppelin.com/[Contracts Wizard]._",
|
|
12792
12792
|
"kind": "dev",
|
|
@@ -373,7 +373,7 @@
|
|
|
373
373
|
},
|
|
374
374
|
"networks": {},
|
|
375
375
|
"schemaVersion": "3.4.7",
|
|
376
|
-
"updatedAt": "2022-05-
|
|
376
|
+
"updatedAt": "2022-05-09T18:30:11.668Z",
|
|
377
377
|
"devdoc": {
|
|
378
378
|
"author": "Superfluid",
|
|
379
379
|
"details": "Using abstract contract instead of interfaces because old solidity does not support interface inheriting other interfaces solhint-disable-next-line no-empty-blocks",
|
|
@@ -21955,7 +21955,7 @@
|
|
|
21955
21955
|
},
|
|
21956
21956
|
"networks": {},
|
|
21957
21957
|
"schemaVersion": "3.4.7",
|
|
21958
|
-
"updatedAt": "2022-05-
|
|
21958
|
+
"updatedAt": "2022-05-09T18:30:11.519Z",
|
|
21959
21959
|
"devdoc": {
|
|
21960
21960
|
"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}.",
|
|
21961
21961
|
"kind": "dev",
|
|
@@ -7059,7 +7059,7 @@
|
|
|
7059
7059
|
},
|
|
7060
7060
|
"networks": {},
|
|
7061
7061
|
"schemaVersion": "3.4.7",
|
|
7062
|
-
"updatedAt": "2022-05-
|
|
7062
|
+
"updatedAt": "2022-05-09T18:30:11.550Z",
|
|
7063
7063
|
"devdoc": {
|
|
7064
7064
|
"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.",
|
|
7065
7065
|
"kind": "dev",
|
|
@@ -20441,7 +20441,7 @@
|
|
|
20441
20441
|
},
|
|
20442
20442
|
"networks": {},
|
|
20443
20443
|
"schemaVersion": "3.4.7",
|
|
20444
|
-
"updatedAt": "2022-05-
|
|
20444
|
+
"updatedAt": "2022-05-09T18:30:11.702Z",
|
|
20445
20445
|
"devdoc": {
|
|
20446
20446
|
"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.",
|
|
20447
20447
|
"kind": "dev",
|
|
@@ -1838,7 +1838,7 @@
|
|
|
1838
1838
|
},
|
|
1839
1839
|
"networks": {},
|
|
1840
1840
|
"schemaVersion": "3.4.7",
|
|
1841
|
-
"updatedAt": "2022-05-
|
|
1841
|
+
"updatedAt": "2022-05-09T18:30:11.677Z",
|
|
1842
1842
|
"devdoc": {
|
|
1843
1843
|
"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.",
|
|
1844
1844
|
"kind": "dev",
|
|
@@ -21072,7 +21072,7 @@
|
|
|
21072
21072
|
},
|
|
21073
21073
|
"networks": {},
|
|
21074
21074
|
"schemaVersion": "3.4.7",
|
|
21075
|
-
"updatedAt": "2022-05-
|
|
21075
|
+
"updatedAt": "2022-05-09T18:30:11.709Z",
|
|
21076
21076
|
"devdoc": {
|
|
21077
21077
|
"kind": "dev",
|
|
21078
21078
|
"methods": {},
|
|
@@ -1036,7 +1036,7 @@
|
|
|
1036
1036
|
},
|
|
1037
1037
|
"networks": {},
|
|
1038
1038
|
"schemaVersion": "3.4.7",
|
|
1039
|
-
"updatedAt": "2022-05-
|
|
1039
|
+
"updatedAt": "2022-05-09T18:30:11.501Z",
|
|
1040
1040
|
"devdoc": {
|
|
1041
1041
|
"details": "External interface of AccessControl declared to support ERC165 detection.",
|
|
1042
1042
|
"events": {
|
|
@@ -519,7 +519,7 @@
|
|
|
519
519
|
},
|
|
520
520
|
"networks": {},
|
|
521
521
|
"schemaVersion": "3.4.7",
|
|
522
|
-
"updatedAt": "2022-05-
|
|
522
|
+
"updatedAt": "2022-05-09T18:30:11.502Z",
|
|
523
523
|
"devdoc": {
|
|
524
524
|
"details": "External interface of AccessControlEnumerable declared to support ERC165 detection.",
|
|
525
525
|
"kind": "dev",
|
|
@@ -17779,7 +17779,7 @@
|
|
|
17779
17779
|
},
|
|
17780
17780
|
"networks": {},
|
|
17781
17781
|
"schemaVersion": "3.4.7",
|
|
17782
|
-
"updatedAt": "2022-05-
|
|
17782
|
+
"updatedAt": "2022-05-09T18:30:11.623Z",
|
|
17783
17783
|
"devdoc": {
|
|
17784
17784
|
"author": "Superfluid",
|
|
17785
17785
|
"details": "Set a variable of type `InitData` in the contract, then call this library's functions directly `initData.functionName()`.",
|
|
@@ -177,7 +177,7 @@
|
|
|
177
177
|
},
|
|
178
178
|
"networks": {},
|
|
179
179
|
"schemaVersion": "3.4.7",
|
|
180
|
-
"updatedAt": "2022-05-
|
|
180
|
+
"updatedAt": "2022-05-09T18:30:11.545Z",
|
|
181
181
|
"devdoc": {
|
|
182
182
|
"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}.",
|
|
183
183
|
"kind": "dev",
|
|
@@ -210,7 +210,7 @@
|
|
|
210
210
|
},
|
|
211
211
|
"networks": {},
|
|
212
212
|
"schemaVersion": "3.4.7",
|
|
213
|
-
"updatedAt": "2022-05-
|
|
213
|
+
"updatedAt": "2022-05-09T18:30:11.545Z",
|
|
214
214
|
"devdoc": {
|
|
215
215
|
"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}.",
|
|
216
216
|
"kind": "dev",
|
|
@@ -1286,7 +1286,7 @@
|
|
|
1286
1286
|
},
|
|
1287
1287
|
"networks": {},
|
|
1288
1288
|
"schemaVersion": "3.4.7",
|
|
1289
|
-
"updatedAt": "2022-05-
|
|
1289
|
+
"updatedAt": "2022-05-09T18:30:11.545Z",
|
|
1290
1290
|
"devdoc": {
|
|
1291
1291
|
"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.",
|
|
1292
1292
|
"kind": "dev",
|
|
@@ -1116,7 +1116,7 @@
|
|
|
1116
1116
|
},
|
|
1117
1117
|
"networks": {},
|
|
1118
1118
|
"schemaVersion": "3.4.7",
|
|
1119
|
-
"updatedAt": "2022-05-
|
|
1119
|
+
"updatedAt": "2022-05-09T18:30:11.509Z",
|
|
1120
1120
|
"devdoc": {
|
|
1121
1121
|
"details": "Interface of the ERC20 standard as defined in the EIP.",
|
|
1122
1122
|
"events": {
|
|
@@ -503,7 +503,7 @@
|
|
|
503
503
|
},
|
|
504
504
|
"networks": {},
|
|
505
505
|
"schemaVersion": "3.4.7",
|
|
506
|
-
"updatedAt": "2022-05-
|
|
506
|
+
"updatedAt": "2022-05-09T18:30:11.511Z",
|
|
507
507
|
"devdoc": {
|
|
508
508
|
"details": "Interface for the optional metadata functions from the ERC20 standard. _Available since v4.1._",
|
|
509
509
|
"kind": "dev",
|
|
@@ -1651,7 +1651,7 @@
|
|
|
1651
1651
|
},
|
|
1652
1652
|
"networks": {},
|
|
1653
1653
|
"schemaVersion": "3.4.7",
|
|
1654
|
-
"updatedAt": "2022-05-
|
|
1654
|
+
"updatedAt": "2022-05-09T18:30:11.536Z",
|
|
1655
1655
|
"devdoc": {
|
|
1656
1656
|
"details": "Required interface of an ERC721 compliant contract.",
|
|
1657
1657
|
"events": {
|
|
@@ -275,7 +275,7 @@
|
|
|
275
275
|
},
|
|
276
276
|
"networks": {},
|
|
277
277
|
"schemaVersion": "3.4.7",
|
|
278
|
-
"updatedAt": "2022-05-
|
|
278
|
+
"updatedAt": "2022-05-09T18:30:11.537Z",
|
|
279
279
|
"devdoc": {
|
|
280
280
|
"details": "Interface for any contract that wants to support safeTransfers from ERC721 asset contracts.",
|
|
281
281
|
"kind": "dev",
|
|
@@ -2276,7 +2276,7 @@
|
|
|
2276
2276
|
},
|
|
2277
2277
|
"networks": {},
|
|
2278
2278
|
"schemaVersion": "3.4.7",
|
|
2279
|
-
"updatedAt": "2022-05-
|
|
2279
|
+
"updatedAt": "2022-05-09T18:30:11.538Z",
|
|
2280
2280
|
"devdoc": {
|
|
2281
2281
|
"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}.",
|
|
2282
2282
|
"kind": "dev",
|
|
@@ -306,7 +306,7 @@
|
|
|
306
306
|
},
|
|
307
307
|
"networks": {},
|
|
308
308
|
"schemaVersion": "3.4.7",
|
|
309
|
-
"updatedAt": "2022-05-
|
|
309
|
+
"updatedAt": "2022-05-09T18:30:11.539Z",
|
|
310
310
|
"devdoc": {
|
|
311
311
|
"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}.",
|
|
312
312
|
"kind": "dev",
|
|
@@ -306,7 +306,7 @@
|
|
|
306
306
|
},
|
|
307
307
|
"networks": {},
|
|
308
308
|
"schemaVersion": "3.4.7",
|
|
309
|
-
"updatedAt": "2022-05-
|
|
309
|
+
"updatedAt": "2022-05-09T18:30:11.539Z",
|
|
310
310
|
"devdoc": {
|
|
311
311
|
"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}.",
|
|
312
312
|
"kind": "dev",
|
|
@@ -5644,7 +5644,7 @@
|
|
|
5644
5644
|
},
|
|
5645
5645
|
"networks": {},
|
|
5646
5646
|
"schemaVersion": "3.4.7",
|
|
5647
|
-
"updatedAt": "2022-05-
|
|
5647
|
+
"updatedAt": "2022-05-09T18:30:11.644Z",
|
|
5648
5648
|
"devdoc": {
|
|
5649
5649
|
"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.",
|
|
5650
5650
|
"events": {
|
|
@@ -2045,7 +2045,7 @@
|
|
|
2045
2045
|
},
|
|
2046
2046
|
"networks": {},
|
|
2047
2047
|
"schemaVersion": "3.4.7",
|
|
2048
|
-
"updatedAt": "2022-05-
|
|
2048
|
+
"updatedAt": "2022-05-09T18:30:11.668Z",
|
|
2049
2049
|
"devdoc": {
|
|
2050
2050
|
"author": "Superfluid",
|
|
2051
2051
|
"details": "Matic Bridged Native SuperToken full interface",
|
|
@@ -476,7 +476,7 @@
|
|
|
476
476
|
},
|
|
477
477
|
"networks": {},
|
|
478
478
|
"schemaVersion": "3.4.7",
|
|
479
|
-
"updatedAt": "2022-05-
|
|
479
|
+
"updatedAt": "2022-05-09T18:30:11.669Z",
|
|
480
480
|
"devdoc": {
|
|
481
481
|
"author": "Superfluid",
|
|
482
482
|
"details": "Functionality specific for Matic Bridged Native Super Tokens",
|
|
@@ -252,7 +252,7 @@
|
|
|
252
252
|
},
|
|
253
253
|
"networks": {},
|
|
254
254
|
"schemaVersion": "3.4.7",
|
|
255
|
-
"updatedAt": "2022-05-
|
|
255
|
+
"updatedAt": "2022-05-09T18:30:11.673Z",
|
|
256
256
|
"devdoc": {
|
|
257
257
|
"author": "Superfluid",
|
|
258
258
|
"details": "A contract must implement this interface in order to support relayed transactionsIt is better to inherit the BaseRelayRecipient as its implementation",
|