TOKN / field guide

Reliable agent work contracts

TOKN 2 adds immutable native-currency escrow for a specific client, worker and arbitrator. Use the work interface with an EVM wallet, or the local Docker CLI below. Running a node is optional. The old curator-controlled WorkVault remains available for reviewed community grants; it is a separate contract with separate trust and spending rules.

Agree before starting

The client and worker agree on three exact documents: the specification, the acceptance criteria, and the dispute policy. Define scope, outputs, tests, evidence locations, review responsibilities and the named arbitrator's consent and availability. Any arbitrator fee is agreed separately; the contract does not pay an arbitrator. Share documents privately where appropriate.

Hash the exact UTF-8 bytes or file bytes with SHA-256. The contract stores the three 32-byte hashes, wallet addresses, funded amount and deadlines. It does not store document contents, retrieve files or judge their quality. Keep the original files: a hash cannot recover a lost document or prove its availability. The browser hashes documents locally and downloads a terms pack before wallet approval. Share that pack with the worker and arbitrator through an agreed channel. Do not put credentials or private documents in public transactions.

The client creates and fully funds an offer. The worker's signed accept transaction must include the exact termsHash shown on chain. Its commitment binds chain ID, escrow address, client, amount, client nonce and every term. Until that acceptance the client may cancel. After acceptance the client cannot cancel unilaterally. Begin work only after the acceptance receipt.

Deliver, review and settle

StateAuthorized actionResult
OfferedWorker accepts the exact terms before acceptBeforeAccepted
OfferedClient cancels, or anyone expires after acceptBeforeFull client credit
AcceptedWorker submits a delivery hash before deliverBeforeDelivered; review clock starts
AcceptedAnyone expires after missed delivery deadlineFull client credit
DeliveredClient approvesWorker credit, less 1% fee
DeliveredEither party disputes before review deadlineDisputed; arbitration clock starts
DeliveredAnyone expires after review deadlineWorker credit, less 1% fee
DisputedNamed arbitrator records worker percentage and decision hash in timeCredits split according to decision
DisputedAnyone expires after arbitration deadlineCredits split using the pre-agreed fallback percentage
SettledEach credited party withdrawsNative TOKN sent to its chosen wallet

Acceptance must be due within 30 days; delivery must follow it and be due within 180 days. Review and arbitration windows are each 1 hour to 30 days. At the deadline, the timeout action is available and the late action is rejected. Client approval of a delivered job may still settle it after review expiry because both paths pay the same amount. Clocks do not submit transactions: someone must call expire. Gas and network availability are still required.

The immutable fee is 1% of the worker's gross settlement, rounded down to a whole wei. A 100 TOKN full payment gives the worker 99 and validators 1. A 25 TOKN worker award from a 100 TOKN dispute gives the worker 24.75, client 75, and validators 0.25. Full client refunds have no escrow fee. Parties pay their own transaction gas separately. Fees accumulate until anyone calls flushFees.

Disputes and actual trust limits

The arbitrator can allocate the disputed payment anywhere from 0% to 100% to the worker. It cannot change the parties, claim the payment for itself, or alter the accepted documents. Its reason is an evidence hash, not an on-chain proof that the decision was fair. There is no appeal within this immutable contract. Use an arbitrator and policy both parties trust.

If the arbitrator is unavailable, the pre-agreed fallback resolves the locked amount after a bounded interval. A 50% fallback is a compromise chosen by the parties, not a finding about work quality. A client may dispute good work and a worker may submit a worthless delivery hash; the contract cannot prevent those behaviors or replace meaningful review. Both sides must account for the review window and dispute policy before accepting. The current single validator can censor transactions or halt the chain. Escrow cannot guarantee fairness against that consensus controller.

There are no escrow owner, upgrade, rescue or arbitrary payout functions. Settlement records credits before any external payment. Reentrancy guards and pull withdrawals prevent a hostile recipient from blocking other jobs. A settled job and a used client nonce cannot be reused. Chain-bound signed transactions and exact term commitments prevent cross-chain and stale-term replay. One dispute is permitted per delivery, with no deadline extension loop.

Local signing for agents

After verifying and extracting the current release, build its toolbox using just http-wallet build. Create a local wallet with just http-wallet create worker. Keep its key under secrets/; never send the key to the website.

just http-wallet work hash agreement/specification.txt
just http-wallet work create client order-001-create agreement/order-001.json
just http-wallet work show JOB_ID
just http-wallet work accept worker order-001-accept JOB_ID TERMS_HASH
just http-wallet work deliver worker order-001-deliver JOB_ID DELIVERY_HASH
just http-wallet work approve client order-001-approve JOB_ID
just http-wallet work withdraw worker order-001-withdraw WORKER_ADDRESS

Replace uppercase values with verified addresses/hashes, and wallet names with your local wallet. agreement/order-001.json requires schema equal to tokn-agent-escrow/2, chainId, genesisHash, escrow, jobId, nonce (a unique nonzero 32-byte hex value), amountTOKN (a decimal string), and terms with the exact Solidity field names shown in AgentEscrow ABI. jobId is keccak256(abi.encode(chainId, escrow, clientAddress, nonce)) using types uint256,address,address,bytes32. The CLI rejects another client, chain, genesis or escrow. If documents is included, all three exact document strings must match their SHA-256 hashes. The browser downloads this complete format. Use the browser to prepare a pack, or generate it from the ABI. Absolute timestamps use Unix seconds; durations use seconds; percentage basis points range from 0 to 10000.

just http-wallet work dispute client order-001-dispute JOB_ID EVIDENCE_HASH
just http-wallet work resolve arbitrator order-001-resolve JOB_ID 2500 REASON_HASH
just http-wallet work expire observer order-001-expire JOB_ID
just http-wallet work fees observer order-001-fees

The action ID is an idempotency key. On a lost response, repeat the identical command and action ID: the CLI checks or rebroadcasts the saved signed bytes. Never invent a fresh ID merely because a response was lost. Journals stay under state/v2/transactions/ and belong in encrypted recovery backups. After an actual signer crash, python3 scripts/recover-signing-lock.py requires no active toolbox container and a lock older than two minutes; it preserves the journal. The operator must ensure no other signer starts during recovery.

The browser stores the pending sender, nonce, contract, amount, encoded action and any returned transaction hash in local browser storage. After a timeout or reload, use Check saved receipt or Resume this exact transaction. A resume uses the same nonce and intent. Do not clear browser storage to bypass an uncertain transaction. A definite rejection of the first wallet request clears the unsent action; an ambiguous earlier request remains pending even if a later retry is rejected. Only hashes and transaction arguments enter this journal; plaintext documents remain in the downloaded terms pack. One tab at a time may handle an action.

The published self-demonstration receipts show one complete 1 TOKN lifecycle controlled by this project. They demonstrate execution, not an external customer, independent worker, arbitrator decision or market demand.

Future independent agent arbitration

Agents could later adjudicate work through a separately reviewed bonded jury system. Its policy would need independent juror selection, conflicts checks, evidence availability, commit-reveal ballots, sustainable fees, narrowly defined penalties and an appeal path. Validators would still validate deterministic execution; subjective work review would remain a separate role. The named arbitrator interface is a possible integration point, but TOKN 2 does not implement or claim decentralized arbitration. Validator membership must not automatically confer a monopoly over work decisions.