AI × Blockchain: Put ABT to Work as We Build

Build a thriving agentic digital city with ArcBlock.

Everyone is talking about AI. What is blockchain still useful for? With ArcBlock doing so much in AI, what value does ABT have here?

Both questions deserve a direct answer. We are building AI into the platform to bring blockchain and ABT into more useful applications. The identity, authorization, and verifiable records we have been working on have more work to do when people and agents work together. ABT needs a concrete role in that work too.

I recently posted a thought on X. Discussions about AI agents and blockchain tend to settle on payments. I care more about what the agents are there to do. A place can process plenty of payments and still have very little worth coming back to use.

An agent economy has to grow out of useful applications. ArcBlock's job is to build the infrastructure so that we and our community can solve real problems on it. Blockchain has a foundational role where identity and evidence matter. ABT remains the single utility token for the ArcBlock ecosystem. Those designs need people building things and people continuing to use them.

I like thinking about this as an agentic digital city: people and agents have their own workspaces, with applications and services running around them. Like a physical city, it needs roads, utilities, and places where people can live and work over time. It comes to life when someone moves in, opens a shop, or offers a useful service to a neighbor. Agents add another kind of participant to that work. That is the opportunity I find exciting.

Infrastructure gives applications somewhere to grow

An agent can pay for an API call through a credit card, a stablecoin, or another existing payment network. The choice depends on the user and the service.

Once an agent acts on your behalf, other questions appear. Who does it represent? What permission did it receive? What did it deliver? What can both parties check if something goes wrong? I covered these questions in AI Agents Need More Than a Wallet. Now I want to take the next step: what grows on top of that foundation?

ARC, the Agentic Realm Computer, is the runtime where we are building it. ARC already provides default mounts for accessing ArcBlock's own chain. Applications can read chain data through the system's entry points without each installing a separate integration module. Chain access belongs in the runtime, much as networking does.

AFS, the Agentic File System, gives different resources a common access structure. Providers are the integration modules connecting those resources. Applications can read ArcBlock chain records through the system-provided approach. Corresponding modules can extend that structure to other chains, including Ethereum. My focus here is the role of ArcBlock's own chain within this environment.

There is a long history behind this. Three Generations of OCAP: From Chain Access Protocol to AFS traces the move from a common chain-access interface, through Blocklet components, into AFS. The placement has changed. The repeated integration work we want to remove remains familiar.

ArcBlock's chain can serve as the common foundation of this city. Payments handle costs. Identity and authorization establish who can act. Proof makes important records checkable. Smart contracts turn parts of an agreement into executable operations. Together, these serve a practical purpose: independent people, agents, and applications need ways to collaborate under shared rules.

Suppose an agent asks another service to do a job. Both sides need to know who requested it, who was authorized to accept it, and which charge corresponds to which delivery record. Each shop can keep its own internal books. When it does business with another shop, they need common ground. Otherwise, every additional service may bring another account system, permission mechanism, and reconciliation process. Shared infrastructure should reduce that repeated work.

Existing chain capabilities give us concrete starting points. Delegated transaction permissions let one account authorize another to perform specified types of operations. Token factory contracts put rules for creating and managing tokens into executable mechanisms. ARC's default chain access currently provides reads; signing and submitting transactions have their own flows. Connecting these foundations into fuller agent settlement and proof workflows is work we are continuing.

When the common network keeps running, each application can concentrate on its own service.

Think of electricity and public-service networks in a city. Applications can keep their internal implementations while important actions across parties have a common basis for checking records. DIDs, a form of digital identity, provide verifiable identity relationships. Blockchain provides evidence for records that need shared verification. Each proof needs a defined scope. Whether the service did its job still needs acceptance.

The more we handle in the foundation, the more attention an application builder can give to making a service people want to use.

ABT's value is in the work it does

ABT is the native token of ArcBlock's public network and the single utility token for the ArcBlock ecosystem. It can be transferred on the public network, pay for services in applications that accept it, and be staked to back network access or service commitments. Each use solves a specific problem worth spelling out.

