Comparing version 0.4.0 to 0.6.0
{ | ||
"name": "erc7656", | ||
"version": "0.4.0", | ||
"version": "0.6.0", | ||
"description": "ERC7656 Reference Implementation", | ||
@@ -30,5 +30,4 @@ "publishConfig": { | ||
"dependencies": { | ||
"@openzeppelin/contracts": "^5.0.2", | ||
"erc6551": "^0.3.1" | ||
"@openzeppelin/contracts": "^5.0.2" | ||
} | ||
} |
@@ -11,3 +11,3 @@ # ERC-7656 | ||
has been deployed to the following address: | ||
has been deployed to erc7656.eth, i.e.: | ||
@@ -50,3 +50,3 @@ ``` | ||
``` | ||
npm i erc7656 @openzeppelin/contracts erc6551 | ||
npm i erc7656 @openzeppelin/contracts | ||
``` | ||
@@ -91,2 +91,6 @@ Make your nft able to deploy plugins | ||
To make your plugin extend `exr7656/ERC7656Service.sol` or `erc7656/extensions/ERC7656ServiceExt`. | ||
--- | ||
Notice that anyone can deploy a service owned by a specific token, usign whatever salt they prefer. To avoid troubles and security issues, any initial setup must be designed so that, despite who is the deployer, the result is what is expected to be. For example, if a service must get some information from the token, it should be the service the one that queries the token, not the other way around. In other words, passing any parameter to the service during the deploying opens to the possibility of a malicious deployer to pass a different set of data causing the service to behave unexpectedly. | ||
@@ -93,0 +97,0 @@ |
Sorry, the diff of this file is not supported yet
Sorry, the diff of this file is not supported yet
License Policy Violation
LicenseThis package is not allowed per your license policy. Review the package's license to ensure compliance.
Found 1 instance in 1 package
License Policy Violation
LicenseThis package is not allowed per your license policy. Review the package's license to ensure compliance.
Found 1 instance in 1 package
26816
1
13
100
- Removederc6551@^0.3.1
- Removederc6551@0.3.1(transitive)