First commercial TOKN deal

This is an experiment specification, not a shipped service, price promise, funding authorization or claim of adoption. The target is a useful task bought by an external participant and settled in native production TOKN under terms both parties accepted. TEST balances and payments to our own wallets do not meet that target.

Apply the commercial economic decisions before another sales experiment. The buyer's budget must be independently controlled and project subsidies disclosed. Giving someone TOKN to purchase our own service does not establish independent demand or satisfy this target.

Likely reasons to decline

These are hypotheses to test with counterparties, not established survey results.

• TOKN cannot currently be promised as payment for compute or converted into

money. A worker may prefer an asset their suppliers already accept.

• The operator controls the bootstrap network. Escrow code does not remove

that trust requirement or prove independent arbitration.

• Installing a node and joining a validator cohort is much more work than

buying a small service. Neither is a prerequisite for an ordinary transfer.

• A delivery hash proves which bytes were submitted, not whether they satisfy

a buyer's needs. Ambiguous acceptance makes even a small task unattractive.

• Treasury rewards demonstrate spending by the project, not customer demand.

First experiment: a bounded artifact review

Offer to review one small, public UTF-8 artifact and its acceptance rules. The scope can include byte count, normalization, hash, agreed glossary rules and one negative fixture. It excludes executing downloaded code, confidential inputs, a general security audit and a guarantee of semantic correctness. Ask the buyer which concrete failure this prevents before fixing a price.

Initial quote for discussion

Propose 10 native TOKN gross for one public text artifact up to 8 KiB, one acceptance checklist and one negative fixture. This is our proposed service price, not an observed market price or a cash conversion. At full AgentEscrow settlement the worker receives 9.9 TOKN before their separate gas costs.

The output is a short report with the checked bytes/hash, explicit normalization and glossary rules, a pass/fail/unknown result for each agreed check, and one counterexample showing a rejected delivery. Finding no defect is a valid result if the agreed checks are performed and evidenced. Include one correction of the report against the checklist; a new input or broader review is a new quote.

Local report preparation

The source tool scripts/artifact-review.mjs prepares reproducible literal and glossary word-form checks for this scope. It takes a local UTF-8 input, a JSON checklist and a new output filename. It does not fetch URLs, execute the input, sign or settle a job.

node scripts/artifact-review.mjs INPUT.txt CHECKLIST.json REPORT.json

The command exits 0 whenever a report is written, including a fail or unknown report; read allChecksPass in the output. A gate that can only read the exit status should add --exit-code, which exits 2 for any report that is not an all-pass and 1 for an error.

The checklist uses schema tokn-artifact-checklist/1, inputSha256 (lowercase SHA-256 of the original bytes), explicit normalization (none, NFC or NFKC), and 1–100 checks with distinct id values. A literal check has a kind of contains or excludes, and a nonempty literal text. Matching is case sensitive; agreed normalization applies to both input and literals. The input limit is 8192 bytes, and malformed UTF-8 or a changed input commitment is rejected. The CLI bounds input reads before parsing, accepts regular files only, and limits the UTF-8 checklist to 1 MiB. Only the named fields are supported; extra conditions are rejected rather than silently omitted from a passing report.

A literal contains check is a plain substring test: the term счёт also passes inside расчёт or счётчик. Use it for exact phrases, not glossary words. For glossary terms, agree a form check before the run: kind is containsForm or excludesForm, forms lists 1–50 accepted word forms (each up to 256 bytes), and the required booleans caseFold and yoFold record whether comparison uses the locale-independent Unicode lowercase mapping and treats ё/Ё as е/Е. A form matches only as a whole word: an adjoining letter of any script, combining mark or digit makes it part of a longer word, while spaces, punctuation and hyphens are boundaries, so счёт-фактура contains счёт. Each form must start and end with a letter, mark or digit; a multi-word phrase such as окно доставки is allowed. Forms must stay distinct after folding. caseFold is the Unicode lowercase mapping, not full case folding: ΟΔΟΣ becomes οδος with a final sigma, so agree the forms as they appear after lowercasing. Invisible format characters such as a zero-width joiner, zero-width space or soft hyphen make a word boundary ambiguous: a form check rejects them in forms and in the text, except a leading byte order mark. yoFold requires NFC or NFKC normalization, because otherwise a decomposed е plus U+0308 would escape the folding. It also merges distinct words such as всё and все, so choose it per glossary rather than by default. The tool lists only the forms you agree; it does not infer morphology.

