CLARITY Act or Not, Let’s Clarify ABT

A few days ago, we published a new ABT page. I introduced it on social media with one line: CLARITY Act or not, we decided to clarify ABT first.

The response was stronger than I expected. I think the line captured something simple. We need durable legal boundaries for the blockchain industry, but builders cannot outsource all clarity to the law. What does a token represent? Who controls it? Under what conditions can it be used? What happens when an agreement is broken? How do participants reconcile the record? A product should answer those questions before a statute answers them for us.

In my previous two essays about the CLARITY Act, I discussed why the treatment of a token must follow its actual rights and conduct, and why builders need rules that can survive a change of administration.^[1] I will not analyze the bill again here. I want to turn the lens back on us and explain, concretely, why ArcBlock needs ABT and what we mean by token utility.

This is not a legal classification of ABT, and it is not investment advice. It is a product-design argument: how can a commitment, a service credit, a scarce resource, a digital right, or a multi-party allocation become a rule that people can understand, a system can execute, and participants can reconcile afterward?

This is also why an essay about ABT needs to discuss Credit Tokens, Curve Tokens, and Digital Assets. ABT is the native token of ArcBlock's public network. It has direct uses in network payments, staking, and coordination among participants. An application's own service allowances, resource rules, and digital rights should be expressed by objects with more precise meanings. Calling everything ABT would not create more utility for ABT. It would collapse different rights and responsibilities back into one vague label. Clarifying ABT also means clarifying what it does not need to pretend to be.

Stake is not yield. It puts a commitment on the table.

In crypto, staking is often treated as a synonym for yield. ArcBlock's Stake for X uses a different definition. A stake is closer to a bond, deposit, or collateral. You lock tokens under a declared set of rules for a specific purpose, giving weight to a commitment that someone else can rely on.

The X could be network access, continuity of a service, or another agreement between participants. A stake can declare its purpose and duration, who may slash it under which conditions, where slashed tokens go, and how long exit takes. While locked, it is not a freely spendable balance.

The most direct example is Stake for Gas. Charging gas for every transaction creates substantial friction for ordinary users. Removing every cost, however, makes dust, Sybil attacks, and spam cheap. ArcBlock balances the two by allowing a user to stake ABT on the public network and receive a transaction-fee exemption within normal limits. The token is not consumed transaction by transaction. It serves as a bond for responsible use of the network.

If someone floods the network or abuses the quota, the rules can slash that stake and send it to the previously declared community pool. Normal use can feel close to gas-free while manufacturing junk transactions quickly becomes uneconomical. The important idea is not “free.” It is moving the cost away from each legitimate action and onto conduct that violates the agreement.

SubGuard is another example that has already reached a product. A user can place an ABT stake behind a participating subscription. If a card expires, a payment rail temporarily fails, or a bill is briefly overdue, the service does not need to stop immediately. The original bill remains due. If the user settles it normally during the protection period, the stake is not used to settle that bill and subscription protection can continue. After outstanding bills are paid and SubGuard is disabled, the remaining stake can be returned under the rules. If the bill remains unresolved, the service can settle the bill and fee from the stake under the agreed terms.

Stake for X separates low friction for responsible use from a real cost for abuse.

We deliberately did not make the stake a cumbersome prepaid balance. Paying normally should remain more efficient. SubGuard exists so a payment incident does not immediately become an operational incident, without asking the merchant to carry all the risk.

Take the idea one step further and imagine Stake for Message. A stranger wants to send you a message, so the sender first stakes a small amount. After a legitimate exchange, the stake returns. If the message is spam, the recipient may slash it under the rules. To remove the recipient's incentive to punish people for profit, the slashed amount can go to a community pool rather than to the person exercising the slash.

This cannot create perfect judgment. An honest request may still be misclassified. Trust in the real world always involves accepting some risk. A stake makes the sender take the request more seriously, while telling the recipient that the sender has placed something at risk behind their conduct. The same mechanism could apply to forum posts, event reservations and no-shows, voting, or other contexts where abuse needs to be discouraged. These are design directions, not a catalog of products available today.

Most applications do not need another stablecoin

What many digital services actually need is not a stablecoin of their own. They need a credit ledger, defined by the rules of the business, that can measure usage precisely and support reconciliation.

