What happens when a financial instrument is created on distributed infrastructure rather than simply transmitted across it? Our response focuses on the operating environment underlying payment stablecoins. A token instantiated on a distributed ledger inherits characteristics of that system—including its rules, governance, capacity, dependencies, attack surfaces and failure behavior. As stablecoins move into production use, we believe understanding those characteristics becomes part of understanding the instrument's overall risk profile.

If a bright-line market protection is removed, what replaces it as markets become more technologically diverse? Our response examines the downstream implications of rescinding the trade-through rule for execution quality, routing, market data, reference prices and increasingly tokenized securities markets. Modernization should accommodate new market structures while keeping economically equivalent securities activity measurable, auditable and subject to appropriate standards regardless of the technology through which it occurs.

Reserve reporting can show whether the assets backing a stablecoin are there. It does not necessarily show how the infrastructure processing the stablecoin actually performs. Our response proposes recurring infrastructure-level measurements covering transaction completion and failure, sustained capacity, stress behavior, finality, congestion, recovery, dependencies and relevant ordering effects. The objective is not to make different technologies perform identically, but to make material operational differences observable before the infrastructure becomes critical.

When does someone actually become a customer of a stablecoin issuer? A stablecoin may be issued to a verified customer and subsequently circulate through wallets, exchanges, businesses and individuals. Our response addresses where the issuer-customer relationship should begin and end, while also examining digital identity, privacy, institutional reliance and the distinction between identifying a customer and determining who or what is authorized to act for that customer.

The important question is no longer simply whether a technology can process a payment, but whether the complete payment journey can reliably produce the required outcome. Our response focuses on end-to-end payment outcomes, interoperability, operational assurance, capacity, recovery and material dependencies—including what can actually be known when interconnected systems disagree, degrade or fail. A central theme is that technology neutrality should preserve architectural choice without assuming operational equivalence.

What should be demonstrated about the infrastructure supporting a stablecoin before that infrastructure becomes a material dependency of the financial system? Our response looks beyond backing and redemption to the complete arrangement through which a stablecoin is held, transferred, settled and redeemed—including capacity under stress, state and finality, unresolved outcomes, recovery, reconciliation and material dependencies. Different architectures can satisfy the same prudential objectives in different ways, but technology neutrality should not mean assuming they are operationally equivalent.

If two execution paths can reach the same or an economically equivalent security, what characteristics of those paths must remain visible for a broker to demonstrate best execution? Our response examines how completion, timing, ordering, rerouting, stress behavior and the authority of transaction state can affect customer outcomes as securities become accessible through increasingly different execution architectures. Common APIs and orchestration layers can simplify access, but should not obscure material differences in the underlying execution path.

What changes when an arrangement moves from relatively limited use toward something the financial system may increasingly rely on? Our response focuses on the transition itself. As reliance increases, we believe the evidence supporting that reliance should mature with it—from pilot operation to meaningful scale, degraded dependencies, unresolved transactions, recovery and the ability to determine what succeeded, what failed and what can safely happen next. The level of confidence placed in financial infrastructure should remain connected to what has actually been demonstrated.