This is the 1st post in a 3 part series on Erasure Bay and two new Erasure use cases. If you’re already familiar with the protocol please skip to the second section or 2:35.
Erasure Bay
Erasure Bay, built on the Erasure protocol, allows for trustless information trade. It enables two unfamiliar parties, one fulfiller and one requestor, to attach stake and levy penalties, respectively. By cleverly aligning the incentives of those parties, both aquire “skin in the game”. Que Erasure’s unique griefing system.
Griefing works like this: A requestor first posts a request for data with a reward. A fulfiller responds, by attaching stake to their submission. If the response meets the requestor’s expectations, the fulfiller is rewarded in full, the stake is released, and the transaction is done. On the other hand, if the data provided is insufficient, the requestor has the option to burn a specified amount of the fulfiller’s stake, within a given timeframe.
Here we have the novel innovation of griefing: the requestor also has to pay in order to burn the fulfiller’s stake. The requestor’s burn is a smaller fraction of the fulfiller’s burn. This “punish ratio” can be adjusted to fit the situation. You could say the “punish ratio” is like the requestors’ quality control, or error tolerance. The key here is the requestor incentivizes good behavior, while assuring the fulfiller will not be recklessly burned(at some cost to the requestor).
See the simplified overview of how erasure works in the diagram below:
In layman’s terms, a low punish ratio like 0.02 says something like, “hey, anyone who submits better get this right, or I’ll burn you, at little cost to me.” A high punish ratio, like 0.8, signals, “don’t worry, I trust you, I probably won’t burn your stake because it will cost me dearly, please have a try.”
The bottom line is, both parties risk loss by acting in bad faith. This elegant protocol has great potential to be applied in new and interesting ways in the future.
The worst scenario for our counterparties is transformed into positive tokenomics. Any Dai burn penalty is sent to uniswap to purchase & lock up NMR. This continually reduces the NMR supply. Even where requestors and fulfillers make a below par exchange, the ecosystem is strengthened.
A more detailed explainer on how the erasure protocol works can be found here.
The Agreement Engine
Erasure’s initial focus in decentralized hedge fund, Numerai, has proven to be a great success outperforming other asset classes with ever growing participation. Building on that momentum, the erasure team still has broader ambitions for the protocol as an agreement engine “creating instant trust with perfect strangers”. A great many use cases abound. Where traditional agreements are too time consuming, expensive, and complex, erasure offers an alternative. A new niche.
In comparison to Numerai, the more generalized agreement app Erasure Bay, in contrast, has so far attracted fewer users. A narrow feature set and scaling problems have perhaps been a stumbling blocks for adoption. Currently, Erasure Bay signups are on hold, as Authereum moves to their layer 2 solution, Hop Protocol.
Erasure Bay Updates
While L2 solutions are assembled, it’s a good time to focus on updates, improvements, and new use cases. I suspect work is already underway on Erasure upgrades and expansions, while the scaling puts things on pause. To that end, two new features are suggested: The Negotiating Table and a feature synonymous with contracting, the Request For Proposal. Both features could add dynamism and virality to Erasure Bay.
The Erasure Bay parameters are a balancing act between the two parties. Depending on the trust between parties, risk tolerance, time preferences etc. These parameters need to be fine tuned.
There’s a broad array of different setups here, where you can tweak parameters for these agreements, such that it models a specific type of relationship. Stake can be massive or have a low punish ratio because you don’t trust the other party. Or alternately you can have the opposite where, the person who’s staking has a great track record and so their stake is not that high. It depends heavily on what the marketplace setup is like
You can create an agreement where it’s completely costless to grief. The ratio could be basically 0
Protocol Architect Stephane Gosselin & Software Engineer James Geary
There seems to be a disconnect here. We have a fine-tuned system tailored to unique parties, without a neutral space for those parties to do the tuning. In its current form Erasure Bay only allows users to interact after the request has been created.
Users should have the option to communicate at the outset, before any request is made. When setting parameters such as reward and punish ratio, Erasure Bay requestors make an educated guess as to the state of the marketplace(prospective fulfillers) to receive an optimal response. Is your reward too high or too low? Is your punish ratio reasonable? It’s difficult to gauge beforehand.
The Negotiating Table
A new feature, the Negotiating Table is one solution. A feedback mechanism for prospective fulfillers and requestors to establish reputation and clarify details of the request.
Currently twitter is a good communication tool for Erasure posts and comments, but both parties could work in concert from the start. There lacks a formal space for terms to be worked out before the parameters are set.
For example, in the post below, “emre” is doubtful about being able to fulfill the request. Would he be willing to do it for a higher, $50 reward? Or, maybe emre’s sources only show up to a maximum 100,000 sq/ft, and would be willing if the scope of the request were changed. This request unfortunately remains unfulfilled.
If there was some negotiation involved beforehand, they could probably work out a deal. Or the requestor could have saved some time. Even if a requestor finds that he won’t find a sufficient fulfiller, maybe he can reformulate or ask a different question, having learned from exploring the Erasure Bay ecosystem.
The negotiating table could be a separate chat room, forum, or possibly on layer 2 dapp. It could also be implemented on twitter, just like the current posting system.
Functions of The Negotiating Table include:
- Come to agreement on parameters, such as reward
- Clarify the wording/meaning of the request
- Establish track record of fulfiller
- Solicit amendments to the request
Request for Fulfillment (RFF)
The Negotiating Table opens up the door to another process we will call Request for Fulfillment(RFF): Similar to Request for Proposal(RFP)
Erasure Bay’s current system could be described as first come first served(FCFS).
First Come First Served(FCFS) The first submission must be accepted.
In contracting work, RFP is a useful process to arrange procurement and business partners. A modified version of RFP could prove useful on Erasure Bay. Let’s look at the standard definition:
The request for proposal(RFP) is a document released that announces an upcoming project they would like to implement. It lists details about the incoming project and asks contractors and organizations to place bids, which include their strategy and desired budget to complete the project.
Similarly, Request for Fulfillment(RFF) would give requestors the option to pick and choose who can ultimately fulfill a request. Multiple fulfillers could que up, stating the terms they’d be willing to accept, along with the reason why they are the right fulfiller for the request.
This is an option that could prove particularly useful for high value requests, or when a certain degree of professionalism is desired, or sensitive data is part of the request. You would not necessarily want the first person to come along to be automatically accepted.
Conclusion
Both features like The Negotiating Table and Request for Fulfillment, could allow for a more flexible system, optimized fulfillments, and fewer unfulfilled requests. These are meant as optional extensions of the main Erasure Bay use case, keeping in line with the ethos in choice and freedom in defi. In the future, as scaling is implemented and adoption accelerates, it will be important to have new ways of interacting.
In two follow up posts, we will look beyond the horizon for new Erasure use cases. Erasure Cast & Erasure Craft
Leave a Reply