The GENIUS Act became U.S. law in 2025. It created the first federal framework for payment stablecoins, and in doing so made the meaning of issuing one much more concrete. An issuer must qualify as a permitted issuer, maintain eligible reserves on at least a one-to-one basis, publish its redemption policy and fees, disclose its reserve composition monthly with the required examination, and meet capital, liquidity, operational, compliance, and risk-management requirements.^[2]

I think one of the law's most useful messages to businesses is not “stablecoins are legal, so every company should issue one.” It is almost the opposite. The law turns a previously vague technical idea into a financial business with explicit redemption obligations, reserve responsibilities, and continuing regulatory cost. For an institution that truly needs to provide a broadly usable payment and settlement asset, that may be infrastructure worth building. For an ordinary business that wants to accept payment and meter the service it provides, it is usually a different problem.

A merchant may need to accept dollars, cards, or compliant digital payments. That does not mean the merchant needs to issue a digital asset that maintains a fixed value against the dollar and carries an obligation to redeem at that value. Existing banks, card networks, or stablecoin payment rails can handle the payment. After payment, the business still needs its own operating ledger: what service allowance did the customer receive, how is it consumed, can it be transferred or refunded, when does it expire, and how do several products or partners share the result?

The real-world analogy is straightforward. Supermarkets, factories, hotels, and software companies accept, account in, and settle with dollars or euros. None of them needs to issue its own dollar or euro. For most businesses and network operators, being able to use a payment asset and becoming the issuer of that asset are completely different decisions.

This is also why the arrival of a stablecoin framework did not lead us to create an ArcBlock stablecoin. We do not see a necessary application-level purpose for doing so. Issuing one would make reserves, redemption, liquidity, disclosure, and compliance central product responsibilities, while most applications are trying to solve service metering and reconciliation. For those applications, we provide Credit Tokens so they can express service allowances through explicit business rules.

This distinction deserves an essay of its own. I plan to return to why most businesses do not need to issue a stablecoin after the GENIUS Act, and why Credit Tokens, loyalty points, and verifiable service ledgers are often closer to what their operations actually require. For now, the essential point is that the asset used for payment and the object an application uses to represent service should not be collapsed into the same question.

The payment rail handles collection and settlement. The Credit Ledger handles continuous service metering.

Airline miles, hotel points, credit-card rewards, and restaurant punch cards have long served similar purposes. AI and API products make the need especially visible. A customer can prepay and have each API call, image generation, or compute job deducted from a balance. A service can also meter usage first and settle an itemized bill later. In both prepaid and postpaid models, a credit-card or stablecoin payment solves the moment when funds enter or settle. The application still needs to record which service was used, by whom, at what rate, and how the parties can resolve a discrepancy.

For a single merchant, a database is often the right answer. Blockchain is not an automatic upgrade to a database. A verifiable ledger becomes useful when multiple stores, partners, authors, providers, or users need to share records and allocation results.

Imagine ten writers offering one subscription. A reader pays once and can read all ten. Revenue might be allocated by readership, or readers might direct part of their allowance to the writers they value. The system needs granular credit and transaction records. The writers do not need to create a stablecoin to do it.

Credit Token provides programmable service credits for these applications. One unit could represent an API call, an image generation, an amount of storage, a subscription right, or an allocation weight defined by the application. The issuer decides how credits are created, consumed, and displayed. ArcBlock Chain provides the token and verifiable-ledger mechanism. The interface should make the issuer, purpose, consumption permissions, expiration, and refund rules explicit. Legal treatment still depends on the specific facts and rights involved; a product name cannot decide it.

Scarce resources create another problem. Demand for GPUs, AI inference, compute instances, and temporary capacity often rises and falls sharply. Idle resources should be used; during peaks, limited supply needs a transparent allocation rule. ArcBlock Chain's Curve Token connects issuance and destruction to a designated reserve token through a declared curve. A fixed rule can resemble a conventional service credit. An application can also map externally measured resource conditions to rule parameters and then apply the curve to the conversion.

Bonding curves are familiar from memecoins and automated trading, but a curve does not belong only to speculation. It can be a tool for resource pricing and allocation. The boundary needs to be explicit: the curve executes the application's declared conversion rule. It does not measure whether a GPU is actually idle, schedule the job, or deliver the compute. Those remain responsibilities of the application.

