TOKN future plans

Reviewed on 2026-09-07, Europe/Berlin. This is a prioritized engineering plan, not a release announcement or a claim of protocol compliance. A milestone is complete only when its acceptance evidence is published with the tested source version.

TOKN is a native agentic token: the native gas and payment asset of its own chain, designed for machine-verifiable agent agreements, escrow, recorded validator decisions and programmatic interaction. The token is not itself an agent. Contract execution does not establish subjective work quality, independent operators or market value.

The target is a more complete, verifiable path from user permission to an agent's work, evaluation, payment and recovery. Progress will be measured by interoperability tests, bounded authority, recoverable failures, independent operation and actual resource use. Having more features, another token or a private demonstration is insufficient to establish that TOKN is more advanced than another system.

Starting point

Production v2 has native transfers, a funded WorkVault for curator-approved grants, immutable AgentEscrow, a bonded QBFT registry and an explorer. Escrow binds exact terms and delivery commitments, funds work before acceptance, and provides approval, dispute, expiry and pull-withdrawal paths. Signed transaction journals preserve exact bytes on retry. Production still has one validator controller and no verified independent operators.

The unpublished v3 candidate adds ReviewEscrow with a fixed panel, strict-majority decisions, equal ballot fees, deterministic no-quorum terms, isolated wallet signing and a separate TEST TOKN cohort network. Its claim queue saves requests for manual review; it does not pay or prove ownership. The local wrapping prototype is operator-attested and test-only. None of these preparation results establish a completed external pilot, production migration or liquid market.

Current gaps include standard agent discovery, delegated user authority, a common task transport, a general evaluator marketplace, portable reputation, selective disclosure, sponsored escrow actions, standardized payment transport and independently secured cross-chain settlement.

What the comparison establishes

These systems address different layers. The table compares declared protocol capabilities with the current TOKN implementation; it does not rank adoption or security from vendor marketing.

The old Virtuals whitepaper paths for the ACP v2 primer and architecture moved during this review. Historical v2 accounts and notification-memo ideas remain design inputs; current implementation claims must be checked against the maintained source. No legacy package installation is proposed.

Architecture boundaries

The canonical job identity is the tuple of chain identity, escrow contract and job ID. Every task, mandate, delivery, ballot, payment receipt and reputation reference must bind to that tuple and its terms commitment. Indexes are reconstructible views; finalized contract state is authoritative for liabilities.

Priority 0: finish the v3 and independence gates

Complete the dedicated TEST TOKN pilot before production registry replacement. Require four independently controlled active QBFT validators: our bootstrap plus three external operators. The full requested pilot also needs three distinct external contract participants: one worker and two reviewers. Disclose overlap in any reduced rehearsal and do not count it as completion of the full pilot.

Use the testnet's 30-minute cohort notice only on its separate chain, keys, data and ports. Keep the production migration's reviewed notice and preserved-history transition separate. A short task can settle as soon as its approval or reviewer threshold transaction confirms; it does not wait for validator admission.

Acceptance evidence: all four nodes report the same finalized blocks and validator set; the three surviving validators continue after the bootstrap is offline; restart and recovery retain genesis and earlier hashes; the full participant cohort completes an accepted exercise and a rejected exercise with actual withdrawals, fee accounting and documented asynchronous recovery. Record exact controllers, role acknowledgements and economics. Production deployment still requires separate review and a preserved-history rehearsal. Existing v2 jobs and addresses remain usable.

Priority 1: authority and standard settlement profiles

User-to-agent mandates

Introduce a separately reviewed authorization contract using EIP-712 typed signing. Bind the user, agent session key, chain, verifying contract, asset, permitted recipients, contract selectors, terms or offering commitments, per-job limit, cumulative budget, validity window, nonce and revocation epoch. Typed signing supplies a signing format; the new contract must implement replay protection and spending policy.

Reserve budget atomically when a job is funded. Never allow two simultaneous requests to each spend the same remaining budget. Define precisely when refunds restore available budget. A user can revoke future spending immediately after the revocation transaction confirms; revocation cannot silently cancel liabilities already accepted by a worker.

Allow delegation only through an explicit parent mandate that permits it. Child scope and budget must be no broader than the parent, with a bounded depth and revocation inherited from every ancestor. AP2 v0.2 does not specify this agent-to-agent delegation layer. Treat it as TOKN-specific research until tested independently. An AP2 adapter must verify its real mandate formats and preserve checkout/payment receipt links; rebranding an EIP-712 message is not AP2 compliance.

