OCAP’s Three Generations: From Chain Access to AFS

OCAP was one of ArcBlock’s earliest ideas. The name stands for Open Chain Access Protocol. If you encounter it in our original white paper, in my book, or through our blockchain access-layer patent, then look at ARC today, you might reasonably ask: where did that protocol for accessing different blockchains go?

OCAP’s history is the story of an access abstraction finding a different home in three generations of products. It began as a chain-access interface in front of applications. It became a responsibility carried by components in the Blocklet architecture. In ARC, that responsibility is part of AFS, the Agentic File System, whose scope also includes files, data, and services.

Those are substantial changes. To understand them, it helps to separate the enduring design intention from the software that expressed it at each stage.

The idea that attracted more attention than I expected

When we designed ArcBlock in 2017 and prepared the original white paper, OCAP sat near the foundation. Above it were Blocklet and a broader set of ideas about developing and running applications. To me, OCAP was a relatively simple, practical part of that design: give applications a reasonably stable way to access chains, and let drivers handle the differences underneath.

When we began presenting the project, however, audiences kept coming back to OCAP. We would explain the larger platform, and the conversation would return to this access layer. That surprised me. It also influenced how we presented ArcBlock afterward: we gave OCAP more room because people wanted to hear about it.

Looking back, the appeal is understandable. Bitcoin, Ethereum, and permissioned blockchains had different interfaces and concepts. Developers could hardly know, before building an application, which chain they would need in the future. Supporting another chain could mean learning another data model, calling convention, and toolset. People might not immediately need our whole platform, but they understood the cost of doing that work repeatedly.

That was the work OCAP was meant to reduce. My direct inspiration was ODBC. Java developers may be more familiar with JDBC: an application uses a common database-access API, while drivers handle individual databases. We wanted a similar division of work for blockchain applications. This is not an analogy added years later to tidy up the story. The early technical white paper explicitly discussed ODBC, JDBC, and chain adapters.

Background: what are ODBC and JDBC?

ODBC means Open Database Connectivity. It defines a common API for database access. A driver translates calls for a particular data source, so an application need not build a separate low-level connection implementation for every database.

JDBC is Java’s database-access API. Java applications work with connections, statements, and result sets through interfaces implemented by database drivers. JDBC does not require ODBC: the historical JDBC-ODBC Bridge was one approach, alongside drivers that connect directly to a database.

These APIs standardize access conventions. They do not make databases identical or erase differences in SQL features and transaction behavior. See Microsoft’s ODBC explanation and Oracle’s JDBC introduction.

From that starting point, OCAP did not need to become another blockchain or a virtual Layer 2 above all the others. A Layer 2 adds a transaction-execution or scaling system that relies on an underlying chain. Our immediate problem was how an application would access a chain, without making the access interface responsible for running that chain.

First generation: make the chain usable

The earliest implementation started with Bitcoin. At the conceptual level, an API or library separating an application from a chain’s specific interface could already express the OCAP idea. When we made that experience available to developers, we chose GraphQL.

GraphQL gave us something quite concrete. A client describes the fields it needs, and the service returns data according to defined types and relationships. Query syntax, documentation, and developer tools could share a familiar approach. Chain-specific implementations remained underneath. We did not need to invent a query language to offer that experience.

GraphQL supplied a common way to express requests; chain adapters did the work of fulfilling them. Even when two chains are accessible through GraphQL, someone still has to design their schemas: the types and fields exposed to callers. What a transaction contains, and how to find records associated with an account, are not questions GraphQL answers for us.

We released OCAP Playground on June 30, 2018. Developers could open a browser, write a query on one side, and inspect results on the other, without first setting up a chain-node environment. The original getting-started article walked through a query for Bitcoin’s genesis block. Bitcoin came first in the implementation work; the public launch article already discussed both Bitcoin and Ethereum. Those are different points in the timeline.

