Scooper Payment Agreement - Discussion

1

Hello Sundae DAO Community!

With the launch of Sundae v3, fees are now collected to the protocol itself, rather than accumulated to the scoopers. This means that currently, they are graciously running the v3 protocol without set terms for their payment, and I think that’s a thing we should rectify quickly.

Based on discussions and estimates from a number of scoopers (here and here), it seems that the infrastructure for 30 scoopers is around 16500 ADA a month, not counting labor.

Additionally, the DAO voted and the scoopers agreed to run the protocol with a 50% discount in protocol fees for the interim, in order to attract some attention and give people a chance to try Sundae v3.

It’s still very early to estimate projections for treasury income, but as this discussion plays out and we collect more data, we will share some projections on protocol revenue.

We anticipate that this structure will need to be revised and re-evaluated at different points throughout the lifecycle of Sundae v3, as protocol revenue increases, and as the price of ADA fluctuates; in the early stages, as we attract liquidity and volume, protocol revenue is likely to be lower, and so higher percentages of the treasury will need to be spent to ensure the scoopers keep the protocol operational.

Based on that, we propose the following payment structure for the scoopers, though we invite input from the community and the scoopers themselves:

  • Collectively, scoopers are paid the following amounts (until re-evaluated by the DAO)
    • 50% of all protocol revenue if protocol revenue in that month is less than 33,000 ADA
    • 16,500 ADA + 10% of protocol revenue otherwise
  • This ADA will be withdrawn and distributed by the treasury administrator (currently Sundae Labs) on a monthly basis
  • The treasury administrator will be paid 1% of the protocol revenue, up to a maximum of 3000 ADA, for performing this service
  • This portion will be distributed among all “active scoopers”
    • First, scoopers will be repaid for any transaction fees for any scoops they performed
    • Next, the remaining funds will be split evenly
    • Active scooper is defined as any scooper that:
      • produces at least 5 scoops during that month
      • has an 80% uptime or better, where uptime is determined by the scooper software hitting a Sundae Labs API for each “missed scoop”
      • any scooper that is “inactive” for 3 months will be removed as a scooper, and must be reinstated by a DAO vote
  • Any credible report of malicious activity will freeze any scooper rewards to that scooper until the DAO can adjudicate the status of that scooper
    • Credibility of said report will be adjudicated by the treasury administrator

In particular, the even split is to avoid infighting among the scoopers, while the uptime requirements are to prevent freeloaders and to encourage a robust and available infrastructure.

Let me know your thoughts!

5 Likes
2

Hi,

Indeed payment to run the protocol need to be set first. We can decide what to do with remaining revenue later.
Seems good to me but I am no scooper ^^ So let’s see what they think.

3

Also not a scooper but I like the framework here. Perhaps its upped to 50% for the first 40k to give a little towards labor ( I dont know how intensive this part is). This would give 3500 ADA/month towards labor. Also how often should this be re-evaluated? Every Month? Every Quarter? Thoughts?

4

Active Scooper

While I agree on the 80% uptime, I’m not sure a fixed number of scoops is a good indication of the efficiency of a scooper. I think a % of the total scoops would be a better metric. Something like 1 to 2 % of the total scoops.
Ideally we’d want a group of scoopers that, once ironed out discrepancies due to the software, they perform similarly.

Scooper collective compensation

For the v3 bootstrap phase, the suggested compensation feels fair to me.

Profit after costs repartition

What do you mean by:

Next, the remaining funds will be split evenly

Would all active scoopers receive the same fraction of the total? Or would it be proportional to the number of scoops?

I would personally split proportional to the number of scoops to better compensate who spends time and resources to implement the best setup.

5

Hi, my name is Matticus. I run the :kiwi_fruit:Kiwipool Staking Scooper

Can you please advise, Pi, roughly how long we have before a decision is made as I’d like to take some time to analyse what is proposed and formulate my thoughts further before adding comments?

This means that currently, they are graciously running the v3 protocol without set terms for their payment, and I think that’s a thing we should rectify quickly.

I think it is important that our focus be primarily on getting this right rather being quick and if we can do both, then great. So hopefully this won’t be rushed

M

6

However long the DAO/Scoopers want to deliberate on this is fine by me.

That being said, we can update the policy if it’s not working. So I don’t think going extra slow is going to buy us any insights that seeing it deployed in practice won’t. And the protocol revenue is small right now, so it’s not like we’ll be handing out tons of funds if the system we pick is inequitable in some way.

7

My main concern is that I don’t want it to devolve into in-fighting over who is getting the most scoops; given the average of 20s between blocks, the protocol health isn’t determined by how fast someone produces the scoop, but distributing proportional to number of scoops creates a race for people to run beefier (and more expensive) hardware. This in turn means that the scoopers expect higher payouts from the protocol to cover their costs, etc.

The main benefit that more scoopers provide is availability; i.e. they will be there to produce a scoop if someone else isn’t.

How about we distribute it proportional to attempted scoops? That is, Sundae Labs runs an API where scoopers can post their failed scoops to, as we will for the “active” determination. Then, we count the number of scoops sent within 5s of the one that made it on chain, and distribute proportional to that.

