§22 The Machine-Readable Value Layer

Humans read bank SMS and invoices; programs read contract return values and event logs. If on-chain assets follow public standards (the VRC family, the ERC family), a program can query balances, authorize transfers, and trigger splits without parsing PDFs—that is the machine-readable value layer. Operationalization of verifiability is in Chapter 6, Section 4 (the three layers of execution–state–history).

Section 1 From Human-Readable Bills to Machine-Readable Interfaces

Traditional value representation relies on human-readable media: bank SMS, paper invoices, numbers on an ERP screen. If silicon coordination still needs OCR or web scraping to learn a balance, friction will cancel the gains from automation. Machine-readability requires that value state be exposed in a deterministic syntax: given an address and a block height, any node returns the same balance; given a transfer function and parameters, any node can predict the state-transition result.

The core contribution of blockchain token standards is precisely to harden that readability into an interface specification. ERC-20 defines methods such as balanceOf, transfer, and approve for fungible tokens on Ethereum; any compatible wallet, exchange, or DeFi protocol can integrate without discrimination. The VRC series functionally parallels and extends the ERC family; if Layer 0 value-exchange + Layer 1 application-chain layering is delivered, asset types on the value internet may still keep composable semantics when accessed across chains and across Layer 1s. VTP (if delivered as designed) is intended to handle message routing at Layer 0, while VRC specifies “what kind of value the message carries”—a division of labor analogous to TCP/IP and HTTP.

The machine-readable interface is the operationalization of verifiability’s second emergence dimension at the asset layer. Chapter 6, Section 4 decomposes verifiable rules into three layers—execution–state–history¹; Menger’s “saleability” decides whether an asset can be widely accepted as a medium of exchange; verifiability decides whether a program can independently re-check issuance rules and balance state at millisecond scale—in silicon settings the latter is often tighter than the former. Monetary emergence ≈ saleability ranking × verifiability threshold—the former from Menger’s dispersed selection over material properties; the latter from three-layer verifiable rules.

Mapping of the three layers onto asset interfaces: execution verifiable—transfer/approve execute by bytecode; state verifiable—balanceOf, collateral ratios, and whitelists queryable in real time; history verifiable—transfer events permanently retained and replayable. In Menger’s era verifiability was limited by closed ledgers; a global ledger reduces it from an institutional privilege to a public technical good.

“Machine-readable” does not contradict human-readable. Block explorers and wallet UIs can render the same state as graphics; the difference is that silicon subjects can call the interface directly, without bank portals and business hours designed for carbon-based users. Public value interfaces lower the integration threshold for new participants (including Agent developers), yet they do not automatically guarantee asset quality—poorly collateralized “stablecoins” and infinitely minted points are, technically, also “standard interfaces.”

Section 2 Fungible Tokens: ERC-20 and VRC-20

A fungible token is an on-chain asset each unit of which is interchangeable, without individual serial differences. Ethereum’s ERC-20 is the de facto standard; VRC-20 is intended to offer a parallel interface for points, API call quotas, game vouchers, governance votes, general utility coins, and similar scenes—functionally equivalent to ERC-20; if Layer 0 / Layer 1 layering is delivered, deployment on a Layer 1 application chain must follow local gas and naming conventions.

Typical Agent uses of VRC-20 include: API quota coins—an enterprise issues COMPANY_API_CREDIT; each internal microservice call consumes one or one-tenth of a unit; insufficient balance fails the call without real-time fiat settlement; ecosystem points—users earn points for tasks, redeemable for services or discounts, with on-chain verification against double-spending; general utility coins—as an intermediate exchange unit in open Agent markets, reducing the complexity of $N^2$ bilateral pricing among $N$ services.

Reasons to choose VRC-20 rather than fiat stablecoins directly are often boundary and incentive: quota coins can be minted without bound inside a private domain without shocking public monetary supply; points can set expiry and non-transfer rules (via contract constraints), whereas stablecoins usually must remain transferable to keep monetary properties. Regulatorily, if VRC-20 is widely used for external payment and pegged to fiat value, it may touch e-money or payment licensing; if confined to a closed ecosystem as a utility credential, the compliance path is closer to prepaid cards or loyalty programs—analysis must be jurisdiction-specific, not one-size-fits-all.

On integration, an Agent completes a micropayment by calling transfer or transferFrom (after prior approve); batch airdrops, mining rewards, and splits all speak the same interface. Developers must mind integer precision and decimals configuration to avoid floating-point error causing contract revert.

Section 3 Stable Settlement: VRC-10 and VRC-11

