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.

1 Like
2

Thanks for sharing the final report. The product appears to be delivered, and I appreciate the honest disclosure that the ten protocol target was not met and the twenty developer KPI was not instrumented. However, for DAO accountability, I believe a few important areas still need clarification.

Budget transparency

The grant amount was $12,000. Could the team share a simple breakdown of planned versus actual spending?

For example, how much was used for engineering, infrastructure or RPC costs, product design, testing, documentation, security, and operations. Milestone completion confirms delivery, but a cost breakdown would help the DAO assess whether the grant created efficient value.

Adoption evidence

The report states that five customers ran fourteen pipelines, while nine teams built on Arbitrum during the grant period. This is useful progress, but the report does not provide enough evidence to assess sustained adoption.

It would help to share, at least privately with the program managers:

  • Evidence supporting the five active customer and nine team claims

  • Number of active pipelines today, not only during the grant period

  • Number of users who moved from the free 10,000 block allowance to paid usage

  • Retention data for the teams that deployed pipelines

  • Arbitrum related revenue, operating cost, and expected runway

Customer privacy is understandable, but the DAO should still have a confidential way to verify these usage claims.

Reliability and security

The report says latency is consistently below one second and that reorg handling is supported through block and parent hash tracking. It would be valuable to publish operational evidence behind these claims.

Could the team provide:

  • Uptime for the last 30, 60, or 90 days

  • Failed delivery rate and missed block rate

  • Reorg recovery process and any incidents so far

  • Average recovery time after an outage

  • Security review or audit details for the payment flow, account credentials, API access, webhooks, and balance crediting system

This matters because teams may rely on these pipelines for payments, monitoring, alerts, and other production workflows.

Competitive value

Indexing and blockchain data tooling already has strong existing providers. The report explains the product workflow well, but it does not clearly show why this solution is meaningfully better for Arbitrum developers than alternatives.

A simple comparison on pricing, latency, reliability, supported destinations, historical backfills, developer experience, and migration effort would help the DAO understand the unique value of funding this product. The six templates and self serve flow are useful, but the competitive advantage should be shown with measurable evidence.

Long term continuity

My main concern is vendor dependency. This is a company operated service, and developers may build important workflows around its pipelines, API, webhooks, and payment system. If the company changes priorities, loses funding, is acquired, or stops supporting Arbitrum, users could face disruption.

The report says continued support is aligned with the team’s own Beacon product, usage based revenue, and enterprise demand. This is a positive incentive, but it is not a firm continuity guarantee.

Could the team clarify:

  • Is there a documented service level commitment for production users?

  • Can users export pipeline configuration, transformations, and historical data easily?

  • Is there a migration guide if the service is discontinued?

  • Are the Arbitrum funded templates, schemas, and integrations open source?

  • Would the team consider an escrow, open source, or handover plan for critical Arbitrum specific components?

last view

I do not see $12,000 as automatically excessive for working indexing infrastructure, a self serve console, payment support, templates, and documentation. But delivered milestones alone should not be the only measure of success.

For future grants or renewals, the DAO should require verifiable adoption data, detailed budget reporting, service reliability metrics, security assurance, competitive benchmarking, and a clear vendor exit plan. This would protect Arbitrum builders while ensuring that DAO funded developer tooling creates durable public value. @dennisindexing

3

Thanks for the detailed read, @MconnectDAO!

BUDGET TRANSPARENCY

The grant was disbursed against three milestones: $6,000 for engineering, $4,800 for product and UX, and $1,200 for the final report. So $10,800 of the $12,000 was allocated to build work.

Planned versus actual, at the level we track it:

  • Engineering time. The large majority of the grant. Roughly 200 engineering hours between February and July 2026.
  • Infrastructure and RPC. A few hundred dollars per month attributable to Arbitrum. Arbitrum One ingestion runs at roughly 10.4 million blocks per month with Arbitrum Sepolia at the same cadence, but this ran on existing platform capacity rather than new infrastructure, so the grant carried the marginal cost only.
  • Documentation, testing and operations. Absorbed into the engineering line rather than tracked separately.

The honest headline is that we spent beyond the grant. At any realistic contract rate, 200 hours is materially more than the $10,800 allocated to engineering and product. We are not presenting that as a complaint, because the overspend was deliberate and it went into three things that were never in the funded scope: the six Arbitrum templates, the self-serve console frontend, and making the whole thing accessible to AI coding agents.

The original proposal committed to an indexing layer, a console, payments and documentation. It did not commit to a template library, it did not commit to the console being a polished self-serve product rather than a functional one, and it did not commit to agent accessibility. We built these because a grant that ships an API is made materially more useful by templates, a frontend and AI accessibility. That was our choice and our cost, not the DAO’s.

ADOPTION EVIDENCE

Customer names are withheld publicly because we do not publish customer identities without their consent, but that is not a reason for the DAO to take usage claims on trust. Confidential disclosure to program managers is the right mechanism, and if needed we will present them to our program manager.

One clarification on the numbers already published, since it affects how they should be read. A “beat” is a block delivered to a pipeline, not a block scanned. A wallet-filtered pipeline only receives matching blocks, so a low beat count can mean a narrow watchlist rather than low engagement. Every block gets scanned and processed in the infrastructure regardless. We would rather flag that than have the figures compared against something they are not measuring.

RELIABILITY AND SECURITY

Most of this is already published rather than asserted.

