@veridex/fetch-adapter

Bounded payments for Fetch.ai agents on BNB Chain.

An agent gets a session key that can spend up to a daily budget, only to allowlisted recipients, only through allowlisted contracts. Every attempt is checked on-chain before value moves.

The design assumption is that the agent gets compromised. When it does, the attacker inherits exactly those bounds and cannot widen them — a session key is forbidden from calling the policy module or the session registry, so it cannot allowlist itself or lift its own budget. Owning the agent gets you its daily allowance at approved merchants, not the treasury.

npm install @veridex/fetch-adapter

Use it from TypeScript

import { VeridexFetchVault } from '@veridex/fetch-adapter';
import { parseUnits } from 'ethers';

const vault = new VeridexFetchVault({
  rpcUrl: 'https://bsc-testnet-rpc.publicnode.com',
  addresses: { vault: VAULT, sessionRegistry: REGISTRY, spendingLimitModule: MODULE },
  sessionKey: process.env.VERIDEX_SESSION_KEY!,   // the hot key — assume it leaks
});

// Ask first: a refusal caught here costs no gas and gives the agent a readable reason.
const decision = await vault.checkPolicy({ token: FET, recipient, amount: parseUnits('10', 18) });

if (decision.allowed) {
  const { txHash } = await vault.pay({ token: FET, recipient, amount: parseUnits('10', 18) });
}

pay() re-checks policy and throws PolicyViolationError before broadcasting, so an agent never burns gas discovering it is not allowed to do something.

Use it from a Python uAgent

Agentverse agents are Python; this SDK is TypeScript. MCP is the seam. Run the server —

npx veridex-fetch-mcp

— and the uAgent calls it over JSON-RPC. That boundary is a security property, not just plumbing: the session key lives in the server, the agent's LLM never sees it and cannot reach the chain directly. A prompt-injected agent can request a drain and simply be told no.

Three tools: veridex_pay, veridex_check_policy, veridex_get_budget.

See demo/fetch-bounded-payments for a working uAgent that makes one permitted payment and one refused one.

Provisioning

Setup is an owner action, so it crosses Wormhole from the hub. It happens once. Paying is an agent action, read from a chain-local SessionRegistry — one storage read, no bridge, no Guardian round-trip. That split is the point of the spoke design: the thing that happens constantly is local; the thing that crosses a bridge happens once.

const provisioner = new VeridexProvisioner({ provider, relayer, addresses, ownerVaa });

await provisioner.attachModules(ownerKeyHash);
await provisioner.setPolicy({
  token: FET,
  dailyLimit: parseUnits('100', 18),
  allowedRecipients: [merchant],       // an empty allowlist is refused, not silently permissive
});
await provisioner.grantSession(
  { sessionKeyAddress, ttlSeconds: 3600, maxValue: parseUnits('25', 18) },
  [{ target: FET, selectors: ['0xa9059cbb'] }],   // transfer only — NOT approve
);

Scoping the session to transfer matters beyond the transfer path: an unscoped session could approve the token and let an attacker pull the balance out later, sidestepping every spending limit.

Two things that will bite you

FET is 18 decimals. Most x402 settlement today is 6-decimal USDC. Read decimals from the token (provisioner.tokenDecimals()); do not assume. A 6-vs-18 mistake misprices by 10¹².

An unprovisioned vault fails open. A vault with no policy attached will send funds anywhere. assertProvisioned() refuses to operate against one, and the MCP server calls it on startup — because an agent wired to a policy-less vault looks bounded and isn't, which is strictly worse than a bare wallet.

License

MIT