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.

Key Terms

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

• Execution chain: Creditcoin blockchain with 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. Each query specifies which source chain, block number, and transaction it wants to be verified. The USC then extracts the data it needs from the verified transaction bytes.

• Proof: A cryptographic proof certifying that parts of 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. The system extracts 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, success of a transaction has to be verified in the universal smart contract by the dapp builders.

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 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 shows the flow of data from source chains to universal smart contracts on Creditcoin.

Reading the diagram above, we can see how groups of attestors monitor new source chain blocks and submit attestations via the P2P gossip network. When a user needs to verify a cross-chain transaction, it builds a query and generates Merkle and continuity proofs (via off-chain workers or the Proof Generation API). The USC contract then calls the on-chain query verifier, which is a part of the Oracle, directly with the proof. The verifier checks the proof immediately and the USC contract can use the verified data to trigger business logic across any number of custom DApps.

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.