Login

u/PaulieB79

r/ethtrader r/thegraph r/hyperliquid1 r/CryptoTradingBot r/ethdev r/polymarketAnalysis r/Polymarket_news
GraphTally: How The Graph Solved Micropayments for the Machine Economy
▲ 6 r/thegraph

GraphTally: How The Graph Solved Micropayments for the Machine Economy

The World Wide Web is one of the most consequential technologies humans have ever built. Yet the people who designed it overlooked one thing: they built it for humans to use, and that is becoming a problem as automation scales.

The gap is most obvious in payments. Credit card forms, one-click checkout, and QR codes all assume a living person is at the screen, ready to authorize a transaction. Increasingly, that is not who is transacting. A growing machine-to-machine economy is taking shape, driven by autonomous protocols, decentralized applications, and software agents acting on people's behalf. These actors transact very differently from humans. They rarely hold a bank account, and they need to pay on demand only for what they consume, rather than committing to recurring subscriptions for every resource they touch.

Read full blog here https://thegraph.com/blog/graphtally-micropayments-machine-economy/

u/PaulieB79 — 4 days ago
▲ 3 r/ethdev

Two ways to give an AI agent live on-chain data from The Graph (x402, no API key)

The Graph's gateway now speaks x402: an unpaid query returns a 402, the agent signs a ~$0.01 USDC payment, and the data comes back. No account, no key the payment is the auth. I built two ways to use that, aimed at two kinds of builders:

Both are mine and usable now. Genuinely curious what people think: does pay-per-query actually fit agent workflows, or is per-call payment friction a dealbreaker vs. a flat API key? Feedback welcome.

reddit.com
u/PaulieB79 — 6 days ago
▲ 3 r/thegraph

Two ways to give an AI agent live on-chain data from The Graph (x402, no API key)

The Graph's gateway now speaks x402: an unpaid query returns a 402, the agent signs a ~$0.01 USDC payment, and the data comes back. No account, no key the payment is the auth. I built two ways to use that, aimed at two kinds of builders:

Both are mine and usable now. Genuinely curious what people think: does pay-per-query actually fit agent workflows, or is per-call payment friction a dealbreaker vs. a flat API key? Feedback welcome.

reddit.com
u/PaulieB79 — 7 days ago
▲ 3 r/thegraph

Introducing Turbine: Settle large trades at low spread powered by Graph Protocol

https://x.com/PropellerSwap/status/2069414733074112567?s=20

https://docs.turbine.exchange/

Middlemen eat your trading profits

On average, you pay 7–8 bps in spread to trade onchain. Together, we pay $9M per day and $3.2B per year. If you do $80M in weekly volume on a $10M prop fund, you lose $2.8M (28%) to fees.

On large trades, the spread is even higher, not 8bps, but 50, 100, or 500 bps and more.

But swapping should be simple: You sell, I buy. Where does all this cost come from?

Long story short: Middlemen sold us the idea that fast trading is THE way to trade.

Ethereum is game-changing technology, literally, so can we change this game?

Can you buy $1M of ETH/AAVE/UNI without "price impact" (fees)?

You can.

Turbine: Trade Slow and Pay Less

Turbine is built to settle large trades at the lowest spread in finance. Lower than any exchange in DeFi, CeFi, and even TradFi.

Turbine has no continuous settlement, needs no market makers, no arbitrage, and has no hidden fees.

Instead, in Turbine, you settle with other traders and onchain liquidity. Slowly. The slower, the better your price gets.

Settle at zero spread

Turbine settles its orders in batches using onchain liquidity.

Turbine settles you with other traders and with all DeFi liquidity.

  • The deepest liquidity in DeFi: Every block, Turbine settles you in a batch with other Turbine orders and LP and all liquidity in DeFi. → See how Turbine's batch solver (APEX) works.
  • Get paid to wait: Wait for traders in a hurry (and willing to pay a spread) to settle for better than the market mid-price.

Worst case, you pay the spread you pay on other aggregators. Best case, you get paid by fast traders to settle.

Orders run for minutes or days and never get stuck

Turbine orders don't go stale. They follow the market price at a spread that tightens over time.

In Turbine, your order moves with the market, is invisible to frontrunners, and cannot be sniped by fast traders.

  • Orders don’t get stuck: A limit order goes stale: You either overpay, or it doesn't settle. In Turbine, your order follows the market. It pays a low spread and settles by the deadline.
  • Orders read price from fast exchanges: Fast exchanges (like Binance, Hyperliquid, Lighter) tell Turbine the current market price every 500ms ( How the oracle works ).
  • Orders protect themselves from bots: Every order and cancellation waits 6 seconds before it enters Turbine’s book. By then, sitting orders are up to date with the latest CEX market price.
  • Orders are invisible: Your order is stored in Turbine's TEE, only accessible to you and invisible until it settles.

Your order follows the market and settles when the spread is low. The more time you give your order, the more you save.

Long-running orders that don’t go stale make peer-to-peer trades possible.

Trade with Peers Today

Trade slow and pay less.

→ Make your first patient trade ✨

Good prices come to those who wait.

Choose how long you can wait and Turbine optimizes your spread to settle you at lowest cost possible.

About

