Hi there
(I'm new to the world of crypto and I'm still a noob and confused so please help me with your answer)
As a note I have read this:
How to restrict pancakeswap users from adding initial liquidity for my issued token?
Let's look at this scenario:
Bob created and launched a new token on BSC with 1000 total supply with name "test".
Bob also created a new pair with 80% of the total supply with 800 wbnb (test800 / 800 wbnb).
So each test token worth 1 wbnb and Instead, he receives 20 new LP-tokens.
Bob burned all the LP tokens by sending them to Dead-Wallet (or used any other locking platform), so far so good.
As nowadays everybody know, whenever someone trades on PancakeSwap, the trader pays a 0.25% fee, of which 0.17% is added to the Liquidity Pool of the swap pair they traded on.
https://docs.pancakeswap.finance/products/pancakeswap-exchange/pancakeswap-pools
A new buyer arrives, buys 100 of my tokens (test) and opens a new pair 100test/300wbnb (Or the same old LP is used) what will happen ?
Will my token price increase?
What if a new buyer creates a new pair with USDT?
How do I create an initial price for my new token?
Is it my first LP that creates my initial token price or the second
LP?
My most important question is:
How can I limit and restrict my LP from adding new pairs by others?
with thanks
I searched a lot on the internet, but no one mentioned it, or at least it was not simple or understandable for an amateur like me. I tried it myself on the Testnet network. The initial price of my coins was built according to my initial pool, but apparently everything changed when I built the second pool.
How can I limit and restrict my LP from adding new pairs by others?
You cannot. If a token is transferable, it is also freely tradeable.
Related
I'm currently working with the Elrond blockchain, and I've successfully registered a new NFT collection & created an NFT following the documentation example here.
However, I need to limit the amount of NFTs that can be created for a specific collection. The documentation says:
The ESDT manager can stop the creation of an NFT for the given ESDT forever by removing the only ESDTRoleNFTCreate role available.
So I guess I could just create the max supply of a collection (e.g 100 NFTs for collection1) and then remove the creation role. But this means I have to create all NFTs beforehand, which is not ideal.
Is there another way to limit the max supply, maybe when registering/issuing the collection itself?
On a separate note, is there good documentation on the difference between EGLD / ESDT / SFT / NFT. I'm particularly interested in SFTs, but I don't understand how the state change from fungible -> non-fungible works (e.g once the SFT becomes non-fungible, is it stuck in that state or can it become fungible again?). Documentation on that is quite unclear.
Thanks in advance for your help!
There is no optionnal "limit supply" for an NFT collection.
After you created the collection and give the ESDTRoleNFTCreate to your adresse or a contract you can call X time the function mint
Eventually, if you use a SC to mint the NFT, you can set a variable to limit the maximum allowed mint.
You cant convert NFT in SFT or SFT in NFT
The only operation allowed is converting an SFT into Meta-ESDT with no way back. This is possible only because SFT are really close to META-ESDT but with no decimals :)
I am doing a research on Uniswap, but I can't find explanations regarding its Swap UI.
What I want to know is what the 0.275% in the second row means.
I am well aware that Uniswap collects transaction fees for the liquidity pools, but the number I keep mentioning keeps changing and even seem to be positive at times.
Is the 0.275% a liquidity pool fee?
If you hover over the number it says The estimated difference between the USD values of input and output amounts. as you can see in the screenshot below:
You can read more about pricing in the uniswap docs.
I kinda need help figuring out the problem here, if anyone can help its very very much appreciated!
I'm trying to test out liquidity for my own token on the Binance Smart Chain, however I'm encountering a confusing issue that I can't seem to figure out.
I created a token with a supply of 1,000,000 (lets call it TOKEN). I am holding all of them in my Metamask wallet and I go to pancakeswap to provide liquidity. As a test, I added 100 TOKEN in a liquidity pool with 0.0001 BNB, setting the price at 1 TOKEN = 0.000001 BNB. Up until this point, everything is working fine.
Then I went to buy 100 TOKEN using 0.0001 BNB, and it says that the price impact is about 99.8%, which is okay with me, and I understand that since I'm buying the entire supply of liquidity.
At this point, after the transaction, I should have 1,000,000 TOKEN in my wallet again, so theoretically, at least in my mind, I can sell my 1,000,000 TOKEN for the old price of 0.0000001 BNB x 1.998 (0.000001998 BNB = 1 TOKEN), after factoring the calculated price impact. According to my calculations, this would mean that by selling 1,000,000 TOKEN, I would receive 1,000,000*0.000001998 = 1.998 BNB after the trade.
However, when I try to execute the trade, the price Pancakeswap sets for my sale of 1,000,000 TOKEN is less than what I originally set as liquidity, meaning that I end up with less BNB than what I started with.
I'm relatively new to the concept of liquidity and setting up your own crypto token, so I would really really appreciate if anyone with more knowledge can help explain what exactly is going on here?
I don’t have any pictures right now but I’ll try to add some when I’m home later.
The template I used is here on GitHub:
https://gist.github.com/mattupham/0a3af746ccbabeef3f461a9664ba4ea0
Thank you so much!
I am reading through UniswapV2 docs and can't understand the inputs of addLiquidity method properly.
As listed in the docs:
amountAMin (uint): Bounds the extent to which the B/A price can go up before the transaction reverts. Must be <= amountADesired.
amountBMin (uint): Bounds the extent to which the A/B price can go up before the transaction reverts. Must be <= amountBDesired.
What does it mean? Can you please give an example? Let's say, I set amountADesired and amountBDesired to 4 and amountAMin and amountBMin to 1. What will happen?
blockchain transactions are not immediate, but must queue before being mined on the blockchain and be effective
When you add liquidity given amountADesired you have to give it amountBDesired in proportion to the existing pair (example pair: 2:1 you have to put 2 tokens A and 1 token B)
once you send the transaction, before it is mined it may happen that others make operations on that liquidity pool, changing the proportion accordingly
by entering amountAmin and amountBmin you are practically telling him: "as long as the proportion is between amountADesired:amountBDesired and amountAMin:amountBmin accepts my liquidity addition, if instead the proportion exceeds my range, cancel my transaction"
Don't kill me if I'm about to ask something stupid. But I'm very noobish in this whole crypto world, and I'm terribly fascinated about its technology.
So just for education purposes I've decided to build my own blockchain following more or less the bitcoin principles (ECC keypair generation using the secpbk1 curve, SHA256 as hashing algo, dynamic diff based on the timestamp of the previous block, p2p connectivity etc..). But I've came to a point where I'm pretty confused about the blockchain's wallet itself.
For what I've learned so far, each transaction has to be signed by a wallet. So my transactions has basically three fields: input, outputs and id. Since the user's wallet signs the outputs field of the transaction, this can't be changed anymore without being signed again by the same private key that belongs to the public key contained in the input field, how can I reward the miners?
If I got it right, the miner creates a transaction signed somehow by the chain using the fee in the outputs field, or by asking the chain itself to generate and sign a special reward transaction for that miner.
The guide that I was following was using the second approach, and was generating a blockchain wallet each time the program was executed on a client. This approach left me perplexed:
wouldn't a client generate a new wallet for "his" blockchain each time it goes back online? If so, wouldn't this create a mess on the transactions signed on the chain? Since each miner (therefore peer) signing its own reward would use a different blockchain wallet than the other peers? Wouldn't this lead to any problems?
The first one that I might think of, is that if we generate a new blockchain wallet that signs rewards for miners, each peer would create a different wallet, so wouldn't this lead to many "ghosts" wallets in the chain, that spits out rewards tokens from nowhere? Is this supposed to happen?
For what I think is definitively more straightforward to use the fee amount to reward the miner, but this doesn't solve my doubts at all. Since the outputs of the transactions are signed upon creation, how could the peer initiating the transaction know upfront the possible miner who finds the block? And if he can't know it, how could possibly the miner "extract" its reward without tampering the transaction itself? Of course it could create a new transaction, and add that to the block. But who would sign that transaction? From where those reward tokens come?
And if the answer is not to generate a new wallet each time, where could you possibly store that very first private key of the chain's wallet where no one can see it, but still be able to use it, without having to put a server in the middle?
Which in my opinion breaks the whole decentralized concept and would add a single point of failure.
I've also implemented a transactions pool, that automatically filters out invalid (tampered) transactions, whenever a miner requests a sub set of them to stamp in a block. But does this mean that the miner for that only exception can tamper the transaction since it'll be "forged" in the block? So who gives a *** if it was tampered once it got in the chain? MEEEEEH that doesn't sound nice at all.
I'm terribly confused, and I'm dreaming key pairs at night. Please help me.
wouldn't a client generate a new wallet for "his" blockchain each time it goes back online? If so, wouldn't this create a mess on the transactions signed on the chain? Since each miner (therefore peer) signing its own reward would use a different blockchain wallet than the other peers? Wouldn't this lead to any problems?
You don't say what problems you think this will lead to. I can't think of any.
For what I think is definitively more straightforward to use the fee amount to reward the miner, but this doesn't solve my doubts at all. Since the outputs of the transactions are signed upon creation, how could the peer initiating the transaction know upfront the possible miner who finds the block? And if he can't know it, how could possibly the miner "extract" its reward without tampering the transaction itself?
The simplest solution to this is for the transaction itself to just contain its inputs and outputs. The fee is the difference between the total inputs and the total outputs.
The miner just includes the transaction in the block of transactions they mine. They also add one additional transaction into the block, sending themselves the reward. Obviously, they know their own destination address. Every participant who receives the newly-mined block checks to make sure this transaction is valid (just as they check every other one) and doesn't claim a larger reward than is allowed.
And if the answer is not to generate a new wallet each time, where could you possibly store that very first private key of the chain's wallet where no one can see it, but still be able to use it, without having to put a server in the middle?
Typically in a file on the local disk. The private key isn't really needed anyway -- you only need it to send. You don't need it to mine or report. So it can be prompted for or decrypted only when actually needed.
Of course it could create a new transaction, and add that to the block. But who would sign that transaction? From where those reward tokens come?
The usual rule is that the reward transaction has no inputs, one output, and no signature. The tokens come from the pool of unclaimed miner reward tokens which can be finite or infinite depending on the blockchain's design. (For bitcoin, this pool is finite.)