Goldsky vs Stork

Stork ships data feeds. Compose ships an execution framework. That distinction explains most of the trade-offs below. Stork hands you a finished, decentralized price feed to consume. Compose hands you a way to build and run oracle logic of your own.

Stork pioneered the pull oracle model. Instead of a provider pushing prices on a fixed heartbeat and paying gas for updates nobody uses, Stork’s publishers continuously sign and aggregate data off-chain. Your application listens to that signed stream and posts an update on-chain only when needed. It verifies the signature and recency, then consumes the value in the same transaction. The result is fresher data, better gas efficiency, and no dependence on the provider’s update schedule. For a standard market-data feed, this design works well, and Stork executes it well.

Compose solves a different problem. It is the framework Goldsky offers for writing durable TypeScript that crosses the offchain to onchain boundary. A trigger, such as an onchain event, a cron schedule, or an API call, starts your code. Your code can read many chains and external systems, compute whatever your application requires, and write the result on-chain. Compose traces, versions, and can recover the whole execution through downtime. Your oracle might really be a piece of business logic: a fund’s net asset value, a reserve attestation, or a prediction market’s resolution rule. Compose lets you express that logic directly, instead of forcing it into a generic numeric feed.

Stork is a latency-focused price-feed network. Stork’s architecture is tuned for speed.

• Stork reports sub-second latency, often closer to several tenths of a second. Aggregators hold fresh data at least every 500ms.^[3]
• Stork for Real Time uses fast websockets to make data available at the millisecond level.^[4]
• Stork’s case studies cite outcomes like Extended, a perps exchange, which reports under 1ms oracle latency and 99.999% uptime from Stork.^[5]
• Stork’s case study also reports end-to-end latency below 5ms for Extended and more than $230B in total trading volume.^[5]

If your protocol depends on price freshness, such as a perp DEX matching centralized-exchange speed, that specialization matters. A build-your-own oracle is not built for that case.

Compose is not trying to win the price-tick race. Its value is correctness, control, and traceability: durable execution, exactly-once delivery, and immutable tracing.

• A Compose oracle’s latency depends on your trigger cadence and the work it does.
• A Compose oracle runs fast for a NAV that updates per block or a reserve proof that runs on a schedule.
• Compose is not a substitute for a millisecond-grade price push.

They optimize for different metrics.

This is where Compose does what a price-feed network can’t: turn your own data and rules into an oracle. Stork’s Temporal Numeric Value primitive can carry arbitrary signed numbers, and its Composite Oracle Service can tune custom aggregations^[4]. This is genuinely flexible for market-style data, but it still delivers a signed number aggregated from publishers, not an arbitrary computation you author and prove.

Compose is purpose-built for the long tail of oracles that don’t fit a standard feed:

• NAV oracles: for tokenized funds and RWAs, computed from your books and custodial data and posted on-chain on your cadence.
• Proof-of-reserves: that pull from your own systems (and many chains), compute the attestation, and write it with a full, immutable execution trace.
• App-specific resolution: prediction-market outcomes, corporate-actions distributions, or settlement rules that depend on your application’s logic, not a market price.
• Identity and compliance attestations: turn KYC/AML or other off-chain checks into on-chain attestations as part of a durable workflow.

We publish guides for exactly these patterns:

• Building a Bitcoin oracle.
• Building a VRF system.
• Building a NAV oracle.
• Building a prediction market.
• Building proof-of-reserves.
• Building a corporate-actions distributor.

Compose ties them to Goldsky’s indexed data across 150+ chains. Compose covers assets without a standard feed, and logic a generic oracle cannot express. This is the difference between consuming a feed and owning your oracle.

Stork and Compose earn trust in different ways. Stork proves the data’s provenance with signatures. Compose records the computation’s execution with an audit trail.

Stork’s guarantee is cryptographic at the data layer. Publishers sign their inputs, the aggregator signs the aggregated result, and your contract verifies those ECDSA/secp256k1 (EIP-712) signatures on-chain before accepting a value.^[6] You can prove a price came from legitimate publishers and a legitimate Stork aggregator using a stated method. This gives strong assurance for a shared, decentralized feed.

Compose’s guarantee is at the execution layer. Code runs in an isolated sandbox. Every external and state-mutating call is captured in an immutable trace, and state is versioned. You can see not just what number arrived, but how it was computed and acted upon, with an auditable, observable record end to end. For a first-party oracle or a money-moving workflow where the logic must be auditable, this is the assurance that matters.

Stork’s automation pushes prices. Compose’s automation runs your business. Stork offers Auto-Pushed Feeds that write price data to a chain on a schedule and delta-tolerance threshold, a plug-and-play delivery option.^[4] That’s automation of the feed.

Compose automates the workflow around the data. Triggered by events, cron, or API, Compose runs general-purpose keepers and settlement: rebalances, scheduled payouts, liquidations, and circuit breakers. It also runs cross-chain coordination that reads many sources and writes atomically. It runs with exactly-once delivery and managed nonces, so a transaction lands once, even through downtime. A Stork price can be the input to that workflow. Compose is what acts on it. Stork reports the price. Compose decides and executes what happens next.

Stork leads on prebuilt assets. Goldsky leads on data breadth and platform scope. Stork supports 500+ assets across 70+ chains (EVM, Solana, Sui, Aptos, and more, deployable on request).^[1] This gives you a head start if your asset is already in its registry.

Goldsky Compose does not ship a feed catalog. It builds feeds from your data, third-party APIs, and Goldsky’s indexed datasets across 150+ chains. Non-EVM coverage includes Solana, Bitcoin, NEAR, Arweave, Stellar, and Sui.^[9] If you need a standard asset that Stork already publishes, Stork is faster to integrate. If you need a feed for an asset, metric, or event no network publishes, Compose covers it. The same applies if you want the oracle wired directly into data you are already indexing. A price-feed catalog does not cover this ground.

Stork prices a feed by sales conversation. Current Goldsky Compose rates are on docs.goldsky.com/pricing/summary.