Hello Sundae DAO Community!
Context
This is the first in a series of discussions / temperature checks as we approach the launch of the Sundae v3 smart contracts. We’ve been hard at work on these new contracts, building what we think is the best protocol, as it would be very hard and inefficient to design the whole protocol “by committee”.
However, we’re at a critical juncture where there’s still an amount of flexibility to change things, and some important decisions to be made about initial protocol parameters, and we wanted to seek validation / input from the DAO community about these decisions.
Note: You might ask, “Where are the v2 contracts?” Given the UI rewrite we did that was labeled as v2, and the second set of Plutus contracts we wrote but didn’t deploy, we’ve decided to call these contracts the v3 contracts to avoid confusion.
Background
For those who don’t know, Sundae v3 is a new set of smart contracts, with a focus on scalability (we’ve benchmarked the scoop sizes at 25 orders per batch, compared to the 2-4 orders per batch in v1) and extensibility (we want it to be possible to “add” new pool types to the protocol easily).
That scalability comes from switching to Aiken, and this gives us an opportunity to revisit the fees collected as part of each trade.
The more efficient contracts, and the larger batch sizes, mean that we can, in theory, dramatically reduce the fee while still covering the infrastructure costs for the scoopers. This could be pushed lower still by voting to use the new sources of income such as staking rewards to subsidize those infrastructure costs as well.
Lower fees would benefit users of the Sundae platform, and potentially attract more trade volume, and thus more TVL, to the protocol. Especially in a landscape dominated by dex aggregators, which search for these savings on behalf of users and puncture through “platform tribalism”, being competitive in the fee department could be an opportunity to attract a lot of attention to the new Sundae v3 contracts.
However, there’s also a growing sentiment in the Sundae community to establish some sort of protocol income, which can be used to pay SUNDAE token holders.
So, we (i.e. members of the DAO) need to decide what balance between protocol income, protocol incentives, infrastructure costs, and competitive fees we would like to strike.
How fees work in v1
In the v1 contracts, the user sets the fee they would like to pay in the datum; this has always been set at 2.5 ADA, and any fee lower than that is ignored by the scoopers. This 2.5 ADA is collected, used to pay the cardano transaction fee, and the remainder placed in a time-lock smart contract to be aggregated later and paid out to the scoopers.
As part of that aggregation, up to 20% of the collected fee is lost due to transaction fees.
So in practice, out of a 2.5 ADA fee, a scooper could be actually earning as little as 0.95 of that.
How fees work in v3
In the current implementation of the v3 contracts, protocol fees are dynamic, and split into two DAO-controlled parameters: The “base fee”, which must be collected for the protocol as part of each scoop, and the “incremental fee”, which must be collected by the protocol from each order.
The “base fee” gets shared among all participants in the scoop; so if there is just a single order, they pay the whole base fee, but if there are 25 orders in a batch, they each pay 1/25th of that fee.
The “incremental fee” is then paid by each user. The total fees are then collected into the pool itself, and can be paid out to the scooper in a large batch, removing the 20% overhead on fee collection that scoopers are currently paying.
The surplus of any fee allocated to the order that isn’t collected by the protocol is returned to the user as part of their swap. This is enforced by the smart contract, and not something that a scooper would have a decision in.
Staking Rewards
Additionally, it has always been the intention for the ADA held in the SUNDAE protocol to be staked, and for the DAO to vote on how those staking rewards get distributed. Due to a subtle bug that wasn’t noticed until after we launched, this hasn’t been possible.
The new contracts ensure that the staking address on a pool can be set, managed by a treasury administrator beholden to the DAO (for example to balance that delegation across multiple single pool operators), and withdrawn into a protocol treasury.
At the protocol’s current TVL of 20m ADA, that would represent roughly an additional 800,000 ADA in income a year (assuming a 4% staking return).
This ADA could be delegated to single pool operators (Sundae Labs’ recommendation), or it could be delegated to scoopers to help subsidize their infrastructure and reduce those fees even further.
As an aside, another question we intend to raise in the coming weeks is whether we should hold an election for a new set of scoopers. The existing scoopers have all served admirably, and we haven’t heard many calls from the DAO to replace them. However, the new contracts may lead to an increased interest in shaking up that cohort.
Comparisons
As a worked example, lets consider a typical “full” scoop with 4 orders currently (in theory, a scoop can be up to 8 orders, but in practice, in order to process orders on a “first-come-first-serve” basis, this needs to be cut in half)
(2.5 ADA * 4 - 1.3 ADA) * 0.8 = ~7 ADA per batch.
In order to make the same return to cover infrastructural costs, the combined per-user fee for a full batch could be as low as:
(7 ADA + 1.3 ADA transaction fee) / 25 = 0.332 ADA.
Similarly, for a “single order batch” (which are currently, unfortunately, the most common), this represents 0.96 ADA of income for the scoopers: (2.5 ADA - 1.2 ADA) * 0.8.
A single-order scoop in the v3 contracts currently has a transaction fee of 0.33 ADA, meaning that to produce the same income, the total fee would need to be 1.292 ADA.
Solving for choices of base fee and incremental fee that give these incomes can be seen here:
For example, a base fee of 1 and 0.292 would produce roughly the same income to cover infrastructural costs as the v1 protocol. At that rate, a user would never pay more than 1.292 ADA in transaction fees, and if volume against a given pool was very high, would actually pay closer to 0.34 ADA per order.
Conversely, if we left the protocol fees roughly the same as they are now (0 base fee, and 2.5 ADA incremental fee), it would result in between 1.2 ADA and 54.2 ADA per batch of additional income for the protocol, above what the scoopers are currently making, that could be directed towards protocol enriching activities that the DAO decided on.
Decision
The above analysis shows a general minimum that we can target if we would prefer to attract volume and TVL to the DEX, but would leave little room for incentive programs, nor would it produce any income for the protocol itself. Ultimately, the long term health of the protocol is dependent on eventually being able to derive revenue in a decentralized way that can invest in further development, incentive programs, protocol liquidity, etc.
So, that’s why we need your input:
- What are your opinions on this new fee structure?
- What methodology would you use to decide on these parameters?
- What would you set these two parameters to, using your methodology?
We’ll foster discussion for a few days, and then collate the most popular options and turn it into a temperature check and a governance vote following the normal approved governance procedures!
