What the GL1 Programmable Compliance Paper Gets Right —
And What It Misses for Credit Unions

The Global Layer One initiative published a significant paper this month: Programmable Compliance: Compliance Architecture for Regulated Tokenised Assets. Contributors include the Monetary Authority of Singapore, the IMF, Banque de France, Standard Chartered, and Kinexys by J.P. Morgan. Chainlink's Automated Compliance Engine is featured as a reference implementation. ERC-3643 and the T-REX protocol are cited as the leading modular composable compliance standard.

This is not an academic exercise. It is the institutional financial system publishing its blueprint for how regulated activity will run on programmable infrastructure.

I've read it closely. The architecture is sound. The STAR framework — Status, Transaction, Asset, Reporting — is the right way to decompose compliance obligations in a tokenised environment. The Transaction Envelope concept, the separation of policy from execution, the Compliance Attestation as an immutable execution-time record: all of it points in the right direction.

But the paper has a blind spot. A significant one.

It was written entirely for banks, Virtual Asset Service Providers, and central bank digital currency corridors. Nowhere in its 33 pages does it address the 4,600 federally regulated credit unions serving 140 million Americans — institutions that operate under a distinct regulatory regime, serve individual members rather than institutional counterparties, and answer to examiners who need to read the compliance trail, not simply trust that it ran.

That gap is not a footnote. It is a fundamentally different design requirement. And Ethereum — not a bespoke permissioned chain — is the right infrastructure to close it.

Why the GL1 Model Assumes a World Credit Unions Don't Live In

The GL1 architecture is elegant precisely because it assumes certain things about its participants: they are legal entities, they operate or co-own the underlying ledger infrastructure, they have compliance teams capable of configuring Policy Managers, and their regulators operate at the institutional level.

Credit unions break all four assumptions.

They cannot afford bespoke ledger infrastructure. The GL1 model implicitly assumes that participants either operate shared institutional infrastructure or have the capital to build toward it. The average U.S. credit union has under $500 million in assets. Many have under $50 million. They cannot co-own a permissioned chain with J.P. Morgan. They need to plug into existing infrastructure that already works — and Ethereum, with its mature token standards, developer ecosystem, and institutional adoption curve, is that infrastructure.

Their compliance obligation runs to members, not entities. The GL1 Identity Management Module is designed around legal entity identifiers — vLEIs, LEIs, institutional KYC. The NCUA's compliance framework runs all the way down to the individual member: their income, their creditworthiness, their beneficial ownership, their investor eligibility. The GL1 paper's Party Packets accommodate "Entity-to-Entity, Entity-to-VASP, VASP-to-Entity, and VASP-to-VASP" patterns. There is no member-to-institution pattern. That is not an oversight for the paper's intended audience. For credit unions, it is the entire use case.

Their regulator is in the room. The GL1 governance model is well-designed for institutional self-governance — policy artefacts, trust dependency governance, execution governance, independent assurance. What it does not design for is a third party with statutory examination authority who arrives periodically and needs to reconstruct the compliance story from the chain. The NCUA examiner is not a downstream consumer of a Compliance Attestation. They are the reason the Compliance Attestation exists.

Audit-Native Is Not Audit-Capable

This is the distinction the GL1 paper comes closest to but never quite makes.

The paper is careful to note that Compliance Attestations "are not equivalent to regulatory filing obligations such as suspicious activity reports, transaction reports, or other regulatory returns." That's accurate and honest. But it leaves an important question unanswered: what does it take for programmable compliance outputs to be directly readable by a regulator, not just technically available?

For banks, the answer involves transformation — taking the on-chain evidentiary record and feeding it into existing reporting infrastructure. The compliance attestation is an input to a process that produces regulatory outputs.

For credit unions, the NCUA examiner arrives and looks at your loan files. They want to understand: how was this member's creditworthiness assessed? What collateral was held? Who approved the loan? What happened to the collateral position over time? These are not institutional reporting questions. They are member-level narrative questions that require a legible, auditable chain of custody from origination through repayment or liquidation.

The GL1 model is audit-capable. Credit union infrastructure needs to be audit-native.

Why Ethereum Is the Right Stack

This is where the GL1 paper's institutional framing creates an implicit assumption worth challenging: that programmable compliance for regulated finance requires permissioned infrastructure.

The paper acknowledges the tension. It notes that "broader market developments point toward increasing interaction with public or open ledger networks" and that "future programmable compliance frameworks may therefore need to operate across hybrid environments." But it stops short of advocating for public chain deployment for regulated activity.

Ethereum's maturity changes that calculus, particularly for credit unions.

ERC-3643 and ONCHAINID already solve the identity problem. ERC-3643 — the T-REX protocol cited in the GL1 paper — was designed around modular compliance modules linked to on-chain identity. ONCHAINID, built on ERC-734 and ERC-735, implements a claim-based identity system where issuers attach verifiable credentials to wallet addresses. This is not a theoretical architecture. It is deployed, audited, and in production.

