Final Grant Report: The Neighborhood, Real-Time Indexing and Dev Tooling for Arbitrum

DAO Programs & Initiatives Domain Allocator Offerings (prev Questbook)
1

SUMMARY

We built a self-serve path for Arbitrum data. A developer can now pick a template, preview it against a live Arbitrum block, deploy a pipeline into their own database or webhook, and pay for usage in USDC on Arbitrum, in about five minutes, without contacting us at any point.

Both engineering milestones were delivered and approved. Milestone 01 was paid on 12 April 2026 and Milestone 02 on 7 July 2026.

Project: The Neighborhood, Real-Time Indexing and Dev Tooling for Arbitrum
Grantee: The Indexing Company
Grant: Arbitrum DevTooling, $12,000, accepted 29 January 2026
Period: February 2026 to July 2026
Status: Both engineering milestones delivered and paid

MILESTONE 01: ARBITRUM INDEXING

Committed: integrate Arbitrum One into The Neighborhood’s indexing infrastructure, supporting real-time event streaming under two seconds and full historical backfills, with verified output accuracy, making Arbitrum data available through the APIs and the pipeline console.

Status: delivered, approved and paid 12 April 2026.

COVERAGE

Arbitrum One is indexed in full, with no sampling. Every block is ingested and available to pipelines rather than a filtered subset. Arbitrum Sepolia is indexed at the same cadence, which matters more than it first appears, since most teams build against testnet for weeks before touching mainnet.

tbl-1-coverage
tbl-1-coverage1520×608 35.9 KB

Chain state is publicly verifiable, no account required:

LATENCY

The committed target was under two seconds from block confirmation to delivery. Measured latency is consistently sub-second, so the delivered figure is better than the commitment by roughly a factor of two. Reliability characteristics, including reorg handling via block and parent hash tracking, are documented at Reliability & Performance - The Neighborhood.

OUTPUT VERIFICATION

Rather than validating against fixtures, every Arbitrum template was tested against real Arbitrum blocks and the decoded output inspected:

tbl-2-verification
tbl-2-verification1520×608 51.2 KB

ON STYLUS

Stylus contracts emit standard EVM logs. They are therefore indexed through the same event pipeline as any other Arbitrum contract, with no separate decoding path required. Reading Stylus contract data was the objective, and that works today through the existing transformation layer.

MILESTONE 02: CONSOLE, TEMPLATES AND PAYMENTS

Committed: launch a self-serve console for pipeline deployment and management, where developers configure filters, preview transformations and deploy to live infrastructure. Enable onchain payments in USDC and ETH on Arbitrum. Integrate a usage-based pricing model. Provide deployment guides and documentation.

Status: delivered, approved and paid 7 July 2026.

ARBITRUM TEMPLATES

Six Arbitrum templates ship in the console, each with a working transformation and deploy configuration that can be edited before deploying. These were not formally part of the grant scope, but they let us verify data correctness end to end and they lower the barrier for anyone starting out. All are live at Indexing Co

tbl-3-templates
tbl-3-templates1520×860 75.6 KB

The two alert templates introduced a new category. An alert is a normal pipeline whose transformation returns nothing until a condition is met, so no alerting service, queue or rules engine was added. The threshold is a constant the developer can read and edit, and comparisons run in base units using BigInt so decimal handling stays correct at 6 and 18 decimals.

SELF-SERVE CONSOLE

Developers browse templates, preview a transformation against a real block, and inspect decoded output before committing to anything. No account is required to explore or test. Authentication is needed only to deploy and manage something that stays running.

Deployed pipelines are listed, paused and removed from the same interface. Deploys run under the signed-in account’s own credentials rather than a shared key, which is what makes per-account usage attribution, and therefore usage-based billing, possible at all.

THE CONSOLE IS AN API SURFACE, NOT JUST A UI

The console is a graphical layer over the same public API that has always driven The Neighborhood. Filters, transformations, pipelines and delivery are the same objects whichever way you reach them, so a pipeline built by clicking and a pipeline built by curl are identical, and you can move between the two at any point without rebuilding anything.

That gives an Arbitrum developer three interchangeable ways in:

