Thank you for reading this. I am learning about cryptocurrency and about Binance smart chain. I want to try to learn and want to clone a few projects such as this one:
https://bscscan.com/address/0x359f35085202c8527a0c767557339635a335eb76#code
I am able to deploy the smart contract but when I try to verify and publish, the Contract ABI is empty. enter image description here
[1]: https://i.stack.imgur.com/zqb06.png
If someone knows how to create a clone from existing smart contract, I am willing to pay to learn. We can set up a meeting time via Zoom or using TeamViewer and I can pay via Paypal. Please message me if you are interested. Thank you very much!!!
I found solution to this problem. Thank you everyone! I needed to deploy the main contract and not the parent one.
Related
I'm new in blockchain development, I wonder why is it necessary to interact with contract from another contract instead of from a personal EOA address?
Besides the delegatecall, I can't imaging any advantage to use contract to call another deployed contract's functions. As a user, I may rather use ethers or web3js through wallet etc to interact with a deployed smart contract instead.
would you please show me some reasons or necessary cases that I should design my project using a smart contract to interact with another smart contract? Thanks a lot!
There are too many use cases:
1- Upgradeable contracts or proxy contracts. Since blockchain technology is evolving so fast, it is so hard to write a contract that will be scalable. With proxy contracts, user calls the proxy contract but proxy calls the main contract. if in the future you have to change the logic of the contract, you deploy a new contract and make the proxy contract call this new contract. This way users will not get affected. You can read more about this pattern here
2- If you ever need to get data from real world, you cannot make an api call because this is not safe and not deterministic. for this reason, we use oracle services which also calls to many other smart contracts behind the scene, gets the results from each, and make a final response to the user. You can read more about oracles here
3- another use case is factory contracts. think about it as a class and users keep make an instance of it. that way instead of factory owner pays for the new contract creation, user will be paying for the deployment. you can read more about factory contracts
4- defi platforms have too many smart contracts and they are interacting each other. They keep the logic separate from each other, so they maintain better and see the missing points better. also putting everything in one contract would make contract code is bloated and make a mess. you can read uniswap
5- another use case to deploy library smart contracts. those are usually mathematical contracts which are deployed once and once u need complex functionalities, instead of you implement in your contract, you use library contracts and use them in your project. You can read about libraries
6- another use case is solving the scalability issues. imagine you have one kitchen and you have to serve all the customers from only one kitchen. As you get more customers, your service will eventually halted. so, there are layer 2 solutions to transfer some of the orders to different kitchens. and this of course happen through smart contract communications. more on layer 2
7- In general you can use inheritance. You deploy some contracts and inherit the logic from those smart contract. that is why you see openzeppelin contracts always inherit from each other
For example there are some standarts in Ethereum ecosystem. ERC20, ERC721, ERC1155 and others. So when you developing new project, instead of writing it from scratch you could install openzeppelin-contracts, import them and inherit. Afterwards you have this "carcass", on the top of which you can implement some additional functionality/custome code, etc. That approach is way more convenient and secure.
Another great example chainlink-contracts. Via them you can read from oracles. Oracles are smart contracts that keep track of cryptocurrencies prices online. Say you want your users to pay 10$ to participate in lottery/some giveaway. Your contract interacts with chainlink contract and makes sure that amount of eth that user paid is greater or equal to 10$ otherwise it returns error.
In solidity there is no true randomness, but again throughout interacting with chainlink contracts we can reach it. Another chainlink feature is automation contracts, check chainlink documentation to learn more(https://docs.chain.link/). To sum up id say that there is a lot of different protocoles/concepts which easier to interact with than to write it again.
"No need to reinvent the wheel"
my question is basically written in title, but for more details, I am using node.js, I read immutableX documentation and review there SDKs, but nothing on javascript,
I want to sign the transaction in cloud function(firebase) on immutableX chain.
Main goal is to transfer ERC20 tokens from one wallet to another. In my case, token which I want to transfer is GODS.
Thanks!
Well, I've never used ImmutableX but I think that for transferring ERC20 tokens you can use any library that can interact with Ethereum contracts like web3js
https://piyopiyo.medium.com/how-to-send-erc20-token-with-web3-js-99ed040693ce
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
Is it possible in Solidity for a smart contract to be able to interact with a specific wallet in such a way that it can pull money from it, and send money to it at any time it needs to? In this particular scenario, there will be a treasury wallet, that I want the smart contract to be able to pull from and send to at any time it needs to. Is this something that's possible with a few approvals, or perhaps is there a better, more standard way to resolve the problem that I'm having?
The treasury wallet needs to do ERC-20 token approve() on the specific wallet and then it can pull money.
For further details, check out EIP-20 spec.
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.