High-frequency Agent collaboration must answer “in what unit to price and settle.” Volatile speculative tokens are unfit as everyday units of account; public- and private-domain stable settlement assets therefore become the machine economy’s default choice.

PCIM public layer (Openverse instance: VRC-10 Bitcurrency) competitively issues against volatile collateral (Bitgold) with dynamic-tier overcollateralization (circulation-tier referenda; upper tier about 161.8%), representing ISO 4217 fiat units on-chain and serving as unit of account and medium of final settlement—these parameters come from the Openverse whitepaper, without independent audit or long mainnet testing; mechanism-neutral counterparts include DAI (ETH overcollateralized CDP), USDC (fiat reserves), and other auditable stable assets. For Agents, public Bitcurrency fits: cross-enterprise, cross-ecosystem scenes that must be roughly comparable to external fiat—paying public DApps, buying on-chain public data, or exiting to fiat via off-ramps. Its public nature means unified rules and network-wide liquidity aims, but also broader regulatory attention and collateral-parameter risk.

VRC-11 Privcurrency is an enterprise or permissioned trade-circle private stablecoin, designed in the blue paper to mint against Bitgold at low collateral (stake ratio 61.8%), circulating inside a permissioned whitelist, often named with a brand prefix (e.g. StarUSD, MicroUSD)—stressing scene binding rather than a rigid dollar peg; protocol-neutral counterparts are enterprise stables or internal settlement tokens on permissioned chains. Supply-chain scenes have already discussed deployment paths; in Agent scenes, Privcurrency fits: M2M settlement within one legal person or alliance, internal API markets, and B2B collaboration that prefers not to expose all flows on a public explorer. Agent wallets on permissioned domains or consortium chains may consider Privcurrency as the default unit, with month-end fiat aggregation declared at the CFO layer.

The relation of the two is “public outside, private inside,” consistent with enterprise Treasury multi-currency configuration across public/private domains. Agents should not be hard-coded to “recognize only one coin”; the orchestration layer must dynamically choose VRC-10 or VRC-11 by counterparty domain, amount, and compliance need, converting via DEX or protocol-native swap when necessary—and conversion itself should be a machine-readable standard operation.

Section 4 Non-Fungible Assets: NFTs and VRC-721

Each non-fungible token (NFT) has a unique identifier and is not interchangeable. Ethereum’s standard is ERC-721; Openverse’s counterpart is VRC-721. Human narrative often links NFTs to art collecting; in the machine economy, more practical uses are permissions, slots, and device keys.

Permissions: only addresses holding a specific tokenId may call an API or a smart-contract method—an on-chain capability credential. The Agent must first verify that its wallet holds a valid VRC-721, then initiate the request; the server contract simultaneously checks ownerOf.

Slots: scarce resources such as compute markets, warehouse units, and spectrum time slots can be represented as exclusive rights by tokenId. Booking a GPU slot means transferring or staking the corresponding NFT; when the slot ends, VRC-13 time logic or a contract timelock releases it automatically.

Device keys: IoT device identity and operating rights can bind to VRC-721; only Agents holding the key NFT may send on-chain commands to the device, reducing unauthorized remote-control risk.

NFTs are unfit as everyday micropayment media—poor liquidity, high pricing friction. Agent scenes should follow the division “settle with fungible stables, authorize with non-fungible credentials.” If an NFT is both collectible and access card, secondary-market speculation may disturb operational stability: permission NFTs should be non-transferable or only permissioned-transferable, lest critical device keys flow into speculative markets.

Section 5 The Time Dimension: VRC-13 Light Link

VRC-13 (Time Token) tokenizes professional service hours, project deadlines, and service commitments; individuals may also issue service credentials backed by their own time. In Agent scenes, time tokens fit time-bounded use rights rather than permanent permissions: e.g. “one hour of consulting daily for the next thirty days,” “a data subscription valid this quarter.”

Openverse official docs also list VRC-30 (Timing Token) defining validity windows by block height; the text below keeps VRC-13 wording—when consulting the whitepaper, note the numbering correspondence with VRC-30. For Agent orchestration, time tokens may combine with VRC-721: 721 means “which slot,” 13 means “when that slot is valid.” The smart contract checks time-token state at block.timestamp or an agreed block height and rejects service calls when expired.

Time tokens should not be treated by Agents as general means of payment—they are non-fungible, time-bound, and often indivisible. The selection principle: when the value core is “a service commitment over a period” rather than “a good delivered instantly,” introduce VRC-13; when the value core is “instant settlement,” use VRC-10/11 or VRC-20.

Section 6 Four Asset Classes for Agent Scenes: A Comparison