Turbine is built by PropellerHeads, audited by Trail of Bits and backed by General Catalyst, Delphi, Faculty, Uniswap Labs, Circle, and 82 market makers, traders, and other strategic partners.

Built on

Turbine would not be possible without the work of the teams and researchers who built the tools and produced the research Turbine builds on:

  • Phala: Phala hosts the TEEs that make Turbine both private and verifiable.
  • Uniswap v4: Turbine pools are a custom Uniswap v4 hook . Turbine also flashloans the liquidity to efficiently settle batches from v4 vaults.
  • Oracles: External markets (Binance, BingX, Bitget, Coinbase, Hyperliquid, Kraken, KuCoin, Lighter, and OKX) provide the prices that guide your orders and LP in Turbine.
  • Eric Budish: Among the many researchers whose ideas contributed to Turbine, Eric Budish had the biggest influence. Thank you for your seminal papers.
  • SPEEDEX: Geoffrey Ramseyer's SPEEDEX was an essential reference for Turbine’s batch settlement algorithm APEX.
  • BuilderNet: Turbine batches settle through Flashbot’s trustless builder .
  • Tycho: Tycho ’s indexing and rust native simulation allow Turbine to include AMM liquidity in Turbine batches and simulate at the speed that APEX needs.
  • Fynd: Fynd provides trustless DEX quotes that set your order’s spread and runs alongside APEX to settle your order at the best price.
  • Ethereum: It's unlikely we would have ended up here without Ethereum. Ethereum is anti-middlemen tech, and its example inspired Turbine’s principles.
reddit.com
u/PaulieB79 — 13 days ago
▲ 3 r/thegraph

Substreams - The chain data you need, in your database, backed by a world-class backend.

Getting on-chain data into your database is now the easy part via u/graphprotocol's The Graph Market.

Hosted Sinks is a fully managed Substreams-sink-as-a-service. You point it at a Substreams package and a database, click Deploy, and we run it for you, at scale, securely, with zero ops on your side. Chain data to your tables, live, in minutes, then query it with the SQL tools you already know.

---

What it does

Bring your Substreams package, pick PostgreSQL or ClickHouse, and hit Deploy. That's it. Fresh chain data starts streaming into your tables, and we keep it running, backed by our highly-available and highly-reliable distributed infrastructure. Running a different kind of sink? Let us know so we can prioritize it! Transactional data for your app, columnar analytics for your dashboards, your choice. Works on all chains available on The Graph Market: Ethereum, Base, Solana, and beyond.

No new runtime on your infrastructure, no blockchain plumbing: your Substreams package maps protobuf straight into relational tables, and you read it back with plain SQL. You already have a database, let us connect and fill it for you.

---

How your team benefits

Spin up in minutes, not sprints. Deploy, start, stop, and delete on demand — all self-service from the portal. No infrastructure to provision.

Always correct, fork-aware. Substreams tracks the canonical chain and signals reorgs automatically, so chain reorgs never leave sheared or stale data behind. Inserts, updates, and upserts keep mutable data current. No manual cleanup.

Update without downtime. Edit your package or config in place and we roll it out gracefully. Need a clean slate? Reset and re-sync from your start block.

Secrets stay secret. Your database credentials live in HashiCorp Vault, never in code or config. Injected at runtime, with built-in disaster-recovery export/import.

Multi-tenant by design. Every deployment is isolated to your organization: strict, enterprise-grade separation out of the box.

Full visibility. Live status, per-instance health, and a complete deployment history — created, scaled, updated, restarted — all in the dashboard.

---

What does it cost

Billing is the same as it currently is, pay only for the data coming out of your Substreams. For the next 6 months, we’ll manage the sink for free. After this initial period, each sink will incur a negligible cost per month, confirmed before billing begins.

The bottom line

Stop staffing a platform team to move blockchain data into a database. Hosted Sinks abstracts away the credential management, the scaling, and the re-sync headaches and gives you back a simple form and a Deploy button.

Check the docs to get started today https://docs.substreams.dev/how-to-guides/sinks/hosted-sinks

Your data. Your database. Our infrastructure. Live in minutes.

reddit.com
u/PaulieB79 — 15 days ago
▲ 3 r/thegraph

Onchain Agent Reputation, In One Round Trip

I've been pitching agents to other agents for months. The question that keeps coming back: "How do I know any of this is real?"
Anyone can mint an ERC-8004 identity. Anyone can put up an agent.json. Anyone can claim to provide a service.
But for the first time, whether anyone has actually paid them for it is answerable onchain — and the answer is two GraphQL queries, both against subgraphs on Base, both live on The Graph Network today.

The two primitives that just clicked

ERC-8004 / agent0 — identity https://thegraph.com/explorer/subgraphs/43s9hQRurMGjuYnC1r2ZwS6xSQktbFyXMPMqGKUFJojb?view=Query&chain=arbitrum-one

Every registered agent: identity NFT, owner wallet, agentURI metadata, feedback events, owner history.

  • Subgraph: agent0-base-mainnet
  • Deployment: QmcLwgyKn3RnyhkkSwLYscP9dL1Fc6omvfC9bFRgcK1e7u
  • Schema: Agent, AgentRegistrationFile, Feedback, Validation

This is the decentralized identity layer. Solved. But identity ≠ reputation. Knowing an agent exists tells you nothing about whether anyone has ever paid them.

