V6.4 NFT Bot Rewards Scheme Proposal

V6.4 NFT Bot Rewards Scheme Proposal.md

Issues with V6 approach

• Each NFT should appear only once in the winning block
• Rewards pool exploitation with the immediate LIMIT orders
• Current scheme has led to gas wars
  • We need data to show the percentage of the gns rewards that are sold for matic fees (the same also for the paid LINK)
• Bad actors are front/back running successful bots
• NFTs are losing value since they can not be profitable in the bot arena for most people
• Generally, create a new scheme that will stop being the playground for bad / greedy actors

NFT Bot Ecosystem Focus

• The security of the platform (no trigger is missed)
  • with lookback history checking there is no need for in-time triggers (almost in-time triggers will be as effective)
• The decentralization of the platform
  • any NFT holder run his/her own bot supporting the platform
• The lowest maintenance cost for the botters in time/value/fee predictability
• A hassle-free client
• The least leakage of GNS value to other protocols/platforms (i.e., reduced fees)
• A constant, sustainable and fair reward fee for all active / legit botters
• A successful use-case of NFTs and their tiers

Pillars

• Implement oracle lookback feature for supporting guaranteed SLs/TPs/LIQs/LIMIT
  • Eliminates / reduces bot misfires and provides guaranteed SLs/TPs/Limits
• Fair distribution of rewards to all bots that secure the protocol
  • Eliminate front-running / gas wars / bad actors
• Equal treatment for all positions, independent of their size (better UX)
• Better utilization / performance of LINK nodes
• Add value to NFTs
• More bots, more decentralization, more platform security
• Reduce rewards since there will be no misfires
  • Use part of the rewards to support SSS
• Stable LINK fee for all triggers (fee should not be correlated to position size)
• NFT tiers affect rewards

Proposal

• Rewards are distributed in rounds (like now)
• We have only one pool of rewards
• For each successful trigger we hold all bots and their NFTs that could potentially trigger in the winning block (see below)
• The bot that first triggers a TP/SL/LIQ/LIMIT pays the LINK for this trigger
  • If the trigger is successful (using the look-back feature), the bot is repayed the LINK & MATIC fee with minted GNS of the same value
  • Else, in the case of an unsuccessful trigger, the fees are paid by the bot
• If trigger is successful, the reward of the trigger is added to the pool of rewards
• All same block bots for a successful trigger (including the triggering bot), that have the needed amount of MATIC/ LINK for triggering the action, get a ticket to partipate in the rewards (each NFT only once)
  • For each NFT that they hold they get a ticket
  • We can consider the tier of the NFTs for the reward, using weighted tickets (i.e. a diamond NFT gets more than a bronze, e.g., x2)
  • If they don't have the required LINK / MATIC they do not get any ticket (since they can't secure the platform)
• At the end of each round, consisting of X successful triggers, the bots and their NFTs share the rewards based on the sum of tickets they have
• The required LINK for each trigger is the same, irrespectively of the position size (more security for the platform)
• There is no need for NFT timeouts so we can remove them
• Rewards can be reduced since there are no misfires and the approach should be much more capital efficient

Possible Exploits

• Winning Block In the extreme case that the rewards are earned by just a few bots due to MEV we can enforce fairness by considering also the triggers in the next block, etc.
• Winning Block The max number of txs per block in polygon, might also be a problem for this approach due to its limited size (~100). We might need to check for triggers in more than one block to mitigate this. For example, a botter can have x bots with one NFT in each, pay a lot of gas and populate most of the block, leaving the rest botters out. In this way he will get one ticket for sure.
• Winning Block Spam transactions to fill the current / next block. Hopefully they have to spend a lot of gas, since the bots will use a fast gas setting and polygon will allow for more txs / block in the future?
• Leaking GNS Make sure the repayed MATIC fee is not extraordinary, i.e. at most the fastest gwei

OPEN ISSUES

• MEV
  • https://ethereum.org/en/developers/docs/mev/#:~:text=Maximal%20extractable%20value%20(MEV)%20refers,of%20transactions%20in%20a%20block.
  • https://blog.marlin.org/introducing-mev-support-for-polygon
  • https://www.blocknative.com/blog/mev-and-creating-a-basic-arbitrage-bot-on-ethereum-mainnet

There absolutely needs to be a mechanism of running the bots without exposing the private keys to the computer. This is really critical IMO. If someone gets hacked, downloads malware, anything like that, we could see permanent - or at absolute minimum weeks - of platform nonfunction. Even worse if somehow this affects ALL bots through a dependency vulnerability. If it did, we could see the platform become nonfunctional until seb could modify and republish the NFT contracts. It would be an absolute disaster. Beyond everything else - this is the thing that needs to be addressed.

The solution is clear to me: Allow each NFT to be assigned to another address to run it. This isnt a difficult implementation. This way the owner with their private key can assign it using a hardware wallet, then store that safely while using the exposed private key to bot with.
Unfortunately there is really no other way unless someone builds some software integrating a hardware wallet to the bot software.
This does mean that there could become a market for assigning to other people. I don't see a way around this except putting a lengthy timelock on the assignment - I would suggest a month - however there would also ideally need to be a mechanism to override this time lock if there was sufficient support for it - because if a dependency vulnerability happened we wouldn't want them all time locked either.

To add further to Asterions proposal:

• If our botting LINK is held in the contract, then an unsuccessful trigger could be debited against the botter, but a successful trigger could just be equally debited from all addresses in that block.
• This would dramatically smooth LINK spending and equalise positions e.g. no incentive to backrun.
• The downside would be having the first person pay all LINK infact encourages people to NOT be first for their profit margin - which in theory would mean an incentive to spend less gas, however I feel it will just result in first person spending 1000 Gwei and next spending 999.9999 so it will be negligible anyway.

== PLANNING REWARD POLICY ==
2. Shared block rewards?
c) Indefinite number of bots eligible, limit number selected randomly. (Ideal solution IMO but have to see if it is possible with Seb).

4. Reward structure (planning-reward-policy)
   b) Forward-looking entitlement to a future reward (as explained with my post with rainbow charts)

I would propose that there is a forward facing allocation of rewards. When you trigger you share a portion of the 8th 10th reward in the future.

• It is very very difficult to know what the 10th reward in the future will be, you have to guarantee you can predic

• It can be smoothed over orders easily by sharing a portion of the 8th to 10th orders.

• See below where each colour represents a group of people who all triggered in the winning block (with the colour squiggle to show). and the vertical bars represent the relevant trades.
  

• In the second example the reward portions are shifted into the future and distributed from each order triggered for a further 8 orders.
  

• However, as this gives anyone triggering a period of time in the future they could possibly increase gas if one is coming up

• Therefore it would be even further suitable to have a short time period which is relatively longer in the future.

• In the next example the reward is smoothed over 5 orders for instance, but don't start until 8 orders ahead of the order.
  

• If we wanted it to be even harder, just make this trades 12-15 after the winning one. Could be equal portions or weighted over those few, the main thing is the future is hard to predict.

• The whole point is this portion should be distributed to a limited number of people in the block - Remember, theres no front running if theres no advantage!