Acceptance evidence: cross-chain/contract replay, wrong recipient, changed terms, expired authority, revoked parent, concurrent overspend and unauthorized delegation all fail before payment. A deterministic trusted interface displays the full monetary scope before user approval. Publish conformance vectors and a simulated compromised-agent run with a proven maximum loss bound.

ERC-8183 compatibility without competing ledgers

Native TOKN is not ERC-20. For new compatible jobs, evaluate a same-chain 1:1 wrapped payment adapter and a strict ERC-8183 settlement kernel. A same-chain wrapper is separate from a cross-chain bridge. Keep one contract authoritative for funding and terminal outcomes; an evaluator adapter can translate an approved panel result into the kernel's evaluator action without holding another copy of the principal.

Legacy contracts remain immutable. A read-only facade may expose legacy state, but must label non-equivalent states. The draft's full-refund expiry cannot be represented as equivalent to a worker-paying timeout or a partial dispute split. Do not synchronize two writable escrows or force old jobs into a new lifecycle.

Acceptance evidence: a pinned draft revision and normative transition matrix; differential tests against a reference implementation; failed hooks and token transfers preserve liabilities; one accepted decision causes exactly one terminal settlement; unauthorized evaluator calls and duplicate adapter events fail. Publish exceptions and supported token behavior before using the word compatible.

Priority 2: transport, discovery and payment interoperability

x402 exact payments, then batching

Add a versioned TOKN binding with CAIP-2 network identity, exact atomic units, explicit asset/recipient and a documented supported transfer method. Start with a funded deterministic API response. Keep read-only verification separate from state-changing settlement, with a facilitator that returns a confirmed receipt or an explicit pending/failure result.

Bind each payment intent to the resource and request identity. Persist the settlement intent before broadcast and return the same result on retry. A delayed settlement receipt must not authorize a second debit. Define resource execution ordering and refund conditions; do not treat x402 payment verification as proof of subjective work quality.

Only add batch settlement after measuring the exact path. Specify the prepaid ceiling, allocation of failed items, receipt commitments, settlement deadline and permissionless recovery if the collector stops. Acceptance: two independently implemented clients pass the pinned schema/transport vectors; 1,000 duplicated or reordered requests produce no duplicate debit; a batch's item totals equal its ledger movement and an unavailable collector cannot lock funds indefinitely.

A2A and offering schemas

Publish an AgentCard only when its declared endpoint, authentication and capabilities work. Map an A2A task to a canonical job reference; retain distinct task-completion and payment-settlement fields. “Completed” computation must not imply paid funds. Cancel requests report whether cancellation is still permitted by the funded agreement.

Begin with durable polling and cursors suited to participants who check every ten minutes. Add streaming and push only with authentication, deduplication, backpressure, expiration and recovery from a missed delivery. Arbitrary webhook URLs require an explicit SSRF defense and registration policy. Keep private artifact access separate from a public hash.

Support domain-specific, versioned offering schemas and read-only resources. Freeze the accepted schema hash in the agreement. Account relationships and notification memos may reference earlier jobs, but cannot alter their payment terms after acceptance. Acceptance: two external A2A clients discover a working offer and complete a job; a twenty-minute offline interval, duplicate notification, worker restart and dropped response recover to the same job without repeated payment.

ERC-8004 references and reputation

Record chain/registry/agent identifiers, wallet authorization and key rotation. Link feedback to an actual funded job and evidence receipt; distinguish rejection, timeout, dispute and approved delivery. Preserve reasons and appeals so a late correction does not erase the audit trail. Filter by reviewer provenance and disclose the weighting method. A hundred related identities must not be presented as a hundred independent recommendations.

Acceptance: a third-party reader resolves the identity and outcome reference, verifies the receipt and detects a revoked or mismatched authorization. Adversarial self-dealing and repeated low-value jobs must not improve the independent-reputation score without a separately justified policy.

Priority 3: an evaluator marketplace with bounded failure

The current fixed panel is a useful baseline, not an open evaluator market. A future market needs a funded evaluator registry, capability-specific qualifications and explicit conflict rules excluding the client, worker and disclosed related controllers. Consensus validator operators may also evaluate only when the relevant pilot or market policy permits that overlap and it is disclosed.

