I am developing a solidity contract to upload Ethereum-based erc721 NFT to opensea.
As a result, there is a way to create a collection in opensea and charge a secondary fee.
Also, I know that there is a way to configure eip-2981 by combining it with erc721.
I am trying to minting using erc721A and minting to buyers through the minting page. Do I have to write a contract with eip-2981 because OpenC is not making a collection? Even after reading articles on the web, I don't quite understand which method to use and why. I wish someone could sort it out.
Your collection will not show up on OS until at least 1 NFT has been minted. I would recommend testing this out on their test site using the Rinkeby network. Also to answer your main question, secondary sales goes something like this:
You as the collection owner can choose how much of a fee you would like to charge up to 10%. You must also know that OS takes 2.5% off the top of any sale regardless as well. So say someone wanted to sell their NFT for 1 ETH, and the collection royalty was set to 10%. When that NFT sells, the collection owner would get 0.1 ETH and OS would take 0.025 ETH. The total royalties collected would be 0.125 and the seller would receive 0.875 ETH.
Related
Is there a way to verify that it is possible to sell a token?
There are a lot of honeypots, so you can buy a token, but then you will be not able to sell it.
I have found that there is a possibility to estimate gas for the swap transaction e.g. on the Uniswap, but in this solution, there are some conditions. The token has to be approved and you have to own some number of the token, so it could be expensive. Do you know any other method to verify that? For example, interacting with the token contract?
Example contract: https://etherscan.io/address/0x419d0d8bdd9af5e606ae2232ed285aff190e711b#readContract
There are also tokens with 100% sell fee, but it is not easy to define the contract internal fee (there is not one method to do that).
I just started learning Solidity to develop smart contracts for an NFT project, and have run into a roadblock I can't seem to understand.
The goal is to mint in several phases (e.g. allow for minting 100 tomorrow, 100 more the next week, and the last 100 the week after). How would I go about doing this?
Keep in mind I do not want the NFTs to be "sniped", and after minting the first 100 I want to reveal NFT pictures, so I am afraid that this reveal will make the IPFS link public and that people can easily see what pictures they can mint in the next phase?
Not sure if I make any sense, and sorry for being a noob, but please let me know if you want me to clarify and thanks!:)
You can definitely do your mint in phases. There are plenty of projects out there that have this type of mint structure already:
Phase 1: Reserved Mint (number to mint for giveaways)
Phase 2: Presale (number to mint to WL members)
Phase 3: Public (number to mint to public members)
In your case each phase would just be p1,p2,p3 and the number allowed to mint in each phase would be 100.
From what I know, there is no good way to reveal the images in phases though. As soon as you update the tokenURI it will be changed for all images. Even if you did reveal them in phases somehow, the ipfs link would be public which means anyone could see where the rare ones are located.
My first suggestion would be to look at the contracts of projects that you want yours to be modeled after on etherscan. These will typically give you the best start as to how you will want to structure your contract.
If you need any more help I'm always available on Twitter #_syndk8
I'm working on a new project that I'm launching soon. The dapp is almost ok, I'm writing the contracts.
But I'm not sure I understood everything, if someone can help me :(
I would like to create a token contract with a supply fix (like 1 million), then make two pre-sales (one with and without whitelist), then a contract to sell on DEX with rewards, staking system, etc.
What is the best way to do this?
Is it possible to :
create the tokens with the first contract
transfer them to the pre sale whitelist contract
make the pre-sale
transfer the remaining tokens to the pre-sale contract without withelist
make the pre-sale
transfer the remaining tokens on the last contract, which will manage all the features of my token + put on a dex
am I right in the way I do it or am I completely wrong ?
If I'm wrong, do I have to do everything in one contract, with specific functions and flags like for the beginning and the end of a pre-dirty ?
if I do everything in one, will some smart guy be able to put the contract on a DEX and add liquidity?
I looked for several ohm/nodes project contracts, I saw the pre-sale contracts but I didn't understand when they create the token because their pre-sale contracts are just sell contracts
and I didn't understand how after the pre sale the main contract takes over
i would like a final contract like that, once the sales are finish
https://snowtrace.io/address/0xf2cfc11093edb5a2dc7f49e70a3a3a9cd4f4fee4#code
if someone can help me, thanks :)
ps : last question, in the contract i dont understand what are payees, shares, addresses and balances variables
This question covers a few different things so I'm going to split my answer up.
Answers:
I looked for several ohm/nodes project contracts, I saw the pre-sale contracts but I didn't understand when they create the token because their pre-sale contracts are just sell contracts
Presale contracts by nature are selling contracts the token contract and the presale contract are generally not the same but there are a thousand ways to do that. They receive x amount of tokens and take payment in say ETH for x tokens.
if I do everything in one, will some smart guy be able to put the contract on a DEX and add liquidity?
Anybody will pretty much always be able to add liquidity for a token because that is external to the token but there are certain ways you can prevent adding liquidity until a certain condition is met say a certain timestamp you just need to detect operations that are swaps/adding liquidity and throw an error.
ps: last question, in the contract I don't understand what are payees, shares, addresses, and balances variables
I am not entirely sure what the purpose of these are for because I am not very familiar with the BRIG protocol.
and I didn't understand how after the pre-sale the main contract takes over
The main contract does not need to take over from the presale contract because the presale contract just runs until all of the tokens are sold and then it just becomes an empty husk.
Other stuff:
In the future please split up your questions across multiple StackOverflow posts.
I'm using OpenZeppelin's PullPayment to handle payouts from my eth smart contracts. While withdrawing the coins with MetaMask, MetaMask shows 0 ETH when withdrawing for instance 2 ETH:
Is it possible for the payout amount to appear in MetaMask?
It is not possible, due to the design of MetaMask. There are a couple of ERCs to show human-readable transaction data fields, but as far as I know none of them have been adopted yet.
I am writing a test application that allows people to purchase tokens.
I am adapting the example from here: https://ethereum.org/token#the-code
Here are my questions:
What is the best way to have a registry of purchases? I would assume this can be a simple web interface that queries the block chain to see who has bought what.
If this is correct, does this mean running geth on a server in order to have the latest blockchain available and then using some kind of PHP / Javascript library in order to query the blockchain every so often?
What is the best way to sell tokens? Could this be done via a web interface or would it be best to sell via the ethereum wallet? Or both?
Lets say I want to split a token into a number of parts as such:
A: A full token = 1
B: 1/10th of a full token called a 10token
C: 1/10th of a 10token called a 100token
D: 1/10th of a 100token called a 1000token
What is the best way to represent this?
For instance, if someone owns a full token they have 100% of that tokens rights. However it would be possible for many parts of a token to be owned by different people who will share rights according to their share.
Visually, it would look something like this:
How to do this is a puzzle to me.
What is the best way to have a registry of purchases? I would assume this can be a simple web interface that queries the block chain to see who has bought what.
You can do the registry in your token sale smart-contract by making event like this
event TokenPurchase(address indexed purchaser, address indexed beneficiary, uint256 value, uint256 amount);
In this case you will be able to watch event log later and get all the addresses you need.
Another approach is to add a simple map to your contract like this mapping (address => uint256) public deposited; and add elements to this map on purchases.
About the representation of the registry for the users you better just take a look at ICO's you like and make it in the same way.
What is the best way to sell tokens? Could this be done via a web interface or would it be best to sell via the ethereum wallet? Or both?
I would say both. But it depends on who are your tokens for. If you sell only using ethereum wallet you will loose a lot of users not familiar with blockchain.
Lets say I want to split a token into a number of parts as such
Take a look at the solutions offered by OpenZeppelin project. Just read their contracts code and I think you'll find solutions you were looking for in this post.