Enabling Publication Flows

Beyond querying, a Gateway Operator often wants to help consumers publish Subgraphs to The Graph Network, so the data they depend on is indexed and served by The Graph network rather than by private infrastructure. Publishing is an on-chain action, which introduces a wallet requirement and some choices about how that wallet is managed. This page covers what a consumer needs to publish and the workflows an operator can support.

A Wallet is Required for Publishing Subgraphs

Querying a Subgraph needs only an API key or an x402 payment. Publishing a Subgraph is different: it is an on-chain transaction against The Graph Network contracts (i.e. the GNS on Arbitrum One), so it requires a wallet.

Concretely, to publish a Subgraph a consumer needs:

A wallet that can sign transactions on Arbitrum One and holds enough ETH for gas.
Optionally, GRT to signal (curate) on a Subgraph to incentivize Subgraph syncing. Curation signal attracts Indexers to index the Subgraph, so a small self-signal is a common way to bootstrap indexing on a freshly published Subgraph.

This is a real difference in the consumer experience: a query consumer may never touch a wallet, but a publishing consumer must. Part of enabling publication is making that step as smooth as possible, whether by guiding them through Subgraph Studio’s publish flow or by supporting publication within an Operator’s own product surface.

Wallet vs Multi-Sig Publication Flows

Who holds the publishing wallet, and how it signs, matters as soon as more than one person is involved or the Subgraph is operationally important. There are three common workflows, in increasing order of control.

Single Wallet (EOA)

A single externally-owned account signs the publish transaction directly. This is the simplest path and fine for individual developers and low-stakes Subgraphs. The tradeoff is that one key is a single point of failure and a single point of compromise: whoever holds it can publish, update, or transfer the Subgraph.

Multi-Sig Wallets

For teams and production Subgraphs, a multi-signature wallet (e.g., a Safe) holds the publishing rights, and a threshold of signers must approve each action. This gives:

Shared control: no single person can unilaterally publish or update a Subgraph.
Continuity: signers can be added or removed as a team changes without losing the Subgraph.
Auditability: each publication or update is an explicit, co-signed on-chain action.

Multi-sig workflows are the recommended default for any Subgraph a business depends on, and enabling it is largely a matter of letting the consumer point their publish flow at a multi-sig address rather than an individual key.

Account Abstraction

Account-abstraction (or smart-account) wallets extend this further, letting the signing logic itself be programmable: session keys, spending policies, sponsored gas, and social recovery. For a Gateway Operator building a smooth publishing experience inside their own product, account abstraction can hide much of the wallet friction from the consumer (for example, sponsoring gas or batching the publish and signal steps) while keeping strong controls.

What an Operator Can Do

Guide consumers to a wallet-ready publish flow (Subgraph Studio, or an Operator’s own product surface).
Recommend multi-sig for any production Subgraph, and support pointing publication at a multi-sig address.
Where it fits an Operator’s product, use account abstraction to reduce wallet friction (sponsored gas, batched publish-and-signal) without giving up control.
Pair publication with a small curation signal so the newly published Subgraph attracts Indexers.