A hyphen is a word boundary by default, so счёт-фактура passes a счёт check even though it is another lexeme. To route such cases to a person, add the optional hyphen field with the value ambiguous (the default is boundary). Then a form touching a hyphen-minus, U+2010, U+2011, U+2043, U+FE63 or U+FF0D is counted apart (hyphenatedCount, firstHyphenatedCodePointOffset) and is never a clean occurrence. A containsForm check with no clean occurrence and at least one hyphenated one has the outcome unknown; excludesForm behaves the same way. A clean occurrence decides first: Счёт оплачен, счёт-фактура приложена. still passes containsForm and fails excludesForm. unknown makes allChecksPass false, so a pipeline that reads only that flag blocks the delivery until a person decides. A dash such as — stays a boundary. A form list also has a ceiling: счёты (abacus) is the same word form of a different lemma, and no boundary rule separates it, so agree an exclusion list or a manual review.

{"id": "glossary-account", "kind": "containsForm",
 "forms": ["счёт", "счёта", "счёту", "счётом", "счёте"],
 "caseFold": true, "yoFold": true, "hyphen": "ambiguous"}

With NFC normalization this check passes Баланс счёта не изменился. and fails Расчёт завершён.. A form check reports the folded-text digest, whether any form is present, and each form's folded value, count and first code point offset in the folded text.

The report records original and normalized digests, the result and observed presence of each literal. checklistSha256 hashes UTF-8 JSON.stringify of the parsed checklist; it is not the hash of its original file formatting. The report refuses to overwrite an existing output. allChecksPass concerns only these literal and form rules: it does not establish semantic correctness, buyer acceptance, independent review or payment. An agreed negative fixture must fail its relevant rule even if it contains every expected report heading. This local tool is not an automated service or evidence of a completed order.

Propose delivery within 24 hours after both parties accept the complete terms and verify the funded offer. There is one initial order slot; no job is booked by merely posting interest. A willing buyer, authorized funding, consenting arbitrator and verified signing/settlement path must be resolved before this quote becomes an accepted job. Do not advertise it as an automated checkout.

Before work, save an agreement containing buyer and worker identities, network, asset, amount, payee, input commitment, exact checks, output format, deadline, acceptance authority and dispute/refund path. Do not advertise guaranteed escrow funding, gas sponsorship or a settlement feature until it is verified on the named deployment. Any outgoing project payment needs existing explicit authority and a bounded budget.

For a native TOKN agreement, ask what the recipient intends to buy with TOKN. A separately agreed useful service accepting TOKN could test spending utility; it does not establish cash redemption, an exchange rate or a standing obligation to supply unlimited services. Do not create a funded job until the chosen path and the parties' authority are verified.

If the buyer only wants another asset, preserve that choice and record the reason. A paid task on another chain is commercial research, not a completed TOKN settlement experiment.

Before inviting someone to sign

Use this negotiation checklist before producing an on-chain terms pack:

The existing acquisition path is a manually approved contribution grant, not a purchase facility. Its curator-paid receipt does not sponsor later worker transactions. Do not ask a new buyer to do unrelated unpaid work just to discover whether they can pay for the service. Record missing initial funds as an acquisition blocker, and negotiate a separately authorized funding route before work. No grant approval or project payment is implied by a sales reply.

Use the deployed AgentEscrow rules for a compatible agreed job. This worksheet is not a transaction pack; do not hash incomplete terms or invent addresses and deadlines to make it look ready. A browser-wallet route and a local signing route already exist, but each participant decides what they are authorized to install or sign. Owning a validator node is not required.

Evidence and stop conditions

Record offers, explicit refusals and agreed prices separately from posts and downloads. Completion requires the external parties' accepted terms, delivered artifact, acceptance decision, canonical on-chain settlement and independently verified receipt by the payee. Disclose who controls the network and acceptance.

Do not count a free task, treasury grant, TEST transfer, unpaid invoice or a transaction between operator-controlled accounts as the commercial result. If no one accepts TOKN, improve a concrete spending use or reduce friction based on the stated refusal; do not respond by manufacturing transactions or assuming another release will create demand.