Prosopo

• Team Name: Prosopo Limited
• Payment Address: 0xb13BBd9C9777CACF397e1C083BbB1531E6fDe990 (ETH/DAI)
• Level: 2

1 Project Overview 📄

1.1 Overview

Prosopo - protecting smart contracts from bots

Captchas were developed because of online spam, fraud, and abuse by bad actors attempting to profit from system weaknesses. In the world of Distributed Apps (DApps), the same patterns of abuse will likely emerge, yet there is no distributed service available to DApps to verify anonymous humanlike behaviour.

Prosopo is a human verification marketplace designed to help human blockchain users prove their humanness whilst remaining anonymous. Under the Prosopo model, Providers supply the market with captchas and are rated by their ability to prevent bots and permit humans. Distributed Apps (DApps) implement captchas as part of their contract interaction flow and their users receive reputation points for completing them. User reputation scores are stored on-chain and accessible to all Polkadot Dapps, for the benefit of the ecosystem.

We envisage Prosopo benefiting the NFT smart contract marketplace, in which there is a high level of bot activity but no desire for formal authentication methods (passport, government ID, driver's licence, etc.).

1.1.1 Problems with existing solutions

• Captchas are free for a reason - existing captcha services, such as reCaptcha and hCaptcha, are geared towards creating a workforce of human labourers to label training data for AI. This strategy places the AI Researcher as the most important client. Whereas, while Prosopo’s captchas can involve labelling tasks, it is not a necessity. The overarching priority will be authenticating humanlike behaviour in the easiest possible way for humans.
• In traditional captcha systems, such as reCaptcha, user reputation scores are hidden from view on centralised servers. There is no way for a user to identify why they have been blocked from a website or why they are having to fill in captchas. Prosopo will make user reputation scores transparent to all.
• As AI progresses, captchas will become harder and harder for humans to complete. Eventually, the format will be redundant. Prosopo will prepare for this by implementing a self-referential system in which existing accounts of high reputation can directly influence the reputation of new unknown accounts, if the accounts are related.

1.1.2 How Prosopo relates to / integrates into Substrate / Polkadot / Kusama

Initially, most DApps will be deployed on smart contract parachains that utilise pallet-contracts, such as Edgeware. The Prosopo verification service must respond to these DApps relatively quickly in order to be useful. Deploying the Prosopo smart contract on each parachain should allow the lowest response times when communicating with DApp smart contracts.

The alternative would be to run a separate parachain exclusively for Prosopo. This offers better scalability but will add latency, such as communicating cross-chain via XCMP.

Therefore, Prosopo will first be deployed per parachain in order to achieve acceptable latency times. The contract can later be migrated to its own parachain if the volume becomes too large.

1.1.3 An indication of why your team is interested in creating this project

There is currently a race to develop identity mechanisms for the blockchain that depend on real world credentials, such as self-sovereign identity. Although we agree that real world identity is necessary for some applications, it is also excessive for many. Signing up with credentials is a deterrent to using a service, especially if the service is low value, such as a poll. In order for Polkadot and blockchain to be as widespread as the internet, they need to be at least as usable, and we want to help make this happen by creating a human verification system that places humans first.

2 Project Details

The Prosopo system aims to create a low-trust Captcha service allowing dapps in the Polkadot ecosystem to detect and block network activity generated by automated bots. This is achieved without reliance on any extra third parties, providing an on-chain reputation system.

2.1 Roles

Provider - commercial and non-commercial entities that offer captchas as a service (such as unlabeled images), who potentially benefit from captchas being completed.

Dapp User - people who wish to use a dapp in the Polkadot ecosystem. They are required to solve captchas provided by the Provider to prove that they are not a bot, which will give them access to use participating smart contracts. They will need to use a suitable wallet to access the substrate parachain in Polkadot where the Prosopo system is deployed.

Dapp Operator - this is the organisation that manages the dapp. It could be a commercial or non-commercial company, an on-chain DAO or other form of on-chain governance system. The dapp is a blockchain application on a Polkadot parachain which users want access to. Dapp operators will set up the infrastructure so that people can access their dapp and will integrate with the Prosopo system allowing their dapp to scalably prevent bots from accessing their system.

Prosopo Operator - This is the organisation that manages the Prosopo system. This will be the team set out in this proposal, with the vision to move to a more open on-chain governance model in future. The Prosopo Operator will create the infrastructure allowing Providers, Dapp Users and Dapp Operators to interact within the Prosopo system.

2.2 Design goals

2.2.1 Functional requirements

2.2.1.1 Dapp Users

Human Dapp Users must be able to reach Dapps by completing captchas

We want as many human users to be able to access Dapps as possible. They do this by completing captchas that are easy for humans yet difficult for bots.

Bot Dapp Users must not be able to interact with Dapps

In general, bots are to be restricted from accessing apps as they should be unable to complete captchas. DApp Users that submit high volumes of incorrect captchas are considered bots and have their accounts banned.

Dapp Users reputation score must be emplaced after captcha completion

Dapp Users will receive a positive or negative change in reputation after successfully or unsuccessfully completing captchas. Reputation must be stored on-chain and be associated with the calling user’s blockchain account/address.

2.2.1.2 Dapp Operators

Dapp Operators must not manipulate captchas

Dapp Operators are not able to see solutions to Captchas until they are submitted to prevent them from creating bots and attacking other Dapps.

DApp Operators must be able to view Dapp User / Provider interactions and pass rates

DApp Operators must be able to view the number of times a user has interacted with individual Providers and the outcomes of the interactions. This is to allow them to correlate the activity of Providers in case a Provider has created a bot to access their system.

DApp Operators must be able to report potential collusion between Dapp Users and Providers

This follows on from being able to view Dapp Users / Provider interactions. Dapp Users and Providers could be colluding to undermine the system and DApp Operators need a way to act on this, if identified.

DApp Operators must be able to vote on the quality of traffic received

The result of the vote will affect Provider reputation on a pro rata basis depending on the number of captchas they’ve served to DApp Users who have then used the DApp Operators’ smart contracts.

2.2.1.3 Providers

Providers must modify Dapp Users reputation scores after captcha completion

Transactions are required to change reputation scores. Providers must submit these transactions and pay the fees.

Providers must receive solutions

Providers need to know how their data is being tagged in order for it to be useful. They also need to collect solutions for previously unsolved captchas in order to continue to provide new captchas to the network.

Providers must provide good captchas

Captchas must let mostly Human Dapp Users through and prevent most Bot Dapp Users from accessing.

Providers cannot create bots to access Dapps

Providers that approve users that have incorrectly answered captchas will be cryptographically detectable and subject to governance rules such as reversals of any rewards/identity of the user and disqualification/suspension/reduced reputation of the Provider to use the system and/or slashing of stakes. If a Provider creates fake data for this purpose, they should also be detectable and slashed.

Providers must not collude with Dapp Users

Providers must not give the answers to Dapp Users.

Providers’ captcha solutions must be hidden from the public

The captcha system will be completely undermined if the solutions are viewable by the public. Therefore, hashes of captchas and solutions can appear on-chain but the actual captchas must reside on the Providers machines.

Providers’ captchas must adhere to predefined captcha templates

Providers must submit data that is compatible with one of a number of captcha templates so that many Providers can serve a single DApp.

2.2.2 Non-functional requirements

2.2.2.1 Scalability

The Prosopo system must be able to to scale to the required onboarding throughput that is expected for or all of the dapps that it services. We expect that for the launch we would need to be able to handle 100 user onboardings / second and would need to scale up significantly to meet the demands of the network. As each substrate parachain in the Polkadot ecosystem has a limited vertical scalability of several hundred/thousand on-chain tx/s, the Prosopo system could be deployed on each parachain to meet the demands of the dapps and be able to adequately scale to this level.

2.2.2.2 Privacy

No personal user information should ever be stored on the blockchain. In reality, the Prosopo captcha system does not require any personal information whatsoever. The only known user information is the blockchain account address and public keys.

2.2.2.3 Usability

Dapp Users should experience a web 2.0 experience similar to existing captcha and recaptcha systems. This will require quality designs, robust infrastructure and a low latency protocol.

2.2.2.4 Costs

Dapp Users should not pay for transactions if they are not bots. To achieve this goal, Dapp Operators will reimburse fees for Dapp Users after they successfully complete captchas. Note that this does require the Dapp Users to pay upfront for transactions that are reimbursed only after successfully completing captchas. Failed captchas result in lost transaction fees for the Dapp User.

Providers and Dapp Operators will be required to cover the costs of any transaction fees of their making.

2.3 Mockups

2.3.0.1 Captcha client

2.3.0.1.2 Flow for Captcha solution including reporting of issues

As a Dapp User

I can request to solve a captcha

So that I can access the dapp

As a Dapp User

I receive an unsolved captcha and can submit the correct solution

So that I can access the dapp

As a Dapp User about to submit a solution

I am told that I need to pay for the tx fees and that it will be reimbursed if it is successful

So that I do not have to worry about paying the tx fee

As a Dapp User that receives captcha data that doesn’t make sense

I can report the captcha data as bad

So that I get a new captcha and can access the dapp

As a Dapp User that correctly submitted a Captcha

I am shown that my solution was correct and that my reputation has increased, and that my tx fee was reimbursed

So I know about my reputation, the reputation is reusable with my blockchain account for next time, and I don’t have to worry about the tx fee

As a Dapp User that submitted an incorrect Captcha

I am shown that my solution was incorrect

And that my reputation has decreased

So that I know I have a reputation and that I should take captchas seriously

And I know my transaction fee has not been refunded

As a Dapp User that correctly submitted a Captcha that was marked as incorrect

I can report that the solution was correct

So that the Provider’s solution and mine can be audited, and my reputation not deduced

2.3.0.2 User Portal

2.3.0.2.1 Registration and staking of Providers

As a Provider

I can login to the portal with my wallet and create a new Provider account

So that I can see what features I am able to access

As a Provider creating a new account

I can register my contact details, enter my provider fee, pay a stake to the system and activate my Provider account

So that my service starts and I can start receiving solved captcha data

As a Provider creating a new account

I can register the url of my Provider service (server)

So that Dapp User clients can contact and receive captcha data from it

As a Provider

I can deactivate my service

So that I can unlock my staked tokens

2.3.0.2.2 Registration and staking of Dapp Operators

As a Dapp Operator

I can login to the portal with my wallet and create a new Dapp Operator account

So that I can see what features I am able to access

As a Dapp Operator creating a new account

I can register my contact details, pay for the service and activate my Dapp Operator account

So that my Dapp can start using the Prosopo service to prevent bots

As a Dapp Operator creating a new account

I can register the url of my dapp client and dapp address on the blockchain

So that Dapp User clients can correctly attribute their login on my dapp

As a Dapp Operator

I can cancel my service from Prosopo

So that I stop paying for the service

And any remaining funds are transferred back to me

As a Dapp Operator

I can report that users from a particular Provider are likely bots

So that the Provider is potentially blocked and my dapp stops having bots attack it

2.3.0.3 Dapp User portal

As a Dapp User

I can login to the portal with my wallet and see my reputation and history

So that I can see what I’ve done

2.3.0.4 Operator Portal

As a Prosopo Operator

I can see a list of the registered Providers and Dapp Operators

And I can use search terms to filter the list

So that I can select one to see their details

As a Prosopo Operator

I can see the details of a registered Provider or Dapp Operator

So that I may contact them and/or conduct an audit of their system by connecting to their server/contract

As a Prosopo Operator

I can see a list of disputes created by Dapp Users, Dapp Operators and Providers

And I can use search terms to filter the list

So that I can take action and investigate

2.4 Architecture

The Prosopo solution consists of three layers, as depicted in the software architecture diagram below. \

1. Client - This is the user interface through which users can interact with the Prosopo system. For the Minimum Viable Product (MVP) this will be a set of web applications which are connected to desktop or mobile wallets. We expect to include a mobile app in future releases. \
2. Server - There is one server component for the Provider. These are considered low Trust services due to the cryptography involved, as explained below. \
3. Blockchain - these are smart contracts that run on a substrate parachain. These contracts facilitate the low-trust interactions between the users of the system. The contracts will be executed by the relevant parachain validators and allow real-time cryptographic auditing of the system. The majority of on-chain content is merely cryptographic proofs which do not reveal any of the relevant captcha data that would compromise the system to bots.

The components are:

1. Captcha client - this is the web or mobile application through which a user will interact with the smart contract they are interested in (games, defi, gambling etc). When a user logs into the application, they are required to complete a captcha in the dapp website, submit the proof to the chain and submit the completed solution to the Provider. Prosopo will be delivering a set of JavaScript and HTML components that will be integrated into the client to allow this flow. \

2. User portal - this is where Providers are able to register their data sources and stake into the system. Dapp operators are able to register the app to use the service and pay for the service. Dapp Users can log in and see their reputation. All users are able to see and manage any disputes as part of the governance and disputes features. The interface for this software is provided in Section 2.7.2.

3. Operator portal - this is where the Prosopo Operators are able to view aggregate analytics about the Prosopo system and can manage disputes from users. This will include Providers being able to register their data sources and stake into the system. Dapp operators are able to register the app to use the service and pay for the service. This also facilitates the governance of the Prosopo system in case of disputes for users. The interface for this software is provided in Section 2.7.3. \

4. Provider server - This is a server service that provides captchas for Dapp Users, validates Solutions as correct and confirms the user's presence and reputation on the blockchain. Providers submit a cryptographic proof (merkle tree of captchas and solutions) of their data before it enters the system which allows the app users to verify captchas in real time. This allows the system to operate with minimal Trust assumptions as the Providers are unable to game the system without verifiable proof of them doing so. This project will deliver the required software which allows Providers to run this service. \

5. Provider database - this is the captcha data itself, connected to the Provider server.

6. Dapp smart contract - this is the smart contract of the dapp (games, defi, gambling etc) that the user wishes to interact with on the blockchain. This contract will be able to query the Prosopo smart contract to determine if a user account has recently completed a captcha or has a high enough captcha reputation to use the application. This allows the dapps to prevent bots from automating use of their software.

7. Prosopo smart contract - contains the logic for staking, captcha commits, reputation and disputes for the Prosopo system. The smart contract will initially be run by the Prosopo team who will administer the governance and dispute features with the aim for a more open long-term system after the concept has been validated. The interface for this contract is provided in Section 2.7.6.

8. Token smart contract - This will be the main token contract for the parachain. Payments and staking for the system will be completed using this token. On most parachains, this default contract is already in place and operational as the default token.

2.5 Main captcha solving sequence

The below diagram shows the primary fluid that the app users will undertake when they want to use a dapp that uses Propos captcha bot protection.

\

An extended technical version of this flow can be found here:

https://drive.google.com/file/d/1LaXZNJiFKhiQ2ylu_TqehvUlzdc3tlZi/view?usp=sharing

Setup phase

The set-up phase allows the different actors in the system to register and deposit stakes required to use the system. This is a requirement for the Providers and Dapp Operators. Dapp Users are not required to register or stake before completing captchas. \

1. The Provider registers to provide captchas and deposits a token stake. They will register with their contact details and the domain of their server that runs the Prosopo service attached to the captcha data. The token stake is used as a guarantee of behaviour, and can be deducted if the Provider is proved to be using fake or poor quality data, providing false answers to users, or running the system so they can create bots. All these attacks are cryptographically provable and will result in the stake being slashed. \

2. The Provider submits a merkle tree root hash of the captcha dataset they will use in the system. Each new data set will require a new proof. The proof is 32 bytes in size, no matter how large the data set (it could be terabytes). This merkle tree contains a leaf for each captcha including an id, the solution (if known) and a salt. This is the primary material used to derive proofs by users that allows them to automatically detect and prove malicious behaviour in disputes. The salt is used to remove the possibility of a dictionary attack on the hash of the leaf data. \

3. Dapp operators also need to register their dapp contract’s address on the Prosopo smart contract and the client domain used for the dapp. They are required to pay for the service upfront which covers the cost of the service as well as the reimbursements of the user fees when they use the service to prove their identity.

Low-trust user verification \

4. The first step to login a Dapp User is for the User or Dapp Client to check whether they meet the anti-bot requirements of the Dapp they want to use. This is a query of the blockchain which will tell them their current reputation and what requirements the Dapp has. If they meet the requirements they can start using the Dapp immediately (step 14), otherwise they will need to complete a captcha proof. \

5. The Dapp User requests a captcha from a Provider. \

6. The Provider responds with two captchas, one which the Provider already knows the answer to, used to perform human validation, and the other which they want to know the answer to. The captcha data is provided in the form of a merkle tree proof which provides the merkle leaf data of the captcha id but not the solution or salt. This can then be used to prove which captcha in the dataset is being committed to by the user.

\

7. When the Dapp User receives the data, the client software will first check that the merkle data corresponds to the on-chain merkle root for the Provider’s data set. They do this by hashing the two leaves they receive per captcha (hash0-0 and hash-0-1 in the above diagram) to retrieve the merkle root. This allows the Dapp User to know that they have received the correct data. The software will automatically report data inconsistencies to the governance functions in the Prosopo smart contract. This is monitored by the Dapp and Prosopo operators to ensure that Providers are not sending false data to users. \

8. The user is then required to solve the two captchas. The Dapp User submits a proof of the solutions on the chain in the form of another merkle tree root hash. This contains the merkle leaves with the captcha id, solution and a user generated salt. The salt removes the possibility of a dictionary attack on the solution. \

9. The user submits raw solutions to the Provider including the merkle tree leaves. \

10. The Provider checks that the received solution corresponds to the same solution that the Dapp User committed to on chain using the merkle tree data. Assuming the data corresponds, they then check the Dapp User’s solution against the known solution to see if it matches. If the known solution matches then the Dapp User is assumed not to be a bot and regard the other solution as correct and marks this in their dataset. \

11. Assuming the solutions were correct, the Provider submits a transaction that marks the Dapp User’s solution as correct and provides some reputation credit to their account as not being a bot. The transaction will automatically refund the Dapp User’s transaction fee, using the dapps deposit funds. Of course, if the solutions were not correct then this will also be marked on the blockchain and the Dapp User’s transaction fee is not reimbursed. \

12.The Provider responds to the Dapp client (with the solutions) confirming that the user correctly submitted the captcha and that the reputation of the Dapp User has been updated on the blockchain. The Provider will also respond with the merkle tree proof including the leaf with the known solution and salt in their data set.

13. The Dapp User uses the merkle tree proof and compares this against their solution. They are then able to verify that their solution was correct (or incorrect) according to the Provider’s data set. If there is an inconsistency between the solutions, the Dapp User is able to prove that the Provider has incorrectly matched their solution and can report this to the Prosopo Operators through one of the governance functions of the smart contract. They also verify that the Provider has indeed made a transaction to update their reputation.

Dapp login

14. The Dapp User has now completed the verification and knows that they will be able to log into the Dapp. They can now call the Dapp contract and they will be able to use it.

2.6 Edge cases, disputes and governance

Several edge cases exist where disputes may be created by different actors in the system. These can then be acted on automatically through a manual investigation facilitated by the Prosopo Operators. The design of the Prosopo system is such that all activity can be fully cryptographically auditable and therefore all behaviour over which a dispute is made can be cryptographically proven. In this way, actors in the system require very low trust about each other knowing that they are all held accountable for their actions.

At launch, the governance of the Prosopo system will be managed by the Prosopo Operators (founding team), however the final vision is for an open governance model.

2.6.1 Governance Economic Model

Governance willnot feature in the MVP so the exact incentivisation scheme is not decided. However, the following economic model outlines the governance approach.

Providersare incentivised to accurately verify humans by either

1. Being paid by the Dapp Operators for their service in the default parachain token
2. Benefiting from data labelling

This will be reflected by the fee the Provider charges per n captchas. A zero or negative fee means that the Provider is potentially benefiting from data labelling. Fees are decided by Providers and provided at registration. It will be possible to update fees at a later date.

Prosopo Operators are incentivised to vote on disputes by payment of a governance fee. The governance fee is subtracted from the dispute loser’s stake.

Prosopo Operators will initially be limited to team members listed in this document and by invite only. Eventually there will be an open signup process for Prosopo Operators allowing anyone to join.

Prosopo Operators are incentivised to vote fairly by staking crypto on their preferred vote, only receiving their crypto back and the governance fee if they sided with the majority. This is described below.

1. Dispute raised by Dapp User against Provider
2. Dapp User pays tx fee to raise dispute and stakes TOKEN in favour of themselves
3. Prosopo Operators review dispute and vote for or against Dapp User
4. Votes may cost Prosopo Operators in quadratic fashion (n^2 * vote stake), with vote stake = ~1 USD (To be confirmed), n = number of votes (To be confirmed)
5. If votes > x (x=minimum number of votes), vote closes, winner is the outcome with the most votes
   1. Dapp User wins => Prosopo Operators’ are refunded tx fees and paid governance fee from Provider’s stake

Provider wins => Prosopo Operators refunded tx fees and paid governance fee from Dapp User’s stake

2.6.2 Disputes and Edge Cases

Provider creates bad quality data

In this case the user receives images that do not make sense (for example, a set of pictures of only fish with the challenge set to “select all dogs”). The DApp User is responsible for reporting the bad captcha data, and will then receive a new captcha from a different Provider. The reported data will be logged in the Prosopo governance portal. A Prosopo Operator will see this dispute and then request to view the Captcha and if it does not make sense they will be able to suspend and/or slash or partially slash tokens from the Provider, refunding the DApp Users reporting transaction fee in the process.

Provider creates fake data that they use to sign into Dapps as bots

In this case, the Provider creates a set of fake captchas (perhaps just empty images) and runs an algorithm which will send these, and only these, captchas to specific Dapp Users that they control. With these fake Captchas, the Provider is able to automate access to the Dapp and effectively circumvent the Prosopo system.

When this happens, the Dapp Operator will, after this has happened several times, report that bots are able to access their system through Prosopo. The reported data will be logged in the Prosopo governance portal. A Prosopo Operator will see this dispute and then request to view the Captcha and if it does not make sense they will be able to fully slash all the tokens from the Provider.

Provider does not provide captchas that match their committed data

In this case, the Provider sends captchas to the user that do not match the cryptographic commitment they made for that data set. The Dapp User client will be able to verify this automatically and reject the captcha and report the inconsistency to a reporting system operated by the Prosopo Operators. If a large number of inconsistent captchas are provided to users, action can be taken by the Prosopo Operator to suspend the Provider.

Provider does not award reputation for a correct captcha by the Dapp User

This is the case where a Dapp User creates a commitment on the blockchain and then sends the solution to the Provider. The Provider then does not validate the solution and does not give reputation to the Dapp User.

As part of the Captcha protocol, the Dapp User client will be able to automatically detect when this occurs and create a dispute against the Provider. This dispute will then be automatically investigated by the Prosopo Operator. If several disputes are made against a capture provider, then the Prosopo Operator may suspend and/or slash the Provider.

Dapp User is a bot

This is the case where someone tries to create a bot which accesses a Dapp with automated software. This could be to collect airdrops or for other financial and non-financial reasons.

Unless the attacker colludes with a Provider as described above, the attacker should not be able to correctly solve the Captchas and will therefore never get past the Prosopo system into the Dapp. Dapp Users bear the transaction cost of incorrectly solved captchas, making it infeasible to try to brute force the system. A negative reputation is accrued on the blockchain account of the Dapp User when they submit incorrect captchas available to be used by any account/contract on the blockchain.

Dapp Operator does not pay fees to Prosopo Operator

When a Dapp User submits a commitment (merkle tree root hash) to a Captcha solution, they must specify which Dapp they are trying to sign into. If the Dapp has not paid their service fees then the transaction will fail. This means that Dapps will not be able to use the Prosopo system without paying their fees for the service.

Smart contract calls for Dapps that read the Dapp User data will also be correlated with Dapp that calls it and will fail if the Dapp has not paid their service fees.

Dapp Users trade accounts to fake reputation

This is the situation where a person creates a Dapp User account with Prosopo, and correctly solves several captchas to create a positive human reputation. At this point, the person starts running some bot software and attaches it to the account.

Note that this process is not automatable, so a person making this type of attack will not be able to do this at scale, as they will not be able to correctly solve Captchas.

We will still recommend to Dapp Operators that they infrequently create Captcha check requirements for their users, based on their needs. This is similar to existing Captcha systems that require infrequent challenges. This could be automated by their Dapp contracts (perhaps with a random timer), or manually triggered by the Dapp Operator if they see strange behaviour. We expect that, because your Prosopo reputation is portable across all Dapps, that users will need to be challenged less throughout their Polkadot experience compared to existing closed Captcha systems.

2.7 Detailed specifications

2.7.1 Captcha Client

This software component controls the UI for a Dapp User to receive and submit a solution to a captcha so that they can use a Dapp. See the UI designs for this component in the Mockups Section. Also see the sequence diagram in Section 2.5 which goes over the flows and data sequence for the user to submit a Captcha.

This will be a publicly published software development kit (SDK) on npmjs.com that can be consumed by the Dapp client software in the browser which will fully manage the UI of the Prosopo Captcha protocol with the Prosopo smart contract and Provider Service. This will include a JavaScript library and some html and css components. Installation for the client will follow the same pattern as Google recaptcha, making this easy and familiar for developers to integrate.

The SDK will also include a CSS file with stylings allowing developers to create a captcha challenge HTML button displaying “I am not a robot”, or similar.

2.7.2 User Portal

This software component is a single page web application allowing Providers, Dapp Operators and Dapp Users to login and manage their account and activity within the Prosopo system. It will be written in a popular front-end javascript framework such as React, Vue or Angular. See the UI designs in Section 2.3.

2.7.3 Operator Portal

This software component is a single page web application allowing Prosopo Operators to login in and manage disputes and other governance features within the Prosopo system. It will be written in a popular front-end javascript framework such as React, Vue or Angular. See the UI designs in Section 2.3.

2.7.4 Provider Service

This software component allows Providers to submit captcha commitments (merkle tree hashes) and send and receive Captchas and solutions to Dapp Users. See the sequence diagram in Section 2.5 which goes over the flows and data sequence for the user to submit a Captcha.

This is a publicly published javascript software development kit (SDK) on npmjs.com that can be used by the Providers to run a server connected to a Captcha database and interact with the Prosopo system. For the MVP release we will support only node js servers running an Express API connected to a Mongodb database and plan to provide support for other languages and databases in the future.

The SDK can be consumed in two ways:

1. Developers can register the Prosopo middleware layer which will fully manage the Prosopo service. https://github.com/prosopo-io/prosopo/blob/master/captcha-provider-service/index.ts

2. Developers can implement the underlying library functions into existing API routes with additional functionality (note they will still need to conform to the REST API specifications to interact with the protocol)

   https://github.com/prosopo-io/prosopo/blob/master/captcha-provider-service/prosopo/prosopo.d.ts#L35

The provided SDK will not provide a fully functional server by itself, and developers will be expected to run a nodejs server and consume the SDK to create the node. That said, it is likely that a reference implementation of a fully functional server will be created and can be copied by developers who are just getting started.

It should be noted that Providers will be required to submit transactions to the Polkadot network and will therefore need to connect to a Polkadot node. It is up to Providers whether this node is run locally on their server or accessed via a cloud service.

Prosopo Captcha Service SDK (javascript)

The following diagram shows a UML diagram for the Captcha Service javascript library.

https://github.com/prosopo-io/prosopo/blob/master/captcha-provider-service/prosopo/prosopo.d.ts

The planned database schema can be seen here:

https://github.com/prosopo-io/prosopo/blob/master/captcha-provider-service/prosopo/dataset.schema.ts

2.7.5 Dapp Smart Contract

This is a set of external functions exposed in the Prosopo smart contract that allow other smart contracts to query the Captcha reputation of Dapp Users. The following two functions as part of the Prosopo contract will allow them to do this.

The Dapp will make either of the following calls in the Prosopo smart contract which will fail if the user is a bot. In this way, smart contracts are protected from bots. The Dapp Operator will choose when and which function to call based on their requirements.

https://github.com/prosopo-io/prosopo/blob/master/prosopo-contract/lib.rs#L118

https://github.com/prosopo-io/prosopo/blob/master/prosopo-contract/lib.rs#L122

2.7.6 Prosopo smart contract

This is the main smart contract which manages the Prosopo system on the Polkadot parachain. This will host the on-chain data about the Providers, Captcha Datasets, Dapps, Dapp Users and Prosopo Operators. It exposes functions to allow

• Providers to register their account, Captcha data and service endpoints and depositing stakes
• Dapp Operators to register their account and pay fees
• Dapp Users to commit to solutions and interact with Providers in a low-trust way and gain identity reputation
• Users and Prosopo Operators to interact with the governance features for disputes resolution

https://github.com/prosopo-io/prosopo/blob/master/prosopo-contract/lib.rs

2.7.7 Token Smart Contract

This is the default token contract deployed to the parachain on which the Prosopo contract is running. We do not expect to develop this ourselves, and it will be a standard token contract (assuming the Balance pallet) that we interact with, already deployed by the parachain operators (e.g. on Edgeware the token would be EDG).

After the release of the MVP we expect to develop a custom governance token to create an open governance model for Prosopo.

2.8 Deliverables summary

The below table outlines the functionalities of each software component that will be delivered as part of the MVP release, which is covered by the W3F grant. We have also outlined future features we would expect to include in these components. These are provided to show our vision but are not part of the delivery.

Component	MVP functionality	Future features
Captcha client	- Prosopo client SDK (javascript, html, css)	- iOS, Android, React Native and Flutter implementations
User portal (closed source - not part of delivery)	- Provider setup - Dapp Operator setup	- Dapp User reputation viewer - Disputes management
Operator portal (closed source - not part of delivery)	Not included	- Aggregate analytics viewer - Disputes management
Provider Service	- Prosopo Captcha Service SDK in javascript supporting Mongodb database	- Java, Go, C++, Python - SQL databases
Dapp Smart Contract	- Prosopo Dapp Substrate external reputation interface
Prosopo Smart Contract	- Prosopo Smart Contract	- Disputes features - Open governance model
Token Smart Contract	Not included	- Governance token

The above software components include documentation required to run them, publishing to public repositories when appropriate and basic partial coverage (~80%) unit tests.

The user and operator portal will be developed and remain closed-source for the initial launch of the project. We will also be developing a closed-source repository which integrates all the components together into a developer environment and manages integration testing as well as continuous integration and continuous deployment of the entire software system.

The user and operator portals will be closed source at the initial launch of the project, to maintain a level of competitive advantage by reducing risks that the system cannot be easily copied. Having the front-end client code closed source also significantly reduces risks of phishing attacks against users of the system. The costs of this development will be covered internally by Prosopo and are not part of the W3F grant. After launch and validation of the product, and especially as we open up system Governance, we will consider making more of the software open source.

While some of this software is closed source and not part of the W3F grant delivery, it is still included in the implementation plan in 2.7 Detailed specifications.

2.9 Ecosystem Fit

2.9.1 Ecosystem Fit

Distributed applications do not currently have any methods to prevent bots in a distributed manner. This project aims to address this need.

2.9.2 Target Audience

DApp developers

2.9.3 What need(s) does your project meet?

• Providing methods for DApp developers to restrict their audiences to human accounts, anonymously.
• Open Provider marketplace.
• Portability and re-usability of reputation across Dapps.
• Ability for smart contracts to block bots with minimal trust assumptions.

2.9.4 Similar projects in the Substrate / Polkadot / Kusama ecosystem?

Effect.network

An opt-in network of workers mostly being recruited to translate texts, proofread machine translations and like social media posts. There were only 16 campaigns live at the time of checking. They have an interesting concept whereby they check worker proficiency in tasks before allowing them to take part in certain campaigns. Therefore, their business model prioritises semi-skilled task completion over human verification.

The Effect Network currently runs on BSC and EOS and the white paper can be found here.

Human Protocol

The closest similar project in the Polkadot ecosystem is the Human Protocol.

The Human Protocol is a permissionless, blockchain-based open-source protocol. A cryptocurrency, HMT, is the primary mechanism of value transfer within the network.

The Human Protocol is designed to allow AI Researchers (“Requesters”) to access the world’s human marketplace by using people to solve data labelling tasks for machine learning. Closely linked to hCaptcha, it is primarily aimed at improving AI algorithms; however it also cites itself as being a global Question & Answer system.

The Human Token (HMT) is an ERC token and a crowd sale ran from 17-18 June 2021, raising $50M. The Human Protocol white paper can be found here.

Kleros & Proof of Humanity

https://kleros.io/

https://www.proofofhumanity.id/

Proof of Humanity (or PoH) is an opt-in, social identity verification system for humans on Ethereum. PoH combines webs of trust, reverse Turing tests, and dispute resolution to create a sybil-proof list of humans.

Verification is achieved via:

• Video including speech and an Ethereum address linked to your profile clearly shown (yes deepfakes are getting better but this particular method is still hard to falsify),
• User vouching with one verification from registered profiles required.

2.9.4.1 How is your project different?

1. Prosopo’s funding structure can be the inverse of other captcha services. We believe it should be possible for Providers to be paid for reliable human verification.
2. By focusing on human verification, not data labelling, there is an incentive for Providers to find better ways to authenticate real humans. Therefore, we hope to see innovation through the creation of the Prosopo human verification marketplace.
3. Prosopo has reputation scores that are completely transparent, which means they can be used by the wider Polkadot ecosystem.
4. Prosopo reputation scores are self-sovereign, and non-transferrable. This means that verification tasks have to be completed by the account in question and cannot be faked by trading reputation.
5. Prosopo is a blockchain only project. The aim is not to replace existing web 2.0 captcha systems but rather to create a marketplace for Providers to offer their services to the Polkadot ecosystem. \
6. Prosopo enables low trust of the Provider by requiring deposits that are liable to slashing in the event of bad behaviour. The DApp Operator is not required to be trusted as the Dapp User interacts directly with the DApp Operator’s contract. \
7. Prosopo will provide software for anyone to become a self-hosting Provider and will eventually allow captchas to be hosted on IPFS. This offers a high degree of decentralisation.
8. Prosopo ultimately aims to reduce the need for captchas. This is in contrast to the data labelling business model, where the incentive will always be labelling data for AI Researchers. \
9. Prosopo use is mandatory, not opt-in. Users must complete a captcha if a smart contract requires captcha verification.

A review of existing solutions is provided below.

2.9.4.2 Comparison against previous solutions

Comparison with other data labelling and captcha service providers:

Feature	Google recaptcha	hCaptcha	Effect AI	Prosopo
Decentralized	❌	Partially	✔️	✔️
Portable reputation	❌	❌	❌	✔️
Anonymous	✔️	✔️	❌	✔️
Open human verification marketplace	❌	✔️	❌	✔️
Low-trust smart contract bot prevention	❌	❌	❌	✔️
Prioritises human verification over data labelling	❌	❌	❌	✔️

2.9.4.3 Similar projects in related ecosystems

Idena

Idena is similar in that it requires users to complete CAPTCHAs to prove their humanness and is entirely anonymous. Participating members must periodically attend validation ceremonies to solve these CAPTCHAs. A user is rewarded with tokens if they successfully solve a captcha (mining). Idena cites itself as a proof-of-person blockchain based on democratic principles. Approximately 8,000 nodes (humans) have joined the network to date and validation ceremonies are held every 19 days (n^0.33).

3 Team 👥

3.1 Team members

• Chris Taylor (Prosopo)
• Jack Tanner (Gimly)
• Blockchain Developer (Pending)
• Jesse Szepieniec (Gimly)
• Caspar Roelofs (Gimly)

3.2 Contact

• Contact Name: Chris Taylor
• Contact Email: chris@prosopo.io
• Website: https://prosopo.io

3.3 Legal Structure

• Registered Address: PROSOPO LIMITED 130 OLD STREET, LONDON, ENGLAND, EC1V 9BD
• Registered Legal Entity: Prosopo Limited
• Gimly is partnering with Prosopo Limited in the development of Prosopo

3.4 Team's experience

3.4.1 Chris Taylor | Architecture and Development

• 14 years product & technology experience across a variety of companies including several startups in advertising and tech

• Early blockchain user and investor with strong knowledge of distributed tech

• Full stack developer from an analytics and mathematics background

• Previously responsible for a team of 6 developers as a Business Analyst delivering a rewrite of an existing system

• Developer of Chrome Extension with 50k+ installs

• Spent 1 year researching Natural Language Processing solutions for captcha development

• Technologies: Python, Cython, JavaScript, Angular, React, Docker, PostgreSQL, MongoDB, Ink, Redspot

• Latest projects:

  • Job schedule analyser for major UK bank (Private)
  • Natural language processing research for captcha (Private)
  • Bin days react app for City of Edinburgh (https://github.com/forgetso/bindays)
  • Youtube metadata downloader (https://github.com/forgetso/youtubemeta)
  • Crypto arbitrage bot (https://github.com/forgetso/arb)

• Linkedin

• Github

3.4.2 Blockchain Developer (Pending)

Gimly is acting as development partner and is in the process of hiring a high calibre blockchain developer to help implement.

3.4.3 Caspar Roelofs | Partner & Advisor

• Founder at Gimly Projects + Partnerships
• Blockchain Netherlands - partnering founder
• Xurux - Blockchain Concept and Business Developer
• University of Groningen - PhD researcher and lecturer in Science, Technology and Innovation
• Graduated from Consensys Academy - Blockchain Foundations and Use Cases
• LinkedIn

3.5 Contributors

The following people have contributed significantly to this application but do not form part of the development team.

3.5.1 Jack Tanner | Architecture

• Experienced blockchain developer and entrepreneur with background in computer science and a zest for distributed governance systems.
• Heavily involved in the blockchain industry since 2015
• Public contributor (development, content and opinions) to the EOSIO and Ethereum blockchain ecosystems
• Teacher at 11 blockchain developer bootcamps in London and The Netherlands
• Panelist and presenter at 20 blockchain conferences and events
• Technical influencer in the blockchain space, large developer network
• 2021 Paper: Technology Review of Blockchain Data Privacy Solutions
• Technologies: Javascript, Nodejs, Ethereum, Solidity, EOSIO, EOS, Smart contracts, Blockchain, Bitcoin, MongoDB and SQL, AWS management and DevOps using CI pipelines, C++
• Latest projects:
  • https://docs.google.com/spreadsheets/d/1luYLBlLQ9AuExOgBlUyqWBT-Sds0Ce4L4eNs_hbtijo
• LinkedIn
• Github

3.5.2 Jesse Szepieniec | UX Design

• Product Manager & UX Lead at Gimly Blockchain Projects
• Product agency owner
• Built and launched 10+ products
• Worked with premium brands, operating in international markets as well as niche products and local markets.
• LinkedIn

3.6 Team Code Repos

Development of a prototype contract and command line Provider service has begun with the following items:

• Ink smart contract
• Ink smart contract unit tests
• Redspot deployment script
• Redspot contract tests

The code can be viewed at the following links with permission. Please request this from chris@prosopo.io.

• https://github.com/prosopo-io
• https://github.com/prosopo-io/prosopo

4 Development Status 📖

Development of the Prosopo software is in the prototype stage. We have conducted market surveys and technical reviews and carefully planned out the project.

We have discussed the project and have the following clients and stakeholders expressing interest in the project:

Clients:

• A Dapp NFT marketplace who want to restrict the number of items per human account
• A Dapp who run airdrops and have problems with bots claiming tokens

Providers:

• The creator of WaveAlert, an app for detecting the number of surfers on beaches from live webcam feeds.

We expect this list to grow as we develop and deploy our marketing strategy.

5 Development Roadmap 🔩

5.1 Overview

• Total Estimated Duration: 5 months
• Full-Time Equivalent (FTE): 2 FTE
• Total Costs: 20475 DAI

The phases of the project are as follows.

1. Design - creating high-fidelity designs of the Minimum Viable Product and finalising the architecture and software interfaces to be developed.
2. Initial setup - creating the initial repositories for the software components as well as an integration repository. We will also set up continuous integration and continuous delivery to a staging server to be used to easily get feedback on developed software.
3. App development - Building the application systems functionalities.
4. Delivery - undertaking security audits and various other measures of software quality assurance, deploying to a demoable substrate test network and packaging and releasing software components

Not all the work outlined in this implementation plan is part of our W3F grant request. We have outlined software that will not be included in this grant in Section 2.8. As we will be concurrently developing our own software and the grant software, we can provide our entire project development plan for your understanding and to set expectations on delivery.

All our schedules assume two full time equivalent software developers / designers (2 FTE).

5.2 Milestone 1 - Prosopo Contract and Provider Service Development

• Estimated duration: 10 weeks
• FTE: 2
• Grant ask: 546 hours
• Grant cost: 13650 DAI

Number	Deliverable	Specification
0a.	License	GPLv3
0b.	Documentation	We will provide both inline documentation of the code and a basic tutorial that explains how a user can use the Contract docker image and Provider Service docker image. This will demonstrate how to register as a Provider from the command line and host and serve captcha data with a local Substrate Chain (Substrate Contracts Node).
0c.	Testing Guide	Core functions will be fully covered by unit tests to ensure functionality and robustness. We will describe how to run these tests in the project READMEs.
0d.	Docker	We will provide two Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
0e.	Article	We will publish an article that introduces Prosopo and the service it will provide. The contract features will be described in the README.md along with details how to run.
1	Prosopo Contract Development	Contract containing all set / get functions for Prosopo captcha service written in ink!. ink! Unit Tests for Prosopo Contract (80% coverage). External ink! contract containing function to check DApp User reputation in Prosopo Contract
2	Prosopo Provider Service	- Command line interface for Providers to: store a local captcha database (MongoDB), serve captchas to users, check captcha solutions, interact with the Prosopo Contract written in TypeScript. TypeScript unit tests (80% coverage)
2	External Contract	External contract containing function to check DApp User reputation in Prosopo Contract

5.3 Milestone 2 - Prosopo Client SDK & Delivery

• Estimated duration: 8 weeks
• FTE: 2
• Grant ask: 273 hours
• Grant cost: 6825 DAI

Number	Deliverable	Specification
0a.	License	GPLv3
0b.	Documentation	We will documentation that explains how to include the Captcha Client in a DApp website and smart contract. All previous documentation will be reviewed and finalised.
0c.	Testing Guide	Core functions will be fully covered by unit tests to ensure functionality and robustness. We will describe how to run these tests in the project README.
0d.	Docker	We will provide Dockerfile(s) that can be used to test all the functionality delivered with this milestone. These come as a single docker-compose file for all three services (Prosopo Client SDK, Provider Service SDK, Prosopo Contract)
0e.	Article	We will create a demo website on GitHub pages that shows how to implement the Captcha Client and create an accompanying article about this.
1	Prosopo Client SDK	This is a frontend JavaScript client presented to a DApp User that will check account status, request captchas from the Prosopo Provider Service, submit solutions, validate captcha data with on-chain commitment from Provider, validate solution was approved on-chain. Unit tests will be provided. The client will be written in TypeScript.
2	Demo Website	We will create a demo website on GitHub pages that shows how to implement the Captcha Client.
3	Integration Repository	Scripts to run all components in developer environment

6 Future Plans

The Prosopo captcha service will be deployed to a Substrate chain (chain to be confirmed) that implements pallet-contracts. This will be the initial version of the service and will help us refine before deploying on additional chains. Initially, Provider registrations will be invite only and will be opened up once the service is deemed to be properly functioning.

6.1 Enhancements

6.1.1 Captcha Service SDK

The following features will be added to the Captcha Service SDK:

6.1.1.1 Multilingual support

Initially, captchas will either be language-independent or English based. This will be expanded to cover as many languages as possible.

6.1.1.2 Database support

Captchas will initially need to be stored in a database on the Providers server. This feature will be improved to accept multiple different types of database and also distributed storage, such as IPFS.

6.1.2 Prosopo Smart Contract

The following features will be added to the Prosopo smart contract:

6.1.2.1 Difficulty Levels

It will be possible for Dapp Operators to request captchas of different difficulties.

6.1.2.2 Time-based Difficulty Scheduling

It will be possible for Dapp Operators to request captchas of different difficulties by different times of the day.

6.1.2.3 Voting on Captcha Formats

Initially, the captcha formats will be limited however it will be possible for community members to submit new formats in future and vote on their inclusion in the system. This will increase the variety of available verification methods. This opens up the possibility of distributed reputation stores that each hold their own database of account scores (or credit scores).

6.1.2.4 Self-referencing

A self-referencing reputation system will be created by assigning some small amount of positive reputation to previously unknown new Dapp Users if they are vouched for by existing Dapp Users with large positive reputations. Vouching may involve some kind of staking.

6.1.2.5 Provider FRAME Pallet

A pallet may be introduced so that the Provider service can become part of the Substrate chain hosting it. This will reduce the need for multiple services to be run by Providers as the Provider Service SDK would not be required, instead replaced by a single substrate node. This strategy may also increase Provider numbers if a major chain adopts the pallet.

6.2 Promotion

Prosopo will be promoted initially via campaigns directed at Dapp Operators in the Polkadot ecosystem. There are currently interested partners in the NFT space with a desire to prevent bots from registering en-masse to claim the majority of tokens from airdrops.

6.3 Support

Prosopo will be supported by the team members who will function as the governing body initially. These roles will eventually be rewarded via a native token and open up to the general public. A community forum and documentation centre will be created to encourage participation.

Prosopo will be running at least one Provider service to ensure that the network has a constant supply of captchas.

6.4 Long Term Plans

Prosopo will be ported to other Polkadot contact parachains such as the Moonbeam’s, which enables contracts that use the EVM (Ethereum Virtual Machine).

The team is committed to contributing to the Prosopo governing body in the long term and fostering community involvement.

Ultimately, we would like to see innovations in bot detection in the blockchain space and believe that a marketplace for human verification methods is an optimal solution. Whilst captchas are currently the focus, future verification may involve grading the humanness of accounts based on account activity and connections. The Prosopo smart contract and Provider service will be flexible enough to accommodate these new formats.

7 Additional Information ➕

7.0.1 How did you hear about the Grants Program?

Web3 Foundation Website

7.0.2 Additional Info

Financing of this proposal and non-grant related development has been funded by Prosopo Limited. There are no other parties involved other than those listed in this document. No previous funding has been received.