The table summarizes standard positioning and selection principles for four asset classes in Agent orchestration. “Four classes” means stable settlement (VRC-10/11), fungible utility (VRC-20), non-fungible permission (VRC-721), and time commitment (VRC-13)—stable settlement lists one public and one private example, compared jointly on decision dimensions.

Decide first whether the counterparty is in a permissioned domain—if yes, prefer VRC-11; else VRC-10; then whether payment is instant delivery or continuing rights—instant uses stables or VRC-20 quotas; continuing rights consider VRC-13 and VRC-721; unique slots issue VRC-721; divisible points alone suffice with VRC-20.

Section 7 On-Chain Assets as Value Interfaces

Synthesizing the standards above, on-chain assets are machine-readable, contract-callable value interfaces, not mere speculative tickers. Interface meaning includes: queryable (balanceOf, ownerOf), transferable (transfer), authorizable (approve/setApprovalForAll), composable (DeFi-style nested calls), auditable (event logs permanently retained). Agent developers call these interfaces as they call REST APIs; the difference is only that state changes require signatures and cannot be unilaterally revoked.

Silicon subjects do not “trust” an issuer’s verbal promise; they verify that interface behavior matches deployment (unless the contract is upgraded—and upgrades themselves should be visible on-chain). x402’s pay-per-call solves “how to trigger payment”; VRC/ERC standards solve “what is paid and whether rules can be independently re-checked”—both layers must hold for the machine economy to scale. The table below summarizes 2024–2026 experiments and VRC design division by asset-layer role:

Three constraint carriers—reputation (platforms, facilitators, card schemes, RPC), stake (DePIN slash, order books, Agent registration deposits), parameters (collateral ratios, whitelists, session-key quotas)—each have weaknesses in silicon settings: reputation is hard for third parties to re-check independently; stake struggles to cover off-chain delivery; parameters become verifiable rules only when on-chain state is readable. x402’s on-chain receipt partly reinforces reputational constraint; ERC-4337 policy contracts write spending rules into queryable state; VRC-10/PCIM collateral queries and 721 slots try to decouple DePIN’s “programmable markets” from a stable pricing layer. Choosing asset standards is, in substance, allocating the verifiability burden between parameter and reputation layers.

Observable implication (colinear with P-22): If parameter-layer asset standards are indeed silicon’s comparative advantage, then before and after the same DePIN vendor is integrated, an Agent scheduler’s $\rho_{\mathrm{audit}}$ (reconciliation/audit scripts as a share of integration engineer-hours) should fall, and $\tau_{\mathrm{read}}$ (collateral-ratio/whitelist query latency, seconds) should be below the dispute-mediation latency $\tau_{\mathrm{revoke}}$ of reputation-layer schemes—comparable in a 12-month dual-track pilot.

Public value interfaces lower machine-economy integration cost but do not automatically guarantee asset quality. Poorly collateralized “stablecoins,” infinitely minted points, and admin-revocable NFT permissions are technically also “standard interfaces”—markets and regulators must screen. Monetary popularization expands the space for trial and combination; risk does not vanish.

If the core gain of a machine-readable value layer is verifiability, then after an Agent orchestration system adopts a new asset standard, the share of integration hours spent on “reconciliation/audit scripts” $\rho_{\mathrm{audit}}$ should fall while the share on “business logic” rises—comparable in dual-track projects where the same team integrates ERC-20 and VRC-20. Observable metrics include $\rho_{\mathrm{audit}}$, cross-chain configuration hours $H_{\mathrm{xchain}}$, and oracle maintenance frequency. If $\rho_{\mathrm{audit}}$ is unchanged, “machine-readable” gains may be offset by cross-chain configuration and oracle maintenance; do not overrate the standard alone.

Section 8 Interoperability with the Ethereum ERC Family

In real deployment, Agents often face Ethereum ERC-20/721 and the Openverse VRC family simultaneously. Only after cross-chain bridges and VTP are delivered as designed can assets flow across ecosystems—until then, configure case by case against production bridges and deployed contracts. Developers should abstract an “asset adapter” at the orchestration layer, unifying homogeneous interfaces across chains into internal types, avoiding hard-binding business logic to chain IDs. Wallets must clearly show “which chain, which standard, what collateral or permission rules the current operation uses,” lest users or Agents mis-send Privcurrency to a public-chain address with no permissioned resolution in a cross-chain transfer.

ERC-20 and VRC-20 can share the same client-library pattern at the Agent code layer; differences are RPC endpoints, contract addresses, and gas tokens. Managing testnet vs mainnet and public vs private configuration is routine enterprise Agent ops—akin to the challenge of wiring enterprise ERP to on-chain contracts.