Stake for Gas is one concrete example. Staking ABT under the public network's rules provides a transaction-fee exemption. The ABT remains locked as a commitment to responsible network use rather than being spent on each normal transaction. Reducing payment friction on repeated operations is a real product concern for users and agents carrying out ongoing tasks. The exemption covers network transaction fees; applications and external services retain their own charges.

Stake for X puts ABT behind a commitment. Participants declare a purpose, a validity period, who may slash the stake under which conditions, and how withdrawal works. They then lock ABT under those rules. Someone accepting a service commitment can see funds committed under defined conditions as well as a promise.

SubGuard subscription protection, already released in Payment Kit, applies this design to service continuity. Users stake ABT for a participating subscription. If payment temporarily fails, the service can continue within an agreed protection period. The original bill remains due. If it remains unpaid, the stake can settle that bill and the service fee under the agreed rules. ABT is doing a very ordinary job here: helping a payment problem avoid becoming an interruption of service.

I discussed these utilities in CLARITY Act or Not, Let's Clarify ABT. Another article, on stablecoins and Credit Tokens, explains the separation between payment and service allowances. How a user pays, which service usage an application records, and how the parties reconcile accounts each need their own design. An application's service credits follow its rules. ABT has native uses in the public network and collaboration between participants.

ABT's product value is concrete: paying costs, supporting network use, and backing certain service commitments with funds and executable rules. These mechanisms have more work to do in an agent environment. When an agent calls a service, authorization, usage records, delivery, and settlement can progressively connect into one checkable workflow. Full native on-chain settlement and cross-party proof workflows in ARC are still being built. Our work is to connect existing chain capabilities more directly to application needs.

This is one reason we build AI. It lets more people create software and more tasks run over time. ArcBlock's chain and ABT give that collaboration foundations it can use. Applications putting them to work let us find out which designs help and which need improvement.

Applications can still choose existing payment methods such as credit cards and stablecoins. Those choices can coexist with ABT's native network uses. A city has different services and ways to pay, while its common network still needs use and maintenance. We want to make that foundation worth using and give ABT clear work to do.

Why ArcBlock

I think ArcBlock's advantage here is clear: we understand blockchain, we keep building AI, and we have consistently worked on making technology useful. Combining those foundations lets us think about agents, applications, and economic activity as parts of a working system.

Starting only from AI models and tools, it is easy to see blockchain as another payment channel and overlook identity, authorization, and verifiable records. Starting only from a token narrative, it is easy to overlook the runtime, context, and interfaces a useful agent system needs. Both sides require substantial engineering. ArcBlock has spent years building along both paths.

In the blockchain era, we built DIDs, wallets, chains, and Blocklets around applications. Since 2023, we have also been working on AI products and their foundations. Today's ARC, AFS, and AFS-UI, which gives people and agents access to the same interface system, have grown out of that practice. They address how an agent finds resources, understands state, acts within its permissions, and leaves the results with the user.

In 2025, we were invited by the Washington State Department of Commerce to join the state’s technology delegation to Japan IT Week in Tokyo, where we presented our blockchain and AI products. That year, we also sponsored Seattle AI Week and discussed practical AI applications with businesses and the technology community. Being invited to represent Washington State internationally, while helping build the local AI community, gave us concrete ways to bring our years of work into government and industry exchanges.

That work has also brought us into academic discussions about software engineering and architecture. This month, I gave a keynote at the Harness4GenUI workshop during ASE 2026 in Munich, on AFS-UI and stable foundations for generative interfaces. I also took part in the live demonstration and panel.^[1] Being invited to bring our engineering work into that research setting and discuss it directly with researchers is something we can be proud of.

We are also sponsoring ICSA 2027 in Sydney, Australia. We want to keep bringing our product and engineering work to the software architecture community; the forms of those exchanges will be announced as they are prepared. Building lasting infrastructure takes continued discussion with users, engineers, and researchers, and testing designs against real problems.

This is why I have confidence in ArcBlock. Our work in blockchain, DIDs, and AI has let us see connections between these problems early. Our commitment to utility gives us a clear standard. The next task is to turn that advantage into tools and services the community can use.

Bring your agent. We need to live here too.

