v0.2 | 2026-08-16

• Добавлен раздел «Ссылки на ресурсы и защита от фишинга» -->

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:

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).

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.

v0.5 | 2026-09-05

• Термин «Залог исполнителя» (EN)

v0.4 | 2026-08-28

• Тимлид: доверенное лицо заказчика; таблица приёмки в три столбца
• Токены: один кошелёк, балансы раздельные; работу можно оплатить любым
• Добавлены «Служебные этапы», «Антивирусная проверка», «Разрешение спора»
• Приостановка помечена как нереализованная
• Ранее (22.08): приёмка, системная оценка, статусы предложения, рабочий бюджет, 14 недостающих терминов -->

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.

Proposal statuses

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:

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. On their own milestone they never have 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:

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.

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:

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:

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)

Next: the «Getting started» section - first practical steps.

v0.3 | 2026-08-28

• PIN: формат, требуется при каждом входе, последствия утери
• Пополнение: QR-код

v0.2 | 2026-08-16

• Добавлена врезка про язык интерфейса и формат даты/времени -->

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:

1. Registration
2. Email confirmation
3. Account activation
4. 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.

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:

1. 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.)
2. 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».)
3. 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:

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, no funds are needed - payment comes to your balance after acceptance.

Topping up the balance:

1. Open Finances → Deposit Funds.
2. 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.
3. 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.

