Prompt2API

Demo

About

Prompt2API turns a plain-English request into a live blockchain data API that AI agents can access and pay for automatically. Creating a custom onchain dataset normally requires writing event decoders, configuring an indexing pipeline, validating it against blockchain data, operating storage infrastructure, and building an API. Prompt2API turns that process into a prompt-driven workflow. A user begins by describing the data they need, such as: “Track Deposit and Withdraw events for this ERC-4626 vault on Base and provide raw events and hourly flows.” Prompt2API interprets the request, checks whether it is supported, and creates a reusable data pipeline. If required information is missing, it asks a follow-up question. Requests outside the supported scope are rejected instead of producing an incorrect pipeline. The hackathon version supports Deposit and Withdraw activity from one to three ERC-4626 vaults on Base. It uses The Graph Substreams to process live blockchain data, normalizes activity from different vaults into one standard format, stores the resulting records in PostgreSQL, and publishes typed REST endpoints for raw events, hourly flows, filtering, pagination, metadata, and indexing health. Before deployment, the operator can review the interpreted request, selected contracts and events, Substreams module graph, live validation results, and artifact hashes. This makes the otherwise automated build process visible and ensures that the deployed pipeline is exactly the one that was tested and approved. Once the dataset is live, another AI agent can request data directly from its API. Protected endpoints respond with HTTP 402 and machine-readable payment instructions. The agent validates the payment requirements, pays 0.001 HBAR through Blocky402 on Hedera testnet, retries the original request with payment proof, and receives the blockchain data automatically. The frontend’s “Pay 0.001 HBAR & load data” button visualizes this autonomous interaction for the hackathon demonstration. It shows the purchased records, payment receipt, Hedera transaction ID, and HashScan verification link. In normal agent-to-agent use, the x402 client performs the same flow without a button or human involvement. Prompt2API therefore removes two major barriers to agent-accessible blockchain data: creating and operating specialized indexing infrastructure, and managing subscriptions or manually issued API keys. The Graph provides the live, reusable data infrastructure, while Hedera enables agents to purchase that data through fast x402 micropayments.

How it's made

