Their rules.

By Andrés Peña Mellado

U.S. Bank brought a bank-issued stablecoin onto a public network without giving up control over the asset. Ten days after the announcement, one of those powers became visible in a public sequence.

On September 9, 2026, U.S. Bank announced USBDC, its own dollar-backed stablecoin built on Stellar. This was not a fintech testing another token. U.S. Bank is the fifth-largest commercial bank in the United States, serves 15 million customers, and was testing how to move value between its entities in North America and Europe on a public blockchain.

The choice of Stellar grew out of the bank's earlier work with the Stellar Development Foundation and PwC. For a regulated institution, the network offers an unusual combination: global reach, settlement in seconds, and costs below a cent, alongside native controls over issued tokens. U.S. Bank could test new infrastructure without surrendering the powers it expected to retain.

The pilot assessed issuance, payments, redemption, freezing, and clawback, which we will return to. It also had to validate the connection between the bank's digital asset platform and its internal operations. This was not yet a stablecoin available to customers, and there was no commercial launch date.

Ten days later, another sequence appeared in the account U.S. Bank had published as the issuer. On September 19, at 02:53:03 UTC, that account sent 24,000 tokens to another address. At 03:08:33, fifteen and a half minutes later, it executed a clawback for exactly the same amount.

These are not two versions of one transaction. Stellar did not reverse the first payment. It recorded a second operation, signed later, that burned 24,000 units and removed them from the recipient's balance. The original transfer is still visible, and so is the clawback.

This reveals an important distinction. A blockchain's history being immutable does not mean an asset's economic state cannot change.

A later operation can change a balance without erasing what happened before. Immutability protects the historical sequence; it does not freeze the state of an asset forever. In this case, the payment was recorded first and the issuer's intervention was recorded afterward.

The bank calls the asset USBDC. The operations identify it as USBDCP. The cited sources do not explain that final letter; the difference in names does not change what the payment and clawback show.

The chain can be public and the asset can still have rules

A clawback lets an issuer withdraw a specified amount from another account's balance. Stellar's documentation describes this power as a response to fraud, errors, or regulatory measures. The operation burns the affected units and remains on the record as a new movement.

U.S. Bank's specific configuration can be checked in Horizon. Its issuing account has three distinct flags enabled. AUTH_REQUIRED requires the issuer to approve a trustline, the relationship an account opens to hold an asset. AUTH_REVOCABLE allows the issuer to withdraw that authorization; when it does, the account retains its balance but can no longer transfer it or make new payments. AUTH_CLAWBACK_ENABLED enables the recovery and burning of a specified amount.

These are related powers, not one single way of freezing money. Authorization determines who can receive the asset. Revocation immobilizes a position that remains in the account. Clawback reduces that balance through another operation. On September 9, U.S. Bank announced it was testing these tools. On the 19th, the public record showed the issuer using one of them.

Technical authorization does not demonstrate contractual consent, either. An approved trustline lets us say that account was able to receive USBDCP. It does not reveal what contract its controller signed, what information they received, or what procedure they accepted in the event of a freeze or clawback. This control was not imposed by the use of a public network: U.S. Bank chose to issue the asset with authorization and recovery powers in the issuer's hands.

The blockchain records the act; it does not decide whether it was justified

The intervention may be legitimate. If there was fraud, a mistaken transfer, or a regulatory order, freezing or withdrawing assets can protect someone who lost funds. The problem appears with a false positive: the same instruction can immobilize legitimate money or take a balance from the wrong account.

Stellar executes the operation it receives. The record lets anyone inspect the acting account, asset, amount, time, and full sequence without entering the bank's private database. It does not show who made the decision inside U.S. Bank, what evidence they assessed, or how an affected person could challenge it.

The public materials cited in this investigation do not describe a specific procedure for contesting an erroneous freeze or clawback. That leaves a concrete boundary: the exercise of the power is visible, while its justification and avenues for redress still depend on internal rules.

It is a useful mirror of what happened with Orionx. In that case, movements could be verified on the network, but custody left a decisive part outside users' view. With USBDC, we can observe the issuer's intervention. To judge it, we still need to know the human procedure that produced it.

You can also try what the bank did

These powers are not locked inside U.S. Bank's infrastructure. They are Stellar functions, and its documentation shows how to configure an issuer, authorize an account, revoke its permission, and execute a clawback.

Testnet is a free environment without real money, so a builder can reproduce the sequence with test accounts and assets before thinking about a product.

When creating an asset, one must decide who can receive it, what action freezes a position, who can withdraw units, and what evidence should exist before doing so. Then one can inspect the record and check which parts of those rules are exposed and which still live outside the network.

Raven shortens the path to getting started. It connects agents such as Claude Code or Codex to Stellar documentation and live ecosystem data, making it possible to ask about these operations, find the sources, and work from them within the same agent. It does not replace the decision about the rules; it helps us reach the point where that decision must be made sooner.