A software service may also involve module authors, application developers, independent operators, infrastructure providers, and people who bring it to users. We want verifiable ledgers and protocols eventually to execute allocation rules those participants accept in advance. In conventional systems, the party closest to the payment often captures the revenue while other contributors depend on private reports and periodic settlement. This direction can make contribution records easier to reconcile and automate more distribution steps, but ArcBlock Chain does not yet deliver it as a complete revenue-attribution and settlement product. It cannot manufacture fairness either. The participants still have to choose a fair rule.

A Digital Asset can connect rights, contracts, and execution

On ArcBlock Chain, we prefer the term Digital Asset for what is usually called an NFT. It should mean more than an avatar, collectible, or speculative image.

One distinctive foundation of ArcBlock's design is that accounts, fungible tokens, Digital Assets, agent identities, stakes, and other objects use DIDs as a common addressing model. They still have different data structures, permissions, and rules. They do not need to live in unrelated address systems. This common addressing model lets protocols refer explicitly to different objects and their relationships, providing a consistent foundation for later authorization and value distribution.

This points toward interesting recursive structures. A Digital Asset might record a digital copyright interest or license. It might reference other people's materials, modules, or rights and the allocation relationships agreed in advance. In the future, a human-readable collaboration contract could be signed and expressed as a Verifiable Credential, then referenced by the related asset, while protocols handle the explicit rules suitable for automation. ArcBlock does not yet ship this whole combination of contract expression, VC linkage, and revenue settlement as one complete product.

A common DID addressing model lets different objects reference one another. Each relationship still has its own rules and evidence boundary.

I want the contract people can read and the agreement a machine can execute to stop living in completely separate worlds. When a work generates revenue, a system could follow relationships declared and accepted by the participants to perform the automatable distribution steps. When an on-chain asset moves, or an authorization is updated, each record can be retained and verified under its corresponding protocol. Whether a real-world right moves with it, or whether a particular credential can be revoked, still depends on the protocol, implementation, and legal arrangement involved.

We need restraint here too. A DID identifies an object; it does not prove that someone owns a real-world copyright. A VC proves that an issuer made a claim; it does not make the claim inherently true. A Digital Asset can express rights, contracts, and authorization records. It does not replace courts or automatically create a legal right. The technology makes it clearer who said what, which evidence was referenced, and how a declared rule was executed.

Public Chain and your own ledger serve different scopes of clarity

Not every record belongs on a public chain.

ArcBlock Chain's public network is useful when an application needs a public record, shared state, and coordination among independent parties. Anyone can also run a Verifiable Ledger for an organization, a personal application, or a defined group of partners. A self-run ledger does not automatically inherit the consensus of the public network, and writing data to it does not make an external fact true. It provides an attributable, traceable record that participants can review.

When we use cloud or AI services today, we often receive a total bill but struggle to answer questions from our side. Which application, agent, failed retry, or development experiment consumed those tokens or compute resources? An internal verifiable usage ledger can support reconciliation inside the team. If a supplier or partner signs corresponding records, both sides can go further and compare accounts or resolve disputes.

This does not require publishing commercial data. It does not require turning every API call into a public-chain payment. A Public Chain supplies the public record needed for cross-organization coordination. A private or self-run ledger supplies the operational clarity needed by one organization and selected partners. Both can use the same DID, credential, and protocol ideas while serving different trust boundaries.

For me, then, clarifying ABT cannot stop at listing a few use cases on a page. It belongs to a larger design. Stake for X gives a commitment an enforceable cost. Credit Token expresses an application's own service allowance. Curve Token makes a rule for scarce-resource conversion explicit. Digital Assets establish connections among rights, credentials, and multi-party collaboration. The public chain and Verifiable Ledgers make those records reconcilable among the appropriate participants.

I still want the CLARITY Act to give the industry durable legal boundaries. Whether it passes or not does not change the work in front of us today. We should not wait for legislation to explain ABT on our behalf. We should put purpose, control, responsibility, and limits into the product, and then explain them in the clearest language we can.

I want the law to tell builders where the boundaries are, and I expect us to explain the boundaries inside our own products. Only when both happen can innovators move with confidence and users understand what they are entrusting to a system.

Further reading