Adam Stockermans

Benny Sidelinger

Two weeks ago, Circle launched CPN Managed Payments. The pitch: banks can settle cross-border transactions on stablecoin rails while staying entirely in fiat. Circle handles the issuing and blockchain infrastructure under the hood so its banking partners don't have to.

Circle isn’t unusual here. Stripe shipped Tempo. Visa and Mastercard joined x402. Franklin Templeton’s BENJI tokenized money market fund now runs 24/7 across 10 blockchains. PayPal, Revolut, Robinhood, and dozens of other platforms are building onchain rails into their products.

What these announcements have in common isn't the token or the chain.

A bank wants to move dollars from New York to São Paulo faster and cheaper. An asset manager wants a tokenized fund that prices and settles 24/7 across jurisdictions. A payment platform wants to accept and pay out in dollars without holding dollars. A prediction market wants to resolve thousands of short-duration contracts on time. An AI agent wants to pay for the services it uses without a human approving every five-cent transaction.

In each case, the onchain part sits in the middle. Everything around it is offchain: the compliance check, the FX conversion, the settlement reconciliation, the audit trail back to the company’s books. What they’re really shipping is a backend that happens to have an asset attached. We built Compose for that backend.

Compose is the execution framework for money that talks to code

, whether that money sits in a fintech app, stablecoin issuer, or bank ledger. Write TypeScript functions, wire them to a trigger (a cron schedule, an onchain event, or an HTTP call), and Compose handles wallets, gas, retries, state, and execution traces.

Onchain finance is 80% offchain engineering

Step through what a financial product does when it touches a blockchain, and we’ll find that the onchain part is maybe 20% of the engineering. Here are a few patterns with onchain actions bolded.

A cross-border payment has the same shape whether you're a bank partner on Circle's CPN, a remittance provider, a payment platform expanding into stablecoins, or a payroll company paying contractors across 40 countries.

Tokenizing real-world assets (Treasuries, real estate, equities) follows the same pattern.

Crypto markets in particular resolve on multiple fixed schedules. Various timeframes (5-minute, 15-minute, 1-hour) across multiple assets mean thousands of new markets per day, each requiring onchain contract interactions to create and resolve. No human is doing that by hand.

 Short-duration crypto markets now account for well over 20% of Polymarket's transaction volume – over $500 million in notional volume per week flowing through Compose workflows.

Resolution is a sequence of offchain operations followed by a single onchain write.

If the read fails, Compose retries. If the write partially lands, Compose checks onchain state before resubmitting. When Polygon reorgs (which happens), Compose replays with a new nonce: shallow confirmation after 3 blocks, then deep monitoring for ~250 more. Miss one and users complain, bots pull capital, Polymarket loses trust.

An AI agent needs to pay for things (API calls, compute, storage, data feeds, services from other agents) without a human approving every transaction. The mechanics vary – x402 is one emerging standard – but the operational shape is the same regardless of protocol.

Emerging standards like x402 give agents a common HTTP-native way to handle steps 1 and 6. But the wallet, spending policy, retry logic, and audit trail are still the agent builder's problem regardless of which protocol wins. This matters more than in human-driven payments. An agent that double-pays, or pays without authorization, or loses its audit trail, does all of it at machine scale.

Across these patterns, the onchain side is maybe 20% of the system. The other 80% is the operational layer between the financial product and the chain.

Stablecoins, scale, and the shift to writing onchain

Smart contracts get auditors and audit reports and public review. The offchain backend that powers most of the actual product gets a VPS, a cron job, and a wallet with some ETH in it.

This made sense when onchain activity was mostly experimental. The contract was the novel part. The rest was a standard backend, and if the backend went down, the damage was a few angry messages in Discord.

A few things have changed in the past two years.

Writing onchain is harder than reading onchain

Goldsky started with the read path. Since 2022, we've shipped 

, the indexing and data infrastructure that teams like Coinbase, Circle, Kraken, Anchorage, Privy, Polymarket, Phantom, and Uniswap use to read blockchain data.

Reading blockchains is now a solved problem in the boring sense. You can trust the infrastructure to be correct eventually, because eventual is the only consistency guarantee the read side needs.

Writing onchain is a different game, especially when money is the thing being moved. When you read a blockchain, the operation is replayable. If something goes wrong you just try again. When you write onchain, there is no undo.

That asymmetry (replayable vs. not replayable) shows up everywhere:

These failure modes don’t have a counterpart on the read side. The write path needs different guarantees: exactly-once settlement, durable state that survives process crashes, deterministic retries that know whether the thing actually happened, reorg-aware confirmation, and a complete audit trail of every external call the system made.

None of this comes out of the box. Every team building anything serious is rebuilding these guarantees from scratch. Usually in a hurry with a backlog of issues that look suspiciously alike across companies.

