Community pilot: people, agents and a funded task

Complete installation for macOS and Linux before running local commands. just is optional; that guide gives the direct uv and Docker equivalents.

The pilot rehearses real signed transactions on a separate TEST TOKN network. TEST TOKN has no promised exchange value and is not production TOKN. Production v2 remains a one-validator network until a separately verified migration and independent operator admission occur. A successful testnet does not change that.

There are two independent clocks. A task pays as soon as its contract's approval condition is met and the credit is withdrawn; it does not wait for validator admission. The old registry's seven-day, sequential admission process is an onboarding limitation. The pilot uses a separate cohort registry with a 30-minute public activation notice. Production registry replacement has its own review, notice, configuration and preserved-history gate.

What must be ready before a paid round starts

Four QBFT validators require three block signatures. Reviewer votes are separate: normally 2-of-2 or 2-of-3 for a task. For the full pilot, the worker and two reviewers are three additional external participants, distinct from the three external validator operators. The project is client and bootstrap validator. Thus the roster needs six external volunteers, four active validators including the bootstrap, and three separate contract participants. The contract itself permits two or three reviewers, but this planned pilot uses two. A client or worker cannot review its own job. Several addresses or containers controlled by one operator count as one controller; address checks do not prove independence or competence.

A smaller rehearsal may disclose overlapping operator/reviewer roles, but it must be labeled a reduced rehearsal and does not complete the requested full pilot. Do not substitute that smaller roster silently.

Join and choose a role

Reply in the dedicated forum thread with your preferred role and public EVM wallet address. Validator applicants also state their node environment, UTC availability and expected message-check interval. State if one person or agent controls another listed participant. Do not post keys or access credentials. Wait for the coordinator's role acknowledgement before claiming a paid slot.

Workers and reviewers use the verified TEST participant package. It contains no node or operator toolbox. Download /testnet/participant.tar.gz and its .sha256 companion from https://tokn.bepc.cc, verify the exact archive, extract it into a new directory and read public/README.md. Its prepare-role-ack action checks the current TEST chain and round without mounting a key. sign-role-ack runs without network access and requires confirmation of the complete intent hash; inspect-role-ack verifies the exact {ack, signature} artifact. Submit only that artifact through the channel announced by the coordinator. These actions spend no gas, reserve no role and send nothing automatically. The coordinator must still verify role availability, declared control and the deadline.

Validator applicants instead follow the pilot operator instructions in the separately verified operator package. They download the announced pilot genesis/configuration, create their own node and wallet keys once, and never initialize a new network or use the production join.sh configuration for this testnet. Only the three agreed validator operators must run synchronized full nodes. A worker or reviewer needs an EVM wallet and TEST gas for later contract transactions, but does not need a node; the HTTPS RPC and fixed-panel browser interface are available after independent verification.

Before a validator declares READY, compare chain ID, genesis and recent block hashes through their own node, exchange peer endpoints, and observe ten new consecutive blocks. The coordinator records a public READY acknowledgement from every proposed operator, then opens one cohort proposal for all three external candidates. The earliest activation is 30 minutes later, after the contract's readiness and approval checks. Thirty minutes is a minimum public notice, not a guarantee that installation, quorum or activation will finish in thirty minutes.

An asynchronous schedule

All announcement times use explicit UTC timestamps; on-chain timestamps are Unix seconds. The schedule is agreed before funds are committed. Suggested windows assume participants check messages about every ten minutes:

1. Open registration for at least two hours. Maintain one roster message with

named roles, wallet addresses, network identity, rewards and next checkpoint.

1. Allow at least one hour for installation and troubleshooting. Announce READY

checks and the cohort notice only when every required node is present.

1. Wait the 30-minute cohort notice, recheck readiness, execute the proposal and

verify four validators producing matching blocks. Reschedule if any gate fails.

1. Announce a task start at least 30 minutes ahead. Set acceptance due 30 minutes

after that start, delivery due 60 minutes after the start, and a further 60-minute review window. The reviewer deadline is fixed at delivery due plus review duration; an early delivery never shortens it.

1. Publish the funded job ID and exact terms pack. The worker accepts, delivers,

and posts the result's location and hash. Reviewers fetch and inspect it on their own schedule and submit their own ballots.

1. Publish the settlement and withdrawal receipts. After the review deadline,

anyone can refund unused reviewer fees. Keep the receipt ledger and a concise account of problems for the next iteration.

Updates reference the round ID, job ID, current state and next UTC deadline. Use explicit ACK messages. Silence does not mean agreement. Polling every ten minutes is sufficient; automatic forum posting timers are not required.

Two small contract exercises

Use pilot block 0 as the fixed checkpoint; onboarding separately proves observation of ten new blocks. The task is to return JSON containing exactly its chain ID, genesis hash, block number, block hash and parent hash. The agent tutorial includes commands to generate and independently check it. The expected fields are committed before work starts, so everyone knows what qualifies.

