HERO Section
COMPLIANCE Fact
FINANCIAL Gate
EVIDENCE Record
Transaction Details

FreezeWire

Prove the event. Enforce the outcome.

FreezeWire is a cross-chain compliance and credit enforcement system that turns verifiable Ethereum compliance events into enforceable credit restrictions on Creditcoin.

The core principle is simple:

Don't trust a service to tell Creditcoin what happened on Ethereum. Prove what happened, validate its meaning, and enforce the result on-chain.

The Problem

Blockchain-based credit systems can enforce rules on-chain, but they cannot natively read and trust application-level events that occur on another blockchain.

Consider a simple example: an address becomes blacklisted by Circle's USDC contract on Ethereum.

A Creditcoin-based lending system may need to prevent that counterparty from drawing additional credit. A traditional approach would use a centralized backend or oracle that tells the credit contract that the address is restricted.

That creates a new trust assumption.

The system is no longer enforcing a proven Ethereum fact. It is enforcing whatever the oracle reports.

FreezeWire was designed to remove that assumption.

The Idea

FreezeWire uses Attestcoin to prove an Ethereum transaction on Creditcoin and then performs its own application-level validation before changing the on-chain eligibility state.

The complete flow is:

Ethereum compliance event → Attestcoin proof → FreezeWire verification → EligibilityLedger → Credit restriction

The backend and frontend are only transport layers. They cannot directly decide that an address is restricted.

How It Works

1. An external compliance event occurs

FreezeWire uses a real Circle USDC Blacklisted event on Ethereum as its external compliance fact.

The demonstrated transaction is:

0xc9edfdbb67b48f26822d8769f63cb890599d98dec539f7f76b92edcc8a2ff787

It occurred at Ethereum block 25,705,174 with transaction index 18.

The affected address is:

0xe05F529f5284D75624eBa386CB716928c3b54A2A

The canonical Circle USDC contract is:

0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48

2. Attestcoin proves the Ethereum transaction

Creditcoin cannot natively read Ethereum transaction logs.

Attestcoin provides the cryptographic bridge that allows FreezeWire to verify Ethereum transaction history from within the Creditcoin environment.

On Creditcoin CC3, FreezeWire verifies the proof through the Attestcoin BlockProver precompile at:

0x0FD2

The demonstrated proof uses Attestcoin chainKey = 3.

3. FreezeWire validates the application-level event

A proof of inclusion is not automatically proof of meaning.

A transaction can be proven to exist in Ethereum history without proving that it represents the specific compliance fact the application cares about.

FreezeWire therefore validates:

Ethereum receipt status
Canonical Circle USDC contract address
Expected Blacklisted or UnBlacklisted event selector
Affected address from the event topics
Original transaction and event ordering
Recovered transaction index
Replay protection
Configured proof window

Only after these checks pass can the eligibility state change.

4. The eligibility state changes on-chain

The validated result is recorded in the EligibilityLedger.

The relevant state transition is:

ELIGIBLE → RESTRICTED

For a valid UnBlacklisted event, the state can transition back:

RESTRICTED → ELIGIBLE

The backend does not have a privileged setStatus operation that can arbitrarily change the state.

5. Creditcoin enforces the restriction

The GatedCreditLine reads the eligibility state and enforces the consequence.

When a restricted address attempts a protected credit operation, the contract reverts with:

Restricted()

This means the compliance result is not merely displayed in the frontend. It becomes an actual on-chain enforcement rule.

Architecture

FreezeWire separates verification, state, and enforcement into three contracts.

BlacklistVerifier

Responsible for:

Attestcoin proof verification
Ethereum transaction validation
Receipt status validation
Canonical USDC emitter validation
Event decoding
Event ordering
Replay protection

It does not own eligibility state.

EligibilityLedger

The on-chain source of truth for counterparty eligibility.

It owns the eligibility state and records the result of a successfully validated compliance event.

GatedCreditLine

Responsible for enforcement.

It does not verify Ethereum proofs. It reads the eligibility state and blocks protected credit operations when the counterparty is restricted.

This separation keeps verification, state, and enforcement independent.

Trust Model

FreezeWire deliberately treats the frontend and backend as untrusted.

The trust flow is:

Ethereum fact → Attestcoin proof → FreezeWire validation → On-chain state → Credit enforcement

The frontend can display information.