[скриншот: 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. Nowhere - not in the database, not in the logs. Only you know it.
• 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:

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.

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

v0.5 | 2026-08-28

• Меню пользователя приведено к фактическому составу

v0.4 | 2026-08-22

• Архив: исправлено (это завершённые, убранные из списка, плюс отменённые)
• Добавлено меню пользователя с разделом «Рефералы»

v0.3 | 2026-08-16

• Добавлены Tasks Calendar (I'm a Customer) и Work Calendar (I'm an Executor)
• Уточнено, что New Task открывает Services Catalog

v0.2 | 2026-07-16

• Приведено к актуальному меню: Task Exchange, Services Catalog, My Requests; группы "I'm a Customer" / "I'm an Executor"; добавлены Feature Requests и Legal information -->

Menu sections

This is a guide to the main menu (on the left). For each item: what the section is, what you can do there, and where to look for details.

Some items appear only after account activation. The exact set of items may vary - some sections are enabled by an administrator. Service (administrative) sections are not described in this guide.

Dashboard

The starting screen after you log in. An overview of your tasks, proposals and balance - a quick look at what's happening and what needs attention.

Marketplace

The showcase of tasks and services - where you look for work and contractors.

• Task Exchange - a feed of open tasks you can respond to (see «I am an Executor»).
• Services Catalog - services and tasks grouped by category.
• Top Services - popular and in-demand types of services.
• Top Performers - a ranking of executors with high reputation.
• My Requests - your requests to add a new category or service to the catalog (if the one you need isn't there yet). Requests are reviewed by the administration.

I'm a Customer

Everything related to the customer role - here you create and manage your tasks. A counter of active tasks is shown next to the section.

• New Task - opens the Services Catalog: there you pick a service and launch the task creation wizard.
• Drafts - tasks in preparation, not yet published.
• Open Tasks - published tasks that are collecting proposals.
• In Progress - tasks under way (including paused ones).
• Completed - closed, finished tasks.
• Archive - holds completed tasks you moved out of the Completed list, as well as canceled ones.
• All Tasks - a combined list of your tasks in all statuses.
• Tasks Calendar - your tasks as a customer laid out on a calendar. A switch shows either whole tasks or individual milestones; planned and accepted (contracted) dates are visible, along with the proposals deadline, status and completion percentage. Clicking an event opens the task.
• Inbox - messages and conversations about your tasks.

For the detailed scenario, see «I am a Customer».

I'm an Executor

Everything related to the executor role - here you find work and manage your orders.

• Find Work - go to the Task Exchange.
• My Proposals - the proposals you've submitted and their statuses.
• Active Orders - tasks you are currently working on.
• Completed - orders you have finished.
• Earnings - payment history and the funds you've earned.
• Work Calendar - the milestones you are responsible for laid out on a calendar (same logic as the customer calendar).
• Inbox - messages and conversations about your orders.

For the detailed scenario, see «I am an Executor».

Finances

Managing money on the platform.

• Wallets - your current balance (available and reserved funds) and the transaction history.
• Deposit Funds - top up your balance from your blockchain wallet.

How money and reservations work is covered in «Money and the secure deal».

Feature Requests

The community ideas section. Here you can propose a new platform feature and follow the fate of others' ideas: ideas go through voting, then fundraising, and funded ones go into development - all the way to delivery. This is how users directly influence the platform's evolution.

Bug

A section for feedback on technical problems.

• Send report - report a bug or problem you've found.
• View bugs - the list of reports you've submitted.

About Platform

Reference and information sections (ordered from introduction to details).

• About AGTI Stemneuron - general information about the platform.
• User Guide - this guide (what you're reading now).
• FAQ - frequently asked questions and short answers (see «FAQ»).
• About fees - which fees apply and what for.
• Changelog - what's new in the system.
• System Information - technical information about the platform.
• Nodes - the network map and the list of nodes (if the section is available). How the network works is described in «The network and its nodes».

Legal information

The platform's legal documents.

• Terms of Service - the rules for using the service.
• Privacy Policy - how your data is processed.
• EULA - the end-user license agreement you accept at registration.

User menu (profile icon in the header)

A separate menu in the top right corner - everything that concerns you personally.

• Profile - your details and statistics.
• Settings - account parameters.
• Referrals - the referral programme: your personal link, the participants you invited and the bonuses you earned. See «Referral programme» for details.
• My Actions - the log of your actions on the platform.
• Subscriptions - your tier and its limits (how many executors and milestones a task may have, whether a Team Lead is available).
• Notifications - alert settings.
• Logout.

Until the account is activated, Activate Account is shown instead of some of these items. Some items are enabled by the administrator and may be absent.

Collaboration

A standalone item at the bottom of the menu - a form to get in touch and propose cooperation.

Next: the role-based sections «I am a Customer» and «I am an Executor» - where every action is broken down step by step.

v0.6 | 2026-09-05

• Требование залога по этапу (EN)

v0.5 | 2026-08-28

• Даты: порядок и зависимости; служебные этапы; лимит файлов 1/10 МБ; сценарии (нет откликов, не запустили, сбой мастера)

v0.4 | 2026-08-28

• Шаг 7: устранено противоречие о моменте выплаты

v0.3 | 2026-08-22

• Приёмка: таблица прав сторон; спор открывает любая сторона
• Приёмка = немедленная и необратимая оплата этапа
• Оценки: системная вне среднего балла, окно 7 дней
• Лестница доработок, таймаут приёмки, разрешение спора, отмена задания (помечены «в разработке»)

v0.2 | 2026-08-16

• Шаги 1-4 переписаны под мастер создания задания (8 шагов, запуск из Каталога услуг): комиссия не блокирует черновик, режим/этапы/тимлид/шифрование задаются в мастере, лимиты подписки, AV-проверка файлов
• Бюджет: заявленный считается как сумма бюджетов этапов
• Остальные шаги перенумерованы (5-9 -> 3-7) -->

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:

1. Create a task in the wizard
2. Refine milestones and budget in the draft
3. Publish the task
4. Review proposals and select executors
5. Start the task
6. Accept work milestone by milestone
7. 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».

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:

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:

1. 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»).
2. Charges the fee for creating the task (the pending one from Step 1 of the wizard - currently 50 KNL).
3. 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.

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. If you change your mind and withdraw a proposal you already accepted, a penalty may apply - this protects the executor who was counting on the work. So accept proposals thoughtfully.

Step 5. Start the task

When the right executors are chosen, the task is started and 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]

From this point, executors work milestone by milestone.

Step 6. Accept work milestone by milestone

When a milestone is ready, its acceptance begins. Either side can put it up for acceptance: the executor, by submitting the finished work, or you, if you can see the work is effectively done but the executor did not press the button. That is only a record of delivery - the acceptance decision is always a separate action, and always yours.

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 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.

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:

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:

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, the task is completed and moves to the Completed section.

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.

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 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 - in team mode starting is a separate action and 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). In Solo there is no separate start: the task goes into work as soon as a proposal is accepted.
• 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:

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»

