USC Architecture Overview

Highest level description of the inner workings of the Creditcoin Oracle and Universal Smart Contracts

Overview

A decentralized oracle is a provider of information external to a blockchain which does not rely on a centralized trusted entity for its security. Instead, each step in the oracle’s data provisioning process is executed by a group of independent actors, none of which have the power to unilaterally interfere with data provisioning outcomes. By adding decentralized data provisioning to Creditcoin, we enable it to trustlessly support smart contracts which can access the state of any blockchain. These smart contracts, known as Universal Smart Contracts (USCs), enable novel cross -chain applications that can react to verified events from other chains.

USC Key Terms

• Source chain: A chain which is connected to Creditcoin via the Creditcoin Oracle. We begin by first supporting EVM chains such as Ethereum, with the eventual goal to enable data provisioning from any chain.

• Readability: Allows Creditcoin users and contracts to read the state of any source chain. Readability relies on a process called attestation which pro-actively tracks the state changes of source blockchains.

• Creditcoin chain: Creditcoin mainnet, testnet, or devnet. All these chains have Creditcoin oracle infrastructure and Universal Smart Contract support.

• Attestation: A cryptographic commitment to data from source chain blocks, validated through consensus.

• Query: A request to verify a transaction from a source chain on Creditcoin. Each query specifies which source chain, block number, and transaction it wants to be verified. Once a transaction is verified, a USC enabled dApp contract can extract the data it needs from the verified transaction bytes.

• Proof: A cryptographic proof certifying that a given transaction occurred on a source chain.

Proofs consist of Merkle proofs (for transaction inclusion) and continuity proofs (for block chain integrity). These are verified at native speeds on Creditcoin. After verification, dApp contracts can extract relevant transaction data directly from verified transaction bytes, bypassing the need for specialized proof systems.

• Native Proof Verifier Precompile: A native precompile on Creditcoin (address 0x0FD2) that verifies queries at native speed. It verifies transaction inclusion and block inclusion using Merkle proofs and continuity chains. See below for details.

The native verifier precompile does not validate if a transaction was successful or not. It only validates if a transaction is included in a block and that block is really a part of the confirmed source chain. Therefore, USC enabled dApp contracts MUST check the "status" field of the transaction to ensure security 0x1 → ✅ Success

Architecture

The Creditcoin Decentralized Oracle relies primarily on the following actors:

Attestors

These make assertions about their view of the latest state of a source chain, such as Ethereum. Creditcoin doesn't trust any single attestor's report about changes to a source chain's state. Instead, a decentralized network of attestors must reach consensus on what state changes, if any, have occurred. This consensus is provided as an aggregated signature of individual attestor votes that can be verified by Creditcoin validators.

For more information on attestors, check out the Step 1: Attestation section of the docs.

Validators

These form the authority set of the Creditcoin blockchain. Validators receive attestation transactions, perform basic structural checks, and include them in blocks through consensus. The runtime (executed by validators) verifies attestor BLS signatures and checks that sufficient quorum has been reached before committing attestations to on-chain storage.

Native Query Verifier Precompile

The Native Query Verifier Precompile (alternatively called the Block Prover Precompile) is a runtime component at address 0x0FD2 that verifies cross-chain data within Creditcoin transactions. It validates two proofs: a Merkle proof for transaction inclusion in a block, and a continuity proof linking that block to an on-chain attestation or checkpoint via a chain of block digests.

The precompile runs as compiled Rust code, avoiding EVM interpretation overhead. Verification is synchronous: given transaction data, a Merkle proof, and a continuity proof, it checks that the Merkle root matches the block in the continuity chain, that the chain ends at a valid attestation/checkpoint, and that block digests are correctly linked via cryptographic hashing.

Two functions are available: verify() (only view, no events) and verifyAndEmit() (state-changing, emits TransactionVerified events). USC contracts use this to verify cross-chain events and transactions in a single transaction, replacing external proof systems and off-chain services.

Interoperability

The net effect of this design is that third-party builders can create contracts on Creditcoin which have secure, trustless access to verified data from other chains. USC contracts can verify that specific transactions occurred on external blockchains (like Ethereum) and then react to those verified events by executing business logic on Creditcoin.

For example, a bridge contract could:

Verify that a user burned ETH on Ethereum (by verifying the burn transaction using the precompile)

Based on that verified proof, mint equivalent tokens on Creditcoin

Builders can leverage these properties to create universal smart contracts which support their own custom cross-chain DApp business logic, enabling trustless cross-chain applications without relying on centralized oracles or intermediaries.

For more information on how to set up your DApp's logic to leverage Creditcoin USC, check out the DApp Builder Infrastructure section of the docs.

Data Provisioning Flow

The diagram below depicts the flow of data from source chains to universal smart contracts on Creditcoin.

The diagram above illustrates readability of cross chain data using Creditcoin USC. Steps: 1-2. Attestors listen for new source chain blocks, vote on attestations, and store those attestations on-chain. These are used later by the Creditcoin Native Verifier to prove source chain transactions. 3a. Meanwhile, dApp builders listen for the emission of events on the source chain which are relevant to their dApp. 3b. When an event is detected, dApp builders send a request to the proof generation server asking for proof of the transaction containing the target event. 3c. The transaction and proofs are submitted to the USC enabled dApp, which forwards them to the Creditcoin Native Verifier. 4. The native verifier verifies merkle and continuity proofs, signaling whether or not the source chain transaction is valid 5. The USC enabled dApp decodes the verified transaction, extracting the relevant event. It then uses the event to trigger dApp logic and emit events.

Creditcoin Oracle Example Use Case

The following diagram demonstrates the use of Creditcoin USC to power a cross-chain loan infrastructure:

Red arrows represent the attestation process. Blue arrows represent the proving process which generates proofs for queries that are then verified synchronously by the Creditcoin Oracle.