Brevis ZK Coprocessor vs. Space and Time: A Complete Comparison for Developers

Choosing the right ZK coprocessor for one’s project is one of the most consequential infrastructure decisions a blockchain development team can make. The platform you select will determine not just the cost and speed of your verifiable computations, but the scope of what you can build, the complexity of your development process, and the chains and data sources your application can access.

Two of the most prominent names in the space are Brevis and Space and Time (SXT). Both offer zero-knowledge proof capabilities for offchain computation, but each approaches the problem from a fundamentally different angle: Brevis is an on-demand ZK coprocessor that fetches data and generates proofs for specific computations, whereas Space and Time is a full verifiable compute layer built around a multi-chain indexed database and a SQL-native interface with automatic proof generation.

In this deep dive, we compare Brevis and Space and Time across every dimension that matters for production applications: data access, cost, performance, query capabilities, developer experience, cross-chain support, and more. By the end, you will have a clear picture of which platform is better suited for your use case and why the differences between them are more significant than they might appear at first glance.

Architecture: Two Different Philosophies

Understanding the architectural differences between Brevis and Space and Time is essential to understanding everything else about how they compare.

Brevis operates as an on-demand proof generator. It does not maintain a persistent, pre-indexed database. When you need to prove something, Brevis fetches the relevant blockchain data at query time, runs your defined computation over it, and generates a ZK proof. This model keeps storage costs low (you are not paying to maintain a persistent dataset), but since data must be retrieved before computation can begin, it comes with the complication of dramatically increasing latency and complexity at query time

Space and Time takes a fundamentally different approach: it maintains a persistent, continuously indexed database that ingests data from all major blockchains and smart contracts in real time. On top of this, developers can create custom tables and ingest offchain data. When you query this database using standard SQL, SXT automatically generates a ZK proof (using its Proof of SQL technology) that the query result is correct and has not been tampered. Verified results can then be served to every chain supported through Chainlink's CCIP network. The proof is generated as part of the query execution; there is no separate circuit definition step, no custom proof logic, and no additional tooling to learn.

This architectural difference has cascading implications across every dimension of the comparison.

Data Sources and Chain Coverage

Space and Time supports 75 chains, including Ethereum, all major L2 rollups, and chains supported through Chainlink's CCIP network for proof computing. This is not just token transfer data; SXT indexes events, transactions, contract state, and more, making it a comprehensive blockchain data layer. Critically, in addition to blockchain data, SXT also supports custom database tables where developers can ingest and store offchain data. This means you can run a single SQL query that joins onchain transaction data with offchain business data, and receive a ZK proof that the entire result is correct, a capability that no other ZK coprocessor in the market currently offers at this level of maturity.

Brevis supports Ethereum and EVM-compatible L2 chains. There is no support for offchain data. The data Brevis can access is limited to what can be fetched from supported EVM chains at query time. This means applications that need to blend blockchain data with external sources — for example, loyalty programs that combine onchain activity with purchase history, or DeFi protocols that need oracle price feeds alongside historical trading data — cannot be built on Brevis alone.

Verdict: SXT's 75-chain coverage with offchain data support dramatically outscales Brevis's EVM-only, onchain-only scope. For any application that touches multiple chains or needs offchain data, this is a decisive advantage.

Cost Comparison

Cost is always a critical factor for production applications, and the pricing models of these two platforms reflect their architectural differences.

Space and Time uses a transparent, usage-based pay-per-proof model. Costs scale based on the number of rows processed and the complexity of joins involved. This model is predictable and aligns cost with the actual value delivered: simple queries are cheap, and complex analytics cost more.

Brevis utilizes an opaque pricing model: costs grow with query complexity, and it is difficult for developers to predict what a given proof will cost before running it. Because Brevis does not maintain persistent data, every query incurs the overhead of data fetching. For applications that run frequent queries or need to process large datasets, the per-proof cost can escalate quickly. The lack of pricing transparency makes it challenging to budget for production workloads with any confidence.

Verdict: Brevis's opaque pricing model and escalating costs as query complexity increases make it difficult to budget for at scale. SXT's transparent, usage-based pricing offers far better cost predictability and often better value for production applications.

Performance and Latency

Speed matters for user-facing applications. Here, the differences between the two platforms are significant.

Space and Time delivers proofs in 6 to 12 seconds, depending on query complexity and block finality requirements. This latency is consistent because SXT is querying pre-indexed data rather than fetching it on demand. For most application patterns this range is more than adequate.

Brevis has latency that scales directly with the number of data points being proven. According to project documentation, the numbers are:

• 64 data points: 58 to 69 seconds
• 256 data points: 68 to 81 seconds
• 1,024 data points: 127 to 144 seconds (over two minutes)
• 4,096 data points: 323 to 350 seconds (nearly six minutes)

This means that even a modest query touching a few thousand data points takes several minutes to complete. For applications that seek responsive user experiences or near-real-time results, this latency profile is a serious constraint (or even a dealbreaker). It effectively limits Brevis to small-scale, infrequent proof generation tasks.

Verdict: SXT is dramatically faster, especially for queries that touch more than a handful of data points. The performance gap widens as query complexity increases, making SXT the clear choice for latency-sensitive applications.

Query Capabilities and Operations

The range of computations you can perform determines what you can actually build with each platform.

Space and Time supports the full breadth of SQL operations as documented in their Proof of SQL syntax reference. This includes SELECT queries with WHERE clauses, JOINs across multiple tables, GROUP BY aggregations, subqueries, and more. Because SXT is built on a relational database model, developers can express arbitrarily complex business logic using the same SQL they already know. The supported data types are comprehensive: booleans, integers from 8-bit to 128-bit, decimals, varchar, varbinary, and timestamps. This covers virtually every data modeling need.