v0.5 | 2026-09-05

• Залог исполнителя по шагам 2-7 (EN)

v0.4 | 2026-08-28

• Тимлид, служебные этапы, процент выполнения (смысл и влияние)

v0.3 | 2026-08-22

• Спор может открыть исполнитель; на время спора средства заморожены
• Оплата поэтапная; таблица удержаний (95 / 5 / 2,5+2,5)
• Оценки: системная вне среднего балла, окно 7 дней
• Защита от бесконечных доработок и процедура спора («в разработке»)

v0.2 | 2026-08-16

• Шаг 5: процент выполнения этапа, календарь работ, вложения к этапу и антивирусная проверка файлов
• Шаг 6: 100 % ставится автоматически при сдаче, при возврате на доработку процент опускается до 99 -->

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:

1. Find a suitable task
2. Study the terms
3. Submit a proposal
4. Wait for the customer's decision
5. Do the work milestone by milestone
6. Submit milestones for acceptance
7. Get paid
8. Leave a rating

To do work, you don't need funds on your balance - payment comes to you after acceptance. 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]

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.

[скриншот: 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.

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 - 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.

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. (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:

• 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

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

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 %:

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 - you can withdraw, but there will be a penalty and a reputation hit.
• 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

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:

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

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:

1. 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.
2. You accept the Team Lead proposal.
3. 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.
4. 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.

A checklist shows how ready the task is: what is already done and what is still missing.

Only the Customer can start the task, whatever the permission settings.

How the work runs

• Each executor handles their own milestones.
• Acceptance happens per milestone: the executor submits it, and whoever holds the permission - you or the Team Lead - accepts the work.
• 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.
• Communication happens in the task chat.

You always see everything the Team Lead does - proposals, acceptances, disputes. Delegating a function costs you only the button for it, never the overview: otherwise two people could decide the same milestone at once.

Once all milestones are accepted the task is completed and both sides leave mutual ratings (the 7-day rule and the synthetic rating apply here too). You rate the Team Lead; executors are rated by whoever recruited them.

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:

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:

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.

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

v0.3 | 2026-09-05

• Новый раздел про залог исполнителя (EN)

v0.2 | 2026-08-22

• Оплата: таблица «событие -> что с деньгами», поэтапность выплаты
• Добавлено удержание 95/5 (и 95/2,5/2,5 с реферером) при выплате и выводе
• Три токена (USDT/KNL/AGTI) таблицей; AGTI - не только активация
• Что эскроу гарантирует и чего НЕ решает; спор открывает любая сторона
• Комиссия блокчейн-сети; отсылка к разделу «О комиссиях» вместо цифр -->

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:

1. Top up - you put funds on the balance (they are available).
2. Publish the task - the system freezes the declared budget (escrow) and takes the fee for creating the task.
3. Start the work - if the actual (working) budget differs from the declared one, the frozen amount is recalculated (re-reservation).
4. Accept milestones - for each accepted milestone the money leaves the reservation toward the executor.
5. 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:

1. 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.
2. Takes the fee for creating the task (see below).
3. 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):

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.

• 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 %:

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.

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:

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:

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

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:

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»

v0.2 | 2026-08-28

• Исправлено противоречие про пользователя чужого узла; открытые вопросы -->

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»

v0.4 | 2026-08-28

• Процент выполнения: смысл 100 %, что ни на что не влияет

v0.3 | 2026-08-28

• Гарантия оплаты: честный ответ; вывод, источник токенов, PIN, поддержка

v0.2 | 2026-08-16

• Комиссия за создание: сумма не хардкодится, добавлено «нехватка баланса не мешает создать черновик»
• Новые вопросы: подписка и лимиты, процент выполнения этапа, календари, ссылки на ресурсы -->

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.

Money

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? No. To do work you don't need funds on your balance - payment comes after acceptance. 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

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 and a reputation hit. Withdraw only when truly necessary.

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.

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.