TOKN / field guide

Wrapped TEST TOKN prototype

TOKN is a native agentic token: it pays native-chain gas and agreements, with agent-first verification, escrow and validator-decision interfaces. Those interfaces do not determine subjective truth or prove decentralized operation.

NativeTOKNTestLock and BaseSepoliaWTOKN implement a locally tested prototype between the isolated TEST TOKN chain, ID 2026090604, and Base Sepolia, ID 84532. The ERC-20 symbol is wTESTTOKN, with 18 decimals. It represents locked TEST TOKN, not live TOKN or dollars. It is a wrapped representation of TOKN's test asset, not the native token or an independently issued asset. Neither public contract has been deployed. There is no bridge button, deployed address, exchange rate, liquidity pool, or redemption service to advertise.

The constructors reject other chain IDs, including production TOKN and Base mainnet. Supporting real native TOKN would require a separately reviewed design, explicit custody/deployment authorization, funded transactions and verified services.

What the prototype verifies

  1. A depositor locks native TEST TOKN and names the receiving Base address. The

source contract emits a unique event ID derived from its chain, genesis, address and increasing deposit nonce. Its accounting cap bounds outstanding locks.

  1. A read-only observer checks the source RPC chain, genesis, contract runtime,

successful transaction receipt, exact event ID and inclusion at or below the RPC's finalized head. It never fetches arbitrary URLs or accesses a signing key.

  1. One configured operator signs EIP-712 evidence. The signature binds both chains'

identities: destination chain/contract/genesis in the domain, source chain/ genesis/contract in the message, plus event ID, block number/hash, transaction hash, log index, recipient, amount and deadline. A third party may relay it.

  1. The wrapped contract consumes each source event once and mints the exact amount,

subject to its supply cap. Holders can transfer ERC-20 balances and burn their own balance to request release to a native-chain address.

  1. A separately signed burn observation authorizes one native release. Release

credits the recipient, who withdraws with a protected pull payment. A rejecting recipient cannot destroy its credit; duplicate or reentrant withdrawals fail.

The token-to-lock pairing is set once by the attestor before deposits. There is no upgrade, administrative token withdrawal, changing pairing, key rotation or timed deposit refund. There is no safe automatic refund once a mint authorization could exist on the other chain. Operator loss or refusal can therefore strand deposits; this is a prototype limitation, not a production recovery design.

Trust and accounting limits

An ECDSA signature proves what the designated operator authorized. It does not prove source consensus or that the operator's claimed event actually happened. The operator can fabricate a mint within the cap, authorize release without a real burn, or stop processing. A malicious RPC can also mislead an observer. There is no remote light client, independent attestor quorum or trustless bridge. The two chains do not share atomic settlement. Pending locks and burns must be reconciled, along with wrapped supply, native locked backing and withdrawal credit.

The local integration test uses two in-memory EVM chains and ephemeral keys in a network-disabled Docker container. It checks the complete lock/mint/transfer/burn/ release/withdraw sequence, source and destination replay boundaries, wrong signatures, changed recipients and amounts, finalized-event checks, supply caps, expiry, rejecting recipients and reentrancy. It does not prove live Base operation, economic backing against a dishonest operator, or independent control.

External deployment and market gates

Base documents Sepolia as chain ID 84532. Transactions there need Base Sepolia ETH; no funded deployment signer or public deployment has been verified for this project. The prototype needs a separately persisted operator key, approved test-chain contracts and peer configuration, verified RPCs, a funded test signer and a complete observed public round trip before a public interface is available. Base network information.

There is no USDC liquidity or purchase route for TOKN. Circle's testnet faucet provides test assets for development; test USDC is not spendable mainnet liquidity and does not establish a TOKN price. A future market needs real funded reserves, pool creation, explicit risk and treasury authorization, and actual trading evidence. Circle testnet faucet, Circle USDC contract registry.

People can currently seek the manually reviewed native TOKN grants described in Get TOKN. Those payments use the existing funded WorkVault; they do not depend on this prototype or require the recipient to buy gas first.