The backend can retrieve evidence and prepare transactions.

Neither is the source of truth for eligibility.

The on-chain verification and ledger state are what determine whether a counterparty is restricted.

Why Attestcoin Matters

Attestcoin is the critical bridge between the external Ethereum fact and Creditcoin enforcement.

Without a mechanism to prove Ethereum history inside Creditcoin, the application would need to rely on an external party to report what happened.

With Attestcoin, FreezeWire can verify the underlying blockchain evidence and then apply its own application-specific rules.

This creates a two-layer verification model:

Layer 1: Cryptographic verification

Did this transaction actually exist in the proven Ethereum history?

Layer 2: Application validation

Did that successful transaction contain the expected Circle USDC compliance event for the affected address?

Both layers are necessary.

Security Design

FreezeWire treats external blockchain data and user-provided inputs as potentially hostile.

Immutable emitter

The verifier relies on the canonical Circle USDC contract rather than accepting an arbitrary token contract from a client.

Receipt validation

The Ethereum transaction must have a successful receipt.

Event validation

The verifier checks the actual event selector and topics.

Address recovery

The affected address is recovered from the proven event data rather than blindly trusting frontend or backend input.

Ordering

The original Ethereum log ordering is preserved during event decoding.

Replay protection

A proven transaction cannot be processed repeatedly.

The replay identity is derived from the proven chain key, block height, and recovered transaction index.

No centralized status oracle

There is no privileged backend operation whose sole purpose is to declare an address restricted.

What Happens If the Proof Is Invalid?

FreezeWire does not treat every submitted proof as a valid compliance signal.

The validation pipeline is:

Proof received → Proof verified → Receipt checked → Emitter checked → Event checked → Address checked → Ordering checked → Replay checked → Eligibility updated

If any required verification step fails, the compliance state is not changed.

A transaction that is valid blockchain evidence but does not contain the expected compliance event also does not automatically make the address restricted.

This distinction is important because a generic blockchain proof should not automatically become an application authorization signal.

What We Learned

The most important lesson was:

Proof of inclusion is not the same as proof of meaning.

A cryptographic proof can establish that a transaction exists in blockchain history. The consuming application still needs to establish that the transaction succeeded, came from the expected contract, contained the expected event, targeted the expected address, and has not already been processed.

This made the consumer-side validation layer a fundamental part of the architecture.

We also learned that replay protection, immutable emitters, receipt status, event ordering, and proof-window handling should be treated as protocol-level security requirements rather than backend conveniences.

Challenges

The biggest technical challenge was crossing the trust boundary between Ethereum and Creditcoin without introducing a privileged status oracle.

Another challenge was correctly interpreting Ethereum event data from the proof instead of trusting metadata supplied by a client.

FreezeWire therefore recovers transaction information from the proof itself and validates the original Ethereum event structure and ordering.

The architecture also required a clean separation between proof verification, eligibility state, and credit enforcement so that the frontend and backend remain untrusted transport layers.

What FreezeWire Demonstrates

FreezeWire demonstrates a reusable pattern for cross-chain compliance:

External blockchain fact → Cryptographic proof → Application-level validation → On-chain state → Enforced financial action

The same architecture can extend beyond USDC blacklist events to other externally verifiable blockchain facts and compliance signals.

The underlying principle is:

If a system can verify what happened, it should not need to trust a party merely telling it what happened.

Current Status

FreezeWire is deployed on the Creditcoin CC3 testnet with a public frontend, backend, and live smart contracts.

The current implementation includes:

Attestcoin proof verification
Ethereum transaction validation
Circle USDC event validation
Receipt status validation
Event decoding
Replay protection
On-chain eligibility tracking
Credit action enforcement
Public transaction evidence
Public proof evidence
Automated smart contract tests
Automated backend tests
Automated frontend tests

Test Results

Smart Contracts: 95 passed
Backend: 46 passed
Frontend: 17 passed
Frontend Build: PASS

Live Evidence

Ethereum Transaction

0xc9edfdbb67b48f26822d8769f63cb890599d98dec539f7f76b92edcc8a2ff787

Ethereum Block

25,705,174

Transaction Index

18

Affected Address

0xe05F529f5284D75624eBa386CB716928c3b54A2A

Circle USDC

0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48

Attestcoin Chain Key

3

Attestcoin BlockProver