For credit unions, ONCHAINID maps naturally to the member relationship. Each credit union deploys its own ClaimIssuer contract. Each member's on-chain identity is owned by the member, attested by the credit union, and verifiable by any counterparty or examiner with appropriate access. The credit union holds a revocable purpose-limited signing key — not custody of the member's identity, but the authority to attest to it. This preserves the member relationship that defines the credit union charter while enabling programmable compliance at the transaction layer.

ERC-3643 compliance modules implement the STAR framework natively. The GL1 STAR framework — Status, Transaction, Asset, Reporting — maps to ERC-3643's modular architecture in a way that is not coincidental. Status checks run through identity-linked claim verification. Transaction checks run through transfer restriction modules. Asset-level controls run through the token contract's administrative functions. Reporting runs through on-chain event emission that produces an immutable, timestamped audit trail.

The difference is that ERC-3643 was designed for deployment on public Ethereum — which means the audit trail is not held by any single institution, is not subject to any single institution's data governance, and is not dependent on any single institution's infrastructure uptime. For an NCUA examiner, that is not a liability. It is a feature.

Base mainnet provides the execution environment. Deploying on Base — Coinbase's Ethereum L2 — provides the cost economics that make credit union deployment viable. Transaction costs that would be prohibitive on Ethereum mainnet become operationally manageable. The security model inherits from Ethereum. The tooling inherits from the entire EVM ecosystem. And the institutional legitimacy of Coinbase's infrastructure provides a bridge to the regulatory conversations that credit unions need to have.

The Member Layer the GL1 Model Skips

The GL1 Transaction Envelope is designed to travel with a transaction, accumulating context and approvals as it moves through the system. Party Packets represent the actors involved. The Identity Manager enriches those packets with entity-level attributes and attestations.

This is the right model. But it assumes the parties are institutions.

For credit union lending, the transaction originates with a member who wants to borrow against their crypto holdings. That member is not a VASP. They are not a legal entity with an LEI. They are an individual with a credit union membership, a crypto wallet, a collateral position, and a loan application that needs to be evaluated, approved, and documented in a way that an NCUA examiner can reconstruct two years later.

The member layer requires:

The Risk and Governance Questions That Change for Credit Unions

The GL1 paper's risk section is thorough. Oracle dependency, smart contract rigidity, stale compliance states, cross-jurisdiction alignment, privacy and immutability tensions — these are all real. But several of them manifest differently in the credit union context.

Oracle dependency is more acute. Credit union collateral is crypto — which means real-time price feeds are not a nice-to-have, they are a safety and soundness requirement. LTV ratios need to be monitored continuously. Margin calls need to trigger automatically. Liquidation mechanisms need to execute reliably. The oracle infrastructure that supports this is not a background dependency — it is core to the risk model that the NCUA cares most about.

Smart contract rigidity creates examination risk. If a compliance rule is wrong and it is embedded in an immutable contract, the error may not surface until examination. The GL1 paper's solution — separate policy from execution so that policy can be updated without redeploying the asset — is the right answer. For credit unions, this is not optional. NCUA examination cycles mean that a compliance error may persist for 18 months before it is discovered. The architecture must support policy updates that are themselves auditable — timestamped, versioned, attributable to a specific governance action.

Administrative intervention needs explicit legal grounding. The GL1 paper discusses asset freezes, forced transfers, and recovery mechanisms as governance features. For credit unions, these are not architectural choices — they are legal obligations. A credit union that takes a crypto-collateralized loan to charge-off may be legally required to liquidate the collateral. The on-chain administrative control that enables that liquidation needs to be documented, governed, and auditable in a way that would survive legal scrutiny. The architecture needs to make that easy, not just possible.

What This Means for the Credit Union Ecosystem

The GL1 paper concludes with a call for further development in two areas: technical standards for heterogeneous ledger environments, and institutional and regulatory engagement on questions of policy precedence and evidentiary standards.

For credit unions, both of those conversations need to happen in parallel — and they need a reference implementation to anchor them.

The NCUA is not hostile to innovation. The GENIUS Act's stablecoin provisions signal that Congress is taking digital asset infrastructure seriously at the federal level. The question is not whether credit unions will eventually need programmable compliance infrastructure. The question is whether that infrastructure will be designed with their regulatory regime in mind, or whether they will be left to adapt institutional bank infrastructure that was never built for them.

Ethereum — with ERC-3643, ONCHAINID, Base mainnet, and the audit-native design principles that the GL1 paper points toward but does not fully articulate — is the right foundation. The architecture exists. The standards are mature. The regulatory conversation is underway.

What has been missing is an implementation purpose-built for credit unions: one that treats the NCUA examiner as a first-class stakeholder, the member as the primary identity primitive, and audit-native compliance as a design requirement rather than a feature.

That is what we are building at Aetherum.