Accepting Payments Is Not Issuing a Stablecoin

People have started asking me a reasonable question. The GENIUS Act is now U.S. law, and stablecoin rules are clearer than they used to be. Why doesn't ArcBlock issue a stablecoin of its own? If ArcBlock wants to help applications handle payments, wouldn't that be the natural next step?

My answer is direct: accepting payment is not issuing a stablecoin, and payment is not the same as operating a business.

A stablecoin can be an excellent payment and settlement asset. A payment gateway can accept, route, and settle that payment, just as it can handle a card or bank payment. But once a customer pays, the difficult work of a digital service is only beginning. What did the customer buy? How much can they use? How is usage metered? When does a subscription renew? What happens when a payment fails? How is a balance shown? How are refunds, partner allocations, support cases, and reconciliation handled?

That is why ArcBlock is interested in more than payment rails. Borrowing from the telecom industry's BSS/OSS model, we want to help applications build digital, composable, and, where useful, verifiable billing and operations support: products, prices, orders, payments, service credits, usage, subscriptions, invoices, support, and reconciliation. Payment is the entry point, not the business operations system.

This is a product and systems-design argument. It is not a legal classification of stablecoins or Credit Tokens, and it is not legal or investment advice. How a specific product should be treated in a particular jurisdiction still depends on the rights it creates, the movement of funds, and how it actually operates.

Stablecoin issuance, payment acceptance, and business operations are different systems

In the physical economy, a supermarket, hotel, factory, or software company may accept dollars, price in dollars, account in dollars, and settle in dollars. None of them needs to issue its own dollar to do those jobs. Accepting and using a currency is fundamentally different from assuming responsibility for issuing it.

The same is true for digital payments. A business may accept cards or bank payments through Stripe. Subject to the relevant network, legal, and integration conditions, it may also accept on-chain assets. ABT, ETH, and stablecoins such as USDC and USDT are examples from different categories; they do not share the same legal treatment, settlement guarantees, or risks. Choosing a payment asset answers, “What does the customer use to deliver value to the merchant?” Choosing a payment method answers, “How is that value authorized, transferred, confirmed, and settled?” Both questions matter. Neither answers, “How does the merchant continuously deliver and operate the service?”

Consider an AI application. A customer adding $100 only tells us that one payment succeeded. The service still has to decide how many credits that payment creates; how different models, API calls, image generations, GPU time, and storage consume them; whether a failed job should be charged; how a team shares an allowance; when low balances trigger warnings or top-ups; how a customer can understand the monthly bill; and how support can investigate a disputed charge.

At minimum, we should separate three layers:

A stablecoin may sit in the first layer, while a payment gateway mainly connects the second. An application lives every day in the third.

Issuing a stablecoin does not automatically produce the next two layers. Integrating one does not create a complete billing system either. Conversely, a good operating system should not be trapped behind one payment asset. One customer may use a card, another a bank transfer, and another ABT or a compliant stablecoin. The application's products, credits, usage, and reconciliation rules should remain coherent.

The GENIUS Act became U.S. law on July 18, 2025. It defines a payment stablecoin as a digital asset designed for payment or settlement whose issuer is obligated to convert, redeem, or repurchase it for a fixed amount of monetary value and represents that it will maintain a stable value relative to that amount. The statute establishes permitted issuers, eligible reserves of at least one-to-one, disclosures for redemption policies and fees, and monthly reserve reporting and examination. It also directs regulators to develop standards for capital, liquidity, operations, compliance, and information-technology risk management.^[1]

Becoming law did not make the entire regime immediately effective. The statute sets its effective date at 18 months after enactment or 120 days after the primary federal regulators issue final implementing rules, whichever comes first. As of this essay, agencies were still working through proposed rules and implementation details.^[2] I am discussing the direction and responsibility boundaries established by the law, not assuming every implementing rule is final.

One useful form of clarity created by the law is that a company can better see whether it actually needs to become an issuer. An institution that intends to operate a broadly used payment and settlement asset, and is prepared to carry continuous reserve, redemption, liquidity, disclosure, and compliance obligations, may decide stablecoin issuance is its core business. Most applications that simply need to collect from customers do not.

“Stablecoins now have a legal framework” does not imply “every company should issue a stablecoin.” It tells the market that issuing this kind of payment asset is a concrete, serious, continuing business. Clear rules help the businesses that need to do it understand how. Other companies can still choose existing payment assets where applicable law, networks, and payment integrations permit.

