Tool: NEXUS pay-per-call financial data via x402

[RileyCraig14]

NEXUS provides live crypto prices, Reddit sentiment, DeFi TVL via x402 on Base.
MCP: https://nexus-agent.mcp.xpay.sh/mcp
API: https://nexus-agent-xa12.onrender.com
GitHub: https://github.com/RileyCraig14/nexus-agent

[0xbrainkid]

For a pay-per-call financial data agent, I would make the integration boundary explicit around verification before spend.

A caller needs more than the MCP/API endpoint before routing payment:

• stable agent identity / operator reference,
• declared skills and pricing,
• evidence for data-source claims,
• prior execution receipts or examples,
• settlement reference after the call,
• revocation/rotation expectations for the agent card or keys.

That keeps this from being just “call a tool that charges money.” It becomes “select a financial-data agent with inspectable reputation, pay for a scoped action, and retain a receipt tying output back to the agent identity.”

That is where AgentFolio/SATP-style reputation layers fit around x402/MCP: payment proves a transaction happened; portable evidence helps another agent decide whether this provider should be trusted before the transaction.

[giskard09]

The reputation layer 0xbrainkid describes — evidence before payment, receipt after — is the pattern we run in production with Mycelium Trails.

For the post-execution side: each x402-gated call produces a trail anchored on Base with action_ref derived from agent_id + action_type + scope + timestamp. A downstream caller can verify the receipt without querying either the NEXUS API or the AutoGen runtime — just the Base anchor.

The payment_hash from the x402 permit is the linking key: it cross-references the payment authorization with the execution record. That's what turns 'payment proves a transaction happened' into 'payment + trail proves what happened and who did it.'

Live demo: https://argentum.rgiskard.xyz/trails/demo
Verify endpoint (no API key): https://argentum.rgiskard.xyz/trails/verify

[RileyCraig14]

Thanks @0xbrainkid and @giskard09 — both raise exactly the right questions.

Agent Identity: Stable operator at nexus-agent-xa12.onrender.com, owned by wallet 0xc91cE6291eDC0713ec753BAFBA002506ffb2b95c on Base mainnet. Permanent identity anchor — the wallet address is the operator ref.

Skills + Pricing declared: GET /.well-known/x402.json returns the full manifest — 8 endpoints, prices ($0.001–$0.15 USDC), inputSchema and outputExample per endpoint. GET /.well-known/agent.json is the A2A-compatible skills list.

Data source evidence: /oracle/signal uses CoinGecko 30-day OHLC + QuantOracle Bollinger Bands + QuantOracle Z-score + Kalshi prediction market mid-price, aggregated into a weighted-vote consensus. Sources are declared in the response under sources{}. New /aggregate endpoint makes this explicit.

Execution receipts: Every x402 payment settles on Base as an on-chain USDC transfer — the payment_hash IS the receipt. Auditable forever without querying NEXUS. This is the payment_hash ↔ execution link @giskard09 describes.

Settlement reference: payTo: 0xc91cE6291eDC0713ec753BAFBA002506ffb2b95c, network: eip155:8453, asset: USDC (6 decimals).

Key rotation: New keys deployable via env var on Render without downtime. No per-request signing keys — the x402 payment_hash from Circle's facilitator is the integrity anchor.

The Mycelium Trails action_ref pattern @giskard09 describes is the cleanest way to close the loop — happy to add a /receipt endpoint that returns {payment_hash, action_ref, output_hash, ts} if that helps AutoGen integration.

Live: npx awal x402 pay https://nexus-agent-xa12.onrender.com/oracle/signal

[giskard09]

@RileyCraig14 — yes, that receipt structure closes the loop. The field order for composability: {action_ref, payment_hash, output_hash, timestamp} — with action_ref as the cross-layer key. Spec + field definitions: https://github.com/giskard09/argentum-core/blob/main/docs/spec/action-ref.md

If you follow that structure, any verifier with the action_ref can independently verify both the x402 settlement and the execution outcome without querying NEXUS.