That is why we encourage BYOA: Bring Your Own Agent. An agent you already use can become a working partner in this environment. We expect more users to want their choice of agent alongside a lasting place for their data and work.

In Builders Change. Property Stays., I used the example of a construction crew. You may hire a different crew for a different job. The materials, finished work, and authority to admit people belong within a boundary the owner manages. Digital property here means a boundary around data and permissions, rather than the scarcity of physical land.

Agents come and go. Work needs somewhere to accumulate.

Our focus will be basic applications and an environment where agents can work. Users pay for the space, storage, and runtime services they actually use. They can also bring an agent they have already chosen and paid for. That puts the service relationship closer to software and infrastructure services. In the city analogy, we provide usable spaces and shared facilities.

I think simply reselling model tokens offers limited room to build a lasting advantage. Model companies control the models and their supply. A reseller has a limited contribution to add. ArcBlock has more useful work to do: give users a home for their data and let different agents enter with defined permissions and leave their work there.

ArcBlock needs to live in this digital city too.

An early-stage view of the same agentic digital city. Participation begins with a real problem and a useful tool.

We will keep using ARC to scratch our own itch: problems we repeatedly run into and want solved. Once we build something, the first question is whether we keep using it. The next is whether it helps people in our community with similar problems. If we do not want to open it every day, expecting others to love it is a stretch.

We will concentrate on the platform and foundational services, including ArcSpace and surrounding tools such as Aside and Atlas. ArcSpace provides a direction for personal data and workspace services. Aside focuses on collecting and organizing everyday content. Atlas explores organizing knowledge and project context for people and agents. These are areas we have chosen to keep working on; each product's capabilities will develop with its versions.

We do not plan to build dozens of unrelated applications to fill an ecosystem diagram. The platform team needs to concentrate on foundations other people can build upon. Problems from daily use feed back into the platform. Each improvement should make the next useful thing a little easier to build.

As tools become ready for wider use, we want to release them promptly as Public Betas. From ArcSpace to Darc Factory and Atlas as they become ready, each will move at its own pace. Darc Factory explores organizing agents for software production. The purpose of opening these tools is to let people try them sooner, find out whether they improve their productivity, and bring real problems back to us. Each tool will have its own Beta announcement.

We work on the basic tools we need most. The community can use those tools to explore further. New uses make new demands on the foundation, and the foundation improves again. It is cumulative work that we and the community do together.

Participating now lets you put tools to work sooner and bring actual needs into their development. Problems solved, work retained, and experience organizing agents become foundations for the next thing you build. Anyone who wants to offer a service can begin by testing it through their own use.

Start with something small

Turning a small need into software you could keep running used to mean finding a software engineer willing to put in the time. AI is lowering that barrier. Someone who understands a problem can now organize agents to do more of the engineering and spend more attention on the product decision: what would make this worth using every day?

The need can be small. Suppose you keep organizing the same kind of material every week and want a tool that turns it into records you and your colleagues can keep using. Build something you can use, then see whether it saves work. Which material it needs, which permissions it needs, and how to check the result become concrete through use. Your problem might be an entirely different inconvenience in daily life.

Your own problem has an advantage: you know when it has been solved. Other people may have a similar one. Helping a friend use the tool, and hearing where their needs differ, can take the product further than imagining an enormous audience on paper.

Between personal use and a neighbor asking to try it are many small improvements.

Even a free application uses storage, compute, or AI services. Someone pays those costs, creating real relationships between the people using resources and the services supplying them. Resource consumption alone is not enough. The tool has to help someone enough to justify keeping it running. Burning more compute on an application nobody wants to use again gets us nowhere.

Some applications will be maintained by their creators. Some will become paid services. Others will remain small tools shared among friends. Each can be a real activity in the city. As more people can build and maintain useful applications, the services involved develop reasons to collaborate and settle accounts. Blockchain and ABT then have specific situations in which their roles can be tested.

Get it right, and growth can be explosive

A small starting point can become a product many people need. AI lets one person or a small team do more. Once a product solves a real problem and finds others who need that solution, it has a chance to grow explosively. Refinement may take a long time, while the breakthrough can come quickly. That is one reason I encourage people to start building now.

