Hello Ref Community! We are back again with the final piece of the puzzle for the upgrades needed for Ref to accommodate a token tax on swaps.
To preface, we will be launching the NEKO liquidity pool on Ref shortly, there are already a lot of NEKO holders and tons of excitement around the token go-live! We anticipate the launch of the NEKO LP will drive a lot of volume to Ref and would love to also setup a farm to further incentivize and reward LP’s in the early stages.
Back to the tax upgrade - The NEKO tax does work when swapping on Ref. However, there is a critical UX flaw that we are proposing to solve. Users cannot select their maximum balance to swap because they must leave room for the token tax. The transaction will not execute unless the user maintains a balance for the tax to be taken from. This is very unintuitive and many users will have substantial difficulties when swapping. Therefore, we propose a front end upgrade that will enable users to swap with their entire balance, just like they would with any other token.
Example:
Let’s say Alice has 1000 NEKO and wants to swap it all. Currently, the website will enter 1000 for her when she clicks the max button. This will return an error from the NEKO contract when Alice attempts to swap because there is no NEKO being allocated for the token tax.
We want the website to calculate the tax amount of 5%, as defined in the token metadata, and enter the amount that will add up to 1000 NEKO (or closest) for Alice when she clicks max.
When Alice clicks max with 5%(0.05) tax [ total NEKO own / 1+ 0.05(tax) ] = swap amount 1000 / 1.05 = 952.3809523809524 it will put 952.380952 for Alice in the swap field
Note that a token tax is an integral component in many token economic frameworks and we believe it is important for Ref to support this as the leading AMM platform on NEAR. We have worked through several iterations of the Neko token code to establish the best possible NEP-141 token solution for token tax, within the metadata, which we will open source for the entire community to use.
I added this as a topic to discuss during next week’s dev meeting.
But here are some of my thoughts and questions:
It’s possible/likely that users will believe there is a bug with the ref site, and then type 1000 in manually. When the swap fails they may blame it on a bug with the ref site as well.
It’s not just the maximum balance. Alice cannot swap any amount above 952.380952.
There are two other issues I see with the approach of the tax being taken directly out of the user’s wallet. The first is that users who want to swap and be left with a specific amount, like 100 NEKO, will have to know what the tax is, and calculate the amount to swap so that they end up with the amount they want to keep.
The second, and imho bigger, issue is that the amount of tokens that will be removed from a user’s wallet is different from the amount they signed/approved for the transaction. If I had 1000 tokens, and approved a tx to swap 500, I expect to have 500 left in my wallet. If I end up with 475 I would assume it’s ref’s fault, and complain on the ref telegram/discord about ref taking more tokens than I approved.
Do all tax tokens work like this? Have you asked for feedback or advice from the near development team(s)/communities? Especially those who contributed to the fungible token standard(s)?
I second @beng thoughts as well.
Why can’t the tax be taken from the input amount. That’s how swap fees work on DEXes. Alice has 1000, she inputs 1000, sends 1000, the contract takes its tax (assuming 5%) so only 950 tokens are sent to be swapped. The only problem I anticipate with this is that Ref’s frontend will be calculating minAmountOut based on 1000 input tokens, so swaps might fail, but it can be solved by having users increase their slippage tolerance to be close to the tax amount. Would this work?
Another question I have is that $NEKO is a single curious case that needs lots of refactoring on Ref’s frontend, have you thought of running your own swapping frontend? depending on the licensing you might be able to fork existing frontends such as Ref’s or Skyward’s and incorporate your changes. You can even start getting referral fees on swaps done from your UI.
For a quick update, we have been discussing with @beng and the Ref Team directly and our plan is to review the Neko Tax Token Contract with NEAR Core Developers who contributed to the NEP token standards we have now.
The goal is to create a best practice solution for tax tokens on NEAR.