Xona Integration
DAEMON should treat Xona as the resource layer for agents and Meterflow as the control plane that makes those resources safe to buy per call.
Clean positioning#
Xona is positioned around agentic commerce, x402 resources, paid AI endpoints, and agent-accessible resources. That maps directly to Meterflow's product surface: meters, receipts, provider revenue, agent budgets, allowlists, spend caps, payment failures, and visibility around paid API usage.
The sharp integration story is not a generic partner card. Xona supplies the resources, Meterflow wraps those resources with billing and policy controls, and DAEMON becomes the builder workspace where agents can use them in real projects.
| Product | Role | What users get |
|---|---|---|
| Xona | Resource layer | Agent-callable APIs and resources such as creative generation, token data, Solana Pulse, brand assets, token news, PumpFun movers, and token signals. |
| Meterflow | Control plane | x402/MPP pricing, route allowlists, spend caps, receipts, provider revenue views, policy failures, and paid-call audit trails. |
| DAEMON | Workspace layer | Project-aware agents that can discover approved resources, run against a budget, call paid APIs, and attach receipts to shipped work. |
Why this is good#
For Xona users
Xona resources become safer to consume because teams can set budgets, enforce policy, understand failed payments, and see what each agent spent.
For Meterflow users
Meterflow gets a clear resource marketplace use case: real agent endpoints with pricing, receipts, provider revenue, and budget controls.
For DAEMON users
Builders can use paid agent tools from inside the workspace without turning each API call into a manual checkout or unmanaged wallet flow.
For providers
Resource owners can expose paid endpoints to agents while keeping usage, revenue, and policy state visible.
DAEMON workflow#
- A builder opens DAEMON and creates or selects a project.
- DAEMON shows Xona resource packs as available agent resources, with Meterflow policy and budget status next to them.
- The builder chooses a resource pack, sets a daily or task-level spend cap, and selects which agents are allowed to call it.
- When an agent needs a Xona resource, DAEMON requests a Meterflow policy check before the call is made.
- Meterflow enforces the route allowlist, budget, payment protocol, and receipt policy.
- The Xona endpoint handles the paid resource call and returns the result to the DAEMON agent workflow.
- DAEMON stores the result with Meterflow receipt metadata so the project has a useful audit trail.
Resource pack model#
DAEMON should expose Xona through named resource packs instead of loose links. A pack can group related endpoints, recommended budgets, agent permissions, and the Meterflow policy needed to call them safely.
| Pack | Use | Default policy |
|---|---|---|
| Market intelligence | Token data, token signals, token news, PumpFun movers, and Solana Pulse for research agents. | Read-only, project allowlist, daily cap, receipt required. |
| Creative pipeline | Image, video, brand kit, and campaign assets for launch or content agents. | Higher per-call cap, explicit project approval, receipt required. |
| Builder automation | Paid resources used by coding, launch, docs, and research agents inside a DAEMON project. | Task-level budget, agent allowlist, spend summary on completion. |
Meterflow contract#
DAEMON should call Xona resources through a Meterflow-aware contract so paid requests are observable and enforceable before an autonomous agent spends.
const policy = await meterflow.evaluatePolicy({
provider: "xona",
resourcePack: "market-intelligence",
route: "/xona/token/pumpfun-movers",
method: "GET",
agentId: daemonAgent.id,
projectId: daemonProject.id,
paymentProtocol: "x402",
recordReceipt: true,
});
if (!policy.allowed) {
throw new Error(policy.reason);
}
const result = await daemon.callPaidResource({
provider: "xona",
route: policy.authorizedRoute,
receiptPolicy: policy.receiptPolicy,
});Product boundaries#
- DAEMON should own project context, agent UX, workspace state, wallet prompts, and task receipts.
- Xona should own the paid resources, endpoint quality, provider catalog, and resource-specific output.
- Meterflow should own meters, pricing policy, x402/MPP payment handling, receipts, spend caps, provider revenue, and policy failures.
- DAEMON should not hide payments. Every paid call should leave visible budget and receipt state tied to a
projectId,agentId, and task.
Current status#
| Capability | Status |
|---|---|
| Xona docs page | Documented as the resource layer for DAEMON agent workflows. |
| Meterflow x Xona boundary | Documented as the first partnership path and control-plane layer. |
| DAEMON next step | Documented as the workspace where builders discover, budget, call, and ship with Xona resources. |
| Automatic spending | Not enabled by default. Paid resource calls should require Meterflow policy checks, budget limits, and receipts. |