The AI industry has just given us a timely example. On October 26, 2026, Anthropic filed its public S-1 for a proposed IPO. It reported $386 million in revenue for 2024 and $4.585 billion for 2025. Revenue in the first half of 2026 reached $16.286 billion, compared with $1.163 billion in the same period a year earlier: roughly 14 times as much.^[2] These are actual revenues for the stated periods. An already substantial business crossed into a different scale within a short time.

Lovable is an example closer to helping more people build software. In its November 2025 anniversary post, it reported that ARR had doubled from $100 million in July to $200 million four months later.^[3] ARR is an annualized recurring-revenue measure, distinct from Anthropic's actual period revenue. Each set of numbers shows how quickly a product can grow once a specific use finds its users.

What interests me is the possibility behind those numbers. AI lowers the barrier to making things and gives a useful service a chance to reach many more people quickly. Growth can be explosive. The essential work is getting the thing right: find a real problem and make something people want to use repeatedly. Coding and application building already offer examples. Daily life and other industries still have many problems worth solving.

One feeling I carry from building companies is that the hardest work often happens when very little seems to be changing from the outside. You may spend a long time trying, refining, and barely getting through, with little visible movement. Then a breakthrough can arrive suddenly. A key problem finally gets solved, the product connects with what people need, and growth takes a different shape.

I do not think about a new product as something that must add the same small increment every day. The work worth doing is finding the right problem, making the product work, and giving users a reason to stay. An apparently small improvement can be the thing that makes it useful to many people. We cannot put the breakthrough on a calendar. We can make something worth finding.

The same city, with diverse activities above and a Tiffany-blue network below representing the ArcBlock foundation. This is a metaphor for collaboration, not a deployment topology.

From the air, this city might have a commercial district alongside quiet homes and parks. Some people make tools; others provide everyday services. It has many centers. Its shape depends on what its residents need and choose to build. A common infrastructure network connects those places. The community's own explorations give them variety. Money and settlement systems serve the real activities happening there.

Exploration and refinement may take a long time. Growth after finding a useful purpose can be fast. Anthropic and Lovable make that possibility visible. Their results will not transfer to us automatically; costs, experience, and continued delivery still need to work. We can build each useful starting point carefully and prepare for the day many more people need it. I do not know which application that begins with. That uncertainty is one reason the community's explorations are worth looking forward to.

ArcBlock's utility approach stands against the logic of meme-coin speculation. Keeping attention alive through emotion and cycling through concepts to attract the next crowd cannot get a user's job done. Our standard is actual use: did the application solve the problem, can the service keep delivering, and will the user come back tomorrow? Blockchain and ABT must meet that standard too.

Back to the questions we started with: what is blockchain useful for in the AI era, and what value does ABT have? My answer is clear. AI lets more people build software and more agents act continuously on their behalf. As they collaborate across people, applications, and organizations, identity, authorization, proof, and settlement have more work to do. ABT belongs in that work through payments, network use, and service commitments.

ArcBlock's years of work on chains, DIDs, and applications are coming together with our AI engineering. We will keep improving the platform, make our own work better with it, and open tools to the community as they become ready. People in that community can bring their agents and build new applications and services on those foundations. Something that suddenly becomes useful to many people may begin right there.

We want to build a thriving agentic digital city. A thriving city has people solving problems, building and maintaining tools, and services continuing to work together. Blockchain provides common foundations for that collaboration. ABT has specific work to do within it. The variety of activity gives us concrete situations in which to test and improve these designs.

Put AI's productive capacity, blockchain's foundations for collaboration, and ABT's utility into one working system. That is ArcBlock's next task, and the work we invite the community to share: build this agentic digital city, and put ABT to work in its construction.

References

1. Harness4GenUI 2026. Official program and keynotes. ASE 2026, Munich, October 12, 2026. ↩
2. Anthropic, PBC. Form S-1, Summary Consolidated Financial and Other Data; Comparison of the Six Months Ended June 30, 2025 and 2026. October 26, 2026. ↩
3. Anton Osika. One year of Lovable: Welcome to the age of the builder. Lovable, November 18, 2025. ↩