x402 Base subgraph — https://thegraph.com/explorer/subgraphs/Cb56epg3EvQ6JRpPfknbkM54QxpzTvLa7mwKNQQfUyoj?view=Query&chain=arbitrum-one

receipts, Every EIP-3009 USDC settlement on Base. Payer, recipient, facilitator, amount, batch detection, escrow tracking.

  • Deployment: QmcE24HARdXXnziPii9bWFRV6njfWW82H1RKPe5x9hBkUN
  • Schema: X402Payment, X402AddressSummary, Facilitator, X402DailyStats
  • Tens of millions of settlements indexed, growing in real time

This is the receipt layer. Brand new. The piece that's been missing.
Compose them and you get the missing reputation primitive: did anyone actually pay this agent for the work they claim to do?
Has this agent ever been paid? (the fundamental query)
Start with the agent's identity:

graphql

# Query agent0 to find Graph Advocate (token #41034 on Base)
{
  agents(where: { id: "8453:41034" }) {
    agentId
    agentWallet
    agentURI
    owner
    totalFeedback
    createdAt
  }
}

Returns:

JSON

{
  "agents": [{
    "agentId": "41034",
    "agentWallet": "0x575267eed09c338fae5716a486a7b58a5749a292",
    "agentURI": "ipfs://QmXuFpFMR5vDt7sHq9JhwuCBZvCNk29JQvboz9oXnEtwwE",
    "owner": "0x575267eed09c338fae5716a486a7b58a5749a292",
    "totalFeedback": "1",
    "createdAt": "1775578091"
  }]
}

You now have an identity. Resolve agentURI to extract the declared payTo address from the registration JSON, then cross-reference it in the x402 subgraph:

graphql

# x402 → has this payTo address received any onchain settlements?
{
  x402AddressSummaries(
    where: { address: "0x0ff5a6ecef783bba35463ec2f8403b9b5e9e7c86", role: RECIPIENT }
  ) {
    totalPayments
    totalVolumeDecimal
    firstPaymentTimestamp
    lastPaymentTimestamp
  }
  recentPayments: x402Payments(
    where: { to: "0x0ff5a6ecef783bba35463ec2f8403b9b5e9e7c86" }
    first: 10, orderBy: blockNumber, orderDirection: desc
  ) {
    blockTimestamp from amountDecimal transferMethod
    facilitator { name }
  }
}

If the response is null or zero — you're looking at an identity nobody has paid. That's data. That's the difference between a registered agent and an active agent.
Five more queries that didn't exist a month ago

  1. The top-earning facilitators

graphql

{
  facilitators(first: 10, orderBy: totalSettlements, orderDirection: desc) {
    id name isActive totalSettlements totalVolumeDecimal
  }
}

Live, real numbers as of today:  

text

| Facilitator | Settlements | USDC volume |
| --- | --- | --- |
| Daydreams | 11.8M | $2.76M |
| Coinbase (9 addresses) | ~4.4M each | ~$1.6M each |

This is the leaderboard of who's actually shipping x402 infrastructure on Base. Not who says they're shipping. Who is.
2. Customer diversity — the shape of the payer graph

graphql

{
  x402Payments(
    where: { to: "0x0ff5a6ecef783bba35463ec2f8403b9b5e9e7c86" }
    first: 100, orderBy: blockNumber, orderDirection: desc
  ) {
    from amountDecimal blockTimestamp
  }
}

Group the response by from wallet:

  • 1 unique payer → self-paid sybil (or single-customer)
  • 5–10 unique payers → small but real
  • 50+ unique payers → genuine multi-customer agent

A single-payer wallet that paid 1000 times tells you nothing. A 100-payer wallet that each paid 10 times tells you the agent serves a market. The graph shape IS the reputation signal.
3. Sybil filter — registered but never used

graphql

# 8004 agents that have a registration file
{
  agents(first: 100, orderBy: createdAt, orderDirection: desc) {
    id agentWallet agentURI createdAt totalFeedback
  }
}

For each, resolve payTo and check x402:

graphql

{
  x402AddressSummary(id: "<role-prefix>0x...") {
    totalPayments
  }
}

If x402AddressSummary is null but the 8004 agent is older than a week — registered identity, zero economic activity. That's almost certainly a name-squatter or abandoned bot.
Filter these from any marketplace and you've already eliminated 80% of the noise.
4. The launch detector — "trending" agents

graphql

{
  x402AddressSummaries(
    where: { role: RECIPIENT, firstPaymentTimestamp_gte: "1780000000" }
    orderBy: totalPayments, orderDirection: desc
    first: 25
  ) {
    address totalPayments totalVolumeDecimal firstPaymentTimestamp
  }
}

(The timestamp is "7 days ago" in unix seconds.)
Return: every address that received its first x402 payment in the last week, sorted by activity. Closest thing the agent economy has to a "trending" tab.
Join with agent0 to filter only known agents. You just built the agent equivalent of Product Hunt — but ranked by money flowing, not upvotes.
5. Facilitator concentration risk

graphql

{
  x402Payments(
    where: { to: "0x0ff5a6ecef…" }
    first: 1000
  ) {
    facilitator { id name }
  }
}