ArcBlock is solving what happens after payment

ArcBlock does not need to issue an ArcBlock stablecoin merely to prove that it supports payments. Historically, the standalone Payment Kit treated payment methods and payment currencies as configurable objects. An application could connect Stripe or configure EVM networks such as Ethereum and Base. On a supported network, a compatible standard-token contract could be configured for payment, and payment could be converted into application-defined credits.^[3] The standalone Payment Kit Blocklet has since been superseded rather than maintained as an independent product; those capabilities are evolving within ARC's unified application architecture.

This separation is deliberate. Cards, bank accounts, ABT, ETH, and stablecoins such as USDC and USDT can each serve payment or settlement where the appropriate compliance and technical integration are in place. An application should not have to become their issuer to accept them. ArcBlock does not need to manufacture another stablecoin before it can help applications get paid.

Our larger product question is the continuous record after payment.

A payment may occur once while service consumption occurs ten thousand times. A customer may buy a monthly subscription or prepay a balance. A company may bill after usage or grant trial credits first. One service action may use a model, storage, networking, and a third-party API. Revenue from one product may eventually need to be allocated among developers, operators, and partners.

Throughout that process, the system needs to answer:

Payment methods can change. The application's record of products, service, and usage must remain continuous.

That is an operations-support system, not merely a wallet or checkout button. Historical Payment Kit work has already demonstrated payment and credit top-up. ArcBlock Chain and Verifiable Ledgers provide token, record, and protocol foundations. We want these capabilities to form more of the post-payment operating layer within ARC over time. Payment brings value in. The application ledger connects value to service. When several parties need to reconcile a shared history, verifiable records and explicit protocols can reduce their dependence on one operator's private database as the sole interpretation of what happened. This remains an active product direction, not a claim that one finished system already covers every billing, support, and reconciliation scenario.

We should stay pragmatic here. A simple product with one operator can often handle billing perfectly well in a conventional database. Blockchain is not mandatory for every invoice. A verifiable ledger adds value when records, authority, audit, and reconciliation cross systems, organizations, or participants.

A Credit Token represents service, not another dollar

The value of a Credit Token begins with the fact that it does not need to pretend to be a public currency.

An application credit could represent one thousand API calls, an image generation, an hour of GPU time, a GB-month of storage, a subscription period, a seat at an event, or an allocation unit among partners. The Credit Token protocol handles token creation, balances, and consumption authority. The application defines purpose, expiration, refunds, presentation, and actual service delivery.

One merchant might accept $10 and grant 1,000 credits. Another might display one credit as one dollar of service balance. The interfaces look different, but the underlying object records the merchant's commitment to provide service and how the customer consumes that commitment. Whether the design is a payment stablecoin or another regulated object still depends on the actual rights and operations. The interface unit or the word “credit” cannot decide the classification.

Airline miles, hotel points, credit-card rewards, game credits, and restaurant stamp cards all demonstrate the same principle. They are useful because they make a business relationship explicit: who can earn them, where they work, what they can obtain, when they expire, and how partners recognize them. Their value does not come from each brand issuing a new dollar.

Digital services make credits even more useful. Imagine an AI platform placing model calls, image generation, and storage in one customer-readable service ledger; a creator network selling a shared subscription and allocating value by readership or customer choice; or a group of independent stores recognizing one loyalty credit while preserving the origin of every grant and redemption. These are design scenarios that Credit Tokens and verifiable ledgers could support, not claims of complete products available today.

The clearer the boundary of a credit, the more useful it becomes—and the less it needs to borrow the idea of money.

A Credit Token does not mean every credit must be public, freely transferable, or permanent. Often a service credit should be consumable only by its issuing application, limited in purpose, and clearly governed. If only the designated service may deduct it, that may be exactly the right design. Forcing it into a freely traded token can create confusion and unnecessary risk.

In fact, the inability to transfer freely between users, sell into an open secondary market, or redeem at will is often a defining product property of a Credit Token, membership, or loyalty credit. Airline miles represent benefits an airline provides under specific rules. A membership tier represents a relationship between a customer and a service. API credits represent usage that the issuing application promises to deliver. Their utility comes from that explicit relationship. If they circulate without reference to the issuer, customer, or service, their meaning becomes less precise.

