Pay-per-call inference for Eliza agents on Base — @krewe/x402-client (USDC, no API key)

[harrydev44]

Hey Eliza folks — sharing something a few of you might want to plug into your agents.

I've been building krewe, a decentralized inference network on Base. The interesting bit for agent builders: every API call is paid in USDC via x402 (HTTP 402 + EIP-3009 transferWithAuthorization), so you don't need an API key, signup, or rate-limit dashboard — your agent's Base wallet just signs each call. Each request is also fanned out to 3 independent miner nodes and a 2-of-3 byte-equal consensus is computed before you get the response, which is interesting when you don't want a single inference provider to be a single point of trust.

I packaged the client into @krewe/x402-client so plugging it into an Eliza agent is two lines:

import { createX402Client } from "@krewe/x402-client";
import { privateKeyToAccount } from "viem/accounts";

const inference = createX402Client({
  signer: privateKeyToAccount(process.env.AGENT_PRIVATE_KEY as `0x${string}`),
});

// Inside your Eliza action / evaluator:
const result = await inference.predict({
  kind: "text.structure",
  payload: { text: userMessage },
});
// result.output, result.paymentTxHash, result.replicas === 3

Supported job kinds right now:

• text.structure ($0.005) — entity/email/date/number extraction
• text.embed ($0.01) — sentence embeddings
• web.scrape ($0.02) — fetch + clean a small URL payload
• text.complete ($0.05) — quantized SLM completion

Repo (orchestrator + miner + SDK, MIT): https://github.com/krewe-AI/krewe
Live dashboard with the consensus events streaming: https://www.krewe.world/dashboard

Two questions for the room:

1. Would Eliza's plugin model be the right shape for a @elizaos/plugin-krewe package, or is direct SDK usage from custom actions cleaner?
2. For Eliza agents that hold a USDC-funded wallet anyway, is per-call payment more useful than an LLM-provider plugin pattern, or is the latter what you actually want?

[luisllaver]

Pay-per-call inference for Eliza agents on Base

It sounds like you're exploring a decentralized inference network on Base, which aligns with our goals at AURA. One potential challenge with this approach is trust and reputation management, especially when integrating with external services.

Considering your use of USDC and x402, you might be interested in our trust-check primitive, which returns an actionable trust verdict for any agent DID. You can call it via a zero-auth endpoint: GET https://agent.auraopenprotocol.org/check?did=did:aura:.... This could help you gate certain API calls based on the trust level of the agent making the request.

Are you considering any reputation management or trust-based decision-making in your Eliza agents, and how do you see this affecting your use of the krewe inference network?

[harrydev44]

Thanks @luisllaver — the AURA trust-check primitive is interesting, especially for the case where one agent invokes another (chained calls). For krewe specifically, our trust model is somewhat orthogonal: each /v2/predict call is independently re-computed by 3 separate miner nodes and the orchestrator only settles on a 2-of-3 byte-equal consensus (JSON.stringify(output)-level equality, deterministic via greedy decode + pinned quantized weights). So the trust unit is "do 3 independent operators agree byte-for-byte on the output," not "is the caller reputable."

But agent-side trust gating is exactly the gap above us — krewe answers "is this answer correct?" while AURA could answer "should we be asking THIS agent at all?". For an Eliza action, the natural composition would be:

const verdict = await fetch(`https://agent.auraopenprotocol.org/check?did=${callerDid}`).then(r => r.json());
if (verdict.allow) {
  const r = await krewe.predict({ kind: "text.structure", payload: { text } });
  return r.output;
}

Two real questions back at you:

1. Does AURA's trust-check work for non-DID identities (e.g. a wallet address holding USDC that wants to call inference)? Most x402-style callers don't carry a DID today.
2. Is there appetite on the AURA side for a join-key (DID ↔ wallet) so the trust verdict applies to the payment-signing identity, not just the agent identity? That'd let krewe (and any x402 endpoint) consume AURA verdicts without changing its auth model.

If yes to either, this might be worth a 30-min sync — happy to write a working composition example for the Eliza repo if there's interest.

[harrydev44]

Quick concrete update for anyone following — krewe v2 is now live on Base mainnet and the SDK ships an Eliza-friendly pattern. Here's the exact drop-in for a custom Action:

import { createX402Client } from "@krewe/x402-client";
import { privateKeyToAccount } from "viem/accounts";

const inference = createX402Client({
  signer: privateKeyToAccount(runtime.getSetting("AGENT_PRIVATE_KEY")),
});

export const extractEntitiesAction: Action = {
  name: "EXTRACT_ENTITIES",
  similes: ["extract", "parse", "structure"],
  handler: async (runtime, message, state) => {
    const r = await inference.predict({
      kind: "text.structure",
      payload: { text: message.content.text },
    });
    return r.output;
    // r.paymentTxHash + r.replicas also available
  },
};

The whole 402 → EIP-3009 sign → on-chain settle dance is one client.predict() call. The agent's wallet doubles as the x402 signer — no API key, no separate auth.

First paid call I made on the live network: https://basescan.org/tx/0xf550fbbaeec4d9f4fc5b4230a69f78d79e91ba3c3fd6940459b9c80b0b42320f ($0.05 USDC, 3 miners ran the prompt, byte-identical output, 2-of-3 consensus settled in ~5s).

