Possible Designs for a Decentralized Hosting Incentivization Model
TL;DR
To make the new Compound frontend truly decentralized, it needs to be hosted by a variety of users and community members similar to the nodes in a blockchain. Users may be willing to run the frontend locally for themselves for free so they can access their Compound Positions. However, non-technical users should also be able to visit a Compound frontend run by another community member via a web address. Anyone hosting the frontend will incur costs each time the site is visited, from server bills to RPC node fees.
To encourage sustainable participation, we need to create an incentivization model that allows those hosting the front end for the community to profit from doing so … and at minimum covers their costs. For reference, currently more than $10,000/month is spent on RPC node calls by current compound users, a single component of the overall cost of delivering a sleek real-time user experience to Compound users.
Below are the possible incentivization models and our considerations.
Incentivization Models
Model 1: Fixed Grant
A fixed grant (e.g., $500) is provided to host the frontend for a set amount of time (e.g. 1 year).
Pros:
- Easy to award to many community members.
Cons:
- It doesn’t account for the variable costs of hosting a frontend. The more users this frontend serves and the faster the server responds, the more cost this frontend will incur. To remain profitable this frontend is incentivized to be slow and unavailable, to reduce their variable costs and maximize their profit.
Who pays: Compound DAO Treasury
Recommendation: Not an appropriate solution
Model 2: Flat Fee Per Transaction Type
The costs incurred from hosting compound.finance are divided by the total number of on-chain actions the compound.finance has processed. Compound DAO uses this information to publish a lookup table estimating the cost of every on-chain transaction type in terms of infrastructure cost:
- For example opening a new position might cost $0.10 (server fees + 34 PRC calls on Average + 2 Write RPC calls)
- While withdrawing might cost $0.05 because people need less research when they close a position and therefore less RPC calls)
Each frontend includes a unique piece of metadata in the transactions they process, and the Compound DAO automatically pays out frontends in proportion to the transactions they process.
Who pays: Compound DAO Treasury
Pros:
- Variable payment for variable traffic encourages hosts to provide the best & fastest user experience. If they become known as the best host they will attract more traffic and more revenue.
- Fixed cost per action doesn’t discriminate between users depositing $10 or $10M and doesn’t discourage whales from using the frontend by taking a % that becomes a massive overpayment when large amounts are deposited.
Cons:
- If the Reward for processing a transaction is greater than the gas fee + actual expenses. The system encourages pushing fake transactions. These should be easy to spot, could also limit the amount a frontend is capable of earning during set periods to encourage open dialog with the host who will ask for an increase if seeing greater than expected volumes.
We recommend this option because:
It encourages hosts to provide the best hardware and lowest latency for the best user experience so visitors take more on-chain actions. More traffic means the host gets paid more. Incentives are aligned.
Model 3: Percentage of The Gas Fee
The frontend charges a percentage of each transaction’s estimated gas fee as an additional fee on the transaction. This Frontend infrastructure “Gas Fee” is distributed directly to the Frontend Host.
Pros:
- If the multiple is set correctly this frontend Gas should cover the entire hosting cost & more.
- Frontends will make more when they’re available and fast during times of congestion when gas prices spike
- Because the user is paying the gas fee you’ll only lose money for pushing fake traffic.
- Chains with higher gas will pay more in frontend fees encouraging migration to lower gas chains.
Cons:
- Only on-chain actions pay: a user may check a position on Compound every day for a year without taking action. Those RPC node calls add up and are being covered by the website host.
- Users may complain when seeing an additional fee which is the real cost of running the website. They can always host the site themselves locally to circumvent paying the fee.
Who pays: End User
We recommend this option because:
A percentage of Gas Fees will encourage anyone of any size bags to participate and they’ll see fees that are similar to what they’re used to rather than believing the Compound DAO lookup table to be correct. (A multiple on Gas will still need to be decided)
Model 4: Percentage of the amount being deposited/Withdrawn
We don’t recommend this option because it will discourage whales from using the frontend if they have to pay 100x as much to take the same action.
Model 5: Charge for page loads
Have users connect their wallet before being able to see any data in the frontend. The frontend then tracks the pageloads, read RPC calls, write RPC calls & on-chain actions. When a user takes an on-chain action the cost of the infrastructure they’ve used between now and their previous on-chain action would be added as a fee.
Pros:
- This would most closely compensate hosters for the “Real” cost of running a frontend, tracking both on-chain & off-chain costs.
Cons:
- Crypto users don’t like being tracked.
- A user could do all off-chain actions on wallet-A then switch to wallet-B to dodge paying any off-chain costs.
Who pays: End User or Compound DAO
We don’t recommend starting with this option, though long term with future solutioning could provide the most sustainable model.
Additional Considerations
Any of these models still require the use of a third party RPC node provider. An RPC node could also be embedded in the frontend executable. While it requires additional knowledge and hardware to run, an ideal scenario is one in which community members are also sustainably incentivized to run RPC nodes moving away from website usability hinging on the uptime of 1 or a couple providers.
We have another entire article we can write on this subject, happy to discuss it in the comments here as well.
Ask
- We invite delegates and the community to share their thoughts on their preferred incentivization model.
- If you’d like to host a beta of the website server for testing please let us know and we’ll share the code as it becomes available during the development process.