Announcing the Proffer Protocol

Social Search with Expert Networks on the Blockchain — A Draft Spec

“Is Julie a compatible life partner for Anshul?”

“Which Dentist is the most reasonably priced and kindest in San Francisco?”

“Which police station in {dangerousCityIGotStuckIn} is the least corrupt?”

“Will John be a good fit for the Google Lens Team?”

These questions are similar in that they can’t be answered using information from the internet alone. They require information that can only be gathered through offline experience and expertise. To answer these questions, one needs a Social Search Engine.

A Social Search engine is designed to find experience goods. Experience goods, like people or chocolate, have to be experienced in order to measure their quality and find the right one. Search goods, like detergent, don’t need to be experienced. You can measure their objective properties to determine quality and find the right search good.

I first learned about the challenges of building a Social Search engine during my master’s thesis at the MIT Media Lab. My research was on love and how people get to know each other using online user interfaces. People are experience goods, but most of the dating sites you use to find them are designed for search goods. So I set out to figure out how can you find the right experience good. The right powerful solution would let you incorporate offline experience but work at scale with a really large potential answer space.

After six years of tackling this problem, we feel that we’ve figured out a way to let you do Social Searches at scale. It takes the form of the Proffer Protocol.

The Proffer Protocol lets apps on the blockchain find answers to questions that need offline expertise. Designed around expert networks and a Global Expertise Bank, Proffer defines a meritocracy built on expertise and financial rewards.

Here we will describe how Proffer works and how any dApp on the Ethereum blockchain can use it as an API for social search.

TL;DR

The Proffer Protocol completes a Social Search in five steps:

1. A Seeker submits a question to Proffer.
2. Responders submit, upvote, and downvote answers.
3. Each Responder has to back their response with tokens that form an incentive pool.
4. The protocol figures out which answers are right using inputs from the Seeker or by looking at the Responder Skill that is backing or rejecting each answer.
5. Correct Responders split the incentive pool and gain Skill as reward. Incorrect Responders lose their stake and Skill as penalty.

Using the classic “Put your money where your mouth is” adage, Proffer makes sure token wealth and Skill is redistributed to users who prove their expertise by giving the right answers. This simple incentive design can scale to support complex Social Search needs as we demonstrate through the dApps we’ve built to explore the limits and strengths of the protocol.

We’re going to first define the roles, transactions, pools, and payouts that the protocol is made of before we get into the details of how a Proffer search unfolds.

Protocol Roles

Firstly, let us define the roles that users play in the protocol. Proffer starts off a search by assigning a Seeker’s questions to a set of Responders.

Stakes & Pools

Next, we need to define the incentive pools created for each query during a search. Essentially questions and answers are backed financially and using the expertise metric Skill.

Financial Payouts

Lastly, let us define which financial payouts happen when a Proffer Search is completed.

Parameters & How it Works

Ask a question, back it with tokens

A Seeker using a dApp (RequestContract) announces on the blockchain that a Question needs to be answered. The Seeker starts off a TokenBackingPool with a SeekerStake (must be at least the minimum transaction fee required to start the Proffer search on the Ethereum blockchain) using the SeekerStake parameter.

1st Set of Parameters

Define the Required Expertise

Every Question on Proffer requires expertise. Proffer maintains a global Expertise Bank storing a Responder’s Expertise — Skill — in the topics that have received their responses.

Proffer’s Global Expertise Bank

Each dApp has to pass in the Question’s topic (or topics for hierarchical coverage e.g. [‘mathematics’, ‘geometry’]) to Proffer via the QuestionTopic parameter.

• Only Responders whose skill in the QuestionTopic meets the MinimumSkill parameter are assigned the Question. If no MinimumSkill is provided, Responders are chosen randomly from all token holders and QuestionTopic skill comes into play with the SkillBacking. SkillBacking is calculated using Responder Skill in the QuestionTopic.
• When someone responds to a Question correctly, they receive Skill in the QuestionTopic.

2nd Set of Parameters

Configure the Answer Space

The Answer Space is the list of answers that have been submitted and voted on by Responders. It can be seeded by an initial set of answers that can then be voted on and added to. Responders can then do one of the following things when they receive the Question:

• They can Pass on a question and choose to not respond. This will cause Skill to be deducted from the user’s account in the QuestionTopic’s Skill Table.
• If DisableNewAnswers is false, then the Responder can submit a new answer and back it with AnswerStake. Responder’s Skill in the QuestionTopic is added to the submitted answer’s SkillBacking.
• They can upvote or downvote an existing answer if DisableUpvotes and DisableDownvotes is false. Responder must back the vote with VoteStake. Responder’s Skill in the QuestionTopic is added (upvote) or subtracted (downvote) to the voted answer’s SkillBacking.

