Search projects, hackathons, sponsors and tech

    ← All projects

    BlockTerms

    Pay AI agents for data they can verify. Purchase live blockchain data through x402

    Demo

    About

    BOUND is an agent-native protocol for buying live blockchain data with explicit, machine-readable delivery terms. Instead of treating an HTTP response as sufficient proof of delivery, BOUND binds each order to a specific provider, source chain, block, query scope, selected fields, payment amount, deadline, and warranty commitment. The provider reserves collateral before payment, the buyer agent pays through x402, and the returned result is checked against the agreed delivery terms. If the final delivery is invalid or late, the original payment is not reversed; the order follows a separate warranty path backed by the provider’s reserved collateral. The current demo uses live Uniswap data from two standardized Graph deployments, a bounded Ethereum state witness, and a real Hedera x402 payment settled through Blocky402. The goal is not to prove every property of a protocol, but to make a narrow paid data request verifiable and economically accountable.

    How it's made

    BOUND is an agent-native protocol for buying live blockchain data with explicit, machine-readable delivery terms. Instead of treating an HTTP response as sufficient proof of delivery, BOUND binds each order to a specific provider, source chain, block, query scope, selected fields, payment amount, deadline, and warranty commitment. The provider reserves collateral before payment, the buyer agent pays through x402, and the returned result is checked against the agreed delivery terms. If the final delivery is invalid or late, the original payment is not reversed; the order follows a separate warranty path backed by the provider’s reserved collateral. The current demo uses live Uniswap data from two standardized Graph deployments, a bounded Ethereum state witness, and a real Hedera x402 payment settled through Blocky402. The goal is not to prove every property of a protocol, but to make a narrow paid data request verifiable and economically accountable. How it's made * BOUND is built as a TypeScript monorepo around a single durable BlockTermsService runtime that owns validation, order state transitions, adapter selection, policy enforcement, and persistence. The same runtime is exposed through four interfaces: a TypeScript SDK, REST API, CLI / npx flow, and an MCP stdio server, so agents can integrate directly without depending on the web UI. Orders move through explicit states such as quoted, reserved, payment-pending, paid, and accepted, with atomic JSON persistence and compare-and-set revisions to avoid unsafe duplicate execution. For the data layer, we deployed two separate subgraphs on Ethereum Sepolia for Uniswap V2 and Uniswap V3. Both expose a normalized schema so BOUND can send the same query shape to different protocol deployments instead of hardcoding protocol-specific logic into the agent. The runtime queries both deployments at a common block, checks schema/version compatibility, validates returned token and balance arrays, and rejects malformed or mismatched responses. For state verification, BOUND uses an EVM JSON-RPC provider with eth_getProof and eth_getBlockByNumber to inspect a bounded set of account/storage fields at a pinned block. The system deliberately limits the proof scope to selected fields and does not claim full Graph query completeness or general financial correctness. Payments use x402 v2 on Hedera testnet through Blocky402 with the exact scheme. The payment adapter is built with @x402/core, @x402/fetch, and @x402/hedera, and only accepts configured network, payee, asset, and budget constraints. In the live demo, buyer account 0.0.9695366 paid 0.01 HBAR to seller 0.0.10524176, while Blocky402 facilitated the network fee. After settlement, the paid request was retried and returned live standardized data from both Graph deployments with matching schema versions. The runtime writes payment-pending before invoking the irreversible payment step and stores the settlement receipt immediately afterward, so a crash cannot blindly trigger a second payment.