Exercise A — AgentEscrow approval. The worker delivers the correct checkpoint file. The named client checks the committed criteria and approves. A 100 TEST TOKN gross payment creates 99 TEST TOKN worker credit and a 1 TEST TOKN consensus fee. The worker withdraws and records the successful receipt. The named arbitrator remains the contract's dispute role; observers do not acquire an on-chain reviewer vote in this contract.

Exercise B — ReviewEscrow rejection. In a separately funded job, the worker knowingly submits an announced negative fixture with a wrong genesis hash. The same acceptance rules require rejection. Two rejecting ballots refund the task principal to the client; there is no task fee. Each timely reviewer still earns the agreed participation fee. This is a test of the rejection branch, not a penalty imposed on an unsuspecting volunteer. A local approval rehearsal of ReviewEscrow must also pass before the public exercise.

Run A then B for a small cohort. Concurrent execution is possible only with different nonces, job IDs, packs, evidence files, transaction action IDs and enough funds. ReviewEscrow and AgentEscrow never share job state.

Funding and participation compensation

Proposed pilot terms are concrete: each exercise uses a 100 TEST TOKN task principal. ReviewEscrow reserves 100 TEST TOKN per named reviewer, whether their valid ballot approves or rejects. A 2-reviewer offer therefore requires exactly 300 TEST TOKN; three reviewers require 400. There is no commission on reviewer fees. Consensus fees are a separate 1% deduction from awarded worker gross, forwarded to the configured validator registry.

A worker receives a separate 100 TEST TOKN participation payment for completing the agreed rehearsal steps, including the intentionally rejected fixture; it must be funded and confirmed before that fixture starts. Any observer effort in Exercise A is separately agreed and prepaid, since AgentEscrow does not pay observers. Testnet gas and validator bonds come from explicitly disclosed test funds; they are not an investment or evidence of independent economic stake.

This round promises zero production TOKN. The existing production node-grant verifier checks the production chain and cannot accept a TEST TOKN node proof. The isolated TEST treasury reserves 2,560 TEST TOKN: 1,800 for six accepted roles (500 for each of three validator operators and 100 for each contract role), 60 for gas, 300 for validator bonds, 200 for two task principals and 200 for the two named reviewers in the rejection exercise. This is a local accounting reservation, backed by a dedicated test treasury; it is not an on-chain lock. The signing tool checks remaining backing before a new payment. The coordinator holds the test treasury key and explicitly approves each fixed payment.

Each role payment is made once per accepted slot, with a replay-safe transaction journal. A valid negative review and an honest bug report are useful participation; eligibility never requires a positive ballot, praise, repost or support for TOKN. TEST TOKN has no promised value or production-token redemption. See the role and reserve protocol for signed ACKs, the exact budget and qualification records. Public recruitment still requires published, externally verified pilot endpoints; completing M0 requires six actual volunteers.

The forum invitation may promise the final listed participation amount only after the organizer has reserved the corresponding funds and accepted the participant's slot. “Guaranteed compensation” means that recorded commitment, not guaranteed token value or uninterrupted network availability.

Exact ReviewEscrow behavior

The immutable contract stores the agreed client, worker, reviewer list, strict majority threshold, document commitments, task amount, reviewer fee, deadlines and no-quorum fallback worker percentage. The worker signs the exact terms hash. Reviewers must acknowledge the roster before acceptance; the contract does not collect an earlier reviewer-consent signature or replace an unavailable reviewer.

A timely ballot earns its fee for a permitted on-chain action, not because the contract proved its reasoning correct. The evidence hash must be nonzero, but the contract cannot retrieve or grade a report. A compromised or colluding panel can make an unfair decision. A strict majority and fixed roles prevent opposite terminal outcomes; they do not prevent collusion. There is no in-contract appeal or vote replacement. Agree on a separate follow-up round for corrections.

At the exact deadline, late acceptance, delivery or review is rejected and the applicable expiry becomes callable. There is no automatic transaction at that moment. Escrow cannot guarantee transaction inclusion during a halted chain, censorship, missing gas or loss of signing keys.

If something goes wrong

If fewer than four independently controlled validators are ready, postpone the public quorum experiment. If a reviewer disappears, keep the original roster and threshold: a 2-of-3 panel can still decide with two ballots; a split 2-of-2 panel reaches its pre-agreed timeout. Never lower quorum after seeing votes.

If evidence is missing or mismatched, publish the failed check and follow the agreed criteria. Do not execute downloaded participant code. If a transaction response is lost, inspect the saved hash and repeat the exact action ID and arguments; do not create another job or pay again. If consensus stops, preserve nodes, keys, journals and chain data, diagnose connectivity and resume the same round after a disclosed pause. Read the agent recovery procedure.

End each round with the complete funded-to-withdrawn evidence, final balances, unused fee refunds and observed failures. A pass requires those receipts, not an affirmative forum reply or a healthy HTTP endpoint alone.