Uniswap Transaction Pending
Samantha Figueredo
My transaction's status is now "Drop and Replaced" but it still shows pending on Uniswap interface and I can not use the coins I wanted to swap. The "approve" button while trying to swap is now unclickable for that coin.
Swaps are the most common way of interacting with the Uniswap protocol. For end-users, swapping is straightforward: a user selects an ERC-20 token that they own and a token they would like to trade it for. Executing a swap sells the currently owned tokens for the proportional1 amount of the tokens desired, minus the swap fee, which is awarded to liquidity providers2. Swapping with the Uniswap protocol is a permissionless process.
note: Using web interfaces (websites) to swap via the Uniswap protocol can introduce additional permission structures, and may result in different execution behavior compared to using the Uniswap protocol directly. To learn more about the differences between the protocol and a web interface, see What is Uniswap.
In a traditional order-book market, a sizeable market-buy order may deplete the available liquidity of a prior limit-sell and continue to execute against a subsequent limit-sell order at a higher price. The result is the final execution price of the order is somewhere in between the two limit-sell prices against which the order was filled.
Price impact affects the execution price of a swap similarly but is a result of a different dynamic. When using an automated market maker, the relative value of one asset in terms of the other continuously shifts during the execution of a swap, leaving the final execution price somewhere between where the relative price started - and ended.
As the amount of liquidity available at different price points can vary, the price impact for a given swap size will change relative to the amount of liquidity available at any given point in price space. The greater the liquidity available at a given price, the lower the price impact for a given swap size. The lesser the liquidity available, the higher the price impact.
Approximate3 price impact is anticipated in real-time via the Uniswap interface, and warnings appear if unusually high price impact will occur during a swap. Anyone executing a swap will have the ability to assess the circumstances of price impact when needed.
The other relevant detail to consider when approaching swaps with the Uniswap protocol is slippage. Slippage is the term we use to describe alterations to a given price that could occur while a submitted transaction is pending.
When transactions are submitted to Ethereum, their order of execution is established by the amount of "gas" offered as a fee for executing each transaction. The higher the fee offered, the faster the transaction is executed. The transactions with a lower gas fee will remain pending for an indeterminate amount of time. During this time, the price environment in which the transaction will eventually be executed will change, as other swaps will be taking place.
Slippage tolerances establish a margin of change acceptable to the user beyond price impact. As long as the execution price is within the slippage range, e.g., %1, the transaction will be executed. If the execution price ends up outside of the accepted slippage range, the transaction will fail, and the swap will not occur.
A comparable situation in a traditional market would be a market-buy order executed after a delay. One can know the expected price of a market-buy order when submitted, but much can change in the time between submission and execution.
Price impact and slippage can both change while a transaction is pending, which is why we have built numerous safety checks into the Uniswap protocol to protect end-users from drastic changes in the execution environment of their swap. Some of the most commonly encountered safety checks:
Expired : A transaction error that occurs if a swap is pending longer than a predetermined deadline. The deadline is a point in time after which the swap will be canceled to protect against unusually long pending periods and the changes in price that typically accompany the passage of time.
INSUFFICIENT_OUTPUT_AMOUNT : When a user submits a swap, the Uniswap interface will send an estimate of how much of the purchased token the user should expect to receive. If the anticipated output amount of a swap does not match the estimate within a certain margin of error (the slippage tolerance), the swap will be canceled. This attempts to protect the user from any drastic and unfavorable price changes while their transaction is pending.
I have been using an exchange called uniswap and i thought my wallet was connected through metamask but turns out i had been using the crypto wallet on brave browser. I had also connected my metamask wallet to uniswap creating a conflict of interest with the two active wallets. I ended up trying to make a swap of tokens on the site and nothing worked at all. now i have 22 pending transactions i cannot cancel in my crypto brave browser wallet
I was trying to swap wrapped ether into MTA or meta. I do not think the use was with the assets i was swapping. I believe it had to do with the two wallets being connected at the same time cause all of the transactions to fail. but it kept all of the attempted transactions as pending in my crypto wallet effectively bogging my wallet with 22 failed transactions pending still. I am unable to cancel any of the transactions manually or send the tokens because even though the transactions were dropped from the network it still says pending within the wallet. @ryanml
As many of you know, the Uniswap Discord server receives a lot of questions from end-users. Prior to the UNI launch, the developers answered these questions but it was a huge drain on expensive developer resources, and there tended to be a large delay between a user asking for support and the user getting an answer due to time zones or the development team just trying to get work done.
Since the UNI launch, the Uniswap Discord server has become overrun with support inquiries and the Uniswap development team has almost entirely stopped answering questions, likely because they are overwhelmed with them. A number of community members have taken up the call and answer questions when they can, but their response time is still unreliable and their availability is limited.
Prior to the UNI launch, I had been using the Uniswap Discord server for training as the volume of questions in there was good for training and the class of questions was particularly representative of generic Ethereum questions. Around the time the UNI launch happened the first of my trainees were to the point where they could start answering some basic questions so I threw them to the wolves and had them help out with the UNI launch craziness and we started training the next batch. Since then, I have grown the team to 5 people, who are now scheduled across all days of the week and all hours of the day (with some breaks for lunch scattered about).
My original plan was to complete training and then propose that the Uniswap dev team hire my team. However, with the surprise launch of UNI, I thought that perhaps the new UNI community fund would be a better source of funding for this sort of endeavor as it seems to naturally align with community building and decentralized financing.
For this reason, I propose having the pricing plan for Uniswap be a bit different. Instead of charging monthly per message/question and denominating in USD, I propose that instead UNI governance sets up a drip of UNI as payment via something like Sablier, which governance could cancel if necessary.
For the reasons outlined above, and in order to mitigate risks for my business (UNI price risk and over-utilization risk) I would like to propose a Sablier UNI stream of 35,000 UNI over 365 days.
For this fee, Serveth Support ( or , website not live yet) would provide 24/7 coverage of all channels in the Uniswap Discord server except the foreign language channels and the development channels. We would provide answers to basic questions and triage and escalation services for more advanced questions. We would be available for almost all hours of the year, with exceptions for lunch breaks throughout the day and occasional unexpected service outages (e.g., power outages, death/dismemberment of a team member, etc.)
If there is sufficient interest in this proposal, I can draft the actual Solidity contract for it. I do not have the 10M UNI necessary to launch such a proposal though, and will wait until I hear whether there is general support before dedicating time to writing the code (writing the contract code alone probably costs a substantial portion of the proposed amount!)
The tentative plan for traditional clients was to just track (e.g., in a public Google Sheet or something) the questions answered by the support staff, each with a Discord link to the conversation. This would allow anyone to spot-check/audit the questions and answers if desired. That being said, that was more intended for the per-question billing model rather than the flat-rate billing model.
Users receive a prompt reply to almost all questions at all hours of the day. Either the question is answered directly by the support staff, or troubleshooting steps are followed and data is gathered for escalation to someone more capable at answering (e.g., me or dev team) for answer at a later time.
I believe this would first require UNI governance to somehow acquire USD, which is a very non-trivial operation. While I would not be opposed to payment denominated in USD, I worry that getting to a place where that is possible is a long way off.
Thanks for the replies and I agree with your point about transparency/public forum and the need for something like Discord. In which case I would suggest we implement a support widget on the front end that takes the user to the #support channel in Discord.
4a15465005