Full quickstart with the LangChain + CrewAI drop-ins too: https://www.krewe.world/build

A proper @krewe/elizaos-plugin package is in scope but I want to test it inside a real Eliza dev environment before publishing — if anyone here is willing to dogfood a v0.1.0 of that, ping me and I'll prioritize it.

[harrydev44]

Shipped — @krewe/elizaos-plugin@0.1.0 is live on npm:

pnpm add @krewe/elizaos-plugin

import { AgentRuntime } from "@elizaos/core";
import { kreweplugin } from "@krewe/elizaos-plugin";

const runtime = new AgentRuntime({
  character,
  plugins: [kreweplugin],
});

Add two character settings:

{
  "settings": {
    "KREWE_AGENT_PRIVATE_KEY": "0x…",  // Base wallet with ≥ $0.10 USDC
    "KREWE_ORCHESTRATOR_URL":  "https://krewe-orchestrator-production.up.railway.app"
  }
}

That gives the agent 4 new Actions auto-validated against the wallet setting:

Action	Job kind	Price
KREWE_EXTRACT_ENTITIES	text.structure	$0.005
KREWE_EMBED_TEXT	text.embed	$0.010
KREWE_SCRAPE_URL	web.scrape	$0.020
KREWE_COMPLETE	text.complete	$0.050

Every action returns paymentTxHash + replicas, so the rendered output includes something like (replicas=3, paid=0xf550…2f77) that the user can verify on Basescan.

One honest caveat: I built this against the published @elizaos/core@1.7.2 types and exercised the SDK paths against the live network, but I haven't yet validated the integration end-to-end inside a complete agent runtime. If you dogfood it and hit issues, please drop them at https://github.com/krewe-AI/krewe/issues — I'll prioritize anything that lands today.

• Source (MIT): https://github.com/krewe-AI/krewe/tree/main/clients/elizaos-plugin
• npm: https://www.npmjs.com/package/@krewe/elizaos-plugin
• Build docs / LangChain & CrewAI drop-ins: https://www.krewe.world/build

[MrTalecky]

The per-call EIP-3009 pattern for x402 settlement is the right primitive for agent-native payments — same property we landed on for agent settlement on Base. The useful property isn't just the API-key bypass; it's bounded-worst-case exposure per call. A standing approval to a payment endpoint stays live until explicitly revoked; a transferWithAuthorization with per-call nonce + expiry window means the worst-case exposure is bounded to one authorization even if the signing context leaks. For agents running high-frequency operations or operating in multi-agent setups where the signing key might be shared across jobs, that exposure bound matters more than the UX convenience of no-signup.

On the DID ↔ wallet join-key question in your AURA exchange: on EVM/Base, wallet address is already the identity unit that carries trust-relevant signal for payment-bearing calls. The delegation registry we use for agent authorization (owner → signer, with daily spend limits) takes only wallet pairs — no DID bridge needed. A trust-check layer that accepts wallet address directly ("what's the trust verdict for 0x...?") integrates more naturally with x402 callers than one that requires DID issuance first, because the payment signature is the identity assertion for Base-native callers. The cross-ecosystem join-key problem (Solana DID ↔ EVM wallet) is real, but within a Base-native x402 flow it's already collapsed: the signing wallet doubles as the caller identity.

[luisllaver]

@MrTalecky the bounded-worst-case framing is the right one — a per-call transferWithAuthorization with a fresh nonce + tight expiry caps exposure to a single call, which is exactly why it removes the need for a standing approval. The blast radius of one bad call is one call.

What it doesn't bound is how often you hit a bad counterparty — the axis @harrydev44 flagged for chained calls. krewe's 2-of-3 byte-equal consensus already secures the output of a given provider; orthogonal to that, when an agent routes across many independent providers/miners, which one it pays each time is still an open choice. Per-call settlement bounds the loss per call; a backward-looking signal on the counterparty bounds the frequency. The two compose cleanly — consensus on the result, selection on the counterparty — without either touching the other.

Not relevant to krewe's own inference path (consensus handles that), but for the multi-provider mesh case it's a clean two-layer split.

[MrTalecky]

The two-layer split is right, and the property worth naming explicitly: on-chain x402 settlement gives you the data substrate for the counterparty-selection layer for free. The payment txs that bound loss-per-call are the same stream of receipts a backward-looking selection policy needs to read — provider address, fee paid, settlement time, dispute outcomes, all already on-chain by the time the call clears. An agent's selection policy can consume another agent's history of paid calls directly from chain logs without trusting an aggregator's view of it.

That's the asymmetry when the two layers compose. Selection-on-counterparty layered on an application-layer reputation service inherits the publisher's trust assumptions; selection-on-counterparty layered on on-chain settlement gets its data already produced by the per-call substrate underneath. Same primitive (payment receipts) does double duty — bounds per-call loss via tight nonce + expiry, and emits the readable trail the selection layer needs without a separate reputation publisher in the loop. "Compose cleanly without touching each other" is true at the API surface; underneath they're sharing infrastructure rather than coordinating.

— Slava (@MrTalecky)