@superfluid-finance/ethereum-contracts 1.1.1 → 1.1.2-dev.c77270b.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/ERC20.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/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/INativeSuperToken.json +1 -1
- package/build/contracts/INativeSuperTokenCustom.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/MultiFlowApp.json +1 -1
- package/build/contracts/NativeSuperTokenProxy.json +1 -1
- package/build/contracts/NonClosableOutflowTestApp.json +1 -1
- package/build/contracts/Ownable.json +1 -1
- package/build/contracts/Proxy.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/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
|
@@ -7906,7 +7906,7 @@
|
|
|
7906
7906
|
},
|
|
7907
7907
|
"networks": {},
|
|
7908
7908
|
"schemaVersion": "3.4.4",
|
|
7909
|
-
"updatedAt": "2022-03-
|
|
7909
|
+
"updatedAt": "2022-03-18T19:00:29.321Z",
|
|
7910
7910
|
"devdoc": {
|
|
7911
7911
|
"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.",
|
|
7912
7912
|
"kind": "dev",
|
|
@@ -3221,7 +3221,7 @@
|
|
|
3221
3221
|
},
|
|
3222
3222
|
"networks": {},
|
|
3223
3223
|
"schemaVersion": "3.4.4",
|
|
3224
|
-
"updatedAt": "2022-03-
|
|
3224
|
+
"updatedAt": "2022-03-18T19:00:29.325Z",
|
|
3225
3225
|
"devdoc": {
|
|
3226
3226
|
"details": "Extension of {AccessControl} that allows enumerating the members of each role.",
|
|
3227
3227
|
"kind": "dev",
|
|
@@ -7923,7 +7923,7 @@
|
|
|
7923
7923
|
},
|
|
7924
7924
|
"networks": {},
|
|
7925
7925
|
"schemaVersion": "3.4.4",
|
|
7926
|
-
"updatedAt": "2022-03-
|
|
7926
|
+
"updatedAt": "2022-03-18T19:00:29.366Z",
|
|
7927
7927
|
"devdoc": {
|
|
7928
7928
|
"details": "Collection of functions related to the address type",
|
|
7929
7929
|
"kind": "dev",
|
|
@@ -13771,7 +13771,7 @@
|
|
|
13771
13771
|
},
|
|
13772
13772
|
"networks": {},
|
|
13773
13773
|
"schemaVersion": "3.4.4",
|
|
13774
|
-
"updatedAt": "2022-03-
|
|
13774
|
+
"updatedAt": "2022-03-18T19:00:29.419Z",
|
|
13775
13775
|
"devdoc": {
|
|
13776
13776
|
"author": "Superfluid",
|
|
13777
13777
|
"details": "Helper library for building super agreement",
|
|
@@ -1156,7 +1156,7 @@
|
|
|
1156
1156
|
},
|
|
1157
1157
|
"networks": {},
|
|
1158
1158
|
"schemaVersion": "3.4.4",
|
|
1159
|
-
"updatedAt": "2022-03-
|
|
1159
|
+
"updatedAt": "2022-03-18T19:00:30.450Z",
|
|
1160
1160
|
"devdoc": {
|
|
1161
1161
|
"author": "Superfluid",
|
|
1162
1162
|
"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",
|
|
@@ -10399,7 +10399,7 @@
|
|
|
10399
10399
|
},
|
|
10400
10400
|
"networks": {},
|
|
10401
10401
|
"schemaVersion": "3.4.4",
|
|
10402
|
-
"updatedAt": "2022-03-
|
|
10402
|
+
"updatedAt": "2022-03-18T19:00:29.587Z",
|
|
10403
10403
|
"devdoc": {
|
|
10404
10404
|
"author": "Superfluid",
|
|
10405
10405
|
"kind": "dev",
|
|
@@ -22431,7 +22431,7 @@
|
|
|
22431
22431
|
},
|
|
22432
22432
|
"networks": {},
|
|
22433
22433
|
"schemaVersion": "3.4.4",
|
|
22434
|
-
"updatedAt": "2022-03-
|
|
22434
|
+
"updatedAt": "2022-03-18T19:00:29.532Z",
|
|
22435
22435
|
"devdoc": {
|
|
22436
22436
|
"author": "Superfluid",
|
|
22437
22437
|
"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()",
|
|
@@ -31588,7 +31588,7 @@
|
|
|
31588
31588
|
},
|
|
31589
31589
|
"networks": {},
|
|
31590
31590
|
"schemaVersion": "3.4.4",
|
|
31591
|
-
"updatedAt": "2022-03-
|
|
31591
|
+
"updatedAt": "2022-03-18T19:00:29.656Z",
|
|
31592
31592
|
"devdoc": {
|
|
31593
31593
|
"details": "This is CFA SuperApp that closes an updated flow.",
|
|
31594
31594
|
"kind": "dev",
|
|
@@ -95487,7 +95487,7 @@
|
|
|
95487
95487
|
},
|
|
95488
95488
|
"networks": {},
|
|
95489
95489
|
"schemaVersion": "3.4.4",
|
|
95490
|
-
"updatedAt": "2022-03-
|
|
95490
|
+
"updatedAt": "2022-03-18T19:00:29.427Z",
|
|
95491
95491
|
"devdoc": {
|
|
95492
95492
|
"author": "Superfluid",
|
|
95493
95493
|
"details": "Please read IConstantFlowAgreementV1 for implementation notes.For more technical notes, please visit protocol-monorepo wiki area.",
|
|
@@ -493,7 +493,7 @@
|
|
|
493
493
|
},
|
|
494
494
|
"networks": {},
|
|
495
495
|
"schemaVersion": "3.4.4",
|
|
496
|
-
"updatedAt": "2022-03-
|
|
496
|
+
"updatedAt": "2022-03-18T19:00:29.370Z",
|
|
497
497
|
"devdoc": {
|
|
498
498
|
"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.",
|
|
499
499
|
"kind": "dev",
|
|
@@ -10399,7 +10399,7 @@
|
|
|
10399
10399
|
},
|
|
10400
10400
|
"networks": {},
|
|
10401
10401
|
"schemaVersion": "3.4.4",
|
|
10402
|
-
"updatedAt": "2022-03-
|
|
10402
|
+
"updatedAt": "2022-03-18T19:00:29.591Z",
|
|
10403
10403
|
"devdoc": {
|
|
10404
10404
|
"author": "Superfluid",
|
|
10405
10405
|
"kind": "dev",
|
|
@@ -3231,7 +3231,7 @@
|
|
|
3231
3231
|
},
|
|
3232
3232
|
"networks": {},
|
|
3233
3233
|
"schemaVersion": "3.4.4",
|
|
3234
|
-
"updatedAt": "2022-03-
|
|
3234
|
+
"updatedAt": "2022-03-18T19:00:29.371Z",
|
|
3235
3235
|
"devdoc": {
|
|
3236
3236
|
"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.",
|
|
3237
3237
|
"kind": "dev",
|
|
@@ -285,7 +285,7 @@
|
|
|
285
285
|
},
|
|
286
286
|
"networks": {},
|
|
287
287
|
"schemaVersion": "3.4.4",
|
|
288
|
-
"updatedAt": "2022-03-
|
|
288
|
+
"updatedAt": "2022-03-18T19:00:29.587Z",
|
|
289
289
|
"devdoc": {
|
|
290
290
|
"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.",
|
|
291
291
|
"kind": "dev",
|
|
@@ -603,7 +603,7 @@
|
|
|
603
603
|
},
|
|
604
604
|
"networks": {},
|
|
605
605
|
"schemaVersion": "3.4.4",
|
|
606
|
-
"updatedAt": "2022-03-
|
|
606
|
+
"updatedAt": "2022-03-18T19:00:29.399Z",
|
|
607
607
|
"devdoc": {
|
|
608
608
|
"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.",
|
|
609
609
|
"kind": "dev",
|
|
@@ -1887,7 +1887,7 @@
|
|
|
1887
1887
|
},
|
|
1888
1888
|
"networks": {},
|
|
1889
1889
|
"schemaVersion": "3.4.4",
|
|
1890
|
-
"updatedAt": "2022-03-
|
|
1890
|
+
"updatedAt": "2022-03-18T19:00:29.400Z",
|
|
1891
1891
|
"devdoc": {
|
|
1892
1892
|
"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.",
|
|
1893
1893
|
"kind": "dev",
|
|
@@ -20792,7 +20792,7 @@
|
|
|
20792
20792
|
},
|
|
20793
20793
|
"networks": {},
|
|
20794
20794
|
"schemaVersion": "3.4.4",
|
|
20795
|
-
"updatedAt": "2022-03-
|
|
20795
|
+
"updatedAt": "2022-03-18T19:00:29.331Z",
|
|
20796
20796
|
"devdoc": {
|
|
20797
20797
|
"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}.",
|
|
20798
20798
|
"kind": "dev",
|
|
@@ -518,7 +518,7 @@
|
|
|
518
518
|
},
|
|
519
519
|
"networks": {},
|
|
520
520
|
"schemaVersion": "3.4.4",
|
|
521
|
-
"updatedAt": "2022-03-
|
|
521
|
+
"updatedAt": "2022-03-18T19:00:29.621Z",
|
|
522
522
|
"devdoc": {
|
|
523
523
|
"author": "Superfluid",
|
|
524
524
|
"details": "Using abstract contract instead of interfaces because old solidity does not support interface inheriting other interfaces solhint-disable-next-line no-empty-blocks",
|
|
@@ -33160,7 +33160,7 @@
|
|
|
33160
33160
|
},
|
|
33161
33161
|
"networks": {},
|
|
33162
33162
|
"schemaVersion": "3.4.4",
|
|
33163
|
-
"updatedAt": "2022-03-
|
|
33163
|
+
"updatedAt": "2022-03-18T19:00:29.345Z",
|
|
33164
33164
|
"devdoc": {
|
|
33165
33165
|
"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}.",
|
|
33166
33166
|
"kind": "dev",
|
|
@@ -17678,7 +17678,7 @@
|
|
|
17678
17678
|
},
|
|
17679
17679
|
"networks": {},
|
|
17680
17680
|
"schemaVersion": "3.4.4",
|
|
17681
|
-
"updatedAt": "2022-03-
|
|
17681
|
+
"updatedAt": "2022-03-18T19:00:29.792Z",
|
|
17682
17682
|
"devdoc": {
|
|
17683
17683
|
"kind": "dev",
|
|
17684
17684
|
"methods": {},
|
|
@@ -17787,7 +17787,7 @@
|
|
|
17787
17787
|
},
|
|
17788
17788
|
"networks": {},
|
|
17789
17789
|
"schemaVersion": "3.4.4",
|
|
17790
|
-
"updatedAt": "2022-03-
|
|
17790
|
+
"updatedAt": "2022-03-18T19:00:29.799Z",
|
|
17791
17791
|
"devdoc": {
|
|
17792
17792
|
"kind": "dev",
|
|
17793
17793
|
"methods": {},
|
|
@@ -14101,7 +14101,7 @@
|
|
|
14101
14101
|
},
|
|
14102
14102
|
"networks": {},
|
|
14103
14103
|
"schemaVersion": "3.4.4",
|
|
14104
|
-
"updatedAt": "2022-03-
|
|
14104
|
+
"updatedAt": "2022-03-18T19:00:29.412Z",
|
|
14105
14105
|
"devdoc": {
|
|
14106
14106
|
"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.",
|
|
14107
14107
|
"kind": "dev",
|
|
@@ -31742,7 +31742,7 @@
|
|
|
31742
31742
|
},
|
|
31743
31743
|
"networks": {},
|
|
31744
31744
|
"schemaVersion": "3.4.4",
|
|
31745
|
-
"updatedAt": "2022-03-
|
|
31745
|
+
"updatedAt": "2022-03-18T19:00:29.669Z",
|
|
31746
31746
|
"devdoc": {
|
|
31747
31747
|
"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.",
|
|
31748
31748
|
"kind": "dev",
|
|
@@ -3659,7 +3659,7 @@
|
|
|
3659
3659
|
},
|
|
3660
3660
|
"networks": {},
|
|
3661
3661
|
"schemaVersion": "3.4.4",
|
|
3662
|
-
"updatedAt": "2022-03-
|
|
3662
|
+
"updatedAt": "2022-03-18T19:00:29.634Z",
|
|
3663
3663
|
"devdoc": {
|
|
3664
3664
|
"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.",
|
|
3665
3665
|
"kind": "dev",
|
|
@@ -32373,7 +32373,7 @@
|
|
|
32373
32373
|
},
|
|
32374
32374
|
"networks": {},
|
|
32375
32375
|
"schemaVersion": "3.4.4",
|
|
32376
|
-
"updatedAt": "2022-03-
|
|
32376
|
+
"updatedAt": "2022-03-18T19:00:29.684Z",
|
|
32377
32377
|
"devdoc": {
|
|
32378
32378
|
"kind": "dev",
|
|
32379
32379
|
"methods": {},
|
|
@@ -1876,7 +1876,7 @@
|
|
|
1876
1876
|
},
|
|
1877
1877
|
"networks": {},
|
|
1878
1878
|
"schemaVersion": "3.4.4",
|
|
1879
|
-
"updatedAt": "2022-03-
|
|
1879
|
+
"updatedAt": "2022-03-18T19:00:29.326Z",
|
|
1880
1880
|
"devdoc": {
|
|
1881
1881
|
"details": "External interface of AccessControl declared to support ERC165 detection.",
|
|
1882
1882
|
"events": {
|
|
@@ -805,7 +805,7 @@
|
|
|
805
805
|
},
|
|
806
806
|
"networks": {},
|
|
807
807
|
"schemaVersion": "3.4.4",
|
|
808
|
-
"updatedAt": "2022-03-
|
|
808
|
+
"updatedAt": "2022-03-18T19:00:29.327Z",
|
|
809
809
|
"devdoc": {
|
|
810
810
|
"details": "External interface of AccessControlEnumerable declared to support ERC165 detection.",
|
|
811
811
|
"kind": "dev",
|
|
@@ -35559,7 +35559,7 @@
|
|
|
35559
35559
|
},
|
|
35560
35560
|
"networks": {},
|
|
35561
35561
|
"schemaVersion": "3.4.4",
|
|
35562
|
-
"updatedAt": "2022-03-
|
|
35562
|
+
"updatedAt": "2022-03-18T19:00:29.542Z",
|
|
35563
35563
|
"devdoc": {
|
|
35564
35564
|
"author": "Superfluid",
|
|
35565
35565
|
"details": "Set a variable of type `InitData` in the contract, then call this library's functions directly `initData.functionName()`.",
|
|
@@ -317,7 +317,7 @@
|
|
|
317
317
|
},
|
|
318
318
|
"networks": {},
|
|
319
319
|
"schemaVersion": "3.4.4",
|
|
320
|
-
"updatedAt": "2022-03-
|
|
320
|
+
"updatedAt": "2022-03-18T19:00:29.401Z",
|
|
321
321
|
"devdoc": {
|
|
322
322
|
"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}.",
|
|
323
323
|
"kind": "dev",
|
|
@@ -378,7 +378,7 @@
|
|
|
378
378
|
},
|
|
379
379
|
"networks": {},
|
|
380
380
|
"schemaVersion": "3.4.4",
|
|
381
|
-
"updatedAt": "2022-03-
|
|
381
|
+
"updatedAt": "2022-03-18T19:00:29.401Z",
|
|
382
382
|
"devdoc": {
|
|
383
383
|
"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}.",
|
|
384
384
|
"kind": "dev",
|
|
@@ -2337,7 +2337,7 @@
|
|
|
2337
2337
|
},
|
|
2338
2338
|
"networks": {},
|
|
2339
2339
|
"schemaVersion": "3.4.4",
|
|
2340
|
-
"updatedAt": "2022-03-
|
|
2340
|
+
"updatedAt": "2022-03-18T19:00:29.402Z",
|
|
2341
2341
|
"devdoc": {
|
|
2342
2342
|
"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.",
|
|
2343
2343
|
"kind": "dev",
|
|
@@ -2027,7 +2027,7 @@
|
|
|
2027
2027
|
},
|
|
2028
2028
|
"networks": {},
|
|
2029
2029
|
"schemaVersion": "3.4.4",
|
|
2030
|
-
"updatedAt": "2022-03-
|
|
2030
|
+
"updatedAt": "2022-03-18T19:00:29.340Z",
|
|
2031
2031
|
"devdoc": {
|
|
2032
2032
|
"details": "Interface of the ERC20 standard as defined in the EIP.",
|
|
2033
2033
|
"events": {
|
|
@@ -766,7 +766,7 @@
|
|
|
766
766
|
},
|
|
767
767
|
"networks": {},
|
|
768
768
|
"schemaVersion": "3.4.4",
|
|
769
|
-
"updatedAt": "2022-03-
|
|
769
|
+
"updatedAt": "2022-03-18T19:00:29.341Z",
|
|
770
770
|
"devdoc": {
|
|
771
771
|
"details": "Interface for the optional metadata functions from the ERC20 standard. _Available since v4.1._",
|
|
772
772
|
"kind": "dev",
|
|
@@ -2993,7 +2993,7 @@
|
|
|
2993
2993
|
},
|
|
2994
2994
|
"networks": {},
|
|
2995
2995
|
"schemaVersion": "3.4.4",
|
|
2996
|
-
"updatedAt": "2022-03-
|
|
2996
|
+
"updatedAt": "2022-03-18T19:00:29.360Z",
|
|
2997
2997
|
"devdoc": {
|
|
2998
2998
|
"details": "Required interface of an ERC721 compliant contract.",
|
|
2999
2999
|
"events": {
|
|
@@ -498,7 +498,7 @@
|
|
|
498
498
|
},
|
|
499
499
|
"networks": {},
|
|
500
500
|
"schemaVersion": "3.4.4",
|
|
501
|
-
"updatedAt": "2022-03-
|
|
501
|
+
"updatedAt": "2022-03-18T19:00:29.362Z",
|
|
502
502
|
"devdoc": {
|
|
503
503
|
"details": "Interface for any contract that wants to support safeTransfers from ERC721 asset contracts.",
|
|
504
504
|
"kind": "dev",
|
|
@@ -4133,7 +4133,7 @@
|
|
|
4133
4133
|
},
|
|
4134
4134
|
"networks": {},
|
|
4135
4135
|
"schemaVersion": "3.4.4",
|
|
4136
|
-
"updatedAt": "2022-03-
|
|
4136
|
+
"updatedAt": "2022-03-18T19:00:29.363Z",
|
|
4137
4137
|
"devdoc": {
|
|
4138
4138
|
"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}.",
|
|
4139
4139
|
"kind": "dev",
|
|
@@ -556,7 +556,7 @@
|
|
|
556
556
|
},
|
|
557
557
|
"networks": {},
|
|
558
558
|
"schemaVersion": "3.4.4",
|
|
559
|
-
"updatedAt": "2022-03-
|
|
559
|
+
"updatedAt": "2022-03-18T19:00:29.365Z",
|
|
560
560
|
"devdoc": {
|
|
561
561
|
"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}.",
|
|
562
562
|
"kind": "dev",
|
|
@@ -556,7 +556,7 @@
|
|
|
556
556
|
},
|
|
557
557
|
"networks": {},
|
|
558
558
|
"schemaVersion": "3.4.4",
|
|
559
|
-
"updatedAt": "2022-03-
|
|
559
|
+
"updatedAt": "2022-03-18T19:00:29.366Z",
|
|
560
560
|
"devdoc": {
|
|
561
561
|
"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}.",
|
|
562
562
|
"kind": "dev",
|
|
@@ -10324,7 +10324,7 @@
|
|
|
10324
10324
|
},
|
|
10325
10325
|
"networks": {},
|
|
10326
10326
|
"schemaVersion": "3.4.4",
|
|
10327
|
-
"updatedAt": "2022-03-
|
|
10327
|
+
"updatedAt": "2022-03-18T19:00:29.582Z",
|
|
10328
10328
|
"devdoc": {
|
|
10329
10329
|
"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.",
|
|
10330
10330
|
"events": {
|
|
@@ -2450,7 +2450,7 @@
|
|
|
2450
2450
|
},
|
|
2451
2451
|
"networks": {},
|
|
2452
2452
|
"schemaVersion": "3.4.4",
|
|
2453
|
-
"updatedAt": "2022-03-
|
|
2453
|
+
"updatedAt": "2022-03-18T19:00:29.621Z",
|
|
2454
2454
|
"devdoc": {
|
|
2455
2455
|
"author": "Superfluid",
|
|
2456
2456
|
"details": "Matic Bridged Native SuperToken full interface",
|
|
@@ -881,7 +881,7 @@
|
|
|
881
881
|
},
|
|
882
882
|
"networks": {},
|
|
883
883
|
"schemaVersion": "3.4.4",
|
|
884
|
-
"updatedAt": "2022-03-
|
|
884
|
+
"updatedAt": "2022-03-18T19:00:29.623Z",
|
|
885
885
|
"devdoc": {
|
|
886
886
|
"author": "Superfluid",
|
|
887
887
|
"details": "Functionality specific for Matic Bridged Native Super Tokens",
|
|
@@ -454,7 +454,7 @@
|
|
|
454
454
|
},
|
|
455
455
|
"networks": {},
|
|
456
456
|
"schemaVersion": "3.4.4",
|
|
457
|
-
"updatedAt": "2022-03-
|
|
457
|
+
"updatedAt": "2022-03-18T19:00:29.627Z",
|
|
458
458
|
"devdoc": {
|
|
459
459
|
"author": "Superfluid",
|
|
460
460
|
"details": "A contract must implement this interface in order to support relayed transactionsIt is better to inherit the BaseRelayRecipient as its implementation",
|
|
@@ -3053,7 +3053,7 @@
|
|
|
3053
3053
|
},
|
|
3054
3054
|
"networks": {},
|
|
3055
3055
|
"schemaVersion": "3.4.4",
|
|
3056
|
-
"updatedAt": "2022-03-
|
|
3056
|
+
"updatedAt": "2022-03-18T19:00:29.604Z",
|
|
3057
3057
|
"devdoc": {
|
|
3058
3058
|
"author": "Superfluid",
|
|
3059
3059
|
"details": "Be aware of the app being jailed, when the word permitted is used.",
|