tbl-4-surfaces
tbl-4-surfaces1520×526 35.5 KB

BRING YOUR OWN AGENT

The console is agent-friendly by design, and the principle behind it is that you do not adopt our agent, you connect the one you already use.

There is no proprietary assistant to learn and no chat window we require you to work inside. A developer registers the Indexing Co MCP server with whichever coding agent they already have open, and that agent gains the ability to build Arbitrum pipelines directly. The agent layer stays entirely the developer’s choice, which matters because agent preferences change faster than data infrastructure should.

The MCP server connects any MCP-compatible coding agent, including Claude Code, Cursor and Codex, to the Indexing Co API and the live event stream over WebSocket. A developer describes the Arbitrum data they want in natural language, and the agent creates the pipeline, writes the transformation, tests it against real blocks and deploys it.

It ships alongside a published skill that teaches the agent the workflow itself, covering filter and transformation patterns, EVM event signatures, destination choice and delivery debugging. The MCP server supplies the tools, the skill supplies the knowledge to use them well, which is the difference between an agent that can call an endpoint and one that can actually build a working pipeline. A preview CLI streams live pipeline events into the terminal so the developer, or the agent, can watch data arrive and confirm the pipeline is correct.

Setup is documented at Build Pipelines with Your AI Coding Agent - The Neighborhood

ONCHAIN PAYMENTS

New accounts receive 10,000 free blocks. Beyond that, usage is paid by topping up in USDC or ETH on Arbitrum. A payment credits the account balance directly, converted at the metered rate.

The payment path uses account-scoped signed PayLinks, so an incoming payment maps to exactly one account and is credited idempotently by transaction hash. Crediting is backed by a provenance ledger recording transaction hash, chain, token, amount and blocks credited.

We use this ourselves. Our own payments product runs its deposit tracking on Arbitrum through the same pipelines described in this report.

WHAT DEVELOPERS CAN DO TODAY

The practical test of this grant is whether an Arbitrum developer with no prior relationship to us can get data flowing unaided. They can:

  1. Open Indexing Co with no account
  2. Pick an Arbitrum template, for example DEX swaps or USDC payments
  3. Preview the transformation against a live Arbitrum block and inspect decoded output
  4. Point delivery at Postgres or a webhook
  5. Sign in and deploy, receiving 10,000 free blocks
  6. Watch rows arrive
  7. Manage, pause or remove the pipeline from the account area
  8. Top up in USDC on Arbitrum when the free allowance runs out

The same pipeline can be driven entirely from the command line, or by an AI coding agent through the MCP server.

The bridge alert is the clearest single demonstration. A developer selects the template, sets a threshold, points it at a webhook, and receives a message when someone moves more than 10,000 USDC or 5 ETH across an Arbitrum bridge. There is no infrastructure to run and no indexer to operate.

ECOSYSTEM IMPACT

Since the grant began in February 2026, The Neighborhood has delivered 536,510 Arbitrum beats across five customers and fourteen pipelines, which is 57% of all Arbitrum volume ever delivered on the platform. Roughly 420,000 of that is historical backfill, including one large Arbitrum Sepolia backfill in July, so realtime delivery over the window was 103,135 beats. Within the window, Arbitrum Sepolia ranks 6th and Arbitrum One 10th of all chains we index, placing Arbitrum combined around 5th.

Two teams began building on Arbitrum with us for the first time during the grant window:

  • A wallet and transaction infrastructure team, from March, now running three pipelines across development and production on Arbitrum One
  • A financial infrastructure team, from May, now running five pipelines on Arbitrum Sepolia and carrying the most active Arbitrum workload on the platform today

Three teams already using The Neighborhood ran Arbitrum workloads through the infrastructure this grant funded:

  • A wallet infrastructure provider running transaction pipelines on Arbitrum One, 99,454 beats delivered in realtime over the window and delivering today. This is the clearest picture of sustained production Arbitrum usage on the platform.
  • An identity and delegation protocol running five pipelines on Arbitrum One covering transfers and registry events
  • Beacon, our own payments product, running deposit tracking on Arbitrum in production