Behind the query interface, we also collected, organized, and indexed chain data. Having a ledger on a node does not mean its contents are already arranged around the questions an application wants to ask. Conveniently retrieving an account’s related records can require turning raw chain data into structures suited to querying. The first generation therefore included both the visible GraphQL interface and the data services supporting it.

The access path was straightforward: an application or Playground sent a GraphQL request to OCAP, which used the appropriate chain adapter and indexing work to reach Bitcoin or Ethereum. The diagram shows access dependencies, not assets moving between chains.

The 2018 interview about our choice of GraphQL preserves the team’s reasoning at the time. Read alongside the release and tutorial, it shows the choice, the product, and the experience of using it. That is a more useful picture of early OCAP than an architecture diagram alone.

Second generation: access becomes part of the application architecture

When we began implementing our own blockchain, the next question followed naturally. If common access was already the experience we wanted to offer applications, why not design for it from the beginning, in the chain and its developer tools?

Forge was our framework for building blockchains. GraphQL was one of its application-facing interfaces from the outset. We also used the name OCAP Chain for our own chain: the access design had become part of the chain itself, rather than an external wrapper. The 2019 introduction to Forge documented both GraphQL and gRPC, a way for programs to invoke operations on remote services. Making GraphQL central to application access did not require every layer to use it.

The next change is easier to understand once Blocklet is defined. A Blocklet is a deployable, runnable unit of software. It can be a complete application or a service used by other applications. ABT Node supplied the environment for running and composing these units; it was later renamed Blocklet Server.

Consider an application that needs to read chain data. In the first generation, it primarily connected to an independently operated OCAP service. In the second-generation architecture, that access service could itself be a Blocklet, deployed and composed alongside other components the application needed. The application still called an interface. What changed was how the software was organized and delivered: the data supplier and the integration component no longer had to be tied to that one standalone service.

My 2023 architecture retrospective recorded this transition: the first OCAP service, built around AWS indexing infrastructure, was succeeded by OCAP components built on Blocklet. The 2021 OCAP-JS release notes also show the name in the continuing development of our own asset chain and SDK. The software carrying the name was evolving with the products.

Access to external chains did not require every request to pass through an indexing service we operated ourselves. Applications could use suitable chain services, with components handling the integration. Who supplied the data, and which interface they used, became implementation choices within that part of the system. The access responsibility remained, while the modules carrying it could follow the application’s needs more closely.

The second-generation diagram therefore shows a Blocklet application using chain-access components to reach an ArcBlock chain or external chain services. It describes responsibilities, not a requirement that every service share one physical endpoint.

Database software offers a useful comparison. With an ORM, an object-relational mapping tool, an application often works primarily with objects and query models instead of repeatedly writing connection and result-handling code. JDBC has not thereby disappeared. Hibernate’s official documentation still covers JDBC connections and access. A higher-level tool can retain the connection layer internally while moving the application’s working interface upward.

That is how I understand this stage of OCAP. A responsibility in an architecture does not have to remain a separate product at its outermost boundary.

Third generation: ARC carries access through AFS

With ARC, the problem becomes broader. Applications need blockchains, but also files, databases, and services. AI agents need to find these resources, understand what they support, and use them with appropriate authorization. If each resource requires a wholly separate way to discover and access it, the original OCAP problem returns at a larger scale.

ARC stands for Agentic Realm Computer. It organizes resources through AFS, the Agentic File System. Resources appear in a tree of paths. A provider adapts a particular underlying system to that tree. Callers can use shared operations such as listing, reading, and querying; providers translate those operations into requests the underlying systems understand. The operations available on any resource still depend on its capabilities and permissions.

OCAP’s idea now has a broader place to live. The first generation asked how applications could access different chains. ARC asks how people and agents can access different resources. A blockchain becomes one resource type within that model.

There is a concrete implementation to examine. ARC’s OCAP provider maps ArcBlock chain data into AFS. With the main-network mount, a caller can find accounts, transactions, and tokens through a structure like this; the actual entries come from the corresponding network:

/dev/chain/main/
  accounts/
  transactions/
  tokens/