Prompt2API is built like a controlled compiler. Gemini interprets what blockchain data the user wants, while trusted backend code decides what is valid and what can run. The frontend uses Next.js, React, TypeScript, and custom CSS. It provides the prompt builder, structured overrides, pipeline status, live validation results, artifact approval, dataset tables, API examples, and a visual x402 payment demonstration. An Express and TypeScript backend controls planning, builds, validation, deployment, dataset queries, and payment protection. PostgreSQL stores pipeline state, build jobs, indexed blockchain events, and synchronization cursors. We use `gemini-3-flash-preview` through Google’s official `@google/genai` SDK. Gemini converts a natural-language request into a strict `PipelineSpec`. It can return only one of three results: a ready plan, clarification questions, or an unsupported result. Gemini is deliberately limited. It cannot return Rust, SQL, shell commands, dependencies, package names, file paths, provider endpoints, or credentials. It only identifies configuration such as the network, vault addresses, Deposit or Withdraw events, starting block, and requested API outputs. The backend parses the response with Zod and validates every EVM address with viem. It confirms that the request uses Base, contains one to three valid vault addresses, includes only supported ERC-4626 events, and has a valid non-negative start block. The backend then derives event topics, Substreams filters, identifiers, package parameters, schema names, paths, and commands without relying on model-generated executable text. Every pipeline comes from a reviewed ERC-4626 template. The template contains fixed Rust mapping code, Protobuf definitions, the ERC-4626 ABI, PostgreSQL schema, `DatabaseChanges` mapper, Substreams manifest structure, dependencies, and pinned toolchain configuration. Only validated parameters are inserted into the generated package. The generated package composes The Graph’s pinned `ethereum-common@v0.3.3` Substreams package. It consumes the reusable `filtered_events` module instead of rebuilding Base block extraction from scratch. Our Rust/WASM mapper then decodes ERC-4626 Deposit and Withdraw logs and converts them into one normalized event format. This composition makes the pipeline reusable. Adding another ERC-4626 vault only changes the validated event filter. It does not require another Rust mapper, ABI, Protobuf model, SQL schema, or API implementation. One pipeline can process one to three vaults while returning the same standardized data structure. The backend runs the Substreams CLI as a restricted child process. It uses fixed executables, argument arrays, canonical artifact paths, reduced environment variables, output limits, cancellation, and timeouts. It never passes model output directly to a shell. The build process compiles the reviewed Rust mapper into WebAssembly, creates a versioned `.spkg`, inspects the package metadata, and checks the module graph. Because the executable mapper is shared between pipelines, Prompt2API uses a fingerprinted Cargo target cache. If the Rust, Protobuf, ABI, Cargo files, toolchain, and build script have not changed, it safely reuses the reviewed WASM and repackages it with the new validated parameters. This significantly shortens repeat builds. Before deployment, Prompt2API runs the package over a fixed 100-block range of live Base data supplied through The Graph Market. It checks the decoded records for allowed vault addresses, supported event types, deterministic event IDs, unsigned raw amounts, block metadata, transaction hashes, and log indexes. The frontend displays these stages so the hackathon judges can see what is happening. It explains when Prompt2API prepares the mapper, inspects the package, verifies the composed module graph, and validates against live Base data. These intermediate screens provide transparency for operators; an AI agent purchasing data does not need to interact with them. If the live range is valid but contains no matching events, Prompt2API reports `NO_ACTIVITY_IN_SAMPLE` instead of treating it as a provider error. The operator can enter another start block and retry the validation without making another Gemini request. After validation, the operator reviews and approves the exact pipeline. Approval contains SHA-256 hashes of both the generated configuration and compiled `.spkg`. Before deployment, the backend verifies the reviewed template files again and recalculates the package hash. If anything changed after review, deployment is rejected. Once approved, Prompt2API creates a separate PostgreSQL schema for the dataset and starts a resumable Substreams PostgreSQL sink. The sink processes historical blocks from the chosen starting block and continues toward the live Base chain head. It stores its cursor so it can resume after a restart. Deterministic event IDs prevent duplicate database rows. PostgreSQL views calculate hourly deposits, withdrawals, net flows, event counts, and unique owners without requiring the Substreams package to be recompiled. The Express API exposes typed endpoints for metadata, health, schema, raw events, hourly flows, filters, and cursor-based pagination. The Graph is load-bearing in two ways. First, The Graph Market supplies the live Base data used for validation and continuous synchronization. Second, the composable `ethereum-common` package provides the reusable EVM event-filtering layer under our standardized ERC-4626 mapper. This supports both composable Graph products and AI tooling that turns one natural-language request into a working Substreams pipeline. For payments, Prompt2API uses x402 v2 with native HBAR on Hedera testnet. Metadata, schema, and health endpoints remain free. Raw-event and hourly-flow endpoints are protected as paid data products. When an agent calls a paid endpoint without payment, the API returns HTTP 402 with machine-readable requirements. These specify the `exact` payment scheme, Hedera testnet, native HBAR, amount, recipient, facilitator fee payer, and requested resource. A separate TypeScript consumer agent uses the official x402 packages for Hedera. Before signing anything, it validates the x402 version, network, asset, price limit, recipient, fee payer, and requested Prompt2API resource. It then creates the Hedera payment authorization and automatically retries the original HTTP request with the payment proof. Blocky402 verifies the proof and settles the payment on Hedera testnet. After successful settlement, the API returns the requested Graph-derived data together with a `PAYMENT-RESPONSE` receipt. The payment produces a real Hedera transaction that can be independently verified on HashScan. The payer’s private key exists only inside the consumer-agent process. It is never exposed to the browser, Gemini, or the Prompt2API data service. For the hackathon demo, the frontend includes a “Pay 0.001 HBAR & load data” button. A server-only Next.js route starts the same restricted consumer-agent process, purchases the data, and returns only the dataset response and settlement receipt to the browser. The page then shows the purchased Base events, Hedera transaction ID, and HashScan link. The button makes the autonomous payment visible to judges. In normal use, an external AI agent performs the complete flow directly: **Request API → receive HTTP 402 → validate and pay in HBAR → retry automatically → receive data** No subscription, manually issued API key, checkout page, or human action is required for the agent’s paid data request.