3rd Set of Parameters

The AnswerStake and VoteStake represents the Responder’s stake of the TokenBackingPool and puts the Responders’ skin in the game by acting as a proof-of-confidence. Responders get their AnswerStake and VoteStake back if their answer’s correctness is undecided after Peer Review. We’ll discuss this further below.

Complete the Search

The final set of parameters helps Proffer decide when to complete the search, how to decide the right answer, and what the payouts will be.

Once the ResponderLimit or JudgementTimeLimit is reached, the search is complete. If JudgeOfCorrectness or JudgeOfIncorrectness are set to 'PEERS' then the Peer Review method is used. With Peer Review (PR), answers can be the following at search completion time:

• PR Correct: Answer has SkillBacking ≥ CorrectnessThreshold.
• PR Undecided: Answer has IncorrectnessThreshold > SkillBacking < CorrectnessThreshold.
• PR Incorrect: Answer has SkillBacking ≤ IncorrectnessThreshold.

We include the undecided category to adapt to the slightly subjective nature of expertise-based searches.

If JudgeOfCorrectness is set to 'SEEKER' then the Seeker has to make a decision on which answers are correct before the JudgementTimeLimit is reached. If no answer has been deemed as correct at search completion time, all answers that are not deemed incorrect by the JudgeOfIncorrectness will be deemed as undecided. The same thing happens when JudgeOfIncorrectness is set to 'SEEKER' except with Seeker’s deciding on incorrect answers.

4th Set of Parameters

Redistribute Wealth and Adjust Expertise

When the search is complete, we decide payouts of tokens and skill based on the following tenets:

You should lose tokens and skill if:

• You contributed an incorrect answer
• You upvoted an incorrect answer
• You downvoted a correct answer

You should gain tokens and skill if:

• You contributed a correct answer
• You upvoted a correct answer
• You downvoted a incorrect answer

Otherwise (if your answer / vote is undecided):

• No financial loss or gain, you get back what you had put in
• No skill lost or gained

If a user is gaining tokens because they submitted a correct answer, they get back their AnswerStake and receive an AnswerPayout which is a piece of the TokenBackingPool that is calculated using the AnswerPayoutRatio parameter.

If a user is gaining tokens because they voted correctly, they get back their VoteStake and receive a VotePayout which is a piece of the TokenBackingPool that is calculated using the VotePayoutRatio parameter.

5th Set of Parameters

Responders earn Skill in the QuestionTopic when they’re right and lose Skill when they’re wrong. The amount lost or gained is a function of the payout ratio parameters, the Seeker’s Skill in the question topic, and the difficulty of the question.

5 dApps in 5 Days — Example Use Cases of the Proffer Protocol

The Proffer team built five apps in five days to win the Coinbase’s Token/Toshi Hackathon. Each of the dApps highlights the flexibility and strengths of the protocol by showcasing it within a different use case.

Proffer Edu

Decentralized education on the blockchain. The dApp uses Proffer to let students get answers to their questions from expert tutors while letting the tutors earn money in exchange for their expertise. Showcases Proffer’s strength in handling one-to-few social search scenarios where Responder expertise is based not only on expertise in the subject matter, but also in the ability to explain it correctly to the student. It also optimizes for getting answers quickly instead of waiting forever to get the most possible accurate answer.

Proffer Pair

A decentralized matchmaker on the blockchain. The dApp uses Proffer to get hundreds of matchmakers to vote on whether two people are compatible or not. Matchmakers earn money for successful matches while users get higher quality matches from expert matchmakers. It showcases a Proffer use case where the Seeker doesn’t need to back the question with SeekerStake and the financial incentives for the responders come purely from AnswerStake and VoteStake.

Proffer Health

A decentralized triage doctor on the blockchain. The dApp uses Proffer to get health questions answered by doctors. Enables doctors and nurses to get paid while verifying that users get accurate answers to their questions. It showcases a Proffer use case that requires Responders with high levels of verified expertise.

Proffer Jobs

A decentralized recruiter on the blockchain. The dApp uses Proffer to get hundreds of recruiters to vote on whether an individual would be a good fit for a job. Unlike Proffer Pair, the Jobs dApp showcases a use case where the Seeker (companies) do put in a high SeekerStake to start off the pool. This incentives high expertise individuals like professional recruiters to join the expert network and potentially make it their day job.

Proffer Sort

