User Guide
How to work with the system: concepts, getting started, and role-based guides
General concepts
This section is a glossary and a map of the system. Read it once before you start: all the other guides ("submit a proposal", "close a milestone", "publish a task") rely on these terms. Whenever something is unclear later, come back here.
What this platform is
This is a marketplace where customers post tasks and executors complete them for a reward. The key difference from an ordinary message board is the secure deal: money for a task is not handed over directly - it is reserved by the system and paid to the executor only after the work is accepted. More on that in «Money and the secure deal».
Roles: who is who
You have one account, but you can act in different roles on different tasks. Today you order work, tomorrow you do someone else's. Your role is defined not by your profile, but by the position you hold on a particular task.
Customer
The person who creates and pays for a task. The customer describes what needs to be done, sets the budget, splits the work into milestones (subtasks), publishes the task, selects executors and accepts the result. The final say on every decision belongs to the customer.
Executor
The person who does the work. The executor finds a suitable task, responds to it (submits a proposal), and - if selected - completes the work and gets paid.
Team Lead
A special role - it appears only in Team mode (see below) and only if the customer chooses to add it. The Team Lead is the customer's trusted deputy, not a senior executor: they do exactly what the customer chose to entrust to them, and nothing beyond that. The customer picks that set themselves.
At the same time the Team Lead is an ordinary executor of their own milestone and is paid out of its budget. There is no Team Lead on simple tasks.
"Team Lead" is the interface term. What can be entrusted to them and what never can is described in «Teamwork».
Important. Roles are about a specific task, not about a person. The same user can be the customer on one task and an executor on another.
Task
A task is the central unit of the system: a description of the work to be done, with a budget and terms. All work on the platform starts with a customer creating a task.
A task goes through several states. In the tasks menu they are grouped into sections exactly as you see them in the interface:
| Menu section | What it holds | In plain words |
|---|---|---|
| Drafts | tasks in preparation | Being created and edited. Not yet visible to executors. |
| Open Tasks | published tasks | Visible to executors, proposals are being collected. |
| In Progress | tasks under way | Executors selected, work is ongoing. Paused tasks also live here. |
| Completed | finished tasks | Work accepted, task closed. |
| Archive | completed tasks moved out of the list, and canceled ones | No work is being done on the task any more. |
While a task is in Drafts, the customer can freely change everything - description, budget, the set of milestones. After publication (moving to Open Tasks) some parameters become fixed (see the role-based guides).
Proposal
A proposal is an executor's response to a task. By submitting a proposal the executor tells the customer: "I'm ready to do this work (or part of it) on these terms." The customer reviews the incoming proposals and decides whom to choose.
A proposal also goes through states: it may be under review, accepted or rejected by the customer, withdrawn by the executor, or expired if no decision was made in time.
An accepted proposal is the moment when an executor "gets" the work, and their reward is counted into the task's working budget.
Milestone
A milestone is a checkpoint or a separate part of the work within a task. Large work is conveniently split into milestones: each has its own meaning, its own result, and can be paid for separately.
Milestones are created by the customer while the task is still a draft. After publication the set of milestones is fixed and can no longer be changed freely.
Why milestones matter:
- Transparency - both customer and executor see which step the work is at.
- Step-by-step payment - payment is tied to completing specific milestones, rather than paid all at once.
- Work distribution - in Team mode different milestones can be done by different executors.
A simple task may consist of a single milestone; a large one - of several, going in order.
Task modes: Solo and Team
When creating a task, the customer chooses one of two modes of work.
Solo
A single executor works on the task. All milestones are assigned to them. This is the simplest and most common case - suitable for most small tasks.
Team Mode
Several executors work on the task, and milestones can be distributed among different people. Team mode is more complex and is organized in two phases:
The customer may add a Team Lead and delegate part of their own functions - this is optional, a team task works fine without one. One setting decides the recruiting order:
- the Team Lead accepts proposals - recruiting runs in two phases: only the Team Lead milestone is open at first, the rest open after they are appointed;
- the customer accepts proposals - no phases, all milestones open at once.
The whole picture is on the diagram in «Teamwork».
If you are just starting, Solo is probably the right choice. Team mode makes sense when the work is large and naturally divided among several people.
Money and the secure deal (escrow)
This is perhaps the most important concept to understand - and exactly what sets the platform apart from ordinary "trust-based" freelancing.
Wallet and balance
Every user has a wallet with a balance. To order work, a customer needs funds on the balance; an executor receives payment to their balance.
Reservation (escrow)
When a customer publishes a task, the system does not give the money to the executor right away. Instead, it reserves the required amount on the customer's balance - freezes it for this task. This is escrow.
Analogy. Escrow works like a notary's safe. The customer puts the money in the safe before the work begins. The executor sees that the money is already set aside and won't go anywhere. But the executor can only take it once the work is done and accepted. Both sides are protected: the customer doesn't pay for undone work, and the executor is sure the payment is guaranteed.
Reserved funds cannot be spent on anything else - they are "tied" to the task until it is completed or canceled.
Task budget
A task has a budget - the amount the customer is willing to pay. While the task is a draft, the customer can change it freely. As the customer accepts executors' proposals, the working budget forms - the actual amount of obligations for the task. If, by the time the work starts, the working budget differs from the originally set amount, the system automatically recalculates the reservation.
Detailed money scenarios for each role are in «I am a Customer» and «I am an Executor».
Notifications and chat
The system reports important events (a new proposal, work acceptance, a status change) via notifications. For communication about a task there is a chat - it can also deliver links that lead straight to the needed action (for example, to a milestone form).
Private margin notes («stickies»)
A margin note is a private note you attach to a chat message or to a milestone. It solves one problem: two weeks later, finding the moment you remember as "we discussed this somewhere around here", and not losing the thought "must ask about the mock-ups" without turning it into a message to the other person.
The key property: only you can see the note. Not the other side of the deal, not the Team Lead, not an arbiter handling a dispute, not support, not the platform administrator. It is not a message and not a comment - it is a note to yourself.
Notes are encrypted with your personal key. The key is opened by your password and PIN code when you sign in, so nobody else can read the text of a note - not even someone who got hold of a copy of the database. This has two consequences:
- if you forget your password and regain access with your recovery key, your notes are preserved;
- if you regain access without the recovery key, your notes are lost for good: no one can bring them back, including the administration. See «Getting started → Recovery key».
If you see «Sign out and sign in again» instead of your notes, just sign in again: the key for your notes is issued at sign-in.
What it looks like:
- In the chat, hovering over a message reveals a sticky icon. A click opens a small window: the text, five colours to choose from, a «pin» checkbox. Once saved, the icon stays visible and takes the note's colour - the marked moments stand out along the thread.
- On a milestone - the same icon in the card header, both on the task management page and in the workspace.
- The «My notes» tab on the task page collects all your stickies as cards: pinned first, the rest newest to oldest, with filters by colour and by place (messages or milestones). From a card you can jump to the source - the chat opens at the right message and highlights it.
Colour means nothing to the system and affects nothing: it is your own coding
- yellow for «ask», blue for «important», green for «done», whatever suits you.
The limits are simple: an empty note cannot be saved, the text is up to 1000 characters, and one message or milestone holds at most 20 stickies. In a closed task (completed, canceled, archived) notes remain readable, but you can no longer create or edit them; deleting your own note is always possible.
If the other person edited the message, or it was removed, the note does not disappear: it gets a mark saying the source has changed or is no longer available. The text of the note is yours, and the system does not delete it because of somebody else's action.
What notes do not do. They cannot be shared and cannot be turned into a message. They take no part in disputes: an arbiter does not see them and they are not included in the dispute materials - if something matters for a dispute, it must be said in the chat. They raise no notifications, and they have no attachments and no formatting.
Resource links and phishing protection
On a platform where money moves, a fake link is the most common way to cheat people: "log in over here", and the address differs from the real one by a single letter. That is why a task and a milestone have a separate Resource links block, built differently from an ordinary address field.
How it works: you do not type the whole address. You pick a resource from a system directory of vetted resources (for example, "GitHub - profile") and enter only the parameter - an account name, a repository name and so on. The server assembles the address, and the host cannot be substituted through the parameter. In effect the link field becomes a whitelist of allowed addresses.
If the resource you need is not in the directory, there is an Add resource button - a request goes to the administration.
Links in the task description and in the chat stay ordinary - unverified. The system does not parse them and does not vouch for them. A link from the resource block can be posted to the chat - it will be marked as verified. Treat everything else that arrives in a conversation with care: check the address, and never enter your password, PIN code or wallet seed phrase on third-party sites.
Quick glossary
All terms with short, plain-language explanations - including the subtle differences between the budget types - are collected in a separate «Terminology» section. Keep it at hand while you get up to speed.
Next: the «Getting started» section - how to register, top up your balance and take the first steps.
Terminology
Here are all the terms that appear in the interface and in this documentation, with short plain-language explanations. Names are given as they are shown in the app. If something is unclear in the text, look the word up here.
People and roles
Customer The one who creates and pays for a task. Makes the final decisions: whom to choose, whether to accept the work. There is exactly one customer per task.
Executor The one who does the work and gets paid for it. In a Solo task there is one executor; in Team mode there may be several.
Team Lead The leader of the team on the execution side. Appears only in Team mode and only if the customer chooses to add them - helps organize the work of several executors. There is no Team Lead on ordinary tasks. (In the interface the role is called Team Lead; in Russian and Ukrainian it is transliterated as «Тимлид» / «Тімлід».)
Remember: a role is tied to a specific task, not to a person. One account can be the customer on one task and an executor on another.
Task and work
Task A description of the work to be done, with a budget and terms. The core unit of the system - everything starts with creating a task.
Proposal withdrawal The executor takes their proposal back. If it has not been accepted yet, there are no consequences; if it has already been accepted, withdrawal carries a penalty and affects reputation. If a security deposit was placed on the milestone, withdrawal costs that too. An accepted proposal can be withdrawn only before the task starts.
Proposal statuses
| Status | What it means |
|---|---|
| Under review | the customer has not decided yet |
| Accepted | the executor is assigned to the task or milestone, the amount is in the working budget |
| Rejected | the customer chose another executor |
| Withdrawn | the executor took the proposal back |
| Expired | no decision was made before the proposals deadline |
Verified link (verified resource) A link assembled from the system directory of vetted resources: the platform sets the fixed part of the address, the user enters only a parameter. Such links are marked as verified.
Unverified link Any link entered as free text - in a task description or in the chat. The platform does not check it and does not vouch for it. Open with care.
Proposal An executor's response to a task: "I'm ready to do this on these terms." The customer reviews the incoming proposals and decides whom to choose.
Milestone A separate part of the work or a checkpoint within a task. Large work is split into milestones to track progress and pay for it in parts.
Draft A task that is still being prepared and is not published. Visible only to the customer, who can change it freely.
Publication The moment when the customer makes the task visible to executors (it moves to the Open Tasks section). After publication some parameters become fixed.
Antivirus scan Every uploaded file is scanned by antivirus. Until the scan has passed the file cannot be downloaded; an infected file is rejected. Password-protected archives are not accepted at all - their contents cannot be checked.
Service milestones "Project Start" and "Project Completion" - created by the system in every task. They are points on the schedule, not work: they have no executor, no proposals are submitted for them, and "Project Start" has no budget either. "Project Completion" closes automatically when the task is closed.
Milestone result What the executor submits for a milestone: files, links, a description of what was done. This is what the customer reviews at acceptance.
Milestone acceptance Reviewing and accepting the result. The sides have different rights here, and it is important not to mix them up:
| Action | Executor (of own milestone) | Team Lead | Customer |
|---|---|---|---|
| Put the milestone up for acceptance | ✔ | ✔ | ✔ |
| Accept the milestone (and pay) | - | if delegated | ✔ if not delegated |
| Send back for revision | - | if delegated | ✔ if not delegated |
| Open a dispute | ✔ | if delegated | ✔ if not delegated |
| Cancel the milestone | - | - | ✔ until the work is submitted |
The Team Lead sits in a separate column for a reason: they act on the customer's behalf in the functions that were delegated to them, and the customer no longer sees buttons for those. On their own milestone the Team Lead never has these rights - there only the customer decides.
The customer can also put a milestone up for acceptance - this is not "accepting the work from themselves". It records the fact that the work has been delivered when the executor forgot to press the button. The acceptance decision is a separate action.
Revision Returning a milestone to the executor for fixing - with a mandatory comment on exactly what needs to be corrected. After revision the milestone is put up for acceptance again. The completion percentage drops from 100 to 99.
Dispute Recording a disagreement over a milestone when the sides could not settle it in the normal course of work. Either side can open a dispute - the customer (the work is not done or has gross errors) as well as the executor (the work is not being accepted for no clear reason, or is returned for revision endlessly). A detailed comment is required. While a dispute is open, the money for the milestone stays frozen in the reservation.
Dispute resolution A two-stage procedure: first the sides agree on a payment amount themselves; after 5 days either side may escalate to a platform staff member (arbiter) whose decision is final. Partial payment is possible - for the part of the work actually done. Under development.
Rating (mutual) After a task is completed, the customer rates the executor and the executor rates the customer. Forms the reputation of both sides.
System (synthetic) rating If one side did not leave a rating when the task was closed, the system puts a provisional maximum rating in their place so that closing is not blocked. How it works:
| Question | Answer |
|---|---|
| When it appears | at the moment the task is closed, not "after 7 days of silence" |
| How long you have to replace it | 7 calendar days from the task closing |
| Can it be replaced with your own | yes, within those 7 days; after that it is fixed permanently |
| Does it affect the average rating | no. System ratings are not counted in the average |
| Is its status visible | yes, such a rating is marked as system-generated |
That is the point: one side's silence should neither block the closing nor inflate the other side's rating. So the rating is recorded, but stays out of the average - and if you manage to leave your own, it replaces the system one and is counted.
Margin note («sticky») A private note attached to a chat message or to a milestone: text and colour. Visible only to its author - not to the other side, the Team Lead, an arbiter or an administrator. All your notes on a task are collected in the My notes tab. See «General concepts» for details.
Security
Confirmation code A one-time code from the registration email - needed only to confirm that the email is yours. Not to be confused with the PIN code.
PIN code Your personal, permanent secret on which quantum-resistant encryption of critical data is built. The system does not store it - only you know it. That is exactly why the data is protected: what isn't in the system cannot be stolen or exposed. The PIN code cannot be recovered - lose it and you lose access to the data encrypted with it. It is neither the login password nor the email code.
Money
Account Your record on the platform. You have one account, and your roles (customer, executor) depend on the particular task.
Account activation A one-time payment in AGTI to the system wallet, after which the account gets full access to work. The wallet the payment came from is bound to the account.
System wallet The platform's wallet that receives activation payments and fees.
Wallet / Balance A user's personal account in the system. The customer needs funds to order work; the executor receives payment to their balance.
Available balance The part of the balance you can use right now: publish tasks, withdraw funds. Counted separately for each token.
Reserved balance The part of the balance frozen for specific tasks. The money is still yours, but you cannot spend it on anything else until the task is completed or cancelled.
There is one wallet, but it holds several tokens and each balance is counted separately:
| Token | What it is for |
|---|---|
| KNL | platform fees: creating a task, paid options |
| AGTI | account activation, buying capabilities - subscriptions and add-ons |
| USDT | settlements on tasks |
Work can be paid in any of the three: the customer picks the token when creating the task, and every milestone is paid in it.
AGTI is not only about activation: it also pays for subscriptions, which determine your limits (how many executors and milestones a task may have, whether a Team Lead is available). A wider role is planned for AGTI - participant statuses, taking part in dispute resolution and in platform governance; that part is under development.
Reservation (escrow) Freezing money for a specific task. On publication the system does not give the money to the executor right away - it sets aside the required amount from the customer's balance and holds it until the work is accepted. Both sides are protected. Analogy: a notary's safe - the money is already set aside, but the executor gets it only after acceptance.
Next come three budget types. They are easy to confuse, so let's go in order.
Preliminary budget The very first, rough estimate of cost that the customer enters in the wizard when creating a task. It does not participate in further calculations and does not change after the draft is created.
So why is it needed. It is the starting point for distributing the budget across milestones, and a historical trace: you can see what estimate the task started from and how far it drifted from the fact. Executors see the declared budget in a published task, not this estimate.
Declared (committed) budget The budget the customer sets and refines while the task is a draft. This is the amount they are willing to allocate. On publication, exactly this amount is reserved (frozen) for the task.
Working (accepted) budget The actual amount of obligations for the task - it is built up from the accepted proposals of executors. As the customer accepts proposals, the working budget accumulates. This is the "real" cost of the task once it has gone into work.
What matters about the working budget:
| Question | Answer |
|---|---|
| Does it include the Team Lead's reward | yes - their work is a separate milestone with its own budget |
| Can it exceed the declared budget | yes, if the accepted proposals add up to more. The difference must be covered when the task starts - see "Re-reservation" |
| Can several proposals relate to one milestone | no: one milestone is performed by exactly one executor |
| Is each milestone paid separately | yes, right at its acceptance |
| Does the reservation shrink after a milestone is paid | yes, the payment comes out of the reserved funds |
| Are fees included in it | no. This is the amount owed to executors; withholdings from the payment are counted separately (see «Money and the secure deal») |
In short. Preliminary - "an estimate at the start". Declared - "how much I'm willing to pay and have frozen". Working - "how much it really costs based on accepted proposals".
Re-reservation An automatic recalculation of the frozen amount. If, by the start of the work, the working (accepted) budget differs from the declared one, the system releases the old reservation and freezes the new, correct amount. It happens automatically; if the balance is short, the system will say so.
Executor's security deposit An amount the executor freezes on their own balance when taking on a milestone. Whether to require it is the customer's choice, made per milestone; most tasks have no deposit. The point is equal responsibility: the customer's money is frozen against the task from the very start, while walking away would cost the executor nothing. The deposit is frozen the moment the customer accepts the proposal and is returned when the milestone is accepted - together with the payment. It is not a fee: the money stays yours. The customer never receives the deposit under any circumstances, except by an arbiter's decision in a dispute.
Fee A platform charge for operations. There are two kinds: one-off (for example, for creating a task - in KNL, charged on publication) and withheld from an amount (on payment to the executor and on withdrawal).
Current amounts are in About Platform → About fees and on the screen before the operation. This guide deliberately avoids specific figures: they change, and the documentation would go stale faster than the platform.
Blockchain network fee ("gas") The blockchain network's own charge for processing an operation - it arises when depositing and withdrawing funds. The platform does not receive it and does not influence its size.
Task cancellation The customer terminating a task. Milestones already accepted and paid stay paid, the unused remainder of the reservation returns to the customer. Cancelled tasks go to the Archive section.
Pause Temporarily stopping work on a task without terminating it. The reservation is kept and the task stays in the In Progress section. The status exists in the system, but a task cannot be moved into it yet - the feature is under development.
Archiving Moving a task to the Archive section. You can archive a completed task when the Completed list gets long; canceled tasks go there too. The task can still be viewed, but no work can be done on it.
Modes and phases
Solo (single mode) One executor works on the task, all milestones are theirs. The simplest and most common option.
Team Mode Several executors work on the task; milestones can be distributed among them. A Team Lead is added optionally.
Phase 1 The stage of organizing a Team task at which the customer (optionally) selects a Team Lead.
Phase 2 The stage of organizing a Team task at which executors are matched to each milestone of the work.
Task states (menu sections)
| Section | What it means |
|---|---|
| Drafts | In preparation, not visible to executors. |
| Open Tasks | Published, proposals are being collected. |
| In Progress | Under way (including temporarily paused). |
| Completed | Work accepted, task closed. |
| Archive | Canceled tasks. |
Next: the «Getting started» section - first practical steps.
Getting started
This section covers the path from your first visit to a ready-to-work account. You only need to go through it once. If some terms are unfamiliar, see «General concepts» and «Terminology».
Preparing your account takes four steps:
- Registration
- Email confirmation
- Account activation
- First login
Step 1. Registration
Open the registration page, enter your email and password, and accept the End-User License Agreement (EULA). After you submit the form, the system creates the account and sends a confirmation email to the address you provided.
[скриншот: registration_form]
Use a valid email address - the confirmation email is sent there, and without it you cannot log in.
What your password should look like
The password rules changed on 6 October 2026. Passwords you already set keep working - there is no need to change them.
- 12 to 128 characters;
- you can use any characters: letters of any alphabet, digits, punctuation, spaces and even emoji;
- a password cannot start or end with a space - so a stray space picked up while copying does not become part of your password;
- there are no rules like "must contain a digit and a capital letter": what makes a password strong is first of all its length.
The best choice is a phrase of several words that is easy to remember and
hard to guess, for example green cat eats soup on wednesday. It is longer and
stronger than a short string like Pa$$w0rd! - and easier to remember.
Your password is accepted the same way on any device: letters typed on a phone and on a computer are treated as the same letters.
Step 2. Email confirmation
Open the email from the system and follow the confirmation link. Then enter the confirmation code given in the email. This protects against registering on someone else's address and confirms the email is really yours.
[скриншот: confirm_code]
Do not confuse the confirmation code from the email with your PIN code
- they are different things. The confirmation code is needed only once, to confirm the email. The PIN code is your permanent secret for encryption (see the «Security: your PIN code» section below).
If the email doesn't arrive, check the "Spam" folder. You can request the email again on the "Resend confirmation" page.
After the confirmation code is entered successfully, your email is considered confirmed.
Step 3. Account activation
A confirmed account must be activated before you can work with tasks and money. Activation is a paid system operation: you make a one-time activation payment to the platform's system wallet.
How it works:
- From your blockchain wallet, send the activation payment to the system wallet - the system shows the exact address and amount. (At the moment the amount is 100 AGTI; for new users it may change, so always rely on the value shown on screen.)
- The wallet the payment came from is automatically bound to your account. This binding is unique within your node: one wallet is attached to one user of that node. From then on, this wallet is your working wallet on the platform. (What a node is - see «The network and its nodes».)
- As soon as the payment is confirmed on the blockchain, the account becomes activated - automatically, with no manual steps.
[скриншот: activation_payment]
Why this way. The platform works with real funds via escrow (see «Money and the secure deal»). A payment from a wallet both activates the account and attaches a verified wallet to you - the one you both send and receive payments through.
Activation progress is visible by status: payment sent → payment confirmed → activation complete. If something goes wrong, the system shows the reason.
Step 4. First login
After activation, log in with your email and password. You'll land on the Dashboard - the starting screen with an overview of your tasks, proposals and balance.
[скриншот: dashboard]
Getting to know the interface
The main menu is on the left. The most useful sections:
| Menu section | What for |
|---|---|
| Dashboard | General overview: your tasks, proposals, balance. |
| Marketplace | Searching for tasks and executors, categories, ratings. |
| I'm a Customer | Everything about the customer role: creating a task, drafts, open and current tasks. |
| I'm an Executor | Everything about the executor role: finding work, your proposals, active orders, earnings. |
| Finances | Wallets and topping up the balance. |
Reminder: one account can be both a customer and an executor. The I'm a Customer section is for when you order work; the I'm an Executor section is for when you do someone else's.
Language and date format. The interface is available in several languages; the switch is in the page header. The date and time format changes together with the language: it is defined per language, so the same date looks different in different languages. This is a platform setting, you don't need to change anything by hand.
Wallet and topping up the balance
To order work, you need funds on the balance: when a task is published, the system reserves an amount for it (escrow). To do work, you usually need no funds - payment comes to your balance after acceptance.
One exception - the security deposit. The customer may require an executor's security deposit on a milestone: this is your own money, frozen for the duration of the work and returned together with the payment. The amount is visible in the task in advance, and it must be on your balance at the moment your proposal is accepted. See «Money and the secure deal» for details.
Topping up the balance:
- Open Finances → Deposit Funds.
- The system shows the address, the amount and a QR code. Open your wallet app (Trust Wallet, MetaMask and the like) and scan the QR code - the details fill in by themselves, no need to type the address by hand.
- After the transfer is confirmed on the blockchain, the funds appear on your balance.
Scanning the QR code is safer than typing: a wallet address is a long string, and a typo in it means the funds are lost for good.
You don't have to wait on the page. A blockchain transfer is not instant: first the network accepts it, then it is included in a block, then the block becomes irreversible. That usually takes a few dozen seconds. The platform used to learn the outcome only while the status page was open; now it finds out the fate of the transfer by itself, so you can close the tab - the credit and the notification will still arrive. The same applies to paying for account activation.
If you set the network fee too low, the transfer may get stuck: the network sees it but does not include it in a block. Such a transfer is not lost and is not cancelled by the platform - it stays in the list as pending and may go through even days later. A transfer rejected by the network is not executed, and no money is taken.
[скриншот: deposit]
Your current balance and transaction history are always visible under Finances → Wallets.
Security: your PIN code
The system has a PIN code - your personal secret on which quantum-resistant encryption of critically important data is built. This is not the email code and not the login password - it is a separate key known only to you.
What it should look like
You invent the PIN code yourself during registration and enter it once - after that it does not change on its own and is never displayed anywhere.
- at least 6 characters;
- letters, digits and special characters are allowed - this is not a four-digit bank-card PIN but rather a short passphrase;
- the longer and more varied, the better: your data encryption rests on it.
It is required at every login
Signing in takes three fields: login or email, password and the PIN code. Without the PIN code you cannot sign in, even with the correct password.
The key things to understand:
- The system does not store your PIN code in readable form. The database holds only its protected fingerprint, which is additionally encrypted with a key that is not in the database: a copy of the database is not enough to guess your PIN. The PIN never gets into the logs.
- That is exactly why your critical data is genuinely protected: what is not in the system cannot be stolen or disclosed. Even the platform itself cannot decrypt that data without your PIN code.
- The encryption (AES-256 with key derivation via Argon2id) withstands attacks even from future quantum computers - hence "quantum-resistant".
What happens if you lose it
Two things must not be confused here:
| What is lost | Can it be recovered |
|---|---|
| Password | yes - by email. With the recovery key your personal data is preserved, without it - lost (see below) |
| PIN code | no. Not by you, not by support, not by an administrator |
The PIN code cannot be recovered, and the consequences are serious. It is required at every login, so without it you cannot sign in to your account - not merely read the encrypted data. Neither support nor the administration can help: there is nothing to return to you, the system does not know this secret.
Write it down and keep it safe - in the same place you keep access to your crypto wallet. It is exactly the same category of secret.
Changing your password and PIN code
The password and the PIN code are changed in Settings → the «Security» tab. To change the password you need the current password and PIN code; to change the PIN code - the current password and the current PIN code. This way your encrypted data is re-encrypted under the new key and is not lost.
Next to each field there is a button with an eye icon - it shows what you typed so you can check for typos, and hides it again.
Recovery key
The recovery key is the only way to keep your personal data if you forget your password. Without the key you can get your account back, but your encrypted personal data will be lost forever. No one can restore it, including the platform administration: we do not have this key and we do not store it.
How to get the key
The key is issued once and takes about two minutes.
- Sign in. If you are already signed in, sign out and sign in again.
- The «Your recovery key» window appears. Click «Show my recovery key».
- Save the key - 6 groups of 5 characters - with «Download as file» or «Copy». Put it into a password manager or write it down on paper and keep it with your important documents. The key is shown only once.
- Enter the group of the key with the given number, tick «I understand…» and click «I have saved the key».
Until the key is saved, the window appears after every sign-in and cannot be closed.
How to check that everything is fine
- The key is saved correctly if you entered the requested group from your saved copy rather than from the screen. Open the file or note and make sure all 6 groups are there.
- Password and PIN code - sign out and sign in again, typing them by hand rather than using browser autofill. You can check what you typed with the eye button.
- After every password or PIN change you receive an email: time, location, IP address and device the change was made from. The IP address is a link to a service that shows who owns it. If it was not you - reset your password right away and contact support.
If you lost the key but remember your password
Issue a new key: «Settings → Security → Recovery Key». The same place shows whether you have a key and when it was issued. Enter your password and PIN code and click «Issue a new recovery key» - the same window as for the first key opens. The previous key stops working the moment the new one is shown to you.
After every key issue you receive an email: when, from where and from which device. The key itself is never in the email. If it was not you - change your password right away and contact support.
30 days after a key is issued you get one reminder: check that the key is kept in a safe place. If you are not sure, issue a new one.
If you forgot your password
- On the sign-in page click «Forgot password?» and follow the link from the email. The link is valid for 1 hour and allows 5 attempts.
- Choose «I have a recovery key» and enter the key, your PIN code and a new password. Your data will be preserved, and the key keeps working.
- If you have no key, choose «I do not have a recovery key» and confirm that you understand the consequences: you get your account back, but your personal data will be lost. After signing in you will receive a new key.
A PIN code cannot be recovered - neither with the key nor without it: it is required at every sign-in. Keep it as safe as the recovery key.
Making it yours: settings
Your personal area opens from the menu in the top right corner. Settings holds the account parameters; right after registration it is worth looking into the Toast notifications block there (the «Parameters» tab).
Toast notifications are the cards that pop up in the top right after an action: «Saved», «Could not publish», «Check the fields». Three things can be configured:
| Parameter | Default | What it means |
|---|---|---|
| Notification duration | 5 seconds | how long an ordinary card stays: success, info, warning |
| Error notification duration | 0 | separately for errors; 0 = do not hide automatically, the card stays until it is closed with the cross |
| Pause on hover | on | while the cursor is over the card the countdown stops; move it away and it continues from the same point |
Allowed values are 0 or 2 to 60 seconds; one and fractional values are not accepted. Errors are deliberately not hidden by default: a single setting for everything would mean important error messages disappearing in three seconds.
New values take effect immediately after «Save», with no need to sign in again - and the save confirmation itself is already shown with the new duration, which doubles as a check that you got what you wanted. Other tabs that are already open pick the setting up when they next refresh.
The thin bar at the bottom of a card shows how much time is left. If «do not hide» is chosen there is no bar at all - otherwise it would run to the end and suggest the card is about to disappear.
These parameters have nothing to do with emails and in-system notifications - those are configured separately, under Notifications.
What's next
Your account is ready. Choose your scenario:
- Want to order work → the «I am a Customer» section
- Want to do work → the «I am an Executor» section
- Need teamwork on a large task → the «Teamwork» section
I am a Customer
This section walks you through the whole customer journey: from creating a task to accepting the work and closing it. If terms are unfamiliar, see «General concepts» and «Terminology».
The whole path fits into a few steps:
- Create a task in the wizard
- Refine milestones and budget in the draft
- Publish the task
- Review proposals and select executors
- Start the task
- Accept work milestone by milestone
- Close the task and rate the other side
All customer actions are in the I'm a Customer menu section.
Step 1. Create a task in the wizard
Open I'm a Customer → New Task - you will land in the Services Catalog. Pick a category, then a service in it, and press Create Task: the wizard opens with the category and the service already filled in.
The wizard has eight steps. You can move between them freely with Previous and Next - nothing is lost while the window is open. The Next button becomes active only when every required field of the current step is filled in correctly.
[скриншот: customer_wizard_step1]
Step 1 - Choose Service. Category and service. Once a service is selected, its statistics appear: how many tasks were completed, how many are in progress, the average rating and the average duration - useful for estimating budget and dates.
Step 2 - Task Creation Fee. Shows which token and how much the publication will cost, what your balance is and whether it is enough. The fee is charged only when the task is published - nothing is charged while it stays a draft. If your balance is short, the wizard warns you but still lets you create the draft - you can top up later, before publishing.
Step 3 - Work mode. Choice between Solo and Team mode (see below in this step). For team mode you also set how many work stages to create right away, whether a Team Lead is required, and whether to encrypt the task chat (a paid option, its price is shown next to it). The minimum number of work stages is 2; the maximum depends on your subscription tier.
Step 4 - Task Details. Title (3 to 255 characters) and a detailed description (20 to 10,000 characters). You can also attach files here: up to 1 MB each in the wizard, formats PDF, DOC, DOCX, TXT, JPG, PNG, GIF, ZIP, RAR.
If your files are larger, attach them later. The 1 MB limit applies only inside the creation wizard. To an existing draft, to milestones and to the task chat you can attach files up to 10 MB. So mockups and bulky specifications are not a problem: create the draft first, then add the files to it.
Password-protected archives are not accepted. The reason is simple: the antivirus cannot look inside an encrypted archive, so the platform cannot vouch for its contents. Such a file is rejected at upload. If you need to send an archive, upload it without a password.
Step 5 - Budget & Timeline. The payment token the work will be paid in, the budget amount and three dates:
- accept proposals until - when applications stop being accepted;
- work start date - when the executor should begin;
- deadline - when everything must be ready.
Dates are picked in a calendar together with time and follow each other: pick the proposals date and the start date shifts after it, pick the start and the deadline follows. Any of them can be adjusted manually.
Step 6 - Milestones preview. The wizard shows which milestones will be created. They are not edited here - that is done later in the draft (see Step 2).
Step 7 - Review. A summary: service, mode, budget, dates, files, encryption. The last chance to go back and change something.
Step 8 - Creating the draft. The wizard saves the task, registers the fee and uploads the files one after another. Files are scanned by antivirus before upload - an infected file is rejected and the wizard tells you so. When finished you see "Draft successfully saved".
Cancelling and closing. If you have already entered something, the wizard asks for confirmation before closing - you cannot lose your input by accident.
The created task is a draft: only you can see it, executors can't yet, and you can change anything in it. Drafts are always available under I'm a Customer → Drafts.
Solo or Team mode
- Solo - one executor does the whole task. The wizard immediately creates two milestones: "Project Start" (no budget) and "Project Completion", which carries the whole budget. The simplest option for small tasks.
- Team Mode - several executors work on the task. The wizard creates "Project Start", "Project Completion" and, between them, as many work stages as you specified (within your tier limit). One stage is performed by exactly one executor, so the number of work stages defines the size of the team.
The service milestones "Project Start" and "Project Completion"
The wizard always creates these two, in every mode, and they work differently from work milestones:
- nobody performs them - they are points on the schedule, not work;
- no proposals are submitted for them - an executor will not see them among the milestones open for proposals and cannot apply;
- "Project Start" has no budget and no acceptance either - there is nothing to accept;
- "Project Completion" is closed by the system automatically when you close the task and leave the ratings.
What they are for: "Project Start" marks the starting point of the schedule and "Project Completion" the final point that the task closing is tied to. They do not count in the readiness checks or in "how many work milestones" there are.
In Solo this is most noticeable: formally there are two milestones, but the work is only in the second one. The whole task budget sits on "Project Completion", and that is what you accept.
If in doubt - start with Solo. Details of teamwork are in the «Teamwork» section.
Your tier limits. Your subscription defines three things: how many executors may work on one task, how many milestones a task may have, and whether a Team Lead is available. The wizard shows all three on step 3: next to the number of executors you see your tier and a link to the subscriptions page, and the work stages field shows its limit as a tooltip ("From 2 to N"). If you enter more than allowed, the value is reduced to your tier maximum.
On the starter tier only one executor per task is allowed - team mode is then unavailable, and so is the Team Lead (it is unlocked separately, not on every tier). Upgrading the tier raises the limits.
Team Lead (optional). The Team Lead is your trusted deputy: you decide what to entrust to them, from nothing at all to recruiting and milestone acceptance. They occupy a milestone of their own and are paid out of its budget.
Enabling "Team Lead required" also sets two more things:
- who accepts the proposals - you or the Team Lead. If the Team Lead does, recruiting runs in two phases: only their milestone is open at first, the rest open after they are appointed. If you do, there are no phases and all milestones are open at once;
- the Team Lead selection deadline - a separate date, necessarily earlier than the proposals deadline. The system suggests one, you can change it.
Details are in «Teamwork».
Faster: create a task from a template
If you post similar tasks, do not build the milestones from scratch every time. A template keeps the structure of a task - milestones, budget shares, durations, acceptance conditions - and turns into a ready draft in a few fields: «I'm a Customer» → «Task Templates» → «Create Task». A template can be made from any of your tasks with «Save as Template» or built from scratch.
A template only fills in a draft: publication, the fee and the reservation work as usual. The full guide is in «Task Templates».
Work that repeats: a recurring task
Maintenance, support, bookkeeping - work you should not have to set up again each time. In the task creation wizard turn on the Regular task switch (step 3, solo mode only) and set the schedule at step 5 (for example, the 5th of every month) and the approval window. You can also set the schedule later, on the draft. The platform creates each next period itself, reserves money only for it and pays after your acceptance. The full guide is in «Recurring Tasks».
Step 2. Refine milestones and budget in the draft
The wizard created the skeleton, but the real work on the task structure happens in the draft: I'm a Customer → Drafts → open the task.
Milestones
A milestone (subtask) is a meaningful part of the work with its own result, which can be accepted and paid for separately. In a draft, milestones can be added, removed and edited freely.
For each milestone set:
- a title and a description of what must be done;
- the order (milestones go sequentially);
- start and end dates (the system fills them in automatically - see below);
- the milestone price.
[скриншот: customer_milestones]
Important. The set of milestones can be changed freely only while the task is a draft. After publication it is fixed (see Step 3). So plan the breakdown in advance.
A simple task may consist of a single work milestone - that's fine.
Dates, order and dependencies
Every milestone has a start date and an end date. What you can and cannot do with those dates is governed by two different mechanisms - easy to mix up:
- Order - the milestone's number in the list. It sets the default sequence and how milestones are displayed.
- Dependencies - which milestones this one actually depends on. Set manually, there can be several.
The date rule is always the same: a milestone cannot start before the one it depends on has finished. What counts as "the one it depends on" is decided like this:
| What the milestone has | How dates are checked |
|---|---|
| dependencies set | it must start after the latest of them ends. With all other milestones it may overlap freely |
| no dependencies set | adjacency applies: it must not start before the previous milestone in order ends |
| dependencies explicitly cleared | no date constraint at all - it can run in parallel with anything |
In other words, "strictly in order" is the default behaviour, not a hard rule. As soon as you set dependencies, the position in the list stops dictating dates and independent milestones happily run in parallel. That is exactly how team tasks are built: three executors work at the same time and the final milestone depends on all three.
If you set dates that break this rule, the system will refuse them and show which milestone the conflict is with.
So you don't have to fill dates by hand, the system suggests them automatically: a new milestone starts on the next working day after the previous one ends, at 09:00, and finishes at 18:00 (weekends are skipped). The suggested dates can be changed - within the same rule.
Budget
A task has several related budget concepts - they are explained in detail in «Terminology». For practice, the following matters:
- Preliminary budget - the amount you entered in the wizard. It is your first rough estimate, a "ballpark" reference; it does not participate in further calculations.
- Declared budget - the amount that will be reserved on publication. The system calculates it itself as the sum of all milestone budgets. Change a milestone price and the declared budget changes with it.
In team mode work stages are created without a budget: you have to distribute it across the stages manually, otherwise the task will not pass the readiness check for publication.
Later, as you accept executors' proposals, the working (accepted) budget forms - the actual cost of the task. But that happens after publication.
The executor's security deposit. Next to the milestone budget there is a "Require an executor's deposit" checkbox and an amount field. It is your right, not an obligation: turn it on where a failed milestone would cost you dearly. The amount is stated in the task's currency and cannot exceed the milestone budget.
The deposit is frozen on the executor's balance the moment you accept their proposal, and returned to them when the milestone is accepted. You never receive it under any circumstances, except by an arbiter's decision in a dispute. Keep the flip side in mind too: the higher the deposit, the fewer executors will respond. Details are in «Money and the secure deal».
[скриншот: customer_budget]
Step 3. Publish the task
Publication moves the task from a draft into the Open Tasks section and makes it visible to executors. At this moment the system performs several checks and operations:
- Checks that there are enough funds. Your balance must have at least the declared budget free. If funds are short - publication won't happen, and a "Not enough funds" message appears. You can top up under Finances (see «Getting started»).
- Charges the fee for creating the task (the pending one from Step 1 of the wizard - currently 50 KNL).
- Reserves the declared budget - freezes the amount for this task (escrow). The money stays yours, but can no longer be spent on anything else.
[скриншот: customer_publish]
After publication the set of milestones is fixed. The task description can still be refined while it is open, but you can't change the set of milestones on the fly. If you need to rework the structure, the task must be unpublished - and then the already submitted proposals become invalid. Do this only when truly necessary.
The task readiness checklist
So that you never have to guess why the publish button is inactive, the task page has a Checklist tab. It lists the conditions the task must meet to move on, plus the share already met. The rule is simple: you will not be refused for a reason that was not in the list.
The list depends on the particular task: a team task has conditions a solo one does not, a task with a Team Lead has conditions about the Team Lead. Irrelevant conditions are not greyed out - they are simply absent from the list.
Every line has one of four kinds:
| Kind | What it means |
|---|---|
| Green tick | The condition is met |
| Red cross | Not met; while any of these remain, you cannot move on |
| «Nothing to check» | The check does not apply - for example the antivirus check when no files are attached |
| «Optional» | Desirable, but it does not block publication |
Only mandatory conditions that were actually checked count towards the share completed.
A line does not merely report failure, it explains what exactly is missing: not «not enough funds», but how much is on the balance, how much is needed and how much is short, with links to the wallet and to topping up; not «some milestones have no budget», but those milestones by name; not «the description is short», but how many characters there are out of how many are needed.
To publish a draft, the following are checked: the length of the description; that the dates are still valid (proposal acceptance not in the past, the start no earlier than that, the deadline no earlier than the start); that working milestones exist (a team task needs at least two); that every attached file has passed the antivirus check; that the budget is set and a payment token chosen; that every working milestone has a budget, including the Team Lead's milestone; that free funds are enough for the reservation. If the task requires a Team Lead - also the deadline for selecting them: set, in the future and earlier than the proposal deadline.
To start the task, the following are checked: working milestones exist and at least one is signed by both sides; all files have passed the antivirus check; the sum of milestone budgets equals the accepted budget; executors are assigned (for a team task - at least two, with a separate line for every working milestone); for a task with a Team Lead - that the Team Lead is appointed and has accepted the appointment; the working chat is created; free funds are enough for the re-reservation.
A gap between the working budget and the reservation does not block the start. While the task is open you accept proposals and the working budget changes - that is normal, and the reservation is recreated at the start. So the line shows both amounts as information and offers an Update reserve button to close the difference in advance. What does block you is not having enough free funds for that difference, and that is a separate mandatory condition. While the working budget is still being formed the button is not shown: it is too early to re-reserve.
The list recalculates itself - when the page opens and after actions that could affect it (you saved the details, edited milestones, uploaded a file, accepted a proposal). There is no need to reload the page; while the recalculation runs the block dims and shows a «checking» note.
The checklist is a convenience, not a protection: if the request does reach the server, it checks the same conditions itself and refuses, listing what is unmet in the same words. Tasks whose status has no way forward (paused, completed, canceled) have no checklist at all.
Step 4. Review proposals and select executors
After publication, executors start sending proposals. You see them in the task card (the Proposals tab).
For each proposal you can:
- Accept - the executor is attached to the task (or to a milestone in Team mode), and their reward is added to the working (accepted) budget.
- Reject - the proposal is declined.
[скриншот: customer_proposals]
As you accept proposals, the working budget accumulates. Watch how it compares to the declared one: if the total of accepted proposals turns out larger, more funds will be needed when the task starts (see Step 5).
Dates in proposals
An executor may propose their own dates, different from the milestone's plan dates (see Step 2). When you accept the proposal, those dates become the contract for that milestone - customer and executor lock them in as an agreement.
The dates must still fit the milestone order: a milestone cannot start before all the milestones it depends on are finished (independent milestones may run in parallel). So on acceptance there are two cases:
- The dates overlap an already accepted (contracted) milestone - you cannot accept the proposal. Someone else's contract can't be moved unilaterally: agree on different dates with the executor (they adjust the proposal), or revise the dates of the other milestone.
- The dates only affect milestones that aren't taken yet - the system warns you that the schedule shifts. You adjust the plan dates of those milestones manually; they are not moved automatically.
Editing dates on a published task. After publication the set of milestones, their budgets and dependencies are frozen (to change them you must unpublish the task). However, you can change the plan dates of a milestone that isn't taken yet (not contracted) right in the published task - open the milestone for editing and adjust only its dates. This is intentional, so you can resolve the schedule-shift warning without unpublishing the task (and without losing the proposals already submitted). Dates of a milestone whose proposal is already accepted (contract signed) cannot be changed - that is your agreement with the executor.
Withdrawing an already accepted proposal. While the task has not been started, an accepted proposal can be withdrawn - the task returns to recruitment. The first three withdrawals have no consequences, after that a penalty applies - this protects the executor who was counting on the work. The executor's security deposit is returned to them in full.
After the start, acceptance cannot be withdrawn - the button disappears. The work is already under way, and withdrawal would send the money for delivered work back to you. If an executor drops out during the work, their milestone can only be cancelled (see Step 6); a new executor cannot be taken on that milestone yet.
Step 5. Start the task
When the right executors are chosen, press Start Work - in Solo and in team mode alike this is a separate action. The task moves to the In Progress section. Here the system reconciles the money:
- If the working (accepted) budget equals the declared one - the reservation is unchanged.
- If they differ (no matter which way) - a re-reservation is performed: the old reservation is released and the new, actual amount is frozen. If the balance is short for this - the system will ask you to top up.
[скриншот: customer_start]
If the start button is inactive, open the Checklist tab: it shows exactly which conditions are missing (see «The task readiness checklist» above).
At the start:
- all proposals that were not accepted are rejected automatically;
- the work chats open: in Solo - your chat with the executor, in a team - the general chat plus a separate work chat with each participant. Negotiation chats stay as history - you can no longer write in them after the start.
From this point, executors work milestone by milestone.
Step 6. Accept work milestone by milestone
When a milestone is ready, its acceptance begins. It can be put up for acceptance by the executor of this milestone, by submitting the finished work, or by you, if you can see the work is effectively done but the executor did not press the button. An executor of another team milestone cannot submit someone else's milestone. That is only a record of delivery - the acceptance decision is always a separate action.
| Action | Executor of this milestone | You (customer) |
|---|---|---|
| Put the milestone up for acceptance | ✔ | ✔ |
| Accept the milestone (and pay) | - | ✔ |
| Send back for revision | - | ✔ |
| Open a dispute | ✔ | ✔ |
| Cancel the milestone | - | ✔ until the work is submitted |
If you delegated a function to the Team Lead (acceptance, revision or dispute), only they see and press that button - you will not have it. Otherwise two people would be deciding. You always accept the Team Lead's own milestone yourself.
The buttons on a milestone card are shown only to those who may press them right now.
Once a milestone is up for acceptance, three options are available:
- Accept - the work is counted, the milestone is closed. Payment goes to the executor immediately, out of the reserved funds; there is no need to wait for the whole task to finish. The action is irreversible - acceptance cannot be undone and the money cannot be taken back.
- Send back for revision - if something is off. Always attach a comment on exactly what needs fixing. The executor will rework it and put the milestone up for acceptance again.
- Open a dispute - a last resort. Use it if the work is effectively not done or has gross errors, and the milestone has been sent back for revision many times with no result. A detailed comment is required.
A submitted milestone cannot be cancelled. A milestone can be cancelled (or marked not fulfilled) while the work has not been submitted - in progress or after it was sent back for revision. Its budget returns to you when the task closes. Once the work is up for acceptance there are three decisions: accept, send back for revision, open a dispute - otherwise delivered work would come to you for free.
A dispute is available to both sides. The executor can open one too - if they believe the work is not being accepted for no clear reason or is returned for revision endlessly. This is deliberate: acceptance must not rest on the customer's goodwill alone.
How a dispute is resolved
A dispute has two stages. Throughout, the money for the milestone stays frozen in the reservation - neither side can take it.
| Stage | Who decides | What happens |
|---|---|---|
| 1. Negotiation | the sides themselves | you propose a payment amount for the milestone (from zero to the full price), the executor accepts or declines. Acceptance closes the dispute |
| 2. Arbitration | a platform staff member | available no earlier than 5 days after the dispute was opened. Either side can escalate; the arbiter sees the milestone chat, files and history. Their decision is final |
Possible outcomes: full payment, partial payment (for what was actually done), or no payment. Any unpaid remainder returns to you when the task is closed.
There is no automatic resolution by timeout - otherwise staying silent would be enough to win. A task cannot be closed while a dispute is open.
Stage: the dispute resolution procedure is under development. For now a dispute records the disagreement and freezes the milestone's money.
[скриншот: customer_accept_milestone]
Always try a revision with a clear comment first - most issues are resolved that way. A dispute is for situations where revisions don't help.
How many times a milestone can be sent back
There is no hard limit, but the system does not allow an endless "submit - return" loop:
| Return | What happens |
|---|---|
| 1-2 | the ordinary working process |
| 3 | a hint to both sides: it may be time to open a dispute |
| 5 | the milestone automatically goes to dispute |
The point is that after a fifth return the loop is clearly not converging, and the question should be settled by a review rather than another iteration.
If you don't respond to a submitted milestone
Frozen money must not hang indefinitely, so:
| Milestone waiting for acceptance | What happens |
|---|---|
| 7 days | you get a reminder |
| 14 days | the milestone automatically goes to dispute |
There is no automatic acceptance or automatic payout by timeout - money never moves without your decision. But you also cannot keep the executor waiting forever.
Stage: the revision ladder and the acceptance timeout are under development. Until they ship, there is no limit on the number of revisions.
All discussions about a milestone are conveniently held in the task chat.
Step 7. Close the task and rate the other side
When all milestones are accepted, cancelled or marked not fulfilled, the project closing thread opens in the work chat with the Complete project button. You rate every participant - the task cannot be closed without that. After that it is completed and moves to the Completed section. While a dispute is open on any milestone, the task cannot be closed.
The money has already been paid by then. Payment is per milestone: the amount for each one goes to the executor the moment it is accepted, it does not accumulate until the task closes. At closing only the unused remainder of the reservation returns to you - for milestones that were not accepted (cancelled, not fulfilled) or the difference between the reservation and the actual payouts.
Rating is mutual. After completion you rate the executor, and the executor rates you. This builds the reputation of both sides on the platform.
How the timing works. You must rate the participants when closing the task - it cannot be closed otherwise. For a side that did not leave their rating, the system puts a provisional maximum in their place so that closing is not blocked.
| Question | Answer |
|---|---|
| When the system rating appears | at the moment the task is closed |
| How long you have to leave yours | 7 calendar days from the closing |
| Does the system rating affect the average | no, it is not counted in the average |
| What happens after 7 days | the system rating is fixed permanently |
So silence does not "gift" the other side an excellent rating: such a rating is marked as system-generated and stays out of the average. But your opinion will not be in their reputation either - if it matters to you, use the week.
[скриншот: customer_close]
If something goes wrong
- Not enough funds at publication or start - top up under Finances, then repeat the action.
- Need to change the set of milestones after publication - unpublish the task (note: submitted proposals become invalid).
- A milestone is done poorly and revisions don't help - send it back for revision with a comment; if there's no result after repeated attempts, open a dispute (see Step 6).
- You changed your mind about an accepted proposal - before the start it can be withdrawn (after three withdrawals - with a penalty); after the start - no.
- An executor disappeared during the work - cancel their milestone while the work has not been submitted; its budget returns when the task closes. Replacing the executor on a milestone is not available yet.
- You no longer need the task - it can be canceled; canceled tasks go to the Archive section. See below.
- Nobody responded before the proposals deadline - the task stays open, the money stays reserved and the fee is not refunded. Nothing happens automatically: new proposals can no longer be submitted after that date, so extend the proposals deadline or unpublish the task and revise the terms - usually it comes down to the budget or the dates.
- You accepted proposals but the task does not start - starting is a separate action (in Solo and in a team alike), no work begins before it. Check the readiness checklist: it shows what is missing (budget not fully distributed, not every milestone has an executor, not enough funds for re-reservation).
- The wizard stopped at step 8 - the steps run one after another: first the draft is saved, then the fee is registered, then the files are uploaded. If it failed on the files, the draft already exists and is in the Drafts section - you can add the files to it manually, no need to go through the wizard again.
Cancelling a task
The consequences of cancelling depend on whether anyone has already taken on obligations. Cancelling a draft and breaking off work in progress are different things, and the system treats them differently:
| When you cancel | What happens to the money | Counted as a cancellation |
|---|---|---|
| Draft | nothing is reserved, no fee has been charged | no |
| Open, no proposals accepted | the reservation returns in full | no |
| Open, proposals accepted | the reservation returns, accepted proposals are annulled | yes |
| In progress | accepted milestones stay paid, unfinished ones are cancelled, the remainder of the reservation returns | yes |
The task creation fee is not refunded in any case except cancelling a draft: it is charged for the publication, which already happened.
What "counted as a cancellation" means. The first three such cancellations pass without consequences - everyone makes mistakes. After that, escalating penalties apply.
Separately, your profile shows the number and share of cancelled tasks. This indicator is not mixed into the average rating: an executor needs to see "cancels every third task" as a plain figure, not as a slightly lower score.
Stage: cancelling a task from the interface is under development.
Related sections: «I am an Executor» · «Teamwork» · «Money and the secure deal»
Task Templates
A task template is a blueprint that turns into a task draft in a few fields. A template remembers everything you usually put together by hand: milestones, their shares of the budget, durations, order, acceptance conditions and work requirements. Only what you made fields to fill changes from task to task: the project name, the number of pages, whether extra work is needed.
Templates pay off when you post similar tasks: landing pages, translations, audits, monthly support. Build it once - and every new task takes a minute.
A template only fills in a draft. Publication, the creation fee and the budget reservation happen as usual - when you publish the draft. The template itself does not touch money.
Where templates live
Menu «I'm a Customer» → «Task Templates». The «From Template» button on the Drafts page and the «Or create from a template» link on the first step of the task wizard lead there too.
The page has two tabs:
- «My Templates» - your personal templates. Only you see them. Next to the tab name: how many templates you have and how many your tier allows.
- «Platform Templates» - ready samples from the platform. Each sample is shown in your interface language; if this sample has no translation into your language, in English. A sample cannot be edited, but you can copy it and adjust the copy.
The card details line has a short template code like #1a2b3c4d - it tells apart templates with the same name (the full code is in the tooltip).
A platform administrator (with the right to manage templates) sees the «Manage Platform Templates» tab. It has one card per sample with language labels: green - the variant is published, grey - hidden, «+ language» - no translation yet. Clicking a label opens that language variant; «+ language» creates a copy of the current variant to translate - it stays hidden until published. In the sample editor the same languages are at the top, you can switch between them; «Delete this language variant» removes one language only. Each language keeps its own structure (stages, shares, terms) - when you change it in one language, adjust the others too.
Each template card has buttons:
| Button | What it does |
|---|---|
| Create Task | Opens the window that creates a draft from the template |
| Pencil | Opens the editor (your own templates only) |
| Copy | For a sample - a copy into «My Templates»; for your own - a duplicate |
| Download | Exports the template to a file |
| Bin | Deletes the template (your own only) |
Three ways to get a template
- From your task. On the page of any of your tasks - in any status, including completed - press «Save as Template». The best template comes from a task that has already gone well.
- From scratch. The «New Template» button on the templates page.
- From a sample or a file. Copy a platform sample or load a file with the «Import» button.
In the first case the system moves the task structure into the template by itself: milestone amounts become shares of the budget, dates become days from the work start, texts are kept as they are. All that is left is to mark what will change (see «Fields to fill») and save.
The template editor
The editor opens in a window with five tabs. The bottom of the window always shows the sum of budget shares: green when it is exactly 100%, red when it is not. A template can only be saved at 100%.
«General» tab
- Template name - how the template is called in the list.
- Short description - what the template is for; shown on the card.
«Task» tab
Everything about the task as a whole:
- Service - the service type from the catalogue. You can leave «Choose when creating a task» and pick it each time.
- Payment token - what the budget is in. «Token of the service» takes the token set for the chosen service.
- Days to accept proposals - from 1 to 30. The creation window uses it to suggest the proposals deadline.
- Execution mode - Solo (one executor) or Team.
- Encrypted workspace chat - as in the wizard.
- The task needs a Team Lead (Team mode only) - the Team Lead share of the budget and the powers delegated to them. More about the Team Lead - in «Teamwork».
- Task title, description and work requirements - the texts of the future task. The title needs at least 3 characters, the description at least 20.
«Regular task» tab
The «Regular task» checkbox is for work that repeats on a schedule (website maintenance, a monthly report). When it is on, the tab title shows an icon, and below you set the rule: when to repeat (a day of the month, a day of the week or equal intervals), the payout time, the approval window before the payout and auto-acceptance. Only a Solo template with exactly one stage that is not turned off by a field can be regular: that stage describes one period. The first payout date and the time zone are not set in the template - they are chosen when creating a task. How regular tasks work - in «Regular tasks».
«Fields to Fill» tab
This lists what you will enter every time you create a task. A field has:
- key - a short name in Latin letters, digits and «_» (for example,
site_name); - label - what the customer sees in the form («Site name»);
- type:
| Type | What is entered | Extra |
|---|---|---|
| Text | A line of text | Max length (up to 1000 characters) |
| Number | A number | Minimum and maximum |
| Yes / No | A checkbox | Can turn milestones on and off (see below) |
| Choice | One option from a list | Options one per line, up to 20 |
- default value - filled into the form automatically;
- required - without it the draft is not created.
A template can have up to 20 fields.
How a field gets into the text. In any template text - task title and
description, requirements, milestone title and description, checklist items -
a field is written as {{key}}. For example: «Landing page for {{site_name}}».
When a task is created, what you entered takes its place.
The fastest way is not to type keys at all. Select a word or phrase in the
text and press the braces button next to the field. The selection becomes a
field at once: {{key}} appears in the text, a new field appears on the
«Fields to Fill» tab, and the selected text becomes its default value.
If you change a field key, every {{key}} in the template texts is updated
automatically.
«Milestones» tab
Template milestones are the work milestones of the future task. The «Project Start» and «Project Completion» points are added automatically and are not part of the template.
For a milestone you set:
- key - a short name (dependencies link milestones by it);
- title and description - fields can be used here too;
- budget share, % - what part of the total budget the milestone gets;
- starts on day - how many days after the work start the milestone begins (0 - right away);
- duration, days - how long the milestone lasts;
- acceptance, days - how many days you have to review the delivered milestone; empty - the platform default;
- deposit share, % - if the executor must put down a deposit: a share of the milestone budget. When a task is created, the share turns into an amount;
- include if - the milestone is included only when the chosen «Yes / No» checkbox is ticked. «Always» - the milestone is always there;
- acceptance checklist - one item per line; the conditions you will accept the work by.
Arrows change the order of milestones. A template can have up to 50 milestones; in Team mode at least two.
Budget shares, together with the Team Lead share, must add up to exactly 100%. The template is written «for all cases»: when a task is created, the shares of turned-off milestones are spread among the remaining ones by themselves.
«Dependencies» tab
A dependency says: «this milestone starts after that one». For each you set:
- milestone and starts after - which milestone follows which;
- type - usually «Finish to start»;
- lag, days - a pause between them.
The date rule is the same for every type: a milestone cannot start before the one it follows has finished (plus the lag). If the template breaks this, the editor tells you from which day the milestone must start.
Milestones without dependencies start after the project start and can run in parallel.
Saving and errors
Press «Save Template». If something is wrong, the window stays open and lists all problems at once at the top. Common ones:
| Message | What to do |
|---|---|
| Budget shares must add up to 100% | Fix the milestone (and Team Lead) shares |
| Milestone «…» must start on day N or later | Move «starts on day» or remove the dependency |
| Unknown parameters in text: … | Add a field with that key or fix {{…}} in the text |
| Milestone dependencies contain a cycle | Remove the dependency that goes round in a circle |
| A team task needs at least two work stages | Add a milestone or switch to Solo |
| You have reached the template limit of your subscription | Delete an unused template or upgrade |
Versions. Every save with changes creates a new version of the template. Old versions are kept, and you can create a task from them too. Tasks already created from a template do not change when it is edited - they are copies.
Creating a task from a template
- Press «Create Task» on the template card.
- Fill in the template fields, the total budget, the proposals deadline and the work start date. If the template has several versions, you can choose one at the top.
- On the right is a preview: the final title, milestones with amounts and dates, the task completion date and warnings.
- Press «Create Draft». A normal draft opens - from here everything is as after the wizard: you can change anything and publish.
How amounts and dates are calculated:
- Budget is split by the shares of the included milestones. Example: a budget of 1,000 with shares 30 / 50 / 20 gives 300 / 500 / 200. If the third milestone is turned off by a checkbox, its 20% is spread between the first two proportionally: 375 / 625. The rounding remainder goes to the last milestone.
- Dates. The work start day is the «Project Start» point. A milestone on «day 0» starts the next day, a milestone on «day 7» - seven days after that. The task completion date is the day after the last milestone ends.
- Proposals deadline - no earlier than tomorrow, no later than in 30 days, and always before the work start date.
If the service or token from the template is not available now, the window shows a field to choose others. A service can only be chosen from the same catalogue category as in the template.
Pressing «Create Draft» again does not create a second draft - the one already created opens.
The page of a task created from a template shows, next to its number, which template and version it was created from.
A regular template. Its card is marked «Regular task», and the creation window has a «Schedule of the regular task» block under the dates. The rule is filled in from the template - you can adjust it. Choose the first payout date and check the time zone (your browser's zone by default). The three nearest «approval deadline - payout» pairs are shown below; while the schedule is not accepted, it says what is missing and the draft is not created. The whole budget becomes the amount of one period, the task deadline - the first payout date. You get the same regular draft as from the wizard. A ready sample - «Monthly website maintenance» among the platform templates.
«Save as Template» on a regular task takes its rule and one stage; periods already paid do not get into the template.
Example: a «Landing page» template from scratch
- «New Template», «General» tab: name «Landing page».
- «Task» tab: Solo mode, title «Landing page for Company», a task description.
Select «Company» and press the braces button - the title becomes «Landing
page for {{company}}». On the fields tab rename the key to
site_nameand the label to «Site name». - «Fields to Fill» tab: add a field «Needs a content management system» of type «Yes / No».
- «Milestones» tab: «Design» - share 30, day 0, 7 days; «Build» - share 50, day 7, 10 days; «Content management» - share 20, day 17, 5 days, «include if» - «Needs a content management system».
- «Dependencies» tab: «Build» after «Design», «Content management» after «Build».
- The bottom shows 100% in green. «Save Template».
Now a new landing page is «Create Task», the site name, a budget, two dates and, if needed, one checkbox.
Template files
- Export - the download button on the card: the template is exported to a file (the current version).
- Import - the «Import» button at the top of the page, a file up to 256 KB. If the file refers to a service, token or power that does not exist here, they are skipped with a warning, and you choose them when creating a task. Errors in the template structure make the import fail.
This is how you share a template with a colleague: they load the file.
Good to know
- Limit. The number of personal templates is limited by your subscription (20 on the free tier, unlimited on the top one). A new version of an existing template does not count. When the tier is lowered, templates are not deleted - only creating new ones is blocked.
- Deleting a template does not affect tasks created from it. Their page keeps the template name, without a link.
- Attached files are not part of a template - add them to the draft.
- A template does not create tasks on a schedule and does not publish them - you create and publish each task yourself.
- Templates can be turned off by the administration - then the menu item, the page and the buttons disappear; tasks already created are not affected.
Recurring Tasks
A recurring task is work that repeats on a schedule: server maintenance, website support, bookkeeping, social media. You agree on the terms once, and from then on the platform creates each next period, reserves the money for it and pays the executor after you accept the report. This goes on until one of the sides ends the series.
One recurring task is a series of periods. Each period has one milestone: the executor submits a report, the customer accepts it, the executor gets paid.
For now recurring tasks work in "Solo" mode (a single executor) with the same amount for every period.
Three dates of every period
- Period start - the executor works from this moment. The next period starts exactly on the payout date of the previous one: periods follow each other without gaps.
- Approval deadline - by this moment the customer must accept the report, return it for rework or open a dispute. The window is set in the terms, for example "3 days before the payout".
- Payout date - the main date. On this day the executor receives the money for the accepted period.
All dates are counted in the time zone of the schedule, which the customer chooses when creating it. "The 5th at 12:00" always stays 12:00 local time, including the switch to daylight saving time.
How a customer creates a recurring task
- In the task creation wizard, at step 3 choose Solo Mode and turn on the Regular task switch. It is not offered in team mode.
- Step 5 gets two tabs: "Budget & Timeline" and "Schedule". On the first one the budget is the amount of one period, and the task deadline is not asked separately: it becomes the first payout. The "Next" button on the first tab opens the second one.
- Fill in the schedule on the second tab:
| Field | Meaning |
|---|---|
| Repeat | "On a day of the month", "On a day of the week" or "At regular intervals" |
| Day of the month and "Every" | A day from 1 to 28 or "Last day"; every month, 2 months, quarter, 6 months or year |
| Day of the week and "Every" | A weekday; every week, 2 weeks or 4 weeks |
| At regular intervals | Every N days or N hours, for example every 240 hours. The shortest period is 1 day |
| Payout time | The time of day when the payout happens |
| First payout date | The day of the first payout; it must fit the chosen rule |
| Time zone | Chosen from a list; your browser's zone by default |
| Approval window before the payout | How much time you have to decide before the payout; it must be shorter than the period |
| Accept the report automatically... | What to do if you do not respond in time (see below) |
The days 29, 30 and 31 are not offered: in short months such a date would be lost. For the end of a month use "Last day".
While the schedule cannot be accepted yet, the text under the table says what is missing ("Required to continue: first payout date"), and empty required fields are highlighted in red.
The bottom of the window shows the three nearest pairs of dates - "approval deadline" and "payout". Check that the rule says what you meant. The "Save schedule" button becomes available when all checks pass. If something is wrong, the reason appears under the table, for example "The approval window must be shorter than the period".
You can also set the schedule later, on the draft page: the "Regular task" card has the "Make this task regular" button (the task must have exactly one work stage). 4. While the task is a draft you can change the schedule with "Change schedule" or remove it with "Remove schedule". After publishing, the schedule changes only with the consent of both sides (see "Changing the terms"). 5. Publish the task as usual. The task creation fee is charged once for the whole series.
The publishing and start checklist also checks the schedule: the approval deadline of the first period must be later than the proposal deadline and must not have passed by the time the task starts.
What the executor sees before proposing
The task page has the "How this regular task works" block. It shows:
- the schedule in words and the time zone;
- the amount per period and the approval window;
- what happens if the customer does not respond (automatic acceptance or a dispute);
- the three nearest dates;
- the main rules: funds are reserved for one period, the series pauses on an unclosed period, leaving with a notice, terms change by consent.
Make a proposal when these terms suit you: once the proposal is accepted they become part of the agreement.
How the series runs
- Accepting the proposal and starting. The amount of the first period is reserved.
- During the period the executor works and submits a report with the usual milestone submit button. The customer accepts the report before the approval deadline.
- An accepted report waits for the payout date. The money goes to the executor on that day, not at the moment of acceptance.
- On the payout date the platform pays the period and immediately creates the next one with its reserve.
All periods are listed in the "Periods" table of the card: number, dates and state ("Period in progress", "Waiting for the customer decision", "Accepted, waiting for the payout date", "Paid out", "In dispute", "Not paid").
Money
- Funds are reserved one period ahead, not for the whole series.
- The reserve for the next period is created at the same moment the previous one is paid. If free funds are not enough, the series pauses (see below).
- The platform fee is the usual distribution of each payout; there is no separate fee per period.
If the customer does not respond in time
The customer decides this in the schedule with the checkbox "Accept the report automatically if I do not respond before the approval deadline":
- Checkbox on - the report is accepted automatically at the approval deadline and the money goes out on the payout date. Such a period is marked "accepted automatically".
- Checkbox off (default) - when the deadline passes without a decision, a dispute is opened automatically and the usual dispute process takes over.
Automatic acceptance is only your consent given in advance. Without the checkbox the platform never pays out on a timer.
Pausing the series
The series pauses in two cases, and both sides get a notification.
The previous period is not closed by the next payout date. The executor has not submitted the report, a dispute is open or the customer has not accepted. The new period is not created and no money is reserved for it. The schedule is not shifted: dates that no longer leave time for approval by the moment the series continues are skipped and not paid. If the executor submits the report later, the customer gets a full approval window from the moment of submission; after acceptance the period is paid at once and the series continues.
Free funds are not enough to reserve the next period. The customer gets 3 days to top up the balance. If the funds appear, the series continues by itself. If not, the series ends without a penalty for the executor.
Ending the series
- The customer presses "End the series". The current period is completed and paid, the next one is not created, the rest of the reserve is returned.
- The executor presses "Leave the series". Leaving needs a notice of one period: the series continues until the end of that term and then ends. There is no penalty for a correct exit.
When the series is over, the task stays "in progress" until the customer closes it with the usual Complete project action (ratings are given there). Mutual ratings are given once for the whole series, not after every period.
Changing the terms
The schedule, the approval window and automatic acceptance can be changed during the series, but only with the consent of both sides and from the next period.
- Either side presses "Propose new terms", fills in the form and sends it.
- The other side gets a notification, and the series card shows the "New terms are proposed" block with the "Agree" and "Decline" buttons.
- The proposer can withdraw the proposal. Only one proposal is open at a time.
- A period that is already created and reserved does not change.
The amount of a period cannot be changed during the series: it is tied to the accepted proposal and the reserve. If the amount must change, end the series and create a new one.
Frequently asked questions
Can an already published task be made recurring? No, the schedule is set on a draft.
Can I choose the 31st? No. Choose "Last day" - then the date is never lost in short months.
What if a period drags on and the payout date is missed? The series pauses. When the period closes it is paid, and the next one appears by the schedule; dates with no time left are skipped.
What do the notifications cover? Pauses, the end of the series and a proposal of new terms. They arrive in the notifications section and, for some events, by email if it is enabled in the settings.
Why did the money arrive not at the moment of acceptance? For recurring tasks the payout happens on the payout date; this is part of the agreement.
Task Matrix
The Task Matrix shows all your tasks on one board. Every task (or milestone) is a card, cards are laid out in columns by state, and the card's colour tells you what needs your attention. The matrix answers «where do things stand and where should I go»; the actions themselves happen on the task page - clicking a card opens it.
The «Task Matrix» item is in the «I'm a Customer» and «I'm an Executor» menus, in the «Overview» group. It is the same page: from the customer menu it opens on the customer tab, from the executor menu - on the executor tab.
Role tabs
- I'm a Customer - tasks you created.
- I'm an Executor - tasks where you work or have submitted a proposal.
- I'm a Team Lead - tasks where you are the team lead. This tab has no menu item of its own: it appears on the matrix page by itself if you are a team lead in at least one task.
A tab where you have nothing is not shown. If the tab you came to from the menu is empty, you will see a hint on where to start instead of the board.
Tasks or milestones
The switch above the board changes the level:
- Tasks - one card per task. Handy for seeing everything at once.
- Milestones - one card per milestone. Handy for seeing where exactly the work is, what awaits acceptance and where there is a dispute.
The selected level is remembered in your browser.
Above the columns there is a counter row: how many cards are in each column and the money in work (separately for each token).
Columns
Customer, «Tasks» level: Drafts · Open Tasks (recruiting executors) · In work · Closed. A paused task stays in «In work» with a «Paused» label, a canceled one goes to «Closed», in grey.
Executor, «Tasks» level:
- My Proposals - tasks where you submitted a proposal and no decision has been made yet. A task still recruiting where your proposal was already accepted is also here: until the task starts there is no work yet - the card shows a «Proposal accepted» label.
- In work - tasks where you are in the team and the work is going on.
- Closed - completed and canceled tasks you worked on.
Rejected, withdrawn and expired proposals are not shown on the matrix - they are in «My Proposals».
Team lead, «Tasks» level: Open Tasks · In work · Closed.
The «Milestones» level is the same for all roles: Not started · In work · Awaiting acceptance · Rework · Disputes · Accepted · Not fulfilled.
- «Not started» - milestones of a published task that has not started yet.
- A milestone of a task that was closed while the milestone was never accepted goes to «Not fulfilled».
- An executor sees only their own milestones; the customer and the team lead see all milestones of the task.
- Milestones of drafts and service milestones (task start and completion) are not shown.
Colour - what needs attention
The column already tells you the card's state, so the colour of the left strip shows urgency. The reason is always written next to the colour.
| Colour | When |
|---|---|
| red | the deadline has passed; a dispute is open on the milestone |
| orange | your action is needed: a milestone awaits your acceptance, proposals await your decision, the team lead search is overdue, a milestone was returned to you for rework |
| yellow | 3 days or less left before the deadline |
| none | everything is on track |
If several reasons apply, the strongest one is shown. Within a column, cards needing attention come first, then by the nearest deadline. Closed cards are not coloured.
Who sees acceptance and recruiting highlighted. If the customer delegated milestone acceptance or team recruiting to the team lead, «Awaiting your acceptance» and «Proposals awaiting decision» are highlighted for the team lead, not the customer. Until a team lead is appointed, the customer decides - and sees the highlight. The team lead's own milestone is always accepted by the customer.
Amounts on cards
- Customer and team lead: before the start - the declared task budget, after the start - the working budget (the sum of accepted proposals). For a milestone - its budget.
- Executor: your share. In «Solo» mode - the whole working budget of the task, in a team - the budgets of your milestones, and if you have only submitted a proposal so far - the amount of your proposal.
Closed cards
The «Closed», «Accepted» and «Not fulfilled» columns show only cards from the last 30 days, no more than 20. The link under the column leads to the full list of completed tasks.
What the matrix does not do
- Drag and drop. Moving a card to another column would mean changing its status, which involves money (publishing reserves the budget, starting re-reserves it). All actions are on the task page.
- Auto-refresh. Data is loaded when the page opens; the «Refresh» button reloads it.
- Filters and search - use the task lists for that.
I am an Executor
This section walks you through the executor's path: how to find a task, respond, do the work and get paid. If terms are unfamiliar, see «General concepts» and «Terminology».
The executor's path:
- Find a suitable task
- Study the terms
- Submit a proposal
- Wait for the customer's decision
- Do the work milestone by milestone
- Submit milestones for acceptance
- Get paid
- Leave a rating
To do work, you usually need no funds on your balance - payment comes to you after acceptance. There is one exception: if the customer requires a security deposit on a milestone, its amount must be on your balance at the moment the proposal is accepted (see Step 4). Otherwise funds are only needed when you act as a customer yourself.
All executor actions are in the I'm an Executor menu section.
Step 1. Find a suitable task
Open I'm an Executor → Find Work (or the Marketplace section). Here you'll see the open tasks you can respond to. Use categories and filters to find what suits you.
[скриншот: executor_find_work]
So you don't have to check «just in case»: task subscriptions
Instead of checking the exchange by hand you can subscribe and receive emails about new tasks. There are three levels:
- the whole catalogue - the «Subscribe to all new tasks» button in the services catalogue header;
- a catalogue section (for example «Development») - the bell next to the section, or the «Follow the section» button inside it;
- a specific service type (for example «Python development») - the bell next to the service type.
Two delivery modes:
| Mode | When it arrives | Who can use it |
|---|---|---|
| Daily digest | one email a day with all matching tasks, grouped by section | everyone, including the free tier; this is the default |
| Instant | an email within a few minutes of the task being published | depends on the tier and is limited in number |
The limit is not only about cost: an instant email is valuable because you learn about the task first and can submit a proposal before others. If everything could be subscribed to instantly, the emails would stop being read and the advantage would disappear by itself. A subscription to the whole catalogue always works as a digest - the instant mode is unavailable for it even on the top tier.
How many subscriptions you can have:
| Tier | Subscriptions in total | Of them instant |
|---|---|---|
| Starter | 3 | none |
| Professional | 10 | 2 |
| Business | 25 | 8 |
| Enterprise | unlimited | 25 |
The limits are counted separately: on Professional you may have ten subscriptions, but at most two of them instant - the rest work as a digest. If instant delivery is not available to you, the option is visible but disabled, with a note on what unlocks it.
What you will actually receive. A task goes into an email if it is open for proposals, was published after the subscription was created, and has not been sent to you before. Subscribed to both a section and a service type inside it - the email comes once; sent instantly - it will not be repeated in the evening digest. You never get emails about your own tasks. The task description is not included - you follow the link to the site for details; if there were no new tasks during the day, no email is sent.
Management - the Task Subscriptions page in the «I'm an Executor» menu: all subscriptions, the mode of each, and two counters (how many subscriptions are used and how many of them are instant). The mode can be changed right in the row; a subscription can be paused or deleted. Pausing differs from deleting in that the creation date is kept - after unpausing, older tasks do not arrive retroactively.
Every email has an Unsubscribe link in the footer: it opens a page without signing in, and one button puts all task subscriptions on pause. Note that this only concerns alerts about new tasks - emails about your own tasks, money and account security keep coming.
Changing your tier never deletes subscriptions. If the right to instant delivery is gone, all instant subscriptions switch to the digest; if there are fewer slots, the oldest subscriptions stay instant (a long-standing subscription is a deliberate choice of direction, a fresh one is more often a trial). You get an email listing the changes and can redistribute the slots yourself. If the new tier allows fewer subscriptions than you already have, the extra ones keep working, but you cannot create a new one until the count drops to the limit.
Step 2. Study the terms
Service milestones. A task may show "Project Start" and "Project Completion". These are points on the schedule, not work: no proposals are submitted for them and they carry no budget. You can only apply for work milestones.
Open the task card and read carefully:
- the description of what needs to be done;
- the milestones of the work and their content;
- the budget and the payment terms per milestone;
- the deadlines;
- the security deposit, if the customer requires one on the milestone.
- the "How this regular task works" block, if the task repeats on a schedule: it shows the payout dates, the customer's approval window and the rules of pausing and leaving. Details are in the section «Recurring Tasks».
[скриншот: executor_task_details]
Assess the task soberly: submit a proposal only if you're confident you can deliver on time and at the required quality. Backing out of already accepted work carries a penalty (see Step 4).
Step 3. Submit a proposal
If the task suits you, submit a proposal. In it you specify:
- the price at which you're ready to do the work (or your part);
- the expected start and end dates;
- a comment to the customer - why you're the right fit.
[скриншот: executor_submit_proposal]
When you submit a proposal, a chat with the customer is created automatically - it's handy for clarifying details. This is the negotiation chat: it is open while recruitment is going on. After the task starts it stays as history, and the work is discussed in the work chat.
Submitting a proposal costs nothing. While the customer is deciding, your money stays available. A freeze may happen later, and only if the milestone requires a security deposit: it is frozen the moment your proposal is accepted (see Step 4).
About dates. You may propose your own dates, different from the milestone's plan dates. But they must fit the milestone order: a milestone cannot start before the ones it depends on are finished. If your dates overlap an already accepted milestone, the customer won't be able to accept your proposal until the dates are agreed - so propose realistic dates.
All your proposals and their statuses are visible under I'm an Executor → My Proposals.
Step 4. Wait for the customer's decision
The customer reviews the incoming proposals and makes a decision. Your proposal may be:
- under review - the customer hasn't decided yet;
- accepted - you're attached to the task (or to a milestone). Congratulations, you can work;
- rejected - the customer chose another executor.
[скриншот: executor_proposal_status]
The deposit is frozen on acceptance. If the milestone requires a deposit, that is the moment the amount moves from your available funds into frozen ones. Not enough - the proposal cannot be accepted: you get a notification saying they wanted to take you and how much was missing. Top up your balance and the customer can accept again.
Withdrawing your proposal. You can withdraw a proposal, but if it has already been accepted, withdrawal carries a penalty (the first three - without it) - it protects the customer who was counting on you, and it affects your reputation. And if a deposit was placed on the milestone, you lose that too: it is forfeited to the platform. So withdraw only when truly necessary.
After the task starts, an accepted proposal cannot be withdrawn - the withdraw button is gone. If you cannot continue the work, tell the customer in the work chat.
Accepted tasks appear under I'm an Executor → Active Orders.
Step 5. Do the work milestone by milestone
Work is done milestone by milestone. Complete them in order, following the description and deadlines. All questions about the task are conveniently discussed in the chat with the customer.
[скриншот: executor_work]
Show your progress on a milestone
Every milestone has a completion percentage. It is a way to show the customer how things are going without words: they see movement and don't have to keep asking "how is it going?".
- The percentage is set with a slider or typed as a number, in steps of 1%.
- Manually you can set a value from 0 to 99.
- 100% is set automatically only - when the milestone is submitted for acceptance. It means "the executor considers the work finished and has delivered it", not "the milestone is closed". The milestone is finally closed by the customer's decision (or by a dispute resolution).
- The percentage can be changed by the executor of this milestone, the task's Team Lead and the customer. The milestone card shows who changed the value last and when.
Why the customer can change it too. The field is a way to keep both sides in sync, not one side's reporting. It happens that an executor forgets to move it for weeks and the customer, by agreement, sets the actual value. The action is not anonymous: the name and the time are visible to both sides, so quietly rewriting someone's progress is not possible.
What happens on a return for revision
The milestone gets the "In revision" status and the percentage drops from 100 to 99%. This is a technical marker meaning "delivered but not accepted", not an assessment of how much work is actually done.
If less is actually done, set the real value manually. The 0-99 range is open exactly for that: after a return you are free to set 40% if forty is what is really done. The "In revision" status stays - it lives separately from the percentage.
What the percentage does NOT affect
So that no false expectations arise:
- it does not affect payment - money follows the milestone budget, not the percentage;
- it does not affect the dates - the milestone dates do not depend on it;
- it does not affect acceptance - a milestone can only be accepted through submission for acceptance.
It is a communication tool: it shows the customer how things are going and saves everyone from "so how is it going?" messages.
Milestone percentages add up into the overall task progress. It is not a simple average but is weighted by budget: an expensive milestone affects the overall figure more than a cheap one.
Milestone attachments
You can attach files to a milestone - sources, mockups, reports. Every file is scanned by antivirus before it is stored: an infected file is rejected and you get a message about it. An attachment can only be downloaded by the person it is meant for, and only after the scan has passed.
Password-protected archives are not accepted. The antivirus cannot inspect the contents of an encrypted archive, so such a file is rejected at upload - regardless of what is inside. Send archives without a password.
Work Calendar
To keep deadlines in sight, open I'm an Executor → Work Calendar: all the milestones you are responsible for are laid out by dates. Planned and accepted (contracted when the proposal was accepted) dates are visible, along with the milestone status and completion percentage. Clicking an event opens the task.
Step 6. Submit milestones for acceptance
When a milestone is ready, put it up for acceptance - this signals the customer to review the result. You can submit only your own milestone: other team milestones have no "Submit for review" button for you. (The customer can also initiate acceptance if they see the work is done.) At this moment the milestone's completion percentage automatically becomes 100%.
Then the customer makes a decision (or the Team Lead, if the customer delegated acceptance). The customer cannot cancel a submitted milestone - only accept, send back or open a dispute:
- Accept - the milestone is counted and paid for.
- Send back for revision - the customer returns the milestone with a comment on what needs fixing. Fix it and submit the milestone again. The completion percentage drops from 100 back to 99% - the milestone is in progress again.
- Dispute - recording a disagreement when the sides could not settle it.
You can open a dispute too, not just the customer. If your work is not being accepted for no clear reason, or is returned for revision endlessly, this is your instrument. A detailed comment is required. While the dispute is open, the money for the milestone stays frozen in the reservation: neither side can take it.
What protects you from endless revisions
| Situation | What the system does |
|---|---|
| 3rd return of the milestone for revision | a hint to both sides: it may be time to open a dispute |
| 5th return | the milestone automatically goes to dispute |
| Milestone waiting for acceptance for 7 days | the customer gets a reminder |
| Milestone waiting for acceptance for 14 days | the milestone automatically goes to dispute |
So you don't have to decide on a confrontation yourself: if the loop is not converging or the customer stays silent, the system moves the case to a dispute for you.
How a dispute is resolved
| Stage | Who decides | What happens |
|---|---|---|
| 1. Negotiation | the sides themselves | the customer proposes a payment amount for the milestone, you accept or decline |
| 2. Arbitration | a platform staff member | available no earlier than 5 days after opening. Either side can escalate; the arbiter's decision is final |
Outcomes: full payment, partial (for what was actually done), or no payment.
There is no automatic resolution by timeout - a dispute cannot be won by staying silent.
Stage: the dispute resolution procedure and the automatic escalation are under development. For now a dispute records the disagreement and freezes the milestone's money.
[скриншот: executor_submit_milestone]
Read revision comments carefully and communicate in the chat - most remarks are cleared in one or two iterations, without reaching a dispute.
Step 7. Get paid
As soon as a milestone is accepted, the reward for it arrives on your balance - immediately, from the funds the customer reserved in advance (escrow). There is no need to wait for the whole task to finish: each milestone is paid separately.
The deposit comes back together with the payment. If you placed a deposit on the milestone, it is unfrozen at that same moment: both the reward and your own money arrive on the balance. The same happens on acceptance by the customer's silence - their silence cannot cost you money.
How much reaches your balance
A platform fee is withheld from the milestone amount; you receive 95 %:
| To whom | If you have a referrer | If you have no referrer |
|---|---|---|
| You | 95 % | 95 % |
| Platform | 2.5 % | 5 % |
| Your referrer | 2.5 % | - |
The same withholding applies when withdrawing funds to a blockchain wallet. Current amounts are in About Platform → About fees.
When all milestones are accepted, the task is completed. Payment history and earnings are visible under I'm an Executor → Earnings and Finances → Wallets.
[скриншот: executor_earnings]
Thanks to escrow, payment is guaranteed: the funds were frozen before the work began, and the customer cannot "change their mind about paying" for work that has been accepted.
Step 8. Leave a rating
After the task is completed, rating is mutual: you rate the customer, and they rate you. This builds the reputation of both sides.
Ratings are given when the customer closes the task. If you did not leave yours, the system puts a provisional maximum in your place - but you have 7 calendar days from the closing to replace it with your own.
A system rating is not counted in the customer's average. So your silence will not improve their reputation artificially - but your opinion will not be in it either. If the rating matters to you, use the week.
[скриншот: executor_rate]
Team tasks
If a task is in Team Mode, executors are recruited per individual milestone: submitting a proposal and working are tied to a specific milestone. The team may have a Team Lead - the customer's trusted deputy.
Check who makes the decisions. The published task card has a "Who makes the decisions" block showing exactly what the customer entrusted to the Team Lead - recruiting, milestone acceptance, rework. It is worth reading before you submit: it determines who you will be dealing with on your milestone.
There are two recruiting orders:
- the Team Lead recruits - only their milestone is open at first, the rest are marked "opens later" and start accepting proposals after they are appointed;
- the customer recruits - all milestones are open at once.
The banner at the top of the task always says which case it is. Details are in the «Teamwork» section.
If something goes wrong
- You changed your mind after the proposal was accepted - before the task starts you can withdraw, but there will be a penalty (after three withdrawals) and a reputation hit; the milestone deposit is forfeited. After the start you cannot withdraw.
- You're running late - warn the customer via the chat as early as possible.
- The customer keeps sending work back for no clear reason - keep the communication in the chat; in disputed cases a separate review is available.
Related sections: «I am a Customer» · «Teamwork» · «Money and the secure deal»
Teamwork
Team mode is for large tasks that are best split between several executors rather than handed to one person. This section explains how team mode differs from Solo, what roles exist and how a team task is organised.
If you are not yet familiar with the basics (milestone, proposal, escrow), start with General concepts and Terminology. This section covers only what is specific to teamwork.
When to choose team mode
| Solo | Team mode | |
|---|---|---|
| Executors | one | several (at least 2) |
| Milestones | all handled by one executor | split between different people |
| Team Lead | none | optional |
| Best for | small and medium tasks | large tasks, mixed skills |
If the task is small, stay on Solo: it is simpler and faster. Team mode pays off when the work splits into parts best trusted to different people.
Roles in a team
- Customer - creates the task, funds it and remains the owner of the money held in escrow. Some decisions belong to the Customer alone and are never handed over.
- Team Lead - the Customer's trusted delegate inside the task. Not a "senior executor" but a delegate: they do exactly what the Customer chose to entrust to them. The role is optional.
- Executors - deliver individual milestones. A team task has at least two of them.
The Team Lead: milestone, budget and payment
The Team Lead is a role that owns a milestone. When the Customer ticks "Team Lead required", the task gets a "Team Lead" milestone with its own budget, dates and responsible person.
That milestone's budget is what pays the Team Lead - exactly as any executor is paid from their own milestone. There is no separate "management fee" anywhere in the system.
The Team Lead milestone differs from work milestones in two ways:
- it spans the whole task period - management runs in parallel with the work, not as a slice in the middle of it;
- it cannot be deleted like a regular milestone: it disappears only together with the "Team Lead required" tick, and only while the task is a draft.
Hiring works like for everyone else: a person submits a proposal for the "Team Lead" milestone. Only the Customer can accept that proposal - a Team Lead cannot hire themselves.
Team Lead permissions: what exactly you entrust
Right below the "Team Lead required" tick there is a "Team Lead permissions" block: a list of task functions, each with a "Customer / Team Lead" switch.
You can pick a ready-made set with one click:
| Preset | What the Team Lead gets |
|---|---|
| Customer decides everything | nothing; the Team Lead only delivers their own milestone |
| Coordinator | recruiting and milestone dates |
| Steward | recruiting, dates, rework, executor replacement, ratings, milestone acceptance |
Or set every row by hand.
Until a Team Lead is appointed, every function stays with you. You set the matrix in the draft, but you hire the Team Lead after publication - in between, the delegated functions do not go anywhere, otherwise they would belong to nobody: you no longer have them and the recipient does not exist yet. For the same reason they return to you the moment the Team Lead leaves the task.
What can be handed over
| Function | What it means in practice |
|---|---|
| Recruiting | the Team Lead accepts and rejects executor proposals |
| Milestone dates | shifts milestone dates within the overall task deadline |
| Send back for rework | returns a submitted milestone to its executor |
| Executor replacement | changes the executor on a milestone |
| Executor ratings | rates executors when the work is done |
| Milestone acceptance | accepts the work - which pays the executor |
| Milestone budget | redistributes amounts between milestones within the task budget |
| Opening a dispute | opens a dispute over a milestone on behalf of the task |
The last three carry a warning icon: switching them on hands the Team Lead the right to move money inside the task.
What always stays with you
These rows are visible in the list but cannot be switched - they are labelled "Customer only":
- publishing, starting, pausing and cancelling the task;
- changing the overall task budget and adding funds;
- accepting the proposal for the Team Lead role itself;
- replacing or removing the Team Lead;
- accepting the Team Lead's own work, editing their milestone budget, opening a dispute over it and rating them;
- editing the task description and the work requirements.
Remember the last point in particular: a Team Lead can never pay themselves, under any settings. Even if you handed over milestone acceptance, their own milestone is accepted by you.
The Team Lead selection deadline
Selecting a Team Lead has its own deadline, earlier than the overall proposal deadline of the task. The system suggests one; you can change it.
Why it exists: if you look for a Team Lead until the very end of the proposal period, there is no time left to recruit the team - and the task simply cannot start.
If the deadline passes and no Team Lead was found, nothing breaks: the money stays in escrow and the task stays where it is. What happens is:
- the task is flagged as "Team Lead selection overdue";
- proposals for the Team Lead milestone keep coming in - if the right person applies later, you accept them and the flag clears by itself;
- you choose what to do next: extend the deadline (as long as it is still earlier than the proposal deadline), return the task to draft (to work without a Team Lead or change their milestone) or cancel the task.
Extending the deadline is not a change of task conditions - you do not need to return the task to draft for it.
How the three variants of a task work
The easiest way to see the difference is side by side: the simplest case on the left, the most complex on the right.
- Solo - one executor, one proposal, milestones accepted one after another.
- Team without a Team Lead - several executors, one per milestone; you accept every proposal and every milestone yourself.
- Team with a Team Lead - the Team Lead milestone and the permission matrix are added. If recruiting is delegated, two phases appear; their own milestone closes last.
Two recruiting orders
The order depends on who you trusted with recruiting.
If the Team Lead recruits
The order is strictly sequential:
- Only the "Team Lead" milestone is open for proposals. The other milestones are visible but marked "opens once the Team Lead is appointed" - proposals for them are refused.
- You accept the Team Lead proposal.
- The remaining milestones then open, and proposals for them are reviewed and accepted by the Team Lead. You see every proposal and every conversation, but you have no accept button - you handed that function over.
- Once all milestones have executors, you start the task.
If you recruit
All milestones, the Team Lead one included, are open for proposals as soon as the task is published. Selecting a Team Lead has no priority: it is one milestone among the rest.
You accept proposals in any order. Executors may well be hired before the Team Lead is - that is fine. The task starts once every milestone has an executor, including the Team Lead milestone.
A Team Lead hired this way handles whatever else you delegated - dates, rework, acceptance - but does not recruit the team.
Readiness to start
Before the task can start:
- at least two executors are hired;
- the budget is fully distributed across milestones, including the Team Lead milestone - its budget must be greater than zero;
- every milestone has an executor, the Team Lead milestone included.
The Checklist tab shows how ready the task is: for every condition you see whether it is met, and for an unmet one - what exactly is missing. A team task has a separate line for every working milestone. See «I am a Customer» for details.
Only the Customer can start the task, whatever the permission settings.
How the work runs
- Each executor handles their own milestones. Only your own milestone can be submitted for review - other cards have no such button.
- Acceptance happens per milestone: the executor submits it, and whoever holds the permission - you or the Team Lead - accepts the work. Only they see the Accept, Send back and Dispute buttons.
- Payment for each accepted milestone goes to the executor who delivered it, out of the reserved funds.
- The Team Lead submits their own milestone to you like any executor - but last, see below.
- At the start, the general team chat and a work chat between you and each participant (with threads per milestone) open. Negotiation chats stay as history.
You always see everything the Team Lead does - proposals, acceptances, disputes. Delegating a function costs you the button for it (it disappears for you), never the overview: otherwise two people could decide the same milestone at once.
Once all milestones are finished, you close the task with the Complete project button and rate every participant, including the Team Lead - it cannot be closed without that. Participants rate you (the 7-day rule and the system rating apply here too).
The Team Lead milestone closes last
While work is still going on any milestone, the Team Lead cannot submit their own - the system will refuse. Their milestone can be submitted only when:
- every work milestone is finished - accepted, cancelled or marked not fulfilled;
- there is no open dispute on the task.
This is exactly the condition under which you can close the whole task.
Why. The Team Lead's job is running the whole project, and it can only be judged once the project is done. Accepting their milestone halfway would mean paying the entire fee upfront with nothing securing the remaining time.
An open dispute delays the Team Lead's payment too - on any milestone, not just their own. The task is not finished yet and the disputed money is frozen. This is a deliberate rule, not a glitch.
After that it works like for any executor: the Team Lead submits the milestone, you accept it or send it back for revision. You always accept - that is one of the non-transferable decisions.
If something goes wrong: revoking permissions
You own the funds, so you can revoke the delegation at any moment, including while the task is running. It is an emergency button: every delegated permission is withdrawn at once, the Team Lead is notified and the action is logged.
After a revocation the Team Lead stays in the team and keeps their milestone - they lose management rights, not their work or their payment. Parting with them entirely is a separate action (removing an executor), always available to you.
Granting permissions back after a revocation requires returning the task to draft: otherwise the Team Lead's terms could be changed unilaterally.
What you see on screen
The banner above the proposals list is the first thing you see on a published task. It tells you how recruiting is going right now:
| When | What it says |
|---|---|
| The Team Lead recruits, not appointed yet | Phase 1 - Team Lead selection. Only proposals for their milestone are accepted |
| The Team Lead recruits, appointed | Phase 2 - forming the team |
| You recruit | Team recruiting. All milestones are open, you accept the proposals |
The "TL" badge in the task header says the same, shorter: selection is on, the Team Lead is appointed, or simply "this task has a Team Lead milestone".
Executors see a "Who makes the decisions" block in the published task card with the same matrix: before submitting a proposal they know exactly what is entrusted to the Team Lead. If a milestone is still closed, instead of "Submit a proposal" there is a disabled "Opens later" with an explanation.
The Team Lead sees the same buttons you do, but only the delegated ones are clickable; the rest are disabled with a "the customer decides" hint. Nothing is hidden - the scope of authority is always visible to both sides.
What the Team Lead cannot do
However much they might want to. The messages they will see:
| What they try to do | What the system answers |
|---|---|
| Accept a proposal when recruiting is yours | Team recruiting on this task is handled by the customer |
| Accept the proposal for their own role | This proposal is decided by the customer |
| Accept their own milestone or change its budget | Decisions on your milestone are made by the customer |
| Change the overall task budget | The task budget is managed by the customer |
| Publish, start, pause or cancel the task | This action is available to the customer only |
| Submit their milestone while others are running | The Team Lead milestone closes last: other milestones are not finished yet |
| Submit their milestone while a dispute is open | While a dispute is open on the task, the Team Lead milestone cannot be closed |
An executor trying to submit a proposal for a work milestone before the Team Lead is appointed (sequential recruiting) gets: "The task's Team Lead must be appointed first".
Edge cases
A Team Lead is appointed but nothing is delegated. That is allowed: they simply work as the executor of their own milestone. On publication you get a warning, "no function is delegated to the Team Lead", but it does not block you.
The task is paused. Permissions are kept, but actions based on them are unavailable to both sides until the pause is lifted.
You unticked "Team Lead required" in the draft. The Team Lead milestone is removed together with its links, the permission settings are erased and the selection deadline is cleared.
The Team Lead leaves the task. The delegated functions return to you automatically, while the matrix settings are kept - a new Team Lead gets the same scope.
Not there yet. The "executor replacement" permission is in the list, but the replacement mechanism itself does not exist in the system yet - the switch will start working together with it. Acceptance can be withdrawn (by either side) only before the task starts; if an executor drops out during the work, their milestone can only be cancelled (while the work is not submitted), and its budget returns to you when the task closes.
Role cheat sheet
Want to be a Team Lead? Submit a proposal for the "Team Lead" milestone of a team task, the same way an executor applies for a regular milestone. Only the Customer can accept it. You are paid from that milestone's budget.
Before applying, check the "Who decides" block in the task card: it shows what will be entrusted to you - coordination only, or acceptance and budget as well. That is part of the terms you agree to.
Want to be an executor in a team? Submit a proposal for a specific milestone of a team task. The rest works as for any executor (see I am an Executor), within your own milestone. Check who accepts work on the task: the Customer or the Team Lead.
Related sections: I am a Customer · I am an Executor · Money and escrow
Money and the secure deal
This section is about how money works on the platform: where it comes from, how it is frozen for a task, and when it is paid out. Understanding this mechanism removes most questions and fears - for both the customer and the executor.
Basic definitions (balance, escrow, budget types) are collected in «Terminology»; here we look at how it all works in practice.
Balance: available and reserved
Money on your balance comes in two states:
- Available funds - you can use them freely: start new tasks, withdraw, etc.
- Reserved funds - frozen for a specific task (escrow). They are still yours, but temporarily unavailable for other purposes until the task is completed or canceled.
Available balance = everything that is not frozen. It is exactly this that the system checks when you publish or start a task.
Both are counted separately for each token. You have one wallet, but inside it KNL, AGTI and USDT keep their own balances: freezing funds for a task in one token does not touch the others, and the "are there enough funds" check always applies to the token the operation needs.
The money lifecycle in a task
In short, step by step:
- Top up - you put funds on the balance (they are available).
- Publish the task - the system freezes the declared budget (escrow) and takes the fee for creating the task.
- Start the work - if the actual (working) budget differs from the declared one, the frozen amount is recalculated (re-reservation).
- Accept milestones - for each accepted milestone the money leaves the reservation toward the executor.
- Completion - all milestones accepted, settlements closed.
On task cancellation, the unused reservation returns to available funds.
Reservation at publication
When you publish a task (move it from a draft to Open Tasks), the system:
- Checks the available balance. It must be at least the declared budget. If funds are short - publication is rejected with a "Not enough funds" message.
- Takes the fee for creating the task (see below).
- Freezes the declared budget - moves that amount from available to reserved.
From that moment, money for the task is guaranteed set aside: executors see that payment is secured.
Re-reservation at start
The declared budget (what you set aside) and the working budget (the sum of accepted proposals) may not match - you might have accepted proposals for a larger or smaller amount. So at the start of the task the system reconciles them:
- Amounts equal → the reservation is untouched, the task simply starts.
- Amounts differ → a re-reservation is performed: the old reservation is released, and the new, actual amount (the working budget) is frozen.
Two examples for clarity (amounts are illustrative):
| Situation | Declared (frozen) | Accepted (working budget) | What happens at start |
|---|---|---|---|
| Accepted less | 1000 | 800 | The reservation drops to 800; 200 return to available funds. |
| Accepted more | 1000 | 1200 | An extra 200 must be frozen. If it's not on the available balance - the system asks you to top up. |
So before starting a task, keep a small reserve on the balance - in case the total of accepted proposals turns out larger than the declared budget.
Payment for the work
Payment is tied to milestones, not to the task as a whole. There is no need to wait for the whole task to finish: the moment the customer accepts a milestone, the money for it goes to the executor.
| Event | What happens to the money |
|---|---|
| Milestone put up for acceptance | nothing, the funds stay reserved |
| Customer accepted the milestone | the amount leaves the reservation and is credited to the executor immediately |
| Customer sent it back for revision | nothing, the funds stay reserved |
| Milestone in dispute | funds are frozen in the reservation until the dispute is resolved |
| Task closed | the unused remainder of the reservation returns to the customer |
- In Solo all milestones are paid to one executor.
- In Team mode each milestone is paid to the executor who performed it. This includes the Team Lead: their work is an ordinary milestone with its own budget, submitted for acceptance and paid the same way.
The Team Lead milestone is paid last. It can only be submitted once every work milestone is finished and no dispute is open on the task. The reason is simple: the Team Lead's job is running the whole project, and paying for it upfront would leave the remaining time unsecured. See «Teamwork».
How much the executor receives
A platform fee is withheld from the milestone amount. The executor receives 95 %:
| To whom | If the executor has a referrer | If there is no referrer |
|---|---|---|
| Executor | 95 % | 95 % |
| Platform | 2.5 % | 5 % |
| Executor's referrer | 2.5 % | - |
For the customer the amount is the same either way: the full milestone price leaves the reservation. The split happens on the platform's side.
The same withholding applies when withdrawing funds to a blockchain wallet: you receive 95 % of the amount. Deposits and transfers between users are free of charge.
What escrow guarantees
- The money is frozen before the work starts - the executor can see that payment is backed and is not working on a promise.
- For an accepted milestone the customer can no longer "change their mind about paying": the payment happens at that moment and is irreversible.
- The customer does not pay for a milestone they did not accept.
What escrow does not solve. It does not judge the quality of the work - the acceptance decision is the customer's. If the sides disagree, that is what a dispute is for (see «I am a Customer» and «I am an Executor»): either side can open one, and while it is being resolved the money stays frozen in the reservation - neither the customer nor the executor can take it.
The executor's security deposit
Everything above is the customer's money. But a deal has two sides, and by default walking away costs them differently: the customer's funds are frozen from the moment of publication, while the executor can leave having lost nothing. To even this out, the customer may require a security deposit on a milestone.
It is a right, not an obligation: most tasks have no deposit. The requirement is set per milestone and stated as a fixed amount in the task's currency - no more than that milestone's own budget.
| Moment | What happens to the deposit |
|---|---|
| The task is published | The executor sees the amount on the milestone - before submitting a proposal |
| A proposal is submitted | Nothing: the money stays available |
| The customer accepts the proposal | The amount is frozen on the executor's balance |
| Work is under way | Frozen; visible in the wallet under "Reserved" |
| The milestone is accepted | Returned together with the payment, in one move |
If the executor does not have enough available funds at the moment of acceptance, the proposal cannot be accepted: the customer sees how much is needed and how much is missing, and the executor gets a notification - they can top up their balance and the customer can accept again. Funds are checked across all the proposal's milestones at once rather than one by one: otherwise part of the money would already be frozen and the refusal would arrive on the last milestone.
When the deposit is not returned
The only case is the executor withdrawing an already accepted proposal. The deposit is then forfeited to the platform. The usual penalty for withdrawal does not go away: the violation is counted as always, the money is simply taken from the deposit.
The customer never gets the deposit - under no circumstances except an arbiter's decision in a dispute. The right to take it by their own decision would give the customer a direct financial interest in failing the acceptance, and the safeguard would turn into a way to earn.
In every other case the deposit is returned in full: the milestone is accepted, the task is cancelled or closed, a dispute is resolved in the executor's favour, the sides settle between themselves, the customer ends the relationship. There is no partial forfeiture - either all of it comes back or all of it is kept.
A deposit is not an expense. It is your own money, temporarily unavailable, just like the customer's reservation. No fee is charged on it and it does not affect payment for the work.
Fees
The platform gives you one wallet, but it holds several tokens and the balance of each is counted separately:
| Token | What it is for |
|---|---|
| KNL | platform fees: creating a task, paid options (for example, chat encryption) |
| AGTI | account activation, buying capabilities - subscriptions and their add-ons |
| USDT | settlements on tasks |
Work can be paid in any of the three tokens. The customer picks the token when creating the task, and every milestone of that task is paid in it - it cannot be changed later.
A practical consequence: to publish a task you need funds in two places - in the task's token (for the budget) and in KNL (for the creation fee). One does not substitute for the other: 500 USDT will not help if you are short of KNL.
Platform fees:
| For what | In what | When it is charged |
|---|---|---|
| Creating a task | KNL | on publication, not when the draft is created |
| Paid options (chat encryption etc.) | KNL | together with task creation |
| Withholding from the executor's payment | from the milestone amount | at the moment of acceptance (see above) |
| Withholding on withdrawal | from the withdrawal amount | at the moment of withdrawal |
| Account activation | AGTI | once, at activation |
| Subscription and add-ons | AGTI | on purchase and renewal |
Current fee amounts are in About Platform → About fees and on the screen before the operation itself. Percentages and amounts change over time, so the only reliable source is the platform, not this guide.
Separately about the blockchain network fee (sometimes called "gas"): this is the network's own charge for processing an operation. The platform does not receive it and cannot influence it. It arises when depositing and withdrawing funds.
If there aren't enough funds
The "Not enough funds" message appears in two cases:
- at publication - the available balance is less than the declared budget;
- at start - there aren't enough available funds for re-reservation (if more was accepted than declared).
The solution is the same: top up under Finances → Deposit Funds and repeat the action.
Refund on cancellation
If a task is cancelled, the unused reservation returns to your available funds. This is the money for milestones that were not accepted.
Amounts already paid for accepted milestones are not returned - that work was accepted, and payment to the executor is irreversible.
The task creation fee is not refunded on cancellation either: it is charged for the publication, which already happened.
Related sections: «General concepts» · «I am a Customer» · «I am an Executor»
Referral programme
You can invite new participants to the platform and get rewarded for it. Invited users are called your referrals, and you are their referrer.
The section is in the user menu (profile icon in the header) → Referrals.
The section may be unavailable - the referral programme is switched on by the platform administrator.
Your referral link
The section shows your personal link in the form
https://<platform address>/register?ref=… and a QR code with the same link.
The button next to it copies the link to the clipboard.
Anyone who registers via your link is automatically attached to you. The link is permanent: it does not expire and is not reassigned.
You can only become someone's referrer at the moment they register. If a person is already registered on the platform, they cannot be attached to you retroactively.
Two kinds of reward
| Kind | What for | When it is credited | In what |
|---|---|---|---|
| Registration bonus | your referral activated their account | once per referral | AGTI |
| Income share | your referral receives payment for work or withdraws funds | every time | in the token of the operation |
Registration bonus
It is credited not for the registration itself but for the account activation by the invited person - that is, when they actually came to work rather than just created a login. The money arrives on your balance automatically, right after the activation payment is confirmed.
The bonus amount is set individually for each referrer and is shown in the section. If it is not set, no registration bonus is credited - the income share works independently of it.
The bonus is never paid twice for the same person: the system enforces this at the database level.
Income share
While your referral works on the platform, you receive 2.5 % of:
- every payment they receive for an accepted milestone;
- every withdrawal they make.
This is not deducted from their money. Here is how a milestone amount is split:
| To whom | The referral has a referrer (you) | No referrer |
|---|---|---|
| Executor | 95 % | 95 % |
| Platform | 2.5 % | 5 % |
| You as the referrer | 2.5 % | - |
The executor receives their 95 % either way - your 2.5 % comes out of the platform's own share. So inviting someone does not worsen their terms in any way, and there is no reason to hide it.
Current percentages and amounts are in About Platform → About fees.
What the section shows
- Total referrals and how many of them are active right now.
- Registration bonuses and income share - separately, broken down by token.
- The list of referrals: name, registration date, status (confirmed, activated), workload, number of completed tasks and submitted proposals, rating.
- A referral card - detailed statistics for a particular person.
All credits also appear in the ordinary operation history: Finances → Wallets.
FAQ
Do I have to pay anything to take part? No. The programme requires neither fees nor a subscription.
Does the referral lose anything? No. Your reward from their operations is paid by the platform out of its own commission, not out of their payments.
What if a referral registered but never activated their account? No registration bonus is credited - it is tied to activation. Such a referral appears in the list with the "not activated" status.
Are there levels (referrals of my referrals)? No. Rewards are credited only for those who registered directly via your link.
Related sections: «Money and the secure deal» · «Getting started»
The network and its nodes
The platform is built not as one big website but as a network of independent nodes. This section explains what that means in practice: an ordinary user does not have to know how the network is arranged, but it helps to understand where your money and your data actually live.
What a node is
A node is an independent site with its own user base, its own tasks and its own wallet. Nodes are run by different operators, and each operator is responsible for their own node.
The name of the system refers to nervous tissue: the nodes of the network are neurons (hence Stemneuron), and the link between them is a synapse.
You always work on your own node - the one where you registered. It is called your home node. Your tasks, balance, transaction history and conversations live there.
Your balance is an obligation of your node, not of the network as a whole. The funds are backed by real money in the wallet of the node where you are registered. That is exactly why moving funds between nodes is not an "internal transfer" but the ordinary route: withdraw to a blockchain wallet from one node and deposit on the other.
Why the network exists
Nodes are not isolated: they know about each other, exchange information about themselves (who is who, what they specialise in, which languages they support) and can verify each other's authenticity by cryptographic signature.
You can look at the network under About Platform → Nodes: there is a network map and a list of nodes with their status and region.
Important: information about the nodes themselves is synchronised between them, but tasks, users and money are not. There is no global catalogue of tasks across the network. The data of your node never leaves it without that node's explicit decision.
A.Synapse - the inter-node protocol
Status: in active development and testing. What follows is how it will work. The feature will appear in the interface once testing is complete - this section is here so that you understand where the platform is heading.
Sometimes a node gets a complex task that none of that node's executors can take on. Today the customer in such a situation simply waits for a suitable executor. A.Synapse is the platform's own protocol, which we are actively working on: it will let a node find specialised nodes in the network and engage their executors.
How it will look from the user's side:
- For the customer. You post a task as usual. If your node has no suitable executors, it sends out an impulse - a request for help to specialised nodes of the network. Responses reach you as ordinary proposals.
- For the executor. You will be able to take on work on another node. Technically that means you become a user of that node as well - otherwise it could not pay you. Your home node stays yours: when the work is done it receives an act, a signed report on the work performed, which counts towards your reputation.
The key principle everything else follows from: money does not cross the node border - the executor's identity does. Paying a guest is an ordinary internal operation of the node that hosts the task, not a debt of one node to another. Escrow and the acceptance rules work exactly as described in «Money and the secure deal».
What this means for you. What you earn on such a task lands on the balance of the node where the work was done - and a balance, as a reminder, is an obligation of that particular node. To bring the money home you have to withdraw it to a blockchain wallet and top up your home node's balance from there: two ordinary blockchain operations, each with its own network fee.
What is not settled yet in this part
This section describes a direction, not a finished mechanism, and it is fairer to say which decisions are still missing:
- who answers for funds held on someone else's node - the node operator's obligations and what happens if they leave the network;
- how reputation travels between nodes: user data is not synchronised across nodes today, so a customer would not see a guest's rating;
- how to prevent faked acts - if anyone can run a node, the network needs admission rules and criteria under which acts count as trustworthy. A cryptographic signature proves the node's identity, not its good faith;
- how a dispute between parties on different nodes is resolved - whose rules apply and who enforces the decision.
Until these are closed, cross-node work is not switched on: we are not going to promise protection that does not exist.
A.Synapse protocol © AGTI Stemneuron, 2026. All rights reserved.
Related sections: «General concepts» · «Money and the secure deal»
FAQ
Short answers to common questions. For details, see the relevant documentation sections.
Account and getting started
What's the difference between a customer and an executor? These are not separate accounts but roles on a specific task. The same user can order work on one task and do someone else's on another. See «General concepts».
The confirmation email didn't arrive. What should I do? Check the "Spam" folder. If there's no email - request it again on the "Resend confirmation" page.
How is the confirmation code different from the PIN code? The confirmation code is one-time, from the email, needed only to confirm your address. The PIN code is your permanent secret for quantum-resistant encryption of critical data; the system does not store it. They are different things.
I forgot my PIN code. What now? It cannot be recovered: the system does not store it, so neither support nor the administration can help.
What that means in practice: the PIN code is required at every login, so without it you cannot sign in to your account - not merely read the encrypted data. A password can be recovered by email, a PIN code cannot. See «Getting started».
What should the PIN code look like? At least 6 characters; letters, digits and special characters are allowed. It is not a four-digit card PIN but rather a short passphrase. You invent it yourself at registration.
How much does account activation cost? Currently 100 AGTI (the amount may change - rely on the screen). It's a one-time payment to the system wallet; the wallet you pay from is bound to your account.
How is AGTI different from KNL? AGTI is for account activation. KNL is the main utility token ("fuel"): it pays for fees, options and subscriptions.
Pop-up messages disappear too fast (or get in the way). Can I change that? Yes: Settings → Parameters → Toast notifications. The duration is set separately for ordinary messages and for errors, plus there is a pause on hover. Allowed values are 0 (do not hide automatically) and 2 to 60 seconds. Errors do not hide by themselves by default - that is deliberate. New values take effect right after saving.
Money
I sent a transfer and closed the tab before it was credited. Is the money lost? No. The platform finds out the fate of the transfer itself and completes the job: the deposit is credited, the activation goes through, the notification arrives. If the transfer got stuck because the network fee was too low, it stays in the list of pending ones and may go through even days later - the platform does not cancel it.
Where do I get AGTI, KNL and USDT? These are BSC blockchain tokens - the platform does not sell them. You can buy or swap them on external crypto services, then transfer them to your wallet and top up your balance from it (Finances → Deposit Funds).
How do I withdraw money from my balance? Withdrawal is not available yet - the feature is under development. For now the balance can be topped up and used inside the platform: paying for tasks and receiving payment for work.
Do I need funds to do work? As a rule no: payment comes after acceptance and you invest nothing. The exception is the security deposit: the customer may require one on a milestone, and then its amount must be on your balance at the moment your proposal is accepted. The deposit is frozen for the duration of the work and returned together with the payment. Otherwise funds are only needed when you are the customer.
How much does creating a task cost? The creation fee is currently 50 KNL, charged when the task is published. The current amount, the token and your balance are shown on step 2 of the creation wizard; a summary of all fees is in About Platform → About fees. If you never publish a draft, the fee isn't charged.
My balance is short of the fee - can I still create a task? Yes. The wizard warns you about the shortfall but still lets you create the draft. You will need the balance later, by the time you publish.
Is payment guaranteed to the executor? Partly - and it matters where the line runs.
What is guaranteed: the money is frozen in escrow before the work starts, and for an accepted milestone the customer can no longer "change their mind about paying" - the payout happens at that moment and is irreversible.
What is not guaranteed: the acceptance itself. The decision is the customer's, and if they do not accept the work, the money stays frozen. That is what a dispute is for - either side can open one (see «I am an Executor»).
In short: escrow protects you from non-payment for accepted work, but it does not replace an agreement on what counts as work done.
I got "Not enough funds". What should I do? Top up under Finances → Deposit Funds and repeat the action. This happens at publication (not enough for the declared budget) or at start (if more was accepted than declared - see re-reservation).
What is re-reservation? If, by the start, the working budget differs from the declared one, the system releases the old reservation and freezes the new amount. See «Money and the secure deal».
Will I get my money back if I cancel a task? The unused reservation (for unaccepted milestones) returns to available funds. Already-paid accepted milestones are not refunded.
For the customer
Can I change the milestones after publication? The set of milestones is fixed at publication. To change it, the task must be unpublished - and then the already-submitted proposals become invalid.
The work was done poorly. What should I do? Send the milestone back for revision with a clear comment. If there's no result after several revisions - you can open a dispute. See «I am a Customer».
I accepted a proposal but changed my mind. You can withdraw an accepted proposal, but it may carry a penalty - it protects the executor who was counting on the work.
Why can't I accept a proposal with different dates? If the proposed dates overlap an already accepted (contracted) milestone, you can't accept - agree on different dates with the executor. See «I am a Customer», the "Dates in proposals" section.
For the executor
How do I learn about new tasks without visiting the exchange every day? Subscribe: there is a bell next to a catalogue section and next to a service type, and a «Subscribe to all new tasks» button in the catalogue header. By default emails arrive once a day as a list; instant delivery (within a few minutes of publication) depends on your tier and is limited in number. All subscriptions are on the Task Subscriptions page in the «I'm an Executor» menu. See «I am an Executor» for details.
I'm tired of emails about new tasks. How do I turn them off? The Unsubscribe link in the footer of any such email: it opens a page without signing in and, with one button, pauses all task subscriptions. Emails about your own tasks, money and account security keep coming - this link does not turn those off. Subscriptions are not deleted; you can switch them back on from the subscriptions page.
I submitted a proposal - why was nothing reserved? That's expected. Submitting a proposal doesn't reserve any of your funds - the financial side is entirely on the customer.
Can I withdraw my proposal? Yes, but if it's already been accepted there will be a penalty (the first three withdrawals without it) and a reputation hit, and the milestone deposit is forfeited. An accepted proposal can be withdrawn only before the task starts; after the start - no.
I proposed my own dates, but the customer can't accept. Your dates may overlap an already accepted milestone or break the order. Agree on the dates with the customer and adjust the proposal.
The customer is not accepting the submitted milestone. How long do I wait? If the work is delivered and there is no decision, you can open a dispute - this is available to the executor, not only to the customer. Automatic reminders and moving a stalled milestone to a dispute are also planned (see «I am an Executor», the section on protection from endless revisions).
The customer keeps sending the work back for revision. What do I do? Same case: open a dispute. A detailed comment is required. While it is being resolved, the money for the milestone stays frozen - neither side can take it.
Does the platform withhold anything from my payment? Yes. You receive 95 % of the milestone amount, the rest is the platform fee (or 2.5 % to the platform and 2.5 % to your referrer if you have one). The same withholding applies to withdrawals. See «Money and the secure deal».
What happens to my payment if the task is cancelled mid-work? Milestones already accepted stay paid - the payout is irreversible. For the milestone you were working on but did not submit, the ability to open a dispute for partial payment is planned. That part is under development.
Team
Who is the Team Lead and what can they do? The Team Lead is the customer's trusted deputy on a team task. They can do exactly what the customer delegated: from nothing at all to recruiting, dates, rework and milestone acceptance. At the same time they are the executor of their own milestone and are paid out of its budget. See «Teamwork».
What can be delegated to the Team Lead, and what cannot? Eight functions can be delegated: team recruiting, milestone dates, sending work back for revision, executor replacement, rating executors, milestone acceptance, milestone budget, opening a dispute. Never delegated: publishing, starting, pausing and cancelling the task, the overall budget, accepting the proposal for the Team Lead role itself, replacing them, and anything concerning their own milestone.
Can the Team Lead pay themselves? No, under no settings. On their own milestone they do not accept the work, do not change the budget and do not open disputes - only the customer does.
Why can't the Team Lead submit their milestone? It closes last: all work milestones must be finished first and no dispute may be open. Their job is running the project, and it can only be judged once the project is done.
What if no Team Lead is found before the deadline? Nothing breaks: the money stays in escrow and the task status does not change. The task gets a "Team Lead selection overdue" mark, proposals for their milestone keep coming, and the customer decides - extend the deadline, send the task back to draft, or cancel it.
How many executors does a Team task need? At least two. The upper bound is set by your tier: one milestone is performed by exactly one executor, so the team size follows from the number of work stages, and their maximum is limited by your subscription.
Why are team mode or the Team Lead unavailable? They are unlocked by your subscription. On the starter tier only one executor per task is allowed - team mode is switched off; the Team Lead is also not available on every tier. The limits are shown on step 3 of the task creation wizard, together with a link to the subscriptions page.
Ratings
What happens if I don't leave a rating? After 7 days the system automatically assigns "excellent" and marks the rating as synthetic. Rating is mutual - the customer rates the executor and the executor rates the customer.
Work in progress
Why can't I set a milestone to 100%? Manually you can set values from 0 to 99. 100% is set automatically when the milestone is submitted for acceptance and means "the executor considers the work finished and has delivered it" - not "the milestone is closed". The milestone is closed by the customer's decision. On a return for revision the percentage drops to 99 - a marker meaning "delivered but not accepted"; the real value can be set manually.
Does the percentage affect payment or dates? No. It is a communication tool: money follows the milestone budget, the dates do not depend on it, and a milestone can only be accepted through submission for acceptance.
Who can change the completion percentage? The executor of that milestone, the task's Team Lead and the customer. The card shows who changed the value last.
Why is the overall task progress not the average of the milestones? It is weighted by budget: an expensive milestone affects the overall figure more than a cheap one.
Where can I see all the deadlines at once? In the calendar: I'm a Customer → Tasks Calendar or I'm an Executor → Work Calendar. You can view whole tasks or individual milestones.
Can I trust a link sent in the chat? Check it. Only links from the Resource links block are guaranteed - they are assembled from the system directory and marked as verified. Links in descriptions and conversations are not checked by the system. Never enter your password, PIN code or wallet seed phrase on third-party sites.
Emails and platform news
What emails does the platform send? Two kinds. Service emails are about your account, security, changes to terms and actions you need to take: they are sent to everyone and you cannot unsubscribe from them (just like password change emails). Platform news are announcements and news: only those who turned them on receive them.
How do I turn platform news on or off? Settings → Email Notifications → "Platform news". News are off by default. You can also turn them off right from an email: at the bottom of every news email there is an "Unsubscribe from platform news" link - it opens a page with one button, no login needed. Service emails and new task alerts are not affected.
In which language do announcements arrive? In the language from your profile settings. If there is no announcement in your language, you get it in English. An announcement that arrived as a notification in the bell can be opened in full on the site.
Support
Where do I write if something is broken? The Bug menu section has Send report - this is the main channel: describe the problem, attach the details, and the report reaches the platform team. Sent reports and their status are visible there too, under View bugs.
The money hasn't arrived / an operation is stuck. First check the operation history under Finances → Wallets: blockchain transfers are not confirmed instantly. If the operation has not appeared there within a reasonable time, send a report via Bug → Send report, stating the date, the amount and the token.
Statuses and navigation
Where can I find completed and canceled tasks? Completed ones are in the Completed section. From there you can move them to the Archive if the list gets long. Canceled tasks also go to the Archive and are labelled separately. Tasks under way (including paused) are in In Progress.