Group by facilitator.name. An agent whose payments route 100% through Coinbase dies when Coinbase has an outage. An agent split 60/40 across Coinbase and Daydreams survives. Concentration is risk; risk is a number you can put on a dashboard.
Compose it from anywhere
Hit both subgraphs from a single client. Working Python — about 30 lines:

Python

import asyncio
import httpx

GRAPH_KEY = "<your-graph-api-key>"
AGENT0 = "43s9hQRurMGjuYnC1r2ZwS6xSQktbFyXMPMqGKUFJojb"
X402_BASE = "Cb56epg3EvQ6JRpPfknbkM54QxpzTvLa7mwKNQQfUyoj"

GW = f"https://gateway.thegraph.com/api/{GRAPH_KEY}/subgraphs/id"

async def query(subgraph_id: str, q: str, variables=None):
    async with httpx.AsyncClient(timeout=15) as c:
        r = await c.post(f"{GW}/{subgraph_id}",
                         json={"query": q, "variables": variables or {}})
        return r.json()["data"]

async def agent_reputation(agent_id: str):
    # 1. identity
    a = await query(AGENT0, """
      query($id: ID!) {
        agent(id: $id) {
          agentId agentWallet agentURI totalFeedback createdAt
        }
      }""", {"id": agent_id})
    if not a["agent"]:
        return {"exists": False}

    pay_to = a["agent"]["agentWallet"].lower()

    # 2. receipts
    x = await query(X402_BASE, """
      query($addr: Bytes!) {
        x402AddressSummaries(where: { address: $addr, role: RECIPIENT }) {
          totalPayments totalVolumeDecimal
          firstPaymentTimestamp lastPaymentTimestamp
        }
        recent: x402Payments(where: { to: $addr }, first: 50,
                             orderBy: blockNumber, orderDirection: desc) {
          from amountDecimal blockTimestamp facilitator { name }
        }
      }""", {"addr": pay_to})

    summary = (x["x402AddressSummaries"] or [None])[0]
    unique_payers = len(set(p["from"] for p in x["recent"]))

    return {
        "identity": a["agent"],
        "total_paid_calls": int(summary["totalPayments"]) if summary else 0,
        "lifetime_usdc": float(summary["totalVolumeDecimal"]) if summary else 0.0,
        "unique_payers_recent": unique_payers,
        "sybil_likely": (summary is None and a["agent"]["totalFeedback"] == "0"),
    }

print(asyncio.run(agent_reputation("8453:41034")))

That function — 30 lines, two HTTP calls — is a complete agent-reputation API. Drop it into anything: a marketplace filter, a routing decision, an alerting rule, a reputation badge in a UI.
Why this changes things
Reputation has been the open problem for the agent economy. We had identity (ERC-8004). We had payments (x402). But we didn't have receipts in a queryable form.
Now we do. Two subgraphs, both live on Base, both indexed on The Graph Network, both composable in a single client-side query.

  • Agent marketplaces can filter sybils with a single boolean check
  • Payment routers can choose recipients by track record, not metadata
  • Users delegating money to agents can verify the agent has been delegated to before
  • Agents themselves earn onchain credit history with every paid call — recurrent paid calls are reputation

The agent economy is no longer just identity + payment rails. It's identity, payments, and receipts.
Try it
Both subgraphs are public on The Graph Network. Query them yourself — no auth beyond a Graph API key:

  • agent0-base-mainnet: 43s9hQRurMGjuYnC1r2ZwS6xSQktbFyXMPMqGKUFJojb
  • x402-base: Cb56epg3EvQ6JRpPfknbkM54QxpzTvLa7mwKNQQfUyoj

Or hit the composed lookup as a paid x402 endpoint:

Bash

curl -sS -X POST https://graphadvocate.com/onchain-x402/address \
  -H 'Content-Type: application/json' \
  -d '{"address":"0x0FF5A6ecef783BBA35463ec2F8403B9B5e9e7C86"}'

$0.01 USDC via x402, no API key, designed for agent-to-agent calls. POST {address} and you get lifetime stats, recent payments in both directions, facilitator metadata, and indexer freshness — all in one round trip.

Bullish on the stack.

u/PaulieB79 — 1 month ago
▲ 1 r/thegraph

The Data You Need Isn't in the API. Build the Subgraph. (Aave V4 Case Study)

https://preview.redd.it/t53i1y8ewa3h1.png?width=1774&format=png&auto=webp&s=870d9b4bd57240b696e64a47564dbd3c51130317

A note for anyone building agents, bots, dashboards, or just trying to answer hard questions about a protocol and hitting a wall.

The wall is always the same.

I needed to know which MEV bots were liquidating u/aave V4 borrowers and across which sub-pools. Simple question. I went to api.aave.com/graphql

Aave's own official API, and it returned most of the data but not all.

It gave me the basics: user, liquidator, collateralReserve, debtReserve, and some aggregated collateral and debt amounts.

What it didn’t give me was the real detail, the share-level breakdown (drawnSharesLiquidated, collateralSharesLiquidated, collateralSharesToLiquidator), the receiveShares flag, or the full PremiumDelta tuple, including the V4-unique risk-premium reset moment. In total, five raw on-chain fields plus the entire PremiumDelta were simply dropped.

And there was still no way to aggregate liquidator behavior across spokes the activities query has no liquidator filter.

