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

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!