If filesystem abstractions are unfamiliar, think of the change this way. Previously, you would locate a chain API and learn its calling conventions. Here, you can discover a tree of chain resources, list a collection, and read a record. A transaction has not become an ordinary file on a local disk. It has acquired a common form of address and access.

Interestingly, the current provider can still use GraphQL to communicate with an OCAP service underneath. AFS carries the shared access responsibility facing the application; GraphQL can continue to handle communication between a provider and a chain service. A request can look like a path read on the outside and a GraphQL query on the inside. The two layers fit together.

In this generation, people and agents use AFS within ARC. AFS routes access to a provider, which connects to chain services or other resources. “Other resources” in the diagram indicates the common integration model, not identical read and write capabilities for every resource.

A resource model with a human interface

Common paths are useful beyond programmatic access. ARC’s blockchain browser, Chain Explorer, uses chain resources and their accompanying interface descriptions to present accounts and transactions to people. An agent can access those resources through AFS operations. Human interfaces and programmatic access can be organized around the same resources, instead of starting with two disconnected data models.

AUP, the Agentic UI Protocol, describes interfaces for people. The AUP resources accompanying the OCAP provider allow chain-data structure and appropriate presentation to be supplied together. This carries the idea beyond trying queries in a standalone Playground: chain access is part of the computing environment, available for applications to reuse.

The same approach allows providers to be written for Ethereum, Solana, or other chains. That is an extension path, not a list of integrations already shipped. The existing implementation discussed here is the OCAP provider for ArcBlock chains. Users should inspect what a particular provider exposes and which operations it implements, rather than infer support from an architecture diagram.

A common path does not replace chain rules

Making a chain accessible through AFS does not turn ledger changes into ordinary file writes. The current OCAP provider offers read-only access to chain data. Reading a transaction and initiating a transaction that needs authorization, a signature, and network processing are different operations. A path helps locate an object; it does not approve a transaction for anyone.

Bitcoin and Ethereum also retain different account and transaction semantics. Applications can reuse access patterns while preserving the network identity, confirmation state, and data timing that matter to their decisions. That boundary continues from OCAP into AFS. A useful abstraction reduces repetitive integration work without removing facts the application still needs.

What ARC advances here, in my view, is a general resource-access model for that division of work. An application can bring chain records and other information it is authorized to use into one workflow. An agent need not approach every resource as an entirely separate world of tools. Resources retain their capabilities and authorization boundaries, while discovery and access can follow a common method.

Where the patent fits

Our Publications entry for Blockchain adapter, protocol, and access layer records US patent US11676139B2. It is directly related to OCAP and came from our work on common chain access and adaptation.

The public text describes particular request, adapter, structured-data, and client-signing flows. GraphQL appears in a dependent claim. It helps explain early OCAP’s implementation, but legal scope must be read from the actual claims. Architectural continuity is not a basis for saying that every common interface belongs to the patent, or that AFS necessarily falls within its coverage.

For a closer explanation of those mechanisms, One interface, several chains: which differences must stay visible? discusses querying, adaptation, and transaction signing. This retrospective follows a different thread: how the same access responsibility found new implementation homes as the application architecture developed.

Reading the history together

The OCAP material in Blockchain in Practice belongs in this history. It records how we explained blockchain access at that point. Later articles and implementations continue the work. The old material need not be rewritten to sound current; a new retrospective can connect the dates and the ideas.

I did not expect an access layer I considered relatively simple to become such an important way for people to understand ArcBlock. Its subsequent changes also helped me distinguish the responsibility worth preserving from the software form that happened to carry it.

In the first OCAP generation, we made that responsibility a chain-facing interface. In Blocklet, it entered composable application components. In ARC, AFS extends it into a common way to access different resources. Each generation requires new engineering work and carries forward problems the previous one already addressed.

So if someone asks where OCAP is today, I would start with ARC’s resource tree. Follow a chain path downward, and the original, practical job is still there: let applications concentrate on what they want to do, and let the appropriate layer handle how to connect to the system that does it.