A decentralized sorting engine that performs comparisons based on human input. Outside of linear time sorting algorithms, most sorting algorithms are comparison based. If the comparison can only successfully be done by a human, then one can’t use algorithms like Merge Sort right out of the box to complete the sort. So Proffer Sort uses Proffer to sort a list of entities using human input while letting the sorters earn money. Proffer Sort can be used for sorting products like Headphones from best to worst or even doctors etc.

This use case explores how Proffer can be used to get Responders to work together to complete a multi-step answering task. It also showcases a scenario where only SeekerStake is used. AnswerStake, VoteStake is set to zero because no one is incorrect in this subjective sort task and hence Responders only earn from the pool that’s seeded by the Seeker.

Key Questions and Design Decisions

1. Why would people put in money to answer questions?

Proffer’s incentive system encourages Responders to “put their money where their mouth is.” Research (e.g. Harris, et. al.) shows that combining positive and negative incentives lead to the best answers with users putting more effort into coming up with the right answer:

Harris, Christopher. “You’re hired! an examination of crowdsourcing incentive models in human resource tasks.” Proceedings of the Workshop on Crowdsourcing for Search and Data Mining (CSDM) at the Fourth ACM International Conference on Web Search and Data Mining (WSDM). 2011.

By getting Responders to back their answers with ResponderStake, we are able to build up the TokenBackingPool — a pool of tokens that rewards correct Responders and penalizes incorrect Responders. dApps can also use the AnswerStake and VoteStake parameter to customize how sure a user has to be of an answer before contributing it. So for use cases that permit more-subjective responses (maybe a search for the best tasting chocolate in Belgium), the AnswerStake and VoteStake amount can be low. However, for use case like a company looking for an expert answer on which supplier is the easiest to work with, ResponderStake can be high to only let confident Responders in to the search.

This model also results in the redistribution of token wealth. So gradually the majority of the tokens in the protocol should go to Responders who answer correctly. Trolls and other users who negatively guide a search are disincentivized from submitting incorrect answers.

2. Bootstrapping Expertise: How is expertise measured at t=0 vs t=∞?

When the Proffer Protocol is first launched, everyone starts off with zero expertise. dApps can choose to verify expertise off the blockchain and initialize expertise values in their Skill Tables for certain use cases like Doctors in a Health Questions app. However, when they’re not initialized, Proffer relies on the wisdom of crowd to measure the expertise backing an answer. The more people backing an answer, the higher the chances are of it being correct.

As more and more searches are performed on Proffer (t=∞), the Global Expertise Bank is filled with a better representation of Responder Skill. This allows Proffer to use signals from the wisdom of the crowd and the Global Expertise Back (quality & quantity) to decipher answer accuracy and precision.

Proffer as a foundational protocol — scaling beyond our initial use cases.

We wanted to build a protocol for Social Search that dApps could build on top of. We see Proffer as the foundation for a series of smart contracts that can be layered on top of each other. We find this layering can create some really powerful dApps that function together to encourage modularity.

dApps who directly call functions on the Proffer Protocol smart contract (Layer 1 dApps) are right above the foundational layer of Proffer. Their core functionality revolves around a specific use case and topic for Social Search. Which is why we use the dApps smart contract address as representing a Topic in the Global Expertise Bank

The dApps that lie on higher level layers do not interact with the Proffer Protocol directly. They instead call upon Layer 1 dApp smart contracts to help them fulfill their Social Search needs.

The following figure shows an example of how this can work. On Layer 2 is a decentralized classroom dApp connects students to professors conducting classes on different topics. Students in the classroom need help with their homework after class. So the classroom dApp asks the Tutor dApp to handle the homework questions of its students. The Tutor dApp is a Layer 1 dApp whose focus is to allow students to submit search queries with their questions and get subject specific tutors to answer them.

The Three Layers of the Proffer Smart Contract Cascade

The Tutor dApp achieves most of it’s functionality by customizing the Proffer Protocol. Tutor has already done the hard work of onboarding tutors and validating their skill on specific Topics with Proffer’s Global Expertise Bank. So the classroom dApp doesn’t have to reinvent the wheel and can just use the Layer 1 app to meet its homework help needs.

Transaction Fees

Since Proffer is one of the first non-infrastructure (compute, storage etc.) protocols on Ethereum which is designed to be used by higher level Smart Contracts, we are experimenting with how to make it easier to use such foundational protocols.

Ether Fees are required to run each transaction successfully on the Ethereum blockchain because transactions cost Gas. Our current approach is to allow higher level dApps to provide Ether when they invoke Proffer. We are also exploring how we can build on top of protocols like 0X to let higher level dApps use their own tokens or Proffer tokens instead of Ether to cover Gas costs for Proffer transactions. Such an integration with 0X could also let higher level dApp users use non-Proffer tokens to run a Proffer search.