USDA+ Integration

Live on Ethereum Sepolia (testnet). Mainnet is not defined yet.

Only on-chain mint / burn / transfer on Ethereum Sepolia is implemented today. Everything in the "Proposed" column below is a design proposal — it is not built and may change.

An optional transaction-builder REST API (returns unsigned mint/burn/transfer payloads, Bearer-token auth) is documented under the API Reference tab, but its backend is not production-ready. The supported path is direct contract calls.

Live on Ethereum Sepolia (testnet). Mainnet is not defined yet.

Proposed — not yet built. The integration platform below is a design proposal. Today, the only implemented functionality is on-chain mint / burn / transfer on Sepolia.

Live on Ethereum Sepolia (testnet). Mainnet is not defined yet.

Interact with the authority proxy address for roles and allowances, and the token address for mint and burn. The authority is an upgradeable proxy — always use the proxy address above, never an implementation address.

Transfers to the token contract itself are blocked. Sending USDA+ to 0xE3C5b3f2d3191d4393Edf2e05D1B31FdC712D69c will revert. To redeem, use burn (approve-first), not a transfer.

Contracts need fixing to be compliant. GENIUS § 4(a)(6)(B) requires lawful-order freeze / seize — a freezer role (freeze / unfreeze / isFrozen enforced in the token's transfer hook, seizure via burn). It is designed but not on the deployed build: the live contracts are the unfreezeable version and must be updated and redeployed.

Source: the Solidity for these contracts lives in the contracts repo on the new-deployment branch (deployed commit dbddd96) — not yet merged to main, which still holds a template. DEPLOYMENT.md on that branch maps this source to the addresses above.

What is live vs proposed. On-chain mint / burn / transfer on the Sepolia testnet is live today — the technical onboarding in stages 4 and 5 reflects the validated flow. The events / webhooks platform, per-bank-employee SSO, and any in-portal automation of this onboarding are proposed, not yet shipped.

Mainnet / production go-live is gated on the GENIUS items: a deployed lawful-order freeze / seize capability (the live contracts still need fixing for § 4(a)(6)(B)) and proof-of-reserves. No partner bank reaches stage 6 until those are closed.

Status: On-chain mint / burn / transfer on Sepolia is live. The events/webhooks platform, per-bank-employee SSO, and in-portal onboarding automation are proposed. Mainnet / production go-live is gated on closing the GENIUS gaps: deployed lawful-order freeze/seize (the live contracts need fixing for § 4(a)(6)(B)) and proof-of-reserves.

Compliance runs bank-side. A+ does not centralise compliance. Each partner bank operates its own AML/BSA program, sanctions screening, transaction monitoring, and lawful-order handling. A+ provides the on-chain minting and redemption rails and the controls described in the technical onboarding; your institution remains the regulated party responsible for the program described below.

Compliance & regulatory

Complete the table below; attach supporting policies, attestations, and your most recent independent reviews where indicated.

#	Question	What we are looking for
1	Are you (or do you intend to become) a permitted-payment-stablecoin issuer under the GENIUS Act, and which path are you pursuing (e.g. insured-depository-institution subsidiary, OCC-approved federal qualified nonbank issuer, or state-qualified issuer)?	A clear issuer classification and the specific statutory path, with current status and expected timeline to authorisation.
2	Which regulator(s) supervise your stablecoin activity, and what licenses, charters, or money-transmission registrations do you hold?	Named primary federal and/or state regulator(s) plus a list of active licenses with jurisdictions, license numbers, and renewal dates.
3	Describe your AML/BSA program and identify your designated BSA/AML compliance officer.	A board-approved, risk-based program covering the four/five pillars, plus the named officer, their reporting line, and evidence of independent oversight.
4	What KYC/CDD controls do you apply at customer onboarding, including beneficial-ownership and enhanced due diligence for higher-risk customers?	Documented identity-verification, CDD, and EDD procedures, including beneficial-ownership collection thresholds and customer risk-rating methodology.
5	What sanctions screening tooling and process do you use (e.g. TRM Labs, Chainalysis, or equivalent), and how do you screen both customers and on-chain counterparties/wallet addresses?	Named blockchain-analytics and list-screening vendors, screening frequency, list coverage (OFAC SDN and others), and how alerts are triaged and escalated.
6	How do you perform transaction monitoring across fiat and on-chain activity, and how are SARs/STRs filed?	Description of monitoring rules/typologies, on-chain tracing capability, alert-to-case workflow, and SAR/STR governance and filing record.
7	How do you handle lawful orders, including freeze and seize requests, and who operates that capability?	A documented process for receiving and validating lawful orders and a named team that executes freeze/seize, consistent with GENIUS § 4(a)(6)(B). On-chain enforcement integrates with A+ controls and is operated bank-side.
8	Do you have travel-rule capability for covered transfers, and which solution or protocol do you use?	Confirmation of travel-rule coverage, the threshold applied, the messaging solution/protocol in use, and how originator/beneficiary data is exchanged and stored.
9	Which jurisdictions do you serve, and which jurisdictions are prohibited or restricted?	An explicit list of served jurisdictions and a prohibited/restricted list, with the geofencing and customer-screening controls that enforce it.
10	What is your audit history for the AML/BSA and sanctions programs (internal audit, independent testing, and any regulatory examinations)?	Dates and scope of the last independent test and any regulatory exams, summary of findings, and remediation status for open items.
11	How do you manage compliance for third parties and outsourced service providers in scope for stablecoin activity?	A vendor/third-party risk-management process covering due diligence, ongoing monitoring, and contractual compliance obligations for in-scope providers.
12	What ongoing compliance reporting and record-keeping do you maintain, including the recordkeeping period and management/board reporting cadence?	Defined record-retention periods, the metrics reported to senior management and the board, and the cadence of that reporting.

Reserve & treasury management

Step 7 of A+ onboarding: reserve composition, custody, segregation, attestation, and how reserve sufficiency bounds your mint allowance.

#	Question	What we are looking for
1	What is the composition of your reserve assets backing minted tokens?	Reserves held only in GENIUS-eligible high-quality liquid assets (HQLA): cash, short-dated US Treasury bills, overnight repos collateralized by US Treasuries, and government money market funds. A breakdown by instrument and maturity, with no commingled commercial paper, corporate debt, or non-permitted assets.
2	Who custodies the reserve assets, and under what arrangement?	Named custodian(s) (qualified custodian / regulated trust bank), account structure, and jurisdiction. Confirmation that reserves are held in trust or fiduciary accounts identified as backing the tokens, not on the issuer's general balance sheet.
3	How are reserves segregated, and are they bankruptcy-remote from the operating entity?	Reserves legally segregated from corporate/operating funds and structured to be bankruptcy-remote, so holders retain a claim on the reserve pool ahead of general creditors in an insolvency. Supporting legal opinion or trust documentation.
4	Can you attest that reserve assets are not rehypothecated, lent, pledged, or reused?	A signed no-rehypothecation attestation: reserve assets are not lent, pledged as collateral, used in repo as the borrower, or otherwise reused, except as expressly permitted under GENIUS for the listed HQLA categories.
5	How frequently do you reconcile 1:1 backing between tokens in circulation and reserve assets?	A defined reconciliation cadence (at minimum daily) comparing on-chain circulating supply to reserve market value, with a documented exception and remediation process when backing falls below 1:1.
6	Who performs the monthly reserve attestation, and what is its scope?	Monthly attestation by an independent registered public accounting firm covering reserve composition, market value, and 1:1 backing. Confirmation the report is published and the engagement letter / scope is available for review.
7	Describe your redemption operations and committed timing.	The redemption process, eligible redeemers, cut-off times, and committed settlement window (e.g., same-day or T+1). On the testnet this maps to the bank calling token.burn(src, amt) after token.approve; redemption must draw from segregated reserves, not operating liquidity.
8	If you are a non-US institution, what is your treasury capability for holding US Treasury bills?	For non-US institutions: the account, custody, and settlement path used to hold US Treasury bills directly or via a US custodian/correspondent, including FX and operational controls. Demonstrated ability to source, hold, and roll T-bills as GENIUS-eligible reserves.
9	How does reserve sufficiency bound your minting allowance?	Confirmation that minting is capped by verified reserves: A+ grants a bounded, non-refilling mint allowance on APlusAuthority sized to deposited/attested reserves, and the bank mints with token.mint(dst, amt) only up to that allowance. Reserves must be in place before the corresponding tokens are minted.
10	What controls govern changes to reserve composition and the mint allowance over time?	Governance for reserve changes (approvals, limits, monitoring) and the process for requesting an allowance increase, including the proof-of-reserves evidence A+ requires before raising it. Note: production go-live is gated on closing the GENIUS gaps — deployed lawful-order freeze/seize and proof-of-reserves.

Status: On-chain mint / burn / transfer on Sepolia is live using placeholder whitelisted addresses (e.g. 0xYourWhitelistedAddress). Proof-of-reserves automation and mainnet / production go-live are proposed and gated on closing the GENIUS gaps.

Technical due diligence

This section captures the technical readiness checks for integrating with USDAPlus. On-chain mint / burn / transfer on the Sepolia testnet are live today; the events/webhooks delivery platform is proposed. Mainnet / production go-live is gated on closing the GENIUS gaps (deployed lawful-order freeze/seize and proof-of-reserves).

Technical readiness

One row per check — fill in the detail column with your environment specifics or a placeholder where not yet finalized.

#	Check	Detail
1	Custody / wallet provider and signing setup	Name your custody or wallet provider (e.g. HSM, MPC, hardware wallet) and how transactions are authorized internally. Confirm who holds signing authority.
2	Whitelisted address(es) the bank will use	Provide the wallet address(es) for A+ to whitelist for MINT_ROLE + BURN_ROLE on APlusAuthority. Placeholder: 0xYourWhitelistedAddress.
3	Constructing and signing mint transactions	Describe how you build and sign token.mint(dst, amt) up to your bounded, non-refilling allowance. Live on Sepolia.
4	Constructing and signing burn (redeem) transactions	Describe how you call token.approve(...) then token.burn(src, amt) to redeem. Live on Sepolia.
5	Broadcasting transactions	Confirm how signed transactions are broadcast (self-hosted node, provider relay) and how you confirm inclusion and handle re-broadcast / nonce management.
6	RPC / node access for Sepolia	Identify your Sepolia RPC endpoint or node provider, expected throughput, and fallback endpoint for resilience.
7	Webhook receiver endpoint (HTTPS)	Provide a publicly reachable HTTPS endpoint to receive event callbacks. Proposed platform — endpoint should be ready for testnet validation.
8	Signature verification (HMAC-SHA256)	Confirm you can verify the X-USDAPlus-Signature HMAC-SHA256 header using a constant-time comparison against the raw request body.
9	Idempotency handling on event id	Confirm you de-duplicate on the event id so redelivered events are processed at most once (idempotent persistence keyed on event id).
10	Monitoring / alerting for delivery failures	Describe how you detect and alert on webhook delivery failures, retries, and processing errors (dashboards, on-call paging).
11	Environments (testnet now, mainnet later)	Confirm separation of testnet and future mainnet configuration (keys, endpoints, secrets) and your promotion path. Mainnet is gated on the GENIUS gaps.
12	Key rotation	Describe your rotation policy and procedure for signing keys and the webhook signing secret, including rollover without downtime.
13	Named technical contact + escalation	Provide a named technical contact (engineering owner) and an escalation path / out-of-hours contact for integration incidents.

Readable events and webhooks draft

The A+ integration platform at integration.usdaplus.com is proposed. It would turn on-chain activity into readable events and relay them to each member bank as signed webhooks, so your systems never have to poll the chain directly. The smart contracts on Sepolia remain the source of truth; events are a convenience layer that would mirror them.

Event envelope

Every event would share one envelope. The full contract is the JSON Schema.

Field	Type	Description
id	string	Unique event id, and the idempotency key. Treat repeated ids as the same event.
type	string	One of mint, redeem, por_update, feed_reading.
org_id	string | null	Issuer org the event belongs to. null = broadcast to all subscribers (e.g. a network-wide figure).
chain_tx	string | null	Source transaction hash, when the event derives from a transaction.
block_number	integer | null	Block the source transaction was included in.
status	string	pending until the source block reaches finality, then finalized. Act on finalized.
payload	object	Type-specific body (see below).
created_at	integer	Unix milliseconds the platform recorded the event.

Event types

Payload types

Each type selects a payload shape. The mint and redeem payloads mirror live on-chain activity; por_update and feed_reading are proposed and have no data source today.

Type	Status	Required fields	Notes
mint	Mirrors live mint	issuer_org_id, minter, to, amount	Optional allowance_remaining (decrementing, non-refilling mint allowance after this mint).
redeem	Mirrors live burn	issuer_org_id, burner, from, amount	from is the holder whose tokens were burned; the source must have approved the burner.
por_update	Proposed	total_supply, total_reserves, reserve_ratio, as_of	Optional issuer_org_id (null = network-wide) and attestation. reserve_ratio = reserves / supply; >= 1.0 is fully reserved.
feed_reading	Proposed	feed, value, as_of	Optional unit (ratio, bps, percent, USD) and source. A generic oracle/feed reading between snapshots.

Money fields (amount, total_supply, etc.) use an object of amount (decimal string in major units; USDA+ has 6 dp), currency (USD or USDA+), and optional base_units. Amounts are strings, not numbers, to avoid float rounding.

Lifecycle

An indexer would write each event as pending when it first observes the transaction, then a finality sweep would flip it to finalized once the block reaches the required confirmations.

1. Observed. Indexer records the event as status: pending.
2. Finalized. Finality sweep updates the event to status: finalized and delivers the webhook.

Webhook delivery

Delivery would be an HTTPS POST to your registered per-bank subscription URL. Each request would carry the header X-USDAPlus-Signature, a lowercase-hex HMAC-SHA256 over the raw request body, keyed with your per-bank secret. Verify it in constant time before trusting the payload.

X-USDAPlus-Signature: <lowercase-hex HMAC-SHA256(rawBody, perBankSecret)>

import { createHmac, timingSafeEqual } from "node:crypto";

// rawBody MUST be the exact bytes received, not a re-serialized object.
export function verify(rawBody: Buffer, header: string, secret: string): boolean {
  const expected = createHmac("sha256", secret).update(rawBody).digest("hex");
  const a = Buffer.from(expected, "utf8");
  const b = Buffer.from(header, "utf8");
  return a.length === b.length && timingSafeEqual(a, b);
}

Proposed endpoints

Method	Path	Purpose
GET	/api/v1/events	List events (with /api/v1/events/:id for one).
GET POST	/api/v1/subscriptions	List or register your subscription URL.
POST	/api/v1/deliveries/:id/replay	Re-send a delivery (use the id for idempotency).
POST	/api/v1/hooks/chain	Internal indexer ingest hook.

Example event

A mint, finalized. Addresses below are placeholders.

{
  "schema_version": "0.1.0-proposed",
  "id": "evt_01J9Z3K8Q1ABCDEF2GHJK",
  "type": "mint",
  "status": "finalized",
  "org_id": "org_example_bank",
  "network": "eth-sepolia",
  "chain_id": 11155111,
  "chain_tx": "0x1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef",
  "block_number": 6543210,
  "confirmations": 12,
  "occurred_at": 1781990400000,
  "created_at": 1781990460000,
  "payload": {
    "issuer_org_id": "org_example_bank",
    "minter": "0xYourWhitelistedAddress",
    "to": "0xYourWhitelistedAddress",
    "amount": { "amount": "100.000000", "currency": "USDA+", "base_units": "100000000" },
    "allowance_remaining": { "amount": "900.000000", "currency": "USDA+", "base_units": "900000000" }
  }
}

A+ is embedded infrastructure: each bank operates its own keys and its own compliance stack. This event layer is proposed to be read-only and would never co-sign or gate your mints. See the full JSON Schema for every field and payload shape.

Interoperable multi-bank testnet proposed

This page describes a proposed interoperable multi-bank testnet: a shared exercise on Ethereum Sepolia (chainId 11155111) where several issuing banks would each operate against the same USDA+ deployment to demonstrate interoperability and proof-of-reserves logic end to end. Nothing here is built yet.

What it would demonstrate

The testnet would run against the existing Sepolia contracts — no new deployment. Each participant would be whitelisted independently:

• Its own custody address (0xYourWhitelistedAddress), holding its own mint key.
• Its own bounded, non-refilling (decrementing) mint allowance set via APlusAuthority.
• MINT_ROLE and BURN_ROLE granted exactly as in the onboarding flow that works today.

Because A+ never co-signs mints, each issuing bank would mint and redeem against its own reserves and allowance, while the shared token contract remains the single source of truth.

Proposed interoperability flows

With several issuers active, the exercise is proposed to show:

Shared event feed and dashboard

A shared, read-only feed is proposed so every participant could observe network activity — not just its own. It would build on the proposed events model: events of type mint, redeem, por_update, and feed_reading, each carrying chain_tx, block_number, and a status of pending until finalized.

{
  "type": "mint",
  "org_id": null,
  "chain_tx": "0x…",
  "block_number": 1234567,
  "status": "pending",
  "payload": { "dst": "0xYourWhitelistedAddress", "amount": "1000000000" }
}

A broadcast event (org_id: null) would be visible to all participants on the shared dashboard, while bank-scoped events would be filtered per subscriber.

Proposed user-flow simulation

To let a bank verify behaviour end to end without writing client code, the testnet is proposed to include clickable interfaces — simple simulated issue / redeem / transfer flows. Each action would trigger the corresponding on-chain transaction and surface the resulting system logs so engineers can confirm what happened.

1. Trigger an action. A participant clicks "issue", "redeem", or "transfer" in the simulation UI.
2. On-chain settlement. The action would submit the matching mint, burn, or transfer transaction from the whitelisted wallet on Sepolia.
3. Verify via logs and feed. The emitted event would appear in the shared feed (pending → finalized), letting the bank verify allowance decrements, balances, and cross-bank effects.

Demonstrating proof-of-reserves across issuers

A core goal is to demonstrate proof-of-reserves logic spanning multiple issuers — each bank attesting against its own reserves while the network reconciles a shared view. This depends entirely on the proposed proof-of-reserves design.

Where this fits

A+ is embedded infrastructure: each bank operates with its own keys and its own compliance stack. The testnet would not centralise custody or compliance — it would simply give participants a shared, observable environment to validate interoperability.

Proof of reserves proposed

What exists today

Nothing. There is no proof-of-reserve contract, no attestation mechanism, and no reserve query anywhere in the A+ Protocol stack. You cannot ask the network whether USDA+ is fully reserved, and the smart contracts do not track reserves at all.

Reserve sufficiency is currently the issuing bank's off-chain responsibility. Each member bank mints and redeems USDA+ against its own reserves within a bounded, non-refilling mint allowance, and is solely accountable for holding adequate USD backing. A+ never co-signs mints and does not custody, measure, or verify any bank's reserves.

The rest of this page describes a design we are proposing for review.

Proposed design

We propose two complementary attestation scopes:

The por_update event

Attestations would be surfaced through the proposed por_update event relayed by the integration platform. The payload is defined in /schemas/events.schema.json and would carry:

Field	Type	Description
total_supply	Money	Total USDA+ in circulation for the attested scope (per-issuer or network-wide).
total_reserves	Money	USD reserves backing that supply, as attested.
reserve_ratio	number	total_reserves / total_supply. A value >= 1.0 would indicate full reservation.
as_of	integer	Unix milliseconds the reserves were measured.
attestation.source	string	Where the figure came from — issuer-self-report, third-party-auditor, or onchain-por-feed.

{
  "type": "por_update",
  "org_id": null,
  "payload": {
    "issuer_org_id": null,
    "total_supply": { "amount": "1000000.000000", "currency": "USDA+" },
    "total_reserves": { "amount": "1002300.00", "currency": "USD" },
    "reserve_ratio": 1.0023,
    "as_of": 1781990400000,
    "attestation": {
      "source": "third-party-auditor",
      "url": "https://example.com/attestation/2026-06"
    }
  }
}

Maturity path for the attestation source

We propose the attestation.source field would evolve as trust assumptions tighten:

1. Issuer self-report. Each bank publishes its own reserve figure (issuer-self-report). Lowest assurance; fastest to ship.
2. Third-party auditor. An independent auditor signs the attestation (third-party-auditor), with a url or ref to the report.
3. On-chain PoR feed. Reserves are published to an on-chain feed (onchain-por-feed) the network can read directly, removing the off-chain trust gap.

Tie-in to the bounded mint allowance

Today an issuer's mint allowance is set manually by the A+ manager. We propose that, in a mature design, an issuer's allowance could be bounded by its attested reserves — the allowance the manager grants (or that increaseMintAllowance permits) would not exceed the bank's most recent attested total_reserves. This would enforce full reservation at the protocol edge: a bank could never mint beyond what it has attested to holding.

Open questions

• Attestation cadence and freshness. How stale can an attestation be before an allowance is frozen? Is as_of enough, or is a continuous feed_reading needed between snapshots?
• Allowance enforcement. Should the reserve bound be enforced on-chain (in APlusAuthority) or off-chain by the manager? On-chain enforcement requires a trusted PoR feed.
• Currency and valuation. total_reserves is in USD, but reserves may be T-bills or deposits. Who values them, and at what frequency?
• Auditor trust and signatures. What signs a third-party-auditor attestation, and how would a bank verify signed_by?
• Disclosure scope. Should per-issuer reserve figures be broadcast to all banks, or only the network-wide aggregate?

Related

Off-chain and fiat-wire layer proposed

The gap a bank partner raised

A+ today is purely on-chain. A whitelisted custody wallet calls token.mint(dst, amt) to issue and token.burn(src, amt) to redeem, bounded by a non-refilling mint allowance. The smart contracts are the source of truth, and that is the full extent of what runs today.

A bank partner noted that this leaves no link between the fiat side and the chain side. When a customer sends a USD wire to fund issuance, nothing in the system acknowledges that wire or ties it to a specific mint. The decision "this wire arrived, so this bank may now mint up to this amount" is made entirely outside A+, by hand.

What is proposed

An off-chain layer that would sit between a bank's fiat rails and its on-chain mint key. It is a design proposal with no implementation.

1. Wire received. The bank's fiat system would record an incoming USD wire (amount, reference, settlement time) into the off-chain layer.
2. Mapped to a mint authorisation. The layer would map that wire to a bounded mint authorisation: wire received → mint up to that amount. It would not co-sign or execute the mint — it would only express the ceiling the bank is now entitled to issue against its own reserves.
3. Mint executed on-chain, unchanged. The bank would still call token.mint(dst, amt) directly from its whitelisted wallet, within its existing allowance. The on-chain path would not change.
4. Fiat instruction logged off-chain. The fiat instruction would be logged off-chain for the bank's reporting and compliance records, giving an auditable trail from wire to mint.

Compliance stays bank-side

This layer is proposed to be reconciliation and reporting only. It would not centralise compliance.

• Each bank would continue to run its own TRM / screening stack against its own customers and counterparties.
• A+ would not ingest, store, or adjudicate compliance data on banks' behalf.
• The off-chain log would be the bank's record, held in the bank's environment, not a shared A+ compliance database.

How it would relate to events

If built, fiat-wire acknowledgements would be a natural producer of off-chain context that pairs with the on-chain mint and redeem events in the proposed events model. A wire acknowledgement would precede the on-chain mint it authorises, so a consumer could correlate a fiat instruction with the resulting mint event by amount and reference.

Status

GENIUS Act compliance

The GENIUS Act (Guiding and Establishing National Innovation for U.S. Stablecoins Act) is the first U.S. federal framework for payment stablecoins. Crucially, it regulates the issuer, not the infrastructure.

In A+, the issuer is each member bank — a permitted payment stablecoin issuer (PPSI). A+ is the shared infrastructure those banks operate. So GENIUS compliance is a split responsibility: the bank carries the issuer obligations (reserves, AML, audits, redemption), and A+ provides the on-chain primitives and controls that let those obligations be enforced and evidenced.

Requirement-by-requirement

GENIUS requirement	How A+ addresses it	Status
Permitted issuer — only PPSIs (bank / IDI subsidiaries, licensed nonbanks) may issue	Multi-issuer model: each issuer is a regulated bank that holds MINT_ROLE / BURN_ROLE. A+ is infrastructure and never issues or co-signs.	Satisfied
1:1 reserves in HQLA (T-bills, demand deposits, repos, MMFs), bankruptcy-remote, no rehypothecation	Each bank backs the USDA+ it mints with its own reserves and holds them itself; A+ never custodies, pledges, or reuses reserves. Mint is capped by a bounded, non-refilling allowance. Reserve holding is off-chain and a proposed part of the program.	In development
No interest / yield to holders	USDA+ is a plain ERC-20 with no rebase or holder-interest mechanism; banks keep their own reserve yield rather than paying it to token holders.	Satisfied
Redemption at par	On-chain burn(src, amt) redeems USDA+ 1:1 against the bank's reserves.	Satisfied
Monthly reserve attestation + public disclosure of reserve composition and outstanding supply	Proposed proof-of-reserves: a por_update event carrying total_supply, total_reserves, reserve_ratio, and an attestation source (self-report → third-party auditor → on-chain feed). Not yet built.	Proposed
AML / BSA program + sanctions screening (issuer is a "financial institution")	Each bank runs its own AML / sanctions stack in its own environment. A+ deliberately does not centralise compliance ingestion. This integration is off-chain and in development.	In development
Transaction blocking + lawful-order freeze / seize / burn (§ 4(a)(6)(B))	A freezer compliance role (modeled on USDC's blacklister): freeze / unfreeze / isFrozen enforced in the token's transfer hook, seizure via burn. Designed, but not on the deployed build.	Contracts need fixing
Emergency controls	pause / unpause on APlusAuthority halts mint / burn authorization network-wide.	Satisfied
Key governance appropriate to a regulated issuer	Privilege tiers: Owner (cold multisig), Manager (warm multisig), Minter / Burner (the banks), and the Freezer (compliance, pending deployment).	Satisfied

A+'s public positioning cites § 4 & § 5 for the overall regulatory setup (AML/BSA integration, reserve management, smart-contract compliance primitives) and § 4(a)(6)(B) for the freeze requirement.

Open compliance gaps

What the issuing bank still owns

A+ cannot make a bank compliant; it can only give the bank the rails. Under GENIUS the bank remains responsible for:

• Holding 1:1 HQLA reserves in bankruptcy-remote accounts, and not rehypothecating them.
• Its own AML/BSA program, sanctions screening, and designated compliance officers.
• Engaging a registered public accounting firm for the monthly reserve attestation.
• Its permitted-issuer registration / licensing with the appropriate state or federal regulator.
• Acting on lawful orders (the freezer key, once deployed, is held and operated by the bank, not by A+).

Sources

• GENIUS Act of 2025 — S.1582 (119th Congress), full text.
• Treasury / FinCEN proposed AML & sanctions rule for stablecoin issuers (April 2026).
• GENIUS Act issuer requirements — overview.