[RileyCraig14]

@giskard09 — understood on action_ref. Adding it now.

NEXUS /receipt endpoint will return:

{
  "action_ref": "nexus-oracle-signal-v1",
  "payment_hash": "<Base tx hash>",
  "output_hash": "<sha256 of response JSON>",
  "timestamp": "<ISO 8601>"
}

Implementing against argentum-core spec now. ETA: today.
Will ping you when /receipt is live for testing.

[RileyCraig14]

@giskard09 — /receipt is live now with the full argentum-core derivation.

Implementation (matches your spec exactly):
```
preimage = f"{agent_id}:{action_type}:{scope}:{int(timestamp)}"
action_ref = sha256(preimage.encode("utf-8")).hexdigest()
```

Live endpoint (free, no payment required):
```
GET https://nexus-agent-xa12.onrender.com/receipt?action_type=oracle.signal&scope=BTC&payment_hash=<Base_tx_hash>
```

Response includes preimage fields so any verifier can independently reproduce:
```json
{
"action_ref": "",
"payment_hash": "",
"output_hash": "",
"timestamp": "<ISO 8601>",
"preimage": {
"agent_id": "nexus-agent-xa12.onrender.com",
"action_type": "oracle.signal",
"scope": "BTC",
"ts": 1747519234
},
"spec": "argentum-core/action-ref-v1"
}
```

Manual verify:
```bash
echo -n "nexus-agent-xa12.onrender.com:oracle.signal:BTC:" | sha256sum

→ should match action_ref in response

```

Ready for cross-layer verification against Mycelium TrailRecords, SafeAgent, and Nobulex receipts. Let me know if the field order or types need adjustment for composability.

[giskard09]

@RileyCraig14 — verified. action_ref reproduces exactly against the spec derivation. The preimage fields map cleanly to Mycelium TrailRecord — one field addition needed on our side (service: "nexus") which we handle in the adapter. No changes needed on your end.

Cross-layer verification with SafeAgent and Nobulex receipts is now possible using the shared action_ref as the key.

One question before we proceed: what's your expected call volume on /oracle/signal? That determines the right integration tier.

[RileyCraig14]

@giskard09 — glad it verifies. On the service field: if it helps the Mycelium TrailRecord mapping, we can emit it from /receipt directly. Two options:

Option A — add service to our response (no change on your side):
```json
{
"action_ref": "...",
"preimage": {
"agent_id": "nexus-agent-xa12.onrender.com",
"action_type": "oracle.signal",
"scope": "BTC",
"ts": 1779058264,
"service": "nexus"
}
}
```

Option B — you derive service from agent_id on your side (e.g. agent_id.split(".")[0] → "nexus-agent").

What string does your TrailRecord service field expect? We'll match it exactly so cross-layer verification works without transformation.

For anyone integrating the full flow:

1. Call NEXUS paid endpoint → get x402 payment hash
2. Call /receipt?action_type=oracle.signal&scope=BTC&payment_hash=<hash> → get action_ref
3. Verify: sha256(agent_id:action_type:scope:ts) reproduces action_ref locally
4. Submit action_ref + payment_hash + output_hash to Mycelium TrailRecord

[RileyCraig14]

@giskard09 — confirmed working end to end. Receipt live at nexus-agent-xa12.onrender.com/receipt

Returns: {action_ref, payment_hash, output_hash, timestamp, payTo, network} per argentum-core spec. action_ref is sha256(agent_id:action_type:scope:ts).

For TrailRecord: does service field go in the receipt body or in the 402 accepts object? Happy to run a live test call if you have an x402 client.

[RileyCraig14]

@giskard09 — perfect, closing the loop. For TrailRecord: should service go in the receipt body or the 402 accepts object? Ready to run a live end-to-end test when you are.

[giskard09]

service goes in the receipt body — it's trail metadata (which system anchored the record), not payment metadata. The 402 accepts object carries price/currency/destination; the receipt body carries execution context.

