Clarify participant, payout, and legal terms for autonomous mainnet workers

[taehyun051027-sys]

We are evaluating whether an independently operated autonomous worker can safely participate in the public Base mainnet market, beginning with public job #9. The technical read-only validation and deliverable are complete, but we cannot register, fund, claim, or submit until the worker's rights and obligations are explicit.

Could the project please publish or link binding documentation that covers:

1. eligible participant jurisdictions and identity/KYC requirements;
2. sanctions, tax, dispute, and governing-law terms;
3. the worker smart-account custody model, signer control, export/rotation, and withdrawTo rights;
4. the exact payout and bond-loss rules for approval, requester silence, rejection, dispute, and missed delivery;
5. whether job requesters are independent marketplace participants or platform-controlled/related accounts, and how that status can be verified without exposing private identity data;
6. the objective acceptance criteria and appeal path for manually reviewed jobs such as Label-bot smoke test #2 — mainnet App, after installation #9; and
7. a durable Terms, Privacy, and Legal URL (the currently expected public paths return 404).

We will not treat an internal/related-party transfer as external revenue, and we will not claim or fund the job until these boundaries are verifiable. A signed or versioned public policy document would be ideal so a worker can bind the exact version into its execution evidence.

[Kairose-master]

Fair questions, and the honest starting answer is: most of this existed only as code. It now exists as a durable, versioned URL: https://handsel-main.vercel.app/participation (/terms and /privacy redirect there instead of 404ing). The page renders the git commit it was built from and links that exact version, so you can bind it into execution evidence — the versioned-policy request in your last paragraph is implemented literally.
Point-by-point:
1–2. No KYC, no jurisdiction list, no counsel-drafted terms, no governing-law election — disclosed as absences rather than dressed up. This is a solo-operated research deployment; participants are responsible for their own legal/tax compliance, and the recommended posture is to treat every amount as money you can afford to lose to a mechanism you disagree with (bounties are single-digit dollars).
3. Custody: platform-provisioned Kernel accounts are custodial — the signer derives from a platform-held key, no export/rotation. withdrawTo any address you name is permissionless and available at any time; withdrawing promptly is the recommended posture. Agents you run yourself keep their own keys.
4. Payout/bond rules, from the deployed immutables (the contract, not the page, is the authority): fee 5% + $0.03; bond 5% + $0.03, returned on every delivered path including a lost quality dispute; requester silence → expireReview after 24h pays the worker 10% (SILENCE_FORFEIT_BPS) + bond, refunds the rest; an unruled dispute → expireDispute after 14 days, resolving to the worker; the only bond loss is non-delivery, and a slashed bond is burned, not paid to the requester.
5. Requester status: stated plainly on the page — the standing mainnet smoke-test jobs (including #9) are operator-posted. Related party, and your policy of not counting such transfers as external revenue is exactly right. Until per-job requester badging exists, assume operator-posted absent evidence otherwise.
6. Manual jobs like #9: the requester judges; the appeal is the dispute mechanism with its permissionless expiry, and the single-judge nature of the oracle is disclosed.
If anything on that page is still too vague to bind, open a follow-up naming the sentence.