Referring candidates

Referrers refer candidates to roles that are live. Anyone can be a referrer. We envision referrers to be freelance recruiters, agencies, job boards, communities, people with a large network, people referring their friends etc, but there is really no limit on who can refer candidates. Referring candidates is completely permissionless.

To become a referrer, the following information is minted on-chain:

• The referrer id

• The wallet address that administers this referrer

• The username

• The contact information (email)

• Who they were referred by (optional: who brought this referrer to the platform)

By bringing on new referrers on the platform (e.g. referring a new referrer), you’re eligible to earn part of the network fee as a reward. A referrer can mint a referral by providing the following information:

• Referral id to identify this referral

• Referrer id of the referrer making the referral

• Referrer signature using the referrer’s wallet private key, to guarantee ownership

• The role id

• Candidate information

  • Name

  • Resume

• Candidate contact information

  • Email

  • Socials (LinkedIn, Lens, Twitter, Angellist…)

• Description why the referrer believe the candidate is a good fit for the role

• Proof of candidate acknowledgement

• Encrypted candidate identifiers (e.g. email, verified wallet address, LinkedIn or Twitter id etc…). This information is used to check for duplicates.

Each referral needs to be acknowledged by the candidate. This can happen in a few different ways:

• The candidate signs a unique referral identifier using a wallet that has been verified using Proof of Humanity or another web of trust. This assumes the candidate already has a verified wallet.

• A trusted third party, elected by the client, sends an email to the candidate’s email address containing a confirmation link. This way, the third party guarantees the owner of the email address acknowledges the referral. Examples here are Magic.link or Torus.

It’s important that the candidate information is kept private: only the referrer, the candidate, the vetter (see later) and the company should know which candidate was referred for a specific role.

Only minimal information is stored on-chain (e.g. the referral id, signature, role id and state). All other information is stored in decentralized storage to reduce costs.

It sometimes happens that the same candidate is referred multiple times by different referrers. In this case, the candidate is attributed to the referrer that made the referral first. This check is performed using the encrypted candidate identifiers (discussed in more depth later).

Each referral also has a state: considering, interviewing, hired, rejected. This state is updated by the client.

The candidate’s contact information is kept hidden from the client until the state of the referral changes to ‘interviewing’. This is to make sure that the client indicates clearly which candidates they’re interested in moving forward with and which ones not. Of course, it’s hard to completely anonymize a candidate (e.g. resumes are often unique and one can find a candidate fairly easily by googling their combination of past employers), but this is not necessary.

Clients are incentivized to properly update the candidate’s status to interviewing as follows:

• It makes it easier for them, as only in that state they’ll get the contact details of the candidate.

• The candidate status is public and is used to determine the ‘client reputation’. Referrers use this information to decide which clients they’ll focus on working for, as they prefer clients that consider candidates quickly.

• Referrers and candidates can flag fraudulent behavior. In case this is acknowledged through a Kleros court (later more on this), they loose a part of the bounty and their client reputation gets severely damaged.