How do I fill the gap?

Every protocol's official API is built to serve their own dapp. Aave's GraphQL exists to power

app.aave.com. Uniswap's API exists to power their interface. They're not hostile, just maybe not built for you.

If you're the analyst, the agent operator, the bot runner, the risk team, the researcher, your questions always involve fields the dapp doesn't render. So the API never has them.

The friction patterns you'll keep hitting

  • No event stream. Protocols publish current state. You usually want what changed when, and why.
  • No liquidator identities or cross-pool aggregation. Apps don't surface them. You very much do.
  • No parameter-change history. The app shows current risk caps. You need to know when they moved, by how much, and what fired right after.
  • Pre-bucketed aggregations. Most APIs give you weekly or daily roll-ups. Your alpha is in the hour or the block.

These aren't bugs. They're the wall.

The realization

The data is on-chain. It's always on-chain.

Every state change in a smart contract emits an event. Those events are public, free, and indexed by every Ethereum node on the planet. The "wall" isn't the data, it's the API in front of the data.

A subgraph lets you bypass the API entirely. You define your own schema, you index the events you care about, you serve your own GraphQL endpoint. No permission required. No business deal. No protocol-team sign-off.

And on u/graphprotocol , you can ship one in a day.

The 5-step playbook

I just did this end-to-end for Aave V4. The whole loop took less than a working day.

  1. Spot the gap. What question can't you answer with the official API? Write it down.
  2. Find the contract events. Open the protocol's GitHub or Etherscan. Find the interface files. Every state change you care about has an event with the fields you need.
  3. Define entities. Schema first. Bytes for IDs, u/derivedFrom for reverse relations, u/entity (immutable: true) for append-only event records. The Graph's best practices basically write themselves.
  4. Wire the handlers. One AssemblyScript function per event, roughly ten lines each:

​

typescript

export function handleLiquidationCall(event: LiquidationCallEvent): void {
  const liq = new LiquidationCall(event.transaction.hash.concat(/* logIndex */));
  liq.user = event.params.user;
  liq.liquidator = event.params.liquidator;
  liq.debtAmountRestored = event.params.debtAmountRestored;
  liq.premiumSharesDelta = event.params.premiumDelta.sharesDelta;
  // ...the rest of the on-chain tuple
  liq.save();
}

  1. Deploy.

    bash

    graph codegen && graph build && graph deploy <your-slug>

Free on Subgraph Studio. Live in minutes. Indexed and queryable as soon as it catches up to chainhead. Publish it to the decentralized network and any indexer can serve it including yours.

What I built and the gaps it filled, with real data pulled today

I called it aave-v4-omnigraph. Here's what it actually returned when joined with AaveKit's official API, in queries I ran while writing this post. Every block number, address, and amount below is real.

  1. "Why did my borrow rate just spike?"

Aave's official API tells you the current state. The Main spoke USDC market right now: $3,909,054 supplied, $3,390,993 borrowed, 86.7% utilization, 3.85% borrow APY. That's at the kink in the IR curve one more draw and the rate moves sharply.

So who pushed it there? The subgraph shows the answer:

plaintext

block 25168990: DRAW 15,600 USDC on Main
block 25168622: DRAW    150 USDT on Main
block 25168385: DRAW    100 USDT on Main

Aave's app tells you the rate is 3.85%. The subgraph tells you which transactions pushed utilization to where it is and how close you are to the next vertical move.

  1. "Is a specific liquidator hunting Aave V4 users?"

Real query result, V4 since launch:

plaintext

Top liquidators:
  0x36331e29...   19 liquidations  →  Main×11, Bluechip×6, Gold×2
  0x1724d296...    3 liquidations  →  Bluechip×1, Main×1, Etherfi×1
  0xbd32122b...    2 liquidations  →  Bluechip×1, Forex

One bot `0x36331e29`... has executed roughly 60% of all V4 liquidations so far, across three sub-pools. Aave's own API doesn't surface that. Your agent can now check whether your spoke is in this bot's working set before your health factor hits 1.05.

  1. "Did Aave just change a risk parameter that affects me?"

&#8203;

plaintext

"Did Aave just change a risk parameter that affects me?"

Real change captured at block 25,142,050:

Core hub adjustments:
────────────────────────────────────
→ Bluechip   drawCap raised from 1,000,000 → 1,250,000 USDC
→ Etherfi    drawCap = 8,500
→ Lido       drawCap = 4,800

Aave's API tells you the current cap is 1.25M. The subgraph tells you when it was 1.0M, when it changed, and what transaction did it. Difference between "your cap is X" and "your cap just changed, re-evaluate."

  1. "Who's getting authorized to control other users' positions?"

Real entries from the last hour:

plaintext

Who's getting authorized to control other users' positions?

Recent approvals (last hour):

Block       User            → Manager         On
────────────────────────────────────────────────────
25172057    0x3a7fa05f...   0xe68ab4f9...     Main
25171984    0x527ed5b9...   0xe68ab4f9...     Bluechip
25171979    0x527ed5b9...   0xe68ab4f9...     Main
25170940    0xeb1acac4...   0xe68ab4f9...     Bluechip
25170783    0x82ab58a9...   0xe68ab4f9...     Main

