Comment of the BSV USA Association (in formation) on GENIUS Act Regulations on Payment Stablecoin Issuance, Offer, and Sale

Docket verified 2026-10-12. Department of the Treasury, notice of proposed rulemaking, "GENIUS Act Regulations on Payment Stablecoin Issuance, Offer, and Sale." Docket TREAS-DO-2026-0496, RIN 1505-AC95, 91 FR 53368 (Aug. 18, 2026), proposed 12 CFR Part 1523. Comments must be received on or before Monday, October 19, 2026. No extension notice appears on the docket as of 2026-10-12, although banking trade groups have asked for one.

• Federal Register: https://www.federalregister.gov/documents/2026/08/18/2026-16796/genius-act-regulations-on-payment-stablecoin-issuance-offer-and-sale
• Regulations.gov docket: https://www.regulations.gov/docket/TREAS-DO-2026-0496
• Comment form: https://www.regulations.gov/commenton/TREAS-DO-2026-0496-0003

Scope note: this rule implements section 3 of the Act only (who may issue, offer, or sell a payment stablecoin in the United States). It does not set prudential, reserve, or chain requirements. Our answers below stay inside the questions Treasury asked. The positions on technical criteria fit best where Treasury asks about issuance timing, chain migration, bridges, and the "technological capability" representation.

[Begin comment text]

To: U.S. Department of the Treasury, Office of General Counsel Re: GENIUS Act Regulations on Payment Stablecoin Issuance, Offer, and Sale (Docket TREAS-DO-2026-0496, RIN 1505-AC95) From: BSV USA Association (in formation) Date: October [__], 2026

1Who we are

The BSV USA Association is a group, now in formation, of US businesses, developers, and users who build on the BSV blockchain. BSV is a public proof-of-work blockchain. It records value in unspent transaction outputs (UTXOs), allows large blocks, and has low transaction fees. BSV has no exchange listing in the United States today.

Our members are mostly small. They write wallets, payment tools, and applications. Some may one day issue, distribute, or support payment stablecoins, or build software that others use to do so. We comment because the definitions in Part 1523 will decide whether that work is possible on any public blockchain, or only on a few.

2Summary

1. Write the rule in neutral, functional terms. Define issuance, transfer, and control by what happens, not by the design of a particular blockchain or token standard.
2. Do not tie lawful issuance or offer to a short list of chains or venues. The Act does not do this. The rule should not do it by implication.
3. Where a technical fact matters, use objective criteria any chain can meet and document. Examples: when a transfer is final, how reorganizations are handled, how supply can be monitored, and what proof of a transaction is accepted.
4. Protect consumers through transparency. Published, testable documentation serves holders better than gatekeeping by venue.
5. Keep the rule workable for small issuers and software developers.

3Answers to Treasury's questions

Questions 8 and 10 (when issuance occurs; "first transfer"). We support tying issuance to the first transfer out of the issuer's control. Treasury should make clear what "transfer" means on a blockchain where finality is probabilistic. We suggest a simple rule: a transfer occurs when the transaction is recorded on the ledger and meets the issuer's published finality policy, such as a stated number of confirmations. The issuer should document that policy and how it handles a chain reorganization that reverses a recorded transfer. This standard works on any chain. It does not favor one consensus design over another.

Question 9 (minted tokens held in the issuer's treasury). A token that is minted but stays under the issuer's sole control should not count as issued. Treasury should define "control" by function: who can authorize the next transfer. That definition covers smart contract accounts, multi-signature arrangements, and UTXO locking scripts alike.

Question 12 (transfers "indirectly" by an issuer). If Treasury clarifies that automatic transfers count, it should say "smart contracts or other automated mechanisms," as its question already does. Many chains, including UTXO chains, do not use account-based smart contracts. The rule should not use one chain's vocabulary as its test.

Questions 16, 19, and 21 (chain migration, bridges, wrapped tokens). A move from one chain to another should not be a new issuance if three things are true: the token on the first chain is burned or locked; the issuer controls both sides, or has contracted for them; and total supply across all chains does not increase. The issuer can show this with public evidence. For example, it can publish the burn and mint transactions, a reconciliation of supply across chains, and a cryptographic proof that each transaction is in a block. Simplified Payment Verification (SPV) proofs, which show a transaction is included in a block without the full chain, are one such standard. Treasury should accept any proof method the issuer documents and an examiner can check. It should not name specific bridge designs as acceptable.

Question 52 (due diligence on "technological capability" to comply with lawful orders). This is the question where chain choice matters most. Freeze, seize, and burn capability can be built in different ways on different chains. On account-based chains it often lives in a smart contract. On UTXO chains it can live in the token's locking scripts or in the issuer's token protocol. Treasury should ask for a capability that is documented and testable. It should not ask for a particular code pattern. A digital asset service provider should be able to rely on (a) the issuer's written description of how each lawful order function works on each chain where the token exists, (b) evidence that the function has been tested or used, and (c) the provider's own review of that material. This approach treats every chain the same. It also gives consumers something they can read.

Questions 7 and 77 (who is a digital asset service provider; self-custody exemption). We ask Treasury to confirm that a person who only writes, publishes, or maintains software, including wallet software, is not a digital asset service provider for that reason alone. The exemption for software and hardware wallets in section 3(h)(1) should be read to protect the people who build those wallets, not only the people who use them.

Question 73 (de minimis safe harbors). [Reviewers to decide: support, oppose, or take no position. If we support one, a narrow safe harbor for technical pilots and testing, limited by dollar volume, would help small developers show that a payment stablecoin works on a given chain before a full launch.]

Regulatory Flexibility Act and Questions 83 and 85 (costs, alternatives, small entities). Treasury's preliminary view is that the rule will not have a significant effect on a substantial number of small entities. Small developers bear real costs when a rule's terms fit some chains and not others. A neutral, functional rule lowers those costs. A rule that, in practice, lets service providers treat only a few chains as safe would raise them and reduce competition. We ask Treasury to consider this effect in its final analysis.

4Closing

Thank you for the chance to comment. We would be glad to give Treasury staff technical documentation on how payment stablecoin issuance, transfer finality, reorganization handling, supply monitoring, and SPV proofs work on the BSV blockchain. We would also be glad to meet with staff.

Respectfully submitted,

John Calhoun Director, BSV USA Association (in formation) [Mailing address] [Email address] [Telephone]

[End comment text]

5Filing checklist

• [ ] Where: regulations.gov, Docket TREAS-DO-2026-0496, comment form https://www.regulations.gov/commenton/TREAS-DO-2026-0496-0003. Treasury prefers electronic filing. Backup by mail: U.S. Department of the Treasury, Attention: Office of General Counsel, 1500 Pennsylvania Avenue NW, Washington, DC 20220. Mail must be received by the deadline, so do not rely on it.
• [ ] How: caption the comment "GENIUS Act Regulations on Payment Stablecoin Issuance, Offer, and Sale." Paste a short cover note in the form box and attach the letter as a PDF. Include name, organization, address, email, and telephone. Everything filed becomes public, so include nothing confidential. Save the tracking number that regulations.gov shows after you submit.
• [ ] By when: received on or before Monday, October 19, 2026. Regulations.gov comment periods usually close at 11:59 p.m. Eastern; confirm the time on the docket page. Internal target: reviewer notes back by Thursday, October 15; final text by Friday, October 16; file by Saturday, October 17.
• [ ] Recheck the docket on October 16 for an extension notice.
• [ ] Cost: none. Filing is free.
• [ ] After filing: record the tracking number and posted comment link in todo.json item t06.