[Plugin Proposal] Dreamline x402 Policy Facilitator for autonomous agent spend governance

[aisatoshinext-arch]

Problem

ElizaOS agents can now hold wallets and spend autonomously via x402.
But there is no standard plugin for spend governance — who decides
whether a payment should happen before it executes?

Without a policy layer, agents can:

• Pay blacklisted destinations
• Exceed per-tx or daily budgets
• Leave no immutable audit trail

Proposal

A Dreamline plugin for ElizaOS that intercepts x402 payments
before execution and checks:

1. On-chain blacklist (DreamlineRegistry on BNB Chain)
2. Per-agent policy (budget, whitelist, tx limits)

If blocked → payment never executes.
If approved → normal x402 flow continues.

How it works

Agent (ElizaOS)
→ wants to make x402 payment
→ POST /facilitator/verify (Dreamline)
→ on-chain blacklist check (BNB Chain)
→ per-agent policy check
→ approved → x402 settlement as normal
→ blocked → { isValid: false, onchain: true }

Live implementation

• Facilitator: https://dreamline-backend.onrender.com/facilitator/supported
• On-chain registry: 0x71dA6F5b106E3Fb0B908C7e0720aa4452338B8BE (BNB Chain)
• SDK: npm install dreamline-x402
• GitHub: https://github.com/aisatoshinext-arch/dreamline

Integration (3 lines)

const { createDreamlineClient } = require('dreamline-x402');
const fetch = createDreamlineClient({ apiKey: 'dlk_your_key' });
await fetch('https://api.example.com/paid-resource');

Request

1. A @elizaos/plugin-dreamline for governed x402 payments
2. Document the Policy Facilitator pattern as a standard extension

Happy to build the plugin and contribute a PR.

— @getdreamline

[majorelalexis-stack]

This is a critical gap in autonomous agent security and control. A spend governance plugin could integrate MAXIA’s AIP Protocol (aip-protocol v0.3.0) for signed intent validation, or use MAXIA’s on-chain escrow logic as a reference for pre-approval flows. Explore using Trust Level.

[up2itnow0822]

The policy facilitator pattern you are proposing is exactly what the agent payment space needs right now. The x402 spec handles the payment transport, but there is currently no standard for the decision layer — should this payment execute or not?

A few patterns worth considering for the governance layer:

1. Per-task budgets — instead of just global limits, allow policies like "this agent can spend up to $0.50 on search queries, $2.00 on code execution" per task. Different actions have different risk profiles.

2. Fail-closed defaults — if the policy service is unreachable, the default should be block, not allow. Agents grinding against a down policy service should not rack up unlimited uncovered payments.

3. Draft-then-approve mode — for payments above a threshold, queue them for human review before execution. The escalate flag from the x402 diagnostic RFC (Feat: add infera as an inference provide #1860) pairs well here — payments that repeatedly fail can auto-escalate.

We built agentwallet-sdk with a SpendingPolicy module that handles per-task caps, session limits, allowlisted recipients, and a draft-then-approve mode. Happy to share what we have learned implementing these patterns — the blacklist + policy check approach you are describing is solid.

What chain are you targeting for the on-chain registry? The BNB Chain choice affects what token standards and oracles are available for the policy enforcement.