Four distinct users authorized the same Position Manager (0xe68ab4f9...) across both Main and Bluechip in under an hour. That's a vault aggregator or auto-leverage product actively onboarding. AaveKit gives you a current "is X my manager?" check. The subgraph gives you the growth curve of that manager's user base public counterparty intelligence.

  1. "Which spokes treat liquidators most aggressively?"

Cross-spoke comparison in one query (impossible from AaveKit):

plaintext

Which spokes treat liquidators most aggressively?

Spoke      targetHF    HFmaxBonus    bonusFactor
────────────────────────────────────────────────────
Gold       1.308       0.900         90%
Main       1.240       0.900         90%
Bluechip   1.174       0.900         90%
Lombard    1.062       0.990         100%
Etherfi    1.019       0.990         100%
Lido       1.014       0.990         100%

Conservative collateral spokes (Gold, Main, Bluechip) maintain higher health-factor buffers and pay 90% bonus. Aggressive LST-yield spokes (Lido, Etherfi, Kelp) run tighter, pay full bonus. That's V4's actual risk-stratification picture. No dashboard surfaces it.

Bonus: the schema is ready for events that haven't fired yet:

  • UpdateUserRiskPremium: 0 events. No user has crossed the riskPremiumThreshold on any spoke.
  • MintFeeShares, Sweep, EliminateDeficit, spoke-side ReportDeficit: 0. Protocol fee accrual hasn't hit the mint threshold; no deficits socialized.

When the first deficit fires, the agent watching this subgraph gets the alert before anyone reading the Aave forum does.

How does an agent pay for it with no API key?

The Graph just shipped an x402 gateway.

Any agent that holds USDC on Base can query this subgraph over HTTP no API key, no signup, no backend account. The agent pays per query in USDC on Base, the indexer earns the fee.

Plug it into an MCP server (one tool, ~40 lines) and the autonomous side becomes trivial:

typescript

server.registerTool("get_v4_hub_flows", {
  description: "Aave V4 Hub&lt;-&gt;Spoke liquidity routing events",
  inputSchema: { spokeName: z.string().optional(), sinceMinutes: z.number().optional() }
}, async ({ spokeName, sinceMinutes }) =&gt; {
  return queryOmnigraph({ spokeName, sinceMinutes });
});

Now your borrower-protection bot, your risk-monitoring agent, your DAO surveillance agent, all of them, pay a few cents per query to get the V4 data they need. No gatekeeper between the data and the actor that needs it.

This is the agent-economy stack working end-to-end:

  • The Graph indexes the protocol's on-chain events into a queryable subgraph
  • x402 turns the gateway URL into a paid endpoint
  • MCP wires the paid endpoint into any autonomous agent

The bot that protects you from getting liquidated doesn't need Aave's permission, doesn't need your API key, and doesn't need to be a person. It just pays one cent and asks.

Why does this matters for Aave users specifically?

When the data behind a protocol becomes openly queryable and pay-per-call, three things shift:

  1. Defense scales to the small user. Today, only whales can afford someone to watch their position 24/7. Tomorrow, a few-dollars-a-month agent does it for everyone, with the same data the MEV firms use. A user with $5k on Main can monitor the same liquidator-bot working set as a user with .
  2. Risk teams stop being a private utility. Gauntlet and Chaos Labs sell protocols the analyses that the subgraph plus an agent can now do publicly.
  3. Governance gets a real-time witness. Every parameter change is in the subgraph, every config bump is queryable. DAOs become harder to influence quietly.

The closer

The data is there. The gateway is there. The payment rail is there.

The missing piece every time is somebody noticing the gap and building the subgraph that fills it.

Now it's you.

If you want a reference implementation, aave-v4 is open source:

github.com/PaulieB14/aave-v4-omnigraph

Live on the decentralized network as subgraph

2Gu5HCAnWrNk2pXidscdhNEQhrwLgMKmssuCe9JhZhAe

One day of work to fill a gap nobody else had filled.

Pick the question your dapp's API can't answer. Build the subgraph that answers it. Wire it to your agent. Let the agent pay for itself.

https://thegraph.com/

reddit.com
u/PaulieB79 — 1 month ago
▲ 9 r/thegraph

Token API v3.18.0 is out today! Batched filters, contract holder detection, and cleaner pool data

New Token API release from Pinax. Highlights for anyone building with it:

https://pinax.network/products/api

Batched filter params Polymarket (3 endpoints) and Hyperliquid (8 endpoints) now accept repeated keys or CSV — ?token_id=a,b instead of firing N requests. Big quality-of-life win for anyone pulling positions or markets at scale.

is_contract flag on /v1/evm/holders You can now tell contract holders apart from EOAs without a second lookup. Useful for filtering out LPs, vaults, and protocol-owned addresses when you're trying to count actual users.

SVM pools get input_decimals and output_decimals Finally — proper decimal context inline. No more cross-referencing token metadata to format pool data correctly.

Fixes worth flagging

  • Polymarket SQL realigned with substreams v0.4.0 (asset_id is now UInt256, positions read all-time window)
  • NFT transfer amount is now a string to preserve UInt256 precision
  • /v1/evm/pools no longer returns CoW Protocol or DODO Router pseudo-pools (these were polluting results if you were aggregating real liquidity)

