Fairway Oracle: Bringing Compliance to DeFi on Cardano

Decentralized finance (DeFi) presents a compelling vision for a more open and inclusive financial system. It aims to deliver trustless, permissionless, and globally accessible financial services. However, as DeFi matures and institutional players enter the space, there is a growing need for compliant DeFi: a protocol that preserve decentralization while incorporating regulatory requirements such as Know Your Customer (KYC) and Anti-Money Laundering (AML) checks.

This is where the Fairway Oracle comes into play. It is a compliance-oracle system built on Cardano that bridges the gap between traditional regulatory requirements and decentralized finance, enabling institutional lending pools and other financial primitives that require identity verification.

Traditional DeFi operates on a simple principle: if you can sign a transaction with your keys, you can participate. But this creates challenges:

1. Regulatory compliance: Institutional lending pools may be legally required to verify user identities.
2. Risk management: Protocols may want to ensure participants meet certain criteria.
3. Reputation systems: Some DeFi applications need to bind actions to verified identities.

A naive solution would be to centralize the entire system, but that defeats the purpose of building on a blockchain. A better approach is to use oracles, trusted off-chain services that attest to specific facts (for example, “this user has passed KYC”) in a cryptographically verifiable way.

The Fairway Oracle architecture

1. On-chain validation (Aiken smart contract)

At the core is a spend validator written in Aiken that protects permissioned pool UTxOs. The validator enforces a simple rule: you can only spend these UTxOs if you present a valid compliance token signed by a whitelisted oracle.

The validator checks:

• Oracle authorization: Is the signing oracle in the whitelist?
• Cryptographic integrity: Is the signature valid?
• Anti-replay protection: Is the token bound to this specific UTxO?
• Action binding: Does the token authorize this exact action?
• Temporal validity: Is the token still within its validity window?
• Identity binding: Does the token match the transaction signer?

These parameters ensure that even if a token is intercepted, it cannot be used in unauthorized contexts.

        // Simplified validator logic
        validator {
          spend(
            datum: Option<PermissionedDatum>,
            redeemer: BorrowWithCompliance,
            own_ref: OutputReference,
            self: Transaction,
          ) {
            expect Some(oracle_datum) = datum
        
            let token = redeemer.compliance.token
        
            and {
              is_oracle_whitelisted(token.oracle_key, oracle_datum.whitelisted_oracles),
              verify_compliance_token(token, redeemer.compliance.oracle_signature),
              token.origin_output_reference == own_ref,
              validity_range_covers(token.validity_range, self.validity_range),
              token.borrow_action_hash == hash_borrow_action(redeemer.action),
              verify_user_matches_borrower(
                token.user_key,
                redeemer.action.borrower_address,
              ),
              list.has(self.extra_signatories, token.user_key),
            }
          }
        
          else(_) {
            fail
          }
        }
        

2. Off-chain oracle service (backend)

The oracle service is a backend server that:

• Verifies user identities through KYC providers
• Stores compliance records linked to Decentralized Identifiers (DIDs)
• Issues time-bounded compliance tokens upon request
• Signs token data using Ed25519 cryptography

        const tokenData = {
          did: request.did,
          userKey: request.userKey,
          originOutputReference: request.originOutputReference,
          borrowActionHash,
          validityRange,
          oraclePublicKey,
          nonce,
        };
        
        const { signature } = signTokenData(tokenData, CONFIG.oraclePrivateKey);
        
        const complianceToken = {
          token: tokenData,
          oracleSignature: signature,
        };
        

The user interface then uses this token when building the transaction:

3. User interface (frontend)

A web interface provides the user experience:

• Wallet connection and KYC flow
• Requesting compliance tokens for specific actions
• Building and submitting transactions with oracle attestations

Token lifecycle

Let’s walk through a borrowing flow to see how these pieces fit together.

Step 1: Identity verification

A user connects their wallet and initiates KYC. The oracle service:

1. Guides the user through identity verification.
2. Creates a binding between their DID, verification status, and wallet payment key.
3. Stores this compliance record in the database.

This happens once per user and establishes their identity in the syste

Step 2: Token request

When the user wants to borrow from a permissioned pool:

1. The frontend requests a compliance token from the oracle.
2. The request includes the user DID, payment key, the specific pool UTxO they want to spend, and action details (amount, interest rate, etc.).
3. The oracle verifies the user’s KYC status.

Step 3: Token issuance

If the user is compliant, the oracle creates a TokenData structure containing:

• user_key : the user’s payment credential hash
• origin_output_ref : the exact pool UTxO being spent (anti-replay)
• borrow_action_hash : a hash of the complete borrow action (prevents parameter tampering)
• validity_range : the time window when this token is valid
• oracle_key : the oracle’s public key
• nonce : optional uniqueness identifier

The oracle signs this data with its private key and returns both the token and signature to the frontend.

Step 4: Transaction submission

The frontend builds a Cardano transaction that:

1. Spends the pool UTxO.
2. Includes a redeemer with the borrow action details and the compliance token plus signature.
3. Is signed by the user’s wallet.

Step 5: On-chain validation

When the transaction hits the blockchain, the validator runs:

1. Extracts the oracle’s public key from the token.
2. Checks whether it is in the pool’s oracle whitelist.
3. Verifies the Ed25519 signature.
4. Confirms the token’s origin_output_ref matches the UTxO being spent.
5. Checks that borrow_action_hash matches the actual action in the redeemer.
6. Validates that the token’s time window covers the transaction’s validity range.
7. Ensures user_key matches the transaction signer.

If all checks pass, the transaction succeeds; otherwise, it is rejected.

Security model

The system employs several security mechanisms.

Anti-replay protection

Each token is bound to a specific UTxO via origin_output_ref. Once that UTxO is spent, the token becomes useless. This prevents attackers from reusing old tokens.

Action binding

The token contains a hash of the complete borrow action (amount, interest rate, etc.). Users cannot modify transaction parameters without invalidating the token.

Temporal security

Tokens have limited validity windows. Even if a token leaks, it can only be used during its designated timeframe—and only for the specific UTxO it was issued for.

Identity verification

The token binds to the user’s payment credential. Only the verified user who requested the token can use it, since they must sign the final transaction.

Oracle whitelisting

Pool operators control which oracles they trust through on-chain whitelists. This enables governance over compliance standards without sacrificing decentralization.

Trade-offs and design decisions

Centralization vs. decentralization

The oracle is a centralized trust point. However, this centralization is opt-in: only pools that require compliance use the oracle, while standard DeFi remains permissionless. Additionally, pool governance can whitelist multiple oracles to avoid single points of failure.

Privacy considerations

The on-chain validator does not see KYC data, only cryptographic attestations. Identity information stays off-chain. However, the oracle learns which wallet addresses correspond to verified identities, which introduces privacy considerations.

Performance

All heavy computation (KYC verification, token signing) happens off-chain. On-chain validation only performs lightweight cryptographic checks, which keeps it cost-efficient.

Use cases beyond lending

While designed for permissioned lending pools, the architecture supports many additional use cases:

• Accredited investor verification
• Geographic restrictions
• Reputation-gated DeFi access
• Sybil resistance
• Privacy-preserving regulatory reporting

Conclusion

The Fairway Oracle demonstrates that compliance and decentralization are not mutually exclusive. Cardano can host both permissionless and permissioned DeFi, allowing institutions and individuals to coexist on the same network.

As DeFi matures, compliance oracles will become critical infrastructure bridging traditional finance and decentralized markets.