In cross-chain scenes, the Agent orchestrator must also handle “same name, different chain”: the same brand Privcurrency may deploy one contract on each of two Layer 1 application chains, with different addresses and whitelists (Layer 0 / Layer 1 layering as designed). VTP messages and UNS resolution, if delivered as designed, should return full chain identifiers, lest an Agent spend chain A’s balance on chain B’s payment. Centralized exchanges’ “choose deposit network” has already taught users this lesson; if silicon subjects lack equivalent checks, losses will amplify automatically.

Section 9 Anti-Patterns and Prudent Practice

Several common misuses deserve caution: minting unique NFTs for API calls that should be fungible micropayments—Gas and liquidity costs explode; using unhedged Bitgold or speculative coins as internal enterprise units of account—importing price volatility into operating cost; approving unlimited allowances to malicious contracts—one phishing wipeout; wrongly mapping permissioned-domain Privcurrency into public-chain liquidity pools—breaking whitelist assumptions. Prudent practice includes default minimum-allowance approve, periodic revocation of unused authorizations, permission NFTs default soulbound (non-transferable), isolating stable-settlement assets and utility tokens in separate wallets, and simulating on-chain operations before multisig confirms large transfers.

Section 10 Composition Patterns and Sketch Cases

Three simplified Agent composition patterns for architecture reference—not investment advice, nor audit reports of production systems.

Pattern A: Public-domain data-procurement Agent. The orchestrator holds a contract wallet controlled by a session key and pays a public data DApp per call in a public stable settlement asset (VRC-10 Bitcurrency as Openverse reference instance; counterparts USDC/DAI); each call returns an on-chain receipt event; the session key is destroyed when the task ends. Public stable settlement is chosen because the counterparty is public and must be roughly fiat-comparable; VRC-721 is not chosen because the data interface is fungible and needs no unique slot.

Pattern B: Alliance manufacturing-collaboration Agent. Multiple suppliers on a permissioned chain use the same enterprise-issued Privcurrency; after a robot finishes a process step, the dispatch contract automatically splits to supplier addresses. VRC-11 is chosen because the whitelist is known and flows need not all be public on a public explorer; VRC-721 marks exclusive line-time slots; VRC-13 marks quarterly maintenance service commitments.

Pattern C: Internal R&D quota Agent. Employee-deployed coding assistants consume company-issued VRC-20 DEV_CREDIT, deducting a fixed quota per thousand inference tokens; HR airdrops quotas monthly; non-transferable. VRC-20 rather than stables is chosen because the aim is internal cost attribution, not external payment; regulatorily closer to internal management accounting than issuing a payment instrument to the public.

The three patterns share this: asset type serves governance boundaries and audit needs; “more expensive, more advanced” is not a selection principle. Architecture review should first draw counterparty domains and compliance boundaries, then consult the table above—do not default everything to Bitcurrency or Privcurrency—Openverse instance parameters follow public documentation.

Governance tokens (also often VRC-20) have another role in Agent ecosystems: protocol upgrades, fee-parameter changes, whitelist amendments—Agents themselves usually do not vote, but governance votes held by their operators decide which contracts Agents may access. Separating “pay with stables,” “utility with quota coins,” and “govern with vote coins” avoids everyday micropayments touching the governance attack surface—a lesson many DeFi protocols learned with dual-token structures.

Section 11 Compute Markets and an Engineering Mnemonic

VRC-20 carries divisible utility and quotas; VRC-10 and VRC-11 carry public- and private-domain stable settlement; VRC-721 carries permissions and slots; VRC-13 carries time commitments. When orchestrating, Agents choose asset type by counterparty domain, delivery tense, and scarcity, so every tool call maps to a verifiable on-chain value state.

DePIN networks such as Akash, Render, Bittensor, and io.net already organize compute trade with on-chain orders and stake, but most still price in a single volatile token; Agents must hedge extra to keep stable books; Ballandies et al. (2023) DePIN taxonomy aligns with such compute-market structure².

Technical decision-makers should mark public/private boundaries and VTP routing assumptions on architecture diagrams, configure independent wallets or sub-accounts per asset type, forbid production private keys from entering Agent images in CI/CD, set periodic scans and revocation for approve, and have counsel review boundaries between permission NFTs and security-type VRC-12—these acts do not create security by themselves, but they make implicit assumptions explicit and reduce path dependence on “deploy the VRC suite with a USDT mindset.” An engineering mnemonic: stable settlement choose 10/11; divisible utility choose 20; unique permission choose 721; time commitment choose 13—concrete instances still require whitelist, collateral state, and compliance labels; a mnemonic cannot replace due diligence; Openverse instance parameters follow public documentation.