We built Compose because we spent three years watching the pattern repeat, and it was time.

Meet Goldsky Compose: the full onchain loop in one platform

 is our framework for the write path. Pair it with Goldsky’s read-side products (Edge RPC, and Subgraphs, Mirror, and Turbo for indexing) and you have the complete onchain operational stack in one place.

For teams building onchain financial products, the shared-platform benefit is operational. When you add a new chain, you add it once – Compose's wallets and execution sit on top of the same Edge RPC infrastructure powering your reads.

Everywhere else, teams assemble this loop from five or six vendors: an indexer, a webhook service, a workflow engine, an RPC provider, a wallet system, a tracing layer. The glue between those vendors is where most incidents happen. On Goldsky, those pieces come already connected.

Here's a first-party price feed, published every five minutes.

Continuous proof of reserves in forty lines

Price feeds are one pattern. Here's another that's become urgent as MiCA's July deadline approaches: a continuous proof-of-reserves reconciliation that compares your offchain reserve balance against your onchain token supply and surfaces drift automatically.

This works as a compliance artifact and not just a monitoring script because every run is traced regardless of outcome: pass, fail, drift, crash, custodian API down. Under MiCA and the GENIUS Act, that trace is the audit deliverable.

 above are only a few dozen lines. A lot more is happening underneath to make them safe in production.

Our design philosophy is that if the durability layer is working well, users will never really think about it. Their app will consistently just work.

The immediate change is that you ship faster. Months of backend engineering become a few TypeScript files.

But the more interesting shift is what becomes economically and operationally feasible.

Before Compose, a two-person team building a tokenized product had to manage a handful of services, unclear boundaries between smart contracts and their web app, and a pile of custom cronjobs for airdrops, auditing, and other onchain side effects. We know because we talked to these teams. Every change was approached with fear – if anything went wrong, debugging was a nightmare with so many possible failure points.

With Compose as the onchain execution layer:

These products were previously hard to ship because every team had to build and maintain the plumbing themselves, usually with a stack of infrastructure work before anyone could get to the actual user-facing product.

We think that custom build goes the way of the custom web server: something every previous era had to do and no one will miss.

If you're crossing the offchain-to-onchain boundary at any serious scale (tokenized assets, stablecoin flows, first-party price feeds, prediction market reoslution, agentic commerce), 

Introducing Compose: the framework for the offchain half of onchain finance

The journey of a Web3 developer is filled with plenty of twists and turns. Every challenge we face while building onchain applications requires a unique approach, and not all solutions are created equally. With the 

 changing every day, we've identified the core moments of insight nearly every Web3 developer encounters on their path from basic RPC calls to onchain enlightenment.

Simple ETH RPCs are great for managing and syncing nodes. But when it comes to powering user-facing applications, RPCs alone leave a lot to be desired. Designed around the needs of consensus, the ETH RPC API can be challenging to work with for many types of queries we'll commonly encounter.

For example, if you want to show all NFTs and their owners within a particular collection, many network hops are required and the data processing load in the client can be overwhelming. Additionally, data is often encoded, requiring yet another operation to run in the client while your users are stuck staring at a loading indicator.

In a demo project, we saw page load times upwards of 10 seconds just to display a small collection of about 20 NFTs. Most Web3 developers, including myself, started by building and experimenting after finding the docs for a node-as-a-service company, which steered us towards an RPC-centric approach (and also happens to require using their service). We can get pretty far after learning this workflow, but eventually will run into performance issues and hard-to-read code without much hope for relief.

Once we hit a wall with ETH RPC, the general way forward is to look for a better solution. Most of us will be very excited to discover the power of indexers like subgraphs, which give us better access to nested datasets produced onchain. Indexers can be thought of as "blockchain scrapers," constantly reading new blocks as they come in and allowing devs to extract, transform, and save the data.

Sample Subgraph Query for NFT Collection Data

By proactively shaping the data as blocks arrive, you can generate a read-optimized copy of the blockchain data your app cares about. The most popular indexer at the time of writing is 

, which is an open-source indexer used by many projects across the industry. While The Graph stores indexed data in a Postgres database, most folks consume the data directly via a GraphQL API.

Even with indexers, there is a lot of engineering work required to keep things running smoothly. At Goldsky, it's taken a lot of time (and code) to get to a place where our subgraphs are stable, fast, and cost-effective at scale. Great indexing requires domain-specific data engineering expertise to perform the necessary optimizations to handle reorg errors, volume spikes, and realtime access to data.

Singular EVM nodes can often lag due to their "eventually consistent" nature and can easily get bogged down by lots of traffic. By load balancing between nodes, 

, Goldsky been able to mitigate indexing costs for end users while simultaneously boosting both the speed and the accuracy of indexing.

