On August 17, 2026, the U.S. Department of the Treasury moved the GENIUS Act from legislation toward implementation.
Its new Notice of Proposed Rulemaking focuses on Section 3 of the Act: who may issue a payment stablecoin in the United States, and when a payment stablecoin is considered to be offered or sold to a person in the United States. Treasury is seeking public comment before finalizing those definitions.
The timing matters. Treasury identifies January 18, 2027 as the expected effective date of the Act. From that point, a person generally may not issue a payment stablecoin in the United States without an appropriate federal or state license. The proposal also addresses access to foreign-issued payment stablecoins and the circumstances under which digital asset service providers may make them available in the U.S. market.
This is an important step toward regulatory clarity. But it also exposes a practical question that licensing rules alone cannot answer:
How will compliance travel with a stablecoin as it moves across issuers, exchanges, wallets, payment applications, DeFi protocols, and eventually AI agents?
Stablecoin regulation is becoming a distribution problem
Stablecoin policy is often discussed at the issuer level: reserves, redemption, disclosures, licensing, supervision, and the ability to comply with lawful orders. Those controls are essential because they determine whether the asset itself can function as reliable digital money.
Yet stablecoins do not remain inside an issuer's application. Their value comes from portability. They can move between wallets, cross application boundaries, settle transactions on public blockchains, and become embedded in products the issuer does not directly operate.
That creates a second compliance layer.
An exchange may need to establish whether a user is eligible to access a service. A payment company may need to know whether a business is operating in a permitted jurisdiction. A regulated protocol may need evidence that a wallet has passed a required check. An AI agent may need to prove that it is acting for an authorized principal and within an approved spending limit.
These are not all the same question. They should not require every participant to collect the same identity file.
If each application responds by rebuilding a full onboarding process, the result will be a network of duplicated passports, corporate documents, addresses, and screening records. Compliance may become more visible, but the system also creates more repositories of sensitive data, more inconsistent decisions, and more attractive targets for attackers.
The stablecoin may move in seconds. The compliance evidence remains trapped in separate databases.
The obvious approaches do not scale well
There are three common ways to manage identity across a regulated digital-asset ecosystem, and each has limitations.
The first is repeated verification. Every wallet, exchange, and application conducts its own KYC or KYB process. This gives each service control over its decision, but it also increases user friction and multiplies raw-data custody.
The second is platform dependence. Downstream applications assume that checks performed by an issuer or centralized intermediary are sufficient for every use case. That is simpler, but it can create blind spots when policies, jurisdictions, risk thresholds, or transaction contexts differ.
The third is a universal allowlist. A wallet is either permitted or denied. This can work in a narrow environment, but a single binary status cannot express the different facts required across payments, trading, lending, remittances, or institutional settlement. It can also expose more about a user's status than a particular transaction requires.
Stablecoin infrastructure needs a more precise model: one in which verified facts can be reused, policies can remain application-specific, and sensitive source documents do not have to be copied into every system.
Separate identity verification from identity-data distribution
A reusable credential model begins with a simple distinction.
An authorized party may still need to perform identity verification, sanctions screening, business verification, or another required check. Privacy-preserving infrastructure does not eliminate that responsibility. What it can change is what happens afterward.
Instead of distributing the underlying identity record, the verifying party can issue a cryptographically verifiable credential. A user or business can then present proof of a specific claim to another service. The service verifies the proof and applies its own policy without automatically receiving the full source file.
Depending on the legal and operational context, the claim might establish that:
- a required verification was completed by an accepted issuer;
- the credential is valid, current, and not revoked;
- a user or business satisfies a defined jurisdictional or eligibility condition; or
- an agent has authority to perform a specific action within a limited scope.
The important shift is from asking, “Can we obtain the entire identity record?” to asking, “What is the minimum reliable fact needed for this decision?”
Zero-knowledge proofs can support this model by allowing a narrow claim to be verified without revealing every attribute behind it. Selective disclosure can reduce unnecessary data sharing. Expiration and revocation mechanisms can prevent a credential from becoming a permanent compliance pass.
This does not make every credential portable everywhere. A relying party must still decide which issuers, checks, assurance levels, and revocation processes it accepts. Interoperability is a governance problem as much as a cryptography problem.
AI agents make the authorization gap harder to ignore
Stablecoins are also becoming a natural payment rail for software agents. An agent can discover a service, negotiate a transaction, and initiate payment without waiting for a human to complete each step.
But possession of a private key proves only that an agent can sign. It does not prove why the agent is allowed to act.
A compliant agentic-payment system may need to establish the principal behind the agent, the permissions delegated to it, the maximum amount it may spend, the assets or merchants it may use, the jurisdictional limits that apply, and whether that authority remains valid at the moment of payment.
Putting the principal's full identity into every agent interaction would create an enormous privacy and security problem. Ignoring the principal would create an accountability problem.
Verifiable credentials offer a middle path. An agent could present proof of authority and scope for a particular transaction without exposing unrelated information about the person or institution it represents. The proof becomes transaction-relevant, while the underlying identity remains protected.
This is where stablecoin compliance, digital identity, and agent governance begin to converge.
Zero knowledge is not a complete compliance strategy
It is important not to overstate the role of privacy technology.
Zero-knowledge proofs cannot determine whether the original identity data was authentic. They do not replace sanctions screening, transaction monitoring, risk governance, record-retention decisions, licensing, supervisory obligations, or responses to lawful orders. A proof faithfully demonstrates only what its underlying verification and credential design support.
Poor inputs still produce poor assurance. Weak issuers still create weak credentials. An expired screening result should not be treated as current simply because it can be proven cryptographically.
The value of zero knowledge is narrower and more practical: once a legitimate check has been performed, it can help reduce how much sensitive information must be disclosed and duplicated to support later decisions.
That makes privacy-preserving identity an architectural component of compliance, not a substitute for compliance.
What builders should prepare for now
The Treasury proposal is focused on the legal perimeter around issuance, offering, and sale. Builders should read the final rule carefully rather than assume that a single technical pattern will satisfy every obligation.
At the same time, teams building stablecoin products can prepare for a market in which compliance evidence must move more efficiently than it does today.
That means designing for:
- policy-specific disclosure, so each service receives only the facts it needs;
- credential freshness and revocation, so eligibility can change without rebuilding identity records;
- issuer and assurance transparency, so relying parties know who performed a check and to what standard;
- cross-application verification, so evidence is reusable without making every application a custodian of raw identity data;
- agent authorization, so machine-initiated payments carry proof of mandate and limits; and
- auditability, so regulated participants can explain how a decision was made.
At zkMe, we view identity and credential infrastructure as a way to make trust programmable while limiting unnecessary exposure of personal and business data. The objective is not anonymous compliance. It is precise compliance: proving the fact a decision requires without spreading every fact a verifier could collect.
The next phase of stablecoins needs portable trust
The GENIUS Act gives the U.S. stablecoin market a clearer legal structure. Treasury's proposed rule begins the difficult work of translating that structure into operational boundaries.
The next challenge is ensuring that compliance can function across the open, programmable environment that makes stablecoins useful in the first place.
If identity remains locked in centralized onboarding databases, stablecoin payments may become faster while trust decisions remain fragmented, repetitive, and data-intensive. If verification becomes reusable and selectively disclosed, compliance can travel with users, businesses, wallets, and agents without turning every service into another store of sensitive documents.
Stablecoins are moving from regulatory debate to implementation. Their identity layer should do the same.