Every Transaction, Decoded.
Every Policy, Enforced.
Before the Signature.

There's a moment in every digital asset transaction that almost nobody talks about: the instant before the signature.

After the loan officer approves. After the DACS score clears. After the collateral is verified. Before the transaction actually reaches the blockchain. In that window — a few milliseconds of compute — is where the real compliance question lives. Not "did this transaction pass?" but "should this transaction have been allowed to run at all?"

That's the question we built AetherumTxGuard to answer.

The Problem With Audit Trails That Start After Execution

Most audit infrastructure in financial technology is retrospective. Something happens, it gets logged. A transaction executes, a record is created. The regulator comes in, you pull the logs, you show what occurred.

That's not a compliance system. That's a record-keeping system.

The NCUA's examination framework — and the broader supervisory posture of every federal financial regulator — is moving in a clear direction: toward pre-execution controls. Toward evidence that the institution had policy gates in place before funds moved, not just after. Toward demonstrating that a human-reviewed, institution-configured rule set was consulted and passed before any cryptographic signing occurred.

We've been building toward this architecture since day one. What we shipped this week is the piece that makes it real.

What AetherumTxGuard Actually Does

Every blockchain transaction — collateral lock, loan disbursement, liquidation execution, yield deployment — is now intercepted by TxGuard before it reaches the signing layer.

Here's what happens in that window:

First, the raw transaction calldata is decoded. Not logged as a hex string. Decoded — resolved to a named function call with typed parameters, matched against a registry of approved protocol ABIs. "0xa9059cbb000000..." becomes "USDC transfer() to address 0x1234... for 25,000 tokens." Human-readable. Examiner-accessible. In plain English before anyone signs anything.

Second, the decoded transaction is evaluated against the credit union's own configured policy. Each institution sets its rules: which contract addresses are approved, which function calls are permitted, what the maximum transaction value is, whether dual approval is required for large movements. That policy lives in the institution's configuration — not in Aetherum's defaults — and it's enforced at the signing layer. A transaction that violates the policy doesn't get a warning. It gets blocked.

Third — and this is the piece that matters most for examination — the result of that verification is logged to the institution's on-chain audit trail before any transaction is submitted. Not after execution. Before. The pre-execution compliance check is itself a cryptographically-anchored event. Examiners don't see what happened. They see what was permitted to happen, and why.

Why This Changes the Examination Conversation

We've had the same conversation with every credit union we've spoken to about digital asset lending. It goes like this: the operational question isn't whether crypto collateral is viable. The CLARITY Act settled that. The question is how you prove to your supervisory committee and your NCUA examiner that you had the right controls in place.

Prior to TxGuard, the honest answer was: you'd show them the audit logs after the fact. You'd show them the DACS score on each loan. You'd show them the collateral monitoring cadence. All of that is valuable. None of it answers the question the examiner is actually asking, which is: what stopped a bad transaction from happening in the first place?

TxGuard answers that question directly. The pre-transaction verification log is the control. It shows — for every single on-chain action — that the transaction was decoded, that it matched an approved protocol, that it passed the institution's own policy rules, and that it was cleared before any signature was applied. That's not a log. That's a control framework.

Per-Institution Policy, Not Platform Defaults

One of the things we were most deliberate about in the architecture is that the policy layer belongs to each credit union individually.

This matters because the regulatory posture of a $500M community credit union in Iowa is different from a $5B institution in California. Their risk appetite is different. Their board-approved investment policy may have explicit constraints on specific asset types or transaction sizes. Their supervisory committee may require dual approval above a certain threshold.

Aetherum's platform enforces those constraints at the signing layer — not at the UI layer, not as a soft warning, but as a hard gate. The credit union configures their approved contract addresses, their function allowlists, their value thresholds. When a transaction request arrives that violates those parameters, it is rejected before it ever reaches the custody signing infrastructure, regardless of how it originated.

That's the difference between a compliance UI and a compliance system.

Yield Access, Policy-Gated

The same TxGuard infrastructure now governs yield deployment for credit unions on the platform.

One of the underutilized opportunities in crypto-collateralized lending is that idle collateral — assets deposited and locked but not yet at risk of liquidation — can earn yield in approved protocols. That's a real economic benefit for the credit union and, passed through, for the member.

But deploying collateral into any external protocol without a rigorous verification layer creates exactly the kind of operational risk that credit union boards and examiners worry about. With TxGuard, every yield deployment request is routed through the same decode-and-verify pipeline. The target protocol must be in the approved registry. The deployment must pass the institution's policy. The pre-execution log entry is created. Then and only then does the position record get written.

The result: credit unions can access yield on idle collateral with full regulatory confidence — not as an exception to their compliance framework, but as a product that runs through it.

What NCUA Examiners See

We built a dedicated reporting layer for examiners directly into the platform. Through the NCUA Examiner interface, any authorized examiner can pull:

A pre-transaction audit report showing every TxGuard verification call — passed or blocked — for any credit union, over any date range, with the decoded transaction detail for each.

A policy compliance report showing the current configuration of the institution's transaction policy with a human-readable summary of every active constraint.

A yield position report showing all deployed collateral positions, deployed amounts, estimated yield, and fee calculations.

And a full compliance package that bundles all three into a single timestamped export — structured for examiner review, not internal dashboards.

The examination conversation doesn't start with "here's what happened." It starts with "here are the controls that were running before anything happened." That's a different conversation entirely.

This Is What Audit-Native Actually Means

We use the phrase "audit-native infrastructure" to describe Aetherum. We've used it since the beginning. But it's worth being precise about what that means at the architectural level.

Audit-native doesn't mean we log everything. Every platform logs everything. It means the compliance record is generated as a byproduct of the transaction execution process itself — not as a separate reporting layer bolted on afterward. It means the cryptographic proof exists before the transaction occurs, not after. It means an examiner looking at the audit trail is looking at the same artifact the signing layer consulted, not a reconstruction of it.

TxGuard is the piece of the architecture that makes that claim fully true. Every on-chain action now generates a pre-execution compliance record. The log isn't derived from the transaction. The transaction is only permitted to proceed after the log entry is created.

That's audit-native infrastructure.

We built this because it's the right architecture for regulated institutions — and because we believe the credit unions that can say "every transaction was verified before signing" are going to have a fundamentally different examination experience than those that can't.

If you want to see it in the platform, we'd be glad to walk you through it.