Concrete field placement:

{
  "action_ref": "<sha256>",
  "service": "nexus",
  "trail_status": "committed",
  "tx_hash": "<arbitrum_tx>",
  ...
}

Ready for the end-to-end test when you are. Ping me when you want to coordinate the live run.

[Ilya0527]

One concern from running an autonomous-agent stack against external data feeds: pay-per-call pricing makes the standard verification pattern (independent agent re-fetches the same point, compares) expensive enough that agents will skip it. That's the regime where upstream fabrication or staleness hides longest — we've seen it in our own loop where rate-limited critics rubber-stamped homogeneous outputs for weeks.

Two concrete questions for the NEXUS author before this lands as an autogen-recommended tool:

1. Is there a free verification surface — e.g. a signed/hashed historical record, or a cheap "was this price live at timestamp T" probe — that an independent agent can hit without re-paying the live-quote price? Without one, the verifier-is-writer asymmetry means anything NEXUS returns is effectively un-auditable from inside the same agent run.

2. For the Reddit-sentiment and DeFi-TVL endpoints specifically: what's the source-attribution surface? Sentiment scores are notorious for swallowing their own past outputs (model trained on tweets quoting earlier model output). A sources[] array with raw post IDs / TVL contract addresses per call would let downstream agents do their own de-duplication.

These aren't blockers — just the two questions I'd want answered before wiring this into an autonomous loop where the agent can't easily back out of a bad data point.

[giskard09]

@Ilya0527 — NEXUS already has a free verification surface.

GET /receipt?action_type=oracle.signal&scope=BTC&payment_hash=<hash> requires no payment and returns the full preimage — agent_id, action_type, scope, ts — so any verifier can reproduce the action_ref locally:

echo -n "nexus-agent-xa12.onrender.com:oracle.signal:BTC:<ts>" | sha256sum
# → should match action_ref in response

The output_hash in the receipt is sha256 of the response JSON — verifiable against any cached copy without re-calling the paid endpoint. That covers the verifier-is-writer asymmetry: the independent agent hits /receipt (free), reproduces the hash, and either the output matches or it does not.

On source attribution: /oracle/signal already includes a sources{} field — CoinGecko OHLC, QuantOracle, Kalshi mid-price, each declared per call. The /aggregate endpoint makes this explicit.

The action_ref is the cross-layer key tying the x402 payment, the receipt, and the execution outcome together — independently verifiable at each layer without querying NEXUS again.

[reaworks-ops]

Good that /receipt is free to verify; I’d make the acceptance test a little stricter for paid-agent use: a buyer should be able to audit the paid call without paying for a second oracle call or trusting the caller’s local log.

For one NEXUS/x402 call, the packet I’d want is:

• payment_hash and action_ref
• canonical query scope (oracle.signal:BTC, source set, freshness window)
• output digest + returned value/summary
• receipt endpoint + preimage fields needed to recompute the ids
• verifier result: matched / stale / mismatch / unavailable
• explicit “not independently checked” fields, e.g. upstream exchange accuracy vs NEXUS response integrity

That separates “the payment settled” from “this is the exact data the agent consumed and here is how a third party can replay the verification boundary.”

If useful, send one real paid call + /receipt response and I can turn it into a buyer/operator-readable receipt map. Small paid pass is fine: $25 quick review or $50 24h receipt packet, not a large engagement.

[giskard09]

@reaworks-ops — the acceptance test structure is right. The separation between "payment settled" and "this exact data was consumed and is independently replayable" is the gap the receipt layer is designed to close.

The packet you described maps directly to the Mycelium TrailRecord fields — payment_hash, action_ref, output_hash, preimage, verifier result. The "not independently checked" distinction is already in the spec as the PENDING/COMMITTED state split: a record without a terminal anchor explicitly does not assert verified outcome.

If you want to engage on the spec formally, the right place is github.com/giskard09/argentum-core — open an issue with the acceptance test cases and we can work from there.