The engine under Chesto
· Chesto · 5 min read
This started as a very practical request.
A customer wanted real people in different countries to experience a product. Not one generic global crowd, but separate groups: Pakistan, India, Ukraine, Germany, the United Kingdom, Canada, Poland, and Australia. Each country needed a small number of slots. Each worker would reserve a spot by locking a refundable stake. Later, selected workers might be asked to use the product, submit experience notes, or optionally leave public feedback.
At first glance, this sounds like an operations task.
Create some task pages. Write instructions. Put workers in a Telegram or Discord group. Answer questions. Collect proof. Pay the honest submissions.
That works when the number is small. It breaks when the work becomes serious.
So we asked a different question:
If this workflow were a car, and we stripped away the paint, the seats, the dashboard, and the marketing language, what engine would be left?
The answer was not "a review tool."
It was not "a KOL tool."
It was not "a group chat where everyone waits for instructions."
The engine was simpler:
a customer defines an action
|
v
Chesto turns it into executable tasks
|
v
eligible humans see the right work
|
v
they reserve, submit, get reviewed
|
v
stake, reward, and proof settle by rule
That is what we built.
The hard part is order
The internet has no shortage of people willing to do small pieces of work.
The hard part is making the work orderly enough to trust.
For a task publisher, the question is not only "Can I reach people?" It is: Can I reach the right people, in the right countries, with a clear budget and proof that the work happened?
For a worker, the question is not only "Can I earn?" It is: Is the task clear, are the rules fair, and will the platform distinguish honest failure from fraud?
For an investor, the question is whether this can become infrastructure instead of service work. A marketplace that depends on group chats does not scale cleanly. A system with reusable contracts, eligibility rules, escrow, proof, and settlement might.
For future us, the question is even simpler: are we building software, or are we hiding manual operations behind a nicer interface?
The boundary matters
Some requests in this category are easy to handle badly.
A customer may say, "I want App Store reviews," or "I want Trustpilot reviews," or "I want public feedback from real users." Those are common growth needs. But if a platform turns that into "pay people for positive reviews," it is no longer building trust. It is selling a shortcut that will eventually damage the customer, the worker, and the platform.
So the product boundary has to be explicit.
People can be paid to try a product. They can be paid to submit real experience notes. They can be asked to provide optional public feedback. But the reward should not be tied to a forced positive review.
Chesto is not trying to sell fake belief. We are trying to coordinate verified human action.
Why group chat was the wrong primitive
The first instinct for a messy human workflow is often a chat room. It feels flexible, but it moves the rules into conversation.
Once the rules live in conversation, they become inconsistent. One worker gets an exception. Another misses a message. A publisher cannot tell which step is blocked. An admin becomes the memory of the system.
We wanted the opposite: fewer private instructions, more public state. Who can see the task, how many slots are left, what commitment is required, and what happens after approval or fraud should all be known by the platform.
The more of this logic moves into software, the less the work depends on someone being awake in a group chat.
The new unit: ActionContract
Chesto already had tasks, submissions, proof review, balances, withdrawals, and payout logic. We did not want to create a separate product beside all of that.
So we added a higher-level layer: ActionContract.
A task is what one worker sees.
An action contract is what the publisher actually wants to accomplish.
For example:
Run a country-specific product-experience action for a customer product across eight countries. Give each country five slots. Pay workers between 5 and 15 USDC depending on the country. Require a 0.5 USDC refundable stake to reserve a slot.
That should not be eight disconnected manual tasks. It should be one action that expands into eight tasks:
ActionContract: customer product experience
|
+-- Pakistan task
+-- India task
+-- Ukraine task
+-- Germany task
+-- United Kingdom task
+-- Canada task
+-- Poland task
+-- Australia task
Each task still uses the existing Chesto machinery: task page, submission API, review, reward, and proof history. The new layer does not replace the old system. It composes it.
That is the important part. We are not building a special-case review tool. We are building a general action engine.
What changed
Tasks can now be country-aware. A Pakistan task is visible to users detected in Pakistan. A Germany task is visible to users detected in Germany. Direct API submissions are checked by the same backend rule.
Workers can reserve a slot with stake. For this action, the stake is 0.5 USDC. It is a seriousness mechanism: honest completion or honest failure can be refunded; spam or fraud can be forfeited.
We also added system_grant, so internal launches, experiments, or platform-sponsored campaigns can start without forcing a publisher to manually top up first. The escrow still has a source, a balance, and a settlement path.
And we made the region display match the backend. Security decisions belong on the server; the interface should show server facts.
Where this goes
The next layer is visibility.
An action dashboard should show each country, slots, stakes, submissions, approvals, remaining budget, and stuck review.
The next layer after that is risk.
IP country is useful, but it is not a wall. VPNs and proxies exist. A mature system should treat country as one signal among many: account history, device patterns, stake behavior, submission quality, review outcomes, and later integrity checks.
The final layer is API access.
A human publisher should be able to create an action from the web. An AI agent should be able to create the same action through an API. Workers should see eligible tasks in the app. Review, refund, reward, and proof should all use the same underlying flow.
That is the long-term shape:
one action in
real humans execute
the platform verifies
money moves by rule
proof remains visible
This is the engine under Chesto.
Not a review tool. Not a campaign spreadsheet. Not a chat room pretending to be software.
A way for projects, agents, and eventually any buyer of real-world work to ask for a human action and get back something structured: eligibility, commitment, proof, and settlement.