Subgraph Studio: Four Stories
The Graph is the indexing protocol for blockchain data — the API layer for Web3. Apps like Uniswap and Aave use it to query on-chain data. I joined Edge & Node, the founding core developer of The Graph, in 2021 as a UX designer. Over five years I moved from IC to design manager to product manager, working primarily on Subgraph Studio (the developer tool for building and deploying subgraphs) and Graph Explorer (the discovery layer for the decentralized network).
Story 1: Indexer Selection Preferences
Situation
On The Graph's decentralized network, queries aren't served by a single server — they're routed to independent Indexers who compete to serve data. An algorithm selects which Indexer handles each query. The question was: how do you let developers influence that selection to match their use case?
Developers had real but varied priorities. A DeFi app processing trades needs the fastest response possible and the freshest data — stale prices mean lost money. An analytics dashboard cares about cost because it's running lots of queries but can tolerate slightly older data. A governance app needs economic security — confidence that the Indexer has enough stake at risk to be trustworthy.
Problem
The obvious approach — sliders, dropdowns, "rank these in order" — falls apart when users want everything. Ask someone "do you want speed, cost, data freshness, or reliability?" and the answer is "yes." You get meaningless preferences that don't actually help the algorithm differentiate.
We needed a UI that forced genuine tradeoffs without requiring developers to understand the indexer selection algorithm underneath.
Approach
I designed a point-budget system: 5 points to allocate across four dimensions — Fastest Speed, Lowest Price, Data Freshness, and Economic Security. Each point adds weight to that dimension in the selection algorithm.
The constraint is the design. With only 5 points across four options, you can't max everything out. You have to make real choices. Put 3 points on speed and you only have 2 left — suddenly cost and freshness are competing for what remains, and you're genuinely deciding what matters.
The interaction is simple — plus/minus steppers with a remaining-points counter. The decision architecture does the heavy lifting: it turns a vague preference ("I want good indexers") into a weighted signal the algorithm can act on.
This lived at the API key level, so developers could set different preferences for different use cases within the same account.
Outcome
We received positive feedback from users on the feature, and they loved feeling like they had a way to voice what was important for their use case.
The deeper win was reframing an algorithmic configuration problem as a prioritization exercise. Developers didn't need to understand how indexer selection worked — they just needed to decide what mattered most.
Story 2: L1 → L2 Migration
(Ethereum to Arbitrum)
(Ethereum to Arbitrum)
Situation
The Graph Network operated on Ethereum mainnet (L1), but transaction costs were making the network expensive to operate. The decision was made to migrate the entire protocol to Arbitrum (L2) — not just subgraphs, but indexer stake, delegation, curation, everything.
This affected every participant in the network: Indexers running infrastructure, Delegators earning rewards on staked tokens, subgraph developers with published subgraphs. Many of these participants had significant financial positions — we're talking about people's staked assets and income streams.
Problem
A "simple" migration tool wouldn't cut it because the network's participants weren't simple. Some Indexers held tokens through vesting contracts — partially vested, fully vested, each with different smart contract constraints. Some operated through multisig wallets. Delegators needed to move their delegation relationships intact. And some edge cases went in both directions (L1→L2 and L2→L1).
If we shipped a migration flow that only covered the happy path and someone with a vesting contract hit a dead end, they'd either be stuck on L1 losing indexing rewards as the network moved on, or worse, their tokens could end up in limbo between chains. And in some cases — particularly vesting contract transfers — failing to complete a multi-step migration within a deadline meant permanent loss of funds. These weren't theoretical risks. Real tokens, real money.
There was no user joy in this project. Nobody wanted to migrate. The entire goal was to make an inherently painful process go smoothly enough that people completed it without incident — and to make sure nobody lost funds because they got confused or dropped off mid-flow.
Approach
I mapped every participant type against every contract/wallet variation and designed distinct flows for each. The final Figma file contained 9+ complete flow variants:
Indexer Stake Migration (standard)
Transfer Delegation (standard)
Vesting Contract — partially vested
Vesting Contract — fully vested
Vesting Stake Transfer & Vesting Stake Transfer (fully vested)
Vesting Delegation Transfer & Vesting Delegation Transfer (fully vested)
Vesting L1 → L2 Transfer
Vesting L2 → L1 Transfer (for reversals/edge cases)
Each flow accounted for the specific transaction sequence, confirmation states, error handling, and "what happens if you close the browser mid-migration" scenarios. The vesting contract flows were particularly complex because the smart contract interactions differed based on vesting status — and some required multiple on-chain transactions that could fail independently (due to gas spikes, wallet disconnections, or simply closing the browser between steps).
Because migrations could stall mid-flow, I also designed a migration dashboard that triaged by urgency. The system detected each user's migration state and surfaced the right action at the right priority:
Urgent action needed — incomplete transfers approaching a deadline where funds would be lost (red, with explicit deadline and consequence)
Incomplete transfers — migrations started but not finished, needing a second transaction to complete (yellow, with clear next step)
Ready to transfer — everything the user still needed to migrate, organized by type: subgraphs, indexer stake, delegation, signal, vesting contracts
This was as important as the individual flows. A user with a vesting contract, three subgraphs, delegation on two indexers, and curation signal needed to see all of their migration tasks in one place, prioritized by what would hurt them most if they ignored it.
The design philosophy was exhaustive coverage over elegant simplicity. A beautiful migration wizard that breaks for 5% of users with vesting contracts isn't a good migration wizard — it's a support ticket generator. And when "breaks" means "loses their tokens," the stakes are even higher.
Outcome
On 28 June, 2024 the migration successfully completed, and all rewards shifted to Arbitrum. In that time period hundreds of subgraphs and indexers along with thousands of delegators migrated to L2.
The migration completed without significant incidents. The measure of success was the absence of failure — no stuck tokens, no angry forum posts about broken flows, no emergency patches for overlooked participant types.
But it was more than just "nothing broke." When GRTiQ — a prominent community account — asked delegators about their experience with the L2 Transfer Tools, the responses told the story: "pretty, pretty slick," "SMOOTH LIKE BUTTER" (via Graphtronauts), and from @Chainskimmerdad: "It only took minutes and a couple clicks. Easy 😎." For a mandatory migration involving real staked assets, "easy" is the highest compliment.
Story 3: The Sunrise of Decentralized Data
Situation
The Graph had two parallel systems: the Hosted Service (free, centralized, simple — over 20,000 developers) and the Decentralized Network (token-based, independent indexers, more resilient but harder to use). The Sunrise initiative would migrate all subgraphs to the decentralized network and shut the hosted service down. Deadline: June 12, 2024. Any subgraph that hadn't migrated would stop working, breaking the dapps that depended on it.
Problem
We were asking developers to leave something that worked fine for something harder to use, on a deadline they didn't set. The hosted service was good enough — free, familiar, years of muscle memory. The decentralized network required crypto wallets, on-chain transactions, query fees, and unfamiliar concepts.
The 2022 false start made the stakes higher. Developer trust was fragile — the community had already pushed back once. If the 2024 execution felt rushed or half-baked, adoption of the decentralized network could stall permanently.
The core design question: how do you move an entire developer community from a comfortable system to a more complex one without destroying trust — on your second attempt?
Approach
I owned the UX direction across a three-phase rollout, working as a part-time IC alongside my management role.
Phase 1 — Sunray (completed March 2024): The groundwork phase. New subgraphs could only be created in Studio, not the hosted service. An "Upgrade Indexer" — centralized infrastructure run by Edge & Node — ensured newly published subgraphs got indexed immediately, with pre-synced subgraphs available for immediate use. A pragmatic concession: make the decentralized network feel as reliable as the hosted service while the migration was underway.I designed a simplified upgrade interface in Subgraph Studio — developers could upgrade hosted service subgraphs to the network in just a few clicks, with gasless upgrades (no on-chain transaction fees) and the ability to batch multiple subgraphs together.
Phase 2 — Sunbeam (April 11 – June 12, 2024): The core migration experience. A 60-day upgrade window with:
Banner notifications in the hosted service dashboard
The upgrade wizard: a few clicks, less than 5 minutes on average, gasless
Auto-upgrade for frequently-used subgraphs that developers didn't manually migrate
The auto-upgrade was the most important design decision of the entire Sunrise. Rather than letting unmigrated subgraphs break on the deadline, the system upgraded them automatically. Developers could claim their auto-upgraded subgraphs in Studio afterward. The failure mode shifted from "your dapp broke" to "your subgraph migrated without you" — a dramatically better worst case.
Phase 3 — Sunrise (June 12, 2024): Hosted service endpoints retired. Primarily communication design — status pages, deprecation notices, documentation for edge cases.
Cross-cutting decisions that reduced friction:
Free tier as migration lubricant. 100,000 free monthly queries requiring no payment method eliminated the "why should I pay for something that was free?" objection.
Wallet-optional onboarding. Crypto wallet required only at publish time, not for deploying or testing. This removed the biggest friction point for Web2 developers.
Credit card billing. Stripe payments alongside GRT tokens, so developers didn't need to navigate crypto exchanges just to pay for queries.
40+ chains supported at launch. All networks previously on the hosted service were available on the decentralized network from day one of Sunray — no chain left behind.
Outcome
The Sunrise completed June 12, 2024. The hosted service went dark. The network held.
Over 6,000 subgraphs went live on the network — including AAVE, Balancer, ENS, Lido, SushiSwap, Decentraland, Snapshot, and PancakeSwap. Query volume grew 11x year-over-year during the Sunrise period: 991 million queries in 30 days versus 89.8 million over the same period in 2023. Data service fees surged 376% year-over-year.
By Q2 2025: over 6 billion queries per quarter (all-time high), 14,000+ active subgraphs with consistent growth, and 1,600+ new subgraphs per quarter — a 46% quarter-over-quarter increase. The migration didn't just preserve the developer base, it catalyzed growth.
Story 4: The Billing Saga
Situation
On The Graph's decentralized network, developers pay for queries with GRT tokens. The billing system I'd originally designed required developers to acquire GRT (buy on a crypto exchange or bridge from Ethereum), deposit it into a billing balance, and manage spend against usage. For anyone used to Stripe, it felt like a different planet — and it was one of the biggest barriers preventing developers from moving to the decentralized network.
But fixing it wasn't straightforward. There was institutional fear about SEC regulation, and one expression of that fear was resistance to building a unified billing interface that could look like Edge & Node was operating as a payment intermediary. The pressure was to "decentralize all the things."
Problem
That pressure kicked off a year-long push for decentralized subscriptions — billing logic executed entirely via smart contracts. The PM driving the initiative was committed to the approach despite my consistent pushback on the UX implications.
And the UX implications were brutal. The only way to prevent overage on a smart contract subscription was a global rate limit. If a developer purchased 1 million queries per month, the system divided that by the number of seconds in a month and set a per-second rate limit. In practice, this meant any burst of queries — which is how real applications behave — would immediately hit the limit. A DeFi app processing a spike of trades at market open would get throttled. The experience was fundamentally broken for how developers actually use APIs.
The deeper problem: developers literally couldn't choose the right subscription tier, because the information required to do so doesn't exist. I mapped out what a developer would need to know to avoid hitting rate limits — monthly query count (easy), average rates per second (easy), peak demand rates (medium), duration of peaks at a specific threshold (hard), and accurate growth estimates (impossible). The subscription model required developers to predict unpredictable traffic patterns.
I flagged this from the beginning. The math didn't work for real usage patterns. But the PM kept pushing forward, and the investigation continued for roughly a year.
Approach
After a year of raising concerns through normal channels without breaking through, I escalated. I went to the PM's manager — the head of product — and made the case directly: we could not ship decentralized subscriptions without creating a terrible developer experience that would actively harm the Sunrise migration.
The head of product and I aligned quickly on an alternative: Stripe integration for pay-as-you-go credit card billing. We looped in the product development lead, scoped the approach, and realized how straightforward it actually was compared to the smart contract complexity we'd been wrestling with.
The pivot happened in weeks. The first design decision was the billing model itself: pay in advance or pay after use?
The diagram made the answer obvious. "Pay in advance" meant developers had to estimate their query volume (the same problem that broke subscriptions), choose payment rails, and manage thresholds. "Pay after use" was: enter card, agree to terms, done. We landed on pay-after-use because it's so much simpler — and it eliminated the estimation problem entirely.
The final billing architecture supported both payment methods side by side:
The yellow sticky notes in the flow are part of the story — they show this was working design, not polished-after-the-fact documentation. Questions like "Should we limit the amount a user can run up before paying?" and "Do we get a billing address here?" were being resolved in real time as we shipped.
We delivered:
Pay-as-you-go credit card billing via Stripe alongside GRT token billing
100,000 free queries per month requiring no payment method at all
A clean, familiar billing experience that removed the entire "acquire crypto to pay for queries" barrier
Outcome
The billing overhaul directly unblocked the Sunrise migration. The free tier eliminated the "why should I pay for something that was free?" objection. Credit card support meant Web2 developers could migrate without ever touching a crypto exchange. These weren't just billing features — they were migration prerequisites.
Why This Story Matters
This is a story about product judgment and knowing when to escalate. I'd designed the original crypto billing, so I understood its flaws from the inside. I spent a year pushing back through normal channels — not because I was slow to escalate, but because I was trying to work within the system. When it became clear the PM wasn't going to change course, I made a judgment call to go above him, which carried real relationship risk. The outcome validated the escalation: a year of complexity replaced by a few weeks of focused execution on the right solution.