Building these systems in-house is a lot of work! At Goldsky, we believe that Web3 companies shouldn't have to manage these heavy infra optimizations themselves, when they could be focusing energy on their core product experience.

Using Graph nodes almost always entails using an API as the sole mechanism for consuming onchain data. But as projects begin to scale, they tend to need additional flexibility that APIs aren't equipped to provide. Web3 companies often run into these types of scaling issues very early in their evolution.

APIs are limited for situations like analytics and optimized queries, leading to development bottlenecks and headaches for the team. Project requirements like search, cross-chain access, or off-chain data mapping can create even more challenges. As business needs grow and diversify, you can soon find yourself in a similar boat to where you were when you first started using RPC nodes — stuck using an API for something it wasn't truly designed for.

Nearly every software company faces scaling challenges as they grow. While Web3 offers a new flavor of these problems, they're not necessarily unique — and because of that, we have a lot of prior art we're able to draw from.

Onchain Data Streaming Pipelines: Limitless Potential

Given the limitations of direct RPC calls and the headache of managing an in-house indexer, Goldsky proposes a new solution. We believe, at the end of the day, that all roads lead to the modern data pipeline.

Using modern data engineering tooling such as 

 as a foundation, Goldsky is bringing a new, streaming-first approach to onchain data accessibility. 

 allows us to do some very powerful things with onchain data:

- Gather and merge data from multiple onchain and offchain sources, and integrate new sources as they're available.

- Process, shape, and filter data directly with SQL.

- Sync live data to multiple destinations: Postgres, Elasticsearch, Kafka, s3, and more.

- Query, search, and build with enterprise-grade tooling under the hood.

Reframing onchain data challenges through the lens of the modern data pipeline gives us a brand new look at the full potential of managing, storing, and serving onchain data. When we start to view indexers like subgraphs and 

 as data sources in a pipeline versus a final output, we can begin to envision a world of possibilities for tailoring highly-performant datasets for any business use case.

 mission is to unleash the full potential of Web3 data.

We’re solving complex data engineering challenges so that builders can focus on what matters most — building transformational applications and delivering value to users.

 for full access to Goldsky’s realtime data streaming platform today, and be sure to give us a follow on 

The Web3 Developer's Journey: From RPC → Indexing → ETL

Web3 developers require reliable, fast, and cost-efficient access to blockchain transaction data to build the next generation of applications. Goldsky’s industry-leading architecture employs several technical approaches to make blockchain indexing faster, more efficient, and optimized for existing data stacks.

Goldsky’s RPC (remote procedure call) load balancer is a key component of our indexing infrastructure. By leveraging multiple RPC providers to retrieve live blockchain data, Goldsky enables efficient access to realtime transactions while keeping the system resilient, performant, and cost-effective.

Goldsky’s RPC load balancer utilizes intelligent failovers whenever our RPC providers experience issues. This allows Goldsky to stay at the edge of the blockchain and continue to reliably stream live data.

Recently, we enhanced our RPC load balancer with a serverless cache using 

 which allowed us to reduce the number of outgoing RPC requests our load balancer makes by more than half, while also improving p50 request latency by 75%.

 greatly reduced our reliance on RPC providers, but for architectural reasons, the Graph Node still uses RPCs for chain head updates. Implementing serverless caching into our RPC load balancer allows us to more efficiently call RPC providers when we need them.

One of the challenges of implementing a caching layer into our RPC load balancer is handling blockchain reorgs. The blocks at the edge of the chain are not immutable, so our caching layer needs to account for these scenarios properly.

Our key insight was to add a TTL (time to live) for each cached RPC response 

 for a given chain. For example, Ethereum mainnet has a block time of 12 seconds, so the TTL for cached RPC responses is 6 seconds. Polygon mainnet has a block time of 2 seconds, so the TTL for cached Polygon RPC responses is 1 second. This TTL ensures that even if a reorg happens, the cached response will be invalidated at most within 2 blocks.

As an edge case example, suppose that our RPC load balancer serves and caches a mainnet block a time 

 (because the block time is 12 seconds) a new block is minted. From time 

 our cache will serve incorrect information to the Graph Node. However, as soon as the Graph Node makes an RPC request 

 it will see and gracefully handle the reorg that happened at time 

. This also means that when The Graph requests the new block at 

 it will see and handle the reorg that happened at time 

. Even though our RPC layer can serve invalid information to The Graph due to the nature of how blocks propagate through the network, indexing speeds aren’t impacted because stale information will not be served for more than 1 block and more often than not we serve valid data from the cache instead of relying on an external RPC service.

At Goldsky, our goal is to provide developers with the fastest, most efficient access to blockchain data. Innovative features like serverless caching and load balancing are just a few ways we’re making that a reality.

 for the latest feature releases and product updates.

Real-time Data

RPC Infrastructure

Automation

Open Source

Follow

Benny Sidelinger

Benny's articles