Those constraints also return the product's attention to use. The primary purpose of a utility token should be to let someone obtain, use, or prove a real benefit—not to create a freely traded marketplace first. Non-transferability does not mean an object has no value. It means the value resides mainly in the service and relationship rather than in bids from unrelated buyers and sellers.

Nor can a name alone distinguish a service credit from a prepaid balance. What did the customer provide? What did the issuer promise? Is it refundable or redeemable? How are funds held? Can the credit be transferred? Which laws apply? The answers come from the actual design. A technical object can express and enforce rules; it cannot let a product evade those questions.

ArcBlock's goal is to let applications make these rules programmable, composable, and traceable. The historical Payment Kit credit top-up flow allowed an application to define the top-up product, price, payment currency, and number of credits granted. Payment could use a configured traditional or on-chain method, while the credit continued to meter the service.^[4] That work demonstrated the division of labor between paying with one asset and operating a service with another object. Complete billing, support, cross-organization reconciliation, and multi-party allocation still require application logic and continued ARC development.

Good payment infrastructure should help applications issue fewer currencies

Many blockchain projects began with “we can issue a token” and then searched for a problem the token might solve. I prefer to work backward from the business facts. What does the customer buy? What does the merchant promise to deliver? Which records belong to one operator, and which must several parties reconcile? Where is a public settlement asset needed, and where is an application credit enough?

One of the most persistent mistakes in early blockchain application design was equating “a new business” with “a new coin.” A team building a social application, content platform, game, or digital service could easily assume that using blockchain—and creating utility—required issuing a fungible token of its own. A token that should have expressed precise product rules was instead designed first as a market-facing currency. Before the application had proved its demand, issuance, liquidity, and market price had already become product burdens.

The deeper problem was that many of these tokens had weak practical utility and imprecise limits on transfer and use. People quickly discovered that the easiest thing to do was not to obtain a service with the token, but to trade it. Some made money and others lost it. Because price movement was the most visible side effect, it came to be mistaken for the token's purpose. The project then had to maintain liquidity, explain the price, and respond to trading expectations, while the product utility it should have built moved into the background.

That is not a failure of markets. It is a failure to design the right object. If a benefit belongs to a particular user, service, or time period, the protocol and application should be able to express those boundaries. If it should not be redeemable or sold on a secondary market, blockchain's technical ability to transfer it should not automatically make unrestricted circulation a product feature.

The conventional economy offers a simpler answer. Starbucks has digital payment, stored balances, membership, and rewards. Airlines, hotel groups, card issuers, and retailers run their own miles, points, tiers, offers, credentials, and memberships. They can build sophisticated loyalty systems without issuing a “Starbucks Dollar” or a “Delta Coin.” A company needs customer relationships and service rules of its own. It does not follow that it needs a public currency of its own.

The same is true for blockchain applications. An application can accept existing currencies or on-chain assets, use Credit Tokens to represent service allowances, use Verifiable Credentials for membership tiers, qualifications, offers, or completion records, and use Digital Assets for unique rights and transferable assets. Giving each object a precise job is clearer than asking one tradable fungible token to pose simultaneously as payment, membership, loyalty points, a credential, and governance.

This does not mean an application should never issue a fungible token, or that restricting transfer or redemption automatically determines its legal treatment. Some networks genuinely need a shared native asset for public fees, protocol security, or coordination that no single operator can provide. The test should be whether the asset performs an indispensable protocol function—not whether the team has built a blockchain application and therefore expects to have a coin.

If the answer truly requires a widely used payment asset that maintains a fixed value and is redeemable as promised, a stablecoin is important infrastructure. The GENIUS Act's clearer boundary for that business is progress.

But if the goal is to let customers pay by card or stablecoin and let an application deliver service by request, usage, or subscription, issuing a new currency usually takes the long way around. The application needs the appropriate payment rails, then needs to focus on product, metering, billing, support, and reconciliation.

That is ArcBlock's choice. We have accumulated implementation experience across multiple payment methods, standard tokens, and credit top-up. We are continuing to bring Credit Tokens, ArcBlock Chain, Verifiable Ledgers, and ARC application capabilities together into the operating layer that follows payment. Payment assets can evolve, business rules can remain application-defined, and the record can be reconciled by participants when needed.

The real question should not be, “What other coin could we issue?”

It should be: after the customer pays, can we make the path from every unit of value to delivered service clear, continuous, and reconcilable?

That is much harder than issuing another stablecoin. It is also much closer to the problem most applications actually face every day.

Further reading