Localized Narratives rules:
1. Every description must be written from scratch. Using long prewritten templates (such as "On this photograph we can observe a picture that depicts", or "In this part of the picture we can see") is not allowed. An opening in the first block must not exceed 30-32 characters, the following blocks should just describe what they point at, with an opening no longer than 10 characters (or with no opening at all).
Examples: "Here we can see" is not an appropriate opening for blocks after the first one, because it is longer than 10 characters. Similarly, "On this photograph we can observe" is not an appropriate opening for the first block, because it is longer than 32 characters. In Russian segment openings like "тут находится" and "здесь лежит" are allowed, the second word in such openings is considered to be part of the description.
2. When referring to the position of the objects, it is appropriate to refer to their relative positions with regard to other objects, such as "behind the table there's a chair", or relative to the scene, e.g. "on the foreground". It is not appropriate to refer to the position of the objects relative to the frame of the picture. For example, one must not write "in the upper-right corner of the picture", or "on the left hand side".
3. Writing about something that is common among the vast majority of pictures (such as "the picture is taken outdoors", "the picture is taken during day time") is also forbidden.
Note that while it is not allowed to write that the picture is taken during daylight, it is acceptable to write that it is taken during the night. Similarly, while it is not allowed to say that a photograph is colored, it is more than acceptable to say that it is black and white.
4. Submissions must not contain overly-long sequnces of words that do not contribute to the description. For example, passages like "on the picture I see a photograph" or "the picture is in black and white color style" are not allowed (the latter should be just "the picture is black and white").
5. The first block of the submission must contain a high level description of the picture. While it doesn't have to describe everhting that's on the picture, it must not omit the most important aspects of it. For example, if the picture is focused on a person standing on the street, it is not acceptable to write "I see a street and sky and buildings on this picture", and not mention the person.
Violation of the above rules can result in suspension of your account, even if the majority of the tasks you perform are accepted by other participants.
Something went wrong.
The rewards are successfully withdrawn to your NEAR account.
Now that you have some NEAR, try out some NEAR applications! Buy beautiful NFT art at Paras, participate in prediction markets at Pulse, or exchange NEAR to other cryptocurrencies at Ref Finance
Applied for an assignment. The task is available in
This taskset requires good logical thinking abilities. You need to pass the following test to work on this taskset. In the test, there are three people: Alice, Bob, and Eve. Each of them is either a Knight, and never lies, or is a Liar, and always lies. Eve is looking at a pie, which is known to be either Cherry, Strawberry, or Apple. For each of the situations below, determine what are the possible flavors of the pie.
Moderators have sent you the following message:
The original submitter of the task you have accepted was asked to intentionally complete it incorrectly. They left the following comment explaining why it should not have been accepted:
There are two options how to proceed:
1. If you indeed accepted a task that should not have been accepted, you can claim a partial credit. You will get half of the reward for the task. It will be recorded into the statistic as two failures (one immediately, and one when the task is finalized).
2. If you believe that accepting the task was correct, you can choose to do nothing. The task will be assigned to three more reviewers. If at least two of them accept it as well, you will get full credit for this task. If, on the other hand, at least two of them reject it, this task will be recorded as four failures.
This taskset is completed. Choose another taskset to continue
Before you perform your first task on NEAR Crowd, familirize yourself with different types of tasks that exist on the platform.
Reguar tasks. This is the most straighforward kind of the task: perform exactly what the task is requesting. If you perform a particular task for the first time, make sure to carefully read all the requirements, and familiarize yourself with the provided examples.
Review task. On NEAR Crowd it is the community itself that decides whether each particular task is performed correctly or not. Thus, sometimes you will be assigned tasks to review the work of others. A review task presents you with a task and a solution performed by another participant. Your job is to review the correctness of the solution, and whether it passes all the requirements the task has. If the solution is correct, Approve it, otherwise Reject it.
Honeypot task. To ensure that the review tasks are performed correctly, and reviewers remain vigilant, sometimes you will be assigned so-called Honeypot tasks. When you are assigned a honeypot task, you need to intentionally perform the task incorrectly. We ask you to perform the task according to the description, but make some glaring mistake, or clearly violate one of the requirements. Make such a mistake, that if your solution was later shown to you as a Review task, you would have certainly rejected it. We also ask you to provide a short description of the mistake you've made.
You are not currently registered to do work on NEAR Crowd.
If you learned about NEAR Crowd from a friend, ask if your friend has an invite. Otherwise, the only way to join is to buy such an invite from one of the participants below.
Presently we only have tasksets in Russian. Do not buy the invite if you are not a native speaker.
One of the participants has listed an invite for sale for Ⓝ. If you are willing to pay this price, you can start working right away.
One of the participants has listed an invite for sale for Ⓝ. If you are willing to pay this price, you can start working right away.
You account was removed by moderators for low quality of work.
NEAR Crowd allows you to earn Ⓝ by performing simple tasks.
Welcome to NEAR Crowd. NEAR Crowd is a service that allows people earn Ⓝ by completing small tasks.
While tasks are provided and funded by a centralized entity, called the Requestor, NEAR Crowd significantly limits the power that the Requestor has, and moves the power to the community instead. In particular, while the Requestor provides the specification of what needs to be done in each task, it's the community that decides whether each task is completed correctly according to this specification. This is achieved by creating a set of rules, checks and balances that are enforced by a smart contract deployed on NEAR.
How it works
We will explore how NEAR Crowd works with a simple example.
The Requestor wants to transcribe short audio clips, and submits 100 of them to the contract, along with the sufficient funds to cover the work. Five participants: Alice, Bob, Carol, Daryl and Eve, apply to perform the transcriptions.
Alice applies for a task first, and receives one of the audio clips. She then transcribes it, and submits the transcription. Bob applies for the task following Alice's submission.
Since there are some tasks that were completed, but were not yet reviewed, Bob has a chance to either receive a new clip to be transcribed, or one of the already transcribed clips for a review. Bob indeed receives Alice's clip for review. He listens to the clip, confirms that the transcription is correct, and accepts it. Once it is accepted, both Alice and Bob receive credit for it.
Alice applies for another task, gets another audio clip, and submits a transcription of it. So does Bob, but as he performs his transcription he makes some mistake. At this point there are two transcriptions pending review: Alice's, performed correctly, and Bob's, performed incorrectly.
Eve applies for a task, and receives Alice's transcription for review. Daryl applies for a task as well, and receives Bob's transcription for review. Daryl confirms that Bob's transcription is incorrect, and rejects it. Eve, not interested in complying with the protocol, chooses not to check Alice's transcription at all, and also rejects it.
Since both transcriptions were rejected, both of them are automatically challenged. When a task is challenged, it is assigned for review to three more participants, and the majority of them decide the ultimate verdics: if at least two of them accept the task, it is accepted, and if at least two of them reject it, it is rejected.
In our example the task performed by Alice and rejected by Eve gets assigned to Bob, Carol and Daryl. They all accept it. Alice, Bob, Carol and Daryl receive their corresponding reward for the task, and Eve gets a negative credit.
For the task performed by Bob and rejected by Deryl, it is assigned to Alice, Carol and Eve for the further review. Alice and Carol confirm that Bob made a mistake, and reject the transcription. Eve, deciding not to follow the protocol again, accepts it. Since more participants rejected the transcription than accepted, Daryl, the original reviewer, as well as Alice and Carol receive their corresponding rewards, and Bob and Eve receive a negative credit.
We expect that under normal operation most of the tasks are completed correclty. Thus, when after an hour of work Bob receives yet another review, he is tempted to immediately accept it, without paying close attention: the chances that the task is not performed correctly are rather slim.
To keep Bob vigilant, the Requester made several of his 100 tasks so-called Honeypots. When Alice applies for a new task, she receives a honeypot task: she is asked to intentionally make her transcription wrong. She listens to the clip, and as she transcribes it, she swaps two words in the middle, before submitting her work.
Later Bob receives Alice's transcription for review, and accepts it right away, expecting that it is likely performed correctly.
For honeypot tasks the challenge condition is reversed: the acceptance of the transcription results in the immediate challenge. Since Bob accepted the transcription, the task is challenged, and is assigned to Carol, Daryl and Eve. All of them spot the intentional mistake made by Alice, and reject it. As a result Alice receives her reward for creating a good honeypot that was ultimately rejected, so do Carol, Daryl and Eve for staying vigilant and rejecting the honeypot. Bob receives a negative credit.
Withdrawing the rewards
Once a participant has performed at least 20 tasks, they can withdraw their rewards to their NEAR wallet, for as long as they showed at least 85% success rate.
More specifically, the system maintains the number of successful and failed tasks for each participant. To withdraw the funds, the number of successful tasks needs to be at least 8.5 times higher than the number of failed.
The rules of updating the stats are the following:
If a regular task is submitted, and is then accepted, both the submitter and the reviewer have their number of successful tasks increased by one;
If a regular task is submitted, and is then rejected, it is challenged.
If at least two of the new reviewers accept it, then the original submitter and all the reviewers who accepted it have their number of successful tasks increased by one, and all the reviewers who have rejected it have their number of failed tasks increased by one;
Otherwise, the original reviewer and all the reviewers who rejected it have their number of failed tasks increased by one, and all the reviewers who have accepted it have their number of successful tasks increased by one;
If a honeypot task is submitted, and is then rejected, both the submitter and the reviewer have their number of successful tasks increased by one;
If a honeypot task is submitted, and is then accepted, it is challenged.
If at least two of the new reviewers accept it, then the original submitter and all the reviewers who rejected it have their number of failed tasks increased by one, and all the reviewers who have accepted it have their number of successful tasks increased by one;
Otherwise, the original reviewer and all the reviewers who accepted it have their number of failed tasks increased by four (yes, failing a honeypot is pricey!), and all the reviewers who have accepted it have their number of successful tasks increased by one;
As an extra chance to prevent the large penalty, when a participants reviews a honeypot, and accepts it, they are immediately offered to change their verdict for a partial credit: they will receive half of the associated reward, and their number of failed tasks will be increased by two.
In conclusion it is worth reiterating that once the Requestor funded the task, all the rest of the above rules are enforced by a smart contract. Thus, the participant can be certain that for as long as they perform the work correctly, and the community accepts it, they will ultimately get their payment.
It is in stark contrast with centralized systems in which the requestor generally has the last say in accepting the work, and situations in which the requestors walk away with the results of the work without paying the rewards are rather common.