That second new team is the clearest signal for a developer tooling grant. The heaviest current Arbitrum workload belongs to a team actively building, deploying new pipelines week to week. Testnet-first is what building looks like before it is what production looks like.

Customer names are withheld here as a matter of course. We are happy to share specific references privately with the program.

A note on units: a beat is a block delivered to a pipeline, not a block scanned. Wallet-filtered pipelines receive only matching blocks, so counts reflect watchlist scope rather than engagement.

AGAINST THE COMMITTED KPIS

tbl-5-kpis
tbl-5-kpis1520×902 84.2 KB

Two of these need honest qualification rather than presentation.

On the ten-protocol target, we fell short. Nine teams have built against Arbitrum on the platform and five carried traffic during the grant window. Direct outreach ran to roughly one hundred teams, but response rates through a quiet market made both conversion and attribution unreliable. We would rather report five and nine accurately than assemble a number that does not survive inspection.

On the twenty-developer target, we are not reporting a figure. We did not instrument developer registration in a way that would let us attribute signups to this grant with confidence, and we would rather leave the line unreported than publish a number we cannot stand behind.

POST-GRANT SUSTAINABILITY

The work this grant funded is not a demonstration that stops when the grant does. Three things make it self-sustaining.

Usage-based pricing settled onchain. The payment path is live: an account exhausts its free 10,000 blocks, tops up in USDC or ETH on Arbitrum, and continues. This is the mechanism that turns Arbitrum developers into paying users without contract negotiation, procurement, or an invoice. Payments settle on Arbitrum, so the chain this grant supports is also the chain the revenue moves across.

The infrastructure is load-bearing for our own product. Our payments product runs deposit tracking on Arbitrum through these pipelines in production. The Arbitrum indexing path degrading is not an abstract customer-facing risk for us, it is an outage in our own product. That alignment is the most durable maintenance guarantee we can offer.

Enterprise demand pulls the same infrastructure forward. The larger conversations in our pipeline are with teams consuming high volumes of chain data, and Arbitrum coverage is part of what they evaluate. Those engagements fund continued investment in the same indexing layer, templates and console that any self-serve Arbitrum developer uses. The self-serve path and the enterprise path are not separate products, so improvements made for one land for the other.

The marginal cost of keeping Arbitrum indexed is now low, because the work of integrating it, verifying it and building the templates is done and paid for. What remains is operation, which is covered by existing customers and our own product usage.

WHAT THIS WORK COULD BE BUILT ON

The grant deliverables are complete as scoped. What follows is not a commitment or a plan we are executing, but a note on where this particular foundation extends naturally, in case any of it is useful to the ecosystem. Each item builds on infrastructure this grant already paid for, so the incremental cost is small relative to starting fresh.

Orbit chains. The original proposal raised Orbit chains as first-class data sources, and that remains the largest available extension. Everything built here is chain-agnostic by construction: the templates, the console, the transformation layer and the onchain payment path make no Arbitrum One assumptions beyond configuration. Bringing an Orbit chain on is therefore integration and verification rather than new architecture, which is a meaningfully cheaper shape of work than the original Arbitrum One integration was. It would give Orbit chains turnkey indexing from launch rather than each one solving it independently.

More Arbitrum protocol templates. The current six cover payments, DEX, lending, bridges and alerts, which are the highest-frequency needs but not the whole surface. The library grows most usefully where developers tell us what they are currently hand-rolling, so this is demand-led rather than something to plan in advance. Perpetuals, NFT activity and governance are the obvious untouched categories.

Deeper usage analytics for developers. Teams can see what they have consumed, but not easily model what a pipeline will cost before running it. Cost preview ahead of deploy would make the usage-based model easier to adopt for teams that need to forecast spend.

Broader alert delivery. Alerts deliver to webhooks today, which already covers Slack, Discord and Telegram through a user-supplied endpoint. First-class destinations would remove that setup step. This is the smallest of the four and mostly a convenience.

Two questions where the ecosystem’s view would be more informative than ours: which Arbitrum protocols would most benefit from a maintained template, and whether Orbit chain coverage is a priority worth pursuing.

LINKS

Start here

Product

Documentation

Live chain state, no account required

Agent and CLI tooling

Company

Happy to answer questions in this thread.