This is far less subject to arguing over millisecond timings in the scooper logic, doesn’t require us to implement ouroboros to select a scooper, and also attempts to optimize the availability of the protocol, rather than the speed.

3 Likes
8

As a SundaeSwap Scooper, I prefer the idea of being remunerated based on the amount of attempted scoop as opposed to actual number of scoop produced.

I think it’s a much better proposition in terms of keeping Scoopers incentivised to run their infrastructure and serving the protocol, without feeling the need to battle for milliseconds. The consistency in reward distribution will also make sure that everyone monitors their infrastructure more closely. Someone who is consistently producing a handful of scoops (due to his/her server being located in a disadvantageous place for example) and is paid accordingly, is less likely to care and make sure that his/her Scooper is working as it should be and serving the protocol (providing availability).

So, I vote for Pi’s idea until someone has a better idea. @Pi, will, it require a lot of time to setup the API that tracks failed and active scoops?

1 Like
9

This makes sense to me and definitely worth giving it a go.

Should the team not have capacity to implement such api, would you consider outsourcing? If you do, would you accept any programming language like java/scala?

1 Like
10

Hey everyone, Martin here, active Scooper.

I am doing well with the v1 Scoops, but i am fully supporting a shared revenue schema between all active scoopers for the new v3 protocol. As we have seen so far on the first days of using v3 on mainnet, the v3 scoops are super fast, thats awesome. But, it also introduces a new “fight against each other” between the scoopers. Its about fighting for the last few milliseconds to be faster than the next scooper. We had that situation back when we started with v1 scoops, and i hated it. To keep v3 scoops fast, we can’t throttle scoopers down from scooping, like we do with v1 scoops. So i totally support the idea to share the revenue across active scooper, who are sending a proof via the sundae-api that they tried to make a transaction, but another one was faster. The scooper software can read out various statistics from the connected node, so that scoopers are not setting up a “blind” node with only one or two peers to get the revenue share. The setup should be decent. We could also introduce automated tests with the scooper software for special scoops that are only ment to be scooped by a specific scooper to check that the scooper infra is doing well.

2 Likes
11

From Eric, AzureADA, another scooper:
Just to give some background for non-scoopers. There is some amazing skill and talent among the scoopers. It’s literally most of the original “who’s who” of the Cardano space, who have contributed widely-used tools to the community. I know I have put hundreds of hours into running a scooper trying to eek out more performance and have paid more than $3,000 USD for computing costs to date. And others have put in more hours than I have, I’m sure. I continually pay attention to and monitor performance in an effort to stay competitive.

I agree with Pi that the primary benefit of having a fleet of competently run scoopers is availability and user experience. We want scooper computers distributed around the globe, to handle any regional outages. If we reward proportional to number of blocks, there is pressure to move servers to geographic locations that are closest to API endpoints or otherwise shave milliseconds off scooping time, which we’ve seen. This has lead at times to literally multiple scoopers in the same data center as the API server. As has been pointed out, the difference between having a scoop accepted or not can be milliseconds. A race car passing the finish line 1 millisecond behind the leader is not a slouch, it is still a fast race car. Probably most scooper setups are on legit high-quality equipment that is run well.

I do like the idea of “proof of trying”, where we ensure that the scoopers are all maintaining equipment that performs well and are monitoring and paying attention to the infrastructure that ultimately provides SundaeSwap’s customers with excellent performance. True, we don’t want scoopers to slack off and have sub-standard setups, but as the race car analogy points out, we have MANY race cars here that are being run well, whose owners have put a lot of time and effort into tuning. I think the proposed solution to equalize rewards and also ensure that everyone is still on the race track, not sleeping in the pit stop is great.

1 Like
12

Thanks for your input Eric and Martin;

Barring any major objections, i’ll turn this proposal into a temperature check pending a governance vote tomorrow!

2 Likes
13

Not only does Sundae have a high calibre of technical expertise in their scooper operators but also outstanding human beings. This has led Sundae into a position where we are collectively very efficient at getting scoops into blocks and will ensure we are well placed during periods of heavy congestion.

The calibre of people involved also should give us great confidence that we’ll collectively maintain the high standards that we’ve set over the first two years so I’m in support of your proposal and looking forward to the new era.

As always, thank you for the opportunity to be a scooper and Vive la Sundae! :ice_cream:

1 Like
14

Ray here, GROW pool, scooper from day 1 :ice_cream:

I’m in general agreement with the comments made by other scoopers so far on this topic. Providing decentralized infrastructure to support a performant platform is our mission. We can do that even more efficiently now with v3.

I’m confident the scooper team will come together and approve a distribution of protocol revenue that is fair and supports sustained high performance scooper infrastructure. In this case the overall sentiment is even distribution of protocol revenue to scoopers that demonstrate high availability.

Having a DAO in place to cast our votes and welcome the larger community to do so is a win-win for us all.

Congratulations on a smooth launch. After running a tour of DEXs on Cardano, Sundae presently has the best prices and performance around on top of stellar yield farming and token launching services. I anticipate word to get out to users, we’ve come a long ways!