- 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
- 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
- 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
- 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
- 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
== 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).
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!