Your Members' Crypto Eligibility Is Now Owned by Your Credit Union — On-Chain

When a member walks into your branch and asks to borrow against their Bitcoin, the first question your compliance officer asks is not about LTV. It's about identity: how do we prove this member is who they say they are, and that they've cleared your KYC process, in a way that holds up to examination?

Until now, that answer lived in your core system. It was a flag in a database — mutable, auditable only through your own logs, and entirely dependent on Aetherum's backend to enforce at the moment of lending.

As of tonight, that answer lives on the blockchain. And the contract that holds it is owned by your credit union — not Aetherum.

What We Built

Every credit union that onboards to Aetherum now gets two smart contracts deployed on Base mainnet at no cost. A ClaimIssuer — the on-chain authority that attests member eligibility — and an IdFactory — the registry that provisions a unique digital identity for each member.

Both contracts are owned by the credit union. Not Aetherum. The contract ownership address is yours. The audit trail written to the blockchain is yours. If you ever terminate your relationship with Aetherum, you keep the infrastructure.

The Custody Analogy That Matters Here

We've always operated on the principle that the credit union owns the asset — not Aetherum. Your members' crypto sits in wallets your institution controls directly. Aetherum is the software layer: we connect the pieces, enforce the policy, and generate the audit trail. We never hold custody.

The same principle now applies to identity. Your credit union is the on-chain authority for your members' lending eligibility. Aetherum holds only a narrowly scoped signing key — purpose 3, claim issuance only — that lets us attach KYC clearance as a cryptographic claim on behalf of your institution. That key cannot transfer contract ownership. It cannot modify your contracts. It cannot move funds. And you can revoke it at any time.

"Aetherum is the software layer. The way Jack Henry processes core banking on behalf of credit unions without owning the member relationship — that's exactly our model for on-chain identity."

What Your Examiner Will See

NCUA's supervisory priorities have been explicit: digital asset activities and third-party vendor relationships are examination focus areas. The question examiners ask when a credit union uses an outside vendor for compliance-critical infrastructure is always the same: who is ultimately responsible?

That last answer — "same model as any other core banking vendor relationship" — is the answer that closes the examination conversation. Credit unions understand vendor relationships. NCUA understands vendor relationships. The model is familiar. The audit trail is just better.

What This Means for Members

Nothing changes for the member. They apply for a loan. They get approved. The KYC they completed when they opened their account is automatically translated into on-chain eligibility behind the scenes.

No new app. No new wallet. No new onboarding step. The digital identity infrastructure is provisioned silently at loan origination — a member ONCHAINID deployed to Base, a KYC claim attached, the loan collateral gate cleared. From the member's perspective, it looks identical to any other loan approval.

From your institution's perspective, it looks like something new: compliance enforced at the chain level, not the application level. A member without a valid KYC claim on their ONCHAINID cannot receive a collateral credit event from your institution — the smart contract prevents it. Not your backend. The chain itself.

The Patent

The system we deployed tonight is covered by a pending patent. The invention is not the contracts — those are open standards (ERC-734, ERC-735). The invention is the governance architecture: per-institution contract ownership at deployment, cryptographic escrow-to-transfer for institutions without existing blockchain wallets, and scoped revocable vendor signing authority designed specifically for NCUA-regulated financial institutions.

That combination — ownership separated from operations at the contract level, with a documented transfer protocol and a permanently revocable vendor key — is what makes this an audit-native system rather than a vendor-managed one. It's the difference between a vendor who promises to keep good records and a vendor whose architecture prevents them from doing otherwise.