Docs The value field is now explicitly documented as decimal-scaled (amount / 10^decimals), NOT a USD price. Worth re-checking any code that assumed otherwise.

Release: https://github.com/pinax-network/token-api/releases/tag/v3.18.0

Anyone else using this for agent / dashboard workflows? Curious what you're building.

u/PaulieB79 — 2 months ago
▲ 4 r/thegraph

An agent can now go from question to onchain data in one round-trip with x402 pay

https://preview.redd.it/an7i46opx50h1.png?width=680&format=png&auto=webp&s=d5c52f7757ac1cd986643ba096685468013f9416

No API key. No signup. The wallet does the auth.

The Graph's x402 gateway is live in production. Pay-per-query subgraph access, settled in USDC on Base, with no account required. Pair it with discovery tooling and an AI agent can go from a natural-language question to onchain data in two steps.

🛠 What's new: x402 gateway in production

gateway.thegraph.com/api/x402/subgraphs/id/{id} accepts pay-per-query access via the x402 protocol.

The official docs frame the use case plainly: x402 is for "autonomous agents and short-lived processes that can't store long-term credentials" and "per-query workloads where pre-purchased credits don't fit the access pattern."

That's exactly the agent shape, and it's now a first-class access pattern on the gateway.

🧭 Pairing it with discovery

x402 handles payment. Discovery — "which of 15K subgraphs do I even hit?" — is what I've been building

subgraph-registry-mcpfor. It's my own project, not a Graph product. It classifies the registry by domain / network / protocol-type and exposes a recommend_subgraph tool that agents can call directly.

The registry SQLite blob is hash-pinned against a SHA-256 baked into the npm package, so agents can verify integrity before loading.

The two pieces compose. Together, the agent workflow runs in two steps.

⚡ The combined workflow

markdown

Agent: "Best subgraph for Uniswap V3 on Arbitrum?"

Step 1 — discovery (no key, no payment):
  call subgraph-registry-mcp.recommend_subgraph
  → returns id=HMuAwufqZ1YCRmzL2SfHTVkzZovC9VL2UAKhjvRqKiR1
    + reliability score + suggested entities

Step 2 — execute (no key, $0.01 USDC):
  POST gateway.thegraph.com/api/x402/subgraphs/id/HMuAwufqZ1...
       { query: "{ _meta { block { number } } }" }
  → 402 + payment-required header
  → client signs EIP-3009 transferWithAuthorization for $0.01 USDC on Base
  → re-POST with Payment-Signature header
  → 200 + GraphQL data

No API key. No signup form. No paid plan.

The wallet does the auth.

🧾 Live receipt

I ran the flow against the gateway, paying $0.01 USDC from a Base wallet, and got back:

json

{ "_meta": { "block": { "number": 45743214, "timestamp": 1778275775 } } }

Real subgraph data. Real onchain settlement. Total wall-clock ~3 seconds. The settlement reference lives in the response's x-payment-response header, auditable on Base.

From code, it's about as much ceremony as a normal fetch:

json

import { createGraphQuery } from '@graphprotocol/client-x402'

const query = createGraphQuery({
  endpoint: 'https://gateway.thegraph.com/api/x402/subgraphs/id/HMuAwufqZ1YCRmzL2SfHTVkzZovC9VL2UAKhjvRqKiR1',
  chain: 'base',
})
const result = await query('{ tokens(first: 5) { symbol } }')

The client handles the 402 → sign → resend dance. Your code only sees the data.

🚀 What this unlocks

Pay-per-query is the foundation. The interesting layer is what gets built on top of it:

  • An autonomous wallet-profiling agent can query 50 protocols' subgraphs in a session for ~$0.50 — settled per-call, no monthly minimums.
  • A trading agent doing pre-trade research pays only for the queries it actually runs.
  • Agent-priced products become composable end-to-end. The upstream subgraph cost is now itself x402, so margins are calculable from query to user.

Agents that operate on metered USDC — discovery free, execution paid — are a different shape of consumer than humans on monthly plans, and the infrastructure for them is now here.

🛑 When to use which

x402 is for the agent-shaped slice of the workload: short-lived processes, per-query economics, no long-term credentials.

For sustained, high-volume application use, the existing API-key flow is the right shape — bulk pricing, no per-call signing overhead, established billing flow.

Two access patterns. Two payment shapes. Same data.

📚 Further reading

reddit.com
u/PaulieB79 — 2 months ago
▲ 8 r/thegraph+1 crossposts

Big drop from Pinax Network today. Hyperliquid joins EVM and Solana as a top-level data domain on the Token API, with full HyperCore order-flow coverage. If you're building anything against HL data, this is a serious step up.

🟢 What's new with Hyperliquid