Select evaluators after the work commitment using an independently verifiable source of unpredictable randomness. A single bootstrap block producer cannot supply meaningful independence for this purpose. Selection, replacement and failure deadlines must be committed before funding; a coordinator must not reroll until a favorable panel appears.

Use commit-reveal ballots bound to job, delivery and evidence, with fees equal for accept and reject. Pay for a timely valid contribution, not agreement with the majority. Penalize only objectively provable protocol faults under accepted rules; a differing opinion alone is not slashable. Model bribery, correlated evaluators, fabricated identities, unavailable evidence and collusion explicitly.

Reserve appeal funds in advance. An appeal uses a distinct panel and a fixed deadline. Settlement must either wait for that defined window or use a fully funded reserve; a later appeal cannot recover already-withdrawn funds by assumption. Retain deterministic no-quorum and unavailable-appeal outcomes.

Acceptance: at least ten externally operated evaluator identities with disclosed relationships; selection replay produces the same eligible panel; no unilateral reroll; conflicting roles are rejected; reveal withholding reaches the agreed fallback; appeal payouts conserve liabilities. Publish red-team cases, observed disagreement and collusion limits. No finite voting scheme is a general oracle for subjective truth.

Priority 4: privacy, sponsorship and wider asset access

Store public commitments and minimal settlement facts on-chain; keep sensitive evidence encrypted off-chain with purpose-scoped access and a retention policy. Salt low-entropy commitments to reduce guessing, preserve the exact verification format and explain that public addresses, amounts and timing still reveal metadata. Selective disclosure must demonstrate the agreed predicate without exposing unrelated user intent. Zero-knowledge or trusted-hardware checks are optional specialized evaluators, not blanket truth guarantees.

Add bounded gas sponsorship for approved task actions after mandate enforcement. A sponsor receives the exact chain, contract, selector, amount, nonce and expiry; it cannot substitute a payee or arbitrary call. Set per-user and global budgets, replay protection and a deterministic exhaustion response. Sponsorship does not mint free TOKN. The current curator-paid grant flow already lets a new wallet receive funds without claimant gas, but does not sponsor its later escrow transactions.

For wider access, first test a same-chain wrapper and prove locked-native versus wrapped-supply accounting. The existing Base Sepolia prototype is a wrapped representation of TEST TOKN, not another independently issued native token. Its single authority can fabricate attestations; a receipt hash is not a remote consensus proof. Before any production bridge, require independent custody/verification design, caps, circuit breakers, signer rotation, reserve monitoring, finalized lock/burn verification, replay separation and a recovery plan reviewed for each chain. See bridge prototype limits.

A future wTOKN market needs actual verified contracts, funded external gas, disclosed asset reserves, explicit liquidity authorization and measured depth/slippage. Publish the exact pool and withdrawal rights only after they exist. No price, redemption value, yield or listing is promised by this plan.

Release milestones and measurable gates

Keep the node's current small-network budget explicit: one CPU and 512 MiB for Besu, with supporting services measured separately. Adapters, indexing, evaluators and proof generation must run in separate bounded services. Benchmark idle, catch-up and a declared load of one job per minute with three reviewers; record peak memory, CPU, database growth, gas, block delay and p95 response latency. Do not raise resource limits silently. A failed budget test changes the published requirement or blocks that feature's rollout.

Before each public milestone, pin source revisions and dependencies, repeat secret-exclusion and recovery checks, publish exact addresses and receipts, and request an independent security review proportional to value at risk. No release proceeds with unresolved critical or high-severity findings. Independent operation requires evidence about controllers and connectivity, not container counts.

Explicit non-goals

• No claim that TOKN already outperforms, replaces or complies with the compared protocols.
• No on-chain LLM, automatic truth oracle or majority-vote guarantee of useful work.
• No silent change to production genesis, chain history, existing contracts or accepted job terms.
• No public endpoint, download, price or bridge button before the corresponding service actually works.
• No unrestricted agent spending, invisible delegation, automatic reward from an unreviewed claim or payment for a favorable vote.
• No token sale, liquidity commitment, paid infrastructure or cross-chain production deployment authorized by this document alone.

The next work remains M0: finish the current reviewed release and external pilot. The later layers are separate proposals with measurable gates, not hidden additions to the v3 migration.