Hey! Thanks for responding. Sorry in advance for the long post in advance haha.
I think I’m a bit confused with the intent of the system then, my apologies. I read it as an open system that anyone could opt into, basically some kind of “bounty board” of votes, where anyone can just go in and click "vote” on ‘available votes’, if that makes sense.
In my head, I was envisioning it having the same issues that Nubila’s “validator/auto-validator” system has. In there, validators can ‘validate’ the weather report from user’s Nubila weather tation. Doing so, validators earn rewards. Exactly how relayers (validators) would vote on users (the nubila devices) and earn rewards.
Their issue is that these validations go up each day, and every validation is instantly completed by bots for the rewards, leaving actual users unable to claim any rewards for themselves. With time, nobody bothers doing it manually as its pointless. All rewards are instantly taken by bots.
That’s what I envisioned this auto-voter system would face too. I (as someone who would definitely act as a relayer if possible) would go in and instantly see every vote already handled by bots. And therefore, my suggestions of anti-abuse mechanics.
The GM NFT of moon+ would act as the anti-bot mechanic in this case. The abuse I was envisioning was the scenario of there being no votes to cast as all votes have already been claimed by bots.
When you said ‘there won’t be many relayers’, I’m curious. It’s a missing piece of the puzzle for me. If it’s not open to anyone, how will the relayers be selected? If it’s open, I do think there will be many relayers (if the rewards are worth it of course).
This definitely highlights an interesting conversation. I agree that limiting the amounts of relay actions per wallet isn’t right, I forgot about the ‘rewards cap’ in the original proposal when I wrote that. It serves the same purpose without risking having votes unhandled.
The system is designed to compensate the relayer, with a set fee cap per wallet, and if there is no gating (moon nfts or otherwise), my worry is that someone will find a way to claim 99% of the relay rewards for themselves over multiple wallets (going around the rewards cap).
Every vote would be handled yes, but it would mean that they’re only handled by software from a few individuals and not spread out over multiple different relayers. And the rewards would be with the same few.
- The ‘good relayer’ in my example would be the people going into VBD on their own, completing votes as they’re available, and earning a fair reward for their time.
- The ‘bad relayer’ would be the person automating every vote and draining the rewards pool for themselves. Exactly what’s happened with the Nubila validation example above.
Both complete the vote for the users, yes, but the rewards end up in the hands of a few, leaving us with a centralized system in a sense.
But yes, if the goal of this is just to handle votes and to simply cover gas fees for the relayer, then sure, it doesn’t matter who does it.
Sure. It’s an UX issue, I can understand that. But when the user opts into auto-voting, a timestamp for when it expires could be added. And an in-app notification sent through VeWorld as it’s getting close to expiring/has expired. I think it’s a reasonable compromise personally.
This proposal specifically says that voting on proposals would be handled outside the voter/relayer system as those require thoughtful input, but in my opinion what dApps users vote for is of even higher importance than for/against/abstain on a proposal. So asking users to resubmit every three months (and requiring a new dapp selection in the process) makes sense.
A dApp currently lives and dies on getting votes (as there is no base allocation), and voter count matters monumentally. Proposals don’t care about the individual voters in the same way, they care about the %s of agreement. Therefore, it doesn’t make sense for me to design a system where a user could lock votes on 10 apps indefinitely.
veDelegate (and other solutions) can always do whatever, that’s true, but I think an official solution should aim to be better than its competitors and learn from mistakes already made (much harder to add time-restricted auto-voting after the fact).
I was going off the 10% relayer fee in the example scenario in the proposal (the b3tr going to the pool). That’s what the user will lose on using the auto-voting service, and that’s why I think it needs to be 1-5%, otherwise everyone would just keep using 3rd party services. Not the fee cap of raw B3TR that the relayer can claim.
That’s what I meant, sorry for the confusing wording. At minute one of the round, all relayers can then cast the votes then.
Disregarding any bots, if all current votes to handle show up at the first minute of the round, that would mean at 3AM my time (CEST), typically.
Unless there are votes to handle for multiple hours each round, that would mean it’s a useless system for me (and most of Europe) to partake in as all possible rewards for the round would be claimed by the time I wake up.
Obviously that’s a hard scenario to design around, and if there are always votes to handle, it wouldn’t matter. I just figured it’d be worth bringing up 
Again, I think the proposed system has a lot of potential. I was mostly focused on the relayer side of things as I agree, all votes just needs to be handled. I just don’t want to see a world where all votes are handled within 1 minute each round by one individual with a bot, claiming all the relayer rewards over multiple wallets.