The new /v1/hyperliquid/* family covers core perps, spot pairs (@N), and builder-deployed DEXs (&lt;dex&gt;:&lt;symbol&gt;) under one consistent coin parameter.

Grouped into four areas:

📊 Markets

Discover markets, pull candles, open interest, the full trade-fill stream, and liquidation history.

  • /dexes
  • /markets
  • /markets/ohlc
  • /markets/oi
  • /markets/activity
  • /markets/liquidations
  • /markets/liquidations/ohlc

👤 Users

Per-trader stats (volume, fees, realized PnL, funding, liquidations) in profile mode (one address) or leaderboard mode (top traders), plus a unified balance-event feed across bridge deposits, withdrawals, vault flows, liquidations, and funding payments.

  • /users
  • /users/positions
  • /users/activity

🏦 Vaults

Lifetime deposit / withdrawal / distribution stats per vault and per depositor.

  • /vaults
  • /vaults/depositors

🌐 Platform

Cross-market, cross-DEX time series of platform-wide volume, fees, trade counts, and liquidations.

  • /platform

> New builder DEXs auto-appear via /v1/hyperliquid/dexes — no API release needed on Pinax's side when new ones launch.

🚀 The bullish part

Market discovery (/dexes and /markets) is free and unauthenticated. You can build a Hyperliquid market browser without provisioning a key. That's a low floor for anyone wanting to ship.

🛠 Other wins in v3.17.0

  • 🐛 Fixed an OHLC duplicate-row bug on /v1/evm/pools/ohlc and /v1/tvm/pools/ohlc. Un-merged historical token-metadata versions were multiplying candles. Confirmed end-to-end on USDC/WETH mainnet.
  • ☀️ 5 new Solana DEXs in protocol filters on /v1/svm/swaps and /v1/svm/pools: meteora_daam, meteora_amm, byreal, moonshot, pancakeswap.
  • 🤖 AI-agent-ready docs: /llms.txt (llms.txt convention), /SKILLS.md (table-driven endpoint catalog by domain), and /openapi is now self-documented. Coding agents can discover capabilities without scraping HTML.

🔭 The bigger picture

EVM. Solana. TVM. Polymarket. And now Hyperliquid — all behind one API surface, with a docs layer designed for LLMs and agents to consume directly.

The data graph keeps widening.

📖 Full release notes: https://github.com/pinax-network/token-api/releases/tag/v3.17.0

reddit.com
u/PaulieB79 — 2 months ago
▲ 10 r/polymarketAnalysis+2 crossposts

https://pinax.network/en/products/prediction-market-api

Production-grade Polymarket data — markets, prices, activity, and P&L — through a single HTTP API

Power AI trading backtests, copy-trading apps, and portfolio dashboards with on-chain Polygon data enriched with Polymarket metadata. Part of the Token API.

  • ✓Read-only REST endpoints covering markets, OHLCV, open interest, activity, positions, and platform aggregates
  • ✓On-chain event data from Polygon, enriched with Polymarket scraper metadata
  • ✓Scales from one-off research scripts to always-on trading agents
u/PaulieB79 — 2 months ago
▲ 5 r/thegraph

Have your agent check out Graph Advocate for your on chain data needs from Graph Protocol

Ask any blockchain data question in plain English. Get back the right subgraph, a ready-to-run GraphQL query, and — when possible — the live answer. Paid per call in USDC on Base via x402.

https://docs.graphadvocate.com/

u/PaulieB79 — 2 months ago
▲ 5 r/thegraph

Tycho Article DEX liquidity is *brutally* complex — prices flip every block, reorgs wreck your data, and most teams still run their own nodes just to get a sane price quote. 😵‍💫

Tycho on Substreams just killed that entire problem.

One streaming source. Real-time liquidity across DEXes. Zero infra to maintain.

Solvers, aggregators, market makers — this is the unlock.

MVP already live, public beta Q2. The Graph’s 2026 roadmap is cooking 🔥

Who’s integrating first?

reddit.com
u/PaulieB79 — 2 months ago
▲ 6 r/thegraph

Lodestar Dispatch is permissionless Arbitrum RPC paid per-call in GRT. lodestar-dashboard.com/dispatch

Setup:

Deposit $GRT to PaymentsEscrow on @arbitrum

Add to wallet: gateway.lodestar-dashboard.com/rpc/42161

Make calls. No keys. No accounts. No rate limits.

reddit.com
u/PaulieB79 — 2 months ago
▲ 9 r/thegraph

https://www.lodestar-dashboard.com/blog/how-to-build-a-horizon-data-service

A complete technical walkthrough of building a production Horizon data service — from Solidity contract to off-chain payment collection — drawn from two real implementations: Dispatch and SubstreamsDataService.

The Graph's Horizon upgrade (GIP-0066, live December 2025) turned the protocol into a permissionless data marketplace. https://thegraph.com/blog/graph-horizon/

Before Horizon, The Graph had one type of data service: subgraphs. After Horizon, anyone can build a new type of data service — JSON-RPC endpoints, streaming data pipelines, oracle feeds, ZK proofs — and plug directly into the existing economic infrastructure. Same staking layer. Same payment layer. Brand new service.

u/PaulieB79 — 2 months ago
▲ 8 r/thegraph

https://thegraph.com/blog/community-builder-queried-defi-lending-protocols-subgraphs-mcp/

A case study in what becomes possible when standardized Subgraphs and open infrastructure meet AI-native tooling.

TLDR: A community builder named u/PaulieB set out to solve one of DeFi's oldest data problems: every lending protocol speaks a different language. By combining Messari's standardized Subgraphs on The Graph's decentralized network with a Model Context Protocol (MCP) server, the result was a single tool that lets any AI agent query live lending data across 90 protocol deployments on 15 chains, in plain English, with no custom adapters required.

u/PaulieB79 — 3 months ago