Uptime. We commit to 99.95% for our own infrastructure and pass through the uptime guarantees of the RPC providers for each network. Public status page with live and historical figures: Indexing Co

Current Arbitrum figures from that page:

ARBITRUM
Last 7 days: 100.00%
Last 30 days: 100.00%
Last year: 99.961%

ARBITRUM_SEPOLIA
Last 7 days: 100.00%
Last 30 days: 99.998%
Last year: 99.998%

Delivery success rate. Across all production customer pipelines on all chains, over the last 7 days, 99.16% of jobs succeeded on first attempt, 4,033 failures out of 479,162 jobs. We are giving the all-chain figure rather than the Arbitrum-only one because it is customer weighted and therefore the more meaningful number for anyone relying on these pipelines in production. For completeness, the Arbitrum-only figure over the same window is 99.96%, and of the 1,254 failures there all but 14 were token metadata lookups rather than delivery failures.

Two caveats on that. The window is 7 days because our log retention is 14, so we are not going to quote 30, 60 or 90 day figures we cannot back. And the measure is an upper bound on failures, since one failed job can emit several error lines, so the true rate is at least this good.

Incidents and recovery. Since Milestone 01 was delivered on 12 April we have had 12 incidents, every one auto-resolved without manual intervention. We call these pipelines self-healing:

Mean recovery: 7.2 minutes
Median recovery: 2.5 minutes
Worst case: 21.9 minutes

That is 86 minutes of total downtime across 122 days but well within our service agreements. This is derived from our own missed-beat alerting rather than an external prober, so treat it as our instrumentation rather than third party verification.

Reorgs. Zero on Arbitrum. Across the full 14 day log window our reorg detector fired on 13 other chains, including Moonbeam 19,797 times, Acala 10,168, Quai 5,171 and Ethereum 77. Arbitrum was zero over that window and we have never observed one. We quote 14 days because that is what log retention supports, but the useful point is that the detector was demonstrably running the whole time rather than silently broken.

The recovery process is documented at Reliability & Performance - The Neighborhood. For each block we track its hash and its parent hash, a mismatch is detected as a reorg, and affected blocks have their delivery flag cleared so corrected data is re-delivered rather than the stale version persisting. Pipelines can also be configured to hold a safe distance from the chain tip, which is the default, or to notify you and let you handle it. Our confirmation delay on Arbitrum is one block, which is thin, and the honest reason that is defensible is that the sequencer does not reorg.

Delivery guarantee. Delivery is at least once and pipelines are self healing. A failed delivery or a downed component causes the affected blocks to be reprocessed rather than left behind, with duplicate delivery accepted as the tradeoff.

Pipeline health is queryable per pipeline through the API: Status - The Neighborhood

Security. Being direct here rather than implying more assurance than exists. There has been no third party security audit of the payment flow. The onchain payment path deliberately has a small surface: top ups are standard USDC or ETH transfers to a receiving address, with no bespoke payment contract to audit. Crediting is idempotent per transaction hash against a provenance ledger, which is what prevents double crediting. API access is key based and deploys run under the account’s own credentials rather than a shared key.

A formal audit is something we will commission when the scale of funds moving through the system justifies the cost, funded at that scale. A $12,000 grant does not cover a meaningful audit.

COMPETITIVE VALUE

Worth flagging that this was part of the original application rather than something left unaddressed. The Questbook proposal covers the competitive positioning and what was novel about the approach for Arbitrum:

That assessment is what the grant was evaluated against, so it is the right place to start on this question. Alongside it, we publish direct comparisons rather than making the claim in the abstract:

Pricing is public at Pricing | The Indexing Company

The short version of the difference for an Arbitrum developer: no subgraph to write or redeploy when a contract changes, arbitrary JavaScript transformations applied before storage rather than a fixed schema, and delivery into infrastructure you already run, Postgres, webhooks or Kafka, rather than an API you have to query. Migration effort is low because the transformation is ordinary JavaScript and the destination is your own database. We see this as a massive improvement in indexing solutions in the space and a better way to index data at scale.

LONG TERM CONTINUITY

Service level commitment: Yes. The 99.95% commitment linked above applies to production users across all services and all chains we index, not only Arbitrum.

Export: Yes, and it is not an escape hatch we built for this question, it is how the product works. Pipeline configuration and transformation code are retrievable through the public API and visible in the console:

Configurations and transformations can be exported and imported. Delivered data already lives in the customer’s own Postgres, warehouse or webhook target, so historical data is in their infrastructure rather than ours by default. That is a deliberate design choice and it is the strongest answer to vendor dependency: we are not the system of record for customer data.

Migration. Because a pipeline is a filter, a JavaScript transformation and a destination, those three artifacts are portable. The transformation is ordinary JavaScript, not a proprietary DSL. A team leaving would take their configuration and transformation and reimplement against another source, with the business logic intact.

Open source status of the templates. A clarification here: the six Arbitrum templates were not part of the funded grant scope. We added them because they let us verify data correctness end to end and they lower the barrier for new developers. They are plain JavaScript and JSON, visible and editable in the console before deploying, and they are free to copy and reuse. They carry no usage restriction.

Escrow or handover. Yes, we would consider an escrow, open sourcing, or a handover plan for Arbitrum specific components if the service were being wound down. We think that is a reasonable ask for DAO funded tooling and we are open to discussing what it should cover.

1 Like