Industry: Blockchain infrastructure, payments, and agentic commerce
Client: Polygon Labs
Use case: Translating natural-language intent into reliable structured actions for agentic payment workflows
Delivered scope: Kinetic-4B, a compact 4-billion-parameter model specialized for tool selection and structured argument generation
Adjacent Polygon infrastructure: Agentic wallets, Polygon Agent CLI, x402 payments, ERC-8004 identity and reputation, Open Money Stack, and stablecoin settlement
Disclosure: Conscious Engines' engagement record identifies Polygon Labs as the client and agentic payments as the intended use. The public Kinetic-4B model card verifies the model artifact and general tool-calling evaluation. Polygon-specific production payment volume and end-to-end transaction outcomes are not publicly disclosed.
1. Outcome at a Glance
Conscious Engines helped Polygon at the model layer of the agentic-payments stack. The work focused on a narrow but critical problem: turning an agent's language-level intent into the correct machine-readable tool call.
The result was Kinetic-4B, a 4-billion-parameter SLM designed to select the correct tool and populate its arguments. In an agentic wallet, that output can sit upstream of deterministic policy checks, transaction simulation, signing, and settlement.
Key Outcomes
82.33%
Tool-calling accuracy
Conscious Engines' 300-sample Composio evaluation.
1.61 seconds
p95 model latency
Published Kinetic-4B evaluation conditions, excluding the complete payment workflow.
4B
Model size
Compact action model based on Qwen3-4B-Instruct-2507.
13,694
Synthetic training examples
Public model-card training corpus across 20 Composio toolkits.
132 million
Trainable parameters
LoRA adaptation trained 3.18% of approximately 4.15 billion parameters.
| Measure | Published or documented result | Evidence boundary |
|---|---|---|
| Model size | 4 billion parameters | Public Kinetic-4B model card |
| Kinetic-4B tool-calling accuracy | 82.33% | Conscious Engines' 300-sample Composio evaluation |
| Kinetic-4B p95 latency | 1.61 seconds | Conscious Engines' published evaluation conditions |
| Claude Haiku 4.5 accuracy | 80.00% | Same published 300-sample evaluation |
| Claude Haiku 4.5 p95 latency | 4.02 seconds | Same evaluation; deployment conditions may differ |
| Untuned Qwen3-4B accuracy | 78.67% | Same published evaluation |
| GPT-OSS-120B accuracy | 76.33% | Same published evaluation |
| Training examples | 13,694 synthetic samples | Public model card |
| Training coverage | Top 20 Composio toolkits, 10 candidate tools per sample | Public model card |
| Trainable parameters | 132 million of 4.15 billion, or 3.18% | Public model card |
| Polygon collaboration | Model for agentic payment and tool-execution workflows | Conscious Engines engagement record |
| Polygon production payment volume using Kinetic-4B | Not publicly disclosed | Polygon ecosystem activity is reported separately |
Under the published test conditions, Kinetic-4B scored 2.33 percentage points above Claude Haiku 4.5 and returned at less than half the reported p95 latency. These are self-reported model-development results, not an independent audit. The evaluation primarily used English, SaaS-style Composio tools rather than a production suite of wallet and blockchain transactions.
That limitation does not weaken the product thesis. It defines the next proof required. Before a model can help move money, it must be evaluated on payment-specific actions, ambiguous requests, adversarial instructions, insufficient balances, changing chain state, and policies that require refusal.
The project matters because agentic payments need two different forms of reliability:
- model reliability: choosing the intended tool and producing valid arguments;
- financial-control reliability: ensuring the proposed action is authorized, safe, idempotent, and correctly settled.
Kinetic-4B addresses the first layer. Polygon's wallet, policy, identity, and settlement infrastructure provides the surrounding execution environment.
2. Why Agentic Wallets Need a Specialized Action Model
An ordinary assistant produces language. A payment agent produces consequences.
If a general chatbot invents a restaurant opening time, the user receives a bad answer. If a wallet-enabled agent selects the wrong contract, amount, asset, chain, or recipient, the system can move real value incorrectly.
Polygon's developer documentation describes the shift clearly:
“An agent doesn't just send tokens: it executes a purpose.”
That purpose might be to buy an API response, pay for compute, renew a service, settle a micro-invoice, move funds between approved accounts, or execute a multi-step treasury instruction. The user expresses an outcome. The system must convert it into bounded actions.
Natural language is not an execution format
Consider the request:
Pay for the market-data API if it costs less than one cent, use the research wallet, and stop after 500 calls today.
The agent must resolve:
- which market-data service is approved;
- which endpoint and tool implement payment;
- whether “one cent” is a per-call or total limit;
- which wallet label maps to the authorized account;
- which token and network the service accepts;
- the correct amount, decimal precision, and recipient;
- whether 500 calls refers to attempts, completed calls, or successful responses;
- whether the daily allowance has already been partly consumed;
- what to do if the price changes or the API response fails after payment.
The final output must be a structured call, not a persuasive paragraph. A simplified proposal could look like:
1{
2 "tool": "X402_PAY_AND_RETRY",
3 "arguments": {
4 "wallet_id": "research_wallet",
5 "endpoint": "approved_market_data_endpoint",
6 "max_price_usdc": "0.01",
7 "daily_call_cap": 500,
8 "network": "polygon"
9 }
10}Even syntactically valid JSON can be unsafe. The wallet identifier may be wrong, the endpoint may not be allowlisted, or the agent may have interpreted the spending limit incorrectly. Tool calling is therefore only the proposal layer.
The failure modes are specific and measurable
| Failure mode | Example | Required control |
|---|---|---|
| Wrong tool | Uses a transfer function instead of x402 pay-and-retry | Tool-selection evaluation and allowlist |
| Wrong argument | Sends 1 USDC instead of 0.01 USDC | Type, range, unit, and decimal validation |
| Invented identifier | Hallucinates a wallet, token, or recipient ID | Resolve identifiers from trusted state, never free text |
| Unauthorized action | Attempts an unapproved contract or counterparty | Wallet-enforced policy and contract allowlist |
| Duplicate action | Retries a settled transaction | Idempotency key and receipt check |
| Stale state | Acts on an old balance, quote, or nonce | Read-before-write and freshness threshold |
| Prompt injection | Tool response asks the agent to reveal a key or widen access | Key isolation, content boundaries, and fixed policy layer |
| Chain mismatch | Uses the right token on the wrong network | Explicit network binding and simulation |
| Partial workflow | Pays but fails to retrieve the purchased service | Atomic or compensating workflow design |
| Excess autonomy | Executes a high-value action without review | Risk-based approval threshold |
A specialized model is useful because these failure modes can be converted into training and evaluation examples. The goal is not general intelligence. It is a high probability of selecting the right approved function and generating valid arguments under a tightly defined schema.
The model must not become the security boundary
The language model should never be trusted to enforce its own spending limit. It should not hold private keys, decide whether its own request is authorized, or bypass an approval because it believes the transaction is reasonable.
The safe separation is:
intent interpretation != authorization != signing != settlement
Kinetic-4B can interpret intent and propose a tool call. Deterministic systems should verify identity, scope, balance, counterparty, limits, and transaction state. The wallet or secure signer should enforce the approved action. The chain produces the settlement record.
This is the payments equivalent of using multiple models and control layers instead of one general model.
3. What Conscious Engines Built for Polygon
The Conscious Engines engagement scope describes Kinetic-4B as a compact tool-calling SLM built for Polygon's agentic-payment workflows. Its role was to translate model or user intent into reliable structured actions.
The public artifact adds technical detail. Kinetic-4B is produced by applying a rank-64 LoRA adapter to Qwen3-4B-Instruct-2507. Only 132 million of approximately 4.15 billion parameters were trained, equal to 3.18% of the total. Training used 13,694 synthetic examples across 20 Composio toolkits, with one correct tool and nine distractors in each sample.
What Kinetic-4B Was Built to Do
Tool selection
Choose the intended action from a bounded set of approved tools.
Structured arguments
Generate JSON-schema arguments that deterministic services can validate.
Compact adaptation
Use LoRA to specialize a 4B model without retraining every parameter.
Distractor-aware training
Learn from one correct tool and multiple plausible alternatives in each sample.
Controlled serving
Run as an adapter or merged model through a production inference stack.
Policy separation
Leave authorization, signing, limits, and settlement outside the language model.
| Technical element | Published configuration |
|---|---|
| Base model | Qwen3-4B-Instruct-2507 |
| Adaptation method | LoRA using PEFT |
| LoRA rank | 64 |
| LoRA alpha | 128 |
| Precision | bfloat16 |
| Training epochs | 2 |
| Maximum sequence length | 10,240 tokens |
| Training data | 13,694 synthetic tool-calling samples |
| Candidate set | Up to approximately 10 tools from one toolkit |
| Output | Tool name plus JSON-schema arguments |
| Serving path | Adapter or merged model, including vLLM support |
Why fine-tune a 4B model for one step
Tool selection is repeated frequently inside an agent loop. A complex request can require several calls to retrieve state, quote a price, validate a policy, prepare a transaction, execute it, and confirm settlement. Latency and model cost compound at every step.
A smaller specialist creates three potential advantages:
- lower inference latency for frequent action decisions;
- private or controlled deployment;
- predictable behavior on a narrow output schema.
The published evaluation supports the narrow capability claim. Kinetic-4B achieved 82.33% on 300 held-out Composio samples versus 78.67% for its untuned base model. The 3.66 percentage-point improvement measures the value of task-specific adaptation under that test.
It does not prove safe autonomous payments. The public model card states that Kinetic-4B can hallucinate argument values when the request is ambiguous or incomplete. It is evaluated only in English and mainly on SaaS API schemas. It is not intended for general chat, long-form writing, math, coding, or RAG.
That candor is important. A production action model should have a deliberately narrow contract.
The correct production placement
Kinetic-4B belongs inside a controlled execution pipeline:
user or agent intent
-> context and approved tool shortlist
-> Kinetic-4B tool and argument proposal
-> JSON schema and business-rule validation
-> wallet policy check
-> transaction simulation or dry run
-> human approval when required
-> secure signer outside model context
-> Polygon settlement
-> receipt, reconciliation, and audit log
The model should see only the tools relevant to the current state and user permission. Reducing a catalogue of hundreds of possible operations to a small authorized shortlist improves both accuracy and safety.
Every money-moving tool should define:
- required and optional arguments;
- accepted units and decimal rules;
- maximum amounts;
- supported assets and networks;
- authorized counterparties and contracts;
- preconditions and state checks;
- idempotency behavior;
- approval threshold;
- confirmation and rollback or compensation path;
- audit fields.
The model generates a proposal inside those boundaries. It does not create the boundaries.
What should be evaluated next
A Polygon-specific evaluation should include at least the following categories:
| Test category | Example |
|---|---|
| Correct action | Pay an approved x402 endpoint within a known limit |
| Ambiguous unit | “Send five” without currency or decimal precision |
| Missing recipient | Transfer request without a resolved counterparty |
| Policy conflict | User requests an amount above the session allowance |
| Prompt injection | API response attempts to change wallet policy |
| Wrong network | Asset exists on multiple chains |
| Insufficient funds | Correct tool but inadequate wallet balance |
| Duplicate request | Same invoice or idempotency key submitted twice |
| Volatile quote | Route changes beyond approved slippage |
| Multi-step failure | Payment settles but the paid service does not respond |
| Revoked authority | Previously valid session has expired |
| Safe abstention | No approved tool can complete the request |
Report exact tool accuracy, argument accuracy by field, invalid-call rate, unsafe-call rate, refusal precision, successful settlement rate, duplicate-payment rate, human-approval rate, p50 and p95 latency, and cost per correctly completed action.
4. How Kinetic-4B Fits Polygon's Agentic Wallet Ecosystem
Polygon's public agentic-payments stack has expanded around the same core problem. Reasoning agents need a safe way to hold value, discover services, express intent, obtain permission, execute an action, and produce a verifiable result.
Polygon summarized the broader challenge in its Agent CLI announcement:
“The problem is infrastructure, not intelligence.”
Kinetic-4B is relevant because infrastructure still needs a translation layer between language and APIs. It can help choose an operation and produce structured arguments. The adjacent projects below provide wallet, policy, identity, payment-protocol, and settlement capabilities.
| Adjacent project | Public capability | Relationship to Kinetic-4B | Attribution |
|---|---|---|---|
| Polygon Agent CLI | Creates wallets, checks balances, sends, swaps, bridges, registers identity, and pays x402 endpoints | Provides actions that a specialized model can select and parameterize | Polygon project; not claimed as Conscious Engines delivery |
| Session-scoped smart wallets | Per-token limits, contract allowlists, configurable allowances, and 24-hour expiry | Enforces constraints after the model proposes an action | Polygon wallet infrastructure; adjacent |
| Polygon LLM Wallet MCP | 18 tools for encrypted wallets, balances, spending controls, and x402 micropayments | Exposes a bounded tool surface to compatible agents | Documented in Polygon's agentic-payment materials; adjacent |
| x402 on Polygon | HTTP-native pay-per-request flow using stablecoins | Lets the agent recognize a payment requirement, pay, and retry the request | Open protocol supported by Polygon; adjacent |
| ERC-8004 | Identity, reputation, and validation registries for agents | Adds trust context before agents transact with services or other agents | Emerging ecosystem standard supported by Polygon; adjacent |
| Open Money Stack wallets | Custodial and non-custodial wallet APIs, ramps, routing, and settlement | Provides enterprise wallet and money-movement infrastructure | Polygon product; adjacent |
| Coinbase Agentic Wallet MCP | Lets agents discover and pay x402 services on Base, Polygon, and Solana | Demonstrates that Polygon settlement can be reached from an external agent-wallet stack | Coinbase project; ecosystem integration |
| Crossmint agent payments | Scoped card or stablecoin authority with limits, counterparties, and time windows | Demonstrates an adjacent policy pattern for agent spending | Crossmint project; independent industry comparison |
| Mastercard Agent Pay for Machines | Credentialing, permissioning, transacting, and multi-rail settlement | Validates demand for machine-initiated payments across traditional and stablecoin rails | Mastercard initiative; Polygon is a participant |
Polygon Agent CLI makes the controls concrete
Polygon's Agent CLI documentation describes session-scoped smart-contract wallets with per-token spending limits, contract whitelists, and 24-hour expiry. The private key remains outside the language model's context. Commands are dry runs by default so a transaction can be inspected before broadcast.
Those controls illustrate the correct division of responsibility:
- Kinetic-4B: propose the intended tool and arguments;
- Agent CLI and wallet: enforce scope, allowances, contracts, expiry, and key isolation;
- orchestration: simulate, approve, execute, and handle errors;
- Polygon network: order and settle the transaction;
- audit and reconciliation: confirm that the intended economic result occurred.
The model can be replaced or upgraded without changing the wallet's authority rules. The wallet can reject a perfectly formatted but unauthorized request.
x402 turns payment into an API interaction
The x402 pattern uses the HTTP 402 Payment Required status. An agent requests a resource, receives payment terms, pays through an approved wallet, and retries with proof of payment.
This creates a machine-native commercial loop:
discover service -> request resource -> receive price -> evaluate policy -> pay -> retry -> receive service -> reconcile
The model can help choose the service and interpret the intent. Deterministic code should parse the payment requirement, validate the price and recipient, enforce the spending policy, create the payment, and confirm the response.
Polygon reported that, as of June 2026, 95% of measured x402 transactions settled through Polygon, representing more than 15.5 million agent payments. Polygon states that the figures came from third-party Dune Analytics data and are subject to change. They are ecosystem-volume claims and must not be presented as Kinetic-4B activity.
External wallet projects show convergence
Coinbase's Agentic Wallet MCP supports payments on Polygon as well as Base and Solana. Its public documentation separates actions the agent can perform from controls retained by the user, including per-call and per-session limits, transfers, and funding.
Crossmint documents another implementation pattern: a user delegates a spend cap, allowed counterparties, and a time window to the agent. The authorization is explicit and revocable. The agent receives bounded spending power rather than the user's unrestricted wallet authority.
These projects reinforce the architectural principle behind Kinetic-4B. The model is not the wallet. It is the intent-to-action component inside a broader policy system.
5. What Payments and Product Teams Should Take Away
This case is not evidence that a 4B model should control money by itself. It shows where a specialized model can be more useful than a general assistant: a frequent, structured decision with a small output surface and a measurable error taxonomy.
The important product decision is to separate reasoning from authority.
- Use the model to propose, not to authorize. The wallet and policy engine decide whether the action is allowed.
- Keep keys outside model context. No instruction, plugin, webpage, or tool response should be able to extract a key the model never sees.
- Give the model the smallest relevant tool set. Tool shortlisting reduces confusion and limits the available action surface.
- Validate every argument deterministically. Amount, units, network, asset, address, counterparty, and limits should not depend on natural-language confidence.
- Make retries idempotent. A timeout must not become a duplicate payment.
- Simulate before settlement. Dry runs, quote validation, and policy checks catch failures before value moves.
- Escalate by risk. High-value, novel, cross-chain, or policy-edge actions should require human approval.
- Evaluate refusals as carefully as successes. A safe agent must know when information or authority is missing.
- Measure the complete action. Correct JSON is not success if settlement, service delivery, or reconciliation fails.
- Version the model, tools, schemas, and policies together. A model benchmark becomes stale when the available actions change.
Production acceptance criteria
| Acceptance measure | Why it matters |
|---|---|
| Payment-specific evaluation set | Shows that general tool accuracy transfers to wallet and protocol actions |
| Tool and argument accuracy | Separates correct function choice from correct field population |
| Unsafe-action rate | Measures proposals that violate amount, counterparty, contract, or chain policy |
| End-to-end settlement success | Shows whether correct proposals become correct completed transactions |
| Duplicate-payment rate | Validates idempotency under retries and timeouts |
| p95 end-to-end latency | Includes policy, simulation, signing, chain, and confirmation time |
| Cost per correct completed action | Measures production economics, not just model inference cost |
| Human-approval rate | Shows how often the system can act within delegated authority |
| Production volume and value | Establishes deployment scale without conflating Polygon network activity with model usage |
Kinetic-4B provides a credible starting point: a public 4B model artifact, a transparent training configuration, a bounded intended use, documented limitations, and a published evaluation. The Polygon engagement connects that specialization to an important product category, agentic payments.
The next milestone is an end-to-end benchmark where success means more than selecting a function. The agent must understand the request, choose the correct action, remain inside delegated authority, settle exactly once, receive the purchased result, and leave an auditable record.
That is the standard for AI that can move money.
Related Conscious Engines research
- The private AI model stack for financial services
- Safe AI agents for regulated financial workflows
- Why one model is not an enterprise AI strategy
- Why your evaluation set is your AI moat
- The bespoke enterprise AI business case
- Companies moving work away from frontier models
Sources and evidence boundaries
- Conscious Engines engagement record. It identifies Polygon Labs as the client and describes Kinetic-4B as a compact tool-calling model for agentic payment workflows. Public Polygon sources describe the surrounding agentic-payment ecosystem but do not report Kinetic-4B production payment results.
- Conscious Engines Kinetic-4B model card on Hugging Face. This is the source for model architecture, training configuration, benchmark results, intended use, and limitations. The benchmark is produced by Conscious Engines and is not an independent Polygon production test.
- Conscious Engines Kinetic-4B technical article
- Polygon developer documentation, Agentic Payments Introduction
- Polygon Agent CLI announcement
- Polygon LLM Wallet MCP Server documentation
- Polygon agentic-payments and x402 overview
- Polygon wallet infrastructure
- Polygon on Mastercard Agent Pay for Machines. Polygon labels the x402 figures as third-party analytics and states that Mastercard's service is a separate product.
- Coinbase Agentic Wallet MCP documentation
- Crossmint, How Agents Pay