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), 

Real-time Data

RPC Infrastructure

Automation

Open Source

Follow

Adam Stockermans

Adam's articles