I deployed a ERC-20-Token, added liquidity to Uniswap v2, then called functions to change the max transaction amount and max wallet amount and renounced ownership of the contract thereafter. As I quickly noticed, I made a massive mistake - I forgot to add the decimals for the uint256 inputs for the max transaction / max wallet, which now has resulted in the maximum transaction and wallet amount becoming 1 token (actually I tried this out and sending 1 doesn't work, but sending 0.999999... works). Obviously, the contract can't be changed any more and the project is basically paralyzed.
Now that I want to relaunch this project with a proper contract, obviously I somehow need to get my hands on that liquidity. Casually removing liquidity isn't an option, because there are hundreds of millions of tokens in the liquidity pool - the max tx/wallet is only 1 token.
I now came to the idea to migrate the LP to Uniswap v3. There, I can select a price range for the token - if the min price is significantly higher than the current price, in theory I could get refunded the ETH that is into the LP, leaving all of the other tokens in the LP. I can approve the migration function, but ultimately it doesn't let me execute it - I assume a problem could be here, that usually when migrating to v3 you get refunded at least a small portion of both tokens because of rounding issues - although though faulty design of my contract I can only receive an amount of token that is less than 1. I already split up my LP token so that my main LP holding contains a round number of the token so maybe there is no refund of the token needed and I get only a refund of one side of the LP - but I still can't press the button to execute the function.
Is there any way to get the ETH of the liquidity pool back, maybe through migrating to v3 using a specific way / any other options?
I have once come across this problem, but later found a solution to it, increase slippage to 49% and increase the token allowance. If it does work, follow this video https://www.youtube.com/watch?v=dXsZWbppoSA it really helped me a long way!
Related
I am trying to display a users transaction history in binance, including fund deposits and withdrawals as well as buying and selling of different crypto's. Does anyone know which binance API endpoints I would use to do this? It seems quite complicated in comparison to other trading platforms.
Thanks
This is the link to the docs: https://binance-docs.github.io/apidocs/spot/en/#withdraw-history-supporting-network-user_data
I can see the Wallet endpoints "Withdraw" and "Deposit", but this won't cover crypto trading will it?, The account trade list call would be ideal, but it requires a symbol input which I'm not sure how I would obtain dynamically.
I would also like this endpoint to provide me with the data so I can get the avg buy price for a crypto
Currently this is not supported. See: https://dev.binance.vision/t/fetch-all-account-orders/279/3
This is the route you're looking for to get the user trade history. The big downside is that you have to specify the exchange symbol, you cannot get the history of the account with just one request:
https://binance-docs.github.io/apidocs/spot/en/#account-trade-list-user_data
Get your account information first. You can then extract non-zero balances from here to get symbols for transactions. You can then loop through each currency pair and get its transaction history. This seems to be the most optimistic way we can get right now
You can also try to use caching. For example, you can remember balance for a particular coin, and if it has not changed by the next launch, then it is likely (but not 100%) that no transactions were made with it
You can also connect to WebSocket, but this is still a terrible crutch and requires a DOS attack to get the necessary data
Please note that here the balances for Savings wallet have LD prefix added to their ticker. For example, BTC in the Savings wallet is labeled as LDBTC
I am trying to wrap my head around how Chainlink VRF integrates into Solidity contracts, such as in this randomly generated NFT tutorial: https://blog.chain.link/random-numbers-nft-erc721/
My question is around the actual funding of the oracle. In the Chainlink VRF documents, this warning is displayed: "Requesting randomness will fail unless your deployed contract has enough LINK to pay for it. Learn how to Acquire testnet LINK and Fund your contract." An example is given of how to fund the VRF contract with metamask and Remix.
However, I'm not really sure how this would work on a large scale. If you have an NFT "factory" that becomes very popular with potentially many requests per day/hour/minute, are you just expected to front run the funding of this VRF contract to avoid the aforementioned warning (seems like the costs would be non-trivial / hard to predict)?
Alternatively, if you wanted your NFT consumer to fund it, would you have to build in some logic that converts Ether to Link and then sends it to the oracle contract? (or make them go buy Link token?)
I could be looking at this the wrong way, but the scalability just doesn't seem well described in the documentation and only looked at from a testing / test network standpoint. Thank you.
You can:
Move the costs directly to the caller
Require LINK payment, or some other form of payment that will cover the costs of oracle request
Request the oracle data in a smaller frequency (if your use case allows it)
Are you receiving some price info from an oracle? Is it sufficient to update the price info once a day instead of once an hour?
Change your contract logic to not require (that much) oracle data
Does your factory really need off-chain random number generation? Wouldn't be sufficient to generate "random" number from the blockhash, difficulty, etc.?
My suggestion is, maybe a little awkward, but for the sake of decentralization, could work.
You charge your Contract1 with a sufficient link to get started
Charge every minter the equivalent link transaction cost in eth (+ the % that covers the costs of the trade to link and transfer between contracts)
As they mint, it is incorporated into the price and the eth is sent to Contract2.
In Contract2 simply exists a public callable function to initiate a swap for the link via routerV2 or a similar contract.
By placing a call to this function and contract, you can then just let any minter activate the swap contract function
The eth in Contract2 will be sent back to Contract1 as a link.
You could have a counter go and then call Contract2 every time the link fund is low and refill it automatically.
If you build it into the mint, then the inter will cover the fees.
I am just curious to know why Bitcoin developers choose a complicated approach like UTXO, rather than using the transaction models used by Ethereum Blockchain.
Basically, Bitcoin nodes maintain a set of all active UTXOs which have not been spent yet and any transaction that comes in is validated using this set. The nodes also update the UTXO set after every transaction.
This model is very analogous to how you'd implement a "wallet" which held currency notes and coins albeit with perfect traceability of each note in your wallet as to where you received it from! It is not complicated once you understand this basic analogy.
Consider the case where you have only a 20$ bill in your wallet. Let's say you buy a product worth 6$ with this 20$ bill. In this case, you will get BACK 14 $ in "change" and these notes are akin to the "unspent transaction outputs". These notes (UTXOs) can then be spent in any later transaction.
The advantage that UTXOs have is that each UTXO can be traced back right upto the point where the actual bitcoin was created (miner reward for example) and even upto the genesis block potentially.
This is akin to your being able to trace back the 20$ bill from where/whom you received it, and in succession being able to trace back how that person received this 20$ bill and so on and so forth until you traced it back to the Federal Reserve Bank mint where it was printed!
You can imagine how this would dramatically increase the security and trust in the system because you could validate each and every facet of a transaction.
However, this model was considered as not efficient enough for the Ethereum protocol which also has smart contract transactions which might execute frequently. Due to this, Ethereum went for a "Account state" based model which makes it far more efficient to calculate balances before and after transactions.
Here are some helpful links that might answer your question:
Considered as skewed towards a pro-ethereum viewpoint - https://ethereum.stackexchange.com/questions/326/what-are-the-pros-and-cons-of-ethereum-balances-vs-utxos
Also a Medium article which goes into more detailed comparison on the UTXO and Ethereum Account State model https://medium.com/#sunflora98/utxo-vs-account-balance-model-5e6470f4e0cf
Is it possible to anonymously programmatically verify that a transaction has reached n number of validations without running a full node? If so, what is the best means to do this?
Basically I want it to build a payment system where after the transfer is initially detected, the customer sees a message thanking them and telling them that their purchase will be processed within 24 hrs and that they'll receive an email once confirmation is complete. Then throughout the day maybe run a cron job that checks that each transaction reaches the desired number of validations and if so divide the money between two wallets and mark the product to be sent. I also don't want it to be with a service like Coinbase or Bitpay where they have control of your coins.
So far I've been experimenting with Blocktrail and mycelium gear. Both have some elements I like but still not everything that I need. With mycelium you can set the number of verifications but for instance if I want to set it for 6 verifications the customer would have to sit there possibly an hour before they see the next screen. Blocktrail allows me to query that a transaction is validated but it only has the ability to check that 1 validation was completed as far as I can tell. Can anyone suggest an API or widget that can accomplish these things? Preferably PHP or if not JQuery.
Blockchain.info has a simple Query API for querying how much bitcoin an address has received. You can add a confirmations=n parameter that will only include bitcoin that has been confirmed 'n' times. It returns a simple value in satoshis.
For example to check how much bitcoin was received with at least 2 confirmations at a specific address you could have your code query the API like this:
https://blockchain.info/q/getreceivedbyaddress/1PFtyX9nQvjP8U2N3iUk2oNorzPfpjX9sK?confirmations=2
I am making changes to my companies internal paysite in order to come into compliance with the new credit card regulations. We have decided that when we get a split tender transaction that comes through we want to get the remaining balance along with how much was on the card to start out with and send that info back to the customer service rep with a message relaying the need for another payment source along with the remaining balance and the amount that was originally on the card.
Instead of chaining the transactions together with the split tender Id we have decided we would like to finalize each split tender transaction with a prior_auth_capture and then request the next payment source and amount and process that transaction in the same manner. I know that we are side stepping the functionality some but those are my orders.
My questions are, is this feasible and possible and how do you do this in code? I am using the C# SDK to implement this in VB.NET 2008
My thoughts are that I would have to process the transaction for the amount passed as a auth_capture transaction and then some how do the prior_auth_transaction with a zero amount or something?
How would this work?
Thanks for much for your help.
James
This is not feasible to do. The purpose of split tender payments is to logically group together split payments into one transaction. By breaking it up into multiple transactions it can get confusing for you, the users, and the processor. Especially if you have issues getting the user to make full payment on their transaction. Failing to void the other transactions would be very problematic. This almost certainly will result in an increased exposure to chargebacks.