Brevis supports a more limited set of operations through its Circuit SDK. Notably, Brevis does not support bitwise operations at all. The supported data types are Uint248, Uint521, Int248, and Bytes32, a narrower set that can be constraining for applications that need to work with strings, timestamps, or decimal values. Complex queries involving multiple tables, large joins, or rich aggregations are difficult or impossible to express within Brevis's circuit-based computation model.

Verdict: SXT's SQL-based approach is far more expressive and flexible than Brevis's Circuit SDK. If your application needs anything beyond simple arithmetic on a small set of data points, SXT provides the query power to support it.

Developer Experience

Developer experience is often underestimated in infrastructure comparisons, but it has a direct impact on time to market, maintenance costs, and the talent pool available to build and maintain an application.

Space and Time offers what is arguably the simplest developer experience in the ZK coprocessor space: developers write standard SQL queries against SXT's indexed database, and proof generation happens automatically. There are no circuits to define, no constraint systems to learn, no specialized cryptographic tooling to master. If a developer can write SQL — and virtually every developer can — they can build with SXT. The system also supports streaming events into tables automatically, further reducing the operational overhead of keeping data current.

Brevis requires developers to define or generate circuits (or equivalent computational artifacts) as part of the proof generation setup. This is a fundamentally much more complex workflow. Developers need to understand the Brevis Circuit SDK, reason about circuit constraints, and debug at the circuit level when things go wrong. This steeper learning curve translates directly into longer development timelines, higher costs for specialized talent, and more potential failure points in production.

Verdict: SXT's SQL-native approach removes an entire category of complexity from the development process. For teams that want to ship quickly and iterate efficiently, this is a major advantage.

Cross-Chain Reads and Settlement

Modern blockchain applications increasingly span multiple chains, making cross-chain capabilities essential.

Space and Time supports cross-chain queries natively across all its indexed chains. Because all chain data is indexed into a unified database, a developer can write a single SQL query that references data from Ethereum, Arbitrum, Base, and many other chains simultaneously. Settlement is also broadly supported, with integration into Chainlink's CCIP network for cross-chain proof delivery.

Brevis supports cross-chain reads within the EVM ecosystem; that is, only Ethereum and EVM-compatible L2 chains. Settlement is also limited to only Ethereum and EVM-compatible L2s. While this covers many popular chains, it excludes non-EVM ecosystems and provides narrower coverage than SXT.

Verdict: SXT offers significantly broader cross-chain capabilities, both for reading data and settling proofs. For multi-chain applications, this is a clear advantage.

offchain Data Support

The ability to work with offchain data is increasingly important as blockchain applications mature and require integration with the broader data ecosystem.

Space and Time fully supports offchain data. Developers can create custom tables, ingest data from external sources, and query that data alongside onchain state in a single verified SQL query. This enables use cases that blend blockchain verifiability with real-world data; for example, proving that a user's onchain activity combined with their offchain purchase history qualifies them for a specific reward tier.

Brevis does not support offchain data. All computations must be performed over data fetched from supported blockchain networks. This limits Brevis to purely onchain use cases and excludes the growing category of hybrid applications that bridge blockchain and traditional data sources.

Verdict: SXT's offchain data support is a unique capability in the ZK coprocessor space and opens up an entire category of use cases that Brevis is fundamentally unable to encompass.

Use Case Fit

Given these differences, each platform is best suited for different types of applications.

Brevis is a reasonable choice when:

• You need a simple, one-time eligibility check on a single EVM chain
• Your data requirements are small (under a few hundred data points)
• You are comfortable writing circuit-level code
• You do not need offchain data or broad multi-chain coverage
• Latency of several minutes is acceptable

Space and Time is the better choice when:

• You need to query complex, multi-chain data
• Your application involves joins, aggregations, or rich SQL queries
• You need to blend onchain and offchain data
• Low latency (seconds, not minutes) is important
• You want a simple, SQL-based developer experience without circuit design
• You need broad cross-chain settlement capabilities
• You are building a production application that will scale

Real-World Implications

The differences between Brevis and SXT are not just theoretical; they manifest in real development decisions every day. Consider a DeFi protocol that wants to calculate a user's historical trading volume across multiple chains and use that to set a personalized fee tier. With SXT, this requires only a single SQL query across the relevant chain tables, executed in seconds with automatic proof generation. With Brevis, one would need to design a custom circuit, fetch data from each chain independently, handle the cross-chain aggregation logic oneself, and wait minutes for the proof, assuming the data volume does not exceed Brevis's practical limits in the first place.

Alternatively, consider an enterprise application that needs to verify onchain supply chain events against offchain shipping data. With SXT, one can ingest both data sources into the database, write a join query, and get a verified result. Brevis does not support offchain data, so this use case is simply not possible.

Conclusion

Brevis and Space and Time both contribute to the ZK coprocessor ecosystem, but they serve different levels of ambition and complexity. Brevis offers a lightweight, focused tool for simple onchain proofs on EVM chains. It has its place in narrow, low-volume use cases in which circuit-level control is desired and latency constraints are relaxed.

Space and Time, however, operates at a different level entirely. With its comprehensive multi-chain indexed database, SQL-native interface, automatic proof generation, and offchain data support, SXT provides a full verifiable compute layer that can support production applications at scale. It removes the circuit design burden from developers, opens up hybrid onchain/offchain use cases, and delivers the query power and performance that modern blockchain applications demand.

For developers and teams evaluating ZK coprocessors for anything beyond the simplest proofs, Space and Time represents the more complete, more scalable, and more developer-friendly option. The gap between the two platforms is not just a matter of features, but rather reflects a fundamental difference in vision. Brevis asks developers to think in circuits. Space and Time allows developers to think in SQL. In the vast majority of use cases, SQL wins.

‍