parsing error in smartcontract constructor, can some one please help me out and show me what I am doing wring and why this error is even thought everytrhing is looking fine from outside.
Constructor ERC721 need two string arguments(name and symbol) so you need to write like this
ERC721("Cryptopost","post")
so replace line 16 by this :
constructor(string memory token, string memory symbol)ERC721("Cryptopost","post")
Are you importing the erc721 openzeppelin file before creating the smart contract? For example:
//Import goes here
import "#openzeppelin/contracts/token/ERC721/ERC721.sol";
//this is the constructor function
constructor() public ERC721("Name", "symbol") {}
Related
I am currently learning solidity.
I have written the code as it appears in "Hands-On Smart Contract Development With Solidity and Ethereum" (O'Reilly/Japanese edition), but when I run TruffleTest, I get the following error
CompileError: project:/contracts/Fundraiser.sol:9:1: ParserError: Function, variable, struct or modifier declaration expected.
Here is the code.
https://github.com/okahijiki/fundraiser
I would appreciate any advice you can give me.
My library's version
Truffle
v5.5.31 (core: 5.5.31)/
Ganache v7.4.3/
Solidity v0.5.16 (solc-js)/
Node v16.15.1/
Web3.js v1.7.4
Here's the linked code:
pragma solidity >0.4.23 <0.7.0;
contract Fundraiser{
string public name;
constructor(string memory _name)public{
name = _name;
}
Count the number of opening braces - and the number of closing braces. You are correctly opening and closing the contract, but the constructor is missing its closing brace.
The solution is simple - close the constructor block with a brace as well.
contract Fundraiser{
string public name;
constructor(string memory _name)public{
name = _name;
} // closing the constructor here
}
This question is essentially a follow-up to this question. I have been trying to follow Alchemy documentation to create an NFT contract but encountered the need (as described in the linked question) to import ERC721URIStorage. However, I now get a number of compilation problems that do not make clear sense to me.
In response to the first error (see below), I have tried adding in the import statement for ERC721: import "#openzeppelin/contracts/token/ERC721/ERC721.sol"; This did not change anything in the set of compilation errors.
It should be kinda like this :>
import "#openzeppelin/contracts/token/ERC721/ERC721.sol";
import "#openzeppelin/contracts/token/ERC721/extensions/ERC721URIStorage.sol";
import "#openzeppelin/contracts/access/Ownable.sol";
import "#openzeppelin/contracts/utils/Counters.sol";
contract LeafNFT is ERC721, ERC721URIStorage, Ownable {
using Counters for Counters.Counter;
Counters.Counter private _tokenIdCounter;
constructor() ERC721("LeafNFT", "NFL") {}
function safeMint(address to, string memory uri) public onlyOwner {
uint256 tokenId = _tokenIdCounter.current();
_tokenIdCounter.increment();
_safeMint(to, tokenId);
_setTokenURI(tokenId, uri);
}
I was able to get the code to work with a slight variation. The relevant points of confusion seem to be:
Whether zero, one, or two of {ERC721, ERC721URIStorage} should be imported. The answer appears to be to import only ERC721URIStorage.
Whether the contract is defined as ERC721URIStorage, ERC721, Ownable, or as ERC721URIStorage, Ownable. The answer appears to be the latter.
Whether the constructor uses ERC721 or ERC721URIStorage. The answer seems to be ERC721.
I think the first two of these points are intuitive (they are the first thing I tried and appear in the code shown in the question). This is because ERC721URIStorage inherits from ERC721, so there is no need to explicitly import ERC721 or define the contract as such.
The third point was less expected, but in hindsight, I think the constructor must cite ERC721 because ERC721URIStorage does not have a constructor of its own and because there is ambiguity about where a constructor can be inherited from (either from a parent of ERC721URIStorage or from Ownable).
Below is the working contract:
Hi all I am building a blockchain-based game around an NFT project and am looking to understand if it's possible to implement the following.
Have a method on the NFT contract that when called can locks the transfer of all minted NFT's for a period. A bit like a game of tag than when your tag the contract all the (NFT / players) cant (move /transfer)
I assume I would need overide the transfer method then do a boolean check.
Something like
function safeTransferFrom(
address from,
address to,
uint256 tokenId
) public virtual override {
if(!isLocked){
safeTransferFrom(from, to, tokenId, "");
}
}
Will this work as I expect and is there any issues with this and would override the transfer method especially around security etc.
Sorry for such a broad question
Thanks
From the context, it seems like you're using the OpenZeppelin implementation. If that's the case, you can override their _beforeTokenTransfer() function, which is effectively called from all functions performing token transfer (as there is multiple of them).
pragma solidity ^0.8;
import "#openzeppelin/contracts/token/ERC721/ERC721.sol";
contract MyCollection is ERC721 {
constructor() ERC721("MyCollection", "MyC") {
_mint(msg.sender, 1);
}
// needs to be unlocked for the `_mint()` function in constructor
bool locked = false;
function setLocked(bool _locked) external {
locked = _locked;
}
function _beforeTokenTransfer(
address from,
address to,
uint256 tokenId
) internal override {
require(!locked, "Cannot transfer - currently locked");
}
}
If you're using other or custom implementation, or chose to only override the publicly visible functions, make sure that there is no other public or external function allowing the transfer without the lock mechanism.
Also few notes to your current code:
You probably won't need the virtual keyword. It allows the function to be further overridden. Unless you're expecting to override this function as well, you can safely remove the keyword.
You're calling the parent function with the same name but different argument set. If you wanted to call the parent function with the same name and the same argument set (assuming it's defined), you'd need to use the super keyword (same as in Java): super.safeTransferFrom(from, to, tokenId);
im doing step by step of this article and i had a problem on truffle compile part.
I've got this error in cmd:
Error parsing #openzeppelin/contracts/token/ERC721/ERC721.sol: ParsedContract.sol:51:72: ParserError: Expected '{' but got reserved keyword 'override'
function supportsInterface(bytes4 interfaceId) public view virtual override(ERC165, IERC165) returns (bool) {
^------^
my contract :
pragma solidity ^0.6.0;
import "#openzeppelin/contracts/token/ERC721/ERC721.sol";
import "#openzeppelin/contracts/utils/Counters.sol";
contract Uniken is ERC721{
using Counters for Counters.Counter;
Counters.Counter private _tokenIds;
mapping(string => uint8) hashes;
constructor() public ERC721("Uniken", "Ukn") {
}
function awardItem(address recipient, string memory hash, string memory metadata)
public
returns (uint256)
{
require(hashes[hash] != 1);
hashes[hash] = 1;
_tokenIds.increment();
uint256 newItemId = _tokenIds.current();
_mint(recipient, newItemId);
_setTokenURI(newItemId, metadata);
return newItemId;
}
}
I'd be thankfull if anyone tell me whatis the problem?
It seems like it isn't seeing the ERC165 contract that ERC721 extends from. That function that it is getting stuck on should be overriding a function of the same name in ERC165, but the truffle compiler doesn't see a function named supportsInterface() in a class that ERC721 inherits from. So I would check to make sure everything imported in the ERC721 smart contract is in the right place in your folder structures, and that ERC721 is correctly inheriting ERC165.
After made some research , I was in truffle version 5.0 and update to the latest version of truffle -> v5.4.6, I am now able to compile
The recent change in Solidity changed the fallback function format from just function() to fallback(), which is pretty nice for beginners to understand what is going on, but I have a question about a suggestion that the compiler gives me when I implement such a fallback.
For example, a piece of code from my project:
pragma solidity ^0.6.1;
contract payment{
mapping(address => uint) _balance;
fallback() payable external {
_balance[msg.sender] += msg.value;
}
}
Everything goes fine, but the compiler suggests that:
Warning: This contract has a payable fallback function, but no receive ether function.
Consider adding a receive ether function.
What does it mean by a receive ether function? I tried looking it up and many examples I could find is just another fallback function.
I am using version 0.6.1+commit.e6f7d5a4
As a complement to the accepted answer, here's how you should define the unnamed fallback and receive functions to solve this error:
contract MyContract {
fallback() external payable {
// custom function code
}
receive() external payable {
// custom function code
}
}
According to solidity version 0.6.0, we have a breaking change.
The unnamed function commonly referred to as “fallback function” was split up into a new fallback function that is defined using the fallback keyword and a receive ether function defined using the receive keyword.
If present, the receive ether function is called whenever the call data is empty (whether or not ether is received). This function is implicitly payable.
The new fallback function is called when no other function matches (if the receive ether function does not exist then this includes calls with empty call data). You can make this function payable or not. If it is not payable then transactions not matching any other function which send value will revert. You should only need to implement the new fallback function if you are following an upgrade or proxy pattern.
https://solidity.readthedocs.io/en/v0.6.7/060-breaking-changes.html#semantic-and-syntactic-changes