[CONTRACT UPGRADE] Ref Swap Accommodate Taxes on NEP-141 Tokens - NEKO

Miao! Miao! Hello NEAR and Ref Fam :heart_eyes_cat:

Background:
On 7/1/22 we submitted our initial proposal to the Ref Gov Forum to upgrade the Ref Contract to accommodate a token tax. Per comments from @beng on the first proposal, we realized that changes were required to the NEKO contract from our end. On 7/16/22, we released a NEKO v2 contract ftv2.nekotoken.near which includes two major upgrades:

  1. NEKO token v2 is updated with 24 decimals (NEAR standard). This change is what required the v2 contract.

  2. NEKO tax information is added to the token metadata. Tax info is now under tax_rate in nft_metadata
    The tax rate is dynamic and can be adjusted externally by admin without re deploying the contract.

The NEKO v2 contract upgrades addressed the issues noted by @beng in our initial proposal. Now the NEKO token open source code can be the standard for tax tokens on NEAR!

We submitted an updated proposal on 8/11/22 to get the ball rolling on the Ref contract upgrade per the NEKO v2 contract. However, we never received a response from the Ref Team.

Introduction:
NEKO token is the first on NEAR to include a tax component within the token economics. In the NEKO tokenomics there is a 5% tax on every swap. Half (2.5%) of the NEKO tax is automatically burned; creating a deflationary mechanic. The remaining 2.5% NEKO tax is deposited into the Fortune Cookie Vault where it is distributed back to the community.

Taxes are an important component for many token economies to balance inflationary emissions. Major AMMs such as Pancake Swap accommodate token taxes via slippage adjustments. The buyer/seller must adjust slippage to accommodate the tax to execute the transaction.

The NEKO tax distribution is verifiable on chain. The burn and transfer to vault are logged inside every swap transaction receipt. Also, the NEKO tax percentage reduces over time as the emissions rate declines. This balances deflationary and inflationary pressures.

Conclusion:
This contract upgrade can be implemented for future tokens that utilize a tax to balance their token economy. The upgrade will allow tokens with more advanced tokenomics to flourish and evolve on NEAR Protocol. There has been at least one project that moved operations from NEAR to another chain due to the lack of token tax support by top AMMs. This is hurting the growth of the NEAR ecosystem.

We are preparing to issue NEKO token grants to ecosystem partners to use as rewards for their onboarding programs. It is time to make NEKO token tradable within the NEAR ecosystem and we propose beginning this endeavor on Ref Finance with a NEKO liquidity pool.

We are looking forward to discussing the next steps!

Initial Proposal on 7/1/22

Revised proposal per NEKO v2 upgrade on 8/11/22

1 Like

@AVB @beng following up


:point_up:t4: This in and of itself is concerning.

If a project token, especially a meme coin, requires taxes to sustain the project, then it is inherently flawed, IMHO.

Overall, allowing taxes on token trades is a slippery slope; one which I stand in strong opposition of.

Hey @Rekt, I appreciate your insights and comment! The topic of taxes in Web3 token economies is certainly divisive. This stems from many of the popular tax tokens operating in bad faith for where the fees from taxes end up (i.e. dev wallets). However, this is not the case for NEKO. My only ask is that you keep an open mind and allow yourself to look at the NEKO tokenomics from a non-biased perspective. Please read through the NEKO litepaper for all the details.

NEKO holders benefit from substantial ecosystem rewards including farming, learn to earn, content creation and more. The tax on NEKO when sold balances these inflationary rewards to facilitate a sustainable environment that NEKO can flourish in. Additionally, the fees from taxes go to directly benefit holders (half the tax is burned and half is distributed back to staked COOKIE=NEKO). One could argue NOT having a token tax is much worse for holders. We all know inflation is a killer and nearly every crypto token charts reflect this.

NEKO holders are willing participants of this token economy and our community is happy to pay a small fee when they sell to reap significant rewards in a more balanced manner. As noted in the proposal, the tax % trends to zero in relation to the NEKO emissions declining.

Let’s examine the facts. First of all, it is our strong community and hardworking content creators that sustain the Neko project, not the token tax. I’m not sure if you are aware of Neko, but we have grown one of the largest NEAR native communities. We have onboarded crypto content creators with large existing audiences and created hundreds of educational videos about the NEAR ecosystem.

Viewers are rewarded in NEKO to engage with Neko content and we have reached tens of thousands of new users via TikTok, Instagram Reels, YouTube Shorts and Reddit. Neko is so much more than a meme coin. The NEKO token tax is only a small component of the project and again it is designed to specifically reward holders. We are also gearing up to distribute NEKO token grants to several NEAR projects to assist with their onboarding programs.

The Neko community started with the Good Fortune Felines NFT collection and has grown significantly from this foundation. We published the NEKO litepaper before anyone could mint a Good Fortune Feline. We made sure our community was onboard with the NEKO token tax before any investment was possible.

You may not agree with the concept, but no one is asking you to join the community or hold NEKO (although we would love it if you did! :heart_eyes_cat:). It is not very decentralized to put your preconceived notions ahead of a community seeking the opportunity to trade the token they have been earning for months. Essentially, you are saying you are in strong opposition of a free market and I’m sure that is not your intention.

Thank you for your time,

@dleer_defi - Neko Co-Founder

Could be proposed as a standard. Until it’s adopted as NEP across projects it’s a specification :nerd_face:

Which was that (out of curiosity)?

How is a token tax alarming?

The deflationary/inflationary balance makes sense to me. As emission falls so does the tax.

I’m for more financial primitives, especially ones that enable multiple projects.

The changes you are requesting need to be done at the client/site, not the contract. Your token contract will extract the tax from the amount sent from the user account before the ref contract receives it. When a user swaps from another token to yours, your token contract will extract the tax from the amount sent from the ref contract before the user account receives it. The client/site needs to take the tax into account when it shows swap/lp amounts to the user, and in the instructions sent to the ref contract.

If they haven’t already, your devs should test actions with your token on the ref exchange contract using the near api or near cli. They can also test using the REF SDK in addition to the near api/cli. The testnet contract address is ref-finance-101.testnet, and they will use ft_transfer_call for swaps and deposits into pools.

They should include tests designed to fail: If a swap or liquidity deposit fails, does the user get the full amount back, does/should your contract keep the tax, does/should your contract also tax the tokens sent back to the user? What happens if you try to swap or deposit 1 yoctoNEKO? What happens if a swap, or withdrawing liquidity, results in the ref contract sending you 1 yoctoNEKO?

Have you looked into creating a NEAR Enhancement Proposal? If not, maybe post on the near governance site asking about this.

I am not on the dev team, and have no idea how willing they will be to change the ref site to handle tokens with tax. It may help if your devs created a fork/branch of the ref website, made the necessary changes to handle your token, and created an issue and/or pull request with the changes. Again, I am not on the dev team and do not know if this will help.

Hey @taoist.near thank you for the comment!

I can’t remember the name of the project anymore :rofl:

There has been at least one project that moved operations from NEAR to another chain due to the lack of token tax support by top AMMs.

That section was pulled from our initial proposal on 7/1 and now I can’t remember the project name. I do know they moved to BSC though.

Hey @Rekt not sure if you saw our response to your comment. It was flagged and hidden for a few days but is back now.

Hey @beng you are 100% right, the tax is accomplished at the client/site.

The “Contract Upgrade” description on the proposal isn’t the correct language. Instead, this is a front end adjustment.

On Ref Testnet, we can execute a NEKO token swap with 5% tax (link to transaction). The transaction will execute if the user selects a swap amount that accommodates the 5% tax. However, the transaction will fail if the user selects the “max swap” amount
 this is what we are proposing to change.

If the user selects “max swap” amount the error message returns below:

{"index":0,"kind":{"ExecutionError":"Smart contract panicked: The account doesn't have enough NEKO to cover Tax, please lower your swap amount"}}

We propose Ref Finance front end to calculate the tax amount (5%) per metadata and enter the delta when a user selects “max swap.”

For example, if a user selects max swap for 1000 NEKO, the max amount displayed will add up to the following:

Max swap amount with 5% tax per metadata = [ total NEKO own / 1+ 0.05(tax) ]

1000 / 1.05 = 952.3809523809524

Ref Front end displays 952.